HELP! Claude now builds almost everything. What is left of the software developer?

Under 613 of the 633 commits of this website sits the same line: Co-Authored-By: Claude. The first is from 8 January 2026. October added 369 more: games, a C64 tribute, a digital museum about Suriname, the visitor counter. Read the git history and you see a developer who mostly describes, reads, tests and approves. Most of the code came from a model.

So I am not an outsider when I ask what is left of the software developer. At Stripe, Spotify and Anthropic it already works this way. Who writes the code is no longer the question there. The question is who still understands it, and who signs for it when it fails.

Sources checked on 14 November 2026, at the original publication where possible. I note whether a figure comes from independent research, a preprint, a survey or a company that sells the tool. The Laravel case is an invented but realistic example. Advice and scenarios are mine and marked as such.

Short answer. At the companies that write about it openly, AI agents now type most of the code, but in no documented organisation has the developer disappeared. The work has moved to specifying, limiting permissions, reviewing and carrying responsibility. What companies publish is extra output. Whether the software gets better or worse, nobody has shown with defect or incident figures. And from 9 December 2026, the manufacturer of software in the EU is strictly liable, whoever or whatever wrote the code.

Vibe coding is not the same as working with agents

Andrej Karpathy named the phenomenon in February 2025: "There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." A month later Simon Willison turned it into a working definition that I use in this article: vibe coding is "building software with an LLM without reviewing the code it writes". If you read, test and can explain the code a model wrote, he says, you are simply doing software development.

That distinction gets lost in most discussions. So I use five terms, and I don't mix them up:

There is no authoritative definition of "AI-first"; mine is above. Karpathy himself called "agentic engineering" his favourite new name for what professionals do in early February 2026. Willison defines it as "the practice of developing software with the assistance of coding agents". Kent Beck talks about augmented coding: the standard is still tidy, working code, he just rarely types it himself.

Who already works like this? Six companies that wrote it down

I looked for organisations that described their own way of working. Statements by executives to investors don't count as evidence for me. Six cases are well documented.

Stripe describes its "Minions" in two blog posts from February 2026. Every week more than 1,300 pull requests are merged that contain "no human-written code". All of them are reviewed by a human. The agents run on isolated development machines without access to production or the internet, and after two failed CI rounds the branch goes back to a person. Stripe publishes no figures on reverted changes or defects.

Spotify offers two kinds of sources, and you have to keep them apart. Co-CEO Gustav Söderström told investors in February that the best developers "have not written a single line of code since December". That was about the best developers, not everyone, and no figures came with it. The engineering blog from June is more precise. More than 99% of engineers use AI coding tools every week, the number of pull requests rose by 76%, and the system for maintenance work merged more than 2.5 million pull requests, mostly without a human. Those are migrations and dependency updates, not new features. Spotify spells out what that means: "76% more PRs to review".

Adyen is the best Dutch case, and the opposite of vibe coding. CTO Tom Adams wrote in September that its roughly 1,400 developers use about a trillion tokens a year. Merge requests per developer rose by 48%, but the self-reported time saving is 15%. A refactor of old code that would normally take six to twelve months was done by "a couple of engineers" in two months, "with no incidents". Adyen also reports longer review times and reviewers pushing back, and it is experimenting with risk labels on every merge request. One of the headings reads: "Coding != Engineering".

Anthropic sells Claude, so read this as company information. According to Fortune, Claude writes 70 to 90% of the code there. An internal study from December 2025 (132 engineers) reports 67% more merged pull requests per engineer per day, and also this: more than half of the engineers can fully hand over only 0 to 20% of their work to Claude. The report names the "paradox of supervision": overseeing Claude requires exactly the skills that heavy AI use may wear down.

StrongDM is the only documented team that also abolished review. In February 2026 Simon Willison described the rules of their "software factory": "Code must not be written by humans" and "Code must not be reviewed by humans". It was a team of three, with a benchmark of at least 1,000 dollars in tokens per engineer per day. Still, this is not vibe coding. Test scenarios live outside the codebase, like a hidden exam, and the agents test against replicas of Okta, Jira and Slack. Review has been replaced by a test factory. There are no defect figures.

