The Tech Stack Below TPS

Host Intro (Gene Kim)

All right. So Jitesh showed us what it looks like when a CEO rolls out AI from the top down. Our next speaker is going to show us what it looks like when AI truly empowers people at the edge of the organization to solve their own problems.

And there is no better person to teach us this than Art Smalley. So any fan of The Phoenix Project is probably a fan of the Toyota Production System. And Art Smalley was one of the first Americans to be hired by Toyota in Japan. In fact, I think he was number two, hired by the famous John Shook. He worked at Toyota's historic Kamigo Engine Plant and spent much of his career creating production engineering excellence in one of the most exquisite and demanding areas — engine design and manufacturing.

He's written amazing books, including Understanding A3 Thinking. He's a Shingo Prize winner. And I got to meet him earlier this year, and I was blown away because the surprise to me was that he is one of the most switched-on vibe coders I've ever met. And so the question becomes, how can an engine guy be good at vibe coding? And I'll just tell you this — it involves a Toshiba J3100 laptop, dBase III, in 1989. So here to tell this amazing story and teach us something about Toyota, something you've never seen before, is Art Smalley.

Art Smalley

Thank you. Thank you, Gene.

I have total imposter syndrome standing up here. I do a lot of presentations at universities and business summits and things, but this type of group is different for me. So following Jitesh and Steve Yegge, I'm like, you got to realize I'm coming at this from a different angle. They're the future. Steve's showing you the future of what things are going to be. I'm showing you how weird things are going to come at you from the side that maybe we're not quite prepared for. But I'm going to tell you my history and story, which Gene thought was good to share. I call this "The Tech Stack Below TPS."

So I make a lot of really simple apps — nothing impressive. On a scale of one to ten, they're three or four. Anybody in here could vibe code them, prototype them in three hours, four hours, have them deployed in three, four days. It's not that hard. It's Claude Code, GitHub, GitHub Actions, push to Vercel. I got a Supabase database connection, maybe some RAG systems, some things going on. But I try and teach non-coders how to code. That's what I do, okay? I'm not in your world. I'm not a software development engineer. I'm not in IT, I'm not a DevOps person. I'm an engine person.

But what I do with a guy named Tyson Heaton at the Lean Enterprise Institute is take people and try and empower them to make different types of apps that they care about. Software — it's really for three or four people. Thirty or forty would be a big number, something like that. We teach them very basic things. We start with people in HR, finance, legal, anywhere, QC. Often we have to start at: how do you use the model, how do you chat with it and not treat it like Google, and how do you do structured prompting? How do you add your knowledge to it in Markdown files or something useful, connect it to a database? And then it windows out, but then some people say, "Okay, well, I want to make a front end for this. I want to have a GUI interface, some kind of front-end thing and connect to it." And very few get to the end and say, "Well, yes, let's make this a real agent in our system and deploy it somehow." But it's fun, and people like to build this stuff.

And Gene wants to know, well, how do you do that, Art? How the heck do you do that? I go, well, it does go back to Toyota — a side of Toyota that people don't know about and the lean community sadly doesn't talk about. I joke that there's a T in Toyota, horizontal top and vertical up and down, and most people are only aware of the horizontal. That's what all the books are about — The Machine That Changed the World. I got a nice email this morning from Dan Jones and Jim Womack; we keep in touch. And anything you've read about it, it's 100% correct, but I consider it the horizontal — or, later, what I'll call the HTML layer.

What really works well in Toyota is the vertical stack. I'm part of a tribe. There are many tribes in Toyota that you don't see or don't know about. Everybody paints the same glowing Toyota picture, which is true, but we have these tribes, these vertical stacks of technology and tribes of capability that go up and down. Now, that's true for R&D, product development, production engineering. I was a manufacturing engineer. It's true for purchasing, HR, in any department of the company. I'm very deep in the stack when it comes to engines.

