Vladi Iancu

CTO · I write about engineering leadership, systems, and staying human

The Software Industrial Revolution

Writing code got cheap. Reading it didn't.

aiai-adoptionengineering-culture

Published

Monday, August 17, 2026. GitHub went down for nearly eight hours. I wasn't affected. I wasn't working at the time, nothing of ours was running on GitHub right then, and some of our code still lives on Bitbucket anyway. But my LinkedIn feed was full of complaints from people in my network.

There was a bug in the mix. A retry storm, which pushed Copilot's token service from its usual 7,000-9,000 requests per second to between 70,000 and 100,000, amplified the outage. According to GitHub's own write-up, traffic had reached a new peak and a critical infrastructure component failed to scale.

And GitHub named the pressure. Monthly commits went from 1.4 billion in April 2026 to 2.9 billion in August. In their words: "That growth explains the pressure on our systems, but it does not excuse these outages."

Four months. Double the commits. GitHub doesn't say how much of that is agents. But it's hard to look at the rest of the data and think it's a coincidence.

The factory floor

It's not just GitHub. On OpenRouter, agentic token usage went up 14x between February and August 2026 — from about 0.51 trillion tokens to 7.3 trillion. Human-driven usage grew 2.8x over the same period.

The language changed too. Steve Yegge's Gas Town is a way of orchestrating 20-30 Claude Code instances at once, with a Mayor as "concierge and chief-of-staff" and polecats as on-demand workers. In a later essay he defines a dark factory as "any system in which coding agents are set up to work autonomously without humans watching."

I keep reading these descriptions and thinking about textile mills.

And it matches what I do every day. I describe the work, the AI writes the code, and I read what it wrote. Sometimes I change a line, but mostly I don't. At ialoc, we now write most new code — new modules, new services, new features — with help from LLMs. We still have ten years of PHP, Laravel and Ionic, written by hand long before I joined.

I'm not a historian

But the broad strokes are worth knowing.

Before the mills, cloth was a cottage business. Women spun, men wove, at home, with their children helping, setting their own pace. As spinning got mechanized, there was suddenly more yarn than weavers could handle, and weavers' wages rose.

Then came the power loom. Cartwright devised it in 1785. It took about 30 years and Horrocks's improvements, patented in 1813, to make it work. After that it went fast: over 12,000 power looms by 1820, 85,000 by 1833. There were 240,000 handloom weavers in 1830. By 1860 there were 10,000.

Animated chart, 1815–1860: power looms in Britain rise from about 12,000 in 1820 to 85,000 in 1833, while handloom weavers fall from 240,000 in 1830 to 10,000 in 1860. Source: Gregory Clark.

Handloom weavers had earned twice as much as factory workers. By 1820, they earned 25% less. Between 1800 and 1840, GDP per worker rose 37% while real wages stagnated and the profit rate doubled. Workers waited decades to see the gains.

The economist Gregory Clark describes the logic of the whole era as a constant search for machines that demanded less and less training and skill. The skill moved out of the worker and into the machine.

That's the comparison I usually hear: the machine absorbs the craft knowledge, and the worker becomes cheaper to replace.

This time, the machine is the junior

In the mills, the machine replaced the skilled worker and the untrained worker tended the machine.

In software, it's the other way around. The machine is the untrained, eager producer. Addy Osmani described it as having a very eager junior developer on your team. It writes fast. It doesn't get tired. It is often almost right.

The scarce skill isn't producing code anymore. Simon Willison put it better than I can:

"Almost anyone can prompt an LLM to generate a thousand-line patch and submit it for code review. That's no longer valuable."

And: "Your job is to deliver code you have proven to work."

Meanwhile, the hiring market has tilted heavily toward experienced workers. Stanford's Digital Economy Lab found that employment of 22-25-year-olds in AI-exposed jobs is 19% below their less-exposed peers, driven by less hiring rather than firing — while "experienced workers show no comparable gap." In Q1 2026, senior roles were 69.3% of US software development job postings on Indeed. Entry-level roles were 4.5%. SignalFire, a VC firm, reports new-grad hiring down about 65% at big tech compared to 2019.

The people with the most experience also trust the machine the least. In the 2025 Stack Overflow survey, developers with 10+ years had the lowest "highly trust" rate for AI output (2.5%) and the highest "highly distrust" rate (21%). The most common frustration, for 66% of developers: answers that are "almost right, but not quite."

Field experiments at Microsoft, Accenture and a Fortune 100 company found that less experienced developers had higher adoption rates and greater productivity gains. In those 2022-23 Copilot trials, juniors got the bigger speed boost.

Speed is what got cheap. What I think the market is paying for is judgement. Someone who can look at a thousand-line patch and say "no."

Seniors are made out of juniors. If the junior rung disappears, where do the next people who can say "no" come from? The mills never had to answer that. They didn't need the weavers back.

