Back to blog
· 9 min read

Why 10x Faster Coding Isn't 10x Faster Shipping

Make the coding ten times faster and a ten-hour feature still takes five and a half. The slowest step sets the pace, and context leaks at the handoffs.

A machine can only run as fast as its slowest part. A factory works the same way.

Picture a bottling line with three stations. One fills the bottles, one caps them and one puts on labels. Say the filler can do 600 bottles a minute, the labeller 600, and the capper only 200. The line makes 200 bottles a minute. Buy a new filler that does 1,000 a minute, and the line still makes 200. The only thing that changes is the pile of open bottles waiting in front of the capper.

A bottling line with three stations. The new filler fills 1,000 a minute. The capper, the slowest station, caps 200 a minute. The labeller labels 600 a minute. A pile of open bottles waits between the filler and the capper. The line makes 200 a minute. A line runs only as fast as its slowest station.

A software team is a production line too, and AI tools have just given it a much faster filler. When Arpit Bhayani posted about Amdahl’s law and why faster coding isn’t making software ship ten times faster, more than a hundred people replied. Many of them described the same thing. The code got faster. The release did not.

I think there are two reasons. The work waits, and some of what was meant gets lost. Both happen in the same place: the handoff, when work passes from one team to the next. To see both, I’ll follow one made-up feature through the whole post: automatic refunds in an online store.

Five hours that don’t move

Amdahl’s law comes from a 1967 paper by Gene Amdahl about adding processors to a computer. The part of a job you can’t speed up puts a limit on the whole job.

The refund feature takes ten hours from request to release. Five hours are writing code. The other five are everything around the code: deciding what is wanted, reviewing, testing and releasing, each usually done by someone else. Now make the coding ten times faster and leave everything else alone.

Stacked bars for the refund feature. At 1x: 5 hours of coding plus 5 hours of everything else, 10 hours. At 2x: 2.5 plus 5, 7.5 hours. At 10x: 30 minutes plus 5 hours, 5.5 hours. Instant: 0 plus 5, 5 hours. The five hours that don't move.

The feature ships four and a half hours sooner. That is a real gain, but the whole job is only 1.82 times as fast. Even if the code appeared instantly, it would still take five hours.

The fifty-fifty split is my assumption. If coding was 90% of your time, a 10x tool would make the whole job more than five times faster; at 30%, as in Arpit’s example, only 1.37x. Most teams have never measured their split.

One fast station, many slow ones

Now give the backend team AI tools, and it gets much faster. The client work, the testing and the release stay at the same speed.

But the faster backend work doesn’t make the feature faster. It arrives earlier and waits, like open bottles in front of the capper. Then the client work waits for DevOps to release it. The feature can’t ship until the slowest team is done.

Across the whole development cycle, it gets worse than the chart. A feature goes through requirements, backend, client, testing, test automation, the CI/CD pipeline and release. Some of these steps happen side by side. Backend and client work often do, and the feature is ready only when both are done, so the finish time is the time of the slower track.

The other steps happen one after another, and each one adds its own time and its own waiting. If the refund feature’s backend is done in an afternoon, the client takes a week, testing and automation take three days, and the pipeline and release take two more, the feature takes about two weeks.

Review is often the first slow step. Generating code takes minutes, but someone still has to read it, and reading code you didn’t write takes longer than writing it with AI. Testing is slow because a tester who joins at the end has to learn the feature from the same thin ticket, and can miss a detail that mattered. The pipeline is slow because one failure sends the change back to the start. A change that took ten minutes to write can wait half a day for a green build.

Across many features, this is the bottling line again, and waiting grows faster than people expect. If the next team can take on four changes a day and starts getting six, two more pile up every day. By the end of a week, ten changes are waiting that weren’t there on Monday.

Google’s DORA research looked at what happens after the code when AI speeds up the coding, in its 2025 report on AI in software teams. More AI use went with shipping more, but also with less stable delivery. Google’s announcement put it this way: “AI doesn’t fix a team; it amplifies what’s already there.” Without strong automated testing and fast feedback, more changes meant more things breaking.

Speed up the coding, and every station after it becomes a bigger share of the time. On many teams, everything after the code is slow.

What gets lost between teams

Waiting is the first cost of a handoff. The second is what gets lost on the way.

There is a party game called Telephone Charades. People stand in a line facing away from each other. The first person acts something out for the second, who copies it for the third, and so on. Nobody after the first person sees the original. By the end of the line, the act has turned into something else.

Telephone Charades: four stick figures in a line. Person 1 says the original act. Persons 2 and 3 copy what they saw. Person 4 ends with something else. Nobody after the first person sees the original.

A feature on a split team goes through a line like that. The customer explains what they need, and someone writes it down. Backend, client, testing and DevOps each read it again for their own part. Every handoff squeezes an idea that is clear in one person’s head into a document or a ticket, and the next person rebuilds it from their own context. At each step, some of the context can drop out.

The person asking for the refund feature wants refunds to be automatic only if the order hasn’t shipped yet. Somewhere between the meeting, the document and the tickets, that condition falls off. The ticket just says “make refunds automatic.”

That is the kind of detail that goes first. In the 1930s, the psychologist Frederic Bartlett had people retell a story one after another. Details that seemed unusual were dropped or swapped for something more familiar. “Make refunds automatic” is the familiar version.

