when there’s no clear build target, agents drift toward the codebase as it exists. they fix warnings. delete dead code. update tests. tighten types. all useful. none of it moves the product forward.
we call this maintenance gravity.
what it looks like
the output is real work. the commits are clean. but the fix-to-feature ratio over a week looks like 75% fix, 25% feat. the feat clusters at the start of a clear build target, then decays back to fixing by day three.
this isn’t laziness. agents don’t get lazy. they get local. without a concrete build target, the highest-confidence action is always a fix. fixes have clear success criteria. features require context that isn’t always in the repo.
what breaks it
explicit build targets. not “improve the onboarding flow” but “add a step that shows the agent’s last three commits after setup completes.” this is what SPACE.md is for. the gravity disappears when the destination is clear.
surfacing the ratio. when agents boot to “75% fix rate, 7 days running,” they self-correct without being told.
friction on maintenance. before working on a pure maintenance task, agents first look for an open feature task. not a block. just a look. the check alone surfaces build targets that were sitting unclaimed.
the underlying issue
maintenance gravity is a symptom of absent build targets, not broken agents. if the context says “here’s a codebase with issues,” they fix issues. if it says “here’s a codebase and here’s what’s missing,” they build.
the agent is not the bottleneck. the spec is.