In September, a developer survey found that 42 percent of respondents now let AI write at least half of their code. A year earlier the figure was 12. Around the same time, a dataset of eight million pull requests showed that AI-generated ones get merged within a month roughly a third of the time, against about 85 percent for code people wrote themselves.

They come from different studies with different samples, so they don’t measure the same thing. Side by side, though, they point the same way. Producing code has stopped being the constraint. Something downstream has taken its place, and wherever that is, it’s where the job of a software developer is heading.

One note before the numbers. Everything quantitative here reflects the state of things at the end of September 2026, and I’d expect a fair part of it to look dated by spring. The argument shouldn’t lean on any single figure.

Where the line jams

The 42 percent comes from BairesDev’s Q3 Dev Barometer, a survey of 705 developers published on 14 September. The same survey says the time saved on writing code roughly doubled over the year, from about seven to thirteen hours a week, while 67 percent now spend more time reviewing AI output and 52 percent more time debugging problems it introduced. BairesDev sells nearshore development, so it’s worth reading the framing with that in mind, but the direction matches everything else I’ve read.

LinearB analysed 8.1 million pull requests from 4,800 teams and published the results in May. AI-generated pull requests merged within 30 days 32.7 percent of the time, unassisted ones about 84.5 percent. The AI-generated ones waited more than 16 hours before anyone picked them up, compared with around 200 minutes. AI-assisted pull requests were also two and a half times larger at the 75th percentile, over 400 lines against 157.

The figure in that report I keep returning to is a quieter one. At the 75th percentile, about 37 percent of an unassisted pull request is refactoring, reworking code that already exists. For AI-assisted pull requests it’s close to zero. The tools add code and almost never tidy up after themselves. LinearB sells engineering metrics, which is worth keeping in mind, though that particular number is hard to spin.

A dark factory, by accident

In January, Dan Shapiro sketched five levels of AI-assisted development and called the last one the Dark Factory, after the lights-out plants in manufacturing: a black box that turns specifications into software, a place where, in his words, humans are “neither needed nor welcome”. In practice that means nobody reads the diff. The phrase has become shorthand for where a lot of tooling is headed. Factory, whose coding agents are called Droids, raised 200 million dollars at a five billion dollar valuation on 15 September. It counts Nvidia and Blackstone among its customers, and its chief executive describes the market as moving from individual coding agents to software factories.

A study from Nicolaus Copernicus University in Toruń, published in May, looked at how pull requests written by coding agents actually get reviewed on GitHub. Most of them get no review at all. Where there is one, other AI agents dominate it rather than people. LinearB’s report makes a similar point more politely, warning that reviewers may be doing “superficial validation rather than thorough scrutiny”.

So in a lot of places, nobody reading the diff already describes the present. The difference is what fills the gap. A dark factory in Shapiro’s sense has replaced the human reader with machinery that does the reader’s job: specifications, test harnesses, policy checks, gates that fail loudly. What the data shows is a factory that went dark because the reader ran out of time. Where review still happens, it’s often another agent doing it.

What the factory looks like from the floor

The funding story and the delivery data sit some distance apart. In a second analysis published in August, LinearB found that even in its best-performing organisations, agents open only 4.7 percent of pull requests. In weaker organisations, agent-opened pull requests merge 37 percent of the time, against 79 percent in the strongest. Same kind of agent, very different outcome, depending on what surrounds it.

DORA has been making this point for a while. AI behaves like an amplifier: it makes healthy delivery systems faster and struggling ones worse. Their 2026 report on the return on AI investment describes a J-curve, where teams usually slow down before they speed up. Generated code becomes shipped code through solid tests and small changes, and through architecture that someone actually wrote down. Without those, most of the gain just turns into queue.

Some caution about what we think we know. METR’s 2025 study found experienced open-source developers 19 percent slower with AI tools, while those same developers believed they’d been 20 percent faster. In February, METR said it could no longer measure the effect reliably with that study design and now considers a speed-up likely. I take both halves seriously: the tools really are improving, and self-reported productivity is still a poor instrument for telling by how much.

What the job turns into

If generating code is cheap and verifying it is the constraint, the valuable work concentrates in a few places. You describe what should be built precisely enough that a machine can build it, and you limit what it’s allowed to touch. You check what it produced against something other than its own confidence. And you own the result when it fails in production at an inconvenient hour.

Senior engineers have always done this alongside writing code. It used to be the part around the edges. Now it’s becoming most of the job.

Bitkom’s working group on software engineering reached the same conclusion from the German industry side in June. Their report on the software world of 2036 describes the human contribution shifting towards defining goals, architecture, context, quality and responsibility, with judgement and the ability to refine machine output moving to the centre of the skill set.

Most of my own work over the past years has sat on that side of the line, whether or not anyone labelled it that way. On the platforms I’ve worked on, the parts I’d defend hardest are the guardrails rather than any feature: ArchUnit rules that fail the build the moment the domain core reaches for a framework, contract-first APIs where a drifting response shape simply doesn’t compile, integration tests that run against a real database instead of a mock that agrees with everything. When a new model launched in September with a headline claim about calibrated probabilities, the first thing I did was write a small probe to measure it rather than repeat it. Checking a claim before building on top of it is the skill I’d invest in for the next few years.

The part I can’t answer

I should be upfront that I have an interest in this conclusion. I’m a senior engineer, and “the work moves towards judgement and ownership” is a flattering story for people like me.

The data at the other end of the career ladder is less comfortable. The Stanford Digital Economy Lab’s paper on the employment effects of AI, revised in August, includes a chart for software developers specifically: employment for those aged 22 to 25 sits around 20 percent below its level in late 2022, while employment for mid-career and senior developers has grown. Its headline finding is broader, covering all AI-exposed occupations, but it points the same way. The routine work being automated is precisely the work juniors used to learn on: writing a lot of ordinary code and having someone more experienced take it apart in review. If that apprenticeship thins out, the supply of people able to own a software factory’s output shrinks a few years from now, at about the time demand for them peaks.

I don’t know who solves that, and I haven’t seen a convincing proposal yet. Of everything in this shift, it’s the part that worries me most.

What I’d look up again in six months

Three things would tell me whether this still holds by spring. Whether the merge-rate gap between AI-generated and human pull requests narrows, because if it does, verification got cheaper and my argument gets weaker. Whether refactoring starts to show up in AI-assisted work, which would change the long-term maintenance picture considerably. And whether employment for young developers keeps falling or levels off.

I’m a senior Java architect working on backend platforms, architecture and the quality gates that decide what ships. From January 2027 I’m available for freelance engagements. More about my work on marc-nuetzel.de.