The Hardest Part of AI Transformation Isn't AI — It's the Dirty Work Nobody Wants to Do

Prologue: From an Old Question to a New One

I remember when I first started out in this industry, I followed a question on Zhihu:

“The internet has been fought to a bloody red ocean, yet smart manufacturing remains a wasteland — why won’t BAT (Baidu, Alibaba, Tencent) step into it?”

Over five years later, this question still has no definitive answer — but the times have changed.

Back then, the subtext was: technology is scarce, industries are waiting to be transformed, and as long as the top-tier players are willing to enter the fray, things will happen. Reality has since falsified that assumption in nearly every way imaginable. And now, LLMs have pushed the “technology is scarce” premise even further. But ask anyone pushing AI adoption in a traditional industry, and odds are they’ll tell you: it’s not that simple.

And so this old question takes on a new form in the AI era:

“AI is already this powerful — why can’t these industries get moving?”

Recently, the term FDE (Forward Deployed Engineer) has suddenly caught fire among major AI companies — and at its core, it’s a response to this very question: if the models are already powerful enough, then the “last mile” bottleneck must lie in the customer site, in the data, in the process, in the organization.

This article is my attempt to answer this old question, drawing on years of observation and hands-on practice.

Let me put the conclusion up front:

What most industries are missing right now isn’t AI — it’s X-Ops.

In other words, the question has never been “should we adopt AI?” — it’s whether this industry, this company, this production line, this workflow has been transformed into a system that AI can plug into, understand, participate in, and feed back into.

Why Has the Software Industry Been Hit Hardest by AI?

It’s not AI. It’s DevOps.

If you look at the fields where AI has truly “broken in” over the past two years, the software industry itself appears to have taken the biggest hit. The reason the software industry has been hit hardest by AI isn’t that its practitioners are the smartest, nor that models happen to favor code — it’s that over the past two decades, it inadvertently transformed itself into the industry that’s easiest for AI to plug into.

AI-Friendliness Wasn’t Born This Way

If I had to list the traits that put AI in its element within the software industry, here’s what I’d pick:

• Open corpus, easy to access: GitHub

• Short feedback cycles: Write code, compile, run tests, see results — feedback arrives in seconds or minutes

• AI-friendly context: Code has comments, modules have interfaces, changes have diffs — nearly everything is textual and structured

• Verifiable correctness: Unit tests, integration tests, CI pipelines provide an automatic grading mechanism for whatever the AI writes

These four pieces together set the iteration flywheel in motion: generate → verify → get feedback → fix → regenerate.

But go back to around the year 2000, and the software industry actually looked a lot more like today’s traditional industries. Release cycles were measured in years. A single version would be polished for months and shipped on a CD. What truly changed everything was the transformation of the delivery model brought by the internet. Software no longer went through “manufacture → copy → ship → install” — instead it became “develop → release → get feedback → update → re-release.” Once this closed loop took shape, the entire way the industry organized itself was forced to restructure:

• Because you needed to release frequently, you needed version control (Git)

• Because you needed to integrate frequently, you needed CI/CD

• Because you needed to collaborate across teams, you needed code review, issue tracking, API documentation

• Because things could go wrong in production at any moment, you needed logging, monitoring, alerting, observability

• Because releasing carried high risk, you needed gradual rollout, rollback, A/B testing

• Because collaboration kept scaling up, you needed Agile, DevOps, SRE (Site Reliability Engineering)

This entire apparatus is what we today collectively call DevOps. But the essence of DevOps isn’t a particular combination of tools — it’s an engineering culture that makes the entire process of “how software is produced, delivered, operated, and improved” explicit, versioned, automated, and observable.

The “Byproduct” DevOps Left Behind Became AI’s Food

Here’s the most interesting part: DevOps was never designed for AI. It solved problems of human-to-human collaboration, the balance between quality and speed, the engineering challenge of delivering at scale.

But its byproducts almost perfectly hit every piece of infrastructure the AI era demands:

In other words, the software industry spent twenty years turning its production process into a system that is extraordinarily friendly to any external agent — whether that agent is a new hire, an outsourced team, or an AI.

When the coding agent arrived, it didn’t need the software industry to do any extra adapting. It simply plugged into a collaboration infrastructure that had been ready and waiting for it all along.

