Earlier last week, my attention was caught by multiple articles discussing a trend in which employees are maxing out their AI token usage because of significant management pressure to increase AI adoption. Here is a Fortune article – and you can also see multiple discussions on Reddit.
The discussion made me think about various ways of resistance. Are we dealing with “Luddites of 21st century”? In my article today, I collected patterns that I see in AI adoption.
The most dangerous resistance to AI in PLM does not look like resistance. Here is how to recognize it and whether you are doing it yourself.
The original Luddites were not irrational. They were skilled textile workers who correctly understood that the industrial machines arriving in early nineteenth-century England would destroy their economic position. Their resistance was wrong as a strategy, but their analysis was right. The machines did change everything.
I think about this when I watch how PLM practitioners, vendors, and organizations are responding to AI.
The obvious version of AI resistance, denial, dismissal, waiting it out, is real but relatively rare in PLM circles today. Most people acknowledge that AI is coming. Most vendors have added something to their product roadmap. Most practitioners have at least experimented with a chatbot.
But there is a more interesting and more dangerous form of resistance. It is not visible as resistance. It looks like adoption. It feels like progress. It produces press releases, roadmap slides, and internal success stories. And it protects existing workflows from real change just as effectively as outright rejection would.
The new AI Luddites in PLM are not the people who say no. Many of them are the people who say yes, but only in ways that change nothing important.
Here are seven patterns I see emerging. Some are individual behaviors. Some are organizational. Some are already visible in how vendors are positioning their products. All of them are worth recognizing, because the gap between genuine AI transformation and these patterns will define which companies gain advantage and which ones spend the next five years wondering why AI did not deliver what they expected.
1. The AI Denier: Dismissing AI in PLM as “Not Ready for Engineering”
This one is the most visible and probably the least common among serious PLM practitioners at this point.
The AI denier in PLM says things like: “AI cannot understand a product structure.” “Our data is too specialized.” “LLMs hallucinate and we cannot trust them with engineering decisions.” “This is just autocomplete. It is not intelligence.”
Some of this skepticism is healthy. Engineering and manufacturing are not casual domains. A wrong component, an incorrect revision, a missed supplier constraint, or an overlooked regulatory requirement can create real operational and business consequences. Skepticism about AI in high-stakes processes is reasonable.
But rejection is not a strategy.
We have seen this pattern before in PLM. In the early 2000s, experienced PDM administrators dismissed SaaS and cloud PLM with the same logic: “Our files are too large.” “Our processes are too complex.” “We cannot trust our IP in the cloud.” Some of those organizations are still running the same on-premise system today. The technology matured around them. The gap grew.
The danger for AI deniers is not that they are wrong about current limitations. They are often right. The danger is that they confuse current limitations with permanent ones. AI models are improving faster than any previous enterprise software category. The people and companies learning now will be much better positioned when the technology matures.
2. The Tokenmaxxer: Measuring AI Success by Usage, Not by Better PLM Decisions
This pattern is almost the opposite of denial, and in some ways it is more insidious. I’d say, it is the closest to the original approach of luddites to destroy machines. You can max token usage and bring AI adoption to halt or make it too expensive.
The tokenmaxxer measures AI adoption by activity rather than outcomes. The metric is how many queries were handled, how many prompts were processed, how many tokens were consumed. In an organizational context, it becomes: how many AI features were shipped, how many AI-assisted sessions were logged, how many users interacted with the assistant this month.
In PLM, this pattern shows up most clearly at the vendor level. A PLM platform adds an AI assistant to every major screen. The release notes describe the product as “AI-powered.” The marketing materials show engineers asking questions in natural language and getting answers instantly. The metrics show high engagement. The underlying data model has not changed. The BOM is still exported to Excel for cross-functional review. Change history is still partial. Supplier data is still disconnected from the item master. The reason a deviation was approved eighteen months ago still lives in someone’s email.
The AI is active. The intelligence is shallow.
This is the engineering equivalent of measuring software developers by lines of code. It is easy to count, easy to gamify, and almost completely disconnected from value.
The question should not be how many AI interactions happened. The question should be: did we make a better decision, find a problem earlier, reduce a cycle time, or preserve context that would otherwise have been lost?
3. The Prompt Tourist: Trying AI Once with No Context and Concluding It Doesn’t Work
The prompt tourist visits AI and concludes they have seen everything.
In PLM, this looks like the engineering manager who spends an afternoon with an AI chatbot, asks three or four generic questions about BOM management or PDM best practices, gets generic answers, and reports back: “We tried it. It does not understand our business.”
They are not wrong that the answers were generic. They are wrong about why.
A general-purpose AI model asked a vague question without product context, organizational constraints, system environment, or specific decision criteria will produce a vague answer. This is not a model failure. This is a context failure. It is the equivalent of calling a highly experienced consultant, giving them no background, asking “what should we do about our PLM,” and then concluding that consultants are useless when they cannot give a specific answer in five minutes.
The skill the prompt tourist is missing is not prompting in the technical sense. It is the ability to define a problem, expose the relevant constraints, provide the right context, and evaluate whether the answer is useful given what was asked. This is not a new skill. It is what good engineers already do when working with people. AI makes it more important and more explicit.
Prompt tourists are common, and they create a specific organizational problem: they report their experience as evidence, which then shapes decisions about investment, adoption, and strategy. A single afternoon of casual experimentation becomes the data point that delays a more serious exploration by two years.
4. The Chatbot Decorator: Adding an AI Interface to PLM Without Changing the Underlying Data
This is probably the most widespread pattern in PLM right now, and it deserves the most attention.
The chatbot decorator adds a natural language interface on top of existing systems and calls it AI transformation. The interface is real. The transformation is not.
Here is how it works in practice. An organization connects an AI assistant to its PLM document repository. Engineers can now ask questions in plain English. The assistant retrieves documents, generates summaries, and answers basic questions about product information. The demo looks impressive. The announcement is well received.
But the underlying situation has not changed. The BOM is incomplete. Change history is partial because some changes were handled offline. The approved vendor list lives in a separate system that is not connected. Supplier lead times, cost history, and open supply risk flags are in the ERP. The context behind why a specific component was selected, including the technical trade-off discussion, the alternative that was rejected, and the supplier negotiation that happened in parallel, exists in a combination of emails, meeting notes, and the memory of two engineers who were in the room.
When an engineer asks the AI assistant a real question, “what is the best substitute for this resistor given our current supplier constraints and cost targets on this assembly,” the assistant does not have enough to answer well. It has documents. It does not have connected, current, permission-aware product context.
The result is a plausible-sounding answer that may be wrong in ways the engineer cannot immediately detect. This is worse than a clearly wrong answer, because the error is not obvious.
Chatbot decoration is AI wallpaper on top of old workflows. It satisfies the requirement to “do something with AI” without creating the conditions for AI to actually help.
5. The Automation Absolutist: Automating PLM Decisions Without Preserving Human Accountability
The automation absolutist believes that if AI can do a task, AI should do the task, and that expanding automation is always progress.
In PLM, this pattern shows up in discussions about autonomous agents, self-managing workflows, and removing human steps from processes to improve speed. Some of this is correct. Many steps in PLM workflows are repetitive, manual, and add no judgment value. Automating them is genuinely useful.
The problem is when automation extends to decisions that carry accountability.
Consider an organization that builds an AI agent to auto-approve engineering change orders below a certain cost threshold. The logic seems reasonable: small changes do not need the same scrutiny as large ones. The agent reviews completeness, checks for obvious conflicts, and approves. Speed improves. The queue shrinks.
Then a batch of components with a subtly incorrect tolerance stack-up ships. The issue was detectable if someone had looked at the full assembly context. The agent was not wrong about the individual ECO. It was missing the cross-system view that a human reviewer would have brought from experience and awareness of what else was in flight.
The question in this case is not whether AI made an error. The question is who is accountable for the decision and whether the organization designed the workflow to preserve that accountability.
Automation absolutists miss the distinction between automating task execution and delegating decision ownership. These are not the same thing. AI can prepare, compare, flag, summarize, and recommend. In many cases it can execute. But in decisions that carry business risk, regulatory implication, customer impact, or safety consequence, the accountability question must be answered before the automation question.
6. The Context Minimalist: Expecting AI to Reason About Products Without Product Context
This may be the most consequential pattern for AI adoption in PLM over the next three to five years.
The context minimalist connects AI to whatever data is easiest to reach, a document repository, a PLM search index, a BOM export, and expects the AI to perform as if it has full product understanding. When the results are poor, the conclusion is that AI is not ready for PLM.
The real issue is not the model. The real issue is that the organization has not captured and organized the context the model needs to be useful.
Product development context in most companies is not in one place. CAD files manage geometry. PDM manages revisions and file relationships. PLM manages items, changes, and process history. ERP manages purchasing, inventory, costing, and production. Spreadsheets fill the gaps. Email carries decisions. Meetings carry context that never gets recorded. And the people who were in the room carry the rest in their memory.
Humans navigate this surprisingly well. We ask colleagues. We search emails. We remember what happened. We read between the lines of a change record. We know which supplier relationship is fragile and why.
AI cannot do this without help. An AI model that can reason about a specific product decision, not best practices in general, but this product, this supplier, this configuration, this customer commitment, this manufacturing constraint, needs that context to be available, connected, and trustworthy.
When context is missing, AI output is generic. When AI output is generic, engineers correctly observe that it is not useful. When engineers observe that AI is not useful, organizations slow down adoption. The context minimalist has created a self-reinforcing failure mode and attributed it to the technology.
This is the most important structural problem for AI in PLM, and it is why product memory architecture is not a nice-to-have. It is the prerequisite for AI to work at the level PLM practitioners actually need.
7. The Old-Process Protector: Fitting AI Into Existing PLM Workflows Instead of Redesigning Them
The old-process protector is not against AI. They are against change.
They want AI, but they want it to fit perfectly into the existing workflow without modifying anything. They want the same meetings, the same approval steps, the same document handoffs, the same disconnected systems, the same after-the-fact data entry. They want a faster version of the old process, not a different one.
This is understandable. Existing processes define roles, responsibilities, and organizational boundaries. They feel safe because they are familiar. Changing them requires political negotiation, retraining, and the discomfort of admitting that the old way was not optimal.
Consider the engineering change management process. Many companies have ECO workflows with twelve to twenty approval steps, built around the assumption that routing a document to a human inbox is the only way to ensure each stakeholder has reviewed the change. This made sense when review meant physically looking at a document and signing off.
AI changes what is possible. An AI agent could monitor a proposed change, pre-screen for completeness, identify downstream impacts across the BOM and manufacturing process, surface the relevant approval history for similar changes, and flag open questions before any human touches the record. The human review step can remain, but the human now arrives with far more context and far less hunting.
The old-process protector insists that every step remain exactly as it was, because changing the process feels riskier than keeping it. The AI gets inserted as a helper inside the old structure. The fourteen-day ECO cycle stays fourteen days. The ROI is near zero. The conclusion is that AI did not deliver value.
The real conclusion should be that the process was never redesigned to use AI.
The Real Divide: Who Will Gain Advantage from AI in PLM
The original Luddites lost not because they were wrong to resist, but because resistance could not stop what was already underway.
The new AI Luddites in PLM face the same situation. AI is not arriving in PLM. It has arrived. The question now is not whether to engage with it, but how honestly.
The real divide will not be between companies that use AI and companies that do not. It will be between companies that use AI to ask harder questions about their workflows and companies that use AI to avoid asking them.
The AI denier falls behind because they refuse to learn. The tokenmaxxer wastes resources measuring the wrong things or overspending expensive tokens. Eventually, tokens will be cheaper and companies will learn how to track them. The prompt tourist underestimates AI because they never gave it real context. The chatbot decorator mistakes interface changes for transformation. The automation absolutist creates risk by removing accountability without replacing it. The context minimalist blames the model for a data architecture problem. The old-process protector spends budget on AI that reinforces yesterday’s workflow.
The companies that gain real advantage will be the ones that ask a harder set of questions: What context are we not capturing today? What decisions should remain human and why? What workflows were designed around human limitations that no longer apply? What would we build if we were starting the process from scratch with AI as a participant, not an add-on?
These are not technology questions. They are design questions. And answering them honestly, without defaulting to one of the seven patterns above, is where the real work of AI adoption in PLM begins.
Just my thoughts…
What patterns are you seeing in your organization or in the industry? I would be interested in the conversation.
Best, Oleg
Oleg Shilovitsky is the co-founder and CEO of OpenBOM and the author of the Beyond PLM blog, where he writes about the future of product development, PLM, and manufacturing technology.
