Organizations are generating AI code faster than they can control it. The bottleneck has moved from writing code to reviewing it, and most engineering teams have not restructured around that shift. The result is codebases growing at unprecedented speed with declining confidence in what those codebases actually contain, how they behave under edge conditions, and whether anyone on the team understands them well enough to maintain them.
Matt Erman is a Senior Software Engineer at Blackboard, the education technology platform, and an Expert Contributor at Snorkel AI. He is the author of "Grokking Software Architecture" (Manning, 2026) and has spent over a decade building full-stack applications across education, banking, insurance, and financial services. He uses AI daily as a managed pair programmer but treats the relationship as one that requires constant oversight.
"AI is good at getting you to 60 or 70% of where you need to be," Erman says. "The other 30% is the hardest part. That's where your judgment and your expertise and understanding of how the system works comes into play. There are too many people that think the 70% is good enough."
Erman frames the shift bluntly. Writing code has always been the base-level expectation for software engineers. AI didn't eliminate a rare skill. It automated the commodity one. "A lot of developers over the years have based their identity on being able to write code and figure stuff out that nobody else could figure out," Erman says. "AI changes that. It almost leaves them with an identity void."
The value moves up the chain: oversight, governance, architectural accountability, and the judgment to determine what should be built in the first place. "The most successful teams are starting to treat AI as an implementation engine, but they're the ones that hold the ultimate architectural accountability," Erman says. "Whatever goes out in production that you put out in a PR is your responsibility. You can't come back and say AI did this and I thought it was right. That's being an amateur."
The trade-off triangle from his book still holds: speed, cost, and quality always compete. AI makes speed cheap. That doesn't make the output good. "You could have AI generate whatever, run it 24 hours a day, and generate millions of lines of code over a week," he says. "But what is that actually doing? There's no human that can check that much code. Now you've built a system that you don't even understand."
AI can burn down a codebase ten times faster than humans can. It presents solutions that miss edge cases, null checks, and security considerations. "It's very good at telling you confidently that this is the correct solution," Erman says. "But just because it tells you something doesn't mean it's true." Business leaders compound the problem by hearing only the speed stories. "They're constantly bombarded with success stories but never hear the negative consequences," Erman says. "Nobody mentions what happens two months later when the shortcuts start creating problems."
Erman's own workflow is deliberately structured to prevent skill atrophy. He treats AI as a pair programmer he manages: step-by-step interactions, constant review, approval before anything ships. "I'm still reading code, reviewing stuff, making small changes," he says. "This is not right; we shouldn't have nested for loops; this is an N-plus-one issue. It keeps me sharp because I'm not just accepting what it puts out."
The strongest use he has found for AI is codebase comprehension. When working in unfamiliar areas of a large product, he uses AI to generate high-level overviews of how systems connect, cutting hours of manual exploration down to minutes. "Is it going to give me 100% of the understanding? Probably not. But 80 or 85%, and I can fill in the gaps when I need to."
For engineering organizations, the slowdown is still faster than teams ever moved without AI. "Slowing down is still moving five times the speed you used to move," Erman says. "But building something quickly is never the ultimate goal. The goal is building something that is reliable, secure, and maintainable. If you can't confidently say your product is getting better, you probably want to take a step back."