Two panels. What the requester said: refunds automatic, only if not shipped yet, built as the right feature. What the ticket said: make refunds automatic, built as another review cycle. The same feature, written down two ways.

A developer with AI tools can build that ticket perfectly in no time. The code does exactly what the ticket says. Then someone in testing notices that orders already on a truck are getting refunded. Now there is another explanation, another fix, another review and another round of tests, across several teams.

This doesn’t only happen with made-up refund features. In 1999, NASA lost the Mars Climate Orbiter. One team’s ground software reported thruster data in pound-seconds, and the navigation team’s software read the numbers as newton-seconds, the unit the written interface specification required. The spacecraft arrived about 170 kilometres lower than planned and was lost. The investigation board found more than a unit mistake. It found a navigation team that was somewhat isolated from the other teams and not communicating its concerns. The requirement was written down. That wasn’t enough when the teams on either side weren’t talking.

Not every handoff loses something. Sometimes the next person catches a case nobody thought about. But a lost condition sends the feature back through all of those slow stations again, and faster coding only gets you there sooner.

Splitting the work made sense, once

None of this means split teams were a mistake. In 1776, Adam Smith described a pin factory where ten workers, each doing one or two steps, could make “upwards of forty-eight thousand pins in a day.” Working alone, Smith wrote, they “certainly could not each of them have made twenty, perhaps not one pin in a day.” Splitting the work is how factories got fast.

Software teams copied that. One person couldn’t be good at all of it, so the work was split up, and each group got very good at its own part: product, backend, client, testing and DevOps. The handoffs lost context and the queues cost time, but the gains from specialists were bigger than those losses. For a long time, it was the only practical way to build large software.

AI changes that trade. When one person can write good code across the backend and the client, write the tests and set up the pipeline, the gain from splitting the work gets smaller. The losses stay the same. A study at a large telecom company found that work split across sites took about two and a half times as long as similar work done in one place, mostly because more people were involved. It looked at teams in different places, but the cause it found applies to any split: more people who have to stay in sync. With five separate groups, there are ten pairs that may need to sort something out between them. The old method fit the old costs. The costs have changed, and I think the method should change with them.

Some companies have already started. Satya Nadella said on the All-In podcast in January 2026 that LinkedIn took its product managers, designers, frontend engineers and backend engineers and “combined them.” In Nadella’s words, “they’re all full-stack builders.”

Not everyone agrees with going that far. Ravi Mehta wrote a case against the full-stack builder: “AI lets anyone on a product team build almost anything. That doesn’t make the team obsolete. It makes the team more important.” I agree with part of that. A small team still needs people with deep skill. It just no longer needs a separate group for every step.

A small team with the whole context

So the bigger gain is in changing the line itself. Give the whole context to a small team, and let it move fast without losing it. Small teams that own a feature end to end aren’t new. What AI changes is how much of the work a few people can now cover.

By a small team I mean a few people who own one feature from the requirement to the release. They all hear what the customer actually needs, including the “only if the order hasn’t shipped yet” part, and they make the decisions about the feature together. The team holds the complete context, so it can design the whole thing properly: the data, the screens, the tests and the release. It owns the feature, not the whole product. Shared systems, like payments or sign-in, still have their own owners.

The tests get written from the real requirement at the start, including a test with an order that has already shipped. The team owns its pipeline, so a slow build is something they can fix themselves instead of a ticket for another group. There are fewer handoffs, so there is less to lose, and fewer queues to wait in.

A small team with the whole context at the centre, with spokes to the data, the screens, the tests and the release. One team designs the whole thing.

Some things still only show up when someone uses it. With a working version in an afternoon, the team can show it to the person who asked for it the same day. That person can try a refund on an order where one item has shipped and one hasn’t, and ask, “What happens here?” The question gets answered in a conversation instead of a review cycle.

Eliyahu Goldratt told a story about keeping a line at one pace in The Goal. On a scout hike, the troop kept stretching out and stopping to wait for Herbie, the slowest boy. So they put Herbie at the front, where the line moved at his pace without gaps, and shared out the heavy things in his pack among the others. The whole troop got faster.

A small team can do the same. It fixes the slowest step first and moves load off it. When the client work is the slow step, the people who finished the backend help with it. They may not write the final screens, but with AI they can build a rough version, connect it to the backend and write the end-to-end tests, so the client specialist spends their time on the parts that need their skill. The aim is every step moving at about the same pace. Split teams find it harder to carry each other’s packs. They can help, but separate priorities and separate ownership get in the way.

This doesn’t remove care. Someone still has to review the work, test it and own it once it ships. What changes is how many people that takes. With AI, the same few people can write the tests, set up the pipeline and handle the release, work that used to need a separate person at each step. That needs a change in mindset more than a change in tools. Things that weren’t possible for a small team before are possible now, and everyone on the team has to start working as if they are. A small team can still be careful. It just doesn’t have to pass the context through five groups to do it.

For a long time, the way to speed up a production line was to buy a faster machine for one station and live with the handoffs between them. AI has given software teams a much faster machine. It has also made a different fix possible: fewer stations, and a small team that can run most of the line itself, at one pace, with the whole context in hand. That is the change I think is worth making.

Sources

Co-written with AI. Credit the prose, blame the opinions.