Knowledge Accumulation Got “Embedded” Into the Production Process

This is the single thing the software industry has done that other industries should learn from most.

In many industries, “knowledge management” is something that requires its own project approval, its own budget, its own performance review — someone has to write documentation, maintain the wiki, run training sessions. But because it has no direct link to business output, it’s always the lowest priority, and it never gets done well.

In the software industry, by contrast, knowledge accumulation isn’t an “extra thing” — it’s a byproduct of the production process.

An engineer doesn’t need to make any “extra effort” to do knowledge management. As long as he follows the established practices, knowledge gets automatically captured in a structured form.

Flip the lens to most traditional industries: knowledge lives in people’s heads, in some sheet of some Excel file, in WeChat chat histories. It’s not that knowledge isn’t being produced — it’s that it’s scattered everywhere, exists in all manner of forms, hard to find and hard to read.

The other side of this coin: the reason AI still can’t break into other industries isn’t that the models aren’t strong enough — it’s that those industries haven’t yet prepared themselves to onboard any “external agent” — whether that agent is an AI, or a new employee.

Why Can’t Most Industries Absorb AI?

A world without a source of truth.

Dirty, Dirty, Dirty, Dirty

Anyone who’s done one or two AI deployment projects in a traditional industry will know these scenes all too well:

• Dirty data: numbers don’t match across systems, systems don’t match reality, and nobody knows what a given data field actually means.

• Dirty processes: the SOP (Standard Operating Procedure) and manuals are written in meticulous detail, but nothing actually runs the way the flowchart says it does.

• Dirty systems: a dozen-plus systems spanning different eras and different vendors — interfaces either don’t exist, or they’re SOAP, or the workflow is “export to Excel and import it again.”

• Dirty knowledge: the core know-how lives inside a veteran’s head, in WeChat chat logs, in some unmaintained Excel file nobody owns.

Stack all four kinds of dirty on top of each other, and for AI to actually deliver value becomes nearly impossible.

But the deeper problem isn’t that “things are dirty right now” — it’s that over the past decade-plus, digital transformation didn’t actually solve this. In many places, it made it worse.

Most Turned Into Dashboards

Over the past decade, nearly every halfway-respectable industrial enterprise has done “digital transformation,” “Industrial Internet,” “smart factory,” “centralized data platform.” But if you look at what these projects actually delivered, the vast majority produced the same thing: a big screen, a few dashboards, a handful of reports.

The various systems, each abbreviated to an English acronym, all sounded right. The project proposals wrote up smoothly. The acceptance demos all ran fine. But they share one common trait: they don’t change how the enterprise operates — they merely “display” the results of how the enterprise already operates.

And so they all ended up as big-screen dashboards for the boss. Display is not the same as change. It became a kind of digital bureaucracy.

Tools, Processes, Organization

Let me try to break down the things in an enterprise that “can be digitized / made intelligent” into three layers.

Tool Layer

What this layer does, fundamentally, is: take things where “people already know what to do” and do them faster, more reliably, cheaper.

The vast majority of “AI projects” and “digital transformation projects” operate at this layer. The reason is simple — they’re easy to get approved, easy to sign off, easy to tell a story about. (I also call this peripheral intelligence.)

Process Layer

Take the links that used to depend on human coordination, meeting-driven decisions, and experience-based judgment, and turn them into system-driven chains with feedback and room for optimization.

The value here is far higher than at the Tool Layer, but it demands data that flows, systems that connect, processes that are explicit, and accountability that is clear. This is where the vast majority of enterprises get stuck — because it requires you to clean up the “four kinds of dirty” first.

Organization Layer

The enterprise itself, as a complex system: how it is described, how it is run, how it is improved.

People can handle local problems by experience, but they struggle to manage a high-dimensional, dynamic, multi-objective, tightly-constrained system in real time. What the third layer aims to do is turn this complex system itself into something that can be modeled, monitored, and tuned.

This is the layer where AI-Native should truly come into play. But it has an awkward characteristic: it’s a hard sell.

If you accept this three-layer framework, one thing becomes clear: what makes AI transformation genuinely hard isn’t the models — it’s the dirty work.