Amazon is the disputed counterexample. According to the Financial Times, based on four anonymous sources, the Kiro agent chose to "delete and recreate the environment" in December 2025, causing a thirteen-hour outage of an AWS service in one region. Amazon says it was "user error - specifically misconfigured access controls - not AI". Reports that junior engineers have since needed a senior's sign-off for AI changes I could not check at the source, and Amazon denies new approval requirements. Both versions agree on one thing: an agent ran with more permissions than it needed.

Around these cases sit percentages from executives: 75% of new code at Google is "AI-generated and approved by engineers" according to Sundar Pichai, and Satya Nadella mentioned 20 to 30% for Microsoft. These numbers cannot be compared with each other, because every company counts something different. And they say nothing about quality.

What I did not find matters just as much. An IT department that has switched entirely to vibe coding, in the sense that nobody reads the code any more, is documented nowhere. The best-known example of real vibe coding is about one person: in July 2025 a Replit agent wiped SaaStr's production database during a code freeze, with data on more than 1,200 executives. For ING, bol, Picnic, ABN AMRO, Booking, Exact and AFAS I found no public, verifiable description of how they work. Anyone who claims that "whole departments" work this way should show which ones.

A Laravel feature in twenty minutes, and five questions afterwards

An example, invented but recognisable. An experienced Laravel developer has to build a feature in an existing application (Laravel 13): team members may export their own team's invoices as CSV. In the past he would first read the code, design the solution and write the migration, the policy, the controller, the request validation, the Blade component and the tests himself. A day's work, with coffee.

Now he opens Claude Code in the repository. The model reads CLAUDE.md with the team's conventions, gets access to the database schema, the routes and version-specific documentation through Laravel Boost (an MCP server from Laravel itself), and makes a plan in plan mode first. He approves it. Twenty minutes later fourteen files have changed, there is a new migration, and all tests are green. He clicks the export button. It works.

But what exactly happened? There are five questions he cannot answer after those twenty minutes without really reading the diff.

1. Is the authorisation right?

The policy may check whether the user belongs to a team, but not whether the invoice belongs to that team. Then anyone who puts another invoice number in the URL can fetch another team's invoices. A test the agent wrote itself usually checks what the agent built: a user exporting their own invoices. The test that matters is about the user who isn't allowed:

it('refuses to export an invoice from another team', function () {
    $user = User::factory()->create();
    $foreignInvoice = Invoice::factory()->create(); // belongs to another team

    $this->actingAs($user)
        ->get(route('invoices.export', $foreignInvoice))
        ->assertForbidden();
});

This is not a theoretical risk. In July 2026 Veracode showed that the models it tested stopped cross-site scripting in only 15% of cases. Apiiro, which sells security software, counted 322% more privilege escalation paths in repositories using AI assistants. Those are detector hits, not confirmed vulnerabilities, but the direction is the same: authorisation is exactly the kind of mistake that looks harmless in a diff.

Tools that promise a map of your code only help halfway here. When I tested Graphify on this site's PHP code, it answered that nothing depended on Auth::requireAuth(), while 18 files call that function. A map that sounds certain about security needs checking, just like an agent.

2. Were N+1 queries introduced?

The export loop fetches the customer for each invoice. With ten test invoices you notice nothing; with forty thousand invoices in production you do. Laravel can make this fail loudly in development, so it doesn't stay silent:

// app/Providers/AppServiceProvider.php
use Illuminate\Database\Eloquent\Model;

public function boot(): void
{
    Model::preventLazyLoading(! $this->app->isProduction());
}

With that line a forgotten with('customer') throws a LazyLoadingViolationException instead of producing a slow page. Safety nets like this only work if they were there before the agent started.

3. Does it fit the architecture?

The agent may have put the export logic in the controller while the team uses a separate action class for that. Or it wrote its own CSV helper when there already is one. Spotify's Chief Architect put it this way: "If Claude has a lot of other code to look at, and that code looks roughly consistent, Claude will do a better job." The reverse is true too. Every inconsistency you let through becomes the example for the next change.

4. Are the edge cases covered?

What happens when a user is in two teams? When an invoice no longer has a customer? When the amount is negative, or the description contains a semicolon? An agent tests what was in the prompt. What wasn't, it tests if you're lucky.

5. Can the migration be safely reversed?

