For the last two years, every conversation about software engineering has orbited the same question: "Will AI replace programmers?"
It's the wrong question.
AI made generating code cheap. It did not — and cannot — make knowing what to build any easier. The bottleneck was never typing. It was always understanding the problem, modeling the right abstractions, and knowing what the user actually needs. AI just made that gap visible to everyone.
The bottleneck was never the code
I spend most of my time not writing code. I spend it modeling.
When I built the document editing workflow for Seed, the hard part wasn't rendering a ProseMirror editor — there are 47 tutorials for that. The hard part was deciding: what happens when two people edit the same block at the same time? When does an autosave fire? What should the restore button do if there's nothing to restore? Can you edit while the document is still loading? What if the WebSocket drops mid-keystroke?
None of those questions have answers in code. They have answers in models. State machines, data flow diagrams, protocol definitions, invariants. The code is just the last 20% of the work — and it's the part AI is getting good at.
The real job has three parts
Understanding the problem. This means talking to users, watching them struggle, reading between the lines of a feature request. AI doesn't do this. It can't. The messy, human work of figuring out what's worth building — that's not going anywhere.
Modeling the solution. This is where state machines, type systems, and architecture live. "When the user clicks restore, we need to: fetch the previous version, show a diff, ask for confirmation, apply the change, invalidate caches on three different services, and handle partial failures at every step." That's not a function. That's a protocol. Modeling it correctly means the difference between a feature that works and one that silently corrupts data.
Writing the code. This is the part AI is accelerating. And honestly? That's great. The less time I spend wiring up API calls and writing boilerplate, the more time I have for parts 1 and 2 — the parts that actually determine whether the product is any good.
What this means for engineers
If your primary skill is converting Jira tickets into pull requests, you should be worried. AI can do that.
If your primary skill is figuring out which Jira ticket matters, what the right abstraction is, and how to model the problem so the solution doesn't collapse under its own complexity — you're more valuable than ever.
The engineers who thrive in the next decade won't be the fastest typists. They'll be the ones who can look at a messy product requirement and say: "This is actually a state machine with seven states. Here are the transitions. Here's what happens on failure. Let's model it before we build it."
State machines, not just code generators
This is why I keep reaching for state machines. Not because useState is bad — it's fine for simple cases. But because the moment your UI logic has more than three interacting booleans, you've already lost. You just haven't noticed yet.
A state machine makes explicit what states exist, what transitions are valid, and what can't happen. That last part — what can't happen — is the one that saves you from 3 AM bugs. AI can generate code. It cannot generate the model. That's still on you.
The takeaway
The AI conversation has been dominated by fear. "Will it take my job?" is the wrong frame.
The right frame: AI is making the typing part of our job cheaper every day. That means the thinking part — the modeling, the architecture, the product sense — is becoming the entire job. Not a nice-to-have. The whole thing.
If that scares you, it's probably because you've been optimizing for typing speed. If it excites you, we should talk.
Photo by Peaky Frames on Unsplash
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime