When Code Is Cheap, What Do You Ship?

The Number in the Layoff Memo

On 15 April 2026, Snap fired about a thousand people. Sixteen per cent of the company. Gone in a memo.

The memo did something unusual. It told the truth.

Most layoff notes hide behind weather words. Headwinds. Realignment. A challenging macro environment. Snap’s chief executive skipped all of that and named the cause out loud: AI agents now generate more than 65% of the company’s new code, and small squads using AI tools can do the work that used to need larger engineering teams (CNBC, 2026).

Then the part nobody could have scripted. The stock went up. Around eight per cent.

Read that sequence again. A company says machines now write most of its software, says it therefore needs far fewer humans, and the market rewards the confession. A sceptic will say the stock went up because Snap has been burning cash for years and the market simply applauded any sign of discipline. That reading is not wrong. But it misses what was actually being priced: not the headcount reduction, but the named cause attached to it. The layoff was not the bad news. The layoff was the proof of concept. (

Worth noting: the roles Snap actually cut were in product and partnerships, not engineering directly. Spiegel named engineering efficiency as the reason; the redundancies landed elsewhere. That gap between stated cause and actual cuts is precisely why the sceptics in this piece deserve a hearing.

The question the memo raises is the right one: if AI writes the code, what does the engineer write?

To answer it properly, it helps to look at what AI can actually do for an engineer right now, in 2026.

That is the entire story. Everything else in this piece is evidence for it, or implication from it.

The Deliverable Moves Up the Stack

The code was never the valuable part, not for most teams.

The code was the toll you paid to find out whether your judgement was right. Now the toll is cheap.

This is not the first time a craft's tooling got cheap. It happened to photography when digital arrived; to music production when software replaced the studio; to design when templates made layout trivial. Each time, the commodity layer collapsed and the layer above it (the judgement, the eye, the taste) became the thing that separated people who were genuinely good at it. Software is the latest version of that pattern.

For thirty years, the scarce and defining act of building software was the writing of it. The code was the work. You hired for it, you queued for it, you protected the people who could do it.

That bottleneck is dissolving. Google says 75% of its new code is now AI-generated and approved by engineers (Google/Fast Company, 2026); Microsoft puts its figure at 20 to 30% (Microsoft, 2025); Snap is past 65% (CNBC, 2026). Roughly three in four developers now reach for an AI tool as a matter of course (Stack Overflow Developer Survey, 2024). The act that used to be the job is becoming the cheap part of the job.

Most teams are not at 65 or 75 per cent yet. But the direction is not in question, and preparing now (before the transition arrives at your organisation) is the entire point.

So where did the value go?

Most people get this wrong in the same direction. They assume that when the cost of code collapses, the value collapses with it. The opposite is happening. The value did not vanish. It moved, up the stack, to the things the model cannot do for you: deciding what to build, knowing whether it is any good, specifying it precisely enough that an agent can execute it, and getting it in front of the right people.

What is left exposed is the engineering. Items eleven through fifteen (the understanding, the decisions, the reliable systems, the communication with humans) were always the job. Now they are the only part of the job that compounds in value as the tools get cheaper.

IBM CEO Arvind Krishna has described what he calls the $8 trillion math problem: reaching 100 gigawatts of global AI compute requires $8 trillion of capital expenditure (at roughly $80 billion per gigawatt), committed entirely to making items 1 through 10 faster and cheaper. Not one watt of those data centres makes items 11 through 15 easier to do (Futurism / IBM, 2025).

The return data confirms the gap. Goldman Sachs calculates that sustaining current investor return expectations requires AI companies to generate more than $1 trillion in annual profit from their AI infrastructure. By 2026, the industry consensus tracked by Goldman Sachs had reached around $450 billion in annual AI revenue: roughly $0.45 back for every $1 of capital expenditure (capex) (Goldman Sachs, 2024). The report named the problem plainly: “too much spend, too little benefit.” The DORA 2026 developer research programme found the missing variable: strong engineering foundations are what actually drive AI return on investment. The organisations seeing real returns are the ones with mature practices in the things AI cannot do: requirements, decisions, reliable systems.

Cheap to Write Is Not Cheap to Own

Those numbers describe where the value actually lives, and it is not in the production layer.

Cheap to write is not the same as cheap to own. This is not a theoretical concern: the evidence is in, and it is not flattering. The cost of code did not disappear when the typing got fast. It relocated, downstream, to review, to maintenance, to the slow tax of running software nobody on the team fully understands.

CodeRabbit (a code review analytics platform) found that AI-co-authored pull requests (bundled sets of code changes submitted for review) carried about 1.7 times more issues than human-only code, with security problems up to 2.7 times worse (CodeRabbit, 2025). The code arrives faster, and arrives carrying more of the kind of problem you do not see until later.

Then the part that should unsettle you. A controlled trial (sixteen experienced developers, 246 tasks, randomised assignment) put developers on code they knew well. With AI, they were about 19% slower (METR, an AI evaluation safety research organisation, 2025). Not faster. Slower. And they believed they were faster the whole time. The tool did not just cost them time. It cost them the ability to notice they were losing it, which is a different kind of problem entirely.

A large industry study found the pattern underneath: AI raises throughput (the rate at which code ships) and worsens delivery stability (DORA, the annual industry developer research report, 2025). It does not fix your team. It amplifies whatever your team already is. Disciplined shops get a multiplier. Sloppy ones get a faster way to ship the mess. There is a name worth keeping for the bill that comes due here: comprehension debt, the accumulating cost of shipping code nobody fully understands. You take it on quietly, at speed. You repay it all at once, in production, on the worst possible day.

The Apprenticeship Needs a New Curriculum

The cost moved. The work moved to higher ground. What about the people?

Stanford Digital Economy Lab found that employment for early-career developers, the ones aged 22 to 25, is down about 20% since AI went standard (Stanford, 2025). Not redistributed. Down. The roles that contracted fastest were the ones closest to items 1 through 10: take a clear ticket, write the obvious implementation, hand it back. That is exactly what an agent now does for nothing.

But look at what is expanding. The roles companies cannot fill fast enough are the ones requiring items 11 through 15: the technical lead who can run a requirements session, the senior engineer who can debug production without a map, the architect who makes good decisions under real ambiguity.

The apprenticeship is not being automated away. It is being rebuilt around a different curriculum. The path forward for early-career engineers is not to compete with AI on items 1 through 10. It is to use those tools to compress the routine work and invest the hours saved into items 11 through 15. The engineers who do that now are not behind the curve. They are the curve. The transition has not arrived everywhere yet.

Three Roles Worth Understanding Now

Three ways to read the shift, each based on the evidence above.

Technology Changed. Engineering Did Not.