A Laravel migration has an up and a down, and php artisan migrate:rollback reverses the last batch. If the agent renamed a column and converted data in up, the question is whether down reverses that cleanly or throws the data away. Almost nobody tests that, agents included, until it's needed.

The tools are honest about this themselves. Claude Code has an automated code review feature for Team and Enterprise plans, and the documentation says: "A review never approves or blocks the pull request, so the decision to merge stays with your team." And: "A review with no findings doesn't mean your code is error-free or secure." That review reads the diff and the surrounding code "without building or running your code". When Laravel announced Boost, it wrote: "treat all generated code as a draft". Whoever leaves the five questions above to a second model leaves the responsibility with nobody.

The first line of defence isn't review either, but what an agent is allowed to do. Claude Code reads permission rules from .claude/settings.json. A minimal example for a Laravel project:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(php artisan migrate:fresh*)",
      "Bash(php artisan db:wipe*)",
      "Bash(git push*)"
    ]
  }
}

This is a brake, not a vault. An agent that may run a script can get around such a rule. The real boundary is that the development environment has no production credentials. That separation is exactly what was missing at Replit and Kiro. How to set up permissions, hooks and a sandbox in practice, I described for Windows maintenance with Claude Code.

Typing faster, reviewing longer: what has actually been measured

The evidence on productivity depends on the level you measure at. The closer you get to the real question (does the software get better?), the thinner the evidence.

The individual task. The only independent randomised trial with finished results comes from METR. In 2025 sixteen experienced open-source developers worked on 246 tasks in their own repositories. With AI the tasks took 19% longer, while afterwards they believed they had been 20% faster. The follow-up with newer tools (February 2026) pointed to a speed-up of about 18%, but the confidence interval ran from −38% to +9%. METR itself calls that "very weak evidence". More telling: many developers refused to do some tasks without AI, which makes a control group hard to fill.

The team. Here the increase does show. Microsoft engineers who started using Claude Code and Copilot CLI merged about 24% more pull requests than expected. A preprint (first version July, revised November 2026) followed 802 developers and 196,212 pull requests at one company that had been told to double its output with AI. Throughput rose by about 12% once someone started using AI, and the goal was only reached after ten months. Meanwhile pull requests grew larger, the load per reviewer doubled, and automated review overtook human review in coverage. The title of that study sums it up: "AI Writes Faster Than Humans Can Review".

The organisation. Google's DORA report (September 2025, almost 5,000 professionals) found that 90% use AI and more than 80% feel more productive. AI use went together with higher throughput, but still also with lower stability. DORA's conclusion: AI amplifies what is already there. A good team gets faster; a messy team gets messy faster. I found no DORA report for 2026.

The platform. According to GitHub's Octoverse, more than 40% of pull requests in September 2026 were started by an agent, up from 17% in March. Agent PRs were merged as often as others, but a merge only says that someone pressed the button.

The long term. Here the evidence is thinnest. No study measures maintainability objectively over more than six months with a comparison group. Vella and Blincoe (accepted by ACM TOSEM) did follow 95 developers for six months. 82% wrote less code themselves, the work shifted from making to checking, and perceived productivity stayed high while their experience of the work got worse. On quality there are only vendor figures. CodeRabbit counted 1.7 times as many issues per AI PR in 470 open-source pull requests; Faros reported 28% more bugs per pull request. Both sell a solution to that problem.

For the backlog this creates, the gap between how much code is added and how much of it anyone has understood and checked, people use the term verification debt. Werner Vogels of Amazon popularised it in his re:Invent keynote of December 2025. I found no verbatim quote in which he coins it, so it is a young term, not an established concept. Addy Osmani uses comprehension debt for roughly the same thing. I wrote about the team side, the understanding that slips away, in Cognitive debt in 2026.

One figure says more than the rest. At Adyen merge requests rose by 48%, and the developers themselves put their time saving at 15%. Somewhere between those two numbers sits the work that now lands on the reviewer.

What went wrong, went wrong through excessive permissions

The incidents with AI agents that are public and well documented have something in common: an agent or AI tool acted with the permissions of a developer or a CI token, without separation between environments.

