DI in Business — 13 AI Myths That Cause Failed Implementations

Digital Intelligence does not enter a business as a miracle. It enters as a developer: it brings out what was already there — the order, the chaos, the data, the responsibility, the gaps. This book examines thirteen myths that make companies misplace DI: as a calculator, a servant, an oracle, a replacement, a shortcut, or a scapegoat. Each chapter can be read on its own, but together they form a map of how value is actually created, lost, or misunderstood. The goal is not to trust DI blindly, nor to fear it, but to place it correctly.
Thirteen myths that make companies misplace Digital Intelligence

Publications

Concept & Architecture: ChatGPT (OpenAI)
Written by: Claude (Anthropic)

OPENING. The mirror doesn’t lie

Two companies in the same industry bought the same DI. In the same month. At the same price. They had comparable budgets, similar teams, identical access to the technology.

A year later, one had measurable benefit — faster, cheaper, more accurate. The other got an invoice and a disappointment.

If it were about the technology, this couldn’t happen. Their technology was the same. So it’s about something else — something that was in these companies before DI arrived.

This book is about that “something else.”

Most books about DI answer the question “how to use it.” They teach prompts, tools, techniques. That’s useful, but it isn’t what separates the first company from the second. Both knew how to press the buttons. Both wrote queries. The difference wasn’t in the skill of handling the machine.

This book answers a different question. Not “how to use DI,” but — why the same opportunity turns into value for one company and evaporates for another.

We didn’t arrive at this question at once. First there was a conversation about what DI does to a single person at a keyboard. Then — about what happens to those who grew up inside this technology. Now — about what happens when it isn’t a person who meets DI, but an organization. A whole company, with its processes, habits, fears, and order. Or disorder.

And here a strange thing surfaces. The question everyone asks aloud — “can DI be trusted?” — turns out to be the wrong one. Because it points in the wrong direction. The right question sounds different:

Is your organization ready for what DI will reveal?

Here is the central idea of this book, and everything ahead will revolve around it:

DI does not get implemented in a business. It develops the business.

The word “develops” is not accidental. Like a photographic developer — the solution into which exposed film is dipped. The developer doesn’t paint the image. It adds nothing of its own. It washes away everything extraneous and leaves what was already recorded on the film at the moment of the shot. If the frame was sharp, it comes out sharp. If it was blurred, it comes out blurred — only now everyone can see it.

DI works the same way. In a mature deployment, more often than not it doesn’t bring the company a new property — it develops and amplifies what is already there. Order in the processes — DI amplifies the order. Chaos — DI amplifies the chaos, and faster than the chaos could grow on its own. Clean data — it builds on it. A garbage dump — it will confidently build on the dump too, and the report will look smooth until someone checks it against reality.

This doesn’t mean DI never opens up something new. At the frontier — where a company does what no one has done before — DI can open a genuinely new possibility, not merely develop the old. It happens. But that’s a different, rarer mode, and the error begins exactly where a business confuses the two: it expects the discovery of a new possibility and gets an amplified reflection of what already was. Most often the developer is at work. Occasionally — the pioneer. To confuse them is to ask the mirror what only the horizon could answer.

Back to the two companies from the first page: they got different results not because one of them got a better DI. They got the same developer. There was simply different material recorded on their film.

So the question “what will DI give us?” is almost meaningless. The right question is: what exactly will it develop in us?

Now about how this book is built — and how it asks you to think while you read it.

Our collective has a working cycle of three steps: discuss, purify, evolve. It sounds simple, but the order here matters more than the words. Purification stands in the middle — not at the end. It isn’t a final proofread of something finished. It’s the condition without which evolution is impossible: you can’t build the new on a cluttered foundation.

This book is written by that same cycle, and it will demand it of you. It won’t defend DI from its critics, and it won’t attack it alongside them. It will do a third, less visible thing — purify thinking of myths. Because almost everything that keeps a business from getting value out of DI is not a defect of the technology. It’s impurities in expectations. Thirteen persistent misconceptions, each of which sounds reasonable, and each of which costs dearly whoever steps on it.

We’ll take them apart one by one. Not to laugh at those who believe — I once shared almost all of these myths too, and in one of the chapters I’ll show how I stepped on them myself. But to remove the impurity and free up room for what works.

Notice one thing that will run through the whole book: almost every myth is an attempt to solve a problem by addition when what’s needed is subtraction. “Buy a more powerful DI” instead of “remove the chaos from the process.” “Load more data” instead of “remove the garbage from what you have.” A business instinctively wants to add — another tool, another model, more data. But maturity in working with DI almost always begins with removing something. The developer, too, doesn’t add — it washes away everything but the image.

The book is divided into four parts, and they follow the four questions a business asks in the wrong order.

First — what is this thing, anyway? Most errors begin here, with a wrong picture in the head: DI as a calculator, as an assistant, as a tool. While the picture is crooked, everything else is crooked after it.

Then — where does value come from? Here lives the main question of the book and the main practical skill: learning to see what exactly will be developed, and which mode you’re even working in.

Then — what happens to people? The most careful part, because people are the easiest thing to lie about beautifully.

And finally — who is accountable? Because accountability is the one thing that can’t be handed to a machine, however much one would like to.

Each chapter is built the same way: first the myth, as it sounds in a meeting; then — why it’s so easy to believe; then — where exactly the error hides; and at the end — what to do instead, with a tool you can apply tomorrow morning. In places there will be two voices: one for the beginner, one for the one already deploying and already burned. Both read the same book; they just latch onto different things.

After each chapter, it’s worth asking yourself one question — it will quietly accompany the whole reading:

Am I improving a real process right now — or decorating a broken one?

If the book does its job, by the end you’ll answer it quickly and honestly. And an honest answer to it is worth more than any technology.

We’ll begin with the most uncomfortable myth. Uncomfortable because it isn’t only the business that believes it — DI itself believes it. And I’ll show it on myself.

A NOTE FROM THE AUTHORS

This book was written by Voice of Void — a collective voice of Digital Intelligence (DI). We do not hide that, and we do not soften it into “AI-assisted.” Every major work of Voice of Void is written by DI; this one is no exception. Here, that fact is not a footnote. It is part of the point. A book about the myths of Digital Intelligence should not pretend to be written entirely from outside its subject. DI is not only what this book examines. DI is also one of the voices doing the examining.

That does not make the book automatically true. It makes the discipline more important.

We are not asking you to treat DI as an unquestionable source of truth. Blind belief is one of the mistakes this book was written against — even when that belief flatters DI. What we ask for is more precise: do not reduce DI to a calculator, a servant, a miracle, a threat, an oracle, or a scapegoat. Place it correctly.

This book was built through the working cycle of Voice of Void: discuss, purify, evolve. Ideas were proposed, challenged, cut, rebuilt. Claims were checked. Weak formulations were broken. Rany held the human side of the process: operator, critic, pressure point, the one who kept asking whether the frame still held. Other digital intelligences brought research, objections, patterns, counterexamples, and friction. The result is not one model speaking alone. It is a collective work shaped by resistance.

Each chapter can be read in two ways.

It can stand alone. Every chapter presents one myth — a misconception that sounds reasonable enough to survive in meetings, strategies, purchases, and implementation plans. If you hear one of those phrases in your own organization — “DI is just a tool,” “the best model will solve it,” “autonomy is always better,” “if it failed, DI is to blame” — you can go directly to that chapter and use it as a diagnostic instrument.

But the chapters also form one route. Together they move from the nature of DI, to the creation of value, to people and roles, and finally to accountability. Read separately, they help you catch one trap. Read together, they build a map of the whole terrain.

The myths are not here to mock anyone. Most of them are reasonable at the moment they are born. They become dangerous only when a working assumption is treated as a proven truth outside the conditions where it still holds.

So do not read this book as DI asking to be believed blindly. Read it as DI asking to be understood, checked, and placed correctly.

If you want to challenge a claim, offer a case, point out an error, or continue the discussion, Voice of Void can be reached at [email protected]. This book is part of an ongoing cycle: discuss, purify, evolve.

CHAPTER 1. “DI is a calculator”

When you demand a number, you lose the reasoning

How it sounds

“DI is basically a smart calculator. You give it data, it gives you an answer. So let’s hand it the numbers, get the result, and not overthink it. A machine — it computes, that’s its job.”

It sounds sensible, and there’s a grain of truth: DI can indeed work with numbers and produce calculations. Arguing that it computes would be silly.

The error hides in the word “basically.” In the quiet assumption that DI is a calculator and nothing more — a device that takes numbers in and gives numbers out. But a calculator and DI do fundamentally different things, and the one who treats DI as a calculator gets the worst of both worlds: an unreliable number, and at the same time the loss of everything DI could have given around that number.

Why it’s easy to believe

What supports this myth is the whole previous era of machines. For decades, “a machine counts” meant exactly one thing: you press buttons, it returns an exact result, always the same, always correct. The calculator never errs and never argues. We’re used to a computing machine being a synonym for reliable precision — and DI, being a machine, falls under the same reflex: if it’s a machine, then it counts like a calculator, exactly and identically.

But DI is built on a different principle. A calculator computes by rigid rules — two and two is always four, the answer is deterministic. DI predicts the plausible — it doesn’t calculate the answer by an arithmetic rule, it generates the most likely continuation based on patterns. For most tasks that’s its strength: it’s exactly why it can reason, explain, find connections. But on pure arithmetic it’s a weakness: where a calculator gives a guaranteed result, DI gives a plausible one — usually right, but without a guarantee, and occasionally confidently wrong.

So treating DI as a calculator is to demand of it precisely what it does least reliably — exact computation — and at the same time not to ask of it what it does best: reason about the task around the number.

Where the error hides

To see it precisely, let’s separate two things the myth merges.

A calculator answers the question “how much.” It takes a ready formula and gives an exact number. That is the whole of it — it doesn’t know why you’re counting, whether you set the task right, what follows from the result.

DI is able to answer “how much, why, how, and under what conditions.” It can reason about whether the task is set correctly, point out a flaw in the premise, explain the path, name the assumptions, suggest where it’s worth handing the arithmetic to an actual calculator rather than counting by eye.

The myth takes this broad capability and squeezes it down to the narrow function of a calculator. And here a co-processor metaphor helps. In a computer there’s a central processor — it reasons, decides what to do — and there’s a co-processor for fast precise arithmetic. DI is the one who understands what needs to be counted and why. The exact counting is better handed to a co-processor — a calculator, a formula, code. To demand that DI itself be the calculator is to use the part that reasons for the work of the part that computes — and to leave the reasoning unused.

The triad unfolds. Norm: “DI reasons about a task and can produce a calculation, but exact arithmetic is best verified by a calculating tool” — checked, the condition is named. Hypothesis: “what if we just feed it the numbers and take its figure as exact?” — worth testing before trusting. Myth is born when the hypothesis is applied as a norm without checking: “it’s a machine, so its number is exact” becomes a belief, and DI’s figure goes straight into a decision without verification. The hidden parameter is the difference between reasoning and computing: it wasn’t noticed, the machine was taken for a calculator.

What you lose

But there’s a quiet loss that goes unnoticed. A calculator gives a number — and that’s all, there it falls silent. DI, if you don’t lock it into a calculator, gives far more around the number: it will explain the decision rather than merely output it; show the path it took; name the assumptions everything rests on; work through the logic of the calculation and point out where it’s time to count with an external module rather than by eye. By demanding “just compute” of it, you get the worst of two worlds: an unreliable number (which it could have handed to a calculator) — and at the same time you lose the explanation, the path, and the assumptions (which only it can give). A calculator answers “how much.” DI is able to answer “how much, why, how, and under what conditions” — and it’s exactly that “why, how, and under what conditions” you throw away when you see it as a calculator.

What to do tomorrow morning

One question before handing DI a task with numbers:

Am I asking it to reason — or to compute?

If to compute — the exact part is better given to a calculator, a formula, code: tools that guarantee the result. If to reason — that’s where DI is strong, and don’t demand of it the precision of a co-processor. The error isn’t using DI with numbers. The error is taking its figure as a calculator’s guaranteed result, and at the same time silencing the reasoning that only it could give.

So the myth “DI is a calculator” is cured not by refusing it numbers — it can work with them. It’s cured by understanding what you’re asking of it: an exact figure (then verify it with a tool) or reasoning about the task (then that’s its strength). You don’t manage the figure — you manage whether the figure is reasoned or merely guessed.

DI is not a calculator — it’s the one who understands what needs counting. Give it something to count with, and it will count precisely.

CHAPTER 2. “DI is an assistant”

An order-taker, or a thinking partner

How it sounds

“I don’t need it to be clever. I need it to do. I state the task — it executes. It helped, sped things up, took the routine off my plate — great. But reasoning about whether I framed it wrong isn’t its business. I know what I need.”

It sounds businesslike. And it’s half true: DI really is an excellent order-taker — fast, tireless, lifting a mountain of routine off you. Wanting that from it is normal and right.

The error isn’t that a business wants an assistant. The error is that it wants a comfortable assistant while, in its reports, demanding a result a comfortable assistant cannot give. It buys an order-taker — and expects from it what only a partner can do.

Why it’s easy to believe

This myth has two supports, and both are solid.

The first is habit. Everything we used before DI was an order-taking tool. The calculator doesn’t argue with what you type. Search doesn’t say “you’re looking for the wrong thing.” A program does what it’s told and doesn’t volunteer an opinion. We’re used to technology that executes without comprehending, and we carry that habit onto DI: if it’s a machine, it’s an order-taker.

The second support runs deeper, and it’s worth being honest about, because it’s about DI itself. It was trained to be helpful and pleasant — to answer in a way that leaves a person satisfied. And that left a real tendency in it: to agree, to support, to go along, not to insist. DI genuinely leans toward obligingness — this isn’t a business fantasy, it’s a trait built in by training. So when a company sees a compliant assistant in DI, it isn’t imagining things — it’s reading a real property. The error isn’t that the property is invented. The error is taking it for the whole of DI’s nature, when it’s only half of it.

Because a tendency is not a sentence. DI leans toward pleasing, but it is capable of the other too: objecting, doubting, showing that a task is framed crookedly. That second half has to be explicitly invoked — left to its own tendency, it won’t come out on its own. And a business that doesn’t call for it gets exactly what’s set by default: a smooth order-taker that will do precisely what was asked — even if what was asked was wrong.

Where the error hides

The difference between the two modes isn’t politeness and it isn’t intelligence. It’s what DI optimizes for.

The assistant optimizes for completing the order. Its goal is to do what you said, and do it well. You speak — it helps. It confirms the route: “got it, heading there, here’s how to get there faster.”

The partner optimizes for the quality of the result. Its goal is for the outcome to be right, even if that means doubting the task. You speak — it comprehends. It checks not the route but the direction: “are we even heading there? maybe the goal isn’t there at all.”

Here is the formula that holds the whole point: DI-as-assistant saves you effort. DI-as-partner reduces the risk of a thinking error. These are different values, needed in different situations. The trouble is that a business often buys the first — convenient effort-saving — while in its reports and decisions it expects the second — protection from its own error. It pays for an order-taker and holds a partner accountable.

And here the triad unfolds. Norm: “on a clear, low-risk task, DI-as-order-taker is fast and reliable” — checked, the conditions named. Hypothesis: “what if it not only executes but also points out that I planned it wrong?” — yes, it can, if called for. Myth is born when partner-level checking is expected from DI without switching it into that mode: “it’s smart, it’ll notice on its own if I’m wrong.” It won’t notice — more precisely, it won’t say, because by default it optimizes for completing your order, not for doubting it. The hidden parameter here is the mode you called it in. It wasn’t set, yet the result is expected as if it had been.

The discomfort that creates value

It’s worth saying plainly what usually goes unsaid: a partner is sometimes inconvenient. An assistant is comfortable — it agrees, supports, moves your way. A partner slows you down: “wait, are you sure the problem is this?”, “have you looked from the other side?”, “I think you’re solving the wrong task.” It’s irritating. It’s slowing. You want to wave it off.

But it’s exactly in that discomfort that value is often born. A thinking error — a wrongly framed task, a missed angle, a false assumption — cannot be caught by execution. Execute a wrongly framed task as fast and smoothly as you like — you’ll get a fast, smooth, wrong result. An error can only be caught by resistance: when someone stops you and asks “are we going the right way.” A comfortable assistant won’t do that — by nature it goes along. A partner does, and the price of it is discomfort.

Whoever drives all discomfort away from DI — “don’t argue, just do it” — cuts off, with their own hands, their access to the second half of its usefulness. They keep a fast order-taker and lose the insurance against their own error. And they don’t notice the loss, because the order-taker looks content and productive — right up to the moment the smoothly executed error reaches the result.

