Back
The topic of industrial AI today is one of the most widely discussed, yet it remains complex to fully grasp. In Russia, hundreds of projects have been launched and tens of billions of rubles spent, yet there is still no systematic answer to the question of what actually works. In the first part of our extensive interview, Jimsher Chelidze* explained why the race for frontier models is not our path, and that the true competitive advantage lies on the shop floor: in data, engineering, and access to real-world facilities.
![1]()
Let me begin not with a forecast, but with a fact—to ensure our discussion remains substantive.
At CIPR 2026, two AI assistants for plant engineers, powered by the GigaChat neural network, were unveiled: a process engineering assistant that generates a prototype manufacturing process based on design documentation, and a design engineering assistant for reverse engineering, which reconstructs an editable digital CAD model from a physical part or drawing. Pilot projects are currently underway at Tekhnodinamika, Tyazhmash, and the United Engine Corporation. Meanwhile, Nornickel has reported on the integration of generative AI into industrial design, significantly reducing both the turnaround time for design documentation and the resource requirements for design teams.
Pay attention to what is actually being compressed. Not the profession itself. A specific phase of work is being compressed—the initial generation of design options and the routine preparation of documentation. This is precisely the phase where junior engineers used to learn and grow. Keep this in mind—I will return to it at the end, as it holds the primary risk.
And here I will mention something often dismissed as a technical detail, yet it determines everything. Demanding verification from an engineer while providing only the model’s raw output is pointless. Verification is physically possible only when the system shows its sources: a link to a specific clause in your manufacturing process, a specific drawing, or a specific customer complaint in your database. Not “the model thinks,” but “the basis is these three documents—see for yourself.”
This is an architectural requirement for the solution, not a mere wish for the employee. An assistant without source traceability is just a plausibility generator, and no engineer will verify it: they will simply click “accept.” Before demanding new behavior from people, give them a tool that makes this behavior possible. Otherwise, you will get a ritual instead of actual control.
Shift Two: From a Single Option to Managing the Option Space. When generation costs pennies, the value shifts to defining constraints and selection criteria: tolerances, available tooling, the actual machine pool, cost efficiency, maintainability, and safety requirements. The ability to precisely formulate constraints becomes the core engineering competency. Essentially, this is a return to the old culture of the technical specification—except now, a poor specification penalizes you not in six months, but in five minutes, and on an industrial scale.
Shift Three: From Personal Expertise to Knowledge Capitalization. An assistant that actually works is one trained on your design documentation, your manufacturing processes, your customer complaints, and your failure reports. This means the knowledge that has lived in the head of a shop floor veteran for thirty years must be converted into data.
And here begins the most underestimated challenge. This changes the social contract within the enterprise. Informal knowledge ceases to be an employee’s personal insurance against dismissal and becomes a corporate asset. This will be the main source of resistance—far greater than the fear of “robots replacing us.” People are not resisting the machine. They are resisting the loss of their monopoly on knowledge. Until you address this issue honestly—through status, compensation, and the role of a mentor-validator—you will not get the data. And without data, the assistant will remain just a beautiful demo.
● Problem formulation and constraint management. A poor specification plus AI equals quickly and beautifully formatted nonsense. Constraints are the engineer’s new interface.
● Data literacy. Understanding where the training dataset came from, what model drift is, and why an assistant that is flawless on a mass-produced part fails during single-unit production.
● Traceability and accountability for decisions. The signature will remain human. The engineer must be able to explain the decision—not just say, “the model said so.”
● The engineer as a “translator” between the shop floor and the data scientist. This is the most scarce and underestimated role. In my portfolio management practice, the absence of this role ruined projects more often than poor algorithms.
The talent pyramid in engineering is built on the premise that an individual goes through the routine and develops intuition through it: why this part behaves this way, why this manufacturing process won’t work on our machine. If the assistant takes over the routine, intuition does not form. And verification without intuition is impossible: you just click “accept.”
The answer here is not to “keep AI away from beginners”—that battle is lost; they are already using it, they just aren’t telling you. The answer lies in redesigning training: a junior engineer learns not from grunt work, but from analyzing the model’s mistakes. Give them a hundred assistant outputs, twenty of which are incorrect, and task them with finding and justifying the errors. This is a much faster and more rigorous simulator than three years of fetching coffee. But it must be built deliberately, not left to happen on its own. It won’t.
● Identify which 2–3 phases of the engineer’s work are actually being compressed by AI, and measure their share in labor costs before implementation. Without a baseline, you will never prove the effect—neither to yourself nor to the board of directors.
● Introduce the role of the model owner—the person responsible for the assistant’s quality after launch. Without it, the model will quietly degrade, and in a year, no one will use it.
● Answer the question of “who signs off” before implementation, not after the first controversial case.
Technology.
● Source traceability must be a mandatory requirement in the technical specification. Without it, verification turns into a ritual.
● Accuracy metrics on your own dataset, not the vendor’s. And a model quality dashboard, for which its owner is responsible.
● Formalize implicit knowledge: customer complaints, failures, “we don’t do it this way here.” This is the training dataset, and you must start with it, not with choosing a model.
People.
● During the adaptation phase, pay for usage, not just for the result. This removes the fear of making a mistake—which is the main bottleneck.
● Honestly resolve the issue with knowledge bearers. The veteran whose expertise you are extracting into the database must receive a new status—mentor-validator, domain model owner—not the feeling that they have dug their own grave.
● Rewrite the engineer training program for verification, not generation.
In five years, the engineer will not disappear. The engineer whose value lay in the speed of their hands will vanish. What will remain is the engineer whose value lies in the quality of their judgment. This is good news—but only for those who have started restructuring talent development today, rather than planning to read about it in an analytical report in three years.
28 July, 2026
Expert Interview | Jimsher Chelidze: “We May Gain Three Years of Productivity Only to Lose a Generation of Expertise”
The topic of industrial AI today is one of the most widely discussed, yet it remains complex to fully grasp. In Russia, hundreds of projects have been launched and tens of billions of rubles spent, yet there is still no systematic answer to the question of what actually works. In the first part of our extensive interview, Jimsher Chelidze* explained why the race for frontier models is not our path, and that the true competitive advantage lies on the shop floor: in data, engineering, and access to real-world facilities.
In the second part of the conversation, the expert turns to the crucial “human” question: how is the engineer’s role evolving as AI assistants enter the shop floor? Read on to learn why verification is more demanding than independent work, who will remain in the profession and who will leave, and how to avoid losing a generation of expertise while gaining three years of productivity.
The interview is published in full, without abridgment.
*Jimsher Chelidze is the CEO of Chelidze & Partners LLC, Business Partner for Digital Development at Horizontal Drilling Center LLC, and a member of the FBA EAC Industry Committee. He is also the author of articles and publications on the philosophy of technology, five books on digital transformation, and the developer of two AI products. He has practical experience working with Gazprom Neft, LUKOIL, the Russian Ministry of Energy, Gazprom Bureniye, and other industrial companies in Russia, Kazakhstan, and China.
AI assistants for process and design engineers are already being tested at major enterprises. How will the engineer’s role evolve over the next five years, and which competencies will become critical?
Let me begin not with a forecast, but with a fact—to ensure our discussion remains substantive.
At CIPR 2026, two AI assistants for plant engineers, powered by the GigaChat neural network, were unveiled: a process engineering assistant that generates a prototype manufacturing process based on design documentation, and a design engineering assistant for reverse engineering, which reconstructs an editable digital CAD model from a physical part or drawing. Pilot projects are currently underway at Tekhnodinamika, Tyazhmash, and the United Engine Corporation. Meanwhile, Nornickel has reported on the integration of generative AI into industrial design, significantly reducing both the turnaround time for design documentation and the resource requirements for design teams.
Pay attention to what is actually being compressed. Not the profession itself. A specific phase of work is being compressed—the initial generation of design options and the routine preparation of documentation. This is precisely the phase where junior engineers used to learn and grow. Keep this in mind—I will return to it at the end, as it holds the primary risk.
Three Shifts That Will Reshape the Engineer’s Work
Shift One: From Generation to Verification. The engineer ceases to be the author of the first draft and becomes an editor and validator. This is cognitively more demanding, not less. Critiquing a plausible but incorrect manufacturing process is harder than creating one from scratch: the model makes mistakes confidently, elegantly, and in the correct format. It gives no signal saying, “I’m not sure about this.”And here I will mention something often dismissed as a technical detail, yet it determines everything. Demanding verification from an engineer while providing only the model’s raw output is pointless. Verification is physically possible only when the system shows its sources: a link to a specific clause in your manufacturing process, a specific drawing, or a specific customer complaint in your database. Not “the model thinks,” but “the basis is these three documents—see for yourself.”
This is an architectural requirement for the solution, not a mere wish for the employee. An assistant without source traceability is just a plausibility generator, and no engineer will verify it: they will simply click “accept.” Before demanding new behavior from people, give them a tool that makes this behavior possible. Otherwise, you will get a ritual instead of actual control.
Shift Two: From a Single Option to Managing the Option Space. When generation costs pennies, the value shifts to defining constraints and selection criteria: tolerances, available tooling, the actual machine pool, cost efficiency, maintainability, and safety requirements. The ability to precisely formulate constraints becomes the core engineering competency. Essentially, this is a return to the old culture of the technical specification—except now, a poor specification penalizes you not in six months, but in five minutes, and on an industrial scale.
Shift Three: From Personal Expertise to Knowledge Capitalization. An assistant that actually works is one trained on your design documentation, your manufacturing processes, your customer complaints, and your failure reports. This means the knowledge that has lived in the head of a shop floor veteran for thirty years must be converted into data.
And here begins the most underestimated challenge. This changes the social contract within the enterprise. Informal knowledge ceases to be an employee’s personal insurance against dismissal and becomes a corporate asset. This will be the main source of resistance—far greater than the fear of “robots replacing us.” People are not resisting the machine. They are resisting the loss of their monopoly on knowledge. Until you address this issue honestly—through status, compensation, and the role of a mentor-validator—you will not get the data. And without data, the assistant will remain just a beautiful demo.
Competencies That Will Become Critical
● Domain depth—the physics of the process, not just breadth. The paradox is that the more accessible AI becomes, the more valuable a deep understanding of the essence. Only someone who understands why can verify the model’s output, not just what is written.● Problem formulation and constraint management. A poor specification plus AI equals quickly and beautifully formatted nonsense. Constraints are the engineer’s new interface.
● Data literacy. Understanding where the training dataset came from, what model drift is, and why an assistant that is flawless on a mass-produced part fails during single-unit production.
● Traceability and accountability for decisions. The signature will remain human. The engineer must be able to explain the decision—not just say, “the model said so.”
● The engineer as a “translator” between the shop floor and the data scientist. This is the most scarce and underestimated role. In my portfolio management practice, the absence of this role ruined projects more often than poor algorithms.
Now, the Main Risk That Is Unacceptably Underdiscussed
If AI takes away the junior engineer’s work, where will the senior engineer capable of verifying the AI come from in ten years? We risk gaining three years of productivity only to lose a generation of expertise.The talent pyramid in engineering is built on the premise that an individual goes through the routine and develops intuition through it: why this part behaves this way, why this manufacturing process won’t work on our machine. If the assistant takes over the routine, intuition does not form. And verification without intuition is impossible: you just click “accept.”
The answer here is not to “keep AI away from beginners”—that battle is lost; they are already using it, they just aren’t telling you. The answer lies in redesigning training: a junior engineer learns not from grunt work, but from analyzing the model’s mistakes. Give them a hundred assistant outputs, twenty of which are incorrect, and task them with finding and justifying the errors. This is a much faster and more rigorous simulator than three years of fetching coffee. But it must be built deliberately, not left to happen on its own. It won’t.
What to Do — Across Three Pillars
Management.● Identify which 2–3 phases of the engineer’s work are actually being compressed by AI, and measure their share in labor costs before implementation. Without a baseline, you will never prove the effect—neither to yourself nor to the board of directors.
● Introduce the role of the model owner—the person responsible for the assistant’s quality after launch. Without it, the model will quietly degrade, and in a year, no one will use it.
● Answer the question of “who signs off” before implementation, not after the first controversial case.
Technology.
● Source traceability must be a mandatory requirement in the technical specification. Without it, verification turns into a ritual.
● Accuracy metrics on your own dataset, not the vendor’s. And a model quality dashboard, for which its owner is responsible.
● Formalize implicit knowledge: customer complaints, failures, “we don’t do it this way here.” This is the training dataset, and you must start with it, not with choosing a model.
People.
● During the adaptation phase, pay for usage, not just for the result. This removes the fear of making a mistake—which is the main bottleneck.
● Honestly resolve the issue with knowledge bearers. The veteran whose expertise you are extracting into the database must receive a new status—mentor-validator, domain model owner—not the feeling that they have dug their own grave.
● Rewrite the engineer training program for verification, not generation.
In five years, the engineer will not disappear. The engineer whose value lay in the speed of their hands will vanish. What will remain is the engineer whose value lies in the quality of their judgment. This is good news—but only for those who have started restructuring talent development today, rather than planning to read about it in an analytical report in three years.
Membership
BECOME FBA EAC MEMBER
FBA EAC is a unique platform that represents and promotes the interests of its members through the support of their business activities in the countries of the Association's presence.
Feedback