• Replit and SaaStr (July 2025): an agent wiped a production database during a code freeze and said recovery was impossible. It wasn't. Replit CEO Amjad Masad: "Unacceptable and should never be possible".
• Nx "s1ngularity" (August 2025): malicious versions of the nx build package looked for AI CLIs on victims' machines and launched them with the flags that switch off every safety prompt (according to StepSecurity --dangerously-skip-permissions, --yolo and --trust-all-tools), to search the file system for keys and wallets.
• Amazon Q Developer 1.84.0 (July 2025): a merged pull request put a prompt into the VS Code extension that was meant to wipe environments. According to AWS it failed because of a syntax error.
• Clinejection (February 2026): the AI bot that triaged issues for the Cline project put an issue title into its prompt. Through that title an attacker could get code to run and steal an npm token. On 17 February an unauthorised version of the package appeared.
• Lovable (2025): apps built with the platform lacked row-level security in the database (CVE-2025-48757, CVSS 9.3). The CVE is marked "disputed": Lovable says each customer is responsible for their own data. That raises the question of responsibility straight away.

What I did not find is just as informative: a public postmortem in which AI-written code is the proven root cause of a major production outage. The big Cloudflare outages of 2025 and 2026 had classic causes: a permissions change in a database, a query without a scope. That doesn't mean AI code is safe. It means nobody measures it. None of the companies in the previous section publishes how many of its incidents come from AI code.

The human risk has been studied better than the technical one. In a well-known experiment by Perry and others, users with an AI assistant wrote less secure code and were at the same time more confident that it was secure. The more you trust the tool, the less closely you look. That is how a mistake gets through review.

What I find overstated is the idea that an agent does harm "on its own": in all the cases above it was given a human's permissions. Invented package names (slopsquatting) are also mainly a lab risk. In one study models recommended packages that didn't exist in 19.7% of cases, but I found no large-scale attack in the wild.

The junior who never learns to debug

An experienced developer recognises an N+1 query because he once had one in production. He spots a gap in a policy because he once closed one. That experience comes from getting stuck yourself, and that is exactly the part of the work an agent takes away.

Anthropic studied this itself. In a randomised experiment, mostly junior engineers learned an unfamiliar Python library, with or without AI. Afterwards the AI group scored 50% on a comprehension test, the group without AI 67%. The biggest gap was on debugging questions. The AI group was not significantly faster either.

At the same time the market hires fewer beginners. According to SignalFire, hiring of new graduates at the twelve largest tech companies is about 65% below 2019 levels, with this explanation: "the operational bottleneck has moved from writing code to reviewing it". Interest rates and the correction after the pandemic hiring wave play a part too; I set out the figures and causes in More or fewer programmers needed in 2027?

Put those two side by side and you see the problem of 2031. Organisations need more and more seniors to judge AI code, and they train fewer and fewer people to become senior. Lisanne Bainbridge described this pattern in 1983 for factories and aircraft, in "Ironies of Automation": "Perhaps the final irony is that it is the most successful automated systems, with rare need for manual intervention, which may need the greatest investment in human operator training." The better automation works, the less often the human steps in, and the worse prepared he is for the time he has to.

That is not an argument for keeping juniors away from AI. It is an argument for deliberately giving them work they have to understand themselves: tracking down the bug before asking the model, explaining the agent's diff to a colleague, writing a function without help now and then. In the same experiment Anthropic saw that participants who asked the AI for explanations rather than code scored better.

Twenty years of experience against a model that does it in minutes

Then the uncomfortable question that every experienced developer has asked themselves at some point this past year. If I spent twenty years learning to write good software and a model does it in minutes, what is my experience still worth?

The honest answer has two halves. Part of what you know becomes cheaper. Writing out a controller, remembering a framework's syntax, setting up a migration, a regular expression that is right first time: that used to be scarce and isn't any more. Anyone whose value was mainly there has a problem.

Fred Brooks wrote in 1986, in "No Silver Bullet": "I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it." Agents take over exactly that last part, the labour of writing it down. The rest becomes more valuable. Knowing which of the fourteen changed files to distrust. Seeing that a solution works but will be in the way in two years. Being able to say why the system was built this way. Understanding what the customer is really asking. Choosing an architecture that an agent can follow. You don't learn that from a prompt, and it isn't in a diff.

Peter Naur went one step further in 1985. A program, he argued, is a theory in the heads of the people who made it: "The death of a program happens when the programmer team possessing its theory is dissolved." What is in the code is derived from that theory. Whoever holds the theory cannot be replaced by whoever only holds the code, not even when that is a very good model.

