My friend Koushik Dasika wrote a post last week called “Coding Was Never the Hard Part.” He’s right. The interesting question is why we’re only able to say it out loud now.
For two decades, the conventional story about software has been that engineers are slow because coding is hard. Now AI writes code, and engineers are still slow, and the conventional story is collapsing in real time. Koushik’s post does an excellent job explaining to business leaders what the work actually consists of. I want to push on something adjacent: what this moment is exposing about the craft itself.
The Gap Was Never Closed
The gap between business and engineering didn’t widen because of AI. The gap was always there. AI just removed the only thing that was hiding it — the visible labor of typing code.
For twenty years, business priced engineering by what it could see. Tickets. Story points. PRs merged. Velocity charts. The unit of value was the visible artifact, because the invisible work — the judgment, the modeling, the trade-off math — never had a line item on anyone’s spreadsheet.
Now the visible artifact is cheap. The agent will produce it in seconds. And business is left holding a question it never had to ask before: what was I actually paying for?
The honest answer is: not much of what mattered. They were pricing the typing, not the thinking. The conversation about AI replacing engineers is mostly a conversation between people who already misunderstood the job and a tool that’s very good at the part of the job they could see. Of course they’re confused. Their model of the work was wrong before the AI showed up.
Syntax Out, Structure In
Here’s what actually changed. The job moved from syntax to structure.
Knowing syntax used to be a credential. You could build a career on knowing the difference between let and const, on memorizing which Rails callback fired in which order, on being the person who could write a regex from memory. That career is over. The AI knows all of it, faster, and it never forgets.
What the AI cannot do — at least not yet — is structure. And structure is the entire game.
Structure at the top of the stack: language and framework choice, service boundaries, data modeling, the question of whether this thing should be a monolith or three services or a queue with three workers behind it. Structure in the middle: implementation patterns, design patterns, where to put the seams, how to model the domain so the next change doesn’t require ripping it all out.
And structure at the small end, which is where most engineers live and most projects die: when to use a join table, when to reach for polymorphism and when to walk away from it, where to put the index, how to spot an N+1 query before it ships, when to cache, how to invalidate the cache (the only hard problem in computer science that hasn’t been solved by training on more data), and the constant temptation to abstract too early. Security touches every layer of this and gets quietly broken at every layer too.
All of these are decisions. The AI will make every one of them for you. It will not tell you which decision is right for your system, with your team, on your timeline, against your particular constraints. It will give you the most statistically common answer, beautifully rendered, and it will ship.
Getting these things right is more important than it has ever been. Because the cost of getting them wrong is now much, much faster to incur.
The Sport Was Always Optional
There’s always been a tribe of developers who treated software as a sport rather than a craft. The whiteboard interview, the Fibonacci puzzle, the binary-tree inversion, the LeetCode grind. These were the real engineers, in the telling, and the rest of us were tradespeople wiring up CRUD endpoints. The job was algorithms. Everything else was secretarial.
This worldview has aged poorly. The AI is better at the sport than the sport’s biggest fans. It is faster, more patient, and it does not get hungry. If the moat was ever cleverness, the moat is gone.
What the AI cannot do is remember. It cannot remember the microservices migration that ate a startup alive in 2019. It cannot remember the elegant ORM abstraction that seemed wonderful in month two and was strangling the team by month fourteen. It cannot remember the cache layer that made everything fast until it made everything wrong, in the worst possible way, on a Saturday night.
This is Chesterton’s Fence, run forward through time. The senior engineer is the person who knows why the fence is there — and, more importantly, who has watched what happens when someone tears down a fence that looked unnecessary on a Tuesday morning. The AI has not watched anything. It has read about fences. That is not the same thing.
The competitive advantage in this moment is not raw intelligence. The AI has more of it than you do. The advantage is having lived through enough architectural decisions to feel, in your gut, how a given choice will play out in three months, in six, in twelve. That feeling does not come from training data. It comes from being on call when the choice you made last March finally breaks.
“Code Quality” Was Never the Thing
There’s a quieter argument inside this moment that I think matters more than the loud ones. “Code quality” is a fallacy.
Quality is real. I believe in quality. Architectural quality is real. Security quality is real. Scale quality, performance quality, operational quality — all real. But “code quality” — the line-level, in-isolation, is-this-idiomatic, does-this-pass-the-linter version of the conversation — was never actually measuring quality. It was measuring something nearby and easier.
A single line of code, looked at in isolation, cannot be called good or bad. The information isn’t there. Quality only exists at the holistic level — at the level of how the parts fit together, how the system behaves under load, how the next change feels, how the security boundary holds. That is architectural quality. Code quality, as the term is usually used, is a proxy for it. And proxies have a way of replacing the thing they were meant to measure.
As my friend Koushik pointed out in his post, this is Goodhart’s Law: when a measure becomes a target, it stops being a good measure. He applied it to velocity. I’d apply it to the entire culture of code review as morality play. We made code-level aesthetics the target. The proxies — linter pass, idiomatic style, “clean code” — became the religion. And the actual quality, the thing the proxies were supposed to point at, drifted somewhere else entirely.
AI has now broken the proxy in plain view. It produces code that scores perfectly against every “code quality” metric anyone has ever written a blog post about. Lint-clean. Idiomatic. Tidy. Architecturally catastrophic. The measure and the thing being measured have finally and openly divorced.
The argument we should be having is about architectural quality. About whether the seams are in the right place. About whether the data model survives the second feature, and the fifth. About whether the security model assumes the right adversary. None of that fits in a PR comment that says “consider extracting this into a helper.”
What’s Left
Strip out the parts that AI now does cheaply, and what remains is the part that was always the actual job. Knowing where the seams go. Knowing which decision today produces which fire next quarter. Holding the system in your head and seeing how a small change ripples through it. Recognizing the architectural pattern that worked at one company and will quietly destroy another.
The people who matter in this moment are the ones who can see the system. Not the ones who can write the function. The judgment-holders. The ones with scar tissue. The ones who have watched a codebase outlive three product pivots and can tell you, without thinking too hard about it, where the next one is going to hurt.
AI did not end engineering. It ended the parts of engineering that were always going to be commoditized eventually — and in doing so, made the rest of it more valuable than it has ever been. Coding was never the hard part. Structure was. It still is. The only difference now is that we can finally say so.