How to Stay Relevant as a Developer After the Code Stopped Being Scarce

I have spent eight years inside China's technology industry, most of it writing software and then reviewing other people's. In that time I have watched this question change shape three times. First it was offshoring. Then it was bootcamps flooding the entry level. Now every piece written on how to stay relevant as a developer arrives with one of two answers, and both of them are dishonest. One says the tools are coming for you and you should panic. The other says nothing important has changed and you should relax.

Neither is worth your attention. Here is the version I think is actually true. The tools will keep getting better. That is not the interesting part. The interesting part is that writing the code was rarely the scarce skill, and a lot of us built careers pretending otherwise.

I say that as someone who spent years as a software engineer and then a senior one before moving into AI work. I was promoted for things I told myself were about code. Looking back, almost none of them were.

A Toy Server and a Repository Somebody Actually Maintains

Two randomized controlled trials of developers using AI reached opposite conclusions. Read together they explain far more than either does alone.

In the first, posted to arXiv in February 2023 and written by researchers at MIT and at Microsoft and GitHub, the two companies that build and sell the tool, developers given GitHub Copilot completed the task 55.8% faster than the control group. The task was implementing an HTTP server in JavaScript, from scratch, against the clock.

In the second, published by METR in July 2025, sixteen experienced open-source maintainers worked through 246 real issues on repositories they had contributed to for years, codebases averaging over a million lines. With AI tools they took 19% longer. They believed they had been sped up by roughly 20%. The distance between what was measured and what was felt is the most useful number in the study.

The trials are not matched experiments, and the honest reading is not that the tool made the difference. The first used Copilot autocomplete with developers recruited on Upwork in 2022. The second used Cursor with Claude Sonnet and long-tenured maintainers in 2025. What changes most between them is the task. One was greenfield code with no history, no conventions and no consequences. The other was work inside a system with, in METR's phrasing, "very high quality standards, or with many implicit requirements".

Implicit requirements. That is the whole thing. Every serious codebase is mostly implicit requirements, and almost none of them are written anywhere a model can read.

You become extremely fast at producing code you could not have written and cannot fully explain. Your output climbs. Nobody objects, because the tests pass.

Hiring Numbers That Disagree With Each Other

Here the evidence gets genuinely messy, and anyone telling you it is clear is selling something.

The Stanford Digital Economy Lab paper "Canaries in the Coal Mine?", by Erik Brynjolfsson, Bharat Chandar and Ruyu Chen, uses ADP payroll records covering millions of US workers through June 2026. Its finding for workers aged 22 to 25 in AI-exposed occupations: employment now sits 19% below where it would be had it kept pace with less-exposed peers. The adjustment runs through reduced hiring rather than firing. The authors themselves refuse the causal reading. They describe the results as early descriptive indicators, note the pattern varies across datasets and note it attenuates when you control for education. Almost every article citing that 19% drops all three caveats.

SignalFire's talent data points the same way. Its 2025 report put new graduates at around 7% of hires at large technology companies, down roughly 25% from 2023 and more than 50% below 2019 levels. Its June 2026 update has entry-level hiring at the tech majors down roughly 65% against 2019.

Now the contradiction. A Federal Reserve Board FEDS Note by Jessica Liu and Douglas Webber, published 27 March 2026, went looking for reduced job postings at firms and in industries with higher AI adoption and found none. Coefficients were small and mostly positive, implying postings rose somewhere between 0.04% and 0.13%. The authors flag their own limitation plainly: they measured total postings, not the specific occupations most exposed to automation. And Indeed's Hiring Lab, in its Q2 2026 vertical report, recorded that software development postings notched a sizable gain while quit rates across tech stayed low, which is what a market looks like when people are afraid to move.

So: aggregate demand for software work is not collapsing. Entry into it is narrowing. Both statements are supported by good data. They stop conflicting once you notice they describe different doors.

What has no support at all is the genre of executive prediction about what share of entry-level work disappears by which year. Those figures circulate constantly and none of them arrive with a published methodology, a dataset or a model anyone can inspect. They come from people with a direct commercial interest in the answer. Treat them as marketing, because that is what they are.

Which Parts of the Job Were Ever Scarce

Strip the typing out and look at what is left.

Deciding what to build, which is mostly deciding what not to build. Knowing why the last three attempts at this failed, knowledge that exists in no repository and usually in no document. Holding a system in your head well enough to predict what breaks at the far end when you change something at this end. And being the person accountable when it breaks anyway, at three in the morning.

None of those transfer cleanly to a model, and not because models are weak. They resist transfer because they depend on a specific history that was never recorded. A model can read your codebase. It cannot know that the retry logic looks strange because of an outage in 2022 nobody wrote up, or that the finance team will reject the obvious data model for reasons that are political rather than technical.

Accountability is the hardest to hand over. You cannot page a model. Someone has to say this is safe to ship and then carry it when it is not. That role was never about producing code. It was always about understanding a system well enough to stake something on it.

I watched this pattern hold across several teams and several promotion cycles. The engineers who advanced were not the fastest producers. They were the ones you could ask a question and get an answer from that was still correct a month later.

The Trap of Shipping Code You Cannot Explain

The 2025 DORA report, run by Google Cloud across nearly 5,000 technology professionals, found 90% using AI at work and more than 80% believing it made them more productive. It also found something less comfortable. AI adoption showed a positive relationship with delivery throughput and a negative relationship with delivery stability. More output. Less reliable output. Around 30% reported little or no trust in the code these tools produce, and they ship it regardless.

