Code generation is nearly free. The software engineering skills AI cannot replace are not.

Sundar Pichai's Cloud Next post in April 2026 put a number on it. Seventy-five percent of all new code at Google is now AI-generated and approved by engineers, up from 50% the previous autumn. The same month I was paying DeepSeek $0.22 per million input tokens off-peak on v4-flash, $0.66 for output, $0.007 per million on cached prefixes. Generation is close enough to free that the price has stopped being the interesting part of the sentence. What is interesting is that the software engineering skills AI cannot replace turn out to be the ones nobody bothered to name, because we assumed anyone doing the job already had them.

I have spent eight years in Shenzhen, most of that as a software engineer and senior software engineer before moving into AI and tech leadership, and I still write code most weeks. What I have watched is a rearrangement rather than a simplification. The scarce thing moved. The job description did not follow it.

Producing a function was never the scarce part

On 10 July 2025 METR published a randomised controlled trial that people are still arguing about. Sixteen experienced open-source developers, 246 real tasks, in repositories they had worked in for roughly five years. Half the tasks allowed AI tooling, mostly Cursor Pro. Beforehand the developers forecast a 24% speed-up. Afterwards they reported a 20% speed-up. Measured against the clock, they were 19% slower.

The sign of that number is less useful than the gap inside it. Thirty-nine points between what those engineers felt and what actually happened, in a group with every incentive to be accurate about their own craft. Speed was never the thing they were measuring when they said they felt fast. They were measuring how little friction there was between having an idea and seeing text appear.

Stack Overflow's 2025 developer survey, published at the end of December, found 84% of developers using or planning to use AI tools while trust in the output fell to 29%, down eleven points in a year. The most-cited frustration, at 66%, was code that is almost right. Second, at 45%, was that debugging AI-generated code takes longer than debugging your own.

Ask anyone who has shipped for a decade where their hardest week went. It will not be a week of writing functions.

The worst bug I ever shipped took four days to find and one line to fix. Nothing in the diff pointed at it, because the bug was not in the diff. It was in the space between two correct programs.

The software engineering skills AI cannot replace live outside the repository

Architecture is a bet about time. The question is never which of two designs a model can produce, because it can produce both, correctly, in under a minute. The question is which one will still be cheap to change in 2029, after the team that chose it has turned over twice and the constraint that justified it has quietly expired.

The information that settles that question is not in the code. It is in who carries the pager at 03:00, whether the vendor contract renews in eighteen months, what the regulator asked compliance last quarter and how much appetite the business has for a migration it cannot demo. A model reads the repository. The decision lives outside it.

Some choices are cheap to reverse. Data model, wire protocol, tenancy boundary and identity are not. Getting a reversible one wrong costs a sprint. Getting a one-way door wrong costs a rewrite, and the rewrite always gets proposed in the quarter the company can least afford it.

DORA's ROI report on AI-assisted development, covered in May 2026, measured the shadow of this. Productivity gains on greenfield tasks ran 35 to 40%. On legacy code the same tooling often returned 10% or less. That difference is the accumulated weight of decisions somebody made years ago, and it is where most engineers actually spend their careers.

Debugging is the skill that did not transfer

Generation is a forward operation. You describe an outcome and receive text. Debugging runs the other way. You have an outcome nobody wants, and you reconstruct the causal chain that produced it inside a system that is live, under load, holding state you cannot fully observe.

The worst bug I ever shipped took four days to find and one line to fix. A service I had written was losing roughly one message in forty thousand. Not enough to page anyone. Enough to matter. The retry logic was correct. The queue was correct. The consumer was correct. Two machines disagreed about what time it was by about 900 milliseconds, and a deduplication window I had set to one second turned that disagreement into silent data loss. Nothing in the diff pointed at it, because the bug was not in the diff. It was in the space between two correct programs.

That is the shape of most production failure I have seen in eight years. Correct components with an incorrect assumption sitting between them. Clock skew, retry storms, a cache that is warm in staging and cold in production, a partner API that returns HTTP 200 with an error in the body.

This is why the 45% figure matters more than it looks. When you debug your own code you are debugging a system you already carry a model of. When you debug generated code you have to build that model first, at speed, under incident pressure, from text you did not write and never reasoned your way into.

Reading systems is now most of the job

LinearB published an analysis of 8.1 million pull requests on 4 May 2026, covering 4,800 organisations across 42 countries. AI-assisted pull requests run about two and a half times larger than unassisted ones, over 400 lines against 157 at the 75th percentile. Agentic pull requests wait more than sixteen hours before a reviewer picks them up, against roughly 200 minutes for human-authored work. AI-generated pull requests merge at 32.7%. Manual ones merge at 84.5%.

The finding I keep returning to is this one. AI-assisted pull requests show close to zero refactoring, while human pull requests still run around 37%. Generation writes new code. It does not go back and make the old code smaller.

GitClear's January 2026 research across 623 million changes says the same thing from the other end. Refactoring line moves fell from 21% in 2022 to 3.8% year to date in 2026. Long-term maintenance updates dropped from 1.7% to 0.46%. Duplicated blocks climbed from 40.3 per million changed lines in 2023 to 73.0. Cross-file method calls fell 35%, from 343 to 223 per thousand changed lines.

So the codebase grows faster, repeats itself more and connects to itself less, and the review queue becomes the ceiling on delivery. Reading a system well is now a load-bearing skill in a way it simply was not in 2019. Not reading the diff. Reading the thing the diff lands in, holding enough of it in your head to notice that the correct-looking change quietly assumes something that stopped being true two releases ago.

