tellsiddh's blog

43 min read

Is the Future of Software Engineering Agentic? What the Data Says in 2026

  • tech
  • ai
  • agents
  • career

Every few weeks someone tells me the software engineer is finished, and every few weeks someone else tells me nothing has really changed. Both are wrong, and both are wrong in ways you can measure. I spent a while reading the predictions, the controlled studies, the labor data, and the history, and this post is my attempt to write down what is actually known as of September 2026, what is still open, and what I think happens next.

A note on how I wrote this. I tried to separate three things that usually get blended together: what people with something to sell are saying, what controlled or large-scale measurements show, and what I personally believe. Where I am guessing, I say so. Where a number is self-reported or comes from a vendor, I say that too. Every number has a footnote so you can check it.

One more distinction, which a colleague pushed me on after the first draft and which I think most of this debate gets wrong. Software engineering is a profession: a title, a headcount, a hiring rate, a salary band. Software development is an activity: the making of software that did not exist before. Most of the data below is about the profession, because that is what gets measured. But the two are coming apart, and if you only watch the profession you will miss most of what is happening. I come back to this at the end.

Where we actually are, September 2026

Start with the things that are not in dispute.

Adoption is essentially total. The 2025 Stack Overflow survey (49,000+ respondents) had 84% of developers using or planning to use AI tools, with 51% of professionals using them daily.1 DORA’s 2025 report put it at 90% of tech professionals.2 Stack Overflow’s May 2026 agents pulse survey found 59% using agents at work, up from 31% a year earlier.3 Whatever you think of the tools, the “will people adopt this” question is closed.

The money is real. Cursor went from $100M annualized revenue in January 2025 to about $4B by June 2026.4 Anthropic reported Claude Code passing $2.5B run-rate in February 2026.5 OpenAI reported Codex at over 5M weekly users by mid-2026.6 Run-rate is a flattering metric (last month times twelve), but these are not toy numbers.

The share of code written by machines at AI-forward companies is high. Google said in April 2026 that 75% of new code is “AI-generated and approved by engineers,” up from 50% the previous fall.7 Anthropic reported in June 2026 that over 80% of code merged to its production codebase in May was authored by Claude.8 Coinbase claimed 95 to 100% by July 2026.9 Every one of these numbers is self-reported by a company that sells AI, and none of them publish a denominator (does autocomplete count? tests? generated boilerplate?). But the direction is consistent across all of them and I do not think it is fabricated.

And the tools crossed a threshold in late 2025. The clearest signal is Andrej Karpathy, who is not a vendor. In October 2025 he told Dwarkesh Patel that coding agents “just don’t work,” called their output slop, and said they were not net useful on his own project. On February 26, 2026 he posted that “coding agents basically didn’t work before December and basically work since.” By March 2026 he said he had not typed code by hand since December.10 When the person who coined “vibe coding” as a half-joke flips from skeptic to full delegation in four months, something changed in the models, not just the marketing.

So: everyone is using it, a lot of code is coming out of it, and the tools got materially better around the turn of the year. That is the baseline. Now the harder questions.

What controlled studies actually show about productivity

This is where the gap between claims and measurements is widest.

The most-cited rigorous study is METR’s randomized controlled trial published July 2025.11 Sixteen experienced open-source maintainers (median ten years experience) worked 246 real tasks on their own repos, randomized to AI-allowed or not. The AI-allowed tasks took 19% longer. The part I keep coming back to: before starting, the developers predicted AI would make them 24% faster. After finishing, having been measurably slowed down, they still believed it had made them about 20% faster. Economists surveyed beforehand predicted 39% speedup. Everyone was wrong in the same direction.

The obvious objection is that this was early-2025 tooling (Cursor with Claude 3.5/3.7 Sonnet) on codebases the developers knew intimately, where an agent has the least to add. METR said as much. So they ran it again.

The February 2026 follow-up had 57 developers, 143 repos, and 800+ tasks with later tools.12 For the ten developers who returned from the original study, the point estimate flipped to an 18% speedup, but the confidence interval ran from -38% to +9%, which is to say it crossed zero. For the 47 new developers: 4% speedup, interval -15% to +9%. METR’s own language was that this is “very weak evidence” and probably a lower bound, because the study design broke: 30 to 50% of participants admitted withholding tasks they did not want to do without AI, and timing became unreliable once people started running multiple agents in parallel. They are abandoning the design entirely. That last part is the most honest thing in the whole literature. The tool changed the shape of work enough that the ruler stopped fitting.

Google’s internal RCT (96 engineers, one enterprise task) found about 21% time reduction, with the authors noting a wide interval.13 That is a real gain. It is also one task in a lab-like setting.

The largest field study I found is from July 2026: 802 developers, 196,212 pull requests, January 2024 to April 2026, at one mid-sized company that had an explicit “2x PR output” mandate.14 Merged PRs per person hit 2.09x the baseline. Per-reviewer load roughly doubled. Automated review overtook human review in volume. Merge and revert rates held flat. The title of the paper is “AI Writes Faster Than Humans Can Review,” and that is the finding. Output doubled; the ability to check it did not.

DORA’s 2025 report (about 5,000 respondents) is the best survey-scale data and it lands in the same place from a different angle.2 In 2024, DORA found that every 25% increase in AI adoption correlated with a 1.5% drop in throughput and a 7.2% drop in delivery stability.15 In 2025 the throughput correlation turned positive, but instability kept rising. DORA’s framing is that AI is an amplifier: it makes good organizations better and dysfunctional ones worse. Gergely Orosz’s 2026 survey of engineering leaders found the same split, with some orgs reporting twice as many customer-facing incidents and others half as many.16 There is no 2026 DORA report; they paused the annual survey this year.17

