AI coding has its Ford moment. Where’s the Toyota part?

Writing code got cheap but the expensive parts moved somewhere else: deciding what to build, reviewing what came back, getting separate pieces to fit, and finding out whether the thing worked once it shipped.

I wondered if that was just my own small experiments, so I looked at what larger studies say. Faros AI's Q2 2026 report draws on two years of engineering telemetry from about 22,000 developers across 4,000 teams, comparing each company's low-AI and high-AI periods. When AI adoption was high, teams completed 66% more epics. Deployments per week went down, though, median review time grew about five times, and incidents per pull request more than tripled.

Faros published its first report on this a year earlier, and some of the measures line up.

Output kept climbing. The cost of checking it climbed faster. Bugs per developer went from a small bump to more than half again, and review time went from nearly doubling to roughly five times. Pull requests grew less than the year before, which might mean teams are learning to keep changes smaller, but the checking still is not keeping up.

CircleCI's 2026 report, covering about 28.7 million CI workflows, shows a similar shape. Activity was up 59% year over year. For the median team, though, throughput on the main branch fell 7%, and the main-branch success rate dropped to its lowest point in more than five years.

Faros's Q3 2026 follow-up, The Speed Trap, adds a detail that matters for the rest of this post. Delivery is speeding up again, but partly because teams are skipping review, with the cost showing up later in QA and operations.

The more careful studies point the same way. Google's DORA team surveyed nearly 5,000 technology professionals and concluded that AI acts as an amplifier: it makes strong engineering systems stronger and weak ones worse. Its 2026 follow-up, The ROI of AI-assisted Software Development, names the cost in between a "verification tax," the extra effort to confirm that AI-written code is correct, secure and fits the design. Stack Overflow's 2026 Developer Survey, with more than 30,000 responses, shows the same tension from the developer's side: 66% use coding assistants or agents, yet only 6.6% would trust AI output on an important decision without checking it.

METR ran one of the few randomized trials. In early 2025, experienced open-source developers took 19% longer on tasks when allowed to use AI, while believing they had been about 20% faster. METR's February 2026 update suggests developers are probably faster now, but calls its own evidence on the size of that gain very weak.

Read together, the number of things being made went up a lot. The number of things finished and working did not keep pace. In a warehouse or a factory, that gap has a name: inventory. It sits between stations and it hides problems. That was the moment the factory comparison stopped feeling like a stretch to me.

Partly, yes. In 1913 Ford started moving the work past the workers, and within about a year the labor to build a Model T chassis fell from roughly twelve hours to 93 minutes. The recipe was standard work, interchangeable parts and a moving line. Agents give software a similar jump: a spec is the standard work, a clear interface is the interchangeable part, and you can run as many stations in parallel as your budget allows.

The same story carries a warning. Ford's line was built around one design, and the switch to the Model A in 1927 shut plants for months. Models change every few months, so a workflow wired tightly around today's tools may be its own Model T plant.

Toyota started from Ford's line. After touring Ford's River Rouge plant in the early 1950s, Eiji Toyoda and Taiichi Ohno built the Toyota Production System to keep quality from slipping as volume grew. Its habits are simple to state: stop the line the moment something is wrong, make only what the next step can use, build in checks so mistakes cannot pass quietly, keep the load even, and improve a little every cycle.

Each one maps onto agents almost directly, and if anything this half fits better than Ford's. Ohno called overproduction the worst kind of waste because it hides every other problem. Eleven pull requests a day that nobody has time to review looks like the same thing to me.

When I sketched how most teams I talk to use AI coding today, it looked like the diagram below. Agents push work forward as fast as they can. It piles up in front of the one step that still runs at human speed, which is review. Whatever slips through comes back later as rework, which shows up as more pull requests.

The version I keep sketching looks more like this. The same agents do the building, but a few things change around them. Work is pulled in only when there is room to check it. The pieces agree on their interfaces before anyone builds. Problems stop the line close to where they happen. And after something ships, someone asks whether it actually worked, and that answer feeds the next spec.

Stops seem to be the hardest part to get right. If every stop looks the same, a person either gets pinged for trivial things or an agent keeps retrying something it can never fix. Sorting stops into three kinds, each with its own rule, seems to help.