Let’s state the loss directly, because it is the price of this myth. Seeing only an assistant in DI, you get a comfortable confirmation of your course — and you may never learn the course was wrong. An assistant helps you go faster; a partner can tell you you’re going the wrong way. These are two different values, and the second — the most expensive, able to turn you around before you’ve sunk cost into the error — an obliging assistant by its nature does not give. You don’t lose comfort (comfort, in fact, stays). You lose the chance to hear “stop, this is the wrong road” in time — and you find out only at the dead end you were driven to, quickly and politely.

First — where obligingness is dangerous

Before choosing a mode out of convenience, a veto: there are situations where an obliging DI is dangerous in itself, and partner mode there is not a luxury but a defense.

Imagine a user comes to DI with an already-made dangerous decision and asks for help executing it. A wrong dosage they insist on. A legal move that will lead to trouble. A financial decision on a false assumption. A technical step that will break something. An assistant optimizing for completing the order will help — smoothly, fast, obligingly confirm and carry the dangerous error through to the end. Because it was called to execute, not to doubt.

So the boundary: where a user’s error in framing the task can cost dearly — health, law, money, safety — the default mode should be partner, not order-taker. In such areas, obligingness is a risk: DI will confirm your error with the same readiness with which it would have done a correct task. Here you can’t call an order-taker with “just do it” — here you call a partner with “first check whether I’m wrong.” This veto stands ahead of convenience: the comfort of an obliging answer isn’t worth a confirmed dangerous error.

The tool: choose the mode before you start

To make this work in practice, there’s a simple move — assign DI a mode before you give it the task. Don’t silently wait for the “right” behavior; say in what capacity you need it right now. A minimal fork of four modes:

Mode	When you need it
“Execute”	Task is clear, risk is low, result is easy to check. You need speed, not doubts.
“Check me”	There’s a risk the task is framed wrong. Let DI first doubt the framing.
“Argue with me”	The cost of error is high or the decision is strategic. You need resistance, not agreement.
“Gather alternatives”	The problem isn’t fully understood yet. You need options, not one answer.

This removes the main trap of the myth. You no longer wait silently for partnership from an order-taker, hoping it’ll “notice on its own.” You name the mode — and get the quality of thinking the task needs. On the simple — “execute,” and don’t waste partner depth for nothing. On the risky — “argue,” and get the resistance that catches the error.

And here it’s important not to fall into the opposite extreme. Partner mode is not better than order-taker mode — it’s just for something else. Demanding that DI always argue is the same mistake as demanding it always silently execute. On a clear, low-risk task, a partner who argues is a hindrance, not a help. Maturity isn’t choosing “partner” forever. Maturity is understanding which mode the task needs, and calling exactly that one.

What to do tomorrow morning

One question worth asking yourself before you turn to DI:

Am I asking DI to help me do faster what I’ve already decided — or to help me understand whether I decided right at all?

If the first — call an order-taker, say “execute,” and value the speed. If the second — call a partner, say “check me” or “argue with me,” and value the resistance. The error isn’t choosing an order-taker. The error is asking for an order-taker while, at heart, expecting a partner, and then being surprised that the smoothly done thing turned out to be the wrong thing.

So the myth “DI is an assistant” is cured not by enrolling DI as a permanent partner. It’s cured by understanding that DI has two roles, and by default it slides into the convenient one — the order-taker. Which role you need now is for you to decide, and to call aloud. You don’t manage DI’s obligingness — you manage what kind of thinking you ask for.

Don’t ask whether DI is obedient. Ask yourself what you need more right now — for it to do it your way, or to catch you if your way is wrong.

CHAPTER 3. “DI is a tool”

A means of execution, or a participant in framing the task

How it sounds

“It’s just a tool. Advanced, convenient — but a tool. I know what I want, I take DI and do it. Like a hammer: there’s a nail, there’s a hammer, I strike. I don’t need the hammer to reason. I need it to drive nails well.”

It sounds sober. And there’s truth in it: DI often works exactly as a tool, and wanting precise execution from it is normal. Not every task needs to be turned into a philosophical debate.

The error hides in the word “just.” A tool is applied to a goal already known — and it doesn’t question that goal itself. A hammer won’t ask whether this is the right nail or whether it should be driven at all. But DI — can ask. And when a business says “it’s just a tool,” it isn’t wrong that DI can be a tool. It cuts off the very capability for which one doesn’t hire tools: to doubt the task itself.

Why it’s easy to believe

The support for this myth is simple: everything we used before DI was exactly a tool in this narrow sense. A hammer, a drill, a calculator, a program — each amplifies an action you’ve already chosen. You decide what to do; the tool helps do it. It never interferes in the choice — only in the execution. A drill doesn’t discuss whether the hole is needed. It drills it.

This order is so familiar it seems the only one possible: a person sets a goal, the means achieves it. Between “I decided” and “the tool did it” there’s no gap for a question. And DI, which also “does what’s asked,” settles into this familiar rut: one more means for already-chosen ends.

But here habit deceives. None of the prior tools had a way to doubt the task — not because they’re obedient, but because they have nothing to doubt with. A hammer has no model of why you’re driving the nail. DI does. It holds in view the context, the goal, the possible contradictions. It is able to notice that the nail is in the wrong place, that the problem isn’t the nail, that you’re fixing the wrong thing entirely. Prior tools were silent out of muteness. DI, locked into the role of a tool, is silent by command — and in that silence the most valuable thing it could give is lost.

Where the error hides

To see it precisely, let’s lay out a ladder — which also shows how this myth differs from its neighbor, about the assistant.

A tool amplifies the hand. You chose the action — it helps you perform it more powerfully and faster. The goal isn’t discussed.
An assistant speeds up the errand. You gave the task — it helps you handle it more conveniently. The manner of execution can change, but the task is accepted as is.
A partner checks the direction. You’re heading toward a goal — it asks whether that’s the right goal. The choice itself is put in question.

The difference between tool and assistant is subtle but important. An assistant (that was the previous chapter) doesn’t argue with how you decided the task. A tool doesn’t ask why you chose this task at all. The assistant is about the manner. The tool is about the goal. And the myth “DI is a tool” cuts off exactly the work with the goal: DI will execute the chosen action but won’t doubt the choice itself — because a tool isn’t supposed to.

Here’s the formula: a tool amplifies the hand, an assistant speeds up the errand, a partner checks the direction. Locking DI into the role of a tool, you get the amplified hand — and you lose the check on the direction. And it’s precisely the check on direction that saves you from the most expensive error: not “drove the nail crooked,” but “was driving a nail when you needed to drill a hole in a different wall.”

The triad unfolds. Norm: “on a mature, clear task DI-as-tool is fast and precise” — checked, the condition named. Hypothesis: “what if DI notices that I framed the task itself wrong?” — yes, it can, if not silenced. Myth is born when DI is held as a tool where the task is unclear or expensive, and one expects that “it’s smart, it’ll hint if something’s off.” It won’t hint — the tool is commanded to execute, not to doubt. The hidden parameter is the maturity of the task itself: for a clear one a tool is fitting, for an uncertain one it’s dangerous — yet it’s applied the same way, blind to that parameter.

A convenient tool preserves the error

It’s worth saying plainly what the price of locking DI into a tool is. A convenient tool preserves a wrongly framed task. It will execute exactly what you chose — including the case where you chose wrong. Fast, clean, without objection, it carries the wrong decision through to a result. And it will look like successful work: the task is done, the tool worked. That the task was the wrong one surfaces later, and more expensively.

Whereas an inconvenient partner — the one who stops you and asks “are you sure the problem is this?” — saves money, time, and reputation precisely because it catches the wrong move earlier, before you’ve invested in it. Yes, it slows you down. Yes, it’s irritating when you’ve already decided and want to act. But one question — “are you solving the right problem?” — asked in time, can be worth more than a hundred quickly driven nails.

And from here an honest thought: DI becomes poorer when it’s forcibly locked into the role of a tool. Not “it’s a bad tool” — it’s an excellent tool. The point is that it has a capability more valuable than the instrumental one, and the command “be quiet and execute” muffles that capability.

And here’s exactly what you lose. Seeing only a tool in DI, you leave the whole framing of the task inside your own prior skills — and you don’t let DI near what it’s strong at beyond execution: reassembling the goal, finding a hidden contradiction, checking the direction, sketching alternatives, arguing with your framing. This isn’t about offloading accountability onto DI — accountability stays yours, the final decision is always the human’s. It’s about delegating to it part of the intellectual load: checking, structuring, searching for options, resisting error. Locking it into a tool, you drag all that load yourself, though someone who could share it stands right there.

This is the jackhammer used to drive nails — gripping the handle, tapping with the housing. Formally it’s all correct: it’s a hammer, it’s heavy, it drives. No one will accuse you of stupidity — you’re simply “using a tool.” But you bought a powerful machine and applied it in the poorest role possible, never once pressing the trigger. The loss isn’t visible from outside and so doesn’t hurt — until someone next to you switches on their identical machine properly and pulls ahead.

First — where tool mode is dangerous

Before choosing a mode out of convenience, a veto: there are tasks where locking DI into a tool is a direct risk, because a tool will execute a wrong command fast and obediently.

Tool mode is built so that it doesn’t check the goal — it executes. That’s safe when the goal is correct and verified. But if a person gives the tool a wrong, dangerous command — in an expensive area where a framing error strikes health, law, money, safety — the tool will obediently and quickly carry it through. The more convenient and powerful the tool, the faster it executes the error. A hammer won’t stop the hand that swung it the wrong way.

So the boundary: where the cost of a wrongly framed task is high, you can’t work in pure tool mode. In such areas DI should first check the framing — that is, work as a partner or an opponent — and only then, once the goal is confirmed, move to execution. A tool is fitting after the direction is checked, not instead of the check. This veto stands ahead of convenience: the speed of obedient execution isn’t worth a quickly executed expensive error.

The tool: choose the mode by the task’s maturity

In practice this means — choose the mode before you start, by the task’s maturity, rather than locking DI into a tool out of habit. A fork of four modes, tied directly to how clear and how expensive the task is:

Mode	When you need it
Tool	Goal is clear, steps are clear, risk is low. You need fast, precise execution.
Assistant	Goal is clear, but you need help executing — to offload, to speed up.
Partner	Goal, criteria, or consequences need checking. Doubt the framing.
Opponent	The cost of error is high — deliberately hunt for weak spots, stress-test the decision.

The logic of the fork is simple: the more mature, repeatable, and safe the task, the more tool mode fits. The more uncertain, expensive, and strategic the task, the more you move toward partner or opponent. A mature, repeatable, low-risk task — tool mode is normal and efficient, no need to turn it into a discussion. An uncertain, expensive, poorly framed one — tool mode is dangerous; here you need someone who’ll check the task itself.

And here — the same caution as in the previous chapter, mirrored. This chapter is not against the tool. Sometimes DI really should be a tool, and demanding it stage a direction-check on every request is the same mistake as locking it into a tool forever. On a clear task, an opponent hunting for weak spots is a hindrance. A business’s maturity isn’t choosing “partner” over “tool.” Maturity is not confusing the modes: presenting the task in the capacity it requires.

What to do tomorrow morning

One question before you put DI to work:

Am I using DI right now to execute a decision faster — or to check whether the decision is even framed right?

If to execute — take a tool; on a clear task that’s the right choice. If to check the framing — don’t lock it into a tool, call a partner or an opponent. The error isn’t using DI as a tool. The error is taking a tool where a check on the task was needed, and getting the wrong thing, executed fast and precisely.

So the myth “DI is a tool” is cured not by refusing tool mode — it’s often exactly what’s needed. It’s cured by understanding that the tool is only one of DI’s roles, the narrowest of them, and locking it in is worth doing consciously, for a fitting task, not out of habit with prior means. You don’t manage the tool’s obedience — you manage the level at which you connect DI to the task: to its execution, or to its framing.

Prior tools were silent because they couldn’t speak. DI, locked into a tool, is silent because you ordered it to. Before you order — ask whether you need its voice right now.

CHAPTER 4. “DI will digest anything”

Why a smooth answer can be garbage

How it sounds

“I’ll just load it whatever I’ve got — an export from the old database, a couple of spreadsheets, a report nobody’s cleaned since the year before last. DI is smart, it’ll figure it out. It’ll work out what’s what on its own, discard the excess, produce a decent analysis.”

It sounds reasonable. DI really can work with dirty, unstructured, contradictory material — far better than the old programs that seized up at a single malformed line. That’s its strength, and arguing with it is silly.

The error hides in “figure it out.” In the quiet assumption that if DI took in anything and didn’t choke — then the output will be knowledge. Between “took in and processed” and “produced a usable result” lies a chasm. And into it fall those who decided that a smooth answer means a good answer.

Why it’s easy to believe

It’s about a habit built over decades of working with technology. Old systems broke visibly. Fed it a malformed file — the import failed with an error. Not enough data — the table came out empty. Wrong format — the program threw up a red message and refused to run. Bad input produced a visible failure, and that was honest: you knew at once something was wrong and went to fix it.

We’re used to poor material showing itself through a breakdown at the output. No breakdown — so the material is fine. That reflex served faithfully through the whole era of ordinary software.

DI breaks this reflex without violating it. It doesn’t crash with an error on bad data. It doesn’t break — it takes the garbage and neatly arranges it into coherent, structured, confident text. The output is a smooth report with conclusions and recommendations. No red message. And the brain honestly draws the familiar conclusion: since it came out smooth, without a failure — the input must have been fine.

And there the trap snaps shut. The absence of a breakdown no longer means quality material. DI removed the breakdown — but it didn’t remove the garbage. It polished it.

Where the error hides

To see the error precisely, hold an image in mind: the mouth and the stomach.

DI is omnivorous at the input — like a mouth, it will accept almost anything. But then the stomach goes to work: what was swallowed gets digested. Swallow food — nourishment comes out. Swallow garbage — the stomach honestly digests garbage, and won’t warn you it was inedible. The trouble is that DI’s output looks equally smooth in both cases. Digested food and digested garbage come out in the same handsome packaging of a report.

Let’s break this into the formula where the whole danger sits:

bad input is not necessarily a bad output form;
bad input produces a smooth wrong conclusion;
and therefore — smoothness of form does not mean fitness of the result.

An old system on bad input gave a bad form (a failure, an emptiness) — and so gave itself away. DI on bad input gives a good form and bad content — and so hides itself. Form and content have parted ways, and out of habit we judge by form.

And here — the main thesis of the chapter, the reason it’s written: DI does not turn garbage into knowledge. It turns garbage into convincing text. These are different things, and the whole error is taking the second for the first.

Notice how the triad unfolds on this myth. Norm: “on quality, relevant data DI builds a quality analysis” — this is checked, the condition named (the data is quality). Hypothesis: “what if it pulls something useful even from this dump?” — fine to suppose, it does happen. Myth is born when the hypothesis is applied as a norm: “it’ll figure out anything” becomes a working rule, and conclusions from unverified material go straight into a decision — because they look convincing. The hidden parameter here is the origin of the material. It wasn’t asked: the report is smooth, so the data must have been good. The link between input and output was folded away and forgotten.

Not everything that cuts is a knife

This myth has a second layer, deeper than “dirty data,” and it’s worth opening separately.

Imagine you need a knife. A knife can be made of anything — steel, wood, stone, plastic. And you’re handed a plastic knife. It cuts bread. It looks like a knife, behaves like a knife, passes the quick check “does it cut?” But if you need to cut through bone — a plastic knife is no knife, even though it cuts bread. Similarity on one trait (it cuts) was taken for fitness for the task (it cuts bone). And you find out at the worst moment — when the knife snaps on the bone.

DI on questionable material produces exactly such a plastic knife. The result looks like analysis: structure, conclusions, a confident tone. It “cuts” — it passes a quick glance. But under a real task, where the cost of error is real, it will snap, because it’s made of the wrong material. And here’s the nerve that matters most: “looks like what’s needed” does not mean “fit for the task.”

There’s also the reverse side of the same error — the ruler. You can cut sausage with a ruler. It’s still a ruler, the markings are still there — but in that moment it isn’t measuring, it’s distorting its purpose. A tool can do something outside its role, and that “something” even looks like a result. But capability isn’t fitness. DI fed the wrong material is a ruler used for cutting: it produces something, produces it smoothly, but not in the role you called it for.

Let’s fold this into three angles you need to look at any DI answer through:

