A short field guide for anyone who has just watched a machine write working code
AI writes code well. That is a real change. It is not the same thing as “there is nothing left for people to do.” Here is the difference, drawn out slowly.
Picture the whole job of “making software that works” as one pie. Now find the slice that is a person typing code into an editor.
It is small. It was always small. Everything around it is the work of deciding what should exist, agreeing on what “right” means, and finding out where it is wrong.
So the honest version of the worry is not “AI can code.” It is: can a machine also do the four bigger slices? That is a much harder question, and the answer today is “parts of them, unevenly, and never the part where someone has to be accountable for the result.”
Here is a pattern that has repeated for two hundred years, and it surprises people every single time.
A tool arrives that does the main task ten times faster. Everyone assumes the workers doing that task will disappear. Often the opposite happens — because the tool makes the whole activity cheap enough that people want far more of it.
Software has an unusually strong version of this. There is a huge pile of software that is genuinely useful but has never been built, because it would cost £150,000 of engineering time and only save someone £4,000 a year. That software is not “not needed.” It is priced out.
Drop the price and the pile starts lighting up.
Drag the price down
Twenty-four real-ish jobs that a small business, a school or a charity would love to have built. Each lights up when building it costs less than it saves.
—
Nobody knows how far down that ladder demand actually reaches. It may reach a very long way. It may hit a ceiling nobody expected. But “the work all disappears” assumes the pile of unbuilt useful things is small, and it is not small.
Try this. One of these lines is wrong. The code runs perfectly — no error message, no crash. It just quietly gives you a slightly wrong number, forever.
Find the line that lies
This is meant to add up a list of numbers and give the average. Tap the line you think is broken.
function average(numbers) { for (let i = 0; i < numbers.length; i++) { }}
If you found it: notice what you actually did. You did not read the code. You read it against an idea in your head of what an average is. The code was fluent. The code was confident. The code was wrong.
You cannot supervise something you do not understand.
This is the whole argument in one line. A machine that writes code faster than you does not remove the need for someone who can tell whether the code is right. It increases it, because now there is far more code arriving, far faster, and all of it looks equally plausible.
Everything above is the reassuring case, and I think it is largely right. Here is the case against it, stated as strongly as I can.
| The comforting story | Why it might not hold |
|---|---|
| Past machines took over physical tasks, and people moved up into thinking work. | This time the thinking work is the thing being automated. There is no obvious floor above it to step onto. |
| Cheaper software means more software, so more jobs. | More software could be built by the same number of people, each doing ten times as much. Demand has to grow faster than productivity, and it might not. |
| Someone still has to check the machine’s work. | One good checker can check a lot of output. Ten writers can become one checker. |
And underneath all three sits the sharpest problem, which is not really about unemployment at all.
Beginner work — the simple, well-defined, someone-check-it-afterwards tasks — is the most automatable work there is. It is also, and this is the trap, exactly how a beginner becomes an expert. You get judgement by doing a thousand small things badly and being corrected.
So the fair summary is not “everything is fine” and not “it is over.” It is: there is a great deal of space left for people, and it is spread very unevenly. The generic advice “just learn to code and you will be fine” is finished. That is a different claim from “coding is finished.”
Yes — but be honest about which reason is yours, because the reasons have not aged equally.
| Reason for learning | How it is holding up |
|---|---|
| “It is a reliable ticket to a well-paid job.” | Weaker than it was. Still true at the top, much shakier at the entry level. |
| “I want to be able to check and steer what the machine builds.” | Stronger than ever. This is the job now. |
| “I want to build my own things without asking anyone.” | Enormously stronger. One person can now build what needed a team. |
| “It teaches me to think clearly about steps, state and failure.” | Unchanged, and it transfers to almost any systems-shaped work. |
There is a new and very easy way to learn nothing at all: hit the first moment of difficulty, ask the machine, get a working answer, move on. Repeat for a year. You will have shipped things. You will not be able to tell when the machine is wrong.
The struggle was never a hazing ritual. It is the mechanism. Being stuck, forming a wrong theory, testing it, and finding out precisely how you were wrong — that is the process that builds the model in your head that you later use to catch the machine lying to you. The tool does not remove that step. It just makes skipping it far more tempting, and the cost of skipping it arrives much later.
So: use it constantly. Ask it everything. But ask it after you have formed a guess, and make it explain rather than just deliver. Read the answer as a colleague’s draft, not a verdict.
Machines got extremely good at the smallest slice of the job. The bigger slices — deciding what is worth making, deciding what “right” means, noticing when something is quietly wrong, and standing behind the answer — are still ours, and there is now more of that work, not less.
The genuine problem is not that there is no room for people. It is that the room is at the top of a ladder whose bottom rungs are being sawn off, and we have not yet worked out what to replace them with.