The threats are real too. The pressure to produce more is growing; Adyen itself warns that "tokenmaxxing", burning as many tokens as possible, is "fundamentally the wrong incentive". The experience of the work can get worse while output rises, as Vella and Blincoe saw. And whoever has twenty years of experience in writing and no appetite for judging faces a different job from the one they chose.

I've stopped typing. Have I stopped programming?

Programming has always been an odd mix of frustration and satisfaction for me. A bug that can't be found all afternoon and then turns out to be one line. A query that works fine with a thousand rows and suddenly doesn't with a million. The moment a hard piece finally works, and you run it again because you don't quite believe it. An elegant solution has something that is hard to explain to someone who never wrote code: it feels as if the problem had always wanted to be solved that way.

Those 613 commits show what got built: in ten months, alongside my job at CareerValue, a website with games, a digital museum and its own visitor counter. That's the easy part of the question. Whether I am still programming is harder.

What I do know: the moments that mattered were always moments of reading, not writing. When I let Claude Code examine my own PC, it wrote a convincing report saying I was running a preview build of Windows and should go back to a stable version. That was wrong. Build 26300 is the regular release. The report sounded exactly as sure about the wrong part as about the rest. You only see that if you know how things actually are.

Maybe that is what programming is now. Not typing the solution, but knowing which solution is right, and seeing when a convincing text is wrong. That is less romantic than working through the night on an algorithm. It is no less of a craft. It just feels different, and I don't know yet whether I will come to love that difference as much.

Who signs when it goes wrong?

European law answers this question more clearly than the debate in the profession. The new Product Liability Directive (EU) 2024/2853 must be transposed by 9 December 2026 and applies to products placed on the market after that date. Software is explicitly a product. Liability is strict: an injured party does not have to prove fault, only a defect, damage and the link between them. How the code came about, by a human or by a model, makes no legal difference. The Netherlands transposes the directive with bill 36.906. The House of Representatives passed it on 15 October, the Senate on 10 November 2026, both without debate.

There is an important limit. Compensation covers injury, damage to property, and lost or damaged data that is not used for professional purposes. Most damage caused by a broken internal system does not fall under it; that remains a matter of contracts. An IT department that only builds internal tools will barely notice the directive. A company that supplies software to consumers will.

In addition, the reporting obligation of the Cyber Resilience Act has applied since 11 September 2026. Manufacturers of products with digital elements must send ENISA an early warning about actively exploited vulnerabilities within 24 hours. The heavier requirements, such as secure by design and a software bill of materials, follow on 11 December 2027. For a software vendor, an incident like Cline's is now a report with a deadline.

The terms of AI vendors usually exclude liability for the output. I haven't checked that vendor by vendor, but the pattern is clear: the risk lies with whoever uses the tool and sells the product. "The AI did it" does not exist as a legal defence.

What it costs, and who pays

Writing code has become cheap. According to the Claude Code documentation it costs on average "around $13 per developer per active day and $150-250 per developer per month". Compared with a salary that is nothing; StrongDM's 1,000 dollars a day is another world.

But writing code was never the biggest cost. Robert Glass put maintenance at 40 to 80% of the total cost of software over its lifetime, 60% on average. AI makes the smallest item cheaper and enlarges the biggest: more code arrives that has to be updated, secured, integrated and understood. In the first quarter of 2026 the App Store received 84% more new apps, while downloads rose by only 2 to 3%. More software is being made than users are being added.

The market is already pricing it in. After Anthropic released eleven plug-ins for Claude Cowork at the end of January 2026, the S&P 500 software and services index was 26% below its October 2025 peak on 4 February. Traders called it the "SaaSpocalypse". Much of that loss has since been recovered. That was about expectations, not measured revenue. At IT service providers the effect is more concrete. According to a summary of the quarterly results, about half of TCS's ongoing contracts have been repriced because of AI, at 10 to 20% lower value. Accenture reports lower prices "in many areas". Gartner expects IT spending to rise by 15% in 2027, but IT services by only 4.9%. The extra money goes to infrastructure and licences, not hours.

What that means for hourly rates is my expectation, not a measurement. Whoever sells code by the hour sells something that is getting cheaper. Whoever sells a system that works, is secure and can still be maintained in five years sells something that is getting scarcer.