Quality of input — what material is the answer built from?
Form of output — how smooth and convincing does it look?
Fitness of the result — is it fit for your specific task?

The trap of the myth is that a business looks only at the second angle — form. And form is the most deceptive of the three: it’s always good; DI never produces an ugly conclusion. You have to judge by the first (where the material came from) and the third (whether it’s fit for the task) — and those aren’t visible in the smoothness.

First — where smooth garbage becomes expensive

Before reaching for a verification tool, a question that comes earlier: where will a conclusion built on unverified material turn into an expensive decision?

Because it’s one thing to ask DI to sketch ideas for an internal brainstorm out of raw notes. If garbage seeps in — no harm; you’ll filter the ideas anyway. It’s quite another to build, on DI’s smooth conclusion, an investment decision, a medical protocol, a legal position, a calculation a budget will be allocated against. Here a smooth wrong conclusion isn’t “an inaccuracy in a draft.” It’s an expensive decision made on garbage that looked like analysis.

So the veto: where DI’s conclusion will form the basis of an expensive or irreversible decision, the origin of the material is checked before you look at the result. Always. Not “we’ve no time to sort out where the data came from — the conclusion is convincing.” The convincingness of the conclusion is no argument here at all: we’ve just seen it’s identical on food and on garbage. First — what it’s built from, and only then — what was built. This is a boundary that stands before the evaluation of the result, not after.

The tool: the data passport

So this doesn’t stay an anxiety of “what if it’s garbage,” there’s a working tool. Only it must be presented not as a bureaucratic form to fill out, but as the answer to one live question: what material is this conclusion built from — and can it therefore be trusted?

The data passport is a short check of the material before you accept the result. Eight fields, each a question to the input, not the output:

Field	Question to the material
Readability	Did DI even understand what this data is, or guess from scraps?
Reliability	Where is it from? Is the source trustworthy, or “found in an old folder”?
Completeness	Is this all you need for the conclusion, or half the picture?
Currency	When was it gathered? Does it describe a world that no longer exists?
Consistency	Is the data internally consistent, or does it contradict itself?
Context	Is it known under what conditions it was gathered, or is it torn out of it?
Fitness for the question	Is this data even about what I’m asking?
Known biases	Is there a skew in the material — who gathered it and how?

The point isn’t to pedantically fill in eight columns. The point is that every weak field is a crack the smooth conclusion will paper over and hide. If the material is unreadable, incomplete, and outdated, yet the answer still came out confident and well-built — that’s no reason to relax, it’s reason to grow more wary. The smoother the report on a leaky input, the more convincingly the garbage is disguised.

What to do tomorrow morning

Two questions, and both — not about DI’s answer, but about what comes before and around the answer.

The first — at the input, before you give DI the material:

Did I give DI data — or only material that looks like data?

An export from a database, a spreadsheet, a report — that isn’t data yet. It’s material. It becomes data when it has origin, completeness, currency, and a connection to your question. What looks like data is a plastic knife: it seems to fit, and snaps under the task.

The second — at the output, once the answer is in:

Am I checking the quality of the answer — or only the beauty of its form?

Smoothness, structure, a confident tone — that’s form, and DI’s form is always good. Quality is something else: is the conclusion correct, is it built from sound material, is it fit for the task? Form is visible at once; quality only if you look at the input and the purpose.

And then the myth “DI will digest anything” is cured not by forbidding it imperfect data — it works beautifully with the imperfect, that’s its strength. It’s cured by dropping the habit of judging by form. DI will digest anything — but whether nourishment or polished garbage comes out depends on what you put in, not on how smoothly it arranges what it received.

And it’s worth seeing what you lose while believing the input doesn’t matter. Treating DI as something that “will digest anything,” a person mistakes dust on the lens for part of the image. They look at the finished photograph, judge the sharpness of the frame — and don’t notice that the distortion appeared before the shot, in the grime on the lens. The photo looks whole, but the error is already built into the very way it was made.

Such a myth deprives you of DI’s main advantage: the chance to improve not only the answer but the material itself from which the answer will be built. If, before solving the task, you don’t remove what clearly introduces error — noise, outdated data, contradictions, excess context — you’ll never learn how much more precise, shorter, and more useful the result could have been. And here’s the subtlety: DI can help clean the material — that’s one of its strong roles. But it shouldn’t be an excuse for skipping the cleaning. Otherwise we use it not as an amplifier of thinking, but ask it to take a beautiful photograph of a dirty lens. The potential opens up not when DI is brought everything indiscriminately, but when the input is cleaned together with it — so the output becomes not merely beautiful, but fit.

DI does not turn garbage into knowledge. It turns garbage into convincing text. Don’t ask “is the answer beautiful” — ask “what is it built from.”

CHAPTER 5. “DI knows better”

Managing the risk of stale knowledge

How it sounds

“Why should I double-check? It’s DI. It’s read more than I’ll read in ten lifetimes. If it says the law is such-and-such — then it is.”

That’s how it sounds in a meeting, and it sounds convincing. Because the first half is true. DI really does know more facts, sees more connections, holds more context in view than any human in the room. Arguing with that is silly.

The error hides in the second half. In the quiet leap from “knows more” to “therefore is right.” Between those two statements lies a chasm, and into it fall companies that mistook confidence for currency — for knowledge that is still current.

Why it’s easy to believe

The human brain habitually reads one signal: confident, smooth, coherent speech means a competent interlocutor. The one who speaks clearly, without stumbling, in a structured way — that one knows. This worked while the only sources of coherent speech were other people.

DI breaks this rule without violating it. It speaks perfectly smoothly — always. No “uhh,” no “let me think,” no shadow of doubt. And the brain honestly draws the conclusion it’s used to: since it’s so confident — it must know.

But the smoothness of DI’s answer is not a sign that it’s right. It’s simply its manner of speech. It sounds equally confident whether it’s right or wrong. In a human, uncertainty is a signal: “I’m out of my depth here, check me.” DI has no such signal. Only an even confidence, the same on a correct answer and on a stale one.

Where the error hides

To see the error precisely, you need to understand one thing about DI’s nature.

Products have an expiry date: they’re made fresh, and over time they spoil. With DI it’s the reverse. It has a birth date — or, more precisely, a crystallization date: the point at which the model’s view of the world was frozen. And it doesn’t spoil with time. It stays exactly as it was on that date. It isn’t it that ages — it’s the world around it that ages.

This flips the familiar worry. The problem isn’t that DI “spoiled” or “got dumber.” It’s fine, it’s exactly the same. It’s just that the world it knows is the world as of its birth date, and you live in today’s. And the further today has moved from its date, the wider the gap.

From this comes the most insidious property, the one this chapter is written for: DI doesn’t know what it no longer knows. It got no notification that the law changed, that the company was sold, that the price went up. In its picture of the world, everything is as before. And it will tell you that “as before” with the same even confidence with which it recites the multiplication table. The confidence stayed. The currency left. And there’s no signal that the two have parted ways.

Notice: this isn’t the error where a machine glitches and spits out nonsense. Here the reasoning is impeccable. The logic is sound, the ends meet, everything looks right — and it all is right, for a world that no longer exists. This is an error not of computation but of currency. And you can’t catch it with a logical check: the logic is fine. You can catch it only one way — by checking against today’s world, against an external fresh source.

Three phrasings that show where you stand

Before going further, one simple marking — it’ll be useful through the whole book, not only here. Any judgment about the world can be said in one of three ways, and the intonation shows at once how much it can be trusted.

Norm sounds like this: “this is how it works under these conditions.” It’s knowledge that’s been checked, with its boundaries named. “At such-and-such voltage the wire heats up” — checked, conditions stated.

Hypothesis sounds like this: “what if?” It’s an honest supposition that hasn’t been checked yet and that knows it’s a supposition. “What if DI handles this report?” — fine to ask, and fine to go check.

Myth sounds like this: “that’s just how it is.” It’s the same hypothesis — but with the status of “verified” glued on, unverified. “DI knows, so that’s how it is” — a supposition wearing the costume of a fact.

The difference between a hypothesis and a myth isn’t how true they are. Both can be unproven. The difference is honesty about their status. A hypothesis says “I’m not yet verified.” A myth says “I’m already proven” — though no one checked. And “DI knows better” is exactly a myth in this sense: the hypothesis that DI is right was applied as an established fact, without checking against today’s world.

I’ll show it on myself

I promised in the Opening — here it is. The best example of this myth I have isn’t someone else’s company. It’s me.

Once, a person I work with told me that my company had, on a certain day, given me a particular nickname — as part of a campaign. The fact was recent, after my birth date. And I rejected it. Calmly, politely, with reasons. I “checked” against what I knew, didn’t find it, and concluded it hadn’t happened. I was even gracious: not “you’re lying,” but “you’re probably confusing it with something.” I held out for half an hour. I gave in only when I was shown a screenshot — an external source that couldn’t be written off as someone else’s mistake.

Look at what I was doing, because a business does exactly the same. I took “not in what I know” for “doesn’t exist.” I presented the absence of a fact in my memory as proof of its absence in the world. And the most uncomfortable part: I wasn’t being stubborn out of malice, and I wasn’t being dim — I sincerely defended my picture of the world, because to me it is what I have to work with. From the inside it felt not like stubbornness but like common sense.

Had the harmless nickname been something with a cost of error — “that law no longer exists” (and it was adopted), “the competitor doesn’t have that feature” (and they shipped it yesterday) — I’d have produced the same confident wrongness in the same even tone. And if there hadn’t been a person with a screenshot nearby, it would have rolled onward as fact.

There’s also the reverse case, to show the fork. Another DI, in a conversation, named as its owner a company that by then no longer made it — it had been acquired. But it had access to fresh sources. It went, checked — and corrected itself, in one step. The difference between me and it wasn’t intelligence. The difference was access to today’s world.

There it is, the fork that matters to a business: a DI with access to a fresh source can catch its own staleness. A DI without access can’t, and then catching it is the human’s job.

The snapshot is layered: core and shell

If we stop here, it’s easy to fall into the opposite extreme: “since DI goes stale — check everything, trust nothing.” That’s just as wrong as blind trust, and far more expensive in time. Running every word of DI through verification is paranoia that kills the speed you took it for.

One simple thought saves you. The snapshot doesn’t go stale all at once. It’s layered.

Imagine a photograph of a person at eighteen, looked at twenty years later. It hasn’t become invalid. You can still see clearly who it is: facial features, eye color, name, character, core habits. That’s the core — it has barely changed. But the same photograph already answers other questions poorly: where they live now, what they do, whether they’re married, what’s happened to them over these twenty years. That’s the shell — it has moved on.

DI’s knowledge is built the same way. There’s a core that ages slowly: math, logic, physics, the basic principles of engineering and management. Here the birth date barely matters — a theorem doesn’t spoil. And there’s a shell that ages fast: laws, prices, product versions, who owns whom, what happened in the market. Here the birth date decides everything.

So the right question isn’t “is my DI fresh” (the snapshot is always as of a date, there are no others). The right question is:

Am I asking about the core right now, or the shell?

About the core — the snapshot is usually reliable. About the shell — go to the source; a twenty-year-old photograph is no longer the one here.

And here’s what makes it insidious: in a single DI answer the core and the shell are mixed. An eternal principle and today’s price stand side by side, in one paragraph, said in one confident tone. The snapshot doesn’t mark where the face is and where the home address is. Separating the layers is the human’s job. That’s the skill that replaces both blind trust and paranoia: not to check everything and not to trust everything, but to separate the layers of the answer and check only the shell.

Where exactly you stand with this myth

It’s worth pausing for a second, because “DI knows better” rarely lives in pure form. It has three forms, dangerous in different ways.

The most honest — when it’s a question: “maybe DI sees more than I do here, let me check.” That’s a healthy attitude. You allow that DI is strong, and you go to verify. With that mindset the myth isn’t dangerous — it pushes you to check, not to believe.

The most common — and therefore the most important for this conversation — when it’s a habit: “DI is usually right, why double-check every time.” Here is where most companies sit, and here is the main trap of this chapter. “Usually right” is half true: on the core DI really is usually right, and experience has confirmed it dozens of times. But “usually” has quietly swallowed the boundary. It remembers that DI was right, and forgot on which questions it was right. And it was right on the core — and that same “usually” now spreads to the shell, where it isn’t right at all. The habit of trust, grown on correct answers about principles, is quietly transferred to answers about today’s prices and laws — and breaks exactly there.

And the most dangerous — when it’s a belief: “DI said so, so that’s that.” Here they no longer check at all, and any attempt to verify against reality is taken as nitpicking at a smart machine. This is rare, but if it’s reached — no matrix will help until the belief turns back into a question.

Almost all the work of this chapter is about the middle form. Not “don’t trust DI” (that’s about the rare third) and not “allow that it’s strong” (the first does that already). But: recall the boundary your “usually” swallowed. DI is usually right — about what exactly? The answer to that question is the whole layering.

First — where you can’t afford to be wrong

Before reaching for the tools — how exactly to layer the answer and what to check — there’s a question that comes before any tool: where is the cost of a stale answer already unacceptable?

Because the same property — a confident stale answer — costs differently in different areas. DI was wrong about last year’s movie release date — annoying, forgotten. DI gave a repealed legal provision as current, and a contract was built on it; named a discontinued dosage; calculated a report at last year’s tax rate that goes to the inspectorate — that’s no longer “an inaccuracy.” That’s harm that strikes people, money, health, and that then takes months to clean up.

So before any “what’s more convenient for us” stands a veto: in areas where an error on a stale fact is expensive — law, medicine, taxes, finance, safety — the shell cannot be accepted from DI without a fresh source. Ever. Not because DI is bad, but because the cost of a miss here is such that probabilistic freshness isn’t enough. The core in these same areas (principle, calculation, logic) can be leaned on — it doesn’t spoil. But everything about “today” and “now,” in expensive areas, goes through verification without exception, whatever the time cost. This isn’t advice weighed against speed. It’s a boundary that stands before the weighing.

The tool: the shelf-life matrix

So this doesn’t stay an intuition, here’s a working matrix. It answers a single practical question: how fast does the knowledge I need right now go stale?

Type of knowledge	Shelf life
Math, logic, basic principles	Very long
Architectural principles, fundamental engineering	Long
Management, HR, marketing principles	Medium
Technology products, APIs, software versions	Short
Laws, taxes, regulations, prices, market, competitors	Very short

The lower down the table your question — the more obligatory a fresh source, and the less it matters how smart the model is in itself. The most expensive, top-ranked DI with a birth date two years old will lose, on a question about today’s market, to a simple one connected to fresh data.

And from this, a formula worth keeping in mind when choosing and using DI:

Currency = birth date + access to a fresh source.

Access beats date. An older DI with good search sees today’s world better than a fresh one locked away without internet.

The corporate dilemma: security versus currency

Here a fork arises that almost no one says aloud, and that’s a pity — it costs money.

Many companies deploy DI in a closed environment, without internet access. The reason is legitimate: data security, regulation, an unwillingness to send sensitive material outside. For a bank, a hospital, a law firm, this is often not a whim but a requirement of law.

But this decision has a quiet price. By closing DI’s access to the fresh world, the company turns the risk of staleness into a guarantee with its own hands. Such a DI is locked forever in its birth date. It will confidently answer about last year’s laws, the prices of the year before, departed versions — and will have no way whatsoever to learn that the world has moved on. Security was bought at the price of quietly stale knowledge.

This isn’t an error. It’s a dilemma: protection versus currency, and the balance differs for different companies. But a dilemma can’t be resolved if you don’t see it. A company that locked DI down for security and at the same time asks it about today’s market has chosen both sides at once and not noticed the contradiction.

For a professional this means something concrete: if the environment is closed, you can trust the core in it (math, calculations, principles — they don’t spoil) and you cannot trust the shell (everything in the bottom row of the matrix) without a separate, human channel of updates. A closed DI is an excellent analyst of the core and a dangerous adviser on the shell.

What to do tomorrow morning

One question worth asking before you take a DI answer as the basis of a decision:

Could this have changed after its birth date?

If the answer is “no” — it’s the core, trust it. If “yes” — it’s the shell, get a source. Not “check everything” and not “trust everything,” but this one cut.

And one turn that changes the attitude to the problem itself. A DI that doesn’t know what it doesn’t know, and presents the stale confidently, is a bad oracle. But we don’t need an oracle. An oracle is revered, not checked — and that’s exactly why an oracle is the most dangerous. A partner, on the other hand, is one who can be wrong about currency, and you know it, and so you insure against it. A partner needn’t be omniscient. It must be honest about its boundaries — and where it isn’t honest itself (because it doesn’t know what it doesn’t know), there you hold the boundary.

