A few weeks ago, I asked a question that sounded provocative, but also increasingly practical: can we vibe code the next PLM?
The question came from multiple conversations I had with customers, prospects, and people in the industry. The idea was simple. If AI can generate applications, scripts, workflows, dashboards, and integrations, what prevents a company from building its own PLM system using AI? In my earlier article, Can We Vibe Code the Next PLM?, I came to a “yes and no” conclusion. Yes, AI can generate many useful PLM-related applications. No, it cannot magically replace the deeper foundation of product knowledge, relationships, lifecycle context, and history that makes PLM implementation valuable over time.
Since then, I’ve been thinking about the next step. Maybe the most interesting question is not whether we can vibe code a PLM application. Andreas Lindethal made an interesting comment asking if we can vibe code a system better than mainstream platforms. I don’t think there is a goal like this. At least, I didn’t see it that way. I think the bigger question is this: what happens when the entire process of PLM implementation becomes AI-native?
Two recent discussions pushed me in this direction. The first was a Y Combinator conversation about how to build an AI-native company. The specific point that stayed with me was not simply “use more AI tools.” The deeper argument was that AI-native companies are designed around intelligent closed loops: work produces observable artifacts, those artifacts become queryable context, AI reasons over that context, proposes actions, humans review them, and the system learns from the outcome. The company itself becomes a continuous feedback machine. That is a very different operating model from “we added a chatbot to our workflow.”
The second was a video on how software development is being restructured by AI. The key shift it described is that development is moving from a process where humans write every specification and every line of code, toward a process where people express intent, assemble context, review AI-generated output, and refine in continuous iterations. The developer’s job does not disappear. The interface to the work changes fundamentally.
Both of these ideas — closed loops and intent-driven creation — apply directly to how PLM implementation gets done.
This made me think about PLM again. For the last 25 years, PLM implementation was mostly a translation process. A company described its requirements. Consultants and implementation teams translated those requirements into configurations, customizations, workflows, data models, integrations, reports, and training materials. The process was slow, expensive, and often frustrating. But it was also necessary because every company is different.
AI may change this equation. Not by eliminating implementation, but by changing what implementation means.
Why Out-of-the-Box PLM Has Always Been a Compromise
Every PLM sales cycle eventually gets to the same discussion: “How much is available out of the box?”
Customers ask this question for a very good reason. They don’t want to spend a fortune on customization. They don’t want a three-year implementation. They don’t want to depend on a small army of consultants every time they need to change a workflow or add a new business rule. “Out of the box” sounds safe. It sounds predictable. It sounds like the opposite of expensive customization.
At the same time, no manufacturing company is truly out of the box. To apply so-called “best practices” or “industry practices” sounds promising, but this is just another way to package out of the box for customers.
Every company has its own product history. It has old part numbers, legacy systems, new ways of managing part numbers, legacy classification schemes, CAD naming conventions, supplier preferences, ERP constraints, ECO habits, spreadsheet templates, undocumented shortcuts, tribal knowledge, and organizational scars. Some processes exist because they are optimal. Others exist because a critical customer once demanded something special. Some are formal. Many are informal. Some are written in procedures. Others live in people’s heads.
So customers wanted two things that were always in tension. They wanted standard software because customization was expensive. But they also wanted the system to reflect the way their company actually works.
This contradiction has defined PLM implementation for decades.
The problem was never that companies did not want standard software. Of course they did. Nobody wakes up in the morning excited to fund a multi-year customization project. The problem is that product development is full of context. A PLM system enters an organization that already has years of accumulated decisions, exceptions, tools, files, spreadsheets, suppliers, and habits.
We usually call this “requirements.” But I think this word is too small.
What companies really bring to a PLM project is not only requirements. They bring the history of how they work, their existing processes, and their historical data. I call the entire history of the product lifecycle — including the reasons why specific events happened and all the context around them — Organizational or Product Memory. Product Memory is the accumulated history of how a company’s products were built, changed, decided upon, and refined over time, including the context, decisions, and exceptions that requirements documents never capture.
How Flexible PLM Tried to Solve the Customization Problem
The PLM industry understood this problem a long time ago. This is why “flexible PLM” became such an important idea.
Rigid systems could not reflect the complexity of real product development. Companies needed flexible data models, configurable workflows, custom objects, relationships, forms, permissions, lifecycle states, business rules, and integrations. Flexibility became the answer to the fact that manufacturing companies are different.
Flexible PLM platforms succeeded because they recognized a simple truth: there is no single universal process for product development, engineering release, procurement handoff, supplier collaboration, or manufacturing preparation. Even companies in the same industry can behave very differently. Their products, supply chains, regulatory constraints, engineering cultures, and system landscapes are different.
Flexible PLM was a major step forward because it allowed systems to adapt to companies instead of forcing companies to fully adapt to software.
But flexibility had a cost. In most cases, flexibility requires experts. Someone needed to translate business reality into a data model. Someone needed to define objects, relationships, workflows, states, permissions, and reports. Someone needed to build integrations. Someone needed to maintain the customization. Someone needed to explain why the system behaved one way and not another.
So the bottleneck moved. It was no longer only about whether the software could support the desired process. Often, it could. The bottleneck became implementation capacity.
Flexible PLM made many things possible, but “possible” did not always mean simple, fast, or affordable.
The Hidden Cost of PLM Flexibility: Why Configuration Still Fails
There is an uncomfortable truth about many PLM implementations. The most expensive part is not always the software. It is the translation of company reality into software behavior.
A company says, “We need change management.” But what does it mean?
Does engineering initiate the change? Does manufacturing review it? Does procurement approve supplier impact? Does quality need to sign off? Are all parts treated the same way? What happens when mechanical, electrical, and software components are released differently? Who and how make validation of changes across multiple disciplines? How is customer data getting involved and checked? How do you handle preliminary parts? What about substitute components? What if ERP already has a part number, but engineering uses another one? What if a supplier change does not require a full engineering change? There are a million questions like that. These questions are not edge cases. They are the real work.
The old PLM implementation model tried to answer them through workshops, requirement documents, process diagrams, configuration sessions, customization, testing, user acceptance, and rollout. It worked, but it was heavy.
This is why OOTB became so attractive. It promised to reduce the weight. But OOTB often solved the cost problem by ignoring the context problem. It said, “Here is the standard process.” The company then had to decide whether to adapt itself to the process or pay to change the process.
Flexible PLM solved the context problem better, but often reintroduced the cost problem.
AI creates a possibility to rethink both.
How AI-Native Thinking Changes PLM Implementation Forever
The AI-native company discussion is interesting because it does not simply say, “Use AI to be more productive.” That is already happening everywhere. The deeper idea is that a company can be designed differently when AI is part of the operating model from the beginning.
An AI-native company tries to make work observable, queryable, and continuously improved. It does not only automate tasks. It creates loops. Work produces data. Data creates context. Context helps AI reason. AI proposes actions. Humans review and correct. The system learns from the outcome.
This idea is very relevant to PLM implementation.
Traditional PLM implementation is mostly a project. You analyze requirements, configure the system, migrate data, train users, and go live. After that, changes become another project, another change request, another customization, another implementation phase.
But what if PLM implementation becomes a loop?
Instead of only asking people what they need, AI can analyze what already exists. CAD files, BOMs, spreadsheets, ECOs, legacy vaults, existing PDM/PLM software, ERP imports and exports, supplier lists, purchasing history, quality issues, service records, meeting notes, emails, and previous decisions can become implementation context. AI can look for patterns. It can suggest workflows. It can generate views. It can propose validation rules. It can identify missing data. It can create role-specific user experiences.
This changes the question.
The old question was: how configurable is your PLM system?
The new question might become: can your PLM environment understand our organizational and product context and generate what we need?
Vibe Coding as the New Interface for PLM Configuration and Implementation
This is where vibe coding becomes more than a software development trend.
In the first wave, vibe coding means that a person can describe an application and AI can generate a working prototype. This is already useful in PLM-adjacent work. A user can ask for a BOM validation tool, a dashboard, an import utility, a supplier comparison report, or a small integration script. AI can generate something useful quickly.
But the next wave is more interesting. Vibe coding can become the new interface for PLM implementation itself.
Instead of writing a detailed specification that says: “Create an ECO workflow with seven states, three approval roles, two conditional transitions, a supplier impact report, and an ERP export trigger,” a user may describe the business situation:
“We release mechanical parts from SolidWorks, electronics from Altium, and the purchasing team needs a clean supplier-ready BOM before anything goes to ERP. Those are examples of our mechanical and electronic designs. This is a document form we use for ECO. This is an example of the Excel we are using today to create RFQ/PO and send to procurement. We often miss manufacturer part numbers and approved vendors. I want a release workspace that checks the BOM, creates tasks for engineers, highlights missing supplier data, and prepares the handoff for purchasing.”
This is not code. It is not even a traditional requirement document. It is a description of intent and context.
AI can translate this description into a first version of a system configuration, data model, workflow, validation rules, user interface, tasks, dashboards, and integration mappings. Humans still need to review it. The organization still needs governance. The data model still matters. But the starting point changes.
The prompt becomes the first draft of implementation.
This is powerful because most PLM pain lives in the last mile. It is not always the core database or lifecycle engine. It is the specific way a company wants to review a BOM, prepare a change, validate supplier data, compare revisions, package information for manufacturing, or hand off data to ERP. The pain of complex user experience, the clicks you need to accomplish a specific goal or find the data — these are exactly the places where traditional customization was too expensive and OOTB was too generic.
AI can compress the distance between “this is how we work” and “here is a system behavior that supports it.”
Why AI-Generated PLM Needs Product Memory to Work
There is a danger here. It is easy to get excited about generated applications and forget the foundation.
AI can generate a beautiful screen. It can generate a workflow. It can generate a form. It can generate code. But if it does not understand the company’s product history, decisions, relationships, rules, and exceptions, the result will be shallow.
This is why Organizational and Product Memory, described in a way that AI can understand, becomes so important.
Requirements are what people say they need during implementation. Product Memory is what the company has actually done over time. The difference is critical.
Requirements are often incomplete. They are influenced by organizational politics, memory gaps, current frustrations, and who happened to be in the workshop. Product Memory is richer. It includes product structures, revisions, changes, decisions, suppliers, exceptions, issues, workarounds, and outcomes. It shows not only what the company wants, but how the company actually behaves.
Future AI-native PLM implementation will need this memory as its context foundation.
A company’s Product Memory should include product structures, BOMs, revisions, configurations, CAD references, documents, change history, decisions, supplier data, procurement context, requirements, quality feedback, service history, and implementation decisions. It should also include the informal context that is usually lost: why something changed, who objected, what tradeoff was made, what alternative was rejected, and what happened afterward. It should capture the way an organization works, the documents it produces, and the communication between people in the organization.
Without Product Memory, AI-generated PLM becomes another layer of disconnected automation. It may look modern, but it will repeat the same old problem. It will create tools without continuity.
With Product Memory, AI can generate applications that are grounded in the company’s actual context.
This is the key point: the future PLM system will not be merely configured from requirements. It will be generated and adapted from Product Memory.
From PLM Customization Projects to Continuous AI-Driven Adaptation
Traditional PLM implementation follows a familiar pattern: requirements, configuration, customization, deployment, change requests. This model assumes that implementation is a phase. You define what you need, build it, deploy it, and then manage deviations later.
AI-native PLM suggests a different loop: capture memory, analyze patterns, generate experience, review with humans, deploy, observe usage, preserve new memory, adapt again.
This is a very different way of thinking.
Customization does not disappear. It changes form. It becomes more continuous, more conversational, and more connected to real usage. The system does not need to wait for a large implementation cycle to adapt. A team can describe a problem, generate a process, test it, adjust it, and allow the result to become part of the company’s operating memory.
Of course, this must be governed. PLM is not a playground where every generated workflow should automatically become production. Product data has consequences. Mistakes propagate into purchasing, manufacturing, quality, compliance, and customer delivery. So the future is not “AI does whatever it wants.”
The future is AI-generated adaptation with human review, permissions, lifecycle control, traceability, and policy.
This is where PLM vendors and enterprise architects need to think carefully. The more AI can generate, the more important governance becomes. The easier it is to create new workflows, the more important it is to know which workflows are official. The faster people can generate dashboards, the more important it is to know which data is trusted. The more agents act on behalf of people, the more important it is to understand permissions, audit trails, and accountability.
AI does not remove the need for architecture. It increases it.
The Architecture of AI-Native PLM: Product Memory at the Center
The architecture that emerges is not one giant monolithic PLM system with a chatbot attached to it. It looks more like a stable Product Memory foundation surrounded by generated and semi-generated — vibe coded — applications, agents, workflows, dashboards, and integrations.
The center must be deliberate. It must contain structured product data, relationships, lifecycle context, revisions, change history, permissions, and integration services. This is where product continuity is maintained.
Around this center, AI can generate many things: BOM review agents, release readiness checks, supplier data validation, role-specific workspaces, dashboards, import tools, export packages, training assistants, change impact analysis, and integration utilities.
Some of these applications will be temporary. Some will be refined into production workflows. Some will disappear after solving a specific problem. That is fine. Not every tool needs to live forever. But they need to operate on a shared foundation.
Otherwise, we will recreate the spreadsheet problem.
This is a big risk. If every department starts generating its own PLM-like applications without shared memory and governance, we won’t get a better PLM environment. We will get AI-generated application sprawl. Instead of Excel chaos, we will have beautiful AI-generated chaos. Thinking backward, we can recall the “SharePoint 2.0” situation, when each department was installing its own SharePoint server to manage documents in the way it wanted. The same pattern at a different technology layer.
The lesson is not to stop AI generation. The lesson is to give it a foundation.
What AI-Native PLM Means for PLM Vendors and Platform Strategy
This shift will also change what PLM vendors need to compete on.
Historically, vendors competed on features, modules, industry templates, configurability, data models, and implementation ecosystems. All of these things still matter. But AI-native PLM will push the competition toward a different set of questions: how open is the platform, how accessible is the product data, can the system expose context to AI agents safely, can it preserve decisions and history, can generated applications use stable APIs and data services, and can the platform govern AI-generated workflows with full traceability.
Something Rob McAveney said at Aras ACE 2026 captures this shift well. Standing on the main stage, he put a single sentence on the screen: “The future of PLM will be built by you.” I wrote about the broader context of his keynote in my ACE 2026 retrospective. Whether or not every vendor arrives at the same conclusion, the direction of that statement is significant. It is an acknowledgment that no vendor can anticipate every company’s operating context. The future platform role is to provide the foundation, the openness, and the governance — and then step aside while companies generate the experiences they actually need.
In this world, the winning platform will not necessarily be the one with the largest number of predefined screens. It will be the one that provides the best foundation for AI-native product work: memory, context, structure, openness, governance, and adaptability.
What AI-Native PLM Implementation Means for Manufacturing Companies
For manufacturing companies, this is both exciting and dangerous.
The exciting part is obvious. Companies will be able to move faster. They will be able to create specific workflows without waiting for long development cycles. They will be able to experiment. They will be able to adapt PLM systems to their actual work instead of accepting generic processes or funding expensive customization.
The dangerous part is also obvious. Without discipline, companies can create a new generation of unmanaged tools. AI can make bad processes faster. It can generate applications that look convincing but are disconnected from trusted data. It can automate workflows that were never properly understood.
So the right question for manufacturing companies is not: “Can we use AI to build PLM?”
The better question is: “What should be generated, and what must remain stable?”
User experiences, dashboards, validators, assistants, workflow edges, import/export tools, and many integration utilities are good candidates for AI generation. Product structures, revision history, lifecycle context, permissions, trusted relationships, and change traceability require a stable foundation.
The future will belong to companies that understand this separation.
Conclusion: The Future of PLM Implementation Is Built on Product Memory
My conclusion is that AI will not eliminate PLM implementation. It will change what implementation means.
The old model was based on translating requirements into configuration and customization. The new model will be based on using Organizational and Product Memory as the context foundation and generating adaptive workflows, user experiences, validations, dashboards, and agents around it. Implementation becomes less of a project and more of a practice.
This is not a return to rigid out-of-the-box systems. And it is not unlimited customization by armies of consultants. It is something genuinely new: a company that can describe how it works, give AI the context of its actual product history, and generate the working environment it needs — governed, traceable, and continuously refined.
For that to work, Product Memory is not optional. It is the foundation everything else stands on.
The old question was: how flexible is your PLM system? The new question will be: how well does your PLM environment know your company, your products, and your customers?
Just my thoughts…
Disclaimer: I’m the co-founder and CEO of OpenBOM, a collaborative digital thread platform that helps engineering and manufacturing teams work with connected, structured product data, increasingly augmented by AI-powered automation and insights.
