Can You Vibe Code PLM Instead of Buying It? What Companies and Investors Are Missing

There is a question I hear in almost every conversation with engineering and manufacturing companies in 2026: do we still need to buy PLM, or can we just vibe code it ourselves with AI?

The question is not coming from dreamers. It is coming from capable teams who have watched Claude and other AI coding tools turn a described intent into working software in hours. They have APIs to their CAD systems, engineers with domain knowledge, and a growing sense that enterprise software pricing belongs to a world that no longer exists.

And it is not only companies asking. Investors are asking a bigger version of the same question. If AI can write production-grade code, can the entire B2B software landscape be redeveloped from scratch? Why pay for decades of accumulated vendor code when a small team with Claude can rebuild the features they actually use? In this framing, PLM is just one line item on a long list of enterprise categories supposedly waiting to be disrupted or dissolved into custom-built internal tools.

I take both questions seriously. I wrote about the first one a few months ago on Beyond PLM, asking whether we can vibe code the next PLM. But theory is one thing. This week, two data points landed in my inbox that show where the real answer lives.

I want to make an argument for the PLM harness. What is that? 

A PLM harness is the stable foundation of structured product data that AI-generated tools need to operate reliably: consistent item identification, multi-level BOM structures, revision control, lifecycle states, procurement data, and history. AI can rapidly build applications around product data, but without a shared harness, every script becomes its own disconnected source of truth, multiplying data silos instead of eliminating them.

The Team That Vibe Coded Their PLM and Hit the Production Wall

A mechanical engineer leading a project with a few thousand parts wrote to me. His team evaluated OpenBOM a few months ago and decided not to buy. Instead, they did what more and more smart engineering teams are doing in 2026: they decided to build their own tooling. They set up BOM properties and templates in their CAD system. They used Codex and their CAD platform’s API to extract design data, some other tools to scrape supplier data, pull part and documents together, and automate the tedious parts of data collection.

And here is the important part. It worked. The scripts ran. The data flowed. By any reasonable definition of a coding project, they succeeded.

Then they moved forward to production planning, execution and changes. And they started to hit issues. Procurement is not closing cleanly. Changes are getting hard to track. The information exists, but the process does not. So he came back to me with an open question: maybe the decision we took a few months ago not to go with OpenBOM is the wrong one? Can you help us? 

I want to unpack why this happens, because it is not a story about one team. It is the pattern hiding inside both the company question and the investor question.

AI Made Building Easy. It Did Not Make Operating Easy.

In my Beyond PLM article on vibe coding PLM, my answer was yes and no. Yes, AI can generate real, useful applications around product data, such as validators, import utilities, dashboards, and integrations. No, it cannot generate the durable structure underneath: consistent product data models, revision control, lifecycle states, and traceability that hold together over months and years. It cannot generate a collaborative environment that will hold teams of engineers, procurement agents and managers working together. 

The email I received this week is that article playing out in real life.

The team built exactly what AI is good at building: data collection, scraping, property extraction, automation of specific tasks. Each script solved a real problem. But a collection of scripts is not an operational system. When the project hit production, the questions changed. What still needs to be purchased? Which revision is actually released? Where are the gaps in supplier, cost, and lead time data? Who changed this, when, and why?

These are not coding problems. They are data management and workflow problems. And they only become visible when the cost of getting them wrong becomes real, which is exactly when a project enters production.

The In-House Tool That Becomes a Liability

The same Beyond PLM article triggered a lot of discussion online and offline. I talked to a few of my long-time colleagues in CAD development, PLM implementation and customizations.Here is a combined comment from those discussions that deserves to be quoted here.

AI-assisted in-house development is a real capability, but a minor threat to established software, because the effort is far from insignificant. There is still a lot of iteration and testing. When an existing product has a strong core, AI helps the vendor enhance and accelerate development, which increases retention rather than replacement.

But the most important observation came from experience, not theory. Over the years, people repeatedly watched in-house developed software turn into a burden for businesses, sometimes to the point of becoming a liability, with the company effectively held hostage by the one staff member who built and understands it. AI has the potential to make that dynamic worse in some respects, even as it mitigates it in others. In the company he works with now, he can already see multiple staff members building AI tools independently, which quickly increases data silos and process fragmentation if nothing keeps it under control.

Read that last sentence again. AI does not eliminate data silos. Without a shared data foundation, AI multiplies them, because now every capable engineer can create one.

What Failed Was Not the Code. It Was the Absence of a Harness.

I found myself back 25+ years watching engineers developing amazing scripts using AutoLISP for AutoCAD. It worked amazingly well until those people were around and crashed magnificently when they left. Decades later, new technologies, we are still at the same place.

Here is how I explain what happened to the team with the 2,000-part project.

Their Claude and CAD API work did not fail. It succeeded at what code can do: moving and transforming data. What was missing is what I call a PLM harness: the stable layer of structured product data, identification, revisions, lifecycle, and process control that AI-generated tools need to stand on.

If you follow my writing on Beyond PLM, you can think of the relationship this way: Product Memory is the conceptual layer, the accumulated product knowledge, relationships, decisions, and history that make product data understandable over time. The PLM harness is its operational implementation, the concrete data services and controls that AI-built tools plug into every day.