My world was not up there at the standardized work, Kanban level. We kind of take that for granted, to be honest with you, because it all depends upon the equipment working. Assembly lines are like 80% people, 20% automated. Engine plants, when I joined, were 80% automated, 20% people. Today, they're 100% automated. So we've been playing with robotics and different types of technology for a long time in Toyota. You don't hear much about that because the weird thing is that TPS and kind of lean did start at a plant called Honsha, where Mr. Ohno there dabbled. But the crown jewel, the masterpiece, was Kamigo, which was the engine plant — because it was casting, forging, machining, assembly, hundreds of suppliers, precision. The precision's in the engine and transmission. We brag that we measure in microns. We joke at the vehicle plant, "You guys measure in millimeters." It's all relative for what they do. They stamp panels, they measure in millimeters. We consider them apes.

We brag that we measure microns. Human hair is 30 microns. We're much more technical. But it's all relative because if you're in the semiconductor world, ASML is like, "Art, you're the gorilla. We do nanometers." Like, what the — a micron, that's 1,000 units of the world I live in. So it's all relative. But TPS did largely come out of that. The mother plants did come out of the engine plant, and we make fun of each other.

But in Toyota, to this day — and we ran spare parts management, initially it was 100,000 spare parts, it grew to over a million — on Toshiba laptops. In the United States it was a T3100. In Japan it was a J — the keyboards were different — J3100, the orange screen there. And we just handed around floppy disks, and if we had to send something to a kid named Paul Kyle in Georgetown, I'm not kidding you, it was sent on a Hayes AT 2400 baud modem, and that's how we sent important data between plants back then. This was 1989. And we'd order spare parts back to Japan and get them shipped, because you had to do that three months before start, every year, or you were screwed. The lead times were horrendous back then.

And I joke every company is like this — you see this meme on the internet a lot, the dependency that can take everything down. We've kind of seen that today with our slide system here. We've got a tech crew, a first-rate tech crew doing a great job behind the scenes debugging, troubleshooting, fixing stuff. We decided to go without this monitor because these are working. But there's always glitches in life, and it's hard to fix under pressure. There's levels of redundancy you have to have. And we have that with spare parts, we have that with machines, we have that with stuff. And although we present this perfect picture of everybody could do everything and knows the Toyota Way, when you get down to it, a critical piece of equipment — there's three or four people that really can manage and control it in a pinch, in emergency situations. A lot of things are like that, and you just have to be respectful of that.

Now, I'm not saying anything you've ever heard about TPS or the surface is wrong. The books are 100% right. What I'm just trying to say — it's the visible layer. It's real, and it's the surface, and in a lot of situations that's enough. But the more assembly-intensive it is, the more the standardized work, the Kanban, the pull system, the visual boards are good enough. But the more equipment intensity you get, the harder it gets.

And I think maybe this analogy works. It's like when people look at a webpage and take it for granted, right? The HTML layer. Well, it looks pretty and nice, but there's stuff underneath that. Those pages just don't appear. When you start stacking up the things below it — a browser, a network, API, programming language, kernel, compiler, OS — and then when you get to that really hard tech stuff, a hard tech layer, well, it's complicated. It's not easy, folks. Same is true in Toyota, to be honest with you. And we don't do much of a job of sharing it because frankly, nobody cares. It's too damn hard to explain to the outside world.

We talk a lot about the high TPS layer. It's easy to see on a tour, show people, just show them that. I live down at the bottom — tooling, engineering, material science — playing with control systems and feedback and measurement, trying to control these really, really precise one-micron-level machines. And that's a side of Toyota you don't hear about, but without it, it doesn't work. You can be good at HTML; if the compiler doesn't run, you're screwed. You can be great at Kanban, standardized work; but if the machines at the bottom don't run, you're really screwed. The whole system collapses.

So I spent most of my life — seven years at Toyota — becoming a proficient engineer, mainly having to study cutting forces, mechanics, things that work. Because this is really what drives whether the component is made or not: the crankshaft is made or not, the shearing force and the cutting force and the orthogonal cutting directions and the material science. You get into certain levels of problems where if you don't understand this, you can't fix it. You can't HTML your way through it, you can't vibe code your way through it sometimes. It's too complex.

