Good developers are often cautious of their own codebase. They know which parts are brittle, which corners are thinly tested, and which modules to approach carefully, and that knowledge shapes every change they make. Mike L. Swafford says coding agents have none of it. “Agents are unafraid of touching code,” he says. An agent knows only what it reads in the codebase, never the history of what has broken before. The first thing to break in a quality assurance (QA) pipeline is the human caution that the pipeline was relying on, and rebuilding that caution as something written down is where the work begins.
Write Down What Developers Used to Know
The defense against an agent’s fearlessness is to externalize the knowledge it lacks. Swafford recommends documenting the architectural rules that experienced developers hold in their heads, so the constraints an agent cannot infer become constraints it can read.
The second measure targets the areas an agent is most likely to damage without noticing. Backfilling tests in historically under-tested parts of the codebase creates a way to detect when behavior changes. Both measures improve quality no matter who or what is writing the code. The rules and tests that keep an agent from breaking things are the ones a team should have had all along.
Review the Intent, and Watch the Tests
Code review historically did more than catch bugs. Swafford notes it also spread a culture of quality, taught team members about the codebase, and provided a compliance safeguard by requiring at least two people to agree before the product’s behavior changed. Agents alter several of those functions at once.
AI radically changes code reviews. The sheer volume of generated code changes the nature of review. AI is excellent at finding code bugs, but not as great as understanding if it did the right thing. What a review must now do is validate intent. Did the agent produce a plan worth reviewing, and did it accomplish that plan? Swafford points to the tests as the most revealing signal. “If you see that it’s changing unrelated tests,” he says, “then that’s a clue that it probably broke something and its workaround was to change the tests.”
When the Verifier Writes the Tests
Agents increasingly write the tests for the code they just produced, which raises the problem of verifying the verifier. Swafford is candid that the industry lacks a standard way to do it. Tools like spec-kit and plan modes formalize part of the process, but validation still happens at the level of the code itself.
He sees a larger shift approaching, comparing it to the move from assembly language to compiled languages. Those lower layers never lost their value, but they stopped being the day-to-day surface of the work. AI is pushing the work up another layer. The determinism and confidence teams want will likely come from making intent specific and verifiable at the prompt layer, not only from checking the code that results. The field is not there yet, but that is the direction.
Deciding Which Code Should Exist
Writing code was the expensive part, and now it is cheap, while validating it has become the costly one. Put simply, the economics of software development are rapidly changing, so we must change how we build software. Code is cheap but merging isn’t. Experiment more but be willing to throw away your prototypes.
Swafford is wary of the obvious failure. Turning cheap code generation toward new features would expand a product’s surface area and make it harder to use. The better use of the capability is security, reliability, and performance. As we move from human-directed to fleets of autonomous agents, this calls for automated flow control that allocates resources, GPUs (graphics processing units), tokens, and validation capacity according to intent and priority.
The hardest version of the problem returns to where the whole shift began. Teams move with far greater confidence in new codebases than in the legacy systems, and the reason is the same undocumented knowledge that makes agents dangerous anywhere. Legacy code carries the “what” without the “why.” The intent behind decades of changes was never written down, and code from 25 or 30 years ago reflects design and validation standards that have since changed substantially.
The caution a good developer brings to a fragile module is exactly what an agent cannot supply, and a legacy codebase cannot provide. Getting as much from these long-lived products as teams now get from new ones is the real frontier. To learn more, connect with Mike L. Swafford on LinkedIn.