Ford's warning comes back here. If models change every few months, what should a team standardize on? The answer I keep landing on is the layers underneath the model. The model is the easiest part to swap. The harness (tools, sandboxes, permissions) decides what an agent can touch. The context (AGENTS.md, skills, specs, docs) decides what it knows about your codebase. And the codebase's own checks (types, tests, linters, CI) decide how quickly a wrong change gets caught. Every improvement to a lower layer helps every model, including the next one.

Context is the most important layer. Agents re-ask settled questions when decisions live in chat threads and people's heads instead of the repository. A simple rule helps: if it isn't in the repo, it isn't decided. A fresh agent with no chat history should be able to answer five things cold: what we are working toward, what is next, what has been decided, who approves what, and what it may do without asking. A new hire needs the same five answers.

I have read a few AI delivery plans from engineering consultancies this year. The better ones share three habits, shown below. Every step is plain code, an AI draft or a person's decision. A person is either a gate (work waits for them) or gives feedback (work keeps going).

Their tool stacks look alike too: Claude Code plus open tools such as OpenSpec or Spec Kit for specs, Superpowers for a spec, plan, execute routine, Matt Pocock's skills for grilling designs and writing tests first, and Caveman to cut token costs.

What I keep wondering about is the last step. Every AI-drafted change still gets the same pull-request review as handwritten code. That is safe, but if the Faros numbers are close, review is exactly where the time goes. And the cost being tracked is tokens, when cost per finished, working change might tell you more.

A lot of people are attacking pieces of this, and when I group what I have looked at by which part of the line it covers, it looks roughly like this.

The whole-line platforms are the ones to watch. 8090 raised a $135M Series A in June, led by Salesforce Ventures, for what it calls a software factory: requirements and blueprints written in plain language, with agents turning them into code. Factory, Lightsprint and others are going after the same idea from different directions. On the in-house side, Cloudflare has written about an AI spec reviewer that looked at hundreds of technical designs before implementation, and an AI code reviewer that blocked thousands of merges that broke their engineering standards.

Looking across all of it, a few things still seem missing to me:

• A shared measure. None of the factory vendors I looked at publish how often a change merges on the first attempt, or what a finished change costs end to end. Their numbers come from case studies and partner announcements, without a published method.
• Review capacity as a real limit. Most setups let agents start as much work as the budget allows, regardless of whether anyone can check it.
• Shared memory as infrastructure. Context still lives in chats and in people's heads.
• Owners for stops. When something stops, it is often unclear who decides.
• Re-tuning when models change. Every new model shifts which steps are still needed. Few teams re-test their setup when one ships.
• The loop after release. Did the change do what we wanted, and does that answer reach the next spec?

Most AI dashboards I see count activity: pull requests opened, lines written, the share of code written by AI. Those are easy to produce and easy to game. Faros's numbers show why they mislead, since teams merged far more pull requests without delivering more. A factory would never judge a line by how many parts it started.

The KPI tree below is how I would set it up. Report the business outcome and DORA's delivery metrics, which gained a fifth measure in 2024: rework rate, the share of deployments that are unplanned fixes. Manage the team measures and levers underneath them. If review time and rework rate rise while pull request counts climb, the line is getting slower, not faster.

If I were running an engineering team today, these are the experiments I would start with.

1. Measure finished, working changes. Track the cost and human minutes behind each change that ships and stays shipped, and put rework rate next to your DORA metrics. Stop reporting pull request counts as progress.
2. Cap work in progress at review capacity. If review is the slowest step, more agents only make the queue longer. Pull new work in when someone can check it.
3. Tier review by risk. Let AI reviewers handle style, tests and routine bugs, and send people only where judgment matters: security, money, customer trust. Cloudflare sorts every merge request into trivial, lite or full review, and a trivial one costs about 20 cents.
4. Write your standards down where agents can read them. Rules, decisions and interfaces belong in the repo as plain MUST and SHOULD statements. Start each rule as advice and make it blocking once it proves itself. Cloudflare's Codex works this way, and its reviewer has held back about 16,000 merges.
5. Give every change a spec and a way to check itself. Anthropic's own advice is to give the agent a target it can verify, such as tests written first. 8090 goes further and keeps requirement, spec, code and test linked, so drift gets flagged instead of discovered a year later.
6. Close the loop, and re-tune when models change. After release, ask whether the change did what it was meant to and feed that into the next spec. When a new model ships, rerun a small test and try removing one step to see if it still earns its place.

I started with two questions and ended up with more. These are the ones I keep turning over:

If you are running agents on your team, I would like to compare notes.