The identity crisis running through software engineering right now has a simple source. Many engineers built their sense of worth on producing solutions in code that no one else could, and AI can now do that too. The mistake is treating that as a loss. The job was never code production. It was problem-solving, and as AI takes over the typing, the human work shifts to setting standards, defining boundaries, weighing tradeoffs, and owning what ships. Speed has been solved. Stewardship has not.
Matt Erman is a Senior Software Engineer at Blackboard, the education technology company behind one of the most widely used learning management platforms, and the author of Grokking Software Architecture, forthcoming from Manning. A self-taught developer turned engineer across banking, insurance, healthcare, and edtech, he started writing the book after noticing a widening gap between what AI demands of engineers and what they are actually learning.
"Our job was really never to actually write code. Our job was to solve problems, and code was just a vehicle to do that. Ideally, you treat the AI as your partner. This doesn't mean less work; it means higher-leverage work on the problems that actually matter. You have it do the coding tasks, but you set the standards, you set the plan, you come up with the guidelines for it," says Erman.
Erman's description of unguided AI is an image worth keeping. The model knows everything that has ever been done in software, which is precisely the problem when a request is too broad.
"It's like if you took 20 puzzles and took five pieces from each one and tried to put them together. You might get some that fit, but a lot of them aren't going to fit the way you want them to," he says. The fix is narrowing the workspace so the AI cannot wander, then refusing to accept the first output.
"You don't take what it first gives you. You question it, you have conversations with it. You're not a passenger with it, you're the driver of the situation." Engineers who tried one wide prompt, got a mishmash of three engineering concepts in one file, and wrote the tools off, he suggests, were diagnosing their own prompting, a shift in posture others have described as architects versus typists.
The irony Erman keeps circling is that the AI era has made foundational knowledge more valuable just as the industry stopped teaching it. Bestseller lists fill with books about using AI, while the architecture knowledge needed to judge its output goes neglected.
"The best use of AI is going to be someone who actually understands fundamentals and is able to guide the AI," he says. "If you don't have them, you have no idea what it's giving you. You don't know if it's correct, you don't know if it's wrong. You're just along for the ride."
That judgment covers scalability, system boundaries, third-party and cross-team integrations, and above all, security, which he wants treated as a first-class module from day one in heavily regulated industries such as Healthcare, Banking, Insurance, and EdTech. Especially since the same tools are sharpening attackers as fast as defenders, a dynamic already exposing carelessly built apps in the wild.
Speed without alignment accumulates quietly. The code works, the PRs merge, and months later, teams discover duplicated abstractions, strange behavioral couplings, and dependencies nobody designed.
"It's not enough to write good code. You have to write code that's consistent and aligned with the architecture of the underlying system, because otherwise you're just creating a mess," Erman says. The danger compounds because teams keep building on the flawed layer. "You can't fix the foundation when you already have ten stories built on it. It's really easy to get to a point where you realize, I just built the Leaning Tower of Pisa, architecturally speaking."
His early-warning system is review discipline. A hundred-file PR defeats any reviewer, so changes stay small and scoped, creating a boundary for the PR the same way architecture creates boundaries for the system.
The operational model Erman uses mirrors how a careful engineer would work alone, a structured approach in the spirit of prompt-driven engineering that he points to himself. He and the AI brainstorm, reject options with reasons, write the plan into a document, and then implement it in phases.
Each phase ends with checks for boundary violations and red flags, plus a sweep of prior phases for regressions that crept in. Failures become new regression tests, and tests must earn their place by catching edge cases or validating behavior rather than padding coverage. The whole team has to row in the same direction on AI use, because ten people moving at AI speed in ten directions produce a tangle that erases every hour the tools saved, the reason teams increasingly invest in a shared control plane for their agents.
What holds it together is a principle older than the tools. Erman borrows it from a restaurant manager he worked for years ago: inspect what you expect. AI is the implementation engine, but the engineer remains the accountable party for every decision that ships. "Treat the AI as an implementation engine," he says, "but you are the person who is actually responsible for the overall decisions and the overall accountability of the task."