And it's not hidden. There's a side of Toyota where we actively talk about this; it's just not public. We have this thing called the TTR — Toyota Technical Review — and if you get published in this internally, it's a big deal. I think a lot of tech companies do this. I'm sure Google, Amazon, Microsoft, they've all got their internal versions of this as well. I don't think you can be a good product or company without having good product and good technology supporting it. And Toyota has that too, but we don't talk about it. It's unpopular. It's too arcane — because who wants to read this? I mean, raise your hand if you're really interested in cutting forces and shearing forces and grading. All right, one hand. One hand. I got one fan. Two. Two maybe.

It's complex. The more complex it gets, the narrower that curve gets, the fewer people who are interested in it — but it's really critical and really important. And Toyota's great not only at the assembly line stuff. They're great at the underpinnings of the technology supporting it. Kind of like ASML is this key company for semiconductors and supporting the world. Toyota's got JTEKT and Denso. They've got these critical suppliers. Toyota wouldn't work without JTEKT and Denso. JTEKT makes the majority of the machine tools — the stuff that does the one-micron precision stuff that we grind — and Denso does the fuel injector technology, the thinking. We call it the bento box — the engine control unit, the bento boxes and things. It doesn't run without them.

And in ways, this is analogous, trying to connect it back to where my world is today and what I think is entirely coming: software and AI are in the tech stack at Toyota. You don't see it. Because weirdly, they started with machine learning and then AI second. Because even after I left, we were trying to do pattern recognition — studying signals and sensors off a machine — for what we call mizen-boshi, famous Japanese words meaning pre-occurrence prevention. Because you can sense problems before they happen in equipment a lot of the time. If vibration is abnormal, temperature is abnormal, timing is slightly abnormal — so we've got something here in the red zone, machine's not down, it's just starting to trend into an area where we are concerned — we're going to go look at it on an automated line before it breaks down.

And this is not being done by IT or a special group in Toyota. It's being done by people that were formerly like me. They're doing coding, now increasingly using AI tools. In the beginning, they would have their own Raspberry Pi devices and hard code things by hand. But they're increasingly dealing with AI, making small little applications in the plant — only within the plant. It's not broadcast to the outside world. Doesn't matter. Other plants don't need to see it. Only the engineers controlling this subsection of equipment need to see it. Same with parts, logistics, and some other things. They're really small teams building really interesting pieces of software that five people care about, five people manage, five people care about. But for their job, it's really critical, and it's really fun to build these things.

Building things at Toyota today is a lot of small tools. And other companies I'm visiting today too — not software companies, hardware companies and different types of institutes.

1989, the story that Gene wanted me to tell — that was a pure resource problem. We were not important. They could not get to us. It was true. On the big scheme of things, we were not that important. But we don't care. We got this. We built a better system, frankly. People liked it. It worked. It later got adopted to be the system at Georgetown over time.

In 2026, there's a little bit of a different battle going on at Toyota — called the governance problem. Because the people in the plant can build things, but they're not enterprise apps. They had to get special permission to deploy it, run it, and put it up on monitors and screens within the facility. And this is still kind of a block. For your companies, maybe not. If you're software, some tech companies, you're smaller, you're AI-native, you probably can't even relate to what I'm going to talk about next.

But I'm tending to work with a lot of larger legacy companies these days — like GE. I do go to Toyota, in North America, some of their divisions. James Hardie custom building products, Sandia National Laboratories. And we teach small groups how to build things, how to code apps that they like for their job, make their job better — and they're all frustrated because they can't yet deploy it safely in the enterprise. There is a problem.

And I think the world's going this way. There's this fun vibe coding the big stuff and the enterprise stuff, and the future is a lot of weird stuff — like people like me build and want to encourage people to build — even if it's only three or four users, because those apps are really, really useful. It beats the heck out of an Excel spreadsheet or a crappy little database connection or something like that. Outside vendor's not going to make it — there's no money in it. IT's too backed up. It's not important enough for them to waste their time on it. They don't have the domain knowledge. They don't understand what you want. It's too confusing. Well, the plant team can build it, but often they're blocked on the approval path for how to deploy it. It's not like the outside world where Art can push it to Vercel and connect to Supabase like that. That's not legal. That's not allowable at these companies that I work with.

