A line in a draft I was reviewing recently stopped me mid-scroll:
AI does not force us to become better coders first. It forces us to become better thinkers, planners, and communicators.
The first part seemed silly to assume, but it was the second part that got me thinking.
Learning to code was, for a good chunk of the early 2000s, the clearest differentiator available to a working professional. It unlocked careers, salaries, and a kind of status that came from being one of the relatively few people who could turn an idea into software. Then the AI boom started, and that barrier began dropping fast.
The noise this produced is loud and mostly familiar: the death of programming, the end of junior roles, vibe coding as the new normal. But underneath, something more subtle and more interesting is happening, I think.
If AI can implement code fast, the bottleneck moves. Away from the code - to the specification. And here is where a common objection comes in: surely AI can help write the spec too? It can. But only up to a point. Because at some level, someone still has to answer the questions the spec raises. Should the product behave like this, or like that? What does the user actually need here? What edge case matters and which one doesn't? Those questions do not have answers inside the model. They have answers inside the domain.
Take that logic to its extreme for a moment: in the limit, the domain expert becomes the only human in the loop. Customer and producer collapse into one person. AI is just the tool in between. That is an exaggeration, and I know it. But it points at something real - the people who are closest to the problem are becoming more central to the work of building the solution.
Now, the obvious counter: agile exists for a reason. You ship an MVP fast, put it in front of real users, find out what you got wrong, and iterate. Not because you are lazy about specs, but because you genuinely cannot know the right spec until something real gets touched. That is still true. And faster, cheaper code generation might actually strengthen the case for iteration - more cycles for the same cost.
I don't think agile is wrong, but we might have to recalibrate it for new boundary conditions (nearly instant code). The slow part is no longer implementation. It is thinking. And thinking in circles without a good initial frame is expensive regardless of how fast the code comes out. The more interesting loop might be: iterate on the spec, not the code. You probably don't need a perfect spec upfront - but investing real time there, with someone who can answer the questions correctly, might get you to a good solution in significantly fewer cycles than the alternative. I am not certain which effect weighs heavier. But the direction feels clear.
The people who stand to benefit from this are the ones who were always close to the problem: domain experts, clinicians, teachers, operators - anyone who has actually lived inside the systems that software is supposed to improve. They always held the knowledge that made a specification correct. But they didn't get paid for it.
Now they might. That, I think, is the genuinely encouraging part beneath all the noise about AI taking jobs. It might return some jobs to the people they always belonged to. If you have spent the last decade building real expertise in something - not in tooling, but in a problem - you may have been investing without knowing it.
I have been testing this logic in practice. Over the last months I have been building with a specs-driven development approach: proper brainstorming first, detailed specs before a single line of code, then implementation. The results have been better than I expected - in one case I hit "run" and came out well past MVP on the first pass, with only minor clarifications needed on the spec side. You can see some of that work in my projects. I think specification-driven-development is worth exploring.
The scarcity has shifted. That tends to matter more than people's preferences about who should hold the monopoly on code.