Think of the best developer you have ever worked with. Got a face in mind? Now answer honestly: was the thing that made them great their typing speed? Their encyclopedic knowledge of syntax? The elegance of their one-liners?
I doubt it. Whoever you pictured, I would bet they were the person who understood why the system existed, what the business actually needed, and how all the pieces fit together. The person you went to when something did not make sense - not when you needed a semicolon placed.
Hold that thought, because it explains almost everything about who will thrive in the AI era - and it has nothing to do with AI.
The developers who never saw the whole
Throughout my career I have met and worked with plenty of developers who could genuinely code. Clean functions, solid patterns, tests in place. Technically, nothing to complain about.
And yet, some of them never saw the connections. They implemented the ticket exactly as written - even when the ticket made no sense. They optimized a module nobody used. They could not tell you what the feature they built last month actually did for a customer, or why the company was willing to pay for it. Ask them “what problem does this solve?” and you would get a description of the code, not of the problem.
They were not bad people or lazy engineers. They had simply drawn a small circle around their job: the code is my responsibility, the rest is someone else’s.
Even back then - years before anyone said “LLM” - those were never the strong ones.
The strong ones always played a different game
The developers who stood out did something else. Before writing a line, they asked why. They knew roughly what the product earned money with, who used it, and what would happen downstream if their service returned garbage. They noticed when two teams were about to build the same thing twice. They pushed back on requirements - not to be difficult, but because they could see the requirement colliding with reality three steps ahead.
In other words: they kept the big picture in view. Business, context, users, the “why” - not just the lines in front of them.
Here is the uncomfortable part. We had a name for this all along. It is the old distinction between a developer and an engineer. One produces code. The other takes responsibility for a system that solves a problem - and treats code as just one tool for doing that.
That line was always there. We just did not have to look at it very often, because as long as code was expensive to produce, being a fast and correct producer was a real edge. You could build a solid career standing entirely on that side of the line.
AI did not draw the line - it exposed it
Then typing became free.
An agent now produces in minutes what a solid developer produced in a day. It does not get tired, it does not lose focus, and it knows every syntax trick in every language. Whatever value came purely from producing correct code has been repriced - brutally.
Notice what did not get repriced:
- Knowing which problem is worth solving in the first place.
- Understanding what the business needs, versus what the ticket says.
- Seeing how a change ripples through the whole system - and through the team.
- Judging whether a technically correct solution is actually the right one.
- Catching the moment when the confident-sounding machine is confidently wrong.
None of that got cheaper, because AI does not understand your business, your users, your constraints, or your politics. It has no idea why the system exists. It answers the question you asked - and the entire craft lies in asking the right question.
So the code-only developer lost their only edge, while the big-picture developer barely feels the shift. They were quietly doing the actual engineering all along; the machine just took over the part that was always the commodity.
AI did not create the divide between developers and engineers. It switched on the lights above it.
The line is crossable - from either side
Before this reads as gatekeeping, let me say the opposite loudly: which side of the line you are on has nothing to do with talent, seniority, or title. It is a habit of attention. I have seen juniors on the right side of it in their first year, and twenty-year veterans still stuck on the wrong side.
Crossing it is not mystical:
- Ask “what problem does this solve?” before every task. If you cannot answer it, that is your first task.
- Follow the money once. Learn what your product charges for, who pays, and roughly why they keep paying. It reframes every ticket you touch.
- Sit where the pain is. An hour with support tickets or a sales call teaches you more about your system than a week in the code.
- Trace one request end to end. From click to database and back. The connections you find are the actual system - the code is just the walls between them.
- Push back once per week. Find one requirement that does not make sense and say so, with a reason. That is engineering muscle, and it grows fast.
Nothing on that list requires permission. All of it compounds - and every bit of it is exactly the work AI cannot take from you, because it happens outside the editor.
The scribes and the authors
For centuries, being able to write - physically, beautifully, fast - was a profession. Scribes copied contracts, letters, and books, and the best of them were valued craftsmen. Their skill was real. But the value was never truly in the penmanship. It was in the message - and the message always belonged to someone else.
Then the printing press arrived. Within a generation, penmanship as a profession was finished. But here is the thing: the press did not hurt authors. It made them more powerful than ever - their ideas could suddenly travel further, faster, cheaper. The people who were destroyed were the ones whose entire value was in producing the text. The people who won were the ones who had something to say.
AI is our printing press. If your whole professional identity is the production of code, the press is coming for exactly that. But if your value was always the message - understanding the problem, the business, the system, the why - then the machine is not your replacement. It is your distribution.
Coding was never the job. It was the handwriting. The job was always the letter.