Stop building AI-Native. Build Application-Native AI.

The point isn't the technology, and it never was.

Black-and-white woodcut-style drawing of an excavator digging at a construction site, with circuit-board traces woven into the ground and building frames

Confession: I’m building AI for manufacturing, but I hate the term “AI-Native”. Not just because it’s everywhere, but because the framing is perfectly wrong.

What do I mean? Well, technology doesn’t solve problems, it scales solutions. You don’t magically dig the foundation of a house faster by dropping hydraulics on the job site, and nobody buys a “hydraulics-native foundation hole”. They buy the hole. So if you engineer hydraulics into an excavator that can do the work of forty people, well, now you’ve got something special. “AI-Native” gets this exactly wrong. It treats the technology as the why, but it’s really the how.

This doesn’t mean AI isn’t remarkable. It is, and I’m excited about its potential. But “done by AI” does not mean something is useful, or even good. It’s a technology, but isn’t something to mold our whole world around or that has to do everything for us for its own sake. Sometimes you just need a shovel.

#AI is actually software-native, and that’s helpful to understand

In spite of the ubiquitous phrase, even software isn’t AI-native. If anything it’s the other way around.

AI tends to thrive where three things exist: rich feedback loops, great contextual mapping, and the ability to take digital action. Software has all three, and the field has spent decades building them. Not for AI, but for humans to iterate faster, and it’s worked. Context lives in structured codebases with version control and code reviews because human engineers need that to collaborate and ship. Feedback loops are practically free and relatively instantaneous, and were built that way for faster iteration as engineers have found better and better ways to test that something works before shipping. And digital actions are just the way the medium works. AI didn’t create this environment, and it wasn’t created for AI. Instead, it inherited it. But that’s also why AI works so well here, because it was applied to an environment that was already built for scale, and it’s now scaling it further using the same principles.

So the real question shouldn’t be “how do I make this AI-native?” That results in the proliferation of chatbots that “help” you order a hamburger but aren’t actually any faster or cheaper than the alternative. Instead, the right question is “What does AI need to be native to my application, and does that exist yet?”

#What manufacturing needs for native AI

Manufacturing is where I live, and it already has the same conceptual equivalents of what was built in software (in fact, a fun exercise is to research where software got the inspiration for many of these concepts - you’ll be surprised, but it’s a bit of a full-circle moment). However, they still mostly live as mental models or flat, transient models in a spreadsheet or on a whiteboard. Closing that gap is where the work lies, but again - this isn’t just for AI’s sake, it’s also what’s needed to help humans scale.

#The context is the value stream

Every manufacturing consultant worth their salt will start by mapping your value stream. Careers have been built here, and you will find no shortage of blog posts and books about how important it is to see the system before taking action. But the resulting artifact is usually just a mental model or a static diagram. Enough to give guiding context to people on the floor in a factory, but woefully insufficient for a model that only lives in the digital world. Give AI a structured, digital model of the value stream, and it finally has the context to be useful. Give humans that same structured view, and guess what? They can make better decisions too.

#Feedback: the plan vs the actual

One of the most critical and difficult exercises when launching or ramping a manufacturing line is a detailed comparison of what actually happened to what was supposed to happen. It means stitching together data from all over the place, dumping it into a spreadsheet, building visuals, and then ultimately asking someone on the floor “Hey… is this right?” for confirmation.

In practice, this usually isn’t even a real feedback loop. We can often access the actuals, but the plan is all over the place in disconnected spreadsheets and whiteboard notes that are constantly changing. I learned at Tesla that “the plan is the plan” - that is, you can’t retroactively update the plan to make your actuals look better. I’ve learned everywhere since both how critically true that statement is, as well as how much discipline it takes to follow it. It’s human nature to want to constantly change and update the plan every time you learn something new. However, closing this loop, and anchoring both in the value stream as the context layer, is what makes AI capable of actually “seeing” your operation.

