Generative code or vibe code is the best tool we have ever had for building on top of a foundation. The mistake is using it to avoid building one.
I have been seeing something I expect to see far more over the next two years. A manufacturer runs a serious software selection. Real requirements, real shortlist, real diligence. One factor increasingly discussed is the influence of vibe code on these decisions. Then, late in the process, a finalist appears that was not there at the start: build it ourselves.
Generative coding tools have made that option look credible in a way it never did before. A small internal team stands up a working prototype in weeks: it demos well, it needs no license, it fits today’s process exactly, because it was shaped around today’s process. The toughest competitor in the evaluation is no longer another vendor. It is the customer’s own team.
I want to take that seriously rather than wave it away, because the people choosing it are not naive. They are responding to a real shift, and some of their reasons are good ones. Speed to a first working version. Avoid a procurement cycle. Have full control of the roadmap. And a tailwind that is hard to argue with in a board meeting: if AI can write the code, why pay anyone for software?
You can vibe code an app. The question is whether you can (or should) vibe code a full Manufacturing Execution System, and the answer has less to do with how good the code generator is than with what an MES actually is.
The hard part was never the code. It was the model.
A MES is not a screen with a database behind it. It is a model of how a factory runs. Before a single workflow is useful, the system has to represent what a lot is, what a unit is, how they relate, how material splits and merges, how a product moves through a route, what state it can be in, what a step requires, what a resource is qualified to do, and how every one of these connects to every other.
That web of meaning is the operational ontology. It is the part that makes a query like “can I run this lot on this equipment right now” answerable at all, because the answer depends on genealogy, on qualification state, on the recipe, on the current route step, and on constraints that only make sense in relation to one another.
The missing layer
This is the layer generative code does not reach. A code generator is very good at the visible surface: the screens, the forms, the workflow that moves a thing from one status to the next. It is close to blind on the ontology, because ontology is not a coding problem. It is a modeling problem, and it encodes decades of manufacturing reality that appears in no prompt. You can generate a convincing interface over a shallow data model in an afternoon.
You cannot generate the model itself, because the model is the accumulated judgement about how this kind of production actually behaves.
So the prototype that wins the room is fast at the surface and silent on the substance. It looks like an MES. It has the screens. What it does not have is the layer underneath that would let those screens stay correct as the factory changes.
Requirements do not hold still
“Custom to our requirements” quietly means custom to today’s requirements. This is the assumption that does the most damage, because a factory’s requirements are not a fixed specification. They are a moving one.
A new product line arrives with a process step that has no precedent in the current model. A regulator changes what has to be recorded and how it has to be signed. A second site comes online and runs the same product a different way. A supplier change forces a new genealogy branch. A quality event demands a containment rule that cuts across the existing route logic.
Each of these is not a new screen. It is a change to the model, and a model that was generated to fit a snapshot has no clean place to absorb it.
A platform built on an explicit, governed model absorbs these as configuration. The ontology already has the concepts; the change is expressed in terms the system understands, versioned, and carried forward through upgrades. A generated system absorbs the same change as new code, bolted onto a structure that was never designed to receive it.
The first path compounds. The second accrues debt, and the debt is structural, not cosmetic. Fit is a snapshot. But operations are not a snapshot, but a film.
The system you generated is a system you now own
The knowledge becomes fragile. The model lives in the heads of the two or three people who built it, and in a generated system there is often no written model at all, only code that happens to work. There is no vendor, no user community, no documentation discipline imposed from outside.
When those people move on, the system stops being understood and starts being feared, which is the moment change slows to a stop.
The evidence on AI-assisted code does not soften this.
- GitClear’s 2025 analysis of 211 million changed lines of code found that copy-pasted code overtook refactored code for the first time on record, with refactored code falling from around 25 percent of changes in 2021 to under 10 percent in 2024.
- DORA’s 2025 State of DevOps report, covering teams where AI use is now near universal, found that AI turned positive on delivery throughput this year while its relationship with delivery stability stayed negative, with more change failures and more rework.
- In Stack Overflow’s 2025 survey of more than 49,000 developers, the single most common frustration, cited by 66 percent, was AI output that is “almost right, but not quite,” and 46 percent said they distrust the accuracy of that output.
These are not arguments against using AI to write code.
They are a warning about what happens to generated code over time, and an MES is a system you keep for fifteen years, not fifteen sprints.
The economics follow from that. Initial build cost is low and visible. Lifetime cost is high and hidden. Software has always spent most of its life in maintenance rather than initial construction, and AI changes only one side of that ledger. It lowers the cost of authoring. It does not lower the cost of validating, securing, integrating, and re-certifying that system every year, indefinitely.
When you choose build, you are not buying a tool. You are deciding to become a software vendor with a single customer and a permanent obligation to staff it.
There is more to say here on consistency eroding across sites, on integration entropy as every connection to ERP, equipment and quality becomes bespoke, and on the upgrade path that is really a rebuild. Those deserve their own post. The pattern underneath them is the one worth ending on.
Augment the foundation. Do not replace it.
We are not in a moment where AI failed to live up to the hype. We are in a moment where AI generates software so well that it tempts us to point it at the wrong layer.
There is a sharp line between two philosophies that look identical on day one. One uses AI to augment a solid foundation. You model the operation properly, with a real ontology, and then AI accelerates everything built on top of it: configuration instead of custom code, logic the platform understands, governs, versions, and can upgrade safely.
The same generative speed that built the throwaway prototype becomes a genuine accelerator, because it is working on top of meaning rather than inventing a substitute for it. That compounds.
The other uses AI to replace the foundation work. It generates software that stands in for the model rather than building on a model that already exists. It demos beautifully and degrades quietly, because every layer above it, including any AI you later try to add, is reasoning over data that was never given meaning. This is the failure mode I keep describing as the Industrial AI Cliff.
The importance understanding how to use AI in manufacturing
AI maturity is capped by execution maturity. You can only act intelligently on an operation you have modeled correctly, and a generated MES skips precisely the step that makes intelligent action possible.
The wider evidence on that gap is consistent. McKinsey reports that more than 80 percent of organizations see no tangible enterprise-level EBIT impact from generative AI. BCG finds only around 5 percent of companies are “AI-future-built,” and those few generate up to 5x greater revenue impact and 3x higher cost reductions, not from better algorithms but from stronger foundations: canonical data models, execution-ready architecture, a real model of how the business runs.
The leaders did not point AI at the foundation to avoid building one. They built one, then aimed AI at everything above it.
The question has moved
Generative code did not settle the old build-versus-buy debate. It moved it. The question is no longer “can we write the code?” The answer is yes, faster every month. The real question is “do we want to own and validate the execution model for the life of the factory, and become a software company to do it?”
For a few organizations the honest answer is yes. For most, it is a cost they will not see until month eighteen, when the prototype that won the evaluation has to become the system that runs the plant and carries every product change, audit, and AI initiative that comes after.
Structure first. Intelligence follows. Improvement compounds.
You can vibe code an app, and you should. It is the best augmentation we have ever had for teams standing on a real foundation. Vibe coding a full MES is the most convincing way yet to persuade yourself you do not need one.