GitClear, a code analysis vendor, examined 211 million changed lines of code from 2020 to 2024. Duplicated code rose from 8.3% to 12.3% between 2021 and 2024. Lines involved in refactoring fell from about 25% of all changes to under 10%. For the first time in their dataset, copy-pasted code exceeded moved code. That is a picture of software being added faster than it is being understood.

This is the specific trap, and it is easy to walk into because it feels exactly like success. You become extremely fast at producing code you could not have written and cannot fully explain. Your output climbs. Your review comments get shorter. Nobody objects, because the tests pass.

Then something fails in a way the tests did not cover, and you find you have no model of the system in your head at all. You have a transcript.

Two checks I use on my own work. Could you delete this and rebuild it without the assistant? Could you describe its failure modes to a colleague without opening the file? If the answer is no, you did not learn anything this week. You produced.

How to Stay Relevant as a Developer: Domain Depth Over Tool-Chasing

A blunt heuristic: whatever generalizes is being commoditized first. General-purpose coding ability is precisely what these models were trained on, in enormous volume, from public repositories. Framework knowledge has always had a half-life measured in months, and the half-life is getting shorter.

What does not generalize is the specific. The regulatory constraint in one market. The physical tolerance in one manufacturing process. The reason a payment flow behaves differently in Lagos than it does here. I live in Shenzhen, where an enormous amount of software exists to control hardware that costs real money when it is wrong, and the binding constraint in that work has never been how quickly anyone can produce code. It is whether the person writing it understands what the machine does.

METR make a point in passing that I think is underrated. They note that domain-specific or repository-specific fine-tuning could plausibly produce genuine speedup. Read that as a career signal rather than a research note. Value is moving toward whoever holds the domain context the general model lacks. Being the person who owns that context is defensible. Being fluent in this quarter's tooling is not, and never was.

Concretely, for anyone early in this: use the tools, then do the reconstruction. Get the answer, read it until you can defend every line, close it and write it again yourself. That is slower. It is also the only version where you end up holding the thing you actually need, which is a mental model rather than a paste. Write incident reports. Volunteer for the migration nobody wants. Read code you did not write, which is now a far larger share of the job than it was five years ago.

The Objection I Cannot Answer

Here is the strongest case against everything above, and I do not think it can be waved away.

Learn judgment, learn systems, learn the domain. That is advice which assumes you are already inside. Judgment is built out of consequences. Consequences require a job where your decisions land on something. The traditional route to all four of the scarce skills I listed was doing large volumes of unglamorous entry-level work, sitting near people who were better and absorbing why things failed. That entry-level work is exactly what these tools now do most convincingly.

So the advice has a hole through the middle of it. Telling a graduate to develop deep systems judgment is close to telling them to already be senior. And the numbers suggest this is not primarily a matter of individual strategy. If new graduates have fallen to around 7% of hires at large firms, no amount of personal positioning changes the denominator. Some proportion of people who would have become excellent engineers will not get the chance, and they will not have done anything wrong.

The partial answers are real, but they are all worse deals than previous cohorts were offered. Open source, where the work is public and the code review is free. Small companies, where you will be badly under-resourced and therefore trusted early. Domains nobody else is competing for. Each of these is a way to buy consequence when the normal market has stopped selling it at a fair price. None of them is as good as the job that used to exist.

Nobody Is Paying for the Apprenticeship

Here is what I keep coming back to. Every model that writes competent code was trained on work produced by people who learned the slow way, by writing bad code in front of someone who told them it was bad and explained why.

The industry is now drawing down a stock of senior engineers it has largely stopped producing. That works for a while. Senior engineers do not expire on a fixed schedule. But the question that actually matters is not whether AI will replace software engineers. It is who will be qualified to check its work in fifteen years, and which company is willing to pay today for a training process whose returns arrive long after the executives approving this year's budget have moved on.

I have not heard a good answer to that. I have not heard it asked much either.

Tools referenced

GitHub Copilot, reviewed here: GitHub Copilot review.

Cursor, reviewed here: Cursor review.

Claude, reviewed here: Claude review.

Devin, reviewed here: Devin 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/

Peng, Kalliamvakou, Cihon and Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (arXiv, February 2023): https://arxiv.org/abs/2302.06590

Brynjolfsson, Chandar and Chen, Canaries in the Coal Mine?, Stanford Digital Economy Lab (revised August 2026): https://digitaleconomy.stanford.edu/publications/canaries-in-the-coal-mine/

Liu and Webber, AI Adoption and Firms' Job-Posting Behavior, Federal Reserve Board FEDS Notes (27 March 2026): https://www.federalreserve.gov/econres/notes/feds-notes/ai-adoption-and-firms-job-posting-behavior-20260327.html

SignalFire, State of Talent Report 2025: https://www.signalfire.com/blog/signalfire-state-of-talent-report-2025

Indeed Hiring Lab, US Labor Market Quarterly Verticals for Q2 2026 (18 August 2026): https://hiringlab.indeed.com/blog/us-labor-market-quarterly-verticals-for-q2-2026/

Google Cloud, Announcing the 2025 DORA State of AI-assisted Software Development Report: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report

GitClear, AI Copilot Code Quality Research (211 million changed lines, 2020 to 2024): https://www.gitclear.com/ai_assistant_code_quality_2025_research