AI agents are generating code at a pace that far outstrips any human's ability to review it. That shift moves the engineer’s job upward, away from typing lines in an IDE to governing overall structure. Agents can write a working function, but the bigger issue is whether the system that function joins still holds together six months from now.
Matt Erman, Senior Software Engineer at Blackboard and author of the Manning book “Grokking Software Architecture,” joined Tom Howlett on episode 6 of The Next Commit. The discussion centered around a problem Matt has been working on from the architect's chair. His conclusion: the fundamentals of good software engineering still hold, but the way teams practice them has to change. What follows is his playbook for keeping architecture intact while agents scale output, and why verification has to carry the load that human review no longer can.
Why an agent's intelligence is the problem, not the solution
The common complaint about coding agents is that they are dumb. Matt turned this notion on its head, saying "[part] of the problem with AI agents is that they're too smart," and continued, "They know the entire internet. Everything that you could possibly know about architecture, the AI agent can know or knows."
That breadth is exactly the risk. An agent with every architectural pattern in its training data, handed a vague task, will reach for all of them at once. "If you don't constrain it, it will essentially take a hodgepodge of all these different architectures or ideas and patterns and just mix them together," Matt said, "because it doesn't know what you're actually trying to accomplish."
Most engineering organizations adopting AI tooling have discovered a powerful structural insight: constraint is actually the key to success. The more you narrow the solution space with architectural boundaries, the more an agent's knowledge becomes an asset instead of a source of entropy. "The more you can constrain it architecturally, the more you can constrain it with boundaries, the better your results are gonna be," Matt said, "because it won't allow the agent to go outside of those. Or if it does, it will fail the build and the agent will have to retry it."
Human review cannot scale, so stop trying to scale it
From Matt’s perspective, human code review has hit a wall. "AI agents are putting out so much code that human review is becoming almost impossible because you can't scale it," he said. "Even if you had ten people reviewing the code, all they'd be doing is reviewing code and not doing anything else."
Add more reviewers and you add more failure modes. People get tired. They take vacation. They have a bad day and rubber-stamp a diff they should have questioned. Multiply that across the volume agents now generate, and human review becomes the weakest link in the system.
Matt’s answer to these challenges is a shift in where you invest. "You don't optimize the code, you optimize the feedback loop," Matt said. "You basically scale the verification process around the agent instead of scaling the manual review process. Because that's what ultimately we'll be able to scale."
The safety net shifts from human attention to automated, independent code verification. The loop runs the same way every time, at machine speed, across every change. It catches what a distracted reviewer misses, and it does not get tired.
Fitness functions: the mechanism that holds architecture in place
The load-bearing piece of Matt's verification layer is architectural fitness functions. They test something unit and integration tests cannot reach: the structural rules of the system itself.
"You can write all the unit tests you want," Matt said. "Those will check your code... but they don’t necessarily check the architectural bounds." A fitness function does. It verifies that a controller stays clean, that a component respects its dependency direction, that nothing reaches into the database when it should go through the proper service.
The reason this matters is cost. An architectural violation might not cause any visible problem for months. Then it compounds. "Over the course of time, your architecture continues to degrade until you hit a point where it just fails completely," Matt said. "When that happens, that becomes much more expensive to fix than fixing a random code bug, because those are foundational components that need to be redone and re-architected." A bug has a small blast radius, whereas architectural rot can take down the whole application.
Fitness functions earn their keep twice. After implementation, they reject violations and force the agent to retry the right way. Before implementation, they act as an executable specification. Matt bakes them into the engineering guidelines his agent reads before planning, which also describe the target architecture. “So when it designs the plan, it already has [everything] planned out based on how the architecture should look." The agent arrives at the plan already constrained, so it rarely goes off track in the first place.
When something does escape, Matt fixes it and then locks it down. "The one thing that is extremely important is that you not only fix it, but you also create regression tests around it," Matt said. Each defect that slips through becomes a regression test, a durable record that both the team and the agent can learn from.
Break the work into phases you can actually verify
Letting an agent run an entire feature in one shot creates a debugging nightmare. If tests fail at the end, you have no idea which part broke it. "You could have done something in phase three that directly caused a regression in phase one," Matt said. "You have no idea where you're starting from."
His process splits every feature into phases, each one a clean commit boundary. Each phase has to meet the same bar as the full feature. “All the tests have to pass, there can be no regressions from the previous phase," he said. A passing phase gets committed as a baseline checkpoint before the next begins.
The payoff is containment. When a regression appears at phase seven and the earlier phases are green, the cause is confined to the latest increment. "If something goes wrong during that phase, you don't have to worry," Matt said. "You just go back, pull the last git commit and start over." This is the same discipline that has always defined good incremental development, now applied to keep agent output verifiable at every step.
Architecture is a scope, not a job title
One of Matt's most compelling ideas is that anyone who changes a system—regardless of their title—is, in effect, making architectural decisions. "Every time you make a change to a class or decide what table goes into a database or what service calls are made, those are all architectural decisions at the end of the day," he said. "The difference is just at what scope they're being made."
A software developer makes decisions at the component boundary. A senior engineer works at the application boundary. An architect looks at the whole system. Same kind of decision, different scope. That framing matters even more in the agentic era, because the engineer’s value is moving up the chain. "Instead of the engineer writing code at a lower level, the value of the engineer actually moves up into the architectural judgment," Matt said.
He described architectural growth as three stages:
- Awareness comes first: understanding how a change ripples through the system, who the downstream consumers are, what happens when something gets called.
- Alignment follows, as your work starts fitting the system's intent and you understand how things are done and why.
- Accountability is earned last. "As you start building the trust, eventually they'll start giving you more accountability," Matt said. "It's something that you earn over time."
That trust, critically, does not extend to the agent. "You don't trust the AI agent blindly, but you trust the verification system you build around the agent," Matt said. "If you don't trust the verification system that you've built, then it's probably not good enough." The engineer owns the intent, the constraints, and the evidence. The agent operates inside them.
The takeaway
Matt built his entire control system by hand, one skill file and fitness function at a time. That works for a disciplined engineer tending a single codebase. It does not scale to an organization running multiple agents across dozens of projects, where the architecture has to hold to one standard regardless of which tool wrote the code.
This is where his hard-won practice meets what code verification needs to become at scale. SonarQube is the independent verification layer for all code, and it works across all three loops. In the agentic loop, it feeds architectural context to coding agents as they plan and write, so the constraints are in place before the first line is generated. In the CI verification loop, it enforces the structure you intend in the quality gates your team already uses, and flags deviations as issues before they merge. In the code maintenance loop, it discovers your real architecture across the whole codebase, so it catches drift that builds up over months, not just the violation in today’s diff. Every change is held to one zero-trust, multilayered standard with an industry-leading low false-positive rate, whichever tool wrote it, so the engineer keeps the judgment while the verification layer carries the volume.
Agents write the code now. You still own the architecture. The teams that encode that ownership into an independent, enforceable standard are the ones whose systems will still hold together a year from now.
Listen to the full conversation with Matt Erman on The Next Commit.