Waiting for review

LinearB looked at 8.1 million pull requests (vendor data, but a lot of it). AI-generated PRs wait more than 16 hours on average before a reviewer picks them up, against about 200 minutes for unassisted ones. Only 32.7% get merged within 30 days, against 84.5%. AI-assisted PRs are also about two and a half times larger.

Animated diagram: three AI agent machines drop pull requests onto a conveyor, with AI PRs drawn about 2.5 times larger than human ones. A single reviewer handles one PR at a time while the rest pile up in a growing queue. AI PRs wait 16h+ to be picked up vs ~200 minutes, and 32.7% merge within 30 days vs 84.5%. Source: LinearB, 8.1M PRs.

Faros AI's 2026 telemetry across 22,000 developers (vendor data, correlational) shows median time in review up 441.5% and PRs merged with no review at all up 31.3% — while task throughput went up 33.7%.

Google's DORA research tells a similar story from a different angle. In 2024, every 25% increase in AI adoption was associated with an estimated 1.5% drop in delivery throughput and a 7.2% drop in delivery stability. By 2025, throughput had recovered — but stability was still hurt. Their explanation: "Without robust control systems, like strong automated testing… an increase in change volume leads to instability."

GitHub's own lesson from August reads the same way. They committed to "stronger testing, safer rollouts, better observability, and more effective alerting."

One more detail from LinearB. Once someone actually picks up an AI-generated PR, the review goes faster than for a human one — about 194 minutes against 252. The PRs that get picked up may be the easier ones, and two-thirds never merge at all. The queue looks like the bigger problem.

The constraint on a software factory isn't how much code it can write. It's how much of the code someone is still willing and able to review.

The soil

The Green Revolution was built on Norman Borlaug's wheat breeding in Mexico: fertilizers, pesticides, irrigation, mouldboard ploughs and high-yield varieties. From the 1960s, it spread fast, and world cereal yields went from 1.4 to 2.7 tonnes per hectare between the early 1960s and 1989-91. Borlaug's work is credited with saving as many as a billion people from famine.

I don't want to lose sight of that when comparing it to what happened to the soil.

And yet. On an FAO platform, soil scientist Boris Boincean puts it bluntly: "we have replaced green agriculture with 'black agriculture'" — farming that runs on non-renewable energy, at the cost of soil fertility. Long-term experiments in Moldova show the initial yield increases followed by stabilization, then decrease. His measure of what's being lost: "Soil organic matter is the integral index of soil fertility." In Haryana, India, a Green Revolution success story, about 60% of the land faced soil degradation by 2000.

Software doesn't have a soil organic matter index. The closest thing I've found is GitClear's data. Across 623 million changes (correlational, not causal), moved code — the signature of refactoring — fell from 21% of changed lines in 2022 to 3.8% in 2026. Duplicated code blocks are up 81% since 2023, the highest they've ever measured. Their summary: "The throughput is real, but so is the debt it accrues."

Animated chart: a soil cross-section where the topsoil layer, standing for refactored (moved) code as a share of changed lines, thins from 21% in 2022 to 3.8% in 2026, next to a bar showing duplicated code blocks up 81% since 2023. Source: GitClear, 623M changes (correlational).

Addy Osmani has a name for the human side of it: comprehension debt, "the growing gap between how much code exists in your system and how much of it any human being genuinely understands."

I don't think the soil is dead.

What I see in my own circle — and this is an observation, not data — is that incidents get fixed faster with AI in the loop. I went looking for rigorous numbers on that and didn't find any. There's also a controlled experiment, "Echoes of AI", where developers maintaining AI-assisted code were no slower and produced no worse results. The authors "did not detect systematic maintainability advantages or disadvantages."

Maybe the soil is fine. Or maybe it's too early to see. In Moldova, yields rose, plateaued, then fell over 25 to 30 years of experiments.

But fixing an incident faster is not the same as paying down the debt that caused it.

The refactor button

The same machines that fill the codebase can also pay some of it down. Google ran 39 code migrations with 3 developers over 12 months; 74.45% of the code changes were generated by LLMs, and the total migration time was estimated to be 50% lower. Amazon's CEO claims AI cut Java upgrades from "typically 50 developer-days to just a few hours" — a CEO claim, so salt accordingly, but the direction matches.

I want some of the time we save on typing to go into making the code easier to understand. The migration examples suggest the tools can help with that too, though someone still has to check the changes.

I don't have a playbook for this. But I keep coming back to the reviewer waiting for another thousand-line patch. If we make their job harder every week, I don't see how we're going to keep this up.

Research assistance by my personal agent (powered by multiple different LLMs) and Claude.

Sources:

If you found this worth reading, share it on Bluesky or LinkedIn.