The judgement of when not to build

Shenzhen makes the temptation to build unusually visible. Huaqiangbei, the electronics market district in Futian, was receiving close to 8,000 overseas buyers a day this summer, with AI-related products accounting for 61% of local electronics transactions by July. You can describe a device on Monday and hold a sample by Friday. Speed of construction has never been the constraint here.

I have sat in enough factory meetings to recognise the moment. Somebody describes a defect that human inspectors keep missing, and within ten minutes the room has converged on a vision model. Cameras, a labelled dataset, a training loop, an inference box bolted to the line. It is a real project. It is fundable. On two separate occasions I can remember clearly, the defect was a lighting problem, and a fixture costing less than a week of my time made the detection problem disappear entirely. Nobody gets promoted for the fixture.

Every system you build arrives with an on-call rota, a dependency graph and a migration you will owe somebody in four years. Generation made day one of a project cheap and did nothing at all to days two through fifteen hundred. Saying no is worth more now than it was in 2020, precisely because the demo is so easy to produce that the argument against building it has to be made against a working prototype.

Mentoring when the answer arrives before the question

A junior engineer in 2026 has an oracle. It responds in four seconds, it is right often enough to be trusted and it will never volunteer the one useful thing, which is that the question was wrong.

What used to happen: you got stuck for two hours, opened three files you had no business opening and came out the other side holding a map of the system you did not know you were drawing. The stuck time was the tuition. It has been refunded, in full, to everyone.

I have written elsewhere on this site about what happens to the hiring pipeline when the junior rung closes, and I am not going to repeat that argument. The one number worth carrying across is that the Stanford Digital Economy Lab's revision of 12 August 2026 puts employment for 22 to 25 year olds in the most AI-exposed occupations 19% below where it would be had it tracked their less-exposed peers.

So mentoring changes shape. I stopped reviewing juniors' code first. I review the decision that produced it. Why this shape. What breaks it. What you would have to believe about traffic, failure or the next two features for this to be the right call. Half the time the code is fine and the reasoning is simply absent, and the absent reasoning is what will hurt them in year three.

The strongest version of the counter-argument

Senior engineers have made this argument before and been wrong every time. Assembly programmers said register allocation required judgement a compiler could not exercise. Then people said memory management did. Then that you could not generate a correct query plan, or an ORM layer, or a deployment topology. Each time the irreducible core turned out to be reducible, and each time the people defending it were the ones with the most experience and the most to lose.

The current evidence supports them, not me. Google reports a complex code migration completed six times faster by agents and engineers working together than engineers managed a year earlier. Open-weight coding models good enough for real repository work now run on a single high-end GPU under permissive licences, which means the price floor is not the API bill. It is electricity.

The concession I owe is larger than that, though. A good part of what I am calling judgement is compressed pattern matching over failures I personally witnessed, and compressed pattern matching over a very large corpus of failures is exactly what these systems are built to do. I do not think architecture is mystical. I think it is currently starved of training signal.

Here is where the argument still holds. SWE-bench has an oracle. The test passes or it does not, within seconds. Architecture has no oracle inside any horizon you could train against. The verdict on a decision I make this month lands in 2030, filtered through staff turnover, a market shift and three product pivots, and even then nobody attributes it correctly. You cannot descend a gradient on that. Until something gives a model consequences it has to live inside for years, it will keep producing locally excellent decisions with no view of year four, and somebody with a mortgage and a memory will have to sign them off.

The stock we are drawing down

Every skill I have listed as the surviving core of this job was acquired by doing work that no longer needs doing.

I learned what a bad abstraction feels like by living inside one for two years. I learned failure modes by causing them, at 02:00, in code I had typed myself. I learned when not to build by building three things nobody used. None of that came from a curriculum. It came from an apprenticeship whose raw material was the routine implementation work that now costs $0.22 per million tokens off-peak.

The market has decided senior judgement is scarce and started bidding for it. What the bidding does not price is that judgement was never taught. It was deposited, slowly and expensively, by exactly the work we just made free.

Every senior engineer working today was produced by a process we are in the middle of switching off. The bill is not due this year, and the people who will pay it are not the ones making the decision.

Tools referenced

Cursor, reviewed here: Cursor review.

GitHub Copilot, reviewed here: GitHub Copilot review.

Claude, reviewed here: Claude review.

Devin, reviewed here: Devin review.

DeepSeek, reviewed here: DeepSeek review.

Qwen3-Coder, reviewed here: Qwen3-Coder review.

Sources

METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (10 July 2025): https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

Stack Overflow 2025 Developer Survey, AI section: https://survey.stackoverflow.co/2025/ai

LinearB, 8 million pull requests reveal where engineering productivity breaks down (4 May 2026): https://linearb.io/blog/8-million-prs-engineering-productivity

GitClear, The Maintainability Gap: 2026 AI Code Quality Research: https://www.gitclear.com/the_ai_code_quality_maintainability_gap

InfoQ on DORA's ROI of AI-assisted Software Development report (11 May 2026): https://www.infoq.com/news/2026/05/dora-roi-ai-assisted-dev-report/

Sundar Pichai, news from Google Cloud Next 2026: https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/cloud-next-2026-sundar-pichai/

DeepSeek API pricing documentation: https://api-docs.deepseek.com/quick_start/pricing

Stanford Digital Economy Lab, Canaries in the Coal Mine? (revised 12 August 2026): https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recent-employment-effects-of-artificial-intelligence/