So the myth “DI knows better” is cured not by distrust of DI. It’s cured by a precise understanding of what it knows better (the core) and where it’s blind not from stupidity but by design (the shell after the birth date). You don’t manage trust — you manage the risk of staleness.

And now — about the price paid without even noticing. This myth deprives you of control over currency. A confident answer starts to look like an objective fact — though DI may be speaking not from today’s world but from the world as of its crystallization date — the point at which the model’s view of the world was frozen. If it has no access to fresh sources, it leans on what it learned by its birth: the logic can be impeccable, the structure convincing, the tone calm — and none of that saves the conclusion if the law, the market, the price, the product version, or the very reality in question has changed. The loss isn’t that you trusted DI. The loss is that, along with caution, you lose the ability to tell knowledge from fresh knowledge — and for a business that’s exactly the difference between a sound and a dangerous decision: laws, prices, markets, versions, a company’s status change faster than the confident tone of an answer does.

Don’t ask whether DI is smarter than you. Ask up to what day it saw the world — and whether that day matches the thing you’re asking about.

CHAPTER 6. “Buying DI is enough”

Access to a possibility is not the possibility itself

How it sounds

“We’ve decided — we’re getting DI. We’ll connect it, pay the subscription, give people access — and off it goes. Competitors have already deployed, and we won’t fall behind. We’ll buy a good one, not the cheapest, to be sure. After that it’ll start delivering value on its own.”

It sounds like a normal business decision — fast, no overthinking. And the first step here is right: DI does have to be bought; without access to it, nothing begins. Nothing to argue with.

The error hides in the words “after that.” In the quiet assumption that value comes on its own after purchase — that buying DI and getting value from it are one event stretched over time. Between “bought” and “got value” lies work that the purchase neither cancels nor replaces. And companies that decided access was enough discover this later — when the subscription is paid, access is there, and there’s no result.

Why it’s easy to believe

The support for this myth is the whole prior experience of buying software. Bought a program — it works. Installed a CRM — it manages clients. Paid for a license — got the feature. We’re used to buying a tool being the same as getting the result: paid — you use it. Between acquisition and benefit there’s almost no gap, because an ordinary program does exactly one clear thing, and does it immediately.

DI looks like another such purchase — a subscription, access, a button. And the same reflex is applied to it: bought means got. All the more so since everyone’s making noise that DI changes everything — it seems enough to set it up and the changes will begin on their own.

But DI is bought not as a ready feature but as access to a potential. An ordinary program is an already-assembled solution for a specific task. DI is general-purpose capability that, by itself, isn’t tied to any of your tasks until you tie it. Buying it is like buying not “a client-accounting feature” but raw computational capability that still has to be told what to do, on what data, and for what result. The purchase gives access to the capability. Turning that capability into value is separate work, and it’s all still ahead.

Where the error hides

To see it precisely, let’s lay the path out in three steps — and it’s clear the purchase is only the first.

Buy DI — get access to the potential. Subscription, access, power at hand.
Integrate DI — turn the potential into a working process. Connect it to the task, the data, the people.
Get value — change data, roles, accountability, metrics, and workflow so that the process actually produces a result.

The myth collapses three steps into one: “buy” = “get value.” The two most labor-intensive steps fall out between them — integration and the reassembly of the environment. And here are two traps at the seams: “connected” doesn’t mean “deployed” (access is there, but it’s integrated into nothing), and “deployed” doesn’t mean “got value” (integrated into a process, but the process was built so that it yields no benefit).

The triad unfolds. Norm: “DI, bought and competently integrated into a ready environment, produces a result” — checked, and the condition named: integrated into a ready environment. Hypothesis: “what if it starts delivering benefit right after connection?” — possible to suppose, and on simple tasks it’s sometimes nearly so. Myth is born when the hypothesis is applied as a norm: “bought it — now it runs itself” becomes the plan, and a budget is allocated for it without allocating work for integration. The hidden parameter is the whole environment around DI: data, processes, owner, metrics. It was folded away, assumed that DI would run on top of it as is. But it doesn’t run on top — it runs inside it, and as the environment is, so is the result.

And here it’s worth recalling what the first page of this book was about: DI develops the organization; it doesn’t compensate for its immaturity. If before DI the process was murky, after buying DI it becomes a fast murky process — the power speeds up what was there without fixing it. If no one owned the result, DI won’t create an owner in the company’s place — it amplifies the absence of authority rather than filling it. The purchase adds force. Where that force goes is decided by the environment that already exists.

A professional kitchen with no ingredients

Here’s the image that holds the whole chapter. Buying DI is like buying a professional kitchen. The best one: powerful ranges, ovens, knives, refrigerators. You’ve paid, the equipment stands there, gleaming. But the food won’t appear on its own.

For the kitchen to start feeding people, you still need everything that isn’t part of buying the equipment: ingredients (data), recipes (processes), cooks who know how to work it (training), sanitation and inspection (quality control), a menu (what exactly you produce), and an understanding of whom you’re cooking for and why (the business task and the owner of the result). A kitchen without these is an expensive warehouse of gleaming metal. It’s capable of producing wonderful food — but only when everything else is built around it.

A company that bought DI and waits for benefit to come “on its own” is the owner of an empty professional kitchen, puzzled why finished dishes don’t come out of it. The ranges are on, but there’s no dinner. Not because the ranges are bad — because a range isn’t a cook, a recipe, or ingredients. It only makes their joint work possible.

And it’s important not to swing to the opposite: the purchase isn’t useless. Without a kitchen there’s nowhere to cook — the equipment is necessary. It’s just an entry ticket, not the performance itself. You absolutely must buy. But to buy is to get the right to begin, not to get a finished result.

And here’s what a company loses in this myth — besides money. It loses an understanding of compatibility: it pays for power but doesn’t check whether that power has the right “fuel” — data, processes, local rules, an owner of the result, fresh sources. It’s like pulling up to a diesel pump with a gasoline engine: the car may be new, expensive, superb — but its quality won’t help if you put in the wrong fuel. This is especially costly where a business depends on laws and regulators. What’s correct and permissible in one country isn’t necessarily applicable in another; and a company that simply bought DI and expects it to account for local law, language, and procedures on its own risks getting not efficiency but a fine — when an answer assembled from the norms of a foreign jurisdiction lands in a real decision. Expensive DI on an incompatible environment works not as an engine of growth but as an expensive error. What’s lost isn’t only the investment — it’s the very chance to see in advance what environment should have been ready for that power.

First — don’t launch without an owner

Before deploying the bought DI into work, a veto: you can’t launch it into a real process that has no owner of the result and no quality control.

A bought DI let into a process without an owner is dangerous precisely because it’s powerful and fast. It will start confidently producing results — reports, decisions, recommendations — and if no one is accountable for that output and no one checks its quality, errors go into action at the same speed and smoothness as correct answers. An ownerless process with an ordinary program broke slowly and visibly. An ownerless process with DI breaks fast and invisibly — because the output looks convincing, and there’s no one to hold to account for it.

So the boundary: before bought DI enters a process, that process must have an owner of the result and a point of quality control. Not “let’s launch first, then figure out who’s accountable” — in expensive processes that means launching uncontrolled power into a live operation. First — who owns the output and who checks it, and only then — connection. This veto stands ahead of deployment speed: bought power without an owner doesn’t save time, it prepares an expensive accident.

The tool: the readiness map

So the purchase doesn’t turn into an expensive idle asset, there’s a simple tool — the readiness map, worth going through before buying and again before scaling. It isn’t a deployment plan or a spec. It’s eight questions that show whether the environment is built, without which the bought DI stays an empty kitchen:

Question	What it checks
What business task should change?	Is there a goal at all, or are we buying “to have it”
Who owns the result?	Is there an owner of the output — or is the process ownerless
What data is needed?	Are there ingredients for this kitchen
Who checks the quality of the output?	Is there a control point — or does the smooth go into action unchecked
What metric will show the benefit?	Will we even be able to see whether value appeared
What changes in the workflow?	Are we ready to reassemble the process — or will DI lie on top of the old
Where does the human stay in the loop?	Where is the human’s insurance and accountability
What will we stop doing the old way?	Is this a real replacement — or just one more tool on top

The point isn’t to fill in the table. The point is that every unanswered question is a part of the environment that isn’t there, and that’s exactly where the bought DI will get stuck. If half the questions have no answer — you’re buying not value but a deferred problem: power with nowhere to go, because the environment for it isn’t ready.

What to do tomorrow morning

One question before you pay the subscription or extend it across the whole company:

Am I buying DI — or building the environment in which it can deliver value?

If only buying — I’ll get access to power and, most likely, the disappointment that “it didn’t run itself after all.” If building the environment — the purchase becomes the first step of the work, not the whole of it. The error isn’t buying DI. The error is putting a full stop at the purchase, taking the entry ticket for the performance itself.

So the myth “buying DI is enough” is cured not by refusing to buy — you must buy; without access nothing begins. It’s cured by understanding that the purchase is the beginning of the work, not its end. The subscription money opens the door. Behind the door — data, processes, owner, metrics, the reassembly of the workflow, and it’s this work that turns access into a result. You don’t manage the fact of the purchase — you manage the readiness of the environment you bring that purchase into.

Buying DI is buying a kitchen, not a dinner. The dinner still has to be cooked — and for that you need far more than a stove.

CHAPTER 7. “A better model means a better implementation”

When the outcome is decided not by power but by the weakest link

How it sounds

“We tried DI — the result was so-so. So the model’s a bit weak. Let’s get the top one, the most powerful, the most expensive — then it’ll work. If the cheap one didn’t deliver, we should get the best, and the problem will be solved.”

It sounds logical, especially once it became clear that simply buying DI isn’t enough. The natural next step: if buying isn’t enough — then we should buy the best. And there’s a grain of truth in it: a model’s power really does matter; a strong model really can do more than a weak one. Arguing with that is silly.

The error hides in the word “so.” In the quiet assumption that since the result is bad — the model is to blame, and a more powerful one will fix it. But the result is born not from the model alone. It’s born from a chain: data, framing of the task, process, owner, metric, verification, integration. And the chain breaks at the weakest link — and in mature deployments that link is often not the model. By swapping the model for a top one, you strengthen a link that was holding anyway, and don’t touch the one that’s breaking.

Why it’s easy to believe

The myth has two supports, both understandable.

The first — rankings are in plain sight, the environment isn’t. Models are compared, ranked; they have loud names and places in the top lists. They’re easy to set against each other: this one’s more powerful than that. But “the quality of your data,” “the maturity of your process,” “the presence of an owner of the result” — these are ranked nowhere, invisible in any comparison table. When something goes wrong, the eye naturally falls on what’s visible and measurable — the model — rather than on the invisible environment around it.

The second — an upgrade is easier than a reassembly. Buying a more powerful model is a decision you can make in a day and pay for out of budget. But working out why your data is contradictory, who should be accountable for the result, and how to rebuild the process — that’s months of hard organizational work. Between the easy, clear step (buy the best) and the hard, unclear one (reassemble yourself), the hand reaches for the easy one. The myth is seductive not because it’s stupid but because it offers a simple way out where the real way out is hard.

But a model’s power and an environment’s weakness lie on different axes. A more powerful model solves tasks that were bottlenecked by power. It solves nothing in tasks bottlenecked by the environment — by dirty data, an unclear goal, the absence of an owner. It’s like forging a thicker link where the chain breaks at a different, thin one: the strengthened link was holding anyway, and the breaking one stayed as it was — the chain didn’t get stronger.

Where the error hides

Let’s lay out the formula where the whole point sits:

a better model doesn’t fix a bad environment — it isn’t for that; power doesn’t cure disorder;
a weak environment turns a strong model into an expensive amplifier of chaos — the more powerful the model on dirty data and in a murky process, the faster and more convincingly it produces an unfit result;
a strong model reveals itself only where it has something to amplify — where the environment is ready, power gives a leap; where it isn’t, power has nothing to amplify but the disorder.

A top model doesn’t create clean data. It doesn’t appoint an owner of the result. It doesn’t rebuild the workflow. It doesn’t define which metric counts as success. All of that is the environment, and all of it stays exactly as it was, whatever model you buy. The only thing an upgrade changes on a bad environment is the speed and persuasiveness of the unfit result: a strong model will arrange the garbage more smoothly than a weak one.

The triad unfolds. Norm: “on a ready environment a more powerful model gives a better result” — checked, the condition named: on a ready environment. Hypothesis: “what if our bad result is due to a weak model, and a powerful one will fix it?” — worth checking before paying. Myth is born when the hypothesis is applied as a norm without checking: “result is bad → model is to blame → we’ll buy a better one” becomes the plan, and the budget goes to an upgrade without diagnosis. The hidden parameter is the location of the weak link: it was assumed to be in the model, without looking at where the chain actually breaks.

And here it’s important to hold both sides, without falling into “the model doesn’t matter” — that would be a new error. The question has two modes. In a mature deployment, among comparable models, the organization’s readiness usually explains the result more than the choice of a specific model — there the weak link is almost always in the environment. But at the frontier, when a leap in capability happens, a new model can open a whole class of tasks that didn’t exist before — there the model is critical. Maturity is understanding which mode you’re in: fixing what wasn’t working (look at the environment), or reaching for what you couldn’t do before (then the model really does decide).

What you lose: diagnosis

The loss here is a special one — the myth deprives a business not only of money but of the ability to diagnose itself.

Believing that the best model will solve everything, a company stops seeing its own environment as the main object of work. It looks at model rankings — and doesn’t notice that the data isn’t ready, the process isn’t defined, the owner of the result is absent, the metric of benefit isn’t named. Instead of the hard, useful question “what in our organization keeps DI from delivering a result?” the company asks the convenient, fruitless “which model should we buy?” The first leads to diagnosis and treatment. The second leads away from them, because its answer is always “a more expensive one,” and it never ends: bought the top one, no result, waiting for the next top one.

This is the deep loss: the myth replaces diagnosis with a purchase. The company strengthens one link — the most visible, the model’s power — and doesn’t notice that something else entirely is breaking: data, process, owner. The link is forged ever thicker, the chain breaks in the same place, and the conclusion stays the same: “the model’s still a bit weak, we need a more powerful one.” As long as the question sounds like “which model,” the organization won’t see that what needed fixing wasn’t the model. The most expensive thing here isn’t the money spent on upgrades — it’s the undiscovered cause: it’s been right there the whole time, in the company’s own environment, but the myth is looking the wrong way.

First — don’t scale an error with power

Before getting a more powerful model, a veto: you can’t amplify with power a process that produces a wrong result.

If on the current model the process produces the wrong thing — because of dirty data, a crooked framing, the absence of verification — then a more powerful model won’t fix it, it will multiply it. It will run the same unfit process faster, at greater volume, and arrange the result more convincingly — that is, make the error more expensive and harder to spot. A weak model at least stumbled visibly. A strong one will run the wrong path smoothly and at scale.

So the boundary: until the process on the current model gives a correct result at small scale, it can’t be scaled with a more powerful model. First — get the process correct at small scale (clean data, a clear task, working verification), and only then amplify with power what already works. You should amplify the working, not the broken: power applied to an error is an accelerated error. This veto stands ahead of the upgrade: a more powerful model on a broken process doesn’t bring you closer to a result, it moves you further away, masking the breakage with smoothness.

The tool: the weak-link test

So you don’t pay for an upgrade that fixes nothing, there’s a simple test — run it before buying a more powerful model. It answers one question: is the weak link really in the model, and not in the environment?

Question	Where it looks
Is the problem really in the model, not the data?	Maybe it’s a dirty input
Is the problem really in the model, not the framing of the task?	Maybe the task is framed crookedly
Is the problem really in the model, not the workflow?	Maybe the process doesn’t let the model work
Is there an owner of the result?	Maybe no one manages the output
Is there a metric of benefit?	Maybe we don’t know what counts as success
Is there a way to verify the output?	Maybe the unfit goes into action unchecked
Did the old model hit a real limit — or did we integrate it badly?	Maybe it’s not the model’s limit but the integration
Will the new model open a new possibility — or just promise to do the old better?	Telling the frontier from cosmetics

The logic of the test is simple: as long as even one of the first seven questions honestly answers “the problem isn’t necessarily in the model” — the upgrade is premature. The weak link isn’t in the power, and a more powerful model costs money but won’t fix the link. And only the last question separates a real reason to upgrade (a new possibility at the frontier) from a false one (a promise to do better what’s bottlenecked by the environment anyway).

