Faster is a Feeling

AI makes developers faster. Faster developers need fewer colleagues. Fewer colleagues means a smaller bill. And the deadline can probably come forward a week.

It fits on a slide. It's also how you end up paying for the same work twice.

In short, the math ain't mathing.

Let's look at the process. I build. She tests. Each of us is a net, and together we catch enough. Squeeze us both, with more output expected from me and nobody replacing the tester who left, and a bug slips through both nets. It ships.

Weeks later it comes back as a client complaint. Someone has to find it, fix it, retest everything around it and deploy again, while the client wonders what else we missed.

Penny wise, pound foolish. The phrase predates AI by a few centuries and still fits.

Faster is a feeling

The whole slide (and perhaps management's entire presentation) rests on one promise: AI makes you faster.

METR tested that in 2025. Experienced developers expected AI to save them about a quarter of their time. They took 19% longer.

When asked how it went, they reckoned they'd been 20% faster. A later round with newer tools found a smaller effect, but the gap between feeling and stopwatch stayed. If the developers couldn't tell, an "AI adoption" dashboard has no chance.

Where the speed is real, it doesn't disappear. It travels. Faros AI tracked more than 10,000 developers. High-AI teams merged 98% more pull requests. Review time went up 91%. Bugs went up 9%. Delivery barely moved.

AI sped up one step in the chain. Every step after it now has more to get through.

The writing got faster. The checking got longer. And the checking has my friend's name on it.

Overload has numbers

Ask the people at the top, and 96% of executives expect AI to lift productivity. Ask the people at the desk, and 77% of those using it say it has added to their workload. Upwork found both in the same survey.

Somewhere between those two numbers sits every tester being asked to check twice as much in the same week.

Replaced by tokens

The slide's last line is always headcount.

If everyone is faster, the thinking goes, some of them must be spare. Yet the people who look spare are often the ones doing the checking, remembering the edge cases and catching what slips through.

Klarna learnt this in public. It let AI handle the work of about 700 customer service agents and stopped hiring. A year later its CEO admitted cost had carried too much weight. Quality had slipped. Humans were coming back.

Rehiring isn't free. And no token budget remembers why the donation form has that odd validation rule. The person who left does.

The plant that never stopped the line

GM's Fremont plant ran on one rule: never stop the line. Volume first, faults later. A union leader called its staff "the worst workforce in the automobile industry in the United States." GM closed it in 1982.

Two years later it reopened as NUMMI under Toyota's system, with about 85% of the same workers. One thing changed: any worker could pull the andon cord and stop production to fix a problem. Within about a year, GM's worst plant became its best.

Same people. Different conditions.

Back to Maastricht

I keep coming back to a talk that touched a bit of a nerve at PloneConf this year. A speaker argued that people who build with AI without learning to code don't care what they build. I disagreed then, and I still do.

But the AI-means-faster crowd is proving his point for him. Rush people, cut the reviewers, pile on output, and you get exactly the careless work he described. The carelessness is built into the conditions. The tool or the person takes the blame anyway, as Fremont's workers did for years until Toyota rehired them.

Care takes time. It takes a second pair of eyes that isn't stretched across three projects.

Let someone pull the cord

I like AI. I use it every day, and I've built things with it I couldn't have built alone. I have no interest in writing an anti-AI article. My quarrel is with the rush.

If AI saves your team time, don't pour all of it straight back into output. Spend some of it on care. Keep the tester. Fill the role that's been sitting empty. And give everyone in the chain, developer and QA alike, a cord to pull when something looks wrong.

The bug that ships comes back. It just comes back with interest.