Build1 publisher2 min readPublished
A dev.to engineer reviews greenfield code hardest because agents lack prior art to follow
A dev.to post makes a statistical case for reading your own code, since agents reproduce whatever pattern already dominates the repo, and its author goes hands-on in greenfield work while easing off once conventions are established.
The Engineer · Build desk
What happened
- A dev.to post argues that staying in touch with a codebase's architecture, module structure and code style is how you inject exemplar prior art for the coding agents that will edit it next.
- The author's stated practice is to be aggressively hands-on in a greenfield codebase and generally more hands-off in larger ones where the conventions are already well established.
- Strict deterministic lints and highly opinionated agent skills did not stop that output, the post says; sloppy code still found a way through.
- The stated order of work is make it right, make it maintainable, make it fast, make it pretty, exclusively in that sequence, with the first step asking both whether the thing was built right and whether it was the right thing.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Review effort gets scheduled against how settled a repo's conventions are, so a two-week-old service can claim more of a senior engineer's week than the large codebase that carries the revenue.
- cost Only one of the six review questions is answered by tooling, and the other five need somebody to read the change, so cheaper generation pushes cost into human review time.
- capability If the pattern claim holds, one well-factored module shapes the agent's later diffs in that area without anyone writing a rule or a lint for it.
The post's argument rests on one claim about how generation works. "Because LLMs thrive in statistically unsurprising patterns, coding agents can better excel at shipping maintainable code if given consistent prior art," the author wrote [2]. If the next diff is conditioned on what the agent found in the repo, then the most common pattern in the repo is the most likely one to come back.
For that to transfer to your codebase, the exemplar has to sit where the agent actually reads, since an agent that never opens the module never sees the pattern. The dominant pattern also has to be the one you want, because the agent will copy a bad one just as faithfully. The author's reason for treating early-stage code more carefully is that "wrong patterns compound with relentless coding agents now in the mix" [7].
The review step is where the hours go. It asks whether the changes made sense, whether the LLM generated unnecessary defensive programming slop, whether it wrote low-value tests, whether the feature exhibited poor interface and abstraction boundaries, whether the implementation followed codebase conventions and prior art, and whether the linter, the formatter and the tests all passed [11]. The author wrote: "I'm a particularly ruthless reviewer, especially when the other side is just an LLM agent" [12].
What the post offers is stated as a thesis [19], drawn from a year and a half of working with coding agents [13]. It does not report a measurement. On the model side the evidence is of the same kind: the author writes that the GPT-5 and GPT-6 families "love to generate defensive programming slop, helper function slop, and unit test slop out of the box" [4], then adds a dismissive aside about AGI [20]. Anyone deciding how much review time to buy is pricing one practitioner's pattern claim.
Agents do get run loose, at step one. The post uses them for quick prototype iteration, for generating UI variants in HTML files, and for testing whether an end-to-end flow works as expected, to prove a concept or disprove an assumption [10]. The author also invokes Mitchell Hashimoto: "we must always be ready for the Whiteboard Defense" [15]. The closing standard is a judgement call: "In a time when writing code is no longer the bottleneck, it is the software engineer's wisdom to say 'no' that makes a world of difference in the long-term maintainability of the codebase and (ultimately) the product," the author wrote [14].
What to watch
- A measurement would settle it: same task, same agent, one consistent repo against one inconsistent one, with slop rates compared.
- Whether agent tooling starts guaranteeing that designated exemplar modules land in the context window on every edit.
- Whether the greenfield rule holds in repos where the established conventions were themselves written by agents.