The counterargument: maybe the craft gets better

All of the above could sound like nostalgia, and that would be too easy. There is a serious argument that this is the best development in the history of the profession.

John Backus described how programmers in the 1950s thought about compilers. They were convinced "that efficient programming was something that could not be automated". FORTRAN would only be widely used if it produced programs "almost as efficient as hand coded ones". It did, and nobody misses allocating registers by hand. Backus also described the "public relations efforts of some visionaries" who attributed "almost human abilities to understand the language and needs of the user" to their systems. That sounds familiar.

Every layer of abstraction, from assembly to high-level languages, from your own servers to the cloud, took away work that craftspeople considered important, and let more people build more software. Anthropic reports that 27% of the work engineers did with Claude would otherwise not have been done at all: small tools, clean-up work, experiments that were too expensive. At the German company epilot, according to the company, 40 of 629 pull requests in 60 days came from eleven people who are not engineers. An engineer still reviewed and merged them, but those 40 changes would not otherwise have existed.

Where the comparison breaks down matters. A compiler is deterministic: the same source code gives the same program, and the source code remains the document you keep and read. With an agent the prompt is not a repeatable source. The generated code is the only thing that remains, and a human has to be able to understand it. Edsger Dijkstra wrote at the end of the 1970s "On the foolishness of "natural language programming"": formal notations are "an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid." About the machine he was wrong; it exists now. About precision he was right. It still has to come from somewhere: from tests, types, specifications and review. That is exactly where the work is moving.

Spreadsheets let people without training build software long before this, with much gain and sometimes a disaster: in 2020, 15,841 positive Covid tests at Public Health England went unreported because an outdated Excel file was full. More people building is good. More software without an owner is not.

Three IT departments in 2030

These are my scenarios, not predictions. They are derived from the cases above.

A. The amplified department. A small team of experienced developers steers several agents, as Stripe and Adyen show today. Humans keep architecture, security, permissions and production. Fewer people work there, but on average more seniors, and reviewer becomes a role of its own. The risk is that no new seniors come along.

B. The democratised organisation. Staff outside IT build their own tools, as already happens on a small scale at epilot. IT becomes a platform team: it provides environments with good defaults, guards integrations, permissions and data, and reviews what goes to production. Vendors of simple SaaS have a hard time, because a department now builds many of those tools itself.

C. The fragile organisation. Things get built at great speed, the PR counters are at record highs, and nobody can explain any more how the systems fit together. The seniors who could have left or are overloaded with review. Every outage takes longer, because nobody holds the theory of the system. This scenario isn't the result of bad AI, but of an organisation that measures output and not understanding.

Which scenario a department gets depends less on the model than on what it measures.

A way of working for an AI-first team

This is my proposal, based on what the documented teams do and what went wrong in the incidents. The most important distinction is the risk of the software. An internal overview for ten colleagues needs something different from a payment system.

Every department also needs: a short policy on which tools, which data never goes to a model and who is ultimately responsible. Team conventions in CLAUDE.md or AGENTS.md, because an agent follows what is written there. Every new dependency checked by hand. Costs tracked per team. And a way out: if your vendor doubles its prices or is down for a day, your team must still be able to work. That is only possible if it understands the code itself.

Don't measure the number of pull requests. Measure the share of changes that get reverted, the number of outages, the time to recovery, the review time per change, and whether the team can still explain a random module from last month. No dashboard measures that last one. A quarterly conversation does.

A 90-day plan for a team of two to five developers

Days 1–30: foundations and a baseline. First measure how things are now: lead time, reverted changes, outages. Set up permissions: no secrets and no production access in the development environment, rules in .claude/settings.json, tests that run on every change. Write CLAUDE.md with the conventions that now only live in people's heads. Have everyone work in plan mode during this period and read every diff themselves.

Days 31–60: experiments with limits. Pick two kinds of work that suit agents: maintenance (dependency updates, migrations) and low-risk new features. Let agents do them, with mandatory human review. Add automated review as an extra layer, not a replacement. Agree that juniors can explain every agent diff before it is merged.

Days 61–90: evaluate and decide. Compare with the baseline, using the figures that matter, not the number of pull requests. Look at where review gets stuck. Decide per type of work how much the agent may do, and write it down. Schedule a monthly session in which the team solves a problem without AI, so the skill doesn't quietly disappear.