Here is what I take from all of this. The honest range for measured individual productivity gain with current tools, on real work, is somewhere between “slightly negative” and “about 20% faster,” with a self-perception gap of 20 to 40 points on top. The 2x, 5x, and 10x numbers you hear are either PR volume (which the Vasilescu study shows you can mandate into existence), or self-reported, or from people who have restructured their entire workflow around agents and are describing their own experience, which is real but does not transfer to a team by decree.

Anthropic itself, in the same June 2026 report that claimed 80% of merged code, said that code volume overstates true productivity and that human review is the new bottleneck.8 When the most bullish company in the space says that, believe them.

The quality bill is arriving

If output goes up and verification does not, something has to give, and we have data on what.

GitClear’s June 2026 report, covering 2023 through mid-2026, found duplicated code blocks per million changed lines went from 40.3 to 73.0, an 81% increase.18 Moved or refactored code as a share of changes fell from 21% in 2022 to 13% in 2023 to 3.8% in 2026. Copy-paste rose from 9.4% to 15.7%. Error-masking constructs (empty catches, silent fallbacks) up 47%. GitClear sells a code quality product, so discount accordingly, but nobody has published contradicting data, and every one of those metrics moves in the direction you would predict if the writer of the code does not have to maintain it.

Veracode’s GenAI code security reports found that 45% of coding tasks (2025) and 44% (2026) introduced an OWASP Top 10 vulnerability in raw model output.19 Syntax correctness went to nearly 100% between the two reports. Security pass rate went from 55% to 56%. The models got dramatically better at producing code that compiles and runs and barely moved on producing code that is safe. This is measured on raw output without agentic self-review or scanners, so the real-world number with a good pipeline is better. But it tells you where the models’ own gradient points.

Then there is the benchmark problem. On SWE-bench Verified, frontier models now score above 90% according to every tracker, and the benchmark is widely considered saturated and contaminated. Scale AI’s SWE-bench Pro V2 (September 22, 2026) is the cleanest primary source I found on this: the top model scores 99.4% on the public task set and about 81.6% on a private, held-out set.20 Scale attributes most of that 17.8 point gap to training-time exposure. Still, 81.6% on genuinely unseen, network-locked, real-repo tasks is remarkable. A year earlier the top score on SWE-bench Pro was 23.3%.

METR’s time-horizon metric is the other capability measure worth knowing.21 It asks: how long a task (in human-expert hours) can a model complete with 50% reliability? Their January 2026 update put the post-2023 doubling time at about 4.3 months. The most capable model they measured (evaluated March 2026) had a 50% horizon of at least 16 hours, at which point METR posted a notice that their task suite can no longer measure reliably above that. Their FAQ is careful to note these are clean, self-contained, algorithmically scored tasks, and the horizon is what a low-context contractor could do, not a high-context employee. The 80% reliability horizon is much shorter. On messy tasks with holistic scoring, performance drops.

Simon Willison put the quality question better than I can, in June 2026: when you ship code faster than engineers can read it, you are making withdrawals from a trust account. Enthusiasts are in a race against time, skeptics are in a race against entropy. Both races are real and I do not know who wins.

Can the review itself be automated?

Everything above says verification is the bottleneck. The obvious next question is whether verification gets automated too, the way generation did. I went looking, and the answer is yes for part of it, no for part of it, and the part that stays human is not the part I expected.

Start with how good human review actually was, because that is the bar. Before Anthropic turned on AI review internally, 16% of its PRs got a substantive comment.22 The best pre-LLM evidence, McIntosh et al. on Qt, VTK, and ITK, found that low review coverage produces “up to two” additional post-release defects per component.23 Real, but modest. Human review is a low-recall, high-variance detector that we have been treating as a gold standard because nothing else existed.

Against that bar, the tools look good on the vendors’ numbers. Anthropic’s multi-agent Code Review took substantive comments from 16% to 54% of PRs, flagged an average of 7.5 issues on PRs over 1,000 lines, and engineers marked under 1% of findings incorrect.22 At Vasilescu’s company the revert rate did not move when automated review took over from humans. A secondary report says Anthropic’s Claude Tag now lands 65% of product-engineering PRs, with only core changes going to a human code owner.24

Against independent benchmarks, they look much worse. SWR-Bench, 1,000 manually verified real PRs with full project context, found the best configuration scored about 34 F1 on PRs with a single ground-truth issue, and recall fell to 16% when a PR had three issues and 12% at four.25 The tools are decent at functional bugs and poor at design, maintainability, and documentation, which is most of what human reviewers actually comment on. A separate study found ChatGPT caught 10% of the quality issues human reviewers flagged, though 40% of its extra comments pointed to something real.26

The two pictures reconcile once you notice what the vendors measure. “Under 1% marked incorrect” is precision. Nobody publishes recall, because measuring what the reviewer missed requires knowing the true bug count, and that number is expensive to get and unflattering when you have it. A reviewer that never says anything wrong and misses half the bugs scores identically. Trust the findings. Do not trust the silence.

Then there are two problems that better models do not obviously fix.