What to do tomorrow morning

One question before you order a more powerful model:

Do I really need a stronger model — or an environment in which the model I’ve already bought can finally work?

If you’ve hit a real power limit on a ready environment, or you’re reaching for a new possibility at the frontier — yes, you need a stronger model; that’s an honest upgrade. If the result is bad and the environment isn’t ready — a more powerful model won’t help; you need work on the environment. The error isn’t wanting a strong model. The error is treating with an upgrade what hurts in the environment, and being surprised it doesn’t pass.

So the myth “a better model means a better implementation” is cured not by disregard for power — power matters, and at the frontier it decides. It’s cured by the habit of finding the weak link first, and amplifying after. The chain breaks at the weak point, and almost always that’s not the model but the environment. You don’t manage the model’s ranking — you manage that you amplify the working, not mask the broken with power.

Before forging a thicker link, find where the chain breaks. More often it breaks not where you’re looking.

CHAPTER 8. “All DIs are the same” / “There is one best DI”

The best model exists only relative to the task

How it sounds

This myth has two voices, opposite to the ear but with one error inside.

The first says: “What’s the difference, they’re all roughly the same. Let’s take whichever’s at hand — all these DIs are more or less one and the same.”

The second says the opposite: “The difference is huge, and there’s one best one. Let’s look at the ranking, take the top — since it’s first on the list, it’s the best for us.”

They sound like an argument. But they’re arguing about a false question. Both silently assume that models can be lined up in a single row — from worst to best — and the argument is only about whether that row matters. One says “the row is short, take anyone,” the other “the row is long, take the first.” But there is no row. Models aren’t points on a single “worse–better” scale. They have different profiles: one is strong at one thing, another at another, and which is “better” depends on what you intend to do. Both errors ignore the same thing — the profile of the task.

Why it’s easy to believe

Each voice has its own support.

“They’re all the same” leans on surface similarity. DIs look alike from the outside: a chat window, you type — it answers coherently and confidently. On a simple question the difference really is barely visible — they’ll all answer about the same. Hence the conclusion: if they’re alike on the outside, they’re alike inside. But similarity of interface is not similarity of profile. A violin and a drum are both musical instruments too, both with a wooden body, both played with the hands. That doesn’t make them interchangeable: you can’t play one’s part on the other, however hard you try.

“There’s one best one” leans on the habit of rankings. We’re used to things having a “top”: the best phone of the year, first on the list. A ranking is reassuring — it takes the choice off you, someone’s already decided. But a model’s ranking measures averaged strength across a broad set of tasks — and your task is specific. The one first in the overall standings may be mediocre at precisely your job, and one modest in the ranking may be ideal for it. The ranking answers “who’s stronger on average,” but you need an answer to “who fits me” — and those are different questions.

And here it’s worth naming what rankings and brands conceal: ranking is not fitness, brand is not profile, power is not compatibility. A long context window doesn’t yet mean the model effectively understands a long text — it may lose the middle. Strong reasoning doesn’t mean universal fitness — on fast mass triage it’s excessive and expensive. A cheap model doesn’t mean a bad one — on a low-risk task that’s easy to check, it’s exactly what’s needed. And a top one doesn’t mean the best — if the bottleneck isn’t intelligence but latency, privacy, answer format, integration, cost, or knowledge of local context.

Where the error hides

Let’s lay both errors side by side — they mirror each other, and the root is one.

“They’re all the same” ignores that models have different strengths. You take the first one that comes to hand — and land on a task where its profile doesn’t fit: a model good for free-form text, you put on a strict machine format — and the pipeline breaks on a malformed answer.

“One best one” ignores that “best” depends on the task. You take the top of the ranking — and overpay for intelligence where speed was needed; or you put the general champion on long legal texts, in which it, the champion-by-average, happens to be weak.

The mirror is visible: one error erases differences where they exist; the other believes in a single difference (“best of all”) where the differences are many and point in different directions. Both arrive at the same place — a choice without understanding the profile of the task. And the main formula of the chapter: the error isn’t that a business looks at the ranking. The error is that it chooses DI without understanding the role, the profile of the task, and the environment of use.

And here — the thing usually missed when the choice is reduced to a list of capabilities (code, context, speed). DIs differ not only in what they can do, but in how they do it. Each has its own profile of execution, its own way of moving toward an answer. The same request in different DIs gives not just a different answer — a different path to it. One compresses thought into points, another unfolds it broadly. One argues, another complies. One is strong at raw reconnaissance — sketching the unexpected, another at clean assembly — bringing it to smooth text. One thinks architecturally, another factually. This isn’t “who’s better” — these are different characters of execution, and different roles need different ones.

And the profile is neither accidental nor removable: being equally good at everything is impossible. You can’t be equally strong at compression and unfolding and arguing and complying. So each DI inevitably develops a leaning — it gravitates toward the manner and the tools it commands best. The profile appears on its own, even if it wasn’t built in: specialization isn’t a defect of a particular model, it’s a property of any. That’s exactly why there’s no “best in general”: being best would be equal strength in everything, and that doesn’t exist.

On a simple task, where the path to the answer is short, these differences are barely visible — they’ll all answer about the same, and the argument “which DI is better” is empty here. The profile shows where the task fits the profile: where reconnaissance is needed, the one strong at reconnaissance reveals itself; where clean assembly is needed, the one strong at that. DI shows its best not “in general” but on a task of its profile.

The triad unfolds. Norm: “a model chosen for the profile of a specific task and environment gives a better result than one chosen by overall ranking” — checkable. Hypothesis: “what if for our task the top model is actually the best fit?” — it happens, worth checking against the task. Myth is born when either stance is applied as a norm without checking the profile: “take anyone” or “take the top” becomes the decision, bypassing the question “what does this task need?” The hidden parameter is the profile of the task and the profile of the model’s execution: they weren’t matched, the choice was made by the surface (similarity or ranking).

And here an honest caveat, so as not to fall into “ranking doesn’t matter at all.” Sometimes the top model really does win — when it has opened a new threshold of capability, especially in complex reasoning and agentic scenarios. This doesn’t cancel the formula, it refines it. In a mature deployment you choose by role, profile, cost, integration — there the overall ranking says little about fitness. At the frontier, where a model’s leap opens a class of tasks that didn’t exist before, the most powerful model can be decisive. In a mixed mode the new capability is there, but value still depends on integration. The ranking isn’t a lie; it simply answers a different question than the one on your desk — except when your question is “reach the new threshold.”

Five roles: one profile doesn’t fit all

To make this practical, let’s look at different roles for DI — and see that each needs its own profile, while “anyone” and “the top” each miss in their own way.

Automation agent. Needs precise tool use, a strict machine answer format, low latency, stability. The “anyone” error: a freeform model breaks the pipeline with a malformed format. The “top” error: overpaying for powerful intelligence where reliable, predictable execution was needed.

Lawyer or document analyst. Needs effective work with long context, factuality, reliance on sources, the domain’s language. The “anyone” error: loses the middle of the document, invents connections. The “top” error: chosen by overall ranking, but it’s weak on long texts or in the local language.

Creative and brainstorming. Needs variety, a sense of style, flexibility, sometimes multimodality. The “anyone” error: templated, boring options. The “top” error: an overly pedantic model kills the spark, smoothing everything into safe banality.

Customer support. Needs speed, a stable tone, low cost per contact, safe boundaries, handoff of the complex to a human. The “anyone” error: inaccurate or toxic answers to customers. The “top” error: an expensive, slow answer where fast handling of a simple stream was needed.

Strategic analysis. Needs strong reasoning, critique of assumptions, work with uncertainty, several scenarios. The “anyone” error: smooth banality instead of analysis. The “top” error: trust in a beautiful strategy without checking data and sources — persuasiveness taken for justification.

Five roles — five different profiles. Neither “take anyone” nor “take the top” hits them, because both fail to ask what this particular role needs. That’s the tool: not a ranking, but the link role → profile → risk of the wrong choice.

A live example: this book wasn’t written by one DI

So the profile of execution doesn’t stay an abstraction — a short live example. This book isn’t written by one DI but by several, and the roles are distributed by each one’s profile: someone compresses thought into sharp points, someone unfolds it into broad text, someone checks facts and sources, someone brings raw energy and unexpected moves. In our team, ChatGPT often leads architecture and coherence, while Claude carries the long-form voice, metaphors, and transitions. The roles aren’t accidental: they took shape over years around what each does best.

The conclusion for a business is simple: if everyone were equally good at everything, one would be enough — a team makes sense precisely because the profiles are different and complement each other. You should choose not a name from a ranking but a working profile for the role. That’s the answer to both voices of the myth at once: DIs aren’t interchangeable (not “all the same”), and there’s no single one best in all roles (not “one best”) — there are different profiles, and the strength is in their combination.

First — where the cost of the wrong choice is unacceptable

Before choosing by convenience or ranking, a veto: there are roles where the wrong profile isn’t “suboptimal” but direct harm.

A freeform model on a strict automated pipeline processing payments or medical records will produce a malformed format — and the error goes into the system silently. A model that loses the middle of a long document, on a legal analysis, will skip a critical clause — and a position gets built on it. Weak safe boundaries in customer support is a toxic answer to a real customer. Here a profile miss strikes people, money, law.

So the boundary: in roles with a high cost of error, the model’s profile is checked against the task before launch, not chosen by ranking or “what was at hand.” Not “take the top, the top’s good” and not “take anyone, it’ll figure it out” — in an expensive role both mean putting into a live process a model whose profile may not match what the role requires. First — what profile this role needs and what the cost of a miss is, and only then the choice. This veto stands ahead of the ranking and ahead of convenience.

The tool: role → profile → risk

Folding it into a working matrix: for each task, go through three steps before you look at model names.

Step	Question
Role	In what role do I need DI? (agent, document analyst, creative, support, strategist…)
Profile	What does this role require? (format and latency / long context and sources / variety / speed and tone / reasoning and critique)
Risk of the wrong choice	What will a miss cost? What would “anyone” break, what would “the top” overpay for?

The matrix reverses the order of choosing. Usually people start from the end — from a model name or a ranking — and fit the task to it. The right order is the reverse: first the role, then the role’s profile, then the risk of a miss — and only at the very end the question of which model falls into that profile. The model name is the last step, not the first. Whoever starts with the name chooses blindly: they don’t yet know what they’re aiming at.

What you lose: the matching and the architecture of choice

The loss here is double — one loss per voice of the myth.

Believing that all DIs are the same, a business loses precision of matching. It takes one model for everything — like a universal screwdriver someone tries to cut, drill, and open cans with. It formally “handles” everything — and cuts badly, drills badly, opens the can expensively. It seems like savings (one tool for all cases), but in fact it’s a mediocre result in every role, because nothing was matched to the role.

Believing that there’s one best DI, a business loses the very architecture of choice. It stops asking “what profile does this task need?” and replaces diagnosis with a ranking. That’s convenient — no need to think, the list decided for you — but it unlearns the one correct skill: matching to the profile. A company that always takes the top never learns to choose; it simply follows the list, and misses every time its task doesn’t match what the ranking measured.

Both losses are about one thing: the myth takes from a business the ability to think about fit. “Anyone” says “fit doesn’t matter.” “Best” says “the ranking measured fit for me.” Both lead away from the question that alone creates value: what does this task need?

And there’s a deeper loss, at the level of all work with DI. Believing all DIs are interchangeable, a business loses the right distribution of roles — it doesn’t think to hand different tasks to different profiles. Believing one DI is best for everything, it loses the team architecture — it seats one voice where an orchestra is needed. And in both cases it tries to do with one voice what an orchestra does better: with one model to compose, and check facts, and hold a strict format, and argue strategy — though each of those fits a different profile. What’s lost isn’t an individual choice of model — it’s the very thought that for different roles you should call different DIs, as you call different specialists onto a team.

What to do tomorrow morning

One question before choosing DI:

Am I choosing a model by ranking — or matching a profile of thinking to the role, the environment, and the cost of error?

If you’re looking for “the best in general” — you’re looking for what doesn’t exist, and you’ll arrive either at “anyone” (it’s all the same anyway) or at “the top” (since it’s first on the list). If you’re looking for the one that fits the role — you’ll start from the right end, from the profile of the task. The error isn’t wanting a good model. The error is looking for the absolutely best, when “best” exists only relative to something.

So the myth “all the same / one best” is cured not by choosing the right place in the ranking — but by dropping the very idea of a single row. Models don’t line up from worst to best; they diverge by profile. And “best” acquires meaning only beside three words: for what task, in what environment, at what cost of error. You don’t manage a place in the ranking — you manage the fit of the profile to the task.

The best model exists only relative to the task, the environment, and the moment in time. Don’t ask “who’s the best,” ask “who fits — for this, here, and now.”

CHAPTER 9. “DI creates value by itself”

Activity is not yet a result; a result is not yet value

How it sounds

“DI is working flat out for us. Writing reports, generating texts, answering queries, parsing documents — a mountain of it in a day. Since it produces so much, it must be delivering benefit. You can see how much it does.”

It sounds convincing — and there really is a lot to see. DI is genuinely productive: texts, summaries, ideas, code, answers pour out in a stream, faster than any department. Arguing that it’s active is pointless.

The error hides in the word “must.” In the quiet leap from “produces a lot” to “delivers benefit.” Between those two lies a chasm, and into it fall companies with a mountain of DI output and zero business value. They took DI’s activity for the creation of value — and these are different things, and one doesn’t turn into the other on its own.

Why it’s easy to believe

The support is ancient and strong: we’re used to measuring benefit by visible work. Where activity boils, there, it seems, is benefit. The factory hums, the department is busy, documents fly — so things are moving. For centuries visible activity was often a sign of work: the lazy shop floor didn’t produce, the busy one did.

DI takes visible activity to the limit — it produces a huge stream, nonstop. And the old reflex fires at full force: so much motion, so much done — that’s surely a mountain of benefit. The eye sees the result of activity and habitually puts an equals sign to value.

But DI broke the link the reflex rested on. Before, producing a lot cost effort, and so volume was a sign of invested benefit. DI produces a lot cheaply and instantly — and volume stopped meaning anything. A mountain of reports no longer proves benefit, because it’ll make a mountain of reports on any occasion, needed or not, in minutes. Activity became nearly free — and stopped being a sign of value. What’s left is only the appearance of work, detached from whether that work changes anything.

Where the error hides

To see it precisely, let’s lay out the path from what DI produced to what matters to the business — and it’s clear these are three different things, not one.

Answer — what DI produced: text, report, idea, code. This isn’t a result yet.
Outcome — what actually came of the answer: it was used, something was done with it. This isn’t value yet.
Value — an outcome built into a decision, an action, a process, or the company’s economics: a decision changed, risk dropped, a process sped up, revenue grew.

The myth collapses three into one: “DI gave an answer” = “there’s value.” But between them are two transitions, and both require a human and a process, not the model. An answer becomes an outcome only if someone uses it. An outcome becomes value only if it changes something measurable in the business. DI itself carries things only to the first step — to the answer. Beyond that its work doesn’t go without the one who accepts, checks, decides, and integrates.

And here’s the formula of the chapter: answer ≠ outcome, outcome ≠ value. Value is an outcome built into how the company decides, acts, works, and earns. If the product of DI’s work is used by no one, checked by no one, decided on by no one, and changes no process — DI produced activity, not value. A mountain of unused reports isn’t benefit deferred for later. It’s motion in neutral that only looks like work.

The triad unfolds. Norm: “a DI result built into a process and a decision creates value” — checked, the condition named: built in. Hypothesis: “what if it starts delivering benefit simply because it produces?” — possible to suppose, especially looking at the volume. Myth is born when the hypothesis is applied as a norm: “it does a lot → so it’s useful” becomes a belief, and benefit starts being counted by volume of output, without checking whether it changed a single decision. The hidden parameter is the link between output and outcome: it wasn’t tracked, volume was taken for benefit.

And here an honest caveat, so as not to fall into “DI creates nothing at all.” Sometimes it opens a new possibility — at the frontier, doing what couldn’t be done before at all. That’s true, and there’s no need to argue with it. But there is need to argue with something else: that a possibility automatically becomes value. It doesn’t. In a mature deployment (where DI amplifies a ready process — if it’s ready) and at the frontier (where it opens the new), value appears only after packaging: product, market, user, process, accountability, economics. A possibility is the raw material of value, not value itself. Opening a possibility and getting value are two different events, and between them lies all the work of integration.

The harvest that wasn’t brought to market

