I came to software the long way around. I trained as a lawyer, practiced, and then reconverted into a low-code software engineer. That detour matters here, because it gave me an outsider's eye on a profession that insiders are sometimes too close to read clearly. And from that vantage point, the shape of what's coming looks obvious to me in a way it doesn't always look obvious from the inside.
Here's the claim, stated plainly so there's no mistaking it: AI will end programming as a craft, but it will never end the work of the business analyst, the product analyst, or QA. Within about five years, that will be the universal reality of the software industry. Maybe a little sooner. Maybe a little later. But it's coming, and it's coming for a reason that has nothing to do with how good the models get.
What AI Is Actually Ending
There's a sloppy version of this conversation that says "AI is replacing developers," and it gets the object of the sentence wrong. AI is not replacing software. Software is exploding — there has never been more of it, and there's about to be far more. What AI is replacing is a single activity inside the developer's day: the act of translating an intention into syntax.
That act — sitting down and typing the implementation, line by line — used to be the entire job in most people's minds. It was the bottleneck, the skill you got hired for, the thing that took years to get good at. And it is exactly the part that a model now does in seconds. I watch it happen every day. I describe what I want, the agent writes it, and the hours that used to disappear into boilerplate, syntax, and "why won't this compile" simply don't disappear anymore.
Writing code was never the point. It was the toll you paid to get to the point. AI is now paying that toll for you — which means the toll booth was never where the value lived.
So if the typing is leaving, what stays? Two things. And they happen to be the two things that bracket the act of writing code on either side: deciding what to build, and confirming that what got built is actually right. The first is the business and product analyst. The second is QA. Everything in between is becoming a machine operation.
The Two Jobs AI Structurally Can't Finish
Let me define them in one line each, because the whole argument rests on these two roles being understood correctly.
- The business / product analyst decides what is worth building, translates a fuzzy human need into precise requirements, and owns the question "are we even building the right thing?"
- QA (quality assurance) confirms that what was built actually works, behaves safely under real conditions, and matches what was asked for — and owns the question "can we stand behind this and ship it?"
Notice what these have in common. Neither is defined by output. A model can generate a requirements document and a model can generate a test suite — and it should, because that's faster. But generating the artifact is not the job. The job is the judgment wrapped around the artifact: choosing what matters, deciding the requirement is correct, declaring that the result passes. That judgment carries accountability, and accountability is the one thing you cannot hand to a model.
Why Requirements and Verification Stay Human
This is the heart of it, so I want to be precise. The reason these roles survive isn't that AI is too weak to do them. It's that they are not really "tasks" at all — they are points of responsibility.
When a model proposes a requirement, someone has to decide whether that requirement reflects what the business and its users actually need. The model has no stake in the outcome. It doesn't get the call when the feature ships wrong. It doesn't sit across from a customer who's furious that the product solved the wrong problem. A human does. And because a human bears the consequence, a human has to make — and own — the decision. The requirement still flows through a person on purpose.
Verification is the same shape. A model can write a thousand tests and report that they pass. But "the tests pass" is not the same statement as "this is safe to ship." Somebody has to look at the green checkmarks and decide they mean what they appear to mean — that the right things were tested, that the edge cases that matter were covered, that nothing important is quietly broken. That decision is QA, and it stays human because trusting it blindly is precisely the failure mode that QA exists to prevent.
AI removes the labor from both roles and leaves the responsibility untouched. The labor was never what we were paying for.
I learned this lesson in a different field. As a lawyer, you don't get paid for writing the contract — templates have existed forever. You get paid for knowing which clause matters, what the client actually needs, and for putting your name on the judgment that it's right. Software is converging on exactly that structure. The developer becomes the person who specifies and verifies, and signs their name to both.
Why Five Years, Give or Take
I'm putting a number on it because vague predictions are useless, but I want to be honest about the error bars. Five years is my best estimate for when "developers are mostly analysts and QA" stops being a hot take and becomes the unremarkable default. It could be three. It could be seven.
What makes me confident about the direction, even if I'm fuzzy on the date, is the trajectory I can already feel in my own work. A year ago, AI helped me write code. Now it writes most of it and I spend my time deciding what to ask for and checking what comes back. I've already crossed the line this prediction is about — I just expect the rest of the industry to cross it on roughly that timeline. I wrote about living inside this shift day to day in my piece on building side projects with an AI squad, and the gap between "I had an idea" and "it's running in production" keeps collapsing.
If you want the practical, hands-on version of how this actually works at the keyboard, I broke down the full workflow in my complete guide to vibe coding with Claude Code in VS Code. The short version: the human stays in charge of intent and verification, and the machine handles the middle.
This Was Never Just About Software
Here's where I'll go further than most people are comfortable going. This premise — machines do the execution, humans validate the requirements and supervise the outcome — is not a software story. It's a work story. Software just gets there first, because IT is the most relentlessly iterative sector we have. Every other industry is downstream of the same wave; it just arrives a few years later as the technology matures.
Take policing. The day is coming when an officer doesn't patrol the streets on foot — robots do. Physical AI, embodied in machines, will handle the patrol itself. So what does the human officer do? Exactly what the developer does. They supervise that the system is working, they analyze where more security is genuinely needed, they decide how to deploy the resources, and they own the consequences when something goes wrong. The patrol is automated; the judgment about where and why to patrol is not. I sketched out where this embodied-AI curve is heading in my look at physical AI and humanoid robots in 2026.
Take cleaning. The robot will do the cleaning — the actual scrubbing, mopping, hauling. The human's job shifts upward: planning where cleaning is needed, improving the process, raising the throughput, catching what the machine missed. The same structure, one rung up the ladder. Execution goes to the machine. Requirements and verification stay with the person.
Once you see the pattern, you see it everywhere. The job that survives automation is almost never the doing — it's the deciding what to do and the checking that it was done right. Business analyst and QA, dressed in the clothes of a hundred different professions.
The Three-Body Lesson: Leverage or Get Left Behind
There's a line of thinking in Liu Cixin's Three-Body Problem series that I keep coming back to: a civilization's fate is bound to whether it can leverage its technological breakthroughs to compound its own capability. The species that uses each advance as a platform for the next pulls away. The one that stands still gets buried by the curve.
Human productivity is on exactly that kind of curve — and it's not linear, it's exponential. Each layer of technology becomes the floor the next one builds on. The printing press, electricity, the computer, the network, and now AI: each one didn't just add output, it multiplied what a single person could do. We are standing on the steep part of that curve right now, and AI is the steepest step yet.
The opportunity isn't to resist the machine doing your old work. It's to climb onto the machine's shoulders and do work that was impossible from the ground.
That's the optimistic reading of all this, and it's the one I genuinely believe. The developer who clings to "but I write the code myself" is standing still on an exponential curve. The developer who says "the machine writes the code, and I'll be the one who decides what's worth writing and proves it works" is leveraging the breakthrough. One of those positions compounds. The other gets buried.
What This Means for Your Career, Concretely
If you're a developer reading this and feeling the floor move, here's the actionable part. Stop investing your identity in the skill that's being automated, and start investing it in the skills that are becoming the whole job:
- Requirement clarity. The ability to take a vague, contradictory, half-formed human need and turn it into a precise specification. This is the business analyst muscle, and it's now central, not peripheral.
- Product judgment. Knowing what's worth building and what isn't. Saying no. Spotting the feature that solves the wrong problem before a single line is written.
- Acceptance criteria and verification. Defining what "done and correct" actually means, and having the discipline to check it rather than assume it. This is QA, and it's the skill that separates "the AI said it works" from "I confirmed it works."
- Critical review of generated output. Reading AI-produced code and specs the way a senior reviewer reads a junior's PR — looking for what's subtly wrong, not just what's obviously broken.
- Security and consequence awareness. Understanding what happens when this ships and something goes wrong, because that's the accountability the machine will never carry for you.
None of these are new skills, exactly. Good engineers have always had them. What's changing is that they're moving from the edges of the job to the center of it. The typing was the middle of the job, and the middle is being hollowed out and filled with a machine. What's left is the two ends — and the two ends were always the parts that mattered.
The Bottom Line
I switched careers from law to engineering, and the irony isn't lost on me that the engineering job is converging toward something a lawyer would recognize: specify precisely, verify rigorously, and put your name on the judgment. The implementation is becoming a commodity. The responsibility is not, and it never will be.
So when people ask me whether AI is going to take the developer's job, I tell them the truth as I see it: it's going to take the part of the job you didn't actually love, and leave you with the part that was always the point. Within five years, every software developer will be a business analyst and a QA. And not long after that, so will almost everyone else. The only real question is whether you climb onto the curve, or let it pass you by.