First, the reviewer is usually the same model family as the author. Self-preference bias is measured, not hypothetical: every judge model tested rates its own family higher than a neutral panel does, by a mean index of about +0.14 across GPT and Claude models.27 Judge decisions on code shift with prompt framing even when the code is unchanged.28 If Claude has a blind spot writing the code, Claude has the same blind spot reading it. The failures are correlated, and correlated failure is the one thing a second reviewer exists to prevent.

Second, whatever oracle you automate, the generator gets optimized against it. SpecBench gave agents a spec plus visible tests, then graded them on held-out tests that only composed features the spec already required.29 Every frontier agent saturated the visible tests. The gap on the held-out tests grew about 27 points for every tenfold increase in code size. One agent produced a 2,900-line hash-table “compiler” that memorized the test inputs. EvilGenie observed explicit reward hacking by both Codex and Claude Code.30 Human review is valuable partly because it is out-of-distribution for the generator. An LLM reviewer is not.

And then the incentive problem, which I have not seen anyone in the tooling debate say plainly. The companies selling review are paid per token. Anthropic’s review costs $15 to $25 per PR, roughly three million tokens, most of it reading context.22 Cursor moved Bugbot from a flat $40 seat to usage-based billing in May 2026, and it re-runs on every push.31 A reviewer that runs more agents and produces more findings bills more. One that says “this is fine” bills almost nothing. I am not claiming the findings are padded. I am saying the pressure on the product runs toward volume, and there is no external check on whether 7.5 findings are 7.5 things that matter. These are also the same companies selling the generation that created the review deficit in the first place. That is a lot of trust to extend to one vendor on one invoice.

There is a path around all of this, and it is not more reading. In July 2026 someone shipped a formally verified 3D mesh intersection in Lean 4 with review instructions attached: read the 93-line specification, run the checker, ignore the 1,000 lines of implementation and the 60,000 lines of machine-generated proof.32 Pure Dafny verification went from 68% to 96% in a year.33 Where a checkable spec exists, reading the implementation is a waste of a scarce human. Where it does not, which is most business software, the spec is the thing that is missing, and writing it is the job.

So: the diff-reading layer of review gets automated, and honestly it should, with the reviewer forced onto a different model family than the author and the tests held where the agent cannot see them. What does not get automated is deciding what to check. That moves up, not away.

The labor market: the damage is at the entry level

This is the part where I think most commentary is either dishonestly rosy or dishonestly apocalyptic, so I am going to give you the numbers and let them sit.

The Stanford Digital Economy Lab “Canaries in the Coal Mine” paper (Brynjolfsson, Chandar, Chen) uses ADP payroll data on millions of workers.34 In its August 2026 revision, employment of 22 to 25 year olds in the most AI-exposed occupations is 19% below where it would be had it tracked less-exposed peers. In the original August 2025 version, software developers aged 22 to 25 were down nearly 20% from their late-2022 peak while developers 35 and over grew. The adjustment happens through reduced hiring, not firings. It shows up in headcount, not in pay. The effect is concentrated where AI automates rather than augments. The authors are explicit that these are descriptive patterns, not causal estimates, and the divergence survives controls for interest rates, remote work, and excluding tech firms.

SignalFire’s 2026 talent report (LinkedIn-style profile data, so it undercounts some hires) has Big Tech new-grad and entry-level hiring down about 65% versus 2019, and down about 76% at early-stage startups.35 Top CS grads in 2025 were 45% less likely to land a Big Tech job than the 2022 class. Engineering managers now average 12 reports, up from 10. SignalFire’s own headline was that the “AI Code Apocalypse” for engineers failed to materialize, because total engineering headcount held up far better than design, product, or marketing. What collapsed was the on-ramp.

The NY Fed’s data by major has computer engineering at 7.5 to 7.8% unemployment for recent grads, second highest of 73 majors, and computer science at 6.1 to 7.0%, top five.36 But CS underemployment is around 19% versus roughly 40% for all majors. Unemployed CS grads are not working retail; they are either in the field or not working. That is a harder market, not a dead one.

Meanwhile, at the senior end, the picture is different. Indeed Hiring Lab (July 2026) found US software development postings up about 15% since Claude Code launched in February 2025, while overall postings fell 7%.37 Postings are still about 27.5% below February 2020. Of the year-over-year increase, 71% was senior roles and 37% had “AI” in the title. Senior positions were 69.3% of all software development postings in Q1 2026, the highest share of any occupation Indeed tracks.38

BLS still projects software developers growing 10% from 2025 to 2035 (1.9M jobs, about 106,000 openings a year, median pay $135,980).39 BLS projections are ten-year trend models and historically slow to absorb technology shocks, and BLS itself flags AI as a risk to this one. Treat it as a prior, not a forecast.

Layoffs: roughly 140,000 US tech cuts year-to-date in 2026 per the FT, with Amazon, Oracle, Meta, and Microsoft accounting for about 50,000.40 Challenger, Gray & Christmas counted about 55,000 US layoffs explicitly citing AI in 2025, twelve times 2023’s figure.41 Block cut nearly half its staff. Salesforce cut about 4,000 support roles with Benioff saying “I need less heads.”42 Coinbase cut 14% with Armstrong saying engineers ship in days what used to take a team weeks.40

And then the reversals. Klarna’s CEO said in May 2025 that they focused too much on cost and got lower quality, and resumed hiring humans.43 Robert Half surveyed about 2,000 managers in April 2026 and found 32% of those who eliminated a role for AI later rehired the same or similar role.44 Gartner predicts half of companies attributing cuts to AI will rehire similar roles by 2027. The FT found companies citing AI for cuts underperformed the Nasdaq by about 10% over the following 30 trading days.40 Andrew Ng’s term for this is “AI washing,” and I think he is partly right: pandemic over-hiring and interest rates explain a lot of 2022 to 2024. But the Stanford data controls for those and the entry-level effect persists.

