Ask an AI to build you an online ordering system and it will. Models, endpoints, a checkout flow, a decent-looking admin page. It works. You can place an order.
Then the interesting part starts.
What happens if 100,000 people place orders at the same time? What if the payment succeeds but creating the order fails? What if two people try to buy the last item at exactly the same moment? What if the database goes down?
None of those questions are about syntax.
The distance has been shrinking the entire time
I've been thinking about this lately: maybe the history of programming is, at its core, the history of reducing the distance between humans and machines.
At first we had to talk to machines in 0s and 1s. Then Assembly. Then C and C++, then Java, Python, JavaScript, and everything after. Each generation took another layer of the machine's complexity away from the programmer.
Today you can build real software without knowing exactly how a CPU executes every instruction. Nobody treats that as a loss. It's just where the line moved.
AI moves the line again. Instead of asking "how do I write this code?", you can say "I want this system to do this," and a large part of turning that intention into code gets handled for you.
Which brings up the obvious question.
So are programmers going to disappear?
I don't think so. But the meaning of "programmer" will probably change.
Because building something that works is different from building something that is well-designed.
Those two things look identical in a demo. They stop looking identical the first time the system meets real traffic or real money. The ordering system that handles one order at a time and the one that handles a hundred thousand are not the same system, even when the happy-path code is nearly the same.
So go back to those questions.
With 100,000 concurrent orders, you're thinking about where the contention is, what's holding a lock, what's queued and what's synchronous, what falls over first.
When the payment succeeds but the order fails, money left the customer's account and there's nothing to show for it. That's a correctness problem about state living in two systems at once, and clean code inside either one doesn't fix it.
Two people buying the last item at the same moment is a race. Whether you handle it depends on decisions made well before anyone wrote a line of business logic.
And if the database goes down: what does the system do, what does the user see, what's recoverable when it comes back?
These are questions about understanding the system and the limitations of the machine. You can't answer them by knowing the language better. You answer them by knowing what happens when the thing runs.
What the abstraction never removed
Every layer so far took away a machine detail, and once it was gone we stopped thinking about it.
AI takes away the code-writing layer. But the questions above were never in that layer. They sat on top of it the whole time, and they're still sitting there after the layer underneath gets automated.
Code writer to problem solver
I think the future won't belong to the person who can write code faster. It'll belong more to the person who better understands:
what needs to be built,
why it should be built this way,
what trade-offs are involved,
and how to know whether what we built actually works correctly.
That last one is worth sitting with. When you write the code yourself, you carry a rough model of it in your head, and that model is part of how you judge whether it's right. When you didn't write it, you don't get that for free. Knowing whether a system works becomes something you do deliberately instead of a byproduct of having typed it.
So the role shifts. Code writer to problem solver, or system designer, or whatever name ends up sticking. The label matters less than where the work goes.
And maybe AI isn't just another new tool. Maybe it's the next stage of the same journey that started with machine code and has always had one goal: to reduce the distance between what humans want and what machines can do.
Top comments (0)