And I think help is on the way if I try and scan the landscape and see what's happening around the latest Microsoft frontier playbook, and they're saying a lot of good things — lean before agents, citizen developers, sandbox governance. But I don't think that answer yet covers when you've got hundreds of people in small three-to-four-person teams building lots of apps. I'm not sure how we're going to govern and manage that yet. I don't have the answer. I'm hoping the people in the audience in smaller companies, more nimble, agile, have the answers — because the big companies are blocked.

Even Toyota. I'm not going to lie — I know we're videotaping — I'm going to get in trouble for this. But the last thing we built: some people in a couple of companies, IT's answer was, "You're about three months in front of us. Could you please stop? Just give us a little more time to catch up to where you're at." And I just think this is inevitable. Long tail of applications. We've got the dark-coded stuff. We have processes for managing that, but it's a little bit like — I feel like barbarians are at the gate. This could be the decline and fall of the Roman Empire. I'm not sure. What happens when you have the citizen coders who can suddenly spin up 300, 400, 500 apps — and how do we manage them responsibly? We don't let Stuxnet in the back door accidentally somehow.

But the trend is undeniable. It's going from the uppermost managerial genius layers — Frederick Winslow Taylor and scientific principles of management at the management layer, industrial engineers as a domain-specific kind of knowledge-thinking — Toyota's always trying to push that to the employee. I predict they will have, in the end, a lot of citizen and vibe coders doing great apps. The ones I've worked with are really excited and want to continue. They can't wait to go forward with this stuff.

Denso is even more impressive. I don't have ties with Denso, but they've got this incredible program for their engineers in Denso and people who want to learn to code. It's even more impressive. Unfortunately, it's behind the wall of Japanese things, and they've largely restricted it to Japan so far. But man, if I was young again, I'd line up to go work at Denso today. Some of the stuff they're doing is so phenomenal. I'm super impressed.

So my request, my wish — I didn't make slides for this, I was too lazy at the last minute. But look, I think the enterprise delivery side is getting figured out. Kudos to Microsoft. They're pushing out — the last September version of Copilot wasn't so bad. It's getting there. Some of the stuff — the Visual Studio Copilot, the templates they're giving you, the Power Platform stuff — that's not my world.

I run Linux. I boot into Omakase Quattro in the morning, and Claude Code is my startup menu. I'll never go backwards. And once people touch that, they don't want to either — even people that are not developers, not coders. Once you teach them to be comfortable at the command line, the CLI in the GUI, it's like, "Oh, this is better. It's faster. It's better. It's not so bad." Not saying everybody will go there, that Windows are going to disappear — GUI exists for a reason. But once you've touched that area and you've connected things and you can do the bash commands at the CLI, you don't want to go back.

It's getting better. I know a lot of people do code in the cloud and use Windows interfaces. I'm not one of them. I'm not that advanced.

So we need places to build — risk-based reviews to the size and scope of the projects. It's spare parts. It's not that dangerous. Coolant management systems — it's not that dangerous. It's not company-proprietary. A lot of that's not scary, proprietary information they can dig out. Building capability — that's kind of what I do on the side these days — and ownership. The people that build it do have to own it and maintain it. You can't just build something and throw it over the wall and say other people maintain it. So this is being sorted out.

I feel there's a murky middle that we don't quite have figured out in the larger legacy organizations. Maybe not so much where you work, but when I see the Cleveland Clinic, Sandia National Laboratories, GE, Toyota — they're all in this difficult murky middle right now, which I think is going to take a year or more to sort out, to figure out how to do this responsibly with proper governance. In the meantime, they just have to scale up and train.

So we have this saying in Toyota: "Good thinking, good products." In my personal opinion, AI is a godsend for this. AI used responsibly sharpens your thinking. I'm not a P-doomer. I am a complete techno-optimist on this stuff. Yeah, there are risks with it. I feel sharper at 61 and a half than I did ten years ago. And I think it's using AI every day to think, code, and debate and sharpen my problem-solving skills. That's a big part of it.

So I'm optimistic about this stuff. Keep doing the good work you're doing. Go forward. Find people like me. They're out there in your tech stack in weird places. One in 100 people like to code. They're not in your department, but they're out there — and I think you find them and incorporate them and pull them into your routines. They'd be very willing to work with you and help out.

So — good thinking, good products. Thank you.