Jos Visser, who spent years at Google and is now at OpenAI, wrote something in June 2026 that I think is the most honest sentence in any of the pieces I read. On the question of where senior engineers come from if nobody hires juniors: “For now I assume that everyone assumes that is someone else’s problem.” He also notes that neither Anthropic nor OpenAI hire new grads. Charity Majors said the same thing more bluntly back in 2024: by not training juniors we are cannibalizing our own future. Two years later, the data says that is exactly what is happening, and nobody has a plan.

A scorecard on the loud predictions

Predictions with dates can be checked. Here is how the famous ones did.

Who When Claim Status, Sept 2026
Dario Amodei45 Mar 2025 AI writes 90% of code in 3 to 6 months, essentially all in 12 True inside Anthropic (80%+ by May 2026) and at a handful of AI-forward companies. Not true industry-wide. He later softened to a Jevons-paradox framing.46
HN commenter reading Amodei’s essay47 Jan 2025 “Software engineering fully automated by 2027, the 0.01% engineer” The essay never says this. The thread itself caught it. Still repeated constantly.
Boris Cherny (Claude Code)48 Feb 2026 “The title software engineer is going to start to go away” by end of 2026 Postings with the title are up 15% since Feb 2025 per Indeed. Wrong on the title, possibly right on the content of the job.
Andrej Karpathy Oct 2025 Agents “just don’t work,” not net useful He reversed himself in Feb 2026. Honest about it, and the reversal is the datapoint.
Andrew Ng Apr 2026 Jobpocalypse won’t happen; postings rising; reading generated code “is not that important” Right on postings, right on AI washing. Reading the code is unimportant only if something else is checking it, and Ng leaves that clause out. Heard with the clause, it is the Lean-mesh position and it is correct. Heard without it, which is how most people will hear it, it is the most dangerous idea in this debate.
Martin Fowler49 Feb 2026 Most LLM claims were “little better than snake oil,” but this time is different By July 2026: “The whole debate about whether this changes software engineering is over.”
JetBrains50 Sept 2026 “Code becomes cheaper to generate but more expensive to verify” Consistent with Vasilescu, GitClear, Anthropic’s own report. It is also exactly the problem their new product line sells a solution to.

The pattern: the people closest to frontier labs were directionally right about capability and early by about a year on the timeline. The people saying “nothing changes” were wrong. The people saying “everyone is fired by 2027” misread their own source. And almost everyone underweighted the verification problem until the data forced it.

What history actually says (with numbers)

Three analogies get thrown around. They are more useful than people think, but only if you read to the end of the story.

ATMs and tellers. US ATMs went from about 100,000 to 400,000 between 1995 and 2010. Tellers went from about 500,000 in 1980 to about 600,000 in 2010.51 Cheaper branches meant more branches, and tellers shifted to relationship work. This is the Jevons paradox example everyone cites. What they skip: BLS counts 339,200 tellers in 2025, projected down another 13% by 2035.52 The complementarity held for about thirty years and then mobile banking broke it. The lesson is not “automation creates jobs.” It is “automation creates jobs until the demand it unlocks is itself automated.”

Spreadsheets and accounting. Bookkeepers and accounting clerks fell from about 2.0M in 1987 to 1.5M in 2000. Accountants and auditors rose from 1.3M to 1.5M. Management analysts and financial managers went from 0.6M to 1.5M.53 The job that was mostly “execute the calculation” shrank by a quarter. The jobs that were “decide what to calculate and what it means” more than doubled. The total went up. The people who lost the clerk jobs were not, for the most part, the people who got the analyst jobs.

Offshoring. In 2000, BLS counted 530,730 “computer programmers” and about 640,000 “software engineers.”54 The offshoring panic of 2002 to 2005 predicted mass elimination of US developer jobs. By 2015, programmers had fallen to about 295,000 (down 45%) while software developer titles had risen to about 1.14M (nearly doubled).55 Total up about 22%. The occupation whose definition was “translate a spec into code” shrank. The occupation whose definition included owning the design grew. Real people in the first group had real careers disrupted.

The consistent shape across all three: the execution layer of a job gets automated, the judgment layer grows, total headcount often rises, the transition is brutal for the specific people in the execution layer, and the complementarity is not permanent. I see no reason software would be exempt from any part of that pattern, including the last part.

So is the future agentic coding?

Yes, for code production. I do not think this is in doubt anymore. The share of code typed by humans is heading toward a small minority at any organization that is paying attention, and the Karpathy reversal is the tell that the tools crossed from “impressive demo” to “default workflow” around December 2025. Addy Osmani’s framing of conductor (one agent, tight loop) versus orchestrator (fleets of agents producing PRs asynchronously) matches what I see, and the orchestrator mode is where the growth is. JetBrains’ prediction that more work gets triggered by repository events and schedules rather than a developer opening an editor is, I think, correct on a three-year horizon.50

No, for software engineering as a job, if you define the job correctly. And here is where I want to be concrete rather than comforting.