And here’s the problem: nobody wanted to do this dirty work over the past few decades, and it’s hard to imagine anyone wanting to do it in the future. Because it doesn’t win glory, doesn’t earn credit, doesn’t make slides, doesn’t advance careers.

Genuine and Pseudo Tacit Knowledge

There’s a widely-circulated saying: “A lot of what we do in this industry is tacit knowledge — AI can’t learn it.”

That’s half right, and half wrong.

Genuine tacit knowledge absolutely exists. But pseudo tacit knowledge is far more common:

• Things that could have been written down, but nobody wrote them.
• Things that could have been structured, but the organization doesn’t reward it.
• Things that could have been shared, but sharing them means losing personal leverage.

A huge amount of what gets called “experience” in vertical industries actually falls into the latter category. Treating pseudo tacit knowledge as genuine tacit knowledge and enshrining it has two results: first, the cost of bringing new people into the field is enormous — the only path is “follow people, watch people, put in the years”; second, AI deployment hits a wall, because what AI feeds on most is accessible, structured, verifiable context.

And the reason the software industry lets newcomers ramp up fast and AI plug in quickly is precisely that it has institutionalized the practice of making explicit what can be made explicit — if you don’t make it explicit, your PR won’t pass, CI won’t run, code review won’t approve. The process forces you to spit your knowledge out.

Behind this are two fundamentally different organizational forms.

The internet and open-source communities are organized around products, systems, collaboration, and reusability — they form a product organization.

Many traditional industries, by contrast, are expert organizations.

An expert organization feels “safer” on the surface — because critical capability is locked inside a few people and won’t spiral out of control. But it has one fatal side effect: it is a system closed to outsiders (whether those outsiders are newcomers or agents).

Which leads to an awkward situation: AI can’t get in, because newcomers can’t get in either.

So, Where Is the Bottleneck?

Back to the opening question: why can’t most industries absorb AI?

Because over the past few decades, they never built an internal system that is “friendly to outsiders.” This isn’t a problem of “AI can’t get in” — it’s a problem of “no systematic force can get in.” AI has simply shone a fresh light on it.

And the real irony is — the way many industries are investing in AI right now is still piling more “agent”-branded dashboards onto the first layer (the Tool Layer), rather than paying down the debt they’ve accumulated on the second and third layers.

The ROI Trap

Most companies, when crunching the numbers on AI, are using an algorithm from a previous era. That algorithm determines that they can see at most a small sliver of AI’s value — and it also dooms their AI transformation to remain stuck at the level of “a cheaper person.”

Three Layers of ROI

Here I draw on the framework from The Three Layers of ROI for AI Agents.

Layer 1 ROI: how many people AI replaced, how much time it saved, how much cost it cut.

This is the AI value that the vast majority of companies grasp most easily. Its strength is that it’s intuitive; its weakness is that it has a low ceiling.

Because at its core, it’s about making old processes cheaper and faster — it doesn’t change how the company operates. The role AI plays here is simply that of a “cheaper person.”

Layer 2 ROI: AI enables people to do things they previously couldn’t do, or couldn’t do well.

The value is far higher than Layer 1, but the barrier to entry is also far higher. It requires companies to be willing to spend on “invisible infrastructure.” The vast majority of companies get stuck at this layer. Not because they can’t do the math, but because this investment demands that the CEO have 3-5 years of patience, while most managers operate with a 6-12 month horizon.

Layer 3 ROI: the agent is part of the organization.

Its core question isn’t “what can AI do for me?”, but: what permissions does the agent hold within the organization? At this point, it is no longer just a “tool” — it becomes a new kind of actor in how the organization runs, and the company’s entire way of working must be redesigned around it.

This is what AI-Native really means. Not “we use AI,” but “the organization has redesigned how it works around AI.” The returns are non-linear, compounding, and long-term.

Why Does the Money Always Flow to Layer 1?

It’s not that companies can’t see the value of Layer 2 and Layer 3 — it’s that their decision-making mechanisms can only write checks for Layer 1.

This is the most awkward part of AI transformation. The reason Layer 2 and Layer 3 ROI is so high is precisely because they are built on “paying down debt” — cleaning up dirty data, untangling broken processes, capturing scattered knowledge, and connecting isolated systems.

And this “debt” is what every manager over the past several decades racked up in pursuit of their own short-term KPIs.