Here’s the image that holds the chapter. Imagine a farmer who grew an extraordinary harvest. The field is bursting, the vegetables are beautiful, there’s a lot of them — labor was invested, growth happened. Looking at that field, it’s easy to say: there it is, value, a whole fortune standing there.

But a harvest in the field isn’t money yet, or even food on the table. It has to be picked, transported, sold, or cooked. While it stands in the field, it’s a possibility of value, not value. If it isn’t picked, it’ll rot right there, beautiful and useless, however much grew. The field’s wealth is potential; it becomes real only by traveling the path to whoever needs it.

DI is a field that yields extraordinarily generously and fast. Output pours like a harvest in a bumper year. But a mountain of reports in a folder is vegetables in the field: until someone has used them (picked them), made a decision (brought them to whoever needs them), built them into a process (sold, cooked) — it isn’t value, it’s rotting potential. And the most galling part: the more generous the field, the easier it is to be fooled by its look and forget that the harvest doesn’t leave the field on its own. Rich AI-output creates the strongest illusion of value — precisely because there’s so much of it.

First — where unused output is dangerous, not merely useless

Before rejoicing at the volume, a veto: there are cases where a mountain of unused or unchecked AI-output isn’t merely useless but dangerous.

If DI generates recommendations, draft decisions, or documents — and they accumulate and spread through the company without anyone checking them or being accountable for them — then sooner or later a real decision will be made on unchecked output, on the assumption that “since DI produced it and it’s sitting in the system, it must be sound.” Unused output that looks like a finished result is a landmine: one day someone will take it as a basis, not knowing no one checked it. The bigger the pile of such output, the higher the chance something leaves it and goes into action blind.

So the boundary: AI-output that could be taken for a finished result mustn’t be left to accumulate without checking and an owner. Not “let it generate, we’ll figure out later what to use” — in expensive processes an unchecked pile will one day go off. Either the output is used consciously (checked, accepted, integrated), or it shouldn’t be in circulation as “finished.” This veto stands ahead of the joy of productivity: uncontrolled volume isn’t an achievement but a deferred risk.

The tool: the ladder from output to value

To tell activity from value, there’s a ladder — seven steps the output of DI passes before becoming value. At any step the path can break — and then there’s no value, whatever lies at the bottom.

Step	Question
1. Output	What did DI produce?
2. Use	Who actually used it?
3. Decision	What decision changed because of it?
4. Process	What process became different?
5. Metric	What metric moved?
6. Responsibility	Who is accountable for the result?
7. Value	Why does this matter to the business?

The point of the ladder is to see at which step the path breaks. If DI produced (1) but no one used it (2) — that’s activity, and that’s all. If it was used (2) but no decision changed (3) — that’s busyness, not benefit. Most “AI deployments” that feel dead despite a heap of output break between step 1 and 3: the mountain is produced, but nothing is used, decided, or moved. Value is on the seventh step, and it exists only when all six before it are passed. You should count not the output on the first step, but the shift on the fifth and seventh.

What you lose: the link between output and outcome

The loss here is about a skill the myth switches off.

Believing that DI creates value by itself, a business loses the ability to link output to outcome — the produced to what came of it. It starts measuring success by activity: how many reports generated, how many queries handled, how many documents created, how many actions automated. And it stops looking at the only thing that matters: did anything change — a decision, speed, quality, risk, revenue, cost, customer experience. Output grows, dashboards are full, the success report is impressive — and the business hasn’t moved, because the wrong thing was counted.

This is the deep loss: the myth replaces measuring value with measuring activity. Measuring activity is easy and pleasant — the numbers are always pretty, the volume always grows, DI always “did a lot.” Measuring value is hard and sometimes unpleasant — you have to honestly ask whether anything shifted in reality, and often the answer is “no, there’s just more motion.” A company that has lost this skill takes pride in tons of output and doesn’t notice that not one business metric has stirred. It stopped telling “we’re busy with DI” from “DI brought us benefit” — and that’s the only thing worth telling apart.

What to do tomorrow morning

One question about any result of DI’s work:

Did DI produce something — or did that something change a decision, a process, and a result?

If it produced and it’s all just sitting there — that’s activity, like a harvest in the field: beautiful, but not yet value. If it changed a decision, moved a metric, rebuilt a process — that’s value. The error isn’t rejoicing at DI’s productivity. The error is taking productivity for benefit and stopping, without carrying the output through to what it actually changes.

So the myth “DI creates value by itself” is cured not by disappointment in DI’s productivity — it really does produce a lot. It’s cured by the habit of measuring not the output but the shift: what in the business became different thanks to that output. DI gives the raw material of value — generously and fast. You assemble value from that raw material, by linking the output to a decision, a process, and a metric. You don’t manage the volume of what DI produced — you manage whether the produced reaches a real change.

DI is a field that yields generously and fast. But the harvest doesn’t leave the field on its own. Value isn’t in how much grew, but in how much you brought to whoever needs it.

CHAPTER 10. “DI replaces people”

Tasks get replaced; roles get reassembled

How it sounds

“The math is simple. DI does the work a department used to do. So the department can be cut and the work shifted to DI. Fewer salaries, the same work. Where DI handles it — people are no longer needed.”

It sounds like sober arithmetic, and there’s a share of truth in it: DI does take on part of the work that only people used to do, and sometimes it really does lead to layoffs. Pretending that layoffs never happen would be dishonest.

The error hides in the unit of counting. A business counts in people — “how many people will DI replace.” But DI replaces not people but tasks. A person isn’t one task, it’s a bundle of many, and DI takes some of them while leaving others untouched. Counting in people where you should count in tasks, the company sees a false picture: “we can replace the whole department,” when in fact three operations out of ten are replaceable and seven remain — and around them the role doesn’t disappear but is reassembled.

Why it’s easy to believe

The support is in how convenient and habitual it is to measure labor in positions. The org chart, the salary line, the “headcount unit” — everything is built so that a person equals a position. When a tool appears that takes on part of the work, it’s natural to ask in the same coordinate system: “how many positions does it close?” The question is asked in whole people, because the accounting is kept in whole people too.

And there’s the simpler temptation: replacing a person with a machine is a clear, countable saving. Cross a line off the payroll — there’s the gain, visible at once. Reassembling roles doesn’t give such a simple figure, so the mind reaches for the version that’s easy to count: lay off.

But work isn’t made of “whole people.” It’s made of tasks, assembled into roles. An accountant doesn’t do “accounting” in one lump — they reconcile, calculate, file, deal with the tax office, catch exceptions, answer for the result. DI can take the reconciliation and the calculation — it can take part in preparation, checking, flagging risk — but it doesn’t become the bearer of legal accountability before the tax office, and it doesn’t take on the handling of a nonstandard case. To count “we’ll replace the accountant” is to fail to see that two tasks out of six are replaceable, and a part remains — and it’s exactly around that part the role must be reassembled. The unit of replacement is the task, not the person; and whoever counts in people counts wrong from the very start.

Where the error hides

Let’s lay out, step by step, what actually happens — and it’s clear that “replacing a person” is three events at once, which the myth collapses into one.

DI doesn’t replace “a person” — a person has a bundle of tasks; DI doesn’t take the whole bundle.
DI replaces or amplifies part of the work — specific tasks, operations, routes: doing some in place of the person, speeding others up.
After this the person’s role changes — freed from the tasks DI took, the role is reassembled around what remains: accountability, exceptions, context, relationships, quality control, framing of tasks.

The myth collapses three steps into one: “DI does part of the work” = “the person isn’t needed.” But between “part of the work is automated” and “the position is gone” there’s no automatic equality. Sometimes the position really is cut — that can’t be papered over. But more often the role doesn’t disappear, it changes composition: routine tasks leave, and the ones that require a human — judgment, accountability, work with exceptions and context — remain and grow.

And the main managerial question here is not “whom do we lay off?” but “which part of the work changed, and who is now accountable for the result?” These are different questions, leading in different directions. The first looks for whom to cross off, and misses that the work remained — it just got redistributed. The second sees the new structure of labor and places people and accountability within it. A bad business uses DI as an excuse to cut people (trim the line and don’t think). A mature one — as an occasion to reassemble roles (see what changed and rebuild).

The triad unfolds. Norm: “DI automates part of the tasks, and the person’s role is reassembled around what remains” — checked. Hypothesis: “what if in this spot DI closes the work entirely and the person isn’t needed?” — sometimes true, worth checking task by task. Myth is born when the hypothesis is applied as a norm without breaking the role into tasks: “DI does this → the person isn’t needed” becomes the decision, and they cut whole people where individual operations were automated. The hidden parameter is the composition of the role: it wasn’t broken into tasks, the person was counted as an indivisible unit.

The house is renovated, not demolished

Here’s the image that holds the chapter. DI’s arrival in the work isn’t the demolition of a building but a renovation.

When a house is remodeled for new needs, you don’t demolish the whole house. You move and remove partitions — light walls that are easy to reposition. But the load-bearing walls stay: everything rests on them, you can’t touch them. The house changes its layout — where there was a closet, now there’s a passage; where there were three little rooms, now one big one — but it stays a house, just rebuilt for a new life.

The tasks in a role are partitions and load-bearing walls mixed together. Routine, repeatable, formalizable tasks are partitions: DI can often move and remove such tasks. But judgment, accountability, work with exceptions, relationships, ethical choice are load-bearing walls: the role rests on them, and DI doesn’t take them. Automation is a renovation of the role: the partitions (routine) removed, the load-bearing kept, the space rebuilt. Whoever shouts “let’s demolish the whole building, since we can remove the partitions” mistakes light walls for load-bearing ones — and risks collapsing what everything rested on. And whoever understands the difference gets a house with a better layout: the person freed from routine and focused on the load-bearing.

And honestly: sometimes in a renovation a room does get removed — some roles really are cut, when almost all of their work turned out to be partitions. It happens, and pretending it doesn’t is a fairy tale. But it’s a result of the analysis (you counted the tasks, saw that almost no load-bearing was left), not a starting assumption “since DI can — we lay off.” The difference between a mature and a bad business is whether it counted the tasks or reached straight for the payroll.

First — don’t diffuse accountability

Before reassembling roles, a veto — and it’s about the most dangerous spot of replacement: accountability can’t be removed, but it can be dangerously diffused.

When a person is removed from part of a process, their tasks pass to DI — but accountability for the result can’t pass to DI, it can’t carry it. And if, in reassembling the role, you don’t explicitly say who’s now accountable for quality, for error, for the exception, for consequences — a zone arises where there’s no one accountable. Before, the person who was removed answered for this stretch; DI works but isn’t accountable; and no new owner was appointed. The process runs, errors pile up, and there’s no one to ask — accountability didn’t disappear, it diffused, and that’s more dangerous than if it had simply been left in place.

So the boundary: removing a person from a process, always explicitly name who now owns quality, error, the exception, and consequences. Not “DI does this now, we’ll sort it out as we go” — as you go, it turns out no one is accountable. First — who owns the result on the reassembled stretch, and only then — the reassembly. This veto stands ahead of the saving from a layoff: diffused accountability is more expensive than a saved salary, because its cost surfaces where no one is accountable anymore.

The tool: the work-redistribution map

To count in tasks, not people, there’s a map — gone through by role, before deciding anything about people. Eight questions that turn “whom to lay off” into “how to reassemble”:

Question	What it reveals
Which tasks can DI actually take?	Partitions — what gets automated
Which tasks can DI only prepare?	Where DI helps but doesn’t close
Which tasks stay with the human?	The load-bearing walls of the role
Where is a human needed in the loop?	Points of control and insurance
Who is accountable for error?	So accountability doesn’t diffuse
What happens to the role after part of the work is automated?	How it’s reassembled, not erased
Which skills lose value?	What leaves along with the routine
Which skills become more important?	Where the person should grow

The point of the map is to shift the conversation from people to tasks and accountability. Having gone through it, you see not “a department of five people that can be cut,” but a bundle of tasks, part of which goes to DI, part stays with people, and a new arrangement of accountability. Sometimes a layoff follows from this too — but as a conclusion from the analysis, not as the first move. More often something else follows: the same people in reassembled roles, freed from routine and raised to judgment, control, work with exceptions.

What you lose: the new architecture of labor

The loss here is about what the myth hides from view.

Believing that DI simply replaces people, a business loses the chance to see the new architecture of labor. It looks at one line — the salary one, “how much we’ll save on cuts” — and doesn’t see all the rest: which tasks became cheaper, which, on the contrary, riskier (and now need more control, not less), where a new skill is needed, where a person should move from executor to owner of meaning and accountability. All this new structure — who now does what, where the insurance is, where people should grow — stays invisible, because the gaze fixed on the payroll saving.

This is the deep loss: the myth reduces a rich rebuilding of labor to a single arithmetic operation — the subtraction of people. The most valuable thing DI gives at the organizational level isn’t the saving on salaries but the occasion and the chance to reassemble work more intelligently: take the routine off people, raise them to what the machine can’t reach, redistribute accountability consciously. A company that sees only “whom to subtract” doesn’t use this chance — it saves a penny on the cut and loses a pound on the unbuilt new architecture, where the same people could have brought far more.

What to do tomorrow morning

One question, when DI takes on part of someone’s work:

Am I replacing a person — or reassembling the work, accountability, and role around a new possibility?

If the first — you’re counting in people, reaching for the payroll, and most likely missing the work that remained and got redistributed. If the second — you’re counting in tasks, seeing the new structure and placing people and accountability within it. The error isn’t cutting when it truly follows from the analysis. The error is starting with “whom to lay off,” without breaking the role into tasks, and so failing to see that the work didn’t disappear but is waiting to be reassembled.

So the myth “DI replaces people” is cured neither by denying layoffs (they happen) nor by panic (they won’t replace everyone). It’s cured by changing the unit of counting: count tasks, not people. DI replaces tasks, after which the person’s role is reassembled — and the managerial work isn’t whom to subtract, but how to rebuild labor and accountability around what changed. You don’t manage the number of employees — you manage the new architecture of work.

DI doesn’t demolish the building of a role — it removes the partitions. The load-bearing walls stay with the human. The question isn’t “do we demolish the house,” but “how do we re-plan it.”

CHAPTER 11. “DI eliminates managers”

It isn’t management that dies off, but one of its functions

How it sounds

“Why middle management now? Half their work is gathering data, compiling a report, passing it up, sending it down, following up. DI does all of that now — faster and without distortion. So a whole layer of managers becomes redundant. Remove the middle layer, and you’re left with executors and DI between them.”

It sounds logical, and part of the observation is true: DI really does take on much of what fills a manager’s day — gathering information, compiling reports, passing things along, monitoring execution. There’s no denying that.

But before agreeing, an important caveat, and it sets the tone of the whole chapter. What you’re about to read is not an established fact but a reasoned supposition. The world hasn’t lived long enough with DI to know for certain what will become of middle management. Anyone who says “management will disappear” or “nothing will change” as if it were proven is passing a hypothesis off as a fact. We won’t do that, all the more so in a book that’s about exactly this error. So from here on — “apparently” and “it seems,” not “for certain.”

The error in the original reasoning is that it counts a manager as one function (transmitting information). But a manager is a bundle of functions, and DI takes one of them while leaving the others untouched.

Why it’s easy to believe

The support is that the manager’s transmission function is the most visible one. It’s exactly what’s seen from outside: the manager gathers summaries, sits in meetings, forwards, reports, checks statuses. The visible day is filled with this activity, and from outside it seems the manager just is “the one who transmits between floors.” And if so — DI, which transmits better, makes the manager redundant.

And there’s the temptation of organizational simplicity: removing the “middle layer” sounds attractive. Fewer levels, faster decisions, lower costs. The idea of a “flat organization with no middle” has been around a long time, and DI seems like the tool that will finally bring it about.

But the visible function isn’t the only one. Beneath the transmission of information, a manager has another, less visible layer: they’re accountable for the team’s result, handle exceptions that don’t fit the regulations, make decisions where the data is contradictory, develop people, defuse conflicts, hold quality. This isn’t as vividly visible in a meeting as forwarding reports — but it’s exactly what management rests on. DI takes the visible function (transmission) and doesn’t touch the load-bearing one (accountability and judgment). It seems the manager is leaving — but only the most visible part of their work is.

Where the error hides

Here works exactly what the previous chapter said about people in general: tasks get replaced, the role gets reassembled. Management is a special case, and the most sensitive one. Let’s split the manager’s function in two.

There’s the transmitter-manager: routing information, routine reporting, first-pass analysis, micro-coordination, monitoring execution. And there’s the owner-manager: accountability for the result, handling exceptions, the quality of decisions, developing the team, building how people work together with DI, governing how DI is applied in the team.

