The Wrong Half of Toyota
A note to myself on AI harness engineering and Kaizen — and why most people connecting these two are using the wrong half of Toyota's playbook.
Well, here's something that's been bothering me.
Everyone is suddenly noticing you can describe AI harness engineering with Toyota vocabulary.
PDCA. Continuous improvement. Eliminate waste. Standardize. Small steps. Stop the line. Martin Fowler did it in April without naming Toyota once. Paweł Puzio on Medium did it last spring with the master-prompt PDCA pattern. The Kaizen-Agent project on GitHub literally put "Kaizen" in the name. There's a piece called "Human-in-the-Loop Is Not a Roadblock. It Is Modern Kaizen." Intercom did a "Kaizen for the AI era" post. The kaizen.com people themselves wrote about the intersection.
It's tidy. It sounds smart. And almost everyone is reaching for the wrong half of Toyota.
That's what I want to write down for myself today. Not as a hot take. As something I want to be clear about before I start saying it out loud.
Quick recap of the two ideas
I'll keep this short because if you're reading this, you already know both pieces.
Harness engineering. Mitchell Hashimoto crystallized the term in February 2026 — "Agents aren't hard; the harness is hard." The harness is everything around an LLM that turns it from a text generator into something that ships work: tools, context, memory, policy, sandboxes, observability, evals. Seven layers in the canonical model. OpenAI's Codex team validated the thesis by shipping ~1M lines of code and 1,500 PRs with seven engineers steering a GPT-5 agent. Stripe's "Minions" merges 1,300+ PRs a week on similar infrastructure. The model is rented from a vendor by the token. The harness is capital your team builds and owns. That asymmetry is the only durable moat in agentic software right now.
Kaizen. "Change for the better." Taiichi Ohno's circle inside Toyota formalized it on top of W. E. Deming's PDCA cycle from 1950. The mechanism: every operational standard is labeled as a tentative best practice — provisional, not final. Improving the standard is everyone's job, not the QA team's. PDCA runs on top of live operations, not in a separate "improvement phase." Eliminate the seven wastes. Respect the people, because they are the ones running the loop.
The connection that the 2026 articles are making, in its most common form, sounds like this:
System prompts are standards. Make them tentative. Iterate them. Eliminate token waste. Run PDCA on the agent. Small steps. Don't try to fix everything at once.
This is correct. This is also where almost everyone stops. And it's the shallow version.
The half that Western Lean missed
I read a Takao Sakai essay in early May that I haven't been able to stop thinking about. Sakai is a Toyota insider — his father worked directly on reforming the Toyota Management System under chief engineer Ichiro Suzuki. He's not a consultant who studied the factory. He absorbed the system before he encountered it as theory.
His core argument: Western Lean writers spent thirty years studying the Toyota Production System (TPS), the factory, and they treated it as the whole story. It isn't. Toyota's system actually has two engines with different KPIs:
- TPDS — Toyota Product Development System. Output: the product model. KPI: development time, design trials per unit time, convergence to product-market fit. Generates gross profit per unit. Agile. Investments here are not waste.
- TPS — Toyota Production System. Output: replicated units. KPI: muda elimination, capital efficiency. Generates quantity. Lean.
Total gross profit = (TPDS-determined unit margin) × (TPS-replicated quantity).
Apply TPS waste-elimination to TPDS, Sakai says, and you commit a category error. A "lean" body-design team is a contradiction. Design trials are investments, not muda. The whole point of TPDS is to spend more iteration cycles up front so each replicated unit downstream carries higher margin.
Then he drops the number that sounded almost unbelievable to me when I first read it: inside Toyota, the gross profit split between TPDS and TPS in 1980 was 50:50. Today it's over 95:5. Even at Toyota, the factory is no longer where the value is made. Intellectual capital — design trials, chief-engineer wisdom, the integration of customer-budget reality into the product model — is now where the gross profit lives.
The split is unsourced in the essay, so I take it as directional rather than as fact. But directionally, it's clearly true for any software-touching industry.
Which half is your AI harness on?
This is the question nobody in the kaizen-for-AI corpus is asking.
Look at what a harness actually produces:
- Not units. Not throughput. The output is answer quality. Diff quality. Hallucination rate. The probability that a given task ends in a usable artifact instead of an apology.
- The cost structure is dominated by design trials — eval suites you build, system prompts you iterate, tool schemas you tune, sandboxes you harden. Token cost of inference is real but it's the wrong place to look for moat.
- The competitive advantage is intellectual capital. Two teams running the same model produce different products because their harnesses differ.
- The KPI is PMF convergence. How well the agent fits the actual job the user is trying to get done. Not tokens per second. That belongs to the inference team.
Read that list again with Sakai's two engines in mind. AI harness engineering belongs on the TPDS side of Toyota's diagram, not the TPS side.
Once you accept that, a lot of the kaizen-for-AI advice in circulation starts to look upside down.
What changes if you accept the reframe
I've been turning this over for a couple of weeks. Here are the implications I keep landing on.
1. Eval-suite building stops looking like overhead.
Treating your eval suite as "engineering overhead to minimize" is the same mistake Sakai documents when Western consultants tell product-development teams to "go lean." Eval iteration is design trials. Each one is an investment. If your management is asking why the team spent two weeks building golden datasets instead of "shipping features", you have a TPDS-as-TPS framing problem, not a productivity problem.
2. Your KPIs need to switch sides of the diagram.
The metrics I see most teams reach for — tokens per second, cost per inference call, latency P99 — are TPS metrics. They belong on the inference infrastructure team. The harness team's metrics are time-to-iteration, number of trials per week, eval delta per release, PMF convergence on real user tasks. If your harness dashboard is full of TPS metrics, you're measuring the wrong engine.
3. The "Chief Engineer" role is missing from most AI teams.
At Toyota, the Chief Engineer owns the integrated product model end-to-end and has management-accounting authority — they own target costing (genka-kikaku), the discipline that ties design decisions to unit economics. The equivalent on an AI team is the person who owns the harness across all seven layers as one product: instruction, tools, memory, execution, policy, observability, evals. Not the prompt engineer. Not the platform engineer. The integrator. This role barely exists outside the frontier labs. When you see Cursor and Anthropic and OpenAI pulling ahead, part of what you're seeing is that they staffed this role and most teams haven't.
4. System prompts are tentative best practices — and that's a different mental model than "versioned code."
DevOps reflex: version your prompts. Growth reflex: A/B test them. Both miss it. The Toyota frame is: this prompt is the best one we know right now. It's labeled as provisional. Anyone using the harness is expected to improve it. Regressions are caught by golden-dataset evals. PDCA runs on top of live execution, not in a separate "improvement sprint." This is what kaizen on Layer 1 actually looks like — not "prompt engineering tips."
5. The 17% mastery drop is a kaizen signal you can't read with TPS metrics.
There's a 2025 Anthropic RCT I keep coming back to: developers using AI scored 17% lower on mastery of the code they had just shipped. The only subgroup that matched manual developers was the one using "generate first, then comprehend." There's a parallel METR study: AI made experienced devs 19% slower while they believed they were 24% faster. These are signals from the loop. TPS metrics — velocity, PR throughput, tokens per task — would never surface them. TPDS metrics would. Mastery, convergence, design-trial quality. That's what a properly Kaizen-shaped harness team would be measuring.
The Borovička parallel I can't quite shake
I've written before about Slovak construction labor working na borovičku — "on Borovička", at 100%, the juniper brandy fueling everything. Our family house was built that way. Bolo to drahé upraviť na určitý štandard, ale býva sa nám dobre. Expensive to bring up to standard, but we live well in it.
Here's the analogue I keep landing on. Vibe coding is na borovičku. Fast, alive, expensive to clean up later, sometimes wonderful, mostly not what you want for the foundation of a house your kids will sleep in.
Harness engineering is the building code. It's not glamorous. It's not the part of the project that wins design awards. It's the part that makes sure the wiring isn't behind the load-bearing wall and the drainage doesn't run uphill. Toyota's TPDS is the same kind of discipline: the unsexy upstream work that determines whether everything downstream is worth doing.
The mistake the 2026 kaizen-for-AI corpus is making is showing up at a building site with a factory improvement playbook — minimize variation, reduce cycle time, eliminate muda — when the work in front of them is architecture. Right tools. Wrong stage.
Three tests for "real Kaizen" vs. just iteration
Last thing I want to write down for myself, because I can already see "kaizen for AI" being diluted into "we improve stuff over time, like everyone else does."
Sakai's framework gives you three tests:
- Distributed ownership. Is everyone running the loop, or only the platform team?
- Standard-as-tentative. Is the current configuration explicitly labeled provisional, or is it the "final" version until someone files a ticket?
- PMF orientation. Is the loop oriented toward customer-facing PMF, or toward internal process metrics?
Most of the 2026 articles pass the third test, fail the first two. Honest read: most "kaizen on AI harnesses" today looks more like Toyota's Chief Engineer system (concentrated authority, one person owns the integration) than like Toyota's shop-floor kaizen circles (distributed authority, everyone on the line improves the line).
That's not necessarily wrong. The Chief Engineer system is also from Toyota. But it's a different system with different dynamics, and pretending the harness work is "kaizen" when it's actually concentrated CE-style integration is going to confuse the next round of conversations.
What I want to do with this
Reading this back, the piece I actually want to write — for LinkedIn, or for the blog, or both — has three moves:
- Reframe: harness engineering is on the TPDS side of Toyota's diagram, not the TPS side. (This is the move nobody is making yet.)
- Implication: the standard kaizen-for-AI advice in circulation is using the wrong metrics. Switch sides of the diagram, change what you measure.
- Cultural point: the "Chief Engineer" role is what's actually missing on most AI teams. Not more prompt engineers. Not more platform engineers. Integrators with target-costing authority.
I don't know yet if this is one article or three LinkedIn posts. The reframe alone might be the post. The KPI switch might be the follow-up. The Chief Engineer point might be the long-form piece where I link Sakai and Hashimoto and Fowler together explicitly.
For now I just want to be able to point at this file the next time someone tells me "we're doing kaizen on our agents" and ask the real question. Which half of Toyota?
No vibe, just hard work.
Notes to self
- Sakai's 95:5 number is unsourced — treat as directional, never cite as fact.
- The Kaizen-Agent GitHub project is a real product doing PDCA across prompts + code + evals. Useful as a concrete example but doesn't make the TPDS/TPS split.
- Fowler's feedforward/feedback control vocabulary maps cleanly onto poka-yoke (mistake-proofing) and jidoka (stop the line) — that's a clean post on its own.
- Don't dilute "Kaizen" into "iteration." The three tests above are the discipline.
- This whole piece runs on my own Sakai absorption from May 7. Without that, the TPDS/TPS reframe doesn't exist. Worth being explicit that the reframe is mine, the source material is Sakai's.
Sources
- Sakai, Toyota Studies: The Way Forward — LinkedIn essay, 2025
- Fowler, Harness engineering for coding agent users — martinfowler.com, April 2026
- Puzio, The Self-Improving Assistant: How Kaizen Principles Transform AI Interactions — Medium, April 2025
- Parabellyx, Human-in-the-Loop Is Not a Roadblock. It Is Modern Kaizen.
- Kaizen-Agent — github.com/Kaizen-agent/kaizen-agent
- Suzuki Yuto, Kaizen Agent Architecture — DEV.to
- Epsilla, The Third Evolution: Why Harness Engineering Replaced Prompting in 2026 — March 2026
- Hashimoto, agent-harness coinage — February 2026
- Anthropic 2025 RCT on developer mastery (17% drop); METR 2025 RCT on perceived productivity (19% slower / 24% perceived faster)