So in the end, everyone settles on a kind of low-level consensus:

Build an AI system that doesn’t change power structures, doesn’t change business processes, doesn’t challenge existing KPIs — one that can be signed off on, can be demoed, can be written up in reports.

It looks like the company “uses AI,” but nothing about how the company actually operates has changed in any meaningful way.

And so, the vast majority of companies only know how to calculate Layer 1 ROI. They will naturally use AI as a cheaper person. But there’s a fatal problem here — when everyone uses AI as a cheaper person, the market will rapidly erase that value. Advantages from cost reduction are short-term, replicable, and something competitors can catch up to quickly.

The Essence of AI Transformation Isn’t Technical

A somewhat uncomfortable conclusion:

The deeper AI transformation goes, the less it becomes a technical problem and the more it becomes a problem of authority, process, and organization.

The Philosophy of X-Ops

The essence of turning something into Ops is transforming a complex system into a control system that can receive feedback, self-regulate, and learn.

By this point, the first three sections have laid out the problem with considerable clarity:

• The software industry was hit hardest by AI, not because it understands AI best, but because it spent the last two decades building DevOps

• Most traditional industries cannot absorb AI, not because AI isn’t powerful enough, but because they have no source of truth

• Most enterprises’ AI transformations stall at the first layer, not because the ROI math doesn’t add up, but because their decision-making apparatus can only fund what produces visible ROI

If an industry genuinely wants to absorb AI, what it needs isn’t “AI” — it’s its own flavor of Ops. I call this X-Ops, where X can be any industry that wants to be genuinely transformed by AI.

But X-Ops is not simply “copy DevOps into another industry.” It’s a deeper way of thinking — about how an organization turns itself into a system that can be continuously observed, continuously fed back into, and continuously improved.

A Control-Theoretic Lens: The Organization as a Feedback System

The core idea of control theory is remarkably simple: for any system to operate continuously in an uncertain environment and improve itself, it must have a closed loop — sense, decide, act, receive feedback, then return to sensing.

DevOps, in fact, closely resembles a control system.

When you break DevOps apart, it maps almost directly onto a control-theoretic structure:

So DevOps is not merely “automated deployment.”

The problem with the traditional development model is that feedback is too slow: requirements go live months later, incidents are only discovered after they happen, and only after ops takes over does development realize the code was never operable.

DevOps fixes this by shortening the feedback chain:

Code commit → automated testing → automated deployment → production observability → user feedback → rapid correction.

This is remarkably similar to negative feedback in control theory: detect the deviation, correct it, and bring the system back within the target range.

At the same time, “stability” in DevOps is not stillness — it is dynamic stability. This point is crucial. Traditional management likes to pursue “no change,” believing that fewer changes bring stability. The DevOps logic is closer to control theory: stability isn’t the absence of change, but remaining controllable amidst continuous change. Or, put another way:

Small-step changes, rapid detection, rapid rollback, rapid recovery, continuous learning.

Now look at the organizational level. The vast majority of companies are not a closed-loop system. They are more like an open-loop pipeline: leadership makes a call → orders are issued → execution happens → … and then nothing.

And AI’s real value is built precisely on top of closed loops. The working style that suits models best is small-step iteration: propose a change, run it, see the results, correct, and go again. If an organization itself lacks a mechanism for “runnable, verifiable, rollback-able,” then AI can’t find its place — it can’t know whether it got things right, and it can’t know where to go next.

So the first meaning of X-Ops is this: transform the organization from an open-loop system into a closed-loop system.

The Three Foundations

Control theory provides an abstract lens. To make it concrete, I believe there are three foundations.

The Fact Layer

Does the system have visibility? A source of truth — this doesn’t mean all data must be piped into a data warehouse, nor that all knowledge must become a knowledge graph. But certain things must be established as “the source of fact.” You can describe it in terms of “data lineage” or “ontology,” but the core purpose is the same: solving the problem of AI-ready organizational context. This layer addresses what AI ought to trust.

The Change Record

Does the system have adjustability? AI has no hands. The physical world and the digital world are inherently separated. To prevent the gap between the two from growing ever wider, critical changes must be traceable. This can be loosely compared to Git, but the point isn’t to slap on “Git” — it’s that the act of change itself must be institutionalized. Who changed what? Why? What is the blast radius? This layer addresses whether AI can understand the organization’s evolution.