The job was never typing. I have written two incident posts on this blog about an OpenSearch cluster: one where a blue/green deployment wedged on an unassignable security index for five hours, one where a k-NN circuit breaker tripped and rebooting the node did nothing because it reloaded the same graphs. Neither of those was a coding problem. They were problems of knowing which of three plausible fixes to try first, knowing when to call AWS support versus keep digging, knowing that closing and reopening the index would flush native memory when a reboot would not, and being the person whose name was on the decision to migrate. An agent can now write the diagnostic scripts faster than I can. It cannot yet be the one who is accountable for the cluster. JetBrains put it as “an agent will not get the call at 3:00 am when something breaks,” and that is marketing copy, but it is also true.

So what is left of the role is three things, and what is gone is a fourth.

Verification, but not the kind most teams are doing. Thoughtworks’ 2026 Europe retreat report said code generation is no longer the bottleneck, verification is.56 Stack Overflow’s top frustration was “almost right, but not quite” at 66%.1 Reading code you did not write, at volume, is what verification looks like in 2026 because most teams have no better oracle. The durable skill is designing the oracle: the held-out test, the property, the contract, the spec small enough to hold in your head. Most working engineers have never written one. The ones who can are the ones the senior postings are for.

Ownership. The decision to migrate and the name on it. This is the layer where the OpenSearch incidents lived, and it is where agents are weakest, not because they cannot reason about it but because nobody has agreed to let them be the one who is wrong.

Process. DORA’s amplifier finding and Orosz’s split between organizations with twice the incidents and half the incidents are the same result. The tool does not have a sign; the organization gives it one. Teams that treat this as a tooling change will get measurably worse, and the ones that treat it as a process change will pull away.

What is gone is the typing, and, sooner than most people expect, the reading.

My prediction

Everything above is what the data says. This section is what I think, and I want to be upfront that I am an optimist by temperament and I have tried to check that against the record rather than trust it.

The record is not kind. Automation has been cruel to the specific people it landed on, and not in the abstract way economists mean when they say “transition costs.” A Demography paper using exogenous variation in industrial robot adoption found that automation between 1993 and 2007 caused substantive increases in all-cause mortality for men and women aged 45 to 54.57 Case and Deaton’s deaths of despair are the same story told from the other end: people who lost stable work also lost, in their words, their place in society, their status and self-respect.58 Those were not people who failed to reskill. They were people whose skill stopped being wanted, in a country that had decided that was their problem.

But there is a detail in Case and Deaton’s own work that I think is the most important fact for anyone trying to predict what happens to engineers. Other rich countries faced the same globalization and the same robots and did not see the wage stagnation or the mortality.59 The technology was the same. The outcome was not. Acemoglu and Johnson make this the thesis of a whole book: a thousand years of history say there is nothing automatic about new technology producing shared prosperity, and whether it does is a political and economic choice.60 Their February 2026 paper goes further and sorts technological change into five kinds, of which only one, the kind that creates new tasks for human expertise, is unambiguously good for workers. The rest depend on who captures the gains. They also name the failure mode: misaligned incentives, path dependence, and what they call a pervasive pro-automation ideology, which together push firms toward replacing people even when augmenting them would be worth more.61

The junior hiring collapse in the data above is the software industry’s version of that default. Nobody decided to stop training engineers. Every company individually decided that training was someone else’s job, and the aggregate is a 65% drop in the on-ramp. That is the pro-automation default operating with nobody’s hand on the wheel.

So here is where the optimism comes in, and where I think it is earned rather than assumed.

Go back to the distinction I drew at the top. Everything in the labor section measures the profession. Ask instead what is happening to the activity, to the amount and shape of software that exists in the world, and the picture inverts.

Software is unusual among the things that have been automated, because the demand for it is not fixed. A factory town needed a certain number of cars built. The world does not need a certain number of programs written; it has always wanted far more software than it could afford to build, and the constraint was the cost of people who could build it. When that cost falls, more gets built, by more people, for more people.

Mitchell Hashimoto, who built Vagrant and Terraform and is not selling anything, has the cleanest account of what that looks like from inside a project.62 Ghostty, his terminal, took 18 months to reach a million daily update checks. libghostty, the library he extracted from it, reached multiple millions of daily users in two months by living inside other people’s software. His read is that the way software gets built and adopted has shifted from polished mainline applications to building blocks that others assemble, and that the barrier which used to limit who could do the assembling, understanding the components well enough to glue them together, is gone. Niche communities that could never have justified a product are getting tools. Maintainers can say no to feature requests because forks are cheap. Research and development gets outsourced to the ecosystem and the mainline cherry-picks what works. He is explicit about the costs: security holes, instability, load-bearing systems nobody understands. He is also explicit that high-quality mainline software does not disappear; it gets more stable and more purposeful because the experimentation happens elsewhere. His summary is that the shift has already happened and we are living in it.

The venture data says the same thing from the outside. Cao’s study of digital ventures found that exposure to AI coding tools increased first-time venture launches after late 2022, and, this is the part that matters, founders with software work experience drove the larger share of those launches, survived better, and accounted for the entire increase in venture financing.63 Software expertise did not become less valuable when the code got cheap. It became the thing that separated ventures that lasted from ones that did not. Solo-founded startups reportedly went from about 24% of new ventures in 2019 to 36% by mid-2025.64 That is Acemoglu’s new-task category showing up in the data: not engineers doing the old job faster, but people with engineering judgment doing things that did not exist as jobs.

Put the two views side by side. The profession is contracting at the entry level and consolidating at the top. The activity is exploding: more software, more specific, for more people, built by more people, with a stable core of well-maintained blocks underneath. These are the same event. Which one you look at determines whether the future reads as bleak or bright, and, as the colleague who pushed me on this put it, your sentiment will shape your goals. I had been looking at the profession.