A PLM harness gives you a consistent item master, so every part has one identity across CAD, BOM, procurement, and suppliers. It gives you revision control, so “which version is in production” is a fact, not an investigation. It gives you BOM structures that connect engineering definitions to purchasing reality, including quantities, costs, lead times, and vendors. And it gives you history, so six months from now you can reconstruct what changed and why.

Without that harness, every script the team wrote had to answer those questions on its own, implicitly, inside its own logic. Ten scripts means ten slightly different answers. That is the fragmentation I’ve described, and it is why the pain showed up precisely at the moment procurement and revisions had to close.

Build vs. Buy Is the Wrong Question. The Right Question Is What to Build On.

For decades, PLM was a binary choice: buy a monolithic system and bend your process around it, or live in spreadsheets. AI has genuinely broken that binary, and I welcome it. Engineers can now build the last mile themselves: the custom validators, the specific reports, the integrations tailored to their exact workflow. This is the same democratization I watched with AutoLISP in AutoCAD and with Visual Basic in the business world, at a much higher level of abstraction.

But both of those earlier waves taught the same lesson. Democratized development creates enormous value at the edges and enormous debt at the center, unless the center is stable.

So the question engineering teams should ask in 2026 is not “should we build our own PLM with Claude?” It is “what stable data foundation should our AI-built tools run on top of?”

This is exactly how we think about OpenBOM. OpenBOM provides the harness: cloud-native product data management with item catalogs, multi-level BOMs, revision control, vendor and procurement data, and open APIs. Your team keeps building with Claude, with your CAD platform’s API, with whatever AI tooling accelerates your work. But the scripts read from and write to a controlled, shared, structured product data layer instead of each script becoming its own private database. AI builds the applications. The harness preserves the truth.

The economics follow from there. Think about the project with the budget of $500k. Already at that scale, the cost of a PDM and BOM system should not be evaluated as a percentage of a CAD license. It should be evaluated against one wrong purchase, one wrong revision released to production, one week of an engineer reconciling scripts instead of engineering. Any one of those typically costs more than a year of software.

What is my conclusion? 

I want to come back to my article earlier this week – How to evaluate the PLM system? The trials fail for a reason worth naming: if an evaluation is happening without a project scope and a clear understanding of the process and environment it is expected to run, the results are not clear. A trial without a real problem tests nothing.

How to do it differently? Take one active assembly or project and walk through the practical questions: what still needs to be purchased, which revisions are production-ready, where the data gaps are, and how much engineering time goes into maintaining scripts and reconciling information. Then define a narrow evaluation with clear success criteria around that specific pain. For a project that involves a team, try to run a scenario where mechanical and electrical engineers work together delivering a consolidated data output that can be used in procurement. 

That is my suggestion to every team currently building their own PLM with AI. Do not stop building. But before your project enters production, ask what your tools are standing on. If the answer is “each script has its own copy of the truth we export to Excel,” you are not building a PLM. You are building next year’s migration project.

And to the investors asking whether all B2B software can be redeveloped with Claude or OpenAI, this story suggests where the real answer lives. The application layer of enterprise software is genuinely under pressure, and much of it will be regenerated, customized, and commoditized by AI. But the durable value was never in the screens and workflows. It is in the data foundations: the structured, controlled, accumulated knowledge that applications operate on. The companies worth backing in this transition are not the ones generating the most code. They are the ones providing the harness that everyone else’s generated code depends on.

AI can vibe code the applications. It cannot vibe code the product memory and an environment to support the team work. Start with the harness, and let AI do what it does best on top of it.

Best, Oleg

FAQ 

Can you build your own PLM system using AI tools like Claude? 

AI can build real, useful applications around product data, including validators, integrations, scrapers, and dashboards. But it cannot generate the durable structure underneath: consistent data models, revision control, and traceability that must hold together over years. Teams that build only the applications typically hit the wall when projects enter production.

Why do in-house AI-built engineering tools fail in production? 

The tools usually succeed technically but fail operationally. Scripts collect and transform data, but production requires controlled processes: knowing what still needs to be purchased, which revision is released, and where data gaps exist. Without a shared structured data layer, every script maintains its own version of the truth.

What is a PLM harness? 

A PLM harness is the stable layer of structured product data that AI-built tools stand on: item catalogs, multi-level BOMs, revision control, vendor and procurement data, and open APIs. It lets teams keep building custom tools with AI while a controlled data foundation preserves consistency and history.

Is buying PLM software still worth it in the age of AI? 

The build vs. buy binary is obsolete. The better model is a hybrid: buy the stable data foundation, and build the last-mile applications with AI on top of it through open APIs. Evaluate the cost against procurement mistakes, revision errors, and engineering time spent maintaining scripts, not as a percentage of a CAD seat.

Will AI make buying B2B software like PLM obsolete? 

AI puts real pressure on the application layer of enterprise software, and many screens, workflows, and integrations will be regenerated or custom-built. But the durable value of systems like PLM sits in the data foundation: structured, controlled, accumulated product knowledge. That layer cannot be reliably generated from prompts, so the likely outcome is AI-built applications running on top of stable data platforms rather than wholesale replacement.

How does OpenBOM support teams building with AI? 

OpenBOM provides cloud-native product data management with item catalogs, BOMs, revision control, and procurement data, exposed through open REST APIs. Teams use Claude and other AI tools to build custom automation that reads from and writes to a shared, controlled product data layer instead of fragmented scripts.