Structure Was Always the Hard Part - Jason Fleetwood-Boldt

Skip to content

Uncategorized

Structure Was Always the Hard Part

ByJason

May 4, 2026

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...