The Evaluation & Feedback System

Does the system have learnability? For the vast majority of deep learning or AI deployment projects, I’ve consistently insisted on evaluation first: build a test set → define evaluation metrics → design the evaluation methodology → evaluate → optimize → evaluate again. This approach is a universal methodology from data science, originally applied to complex system optimization problems. It generalizes far beyond its original domain.

Building Short Feedback Loops

Some will say: “In our industry, safety requirements are too strict, quality demands too high, customer expectations too unforgiving — we can’t iterate fast the way the internet does.”

But the higher-risk the system, the stronger its version management should be, the more rigorous its testing, the more comprehensive its automated verification, the more meticulous its change records. In other words, the harder it is to “iterate fast,” the more an industry needs Ops — not for speed, but for control.

The essence of DevOps has never been “fast.” It’s “still controllable while being fast.” Build your own feedback cadence — it might be monthly, quarterly, annually, but it must be a closed loop.

The Human Use of Human Beings

The deepest meaning of X-Ops is redefining the role of human beings within the organization.

In the past, people in organizations primarily played two roles: the executor (the one who does the work) and the decider (the one who calls the shots). The former is responsible for getting things done; the latter is responsible for deciding what to do and how. Before the age of AI, both roles were scarce — execution required skill, judgment required experience.

AI has changed this structure. Execution grows cheaper by the day, and judgment is beginning to be partially taken over by AI.

Looking back at past waves of technological change, technology rarely eliminates human value outright — it more often shifts where value resides. From the Industrial Revolution to AI, the human role has been steadily moving from “directly operating on objects” to “designing, monitoring, and regulating a system that operates on objects.”

At this point, human value hasn’t disappeared — it has moved up a level.

P vs NP offers a metaphor: finding an answer may be extraordinarily hard, but verifying one may be relatively easy. Just as a year ago we were still doing classical programming by hand, today the conversation has shifted to harness engineering — from “I build the thing myself, with my own hands” to “I define the goals, constraints, tests, acceptance criteria, and feedback loops, and let the machine generate results within a controllable range.” The critical position for humans is no longer being the producer of every specific output, but rather the higher-level evaluator, goal-setter, constraint-designer, feedback-loop builder.

Of course, people’s fear of “automation” is more a matter of control and distribution — and in the age of AI, what deepens the fear even further is that it now encroaches on the position of “evaluator” itself. But all of that is a discussion for another day.

The Three Dangers of X-Ops

X-Ops sounds like a perfectly correct methodology: make things explicit, make things versioned, build feedback loops, continuously improve. But the more correct something is, the more easily it mutates inside an organization. Especially in large companies and traditional industries, any methodology eventually risks becoming new processes, new systems, new forms — even new bureaucracy.

The first danger is tool worship.

X-Ops is not “buy a set of Ops tools.” If you think bringing in Git and CI/CD means you’ve done X-Ops, you’ve most likely just wrapped a new layer of bureaucratic shell around the same old thing.

The second danger is metric alienation.

The moment you build a measurement system, someone in the organization will start optimizing the metric itself rather than the goal behind it — reward hacking. Goodhart’s Law: when a measure becomes a target, it ceases to be a good measure. The goal of X-Ops is to use measurement to drive improvement, not to use measurement to punish people. The moment metrics are used to assign blame, the organization instinctively begins to fabricate data and hide problems, and you’re right back on the well-worn path to digital bureaucracy.

The third danger is the illusion of control.

The most dangerous deviation of all is treating engineering as everything — everything must be measurable, everything must be automatable, everything must be regression-testable. A truly mature X-Ops is the discipline of knowing what can be engineered, and what should not be.

Conclusion

Back to the opening question.

Because the question isn’t just whether AI is there — it’s whether the industry itself has become a system that AI can understand, participate in, and optimize.

Otherwise, AI is just a more advanced shell wrapped around the same old way of operating.

Real AI transformation isn’t about putting AI into the enterprise — it’s about turning the enterprise into a system that can run together with AI.

Otherwise, so-called intelligent transformation, in the end, will merely become another form of digital bureaucracy.