The Agent Hangover
Coding agents increase output faster than maintenance loops can keep systems in sync. Daemons give recurring engineering work an owner.
“AI coding agents are the great equalizer.”
No. They’re the great amplifier. They multiply your existing judgment — good or bad. The best engineers are pulling away.
The Inversion
The old rules of software engineering were optimized for humans. “Don’t over-engineer.” “Keep it DRY.” “Avoid premature abstraction.” These weren’t arbitrary, they encoded real tradeoffs about human constraints. How fast we type, how much we hold in working memory, how exhausting it is to read clever code.
But the constraints changed. When an agent writes code, there’s no typing cost. When an agent maintains code, verbose and explicit is actually easier than clever and compact.
The economics inverted, and a lot of “best practices” inverted with them.
Here’s where it gets uncomfortable: some engineers see this clearly. They understand why the old practices existed, so they can reason about which ones still apply. Other engineers learned the practices as rules. They know what to do but not why. They’re working from a map of a world that no longer exists.
You might think this is a training problem. Teach people the new rules. Update the docs.
It’s not a training problem. It’s a capacity problem.
The Reasoning Gap
To update your practices in a fast-moving environment, you need to run a specific loop. Notice when capabilities change. Hypothesize what that means for your approach. Evaluate whether the hypothesis holds. Propose a change to your team. Defend it against disagreement.
AI can help with some middle steps like explaining tradeoffs and generating alternatives, but it can’t close the loop. Its understanding of its own capabilities is always behind reality. It can’t tell you that the limitation you’re working around was fixed two months ago, or that a practice designed to compensate for its weaknesses no longer applies.
Some engineers can close this loop. Some can’t. The ones who can’t aren’t stupid or lazy. They just don’t have the abstract reasoning this requires.
In a stable environment, that didn’t matter. You could learn the rules, follow them well, and be productive for decades. We’re not in a stable environment anymore.
Not Less Productive — Net Negative
The implication is harsh, and I want to be direct: engineers below a certain cognitive threshold are becoming net negative.
Not “less productive.” Net negative.
When your team discusses changing a practice, a below-threshold engineer can’t evaluate the proposal on its merits. They appeal to tradition (“we’ve always done it this way”), authority (“the senior engineers at my last company said…”), or fear (“this seems risky”). These aren’t arguments. They’re friction.
Above-threshold engineers start routing around it. They make decisions in smaller groups, leave others out. The team bifurcates into people who decide things and people who execute and complain.
Then the second-order problem: your best engineers notice. They see leadership tolerating dead weight. They interpret this—correctly—as a signal that leadership doesn’t understand what’s happening. They start taking calls from recruiters.
You’re paying a friction tax and accelerating attrition of the people you need most. That’s what net negative means.
The Democratization Myth
The common objection is that AI tools should help. Can’t a below-threshold engineer just ask AI why a practice exists and whether it should change?
They can ask. But asking is the easy part. The hard parts are knowing when to ask, knowing what to ask, and evaluating whether the answer makes sense.
If you can’t distinguish good reasoning from plausible-sounding bullshit, the tool just gives you more confident-sounding wrong answers.
This is why the “AI democratizes coding” narrative has it backwards. AI tools are most valuable to people who already know what they’re doing. They save time on tasks you understand. They’re dangerous for tasks you don’t, because you can’t tell when they’re wrong.
The engineers who benefit most from AI are the ones who needed it least.
There Is No New Normal
The other response is to wait. Let the dust settle. Figure out the new best practices, then train everyone.
Best practices aren’t going to stabilize. Agent capabilities improve too fast. Whatever works today needs updating in six months. We’re not transitioning between stable states. We’re entering continuous change.
The teams that win aren’t the ones with the best practices right now. They’re the ones that update fastest. Your rate of improvement matters more than your current position.
Where Do You Stand?
I’m not happy about any of this. The world would be simpler if AI really did democratize coding, if it raised everyone up equally. But pretending otherwise hurts everyone — the below-threshold engineers not getting honest feedback and the above-threshold engineers paying the friction tax.
If you’re reading this and worried you might be below the threshold, here’s a test:
Can you explain, from first principles, why “don’t repeat yourself” became a best practice? Not what it means. Why it emerged. What tradeoffs it encodes. And whether those tradeoffs still hold when an AI agent can instantly refactor duplicated code.
If you can reason through the why, you’re probably fine. The specific answers matter less than the ability to think through them. If you can’t — if you’ve always treated best practices as rules to follow rather than tradeoffs to reason about — start working on that. Fast.
The floor is still rising. And it’s not going to stop.