And again, this isn’t something to do just for AI’s sake. While it’s difficult and manual, it’s the whole point of an S&OP process, and closing this loop means humans can see and perform better as well.

#Actions: humans in control

This is a hard requirement for a factory, even more so than in software. In software, if AI makes a mistake, your marginal loss from that mistake is usually recoverable. In a factory, mistakes cost real dollars, and to borrow the meme, you can’t hand everything off and say “Claude - double my output, make no mistakes.” Instead, you do what software already figured out: you give AI tools to automate real tasks, and you give humans the mechanisms to review, approve, edit, or reject whatever it does. No matter how good the digital context, we are still a ways off from a one-to-one model of the real physical world, and there are things that a model will miss. Human oversight isn’t a limitation, it’s the design.

#The point isn’t AI, it’s eliminating waste

Once AI is native to your manufacturing system, the question becomes “where do I point it?” Luckily, this answer is the same as it’s always been: waste, and the bottleneck. The whole point of industrial engineering is to eliminate waste and optimize the flow of value to the customer. This has been even more codified in the methodologies of Lean, the Toyota Production System (TPS), and the theory of constraints (TOC). We shouldn’t look to AI to just be better for its own sake, but rather it’s a tool we can use to attack that goal and start to scale it at a frequency that wasn’t possible before. Lean gives us eight wastes (seven for the purists), but here are a few straightforward examples where AI can be effective at actually helping you scale.

#Overprocessing

This is where AI shines first. While some overprocessing is physical (e.g. polishing a surface no customer cares about) the reality is that most overprocessing in a modern factory is digital paperwork. Spreadsheets and reports pushed back and forth with analysis that nobody reads, because it’s simply too much. AI can automate most of this and, more critically, use it to connect process data to product performance in ways that were previously too tedious to sustain. So not only can it reduce the overhead, but it can actually use the task to find more opportunities to improve.

#Inventory

The math isn’t hard, it just gets super difficult in a complex, dynamic system. I can’t help but smile at the fact that after formally studying operations and manufacturing engineering and all of the models and equations for ensuring appropriate levels of safety stock and how to determine the right inventory model for a given system… it all largely gets thrown out the window in favor of general guidelines. Not because the math is wrong, but because most of the math assumes a static system, and no factory is static. The analysis that produces the “right” policy can’t just be done once, but rather has to be done constantly, which in practice means it isn’t. When we structure data on the value stream and give AI tools to do this analysis, it has no problem doing this constantly, meaning you can use actual data to guide your policy instead of gut feel.

#Unused potential

This may be the biggest unlock, as well as the most misunderstood. Saving an executive an hour of analysis so they can spend their time focusing on guiding a team sounds great. However, real productivity gains from AI don’t come from accelerating the executive, they come from accelerating the individual, and giving working-level teams the tools they need to see and understand the system. If you’ve read The Goal (and if you haven’t, you should), think of AI as a personal Jonah for everyone, pointing them at the right constraint, the right question, and the right potential experiments to fix the right problems. But it can only do so if it has the context already described. You don’t free up human potential by making it easier for one person to find the right answer, but by doing so for an entire operating team.

#The right framing

“AI-native” gets it backwards - AI isn’t the point, it’s the how. And the point in manufacturing has been clear for a very, very long time: eliminate waste, and make value flow. In the age of AI, the job isn’t to try to reinvent that for the sake of cool new tech and make manufacturing “AI-native,” but rather to make AI manufacturing-native. Where it’s fluent in your value stream, can get feedback, and can accelerate your digital actions to help you drive improvement. If we can do that, then AI stops being a buzzword that people - rightfully, I might add - fear because it’s something we’re molding society around like The Matrix. Instead it starts being something much quieter and much more powerful: a tool that helps us so much that we start taking it for granted.

If you want to see how we’re building value stream context, plan vs. actual feedback, and human-in-the-loop actions into one place for manufacturing teams, schedule a call and we’ll walk you through it.