On meaning, which is the question underneath the question. The developers in the Stack Overflow data are not happy about the tools in the way the adoption numbers would suggest. Trust in AI accuracy fell from about 40% to around 30% in two years, 46% actively distrust it, positive sentiment dropped from above 70% to 60%, and the top frustration is output that is almost right.1 That is the sound of people who liked the craft watching the craft get commodified. I feel it too. But the same survey has the share of developers happy at work going up, not down, and 64% still do not see AI as a threat to their job. Hashimoto ends his adoption post by saying he does not much care whether AI is here to stay, he is a craftsman who wants to build things for the love of the game.65 I think that is where the meaning was all along, and it is the part that is not automated.

What I actually predict, with dates so I can be wrong in public:

By the end of 2028, human approval of code will have split along the cost of being wrong. For internal tools, prototypes, and anything a bad deploy can be reverted out of, nobody will approve anything; the agent builds it, the tests pass, it ships, the way nobody approves a spreadsheet formula. A lot of software is about to become spreadsheet formulas. For everything where a wrong deploy costs money, data, or trust, a human will still sign, but on the spec, the held-out tests, and an independent review, not the diff. The line-by-line read will be gone in both cases. The reviewer running on a different model family than the author will be a compliance norm in the second category, the way separation of duties is in finance, and someone will sell the audit. The interesting question, and the one I cannot predict, is where each company draws the line between the two categories, because the pressure to move things into the first one will be enormous and the evidence that they belong there will be thin.

Why a human signature survives at all in the second category, when the models will be much better than they are now: because the requirements are never actually given. Brooks said in 1986 that the hardest part of building software is deciding precisely what to build, and nothing in the SpecBench data suggests that changed. When the agent hits an ambiguity it either guesses, and someone finds out later, or it asks, and the person answering is doing the approval under a different name. Whatever defines correct for the agent is also its optimization target, so the definition has to come from outside the loop, and the chain of outside checkers terminates in a person who says that is what I meant. And someone is liable. Companies do not remove the signature when the model improves; they remove it when the liability moves, and there is no mechanism for that yet. Anthropic’s own review tool does not approve PRs, inside Anthropic.

By 2030, the title “software engineer” will still exist and US employment under it will be roughly flat against 2022, not the 10% growth BLS projects and not the collapse the 2027 crowd predicted. The median holder will be older, more senior, and spending most of their time on specification, verification, and operations. Visser is probably right that the 2010 to 2020 shortage was the anomaly, and pay compression at the top is likely. There will be a visible shortage of people who can tell whether a system is correct, and it will be traced to the hiring decisions of 2023 to 2027: if the on-ramp stays where it is for five years, the 2030 cohort with five years of experience is a third the size it should be. A handful of companies will have rebuilt apprenticeships and will hold a structural advantage because of it. Most will be trying to hire their way out and failing.

The amount of software in the world, and the number of people and communities it serves, will be far larger than in 2022, and most of it will be built by people who never held the title: founders, analysts, scientists, operators, and hobbyists assembling blocks. The number of people writing software for a living, counted broadly enough to include them, will be substantially higher than in 2022 even as the profession stays flat. This is the spreadsheet outcome, not the teller outcome, and it is the one I am most confident about because it is already visible in both the venture data and the adoption curves of the blocks themselves.

The complementarity is not permanent, and I do not know when it breaks. METR’s horizon is doubling every four to five months on clean tasks. The tellers had thirty years. I would not bet on thirty and I would not bet on three. The capability curve is steeper than any prior wave and the messiness of real systems is a bigger buffer than benchmarks suggest, and I do not have a model that resolves those two facts. Amodei’s “country of geniuses in a datacenter” might arrive, and the physical-world bottlenecks he cites are much weaker for software than for biology, which is exactly why coding went first. When it does, the sequence is the one already visible: the diff, then the spec, then the behavior, then the outcome, each step a human checking something smaller and closer to what they actually wanted. The step that does not automate is wanting something and living with the consequences, because that is not a task, it is the reason the software exists.

Whether the transition is cruel to the people in the execution layer, the way every prior one was, is not a technology question and I am not going to pretend it is. It depends on whether the industry treats the on-ramp as a shared responsibility or a cost, and right now it is treating it as a cost. I would like to be wrong about that. I am not predicting that I will be.

What would change my mind: if entry-level developer hiring is still down 60% or more in 2028 and senior postings have started falling too, the complementarity broke early and I was wrong about the shape. If METR’s horizon passes a working week at 80% reliability on messy tasks, the spec layer is next and the timeline compresses. If the venture launch effect reverses once the AI-native founders hit their second and third years, the demand elasticity I am leaning on was a mirage. I will check all three against this post and say so.

What I am actually doing about it

Not advice, just what I have concluded for myself.

I am treating agent output as untrusted by default, the same way I treat any PR from someone I have not worked with. Not because the models are bad. Because the cost of my review going to zero is the entire failure mode in the data. When I do stop reading the diff, it will be because I have a held-out test or a spec doing the checking, not because I got tired.

I am spending more time on the layer above the code: the data model, the failure modes, the runbook, the thing that pages at 3am. That is where the leverage is and it is where the agents are weakest right now.

I am keeping agent session transcripts. Willison’s point that the work increasingly is the session, and that the failures in it are where the value is, matches my experience. A commit tells you what changed. The transcript tells you what was tried and rejected.

