There is a famous image from the early years of industrialization – workers gathered around a loom, some with hammers in hand. The Luddites were not stupid. They were skilled craftsmen who understood, with unusual clarity, what mechanized production would do to them. They were right about the disruption. They were wrong about the remedy.
The industrial revolution did not destroy people. It destroyed specific forms of work. And in doing so, it forced a painful renegotiation of identity for millions who had built their sense of self around what their hands could do. Textile workers who had spent decades mastering a craft watched machines produce in hours what took them weeks. The fear was not abstract. It was personal.
We are in the opening chapter of a similar shift. But this one is different in an important way. The industrial revolution threatened manual labor. This one threatens knowledge work. The machines in 1820 could outperform your hands. The systems in 2026 can outperform your research, your drafting, your pattern recognition, and your first-pass reasoning. The loom replaced physical dexterity. AI is replacing cognitive dexterity.
And this time, the instinct to smash the machine is understandable — but there is no machine to smash. Intelligence is everywhere. The question is no longer how to protect the loom. It is how to protect the person standing in front of it.
This is what I want to explore before the Share PLM Summit 2026 in Jerez, where I will be joining Martin Eigner and Helena Gutierrez for a workshop and panel discussion on AI, identity, and the future of engineering. The questions we will be discussing are not technical. They are deeply human.
The New Industrial Revolution Is About Knowledge, Not Machines
Every major technological shift makes some previously scarce capability abundant. Industrialization made physical production scalable. A single factory could produce what thousands of craftsmen once made by hand. The scarcity moved. What became valuable was no longer the ability to produce, but the ability to design, manage, and distribute at scale.
AI is doing the same thing to intelligence-like work. The ability to retrieve information, synthesize documents, generate analysis, and produce first-draft reasoning is becoming abundant and inexpensive. A capable AI system can produce a market analysis, a technical comparison, or a structured argument in minutes. What took a team of analysts days now takes a single prompt and a short wait.
But the human reaction across both disruptions follows a recognizable pattern: fear, resistance, identity crisis, and eventually new forms of work. The Luddites feared the loom. Some engineers today fear the model. And in both cases, the fear points at the wrong target.
The industrial revolution did not make people obsolete. It made a specific configuration of skill and labor obsolete, and required people to find their value in a changed landscape. The AI transition will do the same. The question is not whether engineering survives AI. It is what engineering becomes on the other side.
Engineering Identity Was Built on Scarce Knowledge — AI Is Changing That
Engineering knowledge has always been expensive to acquire. Years of product experience, accumulated across programs and failures and design reviews and engineering change cycles — this is not something you pick up quickly. Engineers know this. It shapes how they carry themselves, how they speak in meetings, how they respond to challenges from people who do not share their depth.
This pride is legitimate. It is earned. And it is now under pressure from a direction nobody quite anticipated.
We have been through a version of this before. Google made information retrieval nearly free. Suddenly the person who had memorized a standard or could recall a supplier lead time was no longer the only option in the room. But that shift was incremental. The search engine could surface documents. It could not reason. It could not synthesize. The engineer was still required to make sense of what the search returned.
What is happening now is different in kind, not just degree. Imagine not searching for an answer, but talking to someone who has read the entire internet and can recall, synthesize, and reason across it instantly. That is roughly what engineers are encountering when they open an AI system today. The conversation is fluent. The analysis is plausible. The suggestions arrive with apparent confidence.
The emotional impact of this should not be underestimated. For an engineer who has spent fifteen years accumulating domain expertise, encountering a system that can engage at this level is not merely surprising. It is destabilizing. The foundation of professional identity — the knowledge that took years to build — suddenly feels less exclusive, less special, less load-bearing.
Cheap Intelligence Creates Abundant Options — and a Scarcity of Judgment
I wrote about this shift in December 2025 in the context of PLM consulting and blogging. My argument then was simple: intelligence is cheap, judgment is not. The AC unit is inexpensive. The repair is a luxury. The same logic applies inside engineering organizations, but with a twist that makes it more complicated.
When AI produces answers cheaply, it also produces them abundantly. And abundance changes the problem in a specific way.
I can use AI today to build three different PLM strategies. All three will be well-structured. All three will sound credible. All three will reference the right frameworks and cite the right concerns. Which one is right for your company? That question cannot be answered by the system that generated the options. It requires someone who understands your organization’s maturity, your team’s capacity for change, your data quality, your integration constraints, your political dynamics, and your leadership’s actual appetite for transformation.
The same situation applies to software. Someone recently told me they had built three different PLM systems in a week using AI coding tools, each with a reasonable set of functions. Which one should their company adopt? That question sits entirely outside the competence of the tool that built them.
This is the new engineering reality: cheap intelligence creates an abundance of options, and the scarcity shifts entirely to the judgment required to evaluate them. The engineer’s role is not disappearing. It is inverting. The value is no longer in generating the answer. It is in knowing which answer is right — and being willing to own that decision.
Why Engineers Think in Solutions — and Why AI Needs Problems
There is a pattern I have observed consistently across engineering organizations over many years of PLM work. When you ask engineers to describe their challenge, they almost always describe their solution.
“We need a new BOM structure.” “We need better version control.” “We need integration between our CAD system and ERP.” These are not problems. They are proposed solutions. The actual problem — what is failing, for whom, at what point in the process, with what consequence — is rarely articulated clearly, sometimes because the engineer has already moved past it, and sometimes because they were never asked to hold it still.
This habit is understandable. Engineering organizations reward solutions. The person who identifies a problem and stops there is seen as someone who found a complaint. The person who arrives with a fix is seen as someone who did their job. The cognitive move from problem to solution is so fast and so practiced in most engineering cultures that the problem itself becomes invisible.
AI exposes this gap dramatically. AI systems need the problem, not the solution. They need rich context: what you are trying to achieve, what constraints exist, what has already been tried, what the organizational context looks like, who owns the decision, and what failure looks like. When you give an AI system a proposed solution, you get back a refinement of that solution — which may have nothing to do with the actual underlying need.
Getting engineers to slow down before the solution stage is one of the hardest things I have experienced in this industry. It requires a different kind of discipline. It requires the ability to articulate ambiguity without immediately resolving it. And it turns out that this ability — describing problems with precision and richness — is exactly the skill that makes AI systems useful.
The engineers who will thrive are not the ones who know the most answers. They are the ones who know how to frame the right questions.
Product Memory: The Missing Context Layer Between Engineers and AI
If the problem is that AI needs context and engineers rarely capture it, the deeper question is: where does that context live today, and how much of it is being systematically lost?
The honest answer is that most of it exists outside the engineering systems of record. It lives in email threads and meeting notes and conversations that happened in the corridor. It lives in the memory of the engineer who was in the room when the decision was made. It lives in the slide deck from the design review that was never connected to the BOM item it influenced.
PLM systems and PDMs capture what was decided. They rarely capture why, or what was considered and rejected, or what constraint drove the choice. The CAD file reflects the geometry that survived. It does not reflect the ten geometries that were considered, the supplier feedback that eliminated three of them, or the cost pressure that changed the material selection in the final week.
This is what I have been calling Product Memory: the structured capture of the context, rationale, and decision history that surrounds product data. Not just the authoritative record of what is, but the accumulated understanding of how it got there and why it matters.
The gap here is significant. When you try to connect AI systems to existing engineering environments, the immediate problem is not that the data is unavailable. It is that the data without context produces outputs that look plausible but miss the real constraints. An AI system that can access your BOM but not the reasoning behind the design decisions in it is working with half the picture. It will generate options that violate constraints the engineers already tested and rejected — and nobody will know why until someone with institutional memory raises their hand.
Capturing Product Memory is genuinely hard. It requires changing how engineers communicate decisions, not just how they store files. It requires making the “why” a first-class artifact, not an afterthought. Most organizations have not started this work. Most PLM vendors have not built the infrastructure to support it. This is one of the largest gaps between where AI capabilities are heading and where engineering data environments actually stand.
Leadership Must Re-Architect Work, Not Just Enable AI Tools
A common mistake in enterprise AI adoption is treating it as a productivity layer. The message is something like: your job stays the same, but now you have a faster tool. This framing underestimates the disruption and oversimplifies the response.
Engineers do not just need faster tools. They need a different understanding of what their work is now worth. Telling someone that AI will make them more productive does not address the identity question. It does not answer what happens to the expertise they spent years accumulating. It does not explain what the basis of their professional value will be when intelligence is cheap and ubiquitous.
Leadership’s real responsibility is not AI enablement. It is workflow re-architecture. This means looking honestly at how work actually moves through the engineering organization — where decisions are made, who holds knowledge, what the handoffs are, and where judgment is genuinely required — and redesigning that flow around AI assistance rather than bolting AI onto existing patterns.
This kind of re-architecture changes roles. Some tasks that used to require senior engineers will be handled by AI systems with junior oversight. Some coordination activities that consumed significant human bandwidth will be automated. But the judgment-intensive work — selecting among options, evaluating tradeoffs, navigating organizational dynamics, owning consequences — becomes more important, not less. Leadership must identify where that judgment lives in the organization and build career paths and incentives that reflect its new value.
There is also a human protection dimension that cannot be skipped. The industrial revolution ultimately required social and legal infrastructure — labor laws, worker protections, new forms of education — to manage the transition in a way that did not simply discard the people displaced by machines. The AI transition will require something analogous. Organizations that rush toward AI-enabled productivity without thinking seriously about the engineers inside that transition will create the fear, resistance, and identity crisis that undermines the adoption they are trying to achieve.
Leadership that understands this does not announce AI as a tool. It opens a conversation about what engineering expertise means in a new environment, and creates space for that identity to evolve rather than collapse.
What Is My Conclusion?
Engineers move from knowledge holders to judgment owners. This is a new identity of engineers in the age of AI.
The fear in the room whenever AI comes up in engineering organizations is real and worth naming directly. Engineers are not afraid of tools. They are afraid of becoming irrelevant. They are afraid that the thing they spent their careers building — a reputation for knowing things that others do not — is being devalued faster than they can adapt.
This fear has a historical echo. The Luddites were not fighting against industrialization in the abstract. They were fighting against the loss of a life organized around a specific form of skill. The tragedy is not that they resisted. It is that nobody helped them understand what the transition could look like on the other side.
We have a chance to do better this time. Not because the disruption is smaller — it may be larger — but because we can see it coming with enough clarity to prepare for it thoughtfully.
The engineering identity that survives this transition is not the one that holds the most information. It is the one that exercises the best judgment. The engineer who can formulate a precise problem, evaluate AI-generated options against real constraints, connect product decisions to organizational context, and take responsibility for outcomes — that engineer becomes more valuable in a world of cheap intelligence, not less.
The role shifts from knowledge holder to knowledge orchestrator. From answer provider to judgment owner. This is not a diminishment. It is a redefinition. But it requires organizations, leaders, and engineers themselves to let go of the old measure of expertise and build new ones.
That conversation is what I am most looking forward to in Jerez.
I will be joining Martin Eigner and Helena Gutierrez at the Share PLM Summit 2026 in Jerez de la Frontera, Spain, for a workshop on AI, Identity, and the Future of Engineering, and a panel discussion on how to work in the era of AI. These are the ideas I am bringing into the room.
Share PLM 2026 Summit is just in two weeks.
Best, Oleg
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.