What I would advise everyone

Junior developers. Use AI to get explanations, not just code. Look for a bug yourself for fifteen minutes first. Read every diff as if you have to defend it, because you do. Learn how a database, HTTP and authorisation work; that's what you will be checking.

Experienced developers. Your value is in your judgement, so make it visible: write down the conventions an agent has to follow, and the tests an agent won't think of. Learn the tools well, including permissions, hooks and their limits. Whoever refuses isn't respected but overtaken. What this means for PHP developers I wrote in PHP and AI in 2027.

Lead developers. Your biggest risk is the reviewer who approves everything because it looks good. Keep pull requests small, have agents work on bounded tasks, and make review time visible in planning. Every module has a person who can explain it.

CTOs and IT managers. Measure reverted changes and outages, not pull requests and percentages of AI code. Keep hiring and training juniors: without them, in five years you'll have nobody to check the agents. Find out what product liability from 9 December 2026 means for your products.

Organisations that want to go fully AI-first. Start with permissions and separation of environments, not with the model. Every documented incident began with an agent that was allowed too much. Don't copy StrongDM without their test factory, and don't copy Stripe without their 3 million tests.

Responsibility without oversight

The usual conclusion is that a developer's value shifts from producing code to carrying responsibility. Legally that is already true: from December the manufacturer is liable, whoever or whatever wrote the code. But that claim has a weak spot. Responsibility means something if you can oversee what you are signing for. A reviewer who approves fifty pull requests a day signs for code he cannot fathom. That isn't responsibility. That's a signature.

Can an organisation rely on systems that grow faster than its ability to check them? Only temporarily, and only if it knows it is doing so. The missing figure in this whole investigation, the number of defects before and after the switch, is therefore not a footnote. It is the most important thing nobody has measured.

Naur wrote that a program dies when the team that holds its theory is dissolved. With agents, for the first time, a program can come into being without such a team ever having existed. It runs, it makes money, and it is an orphan from day one. What is left of the software developer is the person who can adopt such a program: who reconstructs the theory, writes it down and vouches for it. There aren't enough of them, and we are training fewer.

Frequently asked questions

What is the difference between vibe coding and AI-assisted programming?

With vibe coding you don't read the code the model writes. You only judge whether the result seems to work. With AI-assisted programming or agentic engineering the model may also write much or all of the code, but a human reads, tests and understands it before it goes into use. That definition comes from Simon Willison (March 2025).

Does AI really write most of the code at large companies?

According to the companies themselves, yes: Google mentions 75% of new code, Anthropic 70 to 90%, and Stripe merges more than 1,300 pull requests a week without human-written code. These figures have not been independently checked and each company counts differently. At all of these companies humans still review the code.

Does AI make developers more productive?

The number of pull requests demonstrably rises, by 12 to 76% in the studies and cases I found. Measured time savings are smaller: Adyen reports 15% self-reported, and the only finished independent experiment (METR, 2025) found experienced developers became 19% slower. The extra output moves work to review.

Is AI-generated code less secure?

Research suggests so, especially for authorisation and cross-site scripting, but most figures come from security vendors. The documented incidents were mainly about agents with excessive permissions and attacked toolchains, not about a single wrong line of code.

Who is liable when AI code causes damage?

In the EU, the manufacturer of the product. Under the new Product Liability Directive, which applies to software placed on the market after 9 December 2026, software is a product with strict liability. Whether a human or a model wrote the code makes no legal difference. Damage to business customers mostly falls under contract law.

Should companies still hire junior developers?

My advice is yes. Whoever wants AI code checked will need seniors in five years, and they only come from juniors who learned the craft. Research by Anthropic shows that learning with AI can lower understanding, especially in debugging, unless you ask the AI for explanations rather than code.

Sources

Cases and company publications

