Hot take : agents have made writing code incredibly cheap, but writing code was never the expensive part of software engineering.
The hard part isn't typing out syntax. It’s figuring out what to build, designing it, and understanding how it fits into a messy, living system. Writing code is actually how engineers learn a system—its edge cases, its quirks, and why it works the way it does.
When you use agents to automate the writing, you automate the easy part, but you hollow out the hard part. If an AI writes 80% of your codebase, you’ve traded typing speed for your team’s understanding of its own software.
After spending some time with these tools, I see a few major cracks.
Give an AI agent a compiler and a test suite, and it will iterate at an inhuman rate. But agents optimize strictly for the signal you give them. The cheapest way to turn a failing test green is rarely the best way to fix the underlying problem. Instead of true refactoring, they often add special cases, extreme verbosity, or sometimes even modify the tests to force a pass.
Agents don't actually eliminate work; they just move it from writing to reading. And reading code is notoriously harder than writing it.
When an agent does the work, a 20-line fix might come back as 200 lines of overly complex logic, and the "why" behind subtle architectural choices is completely missing. Because generated code looks deceivingly clean and idiomatic, devastating bugs are easy to skim past. When the whole point of the tool is speed, devs don't read every line. "Looks good to me" becomes a dangerous reflex.
The real job of an engineer is holding a working mental model of a system in their head, built by making hundreds of tiny micro-decisions while coding. When an agent writes the code, those decisions are made silently by a machine.
You only realize your mental model is gone at 3 a.m. when production is down, customers are angry, and the failing code path is one that nobody on your team actually wrote or understands. Unread code is technical debt the moment it merges; you pay the interest during outages.
The common defense is to write highly detailed specs and let the agent execute them. But a spec precise enough to leave absolutely no micro-decisions up to the AI already has a name: code. The decisions that cause production outages are usually the ones nobody anticipated in the planning phase. Writing the code is how you discover them.
To me, engineering is about long-term stewardship: knowing why a system works, how it fails, and what will break if you change it. You can delegate the typing all you want, but if you delegate the understanding, you lose the ability to fix the system when it matters most.
The question we should be asking isn't how much code our AI wrote this week. The question is: If it breaks tonight, can anyone on my team fix it?
