Why Coding Agents Slow Down Senior Engineers in Brownfield Codebases

Vendor demos are greenfield; enterprise balance sheets are brownfield. Watch a coding agent build a standalone service from an empty directory and the speedup looks undeniable. Put that same agent inside a ten-year-old, 500,000-line repository with implicit domain invariants, layered package boundaries, and three historical ways of handling database transactions, and the economics invert. In July 2025, METR published a randomized controlled trial of sixteen experienced open-source maintainers working on their own mature repositories (averaging 22,000 stars and over a million lines of code) using early-2025 AI tools: before starting, developers forecast a 24% speedup; afterward, they estimated they had worked 20% faster; on the stopwatch, AI assistance increased task completion time by 19%. (METR’s May 2026 follow-up noted that recruiting for randomized trials has grown harder because developers now resist non-AI control assignments, which makes your own repository telemetry the only honest arbiter.) Pair that finding with GitClear’s 2025 longitudinal analysis of 211 million changed lines showing a fourfold surge in duplicated code blocks, and the bottleneck is hiding in plain sight. Sizing your review queue stops pull requests from piling up after submission; the deeper engineering problem is why an unguided agent produces slow, duplicative rework inside a brownfield repo before a pull request is ever opened.

In early 2026, Birgitta Böckeler framed the discipline that separates greenfield demos from production agent engineering with a clean equation: Agent = Model + Harness, where the harness divides into feedforward Guides (context and instructions presented before the agent acts) and feedback Sensors (deterministic checks executed after the agent acts). When senior engineers lose time to a coding agent in a legacy codebase, they are rarely fighting the model’s raw reasoning ability. They are paying for a harness that drops the model into a half-million lines of code with no map, a clumsy edit tool, and no inner-loop sensors.

Start with the missing guide: the package and domain index. When an agent is asked to add an idempotency check or format a ledger entry in a repository with four thousand files, searching the tree turn by turn is expensive in both tokens and tool calls. Without a map, the lowest-friction move for the model is to write a brand-new forty-line helper right inside the file it is editing. That is where GitClear’s fourfold clone surge comes from, and why senior reviewers spend twenty minutes unwinding a five-minute patch . Fix it by generating a compact, CI-verified package map referenced directly from AGENTS.md: a two-hundred-line index that names each canonical internal package (pkg/money, pkg/idempotency, pkg/tenantctx), its exported types and entry-point functions, and the architectural layer it belongs to. Keep that map under a strict token budget and fail CI when a new package lands without an index entry.

Next, fix the edit tool itself. Many internal harnesses still expose either a full-file overwrite tool or a line-number patch tool (replace_lines(start, end, text)). Full-file rewrites on an 800-line brownfield module burn output tokens and routinely drop subtle concurrency comments or edge-case guards. Naive line-number patch tools fail in a different way: as soon as the agent applies the first edit in a multi-hunk change, every downstream line offset shifts, corrupting the second edit and sending the agent into a three-turn recovery spiral. Replace both with a content-addressed, anchor-matched surgical edit tool that requires the model to supply the exact surrounding lines of target context, rejects the edit if the anchor is missing or matches multiple locations, and runs a language-level AST parse check before returning a success receipt to the model.

Finally, move your architectural sensors inside the agent’s turn loop instead of leaving them in human code review or a twenty-minute CI pipeline. Every time the surgical edit tool mutates a file, the harness should automatically run three sub-five-second deterministic sensors before returning control to the model: an import-boundary linter (so a handler package cannot import a raw SQL store directly), an AST structural-similarity check against the canonical package index (flagging newly written functions whose signature and control flow duplicate an existing helper), and the dependency-scoped unit tests for the touched package. When the agent violates a layer boundary or re-implements a helper, the edit tool returns the sensor failure immediately and the agent repairs the mistake on its next turn while the context is still warm in cache.

You can tell within two weeks whether your brownfield harness is working by tracking two numbers per repository: the median number of post-PR human review rounds on agent-authored changes, and the net ratio of deleted or reused lines to newly added lines. Ask your staff engineers one question at this week’s retro: on the last agent-assisted pull request you rewrote by hand, did the agent fail because the model could not write the logic, or because nothing in the harness told it which existing package to call and which architectural boundary it just crossed?