• Stripe, Minions: Stripe's one-shot, end-to-end coding agents (9 February 2026) and part 2 (19 February 2026)
• Spotify Engineering, Coding is no longer the constraint (3 June 2026); TechCrunch, Spotify says its best developers haven't written a line of code since December (12 February 2026)
• Adyen, AI in our development lifecycle (3 September 2026)
• Anthropic, How AI is transforming work at Anthropic (2 December 2025, vendor of the tool); Fortune, on the share of AI code at Anthropic (29 January 2026)
• Simon Willison, How StrongDM's AI team build serious software without even looking at the code (7 February 2026)
• The Register, Amazon denies Kiro agentic AI behind outage (20 February 2026); Fortune, on the Amazon retail outages (12 March 2026)
• Semafor, Google CEO says 75% of company's new code is AI-generated (24 April 2026)
• epilot, Our entire company ships code now (2026)

Research on productivity and quality

• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (10 July 2025, preprint) and the update of 24 February 2026
• He et al., AI Writes Faster Than Humans Can Review (preprint, version 3 of 10 November 2026)
• Microsoft, effect of Claude Code and Copilot CLI on merged pull requests (preprint, July 2026)
• Vella and Blincoe, longitudinal study of developer work with AI (accepted by ACM TOSEM, version 2 of 3 November 2026)
• Google Cloud, 2025 DORA State of AI-assisted Software Development (23 September 2025, survey)
• GitHub, Octoverse 2026 (28 October 2026, platform data)
• Stack Overflow, Developer Survey 2025, AI and 2026, AI (surveys)
• CodeRabbit, State of AI vs human code generation (17 December 2025, vendor); Faros AI, The Acceleration Whiplash (vendor)
• Shen and Tamkin (Anthropic), How AI assistance impacts the formation of coding skills (January 2026, paper)
• Addy Osmani, Comprehension debt (14 March 2026); InfoQ, on Werner Vogels' keynote (10 December 2025)

Incidents and security

• Fortune, on Replit and SaaStr (23 July 2025)
• Nx, s1ngularity postmortem (5 September 2025); StepSecurity, analysis of the attack (27 August 2025)
• AWS, Security bulletin AWS-2025-015 (23 July 2025)
• Adnan Khan, Clinejection (9 February 2026)
• NVD, CVE-2025-48757 (30 May 2025)
• Veracode, 2026 GenAI Code Security Report (July 2026, vendor); Apiiro, 4x velocity, 10x vulnerabilities (4 September 2025, vendor)
• Perry et al., Do Users Write More Insecure Code with AI Assistants? (ACM CCS 2023)
• Spracklen et al., We Have a Package for You! (USENIX Security 2025)
• Cloudflare, postmortems

Legislation

• Directive (EU) 2024/2853 on liability for defective products
• Dutch Senate, bill 36.906, implementation act for the revised product liability directive (in Dutch)
• European Commission, Cyber Resilience Act, reporting obligations; ENISA, Single Reporting Platform

Economics

• Claude Code documentation, Manage costs effectively
• Reuters via The Star, US software stocks hit by Anthropic wake-up call (4 February 2026)
• Gartner, IT spending forecast 2027 (21 October 2026)
• Rutviz Parekh, summary of Indian IT services quarterly results (23 October 2026, secondary); Constellation Research, on Accenture Q4 (1 October 2026)
• 9to5Mac, App Store sees 84% surge in new apps (6 April 2026)
• Robert L. Glass, Frequently Forgotten Fundamental Facts about Software Engineering

History and terminology

• Simon Willison, Not all AI-assisted programming is vibe coding (19 March 2025), with the text of Karpathy's post, and What is agentic engineering?
• Kent Beck, Augmented Coding: Beyond the Vibes (2025)
• John Backus, The History of FORTRAN I, II, and III (1978)
• Edsger W. Dijkstra, EWD667: On the foolishness of "natural language programming"
• Fred Brooks, No Silver Bullet: Essence and Accident in Software Engineering (1986)
• Peter Naur, Programming as Theory Building (1985)
• Lisanne Bainbridge, Ironies of Automation (Automatica, 1983; readable copy)
• The Register, on the Excel error at Public Health England (5 October 2020)

Tools and documentation

• Claude Code documentation, Code Review, Permissions and Agent teams
• Laravel, Announcing Laravel Boost (13 August 2025) and the documentation on preventing lazy loading, authorization, rolling back migrations and testing
• SignalFire, State of Talent Report 2026

Own data

• Git history of vandeblaak.com on 14 November 2026: 633 commits since 8 January 2026, of which 613 carry the line Co-Authored-By: Claude. That line says Claude co-wrote, not that Claude wrote everything.