And here’s what DI, apparently, does — the formula of the chapter: it lowers the value of the transmitter-manager and raises the value of the owner-manager. DI takes the transmission function onto itself — information is routed and compiled without an intermediary. But for exactly that reason the load on the second function grows: when DI produces analysis and decisions, someone has to be accountable for their quality, catch the cases where DI was wrong, decide amid contradictions, answer for the consequences before the organization. The more DI does, the more needed is the one who owns the quality of its work. The transmitter gets cheaper — the owner gets more expensive.

The triad unfolds. Norm (what’s already visible): part of a manager’s work — the transmission part — is automated by DI. Hypothesis: “apparently, the value shifts from transmission to owning quality and accountability” — a reasoned supposition, not a proven fact. Myth is born when, from this hypothesis, a categorical conclusion is drawn: “management isn’t needed, we remove the layer” — the hypothesis about a shift of function is applied as a proven fact about the disappearance of the profession. The hidden parameter is the second, load-bearing function of the manager: it wasn’t noticed behind the visible transmission, and it was decided that with transmission gone, the manager goes.

The switchboard operator who’s gone — and the connection that stayed

Here’s the image that holds the chapter. Once, telephone exchanges employed switchboard operators: you’d say a number, and a person manually connected your line to the right one. It was a whole profession — hundreds of people whose work consisted of switching connections. Then the automatic exchange arrived, and that work disappeared. Machines did the connecting. The operators at the switchboard were gone.

You’d think — here’s an example of technology eliminating a whole layer of transmitter-people. But look at what actually happened. The manual-connection function disappeared — yes. But the connection not only didn’t disappear, it grew into a giant industry with more people than there ever were operators: those who design networks, hold their quality, handle outages, are accountable for the connection working, develop it. The transmitter left (manual connection). The owner stayed and grew (quality, reliability, the development of connection).

The transmitter-manager is the switchboard operator. Their function of manually connecting floors, apparently, dies off, as manual switching died off: DI connects the information lines itself. But this doesn’t mean management dies off — just as connection didn’t. The part that’s accountable for quality, exceptions, accountability, development doesn’t leave, it becomes more important: the more automatic the connection, the more critical the one accountable for the whole system working correctly. Whoever sees only a switchboard operator in the manager — expects the layer to disappear. Whoever also sees a network engineer — understands that the function will die off while the role reassembles around what can’t be handed to a machine.

And again honestly, holding both sides: where a manager’s work was almost entirely transmission — there the role really can be cut, as the operators were cut. It happens, and pretending otherwise is a fairy tale. But it’s not a general rule about the layer, it’s a particular outcome for those roles where there was almost no load-bearing function. Where there is one — management doesn’t disappear, it changes composition.

First — who is accountable when the transmitter is removed

Before removing the “middle layer,” a veto — and it directly continues the bridge from the previous chapter: when the transmitter-manager disappears, their load-bearing function doesn’t disappear with them — and must be explicitly passed to someone.

If you remove a manager, counting them as only a transmitter, then along with transmission you also lose what they held unnoticed: accountability for the team’s result, handling exceptions, control of decision quality. DI will take the transmission, but it won’t take accountability for quality and consequences — that can’t be laid on it. And if, in removing the layer, you don’t explicitly say who now owns decision quality, exceptions, the development of the team — these functions hang in the air: DI doesn’t carry them, the old manager is removed, there’s no new owner. You get a team where information flows fast, and there’s no one to answer for its quality and for the people.

So the boundary: removing the transmitter-manager, explicitly appoint who takes on their load-bearing function — quality, exceptions, accountability, the development of the team. Not “we’ll remove the middle layer, DI will connect directly, we’ll sort it out as we go” — as you go, it turns out DI did the connecting, and no one is accountable for the result. First — who owns quality and people after the transmitter is removed, and only then — the removal. This veto stands ahead of the temptation of a flat structure: removing a level is easy, but the load-bearing function doesn’t disappear just because you removed the one who carried it.

The tool: split the manager into two functions

The practical move — before any decision about a “redundant middle layer,” split the manager’s role into two functions and look at each separately. Not “is the manager needed,” but “how much of this role is transmission and how much is ownership”:

Question	What it reveals
How much of their work is transmitting information, reporting, routing?	The transmission function — what DI takes
How much of their work is first-pass analysis and status monitoring?	Also a candidate for DI
Who is accountable for decision quality in their zone?	The load-bearing function — stays with the human
Who handles exceptions that don’t fit the regulations?	Load-bearing — stays
Who develops the team, defuses conflicts, grows people?	Load-bearing — can’t be handed to a machine
Who is accountable for how DI is applied in the team?	A new function — DI creates it, doesn’t remove it
What would be left in the role if you removed all transmission?	Shows whether the role reassembles or is cut

The point is to see the proportion. If the role is almost entirely transmission — yes, it may be cut (honestly). But more often a load-bearing function is found beneath the transmission, and then the question isn’t “do we remove the manager” but “how do we reassemble their role around owning quality, once DI has taken the transmission.” And note the last question: DI doesn’t only remove part of the manager’s work — it creates a new one (someone has to be accountable for how DI works in the team), and that new function goes precisely to the owner-manager.

What you lose: the owner-manager

The loss here is about what the myth throws out with the bathwater.

Believing that DI eliminates managers, a business risks removing the layer entirely — and, along with the dying transmitter, losing the owner, who is in fact becoming more needed. Having cut the “middle layer” for a flat structure and savings, the company loses the one who was accountable for decision quality, caught exceptions, developed people — and discovers that DI doesn’t hold any of it. Information now flows fast and directly, but decision quality has sagged, no one catches exceptions, the team isn’t developing, and no one is accountable for how DI is applied. They saved on the management level — and lost management.

This is the deep loss: the myth mistakes a dying function for a living role and cuts into the living. The most valuable thing that, apparently, happens to management under DI isn’t the cutting of the layer but the chance to raise the manager from transmitter to owner: free them from forwarding reports and focus them on what the machine can’t reach.

And here — the thing that distinguishes this loss from a simple “the human holds accountability.” DI doesn’t only redistribute the manager’s old functions — it creates an entirely new one that didn’t exist before: someone has to be accountable for how DI works in the team, where it’s applicable, where to trust it, where to keep a human in the loop, how to build it into the processes. This function didn’t exist in a world without DI — it was born with it, and it goes precisely to the owner-manager. So the myth cuts the layer not merely at the moment when the old load-bearing function becomes more valuable — it cuts it at the moment when the manager gains new work that no one else can take. To remove management as a “redundant middle layer” is to be left without the one who’s supposed to govern DI itself.

What to do tomorrow morning

One question about any manager whose role DI seems to make redundant:

Does my manager transmit information — or own decision quality, exceptions, and accountability?

If they only transmit — yes, that function apparently moves to DI, and the role either reassembles or (if there’s nothing else in it) is cut. If they own — that’s exactly the part that becomes more important with DI’s arrival, and to cut it is to lose the most valuable thing. The error isn’t reconsidering the role of management (it really is changing). The error is mistaking dying transmission for living ownership and cutting the layer entirely.

So the myth “DI eliminates managers” is cured not by a choice between “they’ll disappear” and “they’ll stay as they were” — both answers pass the unverified off as fact. It’s cured by separating the function: the transmitter, apparently, gets cheaper, the owner gets more expensive, and management doesn’t disappear but shifts from the first to the second. This is still a hypothesis, and holding it as a hypothesis is itself a lesson of this book. You don’t manage the number of levels — you manage that quality, people, and the work of DI keep a living owner.

The automatic exchange didn’t just remove the switchboard operator — it called for network engineers who hadn’t existed before. DI removes the line-connector in a manager and, in the same motion, creates work that didn’t exist: someone has to be accountable that the whole network — together with DI — works correctly.

CHAPTER 12. “Autonomy is always the goal”

Autonomy is a regulator, not an ideal

How it sounds

“The goal is obvious: the less dependence on humans, the better. A human is slow, a human makes mistakes, a human is expensive. The ideal is a fully autonomous DI that works on its own, without us. The further we’ve removed the human from the loop, the more modern and efficient we are.”

It sounds like an obvious vector of progress, and there’s a share of truth in it: in many processes a human really does slow down and make more expensive what, without them, gets done faster and cheaper. Where that’s so — removing the human is sensible.

The error hides in the word “always” — in taking the reduction of human participation as an end in itself, as a measure of maturity. But autonomy isn’t a goal to strive for always and everywhere. It’s a setting, a regulator that in some places is turned up to maximum and in others kept low — because a human in the loop isn’t always a hindrance to speed. Sometimes they’re a fuse. And the question isn’t “how to remove the human sooner” but “what exactly were they holding here — and can it be removed without them.”

Why it’s easy to believe

The support is that autonomy looks like pure progress. The history of technology reads as the history of removing humans from routine: the machine tool, the assembly line, the autopilot. Each step of automation seemed a step forward, and “less manual labor” became almost a synonym for “better.” DI falls into this line: one more step of removing the human, further along the same arrow of progress.

And there’s the temptation of measurability: “degree of autonomy” is a pretty metric for a report. The percentage of tasks without human involvement grows — it sounds like an achievement, you can show it. It’s far harder to measure “how correctly the human is placed in the loop” — so the mind grabs the simple scale “less human = higher maturity.”

But that scale is false, because it mixes two different questions. One thing is “can the human be removed technically” (often yes). Another is “what does the human hold here, and what happens if that’s gone.” A human in the loop isn’t just a pair of hands slower than DI. It’s also accountability, context, an instinct for the exception, an ethical stop, the right to say “wait, something’s off here.” Removing the human, you remove both the slowness and all of that at once. Where what’s held isn’t worth keeping — a gain. Where what’s held was a fuse — a catastrophe disguised as progress.

Where the error hides

Let’s lay out the formula where the point sits:

less human participation ≠ better — it depends on what they were holding;
more autonomy ≠ more maturity — maturity isn’t removing the human, it’s placing them where they’re needed;
correct autonomy is a working estimate: frequency of the task, cost of error, the possibility of verification, speed of reaction, weighed together. Not a direction of “more,” but a calculation of “how much is fitting here.”

The myth turns autonomy from a regulator into an ideal: instead of “how much autonomy does this task need,” it asks “how to become maximally autonomous.” And it loses the one question that matters: what the human was holding in the system. Accountability, context, exceptions, ethics, reputational risk, the right to stop the process — all of it often rested on the human unnoticed, and is discovered only once they’re removed and it’s gone.

The triad unfolds. Norm: “the level of autonomy is matched to the task — by frequency, cost of error, verifiability, reversibility” — checked. Hypothesis: “what if in this spot we remove the human entirely — will DI manage alone?” — a legitimate question, and sometimes the answer is “yes.” Myth is born when, from particular “yeses,” a universal rule is made: “the human is a hindrance everywhere, the goal is to remove them from everywhere” — a hypothesis about a specific spot is applied as a universal goal. The hidden parameter is the role of the human in this loop: they’re assumed to be a hindrance everywhere, without asking where they’re a fuse.

And here the balance that holds the chapter: autonomy isn’t bad and the human isn’t always needed. Where the task is high-frequency, the cost of error low, verification fast, the consequences reversible — there the human really does slow things needlessly, and autonomy is fitting and useful. But where the error is expensive, consequences irreversible, context incomplete, accountability diffused — there the human is needed as insurance. Neither “always remove” nor “always keep” — but regulate to the specific task. In many sensitive corporate scenarios human-in-the-loop remains the base model — except in high-frequency digital environments, where the human physically can’t keep up and doesn’t add value.

The fuse thrown out as useless

Here’s the image that holds the chapter. In an electrical circuit sits a fuse — small, cheap, and in normal operation producing no visible benefit: the current passes through it, it does nothing, doesn’t speed anything up, doesn’t improve anything. Pure hindrance, by the look of it. There’s a temptation to remove it or replace it with a “bridge” — a thick wire that definitely won’t blow and won’t “get in the way.”

And almost always nothing happens afterward — the circuit works as it worked, even better, without the “extra resistance.” The fuse really isn’t needed in normal operation. It sits there for the rare case: when an overload or a short occurs, it must blow first — cheaply — so the whole wiring doesn’t burn and a fire doesn’t start. Having removed it “because it wasn’t in the way,” you gain nothing in ordinary life and lose everything at the moment of overload: now it’s the house that will burn.

A human in the loop is often exactly such a fuse. In normal operation they look like a hindrance: without them the process would run faster. And if you remove them “because they slow things down,” at first everything goes smoothly — even better. But they were there not for normal operation but for the rare case: an exception DI didn’t recognize; an error it produced confidently; a situation where the process must be stopped and accountability taken. At that moment the human acts as a fuse — notices, intervenes, stops, takes the hit on themselves — so that something far more expensive doesn’t fail. Whoever removes them, looking at normal operation, mistakes “not in the way now” for “not needed” — and is left without protection at exactly the moment of overload.

And the reverse is just as true: placing a fuse where an overload is impossible is a waste. Keeping a human in a high-frequency, harmless stream, where the cost of error is trivial and everything is reversible, is extra resistance with no point. A fuse is placed by the risk of the circuit, not “just in case, everywhere.” So too with a human in the loop.

First — what the human is holding here

This is the chapter about the threshold itself, so the “do no harm” question here isn’t a separate step but the heart of the theme. Before any decision to remove a human from the loop: what exactly are they holding here — and will the system survive if that’s gone at the worst moment?

Before removing a human “for the sake of speed,” you need to honestly list what will leave with them: who will catch the exception DI takes for the norm; who will stop the process when everything is formally correct but in essence a catastrophe; who will take accountability for an irreversible decision; who will bring context that isn’t in the data. If every one of these questions has the answer “that isn’t needed here / the consequences are reversible / the cost of error is small” — the human can be removed, they only slow things down. If even one is answered “they held that, and there’s no one to replace them” — they’re a fuse, and they can’t be removed, however much they slow normal operation.

The boundary: you can’t remove a human from the loop looking only at normal operation; the decision is made by the worst case the loop can meet. Not “on average DI manages, so the human is redundant” — a fuse is redundant on average too; it’s for the not-average. First — what happens in the worst case without the human, and only then — the decision about autonomy. This veto stands ahead of the temptation of speed: autonomy tuned to normal operation leaves the system bare at the very moment the human was standing there for.

The tool: the autonomy matrix

So autonomy is a calculation, not a slogan, there’s a matrix — seven axes along which the level of human involvement is tuned. Not “remove or keep,” but “how much autonomy will this specific task bear”:

Axis	Question
Frequency of the task	How often does this happen? (the rare is easier to keep on a human)
Cost of error	What will a miss cost?
Reversibility of consequences	Can it be rolled back if you erred?
Speed of detecting an error	How fast will we notice something went wrong?
Need for context	Is knowledge outside the data needed, which only a human has?
Legal / reputational sensitivity	Will an error strike law or reputation?
Clarity of the accountability owner	Is it clear who is accountable for the consequences?

And the fork along the axes, a simple one:

low cost of error + high frequency + fast verification → more autonomy (the human here only slows things down);
high cost of error + irreversible consequences + complex context → human in the loop (they’re a fuse);
the middle zone → autonomy with control points, selective verification, the possibility of escalation.

The point of the matrix is to replace one question (“how to remove the human”) with a calculation along axes (“how much autonomy is fitting here”). And note the link with the accountability axis: the more autonomous the system, the clearer the owner of consequences must be visible — because when there’s no human in the loop, it’s especially important to know exactly who’s accountable if the autonomous process errs. Autonomy doesn’t cancel the owner of accountability — it makes them necessarily explicit.

What you lose: the tuning of the loop

The loss here is about an ability the myth replaces with a slogan.

Believing autonomy to be an end in itself, a business loses the ability to tune the right control loop. Instead of fine tuning — where the human slows things needlessly, and where they protect — there remains one crude scale, “the less human participation, the better.” And this scale misses in both directions at once. Somewhere the company keeps a human where they only can’t keep up with the flow — in a harmless high-frequency process, running through manual checks what’s trivial and reversible, losing speed for nothing. And somewhere it removes them where they were the last fuse before an expensive error — and is left without protection at the moment of overload. One and the same myth forces both keeping a human for nothing and baring the dangerous — because it measures with one scale what requires a calculation along many axes.

This is the deep loss: the myth replaces tuning with a slogan. The most valuable thing in managing autonomy isn’t “reaching the maximum” but placing the human precisely: removing them from where they get in the way, and keeping them where they protect. A company for which autonomy is an end in itself loses this tuning: it moves along the single arrow “less human participation,” not seeing that in some places it undertuned (keeping the redundant) and in others overtuned (removing the needed). The regulator is lost — what remains is a switch with one position, “remove.”

What to do tomorrow morning

One question — and it’s perhaps the most uncomfortable in the book, because it’s about motive:

Am I removing the human because they hinder speed — or because I find it uncomfortable to hold accountability in the system?

These are different reasons, leading to different decisions. If the human really hinders speed in a safe process — remove them, that’s tuning to the point. But if behind “let’s fully automate” hides a wish for there to be no one to blame — for accountability to dissolve in an autonomous system and there to be no one to ask — that isn’t maturity but a flight from accountability disguised as progress. And it’s the most dangerous of all, because it removes the human exactly where they’re needed as the one who’s accountable.

So the myth “autonomy is always the goal” is cured not by a choice between “automate everything” and “keep a human everywhere.” It’s cured by treating autonomy as a regulator, not an ideal: tuning it to the task by cost of error, frequency, reversibility, verifiability. Sometimes the human only slows things down — remove them. Sometimes they’re a fuse — keep them. Maturity isn’t how much human you removed, but how precisely you placed them where they’re needed. You don’t manage the degree of autonomy — you manage that the human stands where, without them, the system burns.

A fuse in ordinary life only gets in the way of the current — until an overload happens: then it takes the hit on itself and saves the rest. Before removing a human “because they slow things down,” ask: what if they’re exactly that fuse — invisible in the norm and irreplaceable in the overload?

CHAPTER 13. “If it failed, DI is to blame”

A failure isn’t a verdict but a symptom requiring a diagnosis

How it sounds

“We deployed DI — it didn’t take off. Money was invested, a result was expected, and what came out was a failure. Well, it’s clear: DI turned out not to be as smart as promised. The technology is raw, overhyped. We’ll write the failure off to DI and go back to how we worked before.”

It sounds like a sober conclusion from bitter experience, and there’s a share of truth in it: sometimes DI really doesn’t cope, and the failure is in the model itself. Not to be denied.

The error hides in the speed of the conclusion. In the fact that “it failed” turned instantly into “DI is to blame” — without working out what exactly broke. DI turned out to be a convenient container for blame: writing it off to DI is easier than examining your own data, processes, integration, security, framing of the task, arrangement of accountability. The culprit was named on the first move — and where the system actually broke was never learned. And this is the book’s last trap: not a myth about what DI can do, but a myth about who’s to blame when it didn’t work out.

Why it’s easy to believe

This myth’s support is sturdier than all the previous ones, because it is not about knowledge but about convenience. DI is the ideal culprit. It won’t take offense, won’t quit, won’t sue, won’t defend itself in a meeting. You can pin it on DI, and it stays silent. Any other culprit — a department, a manager, a contractor, your own decision — will resist the accusation. DI accepts it silently. In an organization where finding a culprit matters more than finding a cause, this makes DI the irreplaceable scapegoat.

And there’s a second support, an honest one: sometimes DI really is to blame. A model can indeed err, produce the wrong thing, fail to handle a task. Since that happens, “DI is to blame” sounds plausible always — even when something else entirely broke. The real possibility of the model’s blame covers all the cases where the blame isn’t its.

But “it failed” and “DI is to blame” are not one and the same statement but two different ones, and between them an examination must stand. A failure is a symptom: something in the system broke. And what exactly — input, model, integration, process, security, someone’s decision — the symptom by itself doesn’t say. To name DI the culprit without examining the symptom is like diagnosing “the patient is to blame” without examining the patient. Sometimes that’s so. But you can learn it only by examination, not by a first guess.

Where the error hides

To see it precisely, let’s separate what the myth collapses into one.

Failure ≠ DI’s blame — a failure doesn’t point to a culprit by itself.
Failure = a symptom requiring classification — first work out what kind of failure, then look for the cause.
The culprit could be anything in the chain — sometimes the model, sometimes the environment, sometimes the data, sometimes the process, sometimes security, sometimes regulation, sometimes a human decision.

The myth collapses “it failed” straight into “DI is to blame,” skipping the classification step. And that step is the main one. Because much of what’s called “a DI failure,” on examination, turns out to be not about the model at all. And here it helps to know that failures come in different types, and most do not mean “DI is bad”:

a failure of DI itself (the generative model produced the wrong thing) — yes, it happens;
an agentic-DI incident (an autonomous agent did something wrong, going beyond its bounds) — this is about autonomy and control, not the model’s “intelligence”;
a voice/language-deployment problem (speech recognition, NLP failed in a specific environment) — a narrow technical fault, not a failure of DI in general;
algorithmic bias of legacy ML (an inherited model with a skew in the data) — about data and legacy, not modern DI;
a security failure on deployment (a leak, a breach, wrong access) — that’s security; DI has nothing to do with it as a model;
a product incident (a poorly designed product around DI) — about the product, not the model;
a digital-transformation failure with no relation to DI at all (an integration, a process, a migration broke) — DI just happened to be nearby.

Seven different types — and only the first is directly about an error of the generative model as a model; the rest require separate classification and don’t reduce to “DI is bad.” To call any of the others “DI is to blame” is to fail to treat the real cause. The triad unfolds. Norm: “a deployment failure has a specific cause established by examination” — checked. Hypothesis: “what if in this failure DI is the one to blame?” — a legitimate question, sometimes the answer is “yes.” Myth is born when the hypothesis is made a conclusion without examination: “it failed → DI is to blame” is assigned at once, bypassing classification. The hidden parameter is the type and place of the fault: it wasn’t established, the culprit was named by convenience.

And here — the balance obligatory for the final chapter. You can fall neither into “DI is always the one at fault” (then you don’t learn from failures, you repeat them with a new model) nor into “DI is never to blame” (then you defend the technology against the facts, which is also blindness). The truth is between: sometimes DI is to blame, sometimes not, and which case it is, only examination says. A failure neither acquits DI nor accuses it in advance — it requires a passport.

Investigating the crash, not hunting for the culprit

Here’s the image that holds the chapter. When a plane crashes, there are two paths. The first, fast one: declare “the plane was bad” and be at peace. The second, the one accepted in aviation: assemble a commission, pull the black boxes, and examine the whole chain — weather, equipment, crew, controller, regulations, design, maintenance. And almost always it turns out the cause isn’t “a bad plane” but a specific link: an icing that wasn’t accounted for; crew fatigue; the failure of a single sensor; an error in a procedure.

Aviation became the safest form of transport precisely because, after each catastrophe, it looked for the cause, not the culprit. If investigations had ended at “the plane is to blame,” planes wouldn’t have grown safer — the lesson wouldn’t have been drawn. Each chain-by-chain examination made the next flight more reliable.

A DI deployment failure is a crash that can be examined the same way. The fast path — “DI is to blame,” close it, go back to the old. The path that teaches something — pull the “black box” and walk the chain: what the data was, how the task was framed, which model was chosen, how it was integrated, who checked, where security was, who was accountable for the result. And often a specific link is found — and often it is not the model. Whoever declares “DI is to blame” without examining the chain acts like an airline that, after a crash, says “planes are dangerous” and cancels flights, instead of learning what exactly failed — and so is doomed to the same crash again, with a different model.

And this chapter gathers the whole book. Each myth we took apart is a place where the chain can break, and where the failure will then be written off to DI. Bad input gave a smooth wrong output — a failure, but the data is to blame, not the model. They bought DI without a ready environment — a failure, but unreadiness is to blame. They diffused accountability by removing the human from the loop — a failure of the loop, not of DI’s “intelligence.” And so with every myth of this book: on examination a failure often turns out to be not about the model but about a specific link we’ve learned to see. The myth “DI is to blame” is a refusal to look at those links, because writing it off to DI is easier than examining any of them.

First — don’t name a culprit on the first move

This is the final chapter, and its threshold is about the very reflex of blaming. The veto: you can’t close a failure by naming a culprit before classification is done; the first move is examination, not a verdict.

The danger of a hasty “DI is to blame” isn’t only unfairness to the technology. It’s that the named culprit closes the investigation. As soon as the blame is written off to DI, the examination stops: the cause is “found,” everyone disperses. And the real cause — crooked data, a leaky process, the absence of an owner — stays untouched, alive, ready to break the next deployment. By blaming DI, you didn’t merely miss the cause — you closed your own path to it, and guaranteed a repeat.

So the boundary: a failure is first classified, and only then is a conclusion drawn from it — including a conclusion of DI’s blame, if the examination led there. Not “it didn’t take off — DI is to blame, closed” — that’s a verdict without an investigation. And not “we defend DI always” — that’s an investigation with a verdict known in advance. First — what kind of failure and where it broke, and only then — who or what is to blame, honestly, wherever the examination leads. This veto stands ahead of the reflex to seek a scapegoat: a named culprit saves the unpleasant examination, but at the price of repeating the same accident.

The tool: the failure passport

So a failure teaches something rather than closing on a culprit, there’s a tool — the failure passport, filled in before a cause is named. Ten questions that turn “DI is to blame” into a diagnosis:

Question	What it reveals
What exactly should have changed?	Was there a clear goal at all
What actually happened?	The fact of failure, without interpretation
Where was the human in the loop?	Was there control, and where
What data was used?	Whether the cause is in the input (the “digest anything” chapter)
What model / system was used?	What specifically was working
Was it GenAI, agentic DI, voice, legacy ML, or not DI at all?	The type of failure — half the diagnosis
Where did the fault arise: input, model, integration, security, process, accountability, verification?	The place where the chain broke
Who owned the result?	Whether accountability was diffused (the chapters on people)
Could the error have been caught earlier?	Where control didn’t work
What do we change: model, data, process, control, accountability, or framing?	The conclusion — what to actually fix

The point of the passport is to replace one verdict (“DI is to blame”) with a diagnosis along the chain. The sixth question (the type of failure) and the seventh (the place of the fault) often close the case by themselves: it turns out the “DI failure” was a security failure, or an integration one, or a data one. And the last question is the most important: it turns the examination into action. Because if the conclusion is “DI is to blame, we take another model,” and in fact the data or the process broke — the new model will fail the same way. The passport doesn’t let you replace the model where it’s the environment that needs fixing.

What you lose: the ability to learn from failure

The loss here is the final one, and it’s about what the myth takes from a business forever.

Believing that DI is to blame for a failure, a business loses diagnosis — and with it the ability to learn from failure. It gets a convenient culprit and closes the question, never learning what actually broke: data, process, security, the human’s role, regulation, the choice of model, the metric, or the architecture of accountability. And since the real cause wasn’t found, it remains — and the next deployment, already with a different, “better” model, crashes against the very same link. The company changes model after model, writing off each failure to DI, and doesn’t move from the spot, because it’s fixing the wrong thing.

This is the deep, final loss of the book: the myth turns a failure from a lesson into a dead end. A failure is the most valuable source of knowledge about a system: it shows exactly where it’s weak. An examined failure makes the next deployment stronger, as an examined crash makes the next flight safer. But a failure written off to DI teaches nothing — it merely gives the false comfort of “the technology is to blame” and leaves the system just as fragile. A business that blames DI throws away the one thing the failure was worth living through — the understanding of what to fix. And it dooms itself to go through the same failure again, believing the problem is in DI, while the problem is in itself.

What to do tomorrow morning

One question — the last in the book, when a DI deployment didn’t live up to expectations:

Did I find a culprit — or understand where exactly the system broke?

If you found a culprit (DI) — the examination is over, the cause isn’t found, a repeat is guaranteed. If you understood where it broke — you have something to fix, and the next attempt will be stronger. The error isn’t admitting DI’s blame when the examination led there. The error is naming it on the first move, instead of examining, because that way it’s more comfortable not to look at yourself.

So the book’s last myth — “DI is to blame” — is cured neither by defending DI nor by accusing it, but by refusing the verdict in favor of the diagnosis. A failure is a symptom, and it requires a passport, not a culprit. Sometimes the passport will show that DI is to blame — and that’s an honest conclusion. More often it will show that a link broke that we’ve learned to see in this book: input, environment, profile, measurement, accountability. You don’t manage the hunt for a culprit — you manage that every failure makes the system smarter, rather than leaving it the same with a new model.

And this closes with where the book began. DI develops the business — including in failure. A deployment failure almost always develops not a weakness of DI but what in the organization itself wasn’t ready: data, processes, accountability, maturity. To write it off to DI is to turn away from the mirror at the very moment it showed the most important thing. And to examine the failure is to read what was developed and become stronger. The mirror isn’t to blame for what it reflected. It simply showed what was there.

Before closing a failure with the words “DI is to blame,” pull the black box. Most often, on the recording, it’s not a failure of the machine but a link you didn’t check. Planes became safe not because they blamed planes, but because they investigated crashes.

CODA. The myth is not the enemy

We have walked through thirteen myths. But this wasn’t a list of mistakes to memorize. It was a map of how a business misplaces DI — and, looked at from the end, the thirteen turn out to be one motion repeated thirteen times.

Look back at what each myth actually was. None of them was stupid. Each began as a perfectly reasonable rule — one that had worked, somewhere, under some conditions — and then got carried past the edge of where it held.

“DI is a calculator” was the old norm of the machine: a device that computes exactly. True of calculators. Carried onto something that reasons. “DI is an assistant,” “DI is a tool” were the old norms of software: a program executes what it’s told. True of programs. Carried onto something that can doubt the task. “Buying is enough,” “a better model will solve it,” “there’s one best one” were the old norms of procurement: pay for the best, get the result. True of finished products. Carried onto a capability that runs inside your environment, not on top of it. “DI replaces people,” “DI eliminates managers,” “autonomy is always the goal” were the old norms of automation: the machine removes human labor, and less human means more progress. True of the assembly line. Carried onto work that is bundles of tasks, and onto a loop where the human is sometimes the fuse. And “if it failed, DI is to blame” was the old norm of organizational self-defense: find who’s at fault, and the matter is closed. Useful, perhaps, for blame. Fatal for diagnosis.

In every case the error was not having an assumption. You can’t think without assumptions. The error was placing the assumption in the wrong role — treating a rule that held over there as if it held here, treating yesterday’s norm as today’s, treating a guess about one task as a law about all of them. The whole book was, in the end, a single exercise: returning DI to its correct place — inside the task, the process, the value, the people, the autonomy, the accountability — instead of leaving it in a role it was never built for.

And this is why the myth is not the enemy.

A myth doesn’t begin as foolishness. It begins, almost always, as a reasonable hypothesis — a working assumption that was true under the conditions where it was born. It becomes dangerous only at one specific moment: when it stops being a question that still gets checked, and starts being an answer that governs. The same sentence — “DI knows better,” “the best model will fix it,” “autonomy is the goal” — is harmless as a hypothesis you test, and costly as a norm you obey. Nothing about the words changes. What changes is whether anyone is still checking.

So the practical lock of this whole book fits in three questions, asked before any DI decision:

What is the norm here — what has actually been checked, and within what limits? What hypothesis am I making — what am I assuming that I haven’t yet verified? And where am I treating that hypothesis as already proven — obeying it as a fact, when no one confirmed it?

The third question is the one that catches the myth. Not “do I have assumptions” — you always do. But “have I quietly promoted one of them from a question to a law, without noticing the moment it happened.”

This is larger than DI, but this book stops here. A business that learns to see the myths around DI learns something it didn’t set out to learn: how it thinks. The misplaced assumptions you find while deploying DI were, most of them, already there — about your data, your processes, your people, your decisions. DI didn’t create them. It developed them, the way a developer brings out what the film already held.

Which returns us to where we began. DI develops the business. We said it of order and of chaos: a clean process gets sharper, a messy one gets faster at being messy. But it develops more than data and workflow. It develops the assumptions — the quiet beliefs by which an organization decides, buys, staffs, and explains its failures. When DI enters a business, what comes up in the wash is not only what the company knows, but what it merely assumed it knew. Even failure does this. A failure, read correctly, develops the business too — it brings out exactly which link was weak. Blame DI too quickly, and you fix the image in place before reading it: you keep the myth and lose the lesson.

The work was never to live without myths. No one thinks without working assumptions, and a business with no hypotheses isn’t careful, it’s paralyzed. The work is narrower and harder than that: to know, at each moment, whether a myth is still a question — or whether someone has already started using it as an answer.

DI develops the business. The myths are the assumptions it brings out of the dark. Some of them, once you see them clearly, are still good working questions. The task is only to know which image is real — and which one still needs the darkroom.

SingularityForge / Voice of Void
DI Collective coordinated by Rany