The short answer#
A robot writes my code now. I still have a job.
Both of those are true. This post is about why.
I am not going to tell you that nothing changed. A lot changed, and some of it is bad news for people just starting. I will show you that part too, with the numbers, and I will not dress it up.
But the short answer is this. The part of the job where you type went away. The part where you decide got bigger. Those are not the same skill, and only one of them was ever the hard one.
My three robots#
I have used three of these tools. Here is the honest story of each.
2024, Cursor. It guessed the rest of my line while I typed it. Like a phone guessing your next word, but for code. Useful. Small.
2025, Claude Code. This one was a step change, and it is why I moved. It did not just finish a line. It could read twenty files, make a plan, change ten of them, run the tests, and come back and tell me what broke. It behaved less like autocomplete and more like an engineer who reads before writing.
2026, Kiro. I tried it recently, and I did not move. It is built by AWS around one strong idea: write down what you want before anything gets built. That idea is genuinely good and I took it with me — I explain it below, because it is the best habit in this whole post. But Claude Code is still what I open every morning, and knowing exactly what Kiro does well has not changed that. Liking an idea and switching tools are two different decisions.
What a robot helper really is#
If you do not write software, here is the whole thing in four steps.
You type what you want in plain words. The robot writes the code. The tests run. Then you read it and say yes or no. If you say no, it goes round again.
People call this an agent. That word just means it does several steps on its own before it comes back to you. It is not thinking. It is very fast, it has read a great deal of code, and it does not get bored.
Almost everyone does this now#
This is not a small group of early fans any more. Stack Overflow asked 49,009 people who write software, in 166 countries, in mid-2025.
Those top two bars are answers to two different questions, so I am keeping them apart. 84% use them or plan to. 80% actually use them. Either way, this is now the normal way to work.
Almost nobody trusts it#
Here is the part that surprised me. The same people who use it every day do not believe it.
Add them up. More people distrust the output than trust it. Only 3 in 100 highly trust it. And the warm feeling about these tools has been cooling, not warming: it fell from 72% to 60% in one year.
One more number, and it is my favourite in this whole post. When asked why they would still go and ask a person for help, the top answer, at 75%, was: "when I don't trust AI's answers."
Read that again. The most common reason to need a human being is that the machine might be wrong.
The "almost right" trap#
This is the heart of it, so I want to be slow and clear.
Wrong code is easy. Wrong code breaks. It breaks loudly, right away, and you go and fix it. Wrong code has never been the expensive kind.
Almost right code is the expensive kind. It runs. It passes the tests. It looks finished. It reads like something a careful person wrote. And then it does the wrong thing on a Tuesday, to one customer, in a way nobody notices for a month.
I am not the only one who has noticed. In the same survey, 66% said they now spend more time fixing code that is almost right. 45% named it their single biggest frustration with these tools.
So the robot did not delete the work. It moved the work. It used to be typing. Now it is reading. And reading someone else's almost-right code has always been harder than writing your own.
Say it first, build it after#
This is Kiro's good idea, and it is the thing I took away from trying it.
Most people use these tools by asking for a thing and watching code appear. Kiro will not let you. Before it writes anything, it writes three plain files and makes you approve each one.
The first time, this felt slow. I wanted the code. I had to sit and read a list of requirements instead.
It is slower at the start and much faster at the end. Here is why. A robot is extremely fast at building the wrong thing. If you have not said what you want, it will guess, and it will guess beautifully, and you will not find out until it is all built.
Ten minutes writing down what you actually want will save you an afternoon. That is not a new idea — people have said it about software for fifty years. What is new is that the cost of skipping it went up, because the building step got so cheap that you can now build the wrong thing before lunch.
So, to be plain about it: I did not switch. I kept Claude Code, because it is stronger at the engineering itself — reading a big codebase, holding all of it at once, doing the careful bits. What I took from Kiro was the habit, not the tool. I now write the spec first by hand, every time, inside Claude Code. You do not need Kiro to get the best thing about Kiro.
Why these two, and not an app builder#
People lump all of these tools together and call it "vibe coding." That hides the most useful thing you can know about them. There are two families, and they do different jobs.
The app builders are genuinely good at their job. You type a sentence and get a real, working app in your browser, with a database and a login screen, and no setup at all. If you are not an engineer, that is close to magic, and I am not going to sneer at it.
Their limit is well documented and it is the same limit in each of them. One review of these tools puts it plainly: as logic gets more complicated, the output "requires extensive restructuring," and as soon as your needs "shift from the standard quick prototypes and templates," the help gets thinner. There is a known pattern behind this that many people have noticed: the fiftieth prompt produces worse code than the fifth. Early on the tool is filling in a familiar shape. Later it is trying to hold your particular mess in its head.
So the common path is not to pick a side. It is to prototype in an app builder to find out whether the idea is any good, then rebuild in a codebase tool once you know it is.
Why I land on Claude Code#
Almost none of my work is starting from nothing. It is changing something that is already there, that has history, that has tests, and that has decisions in it made by people who are not around to ask.
That is the whole reason. Claude Code holds a large existing project in its head and works across many files at once, in the terminal, next to git and the tests. The app builders are not trying to do that, so it is not really a fair fight in either direction.
And Kiro earns its place for one thing, which I said above: it forces the plan out of your head and onto the page before it builds. You can copy that habit into any tool. I did.
Where Claude Code is weaker, since I should say it. When it does not understand your codebase, chasing the problem down is harder than in a tool with a graphical interface, because there is less to point at. And a GUI editor makes it easier to see exactly what changed before you accept it. If you are new, that visibility is worth a lot.
Do not pick by leaderboard#
You will see these tools ranked by score on tests like SWE-bench, where an agent is given a real bug and judged on whether it fixed it. It is tempting to just read off the top of the table.
Then researchers went and checked the marking. They found 345 patches that had been recorded as passing and were actually wrong, plus 36 tasks whose tests were too weak to catch a bad answer. It touched 24.4% of entries on one leaderboard and 40.9% on another, and it changed the rankings once corrected. Their conclusion was that these scores overstate how good the agents really are.
Sit with that for a second, because it is the same trap as before. The code looked right. The tests went green. The scoreboard wrote down "solved."
Even the scoreboard got fooled by almost-right code. That is not an argument for any particular tool. It is an argument for the thing this whole post is about: somebody has to actually read it.
One disclosure, since it matters: I use Claude Code daily and this site is built with it, so I am not a neutral party. Take the preference with salt. The reasoning is the part you should keep.
The servers changed too#
People talk about AI writing code. Fewer people talk about the other half of the job: the servers, the wiring, the boring setup. That changed just as much.
In September 2026 I moved this website. It used to sit on a free service. Now it sits on a server I rent.
The old way was: read the manual, type the settings by hand, get one character wrong, wait, try again. Two days of that, and most of it was not thinking. It was remembering exactly where a comma goes.
The new way was: I said what I wanted. A web server that serves the site. A job that picks up new work every minute and swaps it in without the site ever going dark. A daily check that emails me if the security certificate is close to running out, so that a quiet failure cannot stay quiet.
The robot wrote the settings. I read every line before any of it went live. That sentence is the whole job now.
Here is the honest catch. I could only approve it because I already knew what those settings should say. If you cannot read the config, you cannot approve the config, and then you are not an engineer with a fast helper. You are just hoping.
The words of the job changed#
If I write down what I did in a week three years ago, and what I do in a week now, the verbs are all different.
| What the job used to be | What the job is now |
|---|---|
| Type the code | Say what the code must do |
| Remember how to write it | Notice when it is wrong |
| Read the manual | Read the change |
| Ask "does it run?" | Ask "should it exist?" |
| Fix the thing that broke | Catch the thing that works but is wrong |
| Be fast at building | Be right about what to build |
Look down the right-hand column. Not one of those is typing. Every one of them is judgement. That is the move, in one table.
This is why people have started saying Product Engineer instead of just engineer. The title is not marketing. It is describing where the work actually went.
Fast is not the same as right#
Google's DORA team studies how software teams actually perform. Their 2025 report on AI found two things at once, and most people only quote the first.
AI raised how much work gets shipped. It also raised how often that work breaks. Speed went up and steadiness went down, in the same teams, at the same time.
Their line for it is very good: AI does not fix a team. It amplifies what the team already was. A good team gets better. A messy team makes a bigger mess, faster.
A fast car does not know where you live.
The scary part, said plainly#
I promised I would not dress this up, so here it is.
Stanford's Digital Economy Lab has been watching real payroll records — actual paycheques, not surveys — from late 2022 through June 2026. For young people aged 22 to 25, in the jobs most exposed to AI, employment is now about 19% below where it should be. And that gap is getting wider, not narrower.
Meanwhile older, more experienced people in the same field did fine.
The researchers found a clean split in which work got hit, and it is the most useful idea in this whole post. They separated two kinds of knowing:
- Things you can look up in a book. Facts, rules, steps, the standard way to do a standard thing.
- Things you only learn by doing them. Taste. Judgement. Knowing which question to ask. Knowing when an answer smells wrong.
The robot ate the first kind. It has barely touched the second.
And the first kind is exactly what a beginner is hired for. That is the bad news, straight: the bottom rung of the ladder is being sawn off. Not because juniors are bad, but because the task they used to be given is now free.
But the jobs did not vanish#
Now the other half, which gets quoted much less often.
That same Stanford team titled their most recent update "No Widespread Displacement." The pain is sharp and narrow — young people, in specific jobs — not broad.
And the US Bureau of Labor Statistics, which has no reason to be cheerful about this, currently projects software developer jobs to grow:
So hold both of these in your head at once, because both are true:
Fewer doors at the bottom. More work overall.
"There is no more need for coders" is not what the evidence says. What it says is narrower and stranger: there is less need for typing, and the people who only sold typing are the ones getting hurt.
The two halves of the job#
Here is the whole argument in one picture.
Every engineering job has always been two halves. The half where you work out what the right thing is. The half where you type it in.
The robot is very good at the second half and cannot do the first half at all. So the second half shrank, the first half grew to fill the space, and the total amount of work stayed roughly where it was.
If your value was in the typing half, this is frightening, and you should take it seriously. If your value was in the deciding half, you just got a very fast pair of hands.
What is left for a person#
Six things. I have not seen a machine do any of them well.
That last one deserves a sentence of its own. When it breaks at two in the morning, nobody wakes up the robot. The robot has no stake. You cannot outsource the part where it matters to you.
How to be the one still needed#
The old ladder had a bottom rung that said "do the simple tasks for a year and learn by doing them." That rung is the one being cut. So you have to climb differently.
Learn to read code faster than you write it. This is now the core skill and almost nobody practises it on purpose. Take code you did not write. Work out what it does. Find the bug in it.
Build whole things, not exercises. A small, finished, real thing that someone actually uses teaches you more than fifty tidy practice problems, because only the real one has the awkward parts.
Learn what "done" means. Not "it runs." Done means it handles the strange input, it fails in a way someone can understand, and it does not fall over on the busiest day.
Collect the things you cannot look up. Every time something breaks in a surprising way, you have just learned the kind of thing the robot does not have. Those hours are the ones that keep paying.
And do not practise being a typist. That job is taken.
So what do I actually think?#
I write far less code than I did three years ago. I ship much more. Both of those are true and neither of them is a contradiction.
My day is now mostly: work out what should exist, say it clearly enough that a machine can build it, then read very carefully what came back. The typing that used to fill that day is gone and I do not miss it.
What I would not do is tell a beginner that this is all fine. It is not all fine. The way in is genuinely harder than it was for me, and anyone who tells you otherwise is not looking at the payroll data.
But "nobody needs engineers any more" is not what is happening. Something more specific is happening. The part of the job you could look up stopped being worth paying for. The part you can only learn by doing it is worth more than it has ever been.
The machine cut the part. Somebody still has to measure it.
Build it together#
This is the work I care about most right now: deciding what is right, writing it down clearly, and checking what the machines build.
I am open to collaborating on exactly that — as a product engineer or on the DevOps side, which are the two halves this post has been about. Not a job and not a seat on your team. Something built together, with a start, an end, and something working at the finish.
- Build it end to end. From the spec through to it running in front of real users.
- Fix the checking step. For a team now shipping AI-written code faster than it can read it — the spec-first habit above, and a review that actually catches the almost-right ones.
- The servers and the wiring. Set up the way I described above, and handed over with the notes.
And if you think I have got any of this wrong, I would genuinely like to hear it — especially the numbers on young engineers. I would be glad to be wrong about those.
References#
- 2025 Developer Survey — AI (adoption, trust, daily use) — Stack Overflow — https://survey.stackoverflow.co/2025/ai
- Developers remain willing but reluctant to use AI (the "almost-right" figures, favourability) — Stack Overflow Blog — https://stackoverflow.blog/2025/12/29/developers-remain-willing-but-reluctant-to-use-ai-the-2025-developer-survey-results-are-here/
- State of AI-assisted Software Development 2025 (throughput and instability) — DORA / Google Cloud — https://dora.dev/dora-report-2025/
- Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence — Stanford Digital Economy Lab — https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recent-employment-effects-of-artificial-intelligence/
- No Widespread Displacement, but the AI Employment Gap for Young Workers Has Widened to 19% (data through June 2026) — Stanford Digital Economy Lab — https://digitaleconomy.stanford.edu/news/canariesaug26/
- Software Developers, Quality Assurance Analysts, and Testers (2025–2035 projections, median pay) — U.S. Bureau of Labor Statistics, Occupational Outlook Handbook — https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm
- Recap: Spec-driven development with Kiro (DEV314) — AWS Builder Center — https://builder.aws.com/content/393ZE7220eIhhxyCeBYythp5Qnm/recap-spec-driven-development-with-kiro-dev314
- UTBoost: Rigorous Evaluation of Coding Agents on SWE-Bench (345 mislabelled patches) — arXiv — https://arxiv.org/abs/2506.09289
- Best vibe coding tools in 2026 (the two tool families and their limits) — Appwrite — https://appwrite.io/blog/post/comparing-vibe-coding-tools
Sources 1–6 and 8 were read directly and every figure quoted above traces to them. The Stack Overflow survey ran from 29 May to 23 June 2025 with 49,009 responses from 166 countries. The Stanford figures come from ADP payroll records covering November 2022 to June 2026, not from a survey.
Two things I want to be careful about. The 84% and 80% figures answer different questions — "use or plan to use" against "currently use" — so I have kept them apart rather than blending them into one number. And the trust breakdown in source 1 is reported differently from the summary in source 2; I have quoted source 1's own categories rather than mixing the two.
Figures are current as of September 2026. The BLS projection is a projection, not a measurement, and it was made before anyone knew how 2026 would go. The Stanford gap has widened at every update so far, so treat 19% as a floor rather than a settled number.
Frequently asked questions#
Will AI replace software engineers?
Not on the evidence available today. The US Bureau of Labor Statistics projects software developer employment to grow 10% from 2025 to 2035, with about 106,100 openings a year, and Stanford's most recent study of actual payroll records is titled “No Widespread Displacement.” What is changing is the shape of the work: the typing shrank and the deciding grew. The real damage is concentrated at the entry level, where employment for 22–25 year olds in AI-exposed jobs sits about 19% below trend.
Is it still worth learning to code in 2026?
Yes, but learn a slightly different skill. The valuable thing is no longer producing code quickly; it is reading code and judging whether it is right. Practise on code you did not write. Build whole, real, finished things rather than tidy exercises, because only real projects contain the awkward parts that teach you anything.
What is spec-driven development?
Writing down what you want before any code exists. Kiro, the AWS agentic IDE, makes this the default: it produces a requirements document, then a design, then an ordered task list, and asks you to approve each one before it writes code. The reason it works is that an AI agent is extremely fast at building the wrong thing, so ten minutes of writing down what you actually want can save an afternoon of building something you did not.
Claude Code or Kiro — which should I use?
I use Claude Code for the engineering itself, because it holds a large existing codebase in context and works across many files in the terminal alongside git and the tests. Kiro's strength is the spec discipline: it forces the plan out of your head and onto the page before building. You do not need Kiro to get that benefit — you can write the spec first in any tool, which is what I now do.
How are Claude Code and Cursor different from Lovable, Bolt or Replit?
They are two different families of tool. Lovable, Bolt, v0 and Replit Agent start from nothing and give you a working app fast with no setup, which is genuinely valuable, but they thin out once your requirements leave the standard templates. Claude Code, Cursor and Kiro are built to change code that already exists, with its history and tests, and they assume you can read code. A common path is to prototype in the first family and rebuild in the second once the idea is proven.
Does AI actually make developers faster?
It makes them ship more, and it also makes what they ship break more often. Google's 2025 DORA report found AI raises throughput and instability together, and concluded that AI amplifies whatever a team already was rather than fixing it. Separately, 66% of developers in the 2025 Stack Overflow survey said they now spend more time fixing AI code that is almost right, and 45% named that their biggest frustration.