The popular version of the AI-and-engineering story is a comforting one: the tools lift everyone up, the junior writes senior-quality code, and the playing field levels out. It is a nice story. It is also, mostly, backwards. AI does not close the gap between engineers. It widens it — because the thing it rewards most is the one thing it cannot give you, which is judgement about why you are doing any of this.
The inversion
A lot of what we call best practice is really an accommodation to human limits. We kept functions short because a person can only hold so much in their head. We were disciplined about not repeating ourselves partly because changing the same thing in five places by hand is how bugs happen. We wrote things down because human memory is lossy. Good rules — but rules shaped by the cost of being a human at a keyboard.
AI changes those costs. When an agent can read an entire codebase in seconds, refactor a duplicated pattern across forty files atomically, and never forget where anything is, some of those old constraints simply stop binding. The economics that produced the rule inverted, and quietly, some of the rules inverted with them. Not all of them — but enough that "we've always done it this way" is no longer a safe default.
The reasoning gap
Here is where the gap opens. Two engineers both know the rule "don't repeat yourself." One of them knows why: that duplication is dangerous mainly because it drifts out of sync when you change one copy and forget the others, and that the rule is really about a maintenance risk, not about the mere existence of two similar blocks. The other just knows the rule.
Hand both of them a world where an AI can find and update every copy of a pattern instantly and reliably. The first engineer can reason about whether the rule still applies here, and when the duplication is now cheaper than the wrong abstraction. The second can only recite the rule. When the ground shifts, understanding lets you re-derive the right answer; memorisation just leaves you defending a rule whose reason has evaporated.
That is the reasoning gap, and AI pours fuel on it. The engineer who understood the tradeoffs gets a force multiplier. The engineer who memorised the conclusions gets a confident tool for producing more of yesterday's answers, faster.
Not just less productive — net negative
It would be one thing if the under-the-line engineer were simply less productive. The harder truth is that in a fast-moving environment they can go net negative for the team. They slow good changes down by appealing to tradition — "that's not how we do it" — without being able to say whether the tradition still makes sense. They generate friction, review by reflex, and anchor discussions to rules that no longer earn their keep. The cost is not just the work they do not do; it is the drag they put on everyone reasoning around them.
The democratization myth
This is why "AI democratises coding" is only half true. Yes, the floor of what is possible rose: someone who could not ship at all can now ship something. But the value of judgement rose faster. AI tools are most valuable to the people who already know what they are doing, because those are the people who can tell when the tool is right, when it is confidently wrong, and when the situation has changed enough that the old answer no longer holds. A tool that amplifies you is only as good as the thing being amplified.
There is no new normal
The instinct is to wait for things to settle — to learn the new best practices and then relax into them. But the capabilities are improving too quickly for that. Every few months some constraint that shaped how we work loosens again, and another batch of received wisdom quietly expires. There is no stable new normal to memorise. What matters is not where you stand today but how fast you can re-derive the right answer when the ground moves again — and that is a property of understanding, not of the rulebook you have memorised.
This is also the honest case for keeping a human firmly in the loop, and it is how we designed TaskGoblin. The agent writes the code and reviews the merge request, but it never approves and never merges — because the judgement about whether a change is actually right for this system, right now, is exactly the part that does not automate. The agent raises the floor of what gets produced. Deciding what should be true about the system is still yours, and it is worth more than it has ever been.
Where do you stand?
Here is a test you can run on yourself. Pick a practice you follow — DRY, small functions, exhaustive tests, whatever. Can you explain the constraint it was originally a response to? And can you say honestly whether that constraint still binds now that an AI is doing part of the work? If you can, you will be fine; you will keep re-deriving good answers as the tools change. If all you can offer is that it is the rule, that is worth noticing — because the floor is still rising, and the distance between reciting the rules and understanding them is exactly the distance it is opening up.