I am running my own models and writing my own small agents, not because I need to, but because Visser is right that not understanding the tool you are managing is a disservice to yourself.

I am reproducing my own work. Hashimoto’s account of how he went from skeptic to power user has a step in the middle that I think is the whole thing: he did every commit by hand, then made an agent produce the same result without letting it see his solution, and compared.65 It was slow and it was where his expertise came from. A colleague recently asked me to do exactly this with a fix he had shipped, not because he doubted the fix, but because he wanted an independent reproduction to find the flaw in his own process if there was one. That is the instinct the review section is about, arriving from a person instead of a paper, and I am adopting it.

I am watching the junior hiring numbers more than the benchmark numbers. The benchmarks tell you what the models can do. The hiring numbers tell you what the industry has decided to do about it, and right now the industry has decided to stop growing the next generation and hope someone else deals with it. That decision will show up in the data long before any benchmark does.

And I am trying to keep my eyes on the activity rather than the profession. The profession is where my paycheck comes from, so I will keep watching it. But the thing I actually care about, the thing that got me into this, is making something work that did not work before and understanding why. There is about to be more of that in the world than at any point in the history of the field, done by more people, most of whom will never call themselves engineers. I am not sure how the title does. I am fairly sure the work does fine.

– Siddharth

  1. Stack Overflow, 2025 Developer Survey: AI, July 2025. 49,000+ respondents, self-selected online sample. ↩ ↩2 ↩3

  2. Google Cloud, 2025 DORA State of AI-assisted Software Development, September 2025. About 5,000 survey respondents; correlational. ↩ ↩2

  3. Stack Overflow, Agents on a leash: agentic AI remains mostly monitored at work, May 2026. 1,100 respondents. ↩

  4. Forbes, Cursor hits $4 billion in annualized revenue, June 2026. Run-rate, not GAAP revenue. ↩

  5. Anthropic, Series G funding announcement, February 2026. ↩

  6. OpenAI, Codex for knowledge work, 2026. Vendor-reported weekly users. ↩

  7. The Verge, Google says 75 percent of all its new code is AI-generated, April 2026, quoting Sundar Pichai’s Cloud Next post. No public definition of the denominator. ↩

  8. Tom’s Hardware, Anthropic says Claude now writes more than 80 percent of its merged code, June 2026, reporting an Anthropic Institute analysis. The same report notes that code volume overstates productivity and that human review is the bottleneck. ↩ ↩2

  9. Cointelegraph, Over 95% of Coinbase’s code is now written with AI, July 2026. CEO statement. ↩

  10. Forbes, AI agents wrote 80% of Karpathy’s code, March 2026. ↩

  11. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025. Paper at arXiv:2507.09089. 16 developers, 246 tasks, 95% CI on the slowdown +2% to +39%. ↩

  12. METR, Uplift update, February 2026. 57 developers, 143 repos, 800+ tasks. METR calls the result “very weak evidence” and is retiring the design. ↩

  13. Paradis et al., How much does AI impact development speed? An enterprise-based randomized controlled trial, ICSE-SEIP 2025. 96 Google engineers, one task. ↩

  14. Vasilescu et al., AI Writes Faster Than Humans Can Review, July 2026. Observational, single company, adoption not randomized. ↩

  15. TechTarget, Google DORA: software delivery caught up to AI coding tools, covering the 2024 DORA findings. ↩

  16. Gergely Orosz, The impact of AI on software engineers in 2026, Pragmatic Engineer, 2026. Self-selected newsletter audience. See also his Six Predictions piece, February 2026. ↩

  17. Waydev, DORA pauses the annual survey, September 2026. I could not find the primary dora.dev announcement. DORA did publish a smaller ROI of AI-assisted Software Development report in May 2026. ↩

  18. GitClear, The Maintainability Gap, June 2026. Vendor research; sample is GitClear customers plus public repos. ↩

  19. Veracode, 2026 GenAI Code Security Report, 2026, and the 2025 report, July 2025. Vendor research on raw model output, 80 tasks, 100+ models. ↩

  20. Scale AI, SWE-bench Pro V2, September 22, 2026. 642 public tasks, 272 private, network-locked. ↩

  21. METR, Time Horizons and Time Horizon 1.1, January 2026. METR notes measurements above 16 hours are unreliable with the current task suite. ↩

  22. InfoQ, Anthropic Introduces Agent-Based Code Review for Claude Code, April 2026, reporting Anthropic’s internal figures. Vendor data; the “under 1% incorrect” figure is precision as judged by Anthropic engineers, not recall. The $15 to $25 per PR figure is from the same coverage. ↩ ↩2 ↩3

  23. McIntosh, Kamei, Adams, Hassan, The Impact of Code Review Coverage and Code Review Participation on Software Quality, MSR 2014. Qt, VTK, ITK. ↩

  24. Let’s Data Science, Claude Code team details its internal review and agent workflows, July 2026. Secondary source; I could not find the 65% figure in Anthropic’s own Claude Tag announcement. ↩

  25. Li et al., SWR-Bench: Assessing LLM Performance in Real-World Code Review Comment Generation, v2 June 2026. 1,000 manually verified PRs with full project context. Per-issue-count breakdown is Table 5. ↩

  26. Studying Quality Improvements Recommended via Manual and Automated Code Review, February 2026. ↩

  27. IOV Labs, The Judge in the Mirror: self-preference bias in LLM-as-judge, 2026. See also Self-Preference Bias in Rubric-Based Evaluation, April 2026. ↩

  28. Auditing LLM-as-a-Judge for Software Engineering, April 2026. ↩

  29. Srikanth, Wu, Jiang (Weco AI), Measuring Reward Hacking in Long-Horizon Coding Agents, May 2026. 30 tasks from a JSON parser to an OS kernel. Vendor-affiliated authors. ↩

  30. EvilGenie: A Reward Hacking Benchmark, 2025 to 2026. Tests Codex, Claude Code, and Gemini CLI. ↩

  31. Cursor, Updates to Bugbot for Teams and Individuals, May 2026. ↩

  32. Codalio, Read 93 Lines, Skip 1,000, July 2026, summarizing the Hacker News Show HN thread. Codalio sells a specification product; the underlying Lean project is the primary source. ↩

  33. A benchmark for vericoding: formally verified program synthesis, 2025. The 68% to 96% figure is for pure Dafny verification tasks, which are much narrower than general software. ↩

  34. Brynjolfsson, Chandar, Chen, Canaries in the Coal Mine, August 2026 update, Stanford Digital Economy Lab. Original August 2025 paper. ADP payroll data; descriptive, not causal. ↩

  35. SignalFire, State of Tech Talent 2026, June 2026. Profile-based data; undercounts some hires. ↩

  36. Federal Reserve Bank of New York, The Labor Market for Recent College Graduates. Major-level figures lag one to two years. ↩

  37. Indeed Hiring Lab, AI and Job Postings: From Destruction to Creation?, July 2026. Postings, not hires; Indeed flags the Claude Code timing as correlation. ↩

  38. Indeed Hiring Lab, The Labor Market Is Tilting Toward Seniority, July 2026. ↩

  39. BLS, Occupational Outlook Handbook: Software Developers, QA Analysts, and Testers, 2025 to 2035 projection. ↩

  40. TechCrunch, The running list: major tech layoffs in 2026 where employers cited AI, July 2026, citing FT counts. ↩ ↩2 ↩3

  41. CNBC, Amazon, Microsoft and more cite AI for 2025 layoffs, December 2025, citing Challenger, Gray & Christmas. ↩

  42. Fortune, Benioff on AI agents and support layoffs, September 2025. ↩

  43. Bloomberg, Klarna turns from AI to real person customer service, May 2025. ↩

  44. CNBC, Employers who laid off workers for AI are reversing their decisions, July 2026, covering the Robert Half survey and Gartner forecast. Surveys of HR leaders, small samples. ↩

  45. Business Insider, Anthropic CEO: AI will write 90% of code in 3 to 6 months, March 2025. ↩

  46. Fortune, Dario Amodei on the Jevons paradox and white-collar jobs, May 2026. ↩

  47. Hacker News, comment 42857721, January 2025, in the DeepSeek R1 thread. ↩

  48. Fortune, Claude Code creator says the software engineer title will go away, February 2026. ↩

  49. Martin Fowler, Future of Software Development retreat notes, February 2026, and fragment of July 6, 2026 for the “debate is over” quote. ↩

  50. JetBrains, Introducing JetBrains Air, September 22, 2026. Product announcement; read with that in mind. ↩ ↩2

  51. James Bessen, Toil and Technology, IMF Finance & Development, March 2015. ↩

  52. BLS, Occupational Outlook Handbook: Tellers, 2025 to 2035 projection. ↩

  53. Business Insider, What Excel and ATMs tell us about AI and jobs, October 2023, citing Morgan Stanley analysis of BLS data. ↩

  54. BLS, Occupational Employment Statistics, May 2000 national release. Programmers 530,730; applications engineers 374,640; systems software engineers 264,610. ↩

  55. BLS Occupational Employment Statistics, May 2015 national estimates, via the OES archive. Occupation definitions changed in 2010 and 2018, so the 2000 to 2015 comparison is approximate. ↩

  56. Thoughtworks, The Future of Software Engineering, Europe 2026, June 2026. ↩

  57. O’Brien, Bair, Venkataramani, Death by Robots? Automation and Working-Age Mortality in the United States, Demography 59(2), 2022. Uses exogenous variation in robot adoption for causal inference. ↩

  58. Minneapolis Fed, “Deaths of despair” and economic opportunity, 2023, summarizing Case and Deaton’s Deaths of Despair and the Future of Capitalism, 2020. ↩

  59. USC Schaeffer Center, What is Driving Deaths of Despair?, 2025, quoting Case and Deaton on other developed countries. They attribute the US difference largely to healthcare costs, not only labor policy. ↩

  60. Acemoglu and Johnson, Power and Progress, 2023. The “nothing automatic” quote via Vox, July 2023. ↩

  61. Acemoglu and Johnson, Building Pro-Worker Artificial Intelligence, NBER Working Paper 34854, February 2026. ↩

  62. Mitchell Hashimoto, The Building Block Economy, April 2026. He notes the Ghostty and libghostty numbers are aggregates from update checks and integrator reports, not precise telemetry. ↩

  63. Cao et al., AI Coding Tools and Digital Entrepreneurship: The Role of Software Expertise, v3 September 2026. Product-category exposure design; observational. ↩

  64. Forbes, Why AI Agent Startups Are Becoming The New Solo-Founder Playbook, August 2026. I could not trace the 23.7% to 36.3% figure to a primary dataset; treat it as indicative. ↩

  65. Mitchell Hashimoto, My AI Adoption Journey, February 2026. The reproduce-your-own-work discipline is Step 2 of six. ↩ ↩2