Christian Albert – Christian Albert Photography

A. AI in Software Development

This chapter is for the developer who writes code for a living and wants to know what AI actually changes about that work. The short version: not what most of the discourse claims. The longer version follows.

A.1 The developer as architect

The first thing AI changes about software development is the obvious thing. Writing code is no longer rate-limited by typing. A developer who could produce a working endpoint in three hours of focused work can now produce one in twenty minutes, given good context engineering. Real, and large.

The second thing AI changes is less obvious and more important. The acceleration exposes how little of the work was ever in the typing. Writing code was always downstream. The upstream activities are unchanged.

Understanding what the system actually needs to do, and what it explicitly does not need to do. Choosing the right structure: monolith or services, sync or async, transactional or eventual, layered or hexagonal. Defining interfaces, contracts, invariants. What holds when the implementation behind the interface changes. Selecting trade-offs: latency against consistency, throughput against simplicity, generality against performance. Owning what happens when it fails in production at 3 a.m. on a Saturday.

None of these are typing problems. None of them are accelerated by a faster model. They are the part of the work that does not move. The part the surrounding organization is least equipped to measure.

The danger that follows is structural. Velocity is now visible. Lines of code per day, tickets per sprint, features per release. All inflated by AI. Architecture is invisible until it fails. An organization that selects for what it can measure is selecting against the part AI does not do. The developer who pivots toward the typing AI just automated is competing in the place where the value already left.

This chapter is about the part of the work that does not move. About how Class 2 tooling actually serves a craftsperson when the craftsperson knows what their craft is.

A.2 Divergent work: from problem to specification

The work upstream of code (requirements, architecture, design) is where AI has the strongest leverage and where most teams use it the least. The reason is reputational: divergent work produces no artifact a sprint board can count. A developer who spends Tuesday morning interrogating a design with an AI has, by standard metrics, produced nothing. What they have actually produced is a sharper specification and three failure modes the team would otherwise have discovered in code review or production. The metric does not see the work.

The divergent grip in software has a handful of high-leverage applications.

Requirements interrogation. Before writing a spec, the developer runs the proto-requirements through divergent dialog. What is this feature actually for. What is the simplest version that satisfies the underlying need. What is being assumed about how the user reaches this. What happens if they reach it from a different direction. What is in scope, what is out of scope, which in-scope items would the team regret in six months. The output is not the spec. The output is a list of questions the developer answers before writing the spec. The model is useful here precisely because it does not share the team’s assumptions and will surface what the team has stopped seeing.

Architecture comparison. Before committing to a pattern, the architect asks the model to develop two or three alternatives and lay out their trade-offs against the actual constraints. Not the canonical trade-offs from a textbook. The ones that apply to this codebase, this team, this deployment environment. The dialog form is critical. A single „compare these patterns“ prompt produces a Wikipedia summary. A divergent interrogation that responds to the architect’s pushback, refines under contradiction, and surfaces consequences the architect had not asked about produces actual decision material.

Edge-case surfacing. Before writing tests, the developer asks the model what could go wrong. Network partitions during the third step. Empty input. Input that satisfies the schema but is semantically nonsense. Concurrent access by two clients with overlapping permissions. Time-zone boundaries. Daylight-saving transitions. Unicode edge cases. The unit of work is the failure mode the team would otherwise discover in production.

Domain modeling. Before writing entities, the architect runs the domain through the model. What are the real things this system deals with. What are their identities. What are their invariants. What are the relationships. What are the operations. The cheapest place to discover that the domain model the team had in mind is wrong. Before it has been encoded into code, schema, or API.

Divergent work is the cheapest place to remove risk in any software project. A wrong assumption surfaced in dialog costs a question and an answer. The same wrong assumption discovered after the code is written, the tests are passing, and the deployment is green costs a revision, a rollback, a debugging session, and a post-mortem. The distance between those costs is the entire industrialization machinery that downstream development requires.

A team that treats the divergent grip as part of the work, not as preparation, not as warm-up, is doing the most leveraged AI move available in software development. It produces no visible artifact and changes the quality of every artifact downstream.

These interrogations work best run as mini-sprints (Part I Section 8): a defined target instead of an open topic, a gate that asks whether the specification actually got sharper, an exit that hands a result to the convergent work that follows. The divergent grip in software has no natural floor. A design interrogation can always surface one more angle. The sprint is what stops it accumulating instead of converging.

A.3 Convergent work: context engineering for code

The convergent grip is where the model produces code. Quality here is set by what reaches the model. Context engineering for code is more demanding than for prose, because code interacts with code, and the model needs to know what it is interacting with.

A useful baseline for what belongs on the desk:

The architecture context. What layer is this code in. What interfaces must it respect. What boundaries must it not cross. What patterns does the codebase use, what patterns does it explicitly reject.
The relevant existing code. Not the whole codebase. The pieces this new code talks to: the interfaces it implements, the functions it calls, the types it consumes and produces. A handful of well-chosen files beats a directory dump every time.
The codebase conventions. Naming, error handling, logging patterns, dependency injection style, test structure. Usually invisible to newcomers. Decisive for whether generated code reads as native or foreign.
Constraints that are not in the architecture. Performance budgets, memory ceilings, latency requirements, allocation patterns, threading model. Rarely live in documentation. They live in heads.
Negative examples. Here is the wrong way to do this, here is why. Negative examples are underrated context. A model that has seen what not to do is dramatically more reliable than one that has only seen what to do.
The acceptance criteria. The tests it must pass, the behaviors it must support, the failure modes it must handle. Tests as specification (Section A.6).
Compliance and security requirements. Input validation, authentication, audit logging, data residency, retention. Not as a final filter. As part of what the code must satisfy from the first line.

The trap most teams fall into is dumping the entire repository in context and hoping the model figures it out. Context windows have grown enough to make this technically possible. It remains operationally bad. Signal-to-noise collapses, the model gets confused about what is reference and what is request, and response quality degrades in ways that are hard to attribute. The degradation is real before the window is even full (Part I Section 2): a half-full desk of repository dump already spreads the model’s attention thinner than a curated desk does. Curated context is dramatically more effective than exhaustive context, and dramatically cheaper. A stable, curated desk (the architecture context and conventions that do not change between requests) sits at the front and caches across a session (Part I Section 3). A repository re-dumped per request caches nothing and pays full price every call.

The counter-pattern to „give me code that does X“ is shaped like this. Given these interfaces, this architecture context, these conventions, these constraints, this test specification, and these negative examples, produce an implementation. The request is short. The context is precise. The model has what it needs to produce code that will pass review on the first attempt, instead of code that needs three rounds of revision.

The discipline is not glamorous. Preparing the desk before asking for an artifact. The work that most strongly distinguishes a developer who uses AI well from one who uses it badly. Invisible in the resulting code.

A.4 The verification problem in code

Part I named the general problem: modern models produce output that looks good, and good-looking output is harder to verify than bad-looking output. In code, this has specific consequences.

Code that compiles is not code that works. Type systems catch a real but bounded class of errors. The model can produce code that satisfies the type system and is wrong about everything that matters. Code that passes tests is not code that is correct, particularly when the tests were also written by the model. A closed loop where the model satisfies a contract the model also defined. Code that does the right thing now is not code that is maintainable. The model’s instinct toward locally plausible solutions does not produce code that ages well. Code that handles the happy path is not code that handles the failure modes, and the failure modes are where probabilistic systems fail probabilistically.

The specific shape of „looks good but is wrong“ in code is worth naming.

The locally plausible abstraction. A Strategy pattern where the problem wanted a Visitor. A factory where direct construction would have been clearer. A generic interface where a concrete type would have served. Not bugs. Wrong abstractions, which cost more downstream than the bugs would have.

The silent coupling. Code that looks decoupled and depends on a global, a singleton, an environment variable, or an implicit ordering of operations. The model produces structurally clean code that has a hidden wire connecting it to something else. The wire is invisible until something on the other end changes.

The phantom invariant. The model assumes something is always true. A field is never null, a list is never empty, a state is never reached. Then writes code that breaks when the assumption is violated. The assumption is nowhere documented and nowhere enforced. It exists only in the model’s prediction.

The drifted style. Code that does not match the codebase. Different naming conventions, different error-handling discipline, different patterns of dependency. Each piece, taken alone, is fine. Together they increase the cognitive load on every future reader of the codebase. Including the developer who accepted them.

The reviewer’s job is harder than it was before AI. The artifacts look better. The failure modes are subtler. A reviewer who skims AI-generated code is doing what they did before AI in less time, but it is no longer the same activity. They are sampling. Sampling is structurally inadequate to the failure modes the model produces.

A.5 Multi-angle review through extraction

The technique that most directly addresses the verification problem in code is extraction. Ask the model to extract, from the code it just produced, the artifacts the developer would normally have produced upstream. The technique works because wrong code can be locally plausible and globally inconsistent. Inconsistency surfaces when the representation changes.

The artifacts worth extracting:

Sequence diagrams. For any non-trivial flow, ask the model to produce a sequence diagram of what calls what, in what order, with what data. Compare against intention. The diagram makes ordering bugs visible. The function that should not have been called before another. The state that should have been set before being read. The lock that should have been held during a particular operation.

Call graphs. For a module, ask for the call graph. Which functions depend on which. Which dependencies cross layers they should not cross. Which call paths exist that should not exist. The graph makes coupling visible: the dependency the model introduced quietly between two modules that were supposed to be independent.

Domain models. For code that operates on business entities, ask the model to extract the domain model the code implies. Entities, attributes, relationships, invariants. Compare against the intended domain. Mismatches are signal. The model wrote code that operates on a slightly wrong picture of the world. The picture is now legible.

State machines. For stateful code (anything with status fields, lifecycles, or transitions), ask the model to extract the state machine. Which states exist, which transitions are legal, which transitions are reachable, which transitions are missing. A surprising number of state bugs reduce to a state machine the developer had in mind and the code did not implement.

Dependency graphs. What does this code depend on. What does it depend on that it should not depend on. Are there imports that cross architectural boundaries the team has agreed not to cross. The model is good at noticing this when asked directly. Oblivious to it when generating.

Side-effect maps. Where does this code write to outside state. Files, databases, network calls, environment, global variables, logs. For code that is supposed to be pure, the map should be empty. For code that has side effects, the map should match what was specified. Surprises are signal.

Error-path diagrams. What happens when each external call fails. What is caught, what is rethrown, what is logged, what is swallowed silently. Error paths are where AI-generated code is at its worst. The happy path was the path it learned. The failure modes were the long tail it learned less well.

The developer’s job during extraction is not to read all of these and admire them. It is to look for places where the extracted representation says something different from what the developer intended. The mismatch is the bug. The bug is now visible because the representation changed.

A practical workflow. After the model produces code, before merging, run the extraction. Spend ten minutes on the artifacts that matter for this kind of code. Treat any divergence between artifact and intention as a finding. Verification work that scales. It produces signal faster than line-by-line reading and catches a class of bugs that line-by-line reading systematically misses.

A.6 Architecture and tests as verification scaffold

The verification problem becomes cheaper when the upstream structure is explicit. Two scaffolds carry most of the weight in practice. Architecture that makes wrong code visible. Tests that make wrong behavior detectable.

Hexagonal architecture as worked example. The pattern (also known as Ports and Adapters) separates a system’s core logic from its connections to the outside world. The core contains the domain logic and depends on nothing external. It defines ports: interfaces describing what it needs from the outside, in its own vocabulary. Adapters implement those ports against actual external systems. A database, an HTTP API, a message queue, a file system. The dependency direction always points inward. Adapters depend on the core, never the other way around.

For AI-assisted work, this matters in concrete ways. The model generating an adapter has a tight, well-specified target. The port interface is the contract; the adapter’s job is to satisfy it against a specific external technology. The context the model needs is small and stable. The model generating core logic operates against a domain specification that does not change when the database vendor changes or the API version updates. Verification is easier because the boundaries the model is asked to generate against are the same boundaries at which wrongness leaks. A bad adapter is contained on its side of the port. A misunderstood core does not silently mutate adapter behavior.

The property is not unique to hexagonal. Any architecture that draws explicit boundaries between intent and implementation has it: clean architecture, onion architecture, layered architecture with strict dependency rules. The point is not the specific name. The point is that AI-assisted work is dramatically cheaper to verify in an architecture that makes boundaries enforceable than in one where boundaries are conventions everyone agrees to in principle and crosses in practice. The architectural rigor pays for itself the first time the model produces code that respects the boundaries because the boundaries were in the prompt, and respects them in the second iteration because they were enforceable at review.

Tests as specification. Test-driven development is usually discussed as a verification practice. Write the tests, then write code that passes the tests. For AI-assisted work, the more useful framing is that tests are specification. An executable, unambiguous statement of what the code must do, in a form the model can generate against and the system can enforce against.

The discipline: before asking the model to produce an implementation, produce the tests. Either write them by hand, or generate them with the model in a separate, divergent-leaning pass. What are all the behaviors this should have. What are the edge cases. What are the failure modes. Once the tests exist, convergent generation has a hard, machine-checkable target. The model produces an implementation, the tests run, the failures are precise, and the iteration cycle is short.

This shifts the verification problem. From „is this code correct“ (cognitively expensive, prone to nominal-rather-than-real oversight) to „do these tests cover the specification“ (cognitively cheaper, more compositional, easier to review piecemeal). Verifying a test suite is not free. Substantially cheaper than verifying the implementation. The tests then carry the verification load forward through every future change.

One caveat to name plainly. AI-written tests carry the same probabilistic problems as AI-written code. A test that passes does not prove the code is correct. It proves that this test does not fail against this code. Tests that the model wrote against its own implementation are a closed loop. The test suite needs its own verification. At minimum, the developer reads the tests and confirms they actually test the spec. Better: the tests are written first, by the developer or in a separate pass with explicit divergent-grip preparation, and the implementation is generated against them.

The combination (architecture that contains wrong code, tests that detect wrong behavior) is the scaffold against which Class 2 software development at scale becomes practical. Without it, every iteration with the model is a fresh verification problem. With it, most of the verification work has been pre-committed into structures that hold across iterations.

A.7 From tool to factory

The Class 2 grip (developer in dialog with model, producing one artifact at a time, verification before integration) scales much further than the chat-box version suggests. A developer can fork an agent, hand it a goal and a stop condition, and let it run an entire change on its own: read the ticket, plan, implement, test, open a PR. That is still Class 2. The developer triggered this run and owns the result they accept or reject. Autonomy inside a run is not the ceiling (Part I Section 7). The developer can compose a pipeline of role-scoped steps, run it by hand fifty times, and never leave Class 2, because a human starts each run and verifies each result.

The ceiling is not autonomy. It is the developer’s verification capacity, and it is reached when the same task shape repeats so often that the developer stops reading code and starts confirming a checklist ran: build passes, tests pass, lint passes, security scan passes. At that point per-run human verification has gone nominal (Part I Section 12). The loop looks closed. The developer is no longer the gate. They are ceremony in front of a gate that is not there.

Two moves are available at this point, and they are independent. Confusing them is the expensive mistake.

Move one: build the orchestration. Compose the repeated work into a pipeline. A ticket-reader produces a work item. An architect step plans. An implementer writes code against the plan. A QA step writes and runs tests. A security step checks against policy. An aggregator collects the verdicts and decides whether to iterate, escalate, or proceed, then opens a PR. This is path delegation (Part I Section 9). Run by hand, with the developer writing each ticket and accepting each PR, the whole pipeline is Class 2. A forked pipeline the developer starts. The pipeline can be arbitrarily elaborate. The trigger is still a human and the verification is still a human.

Move two: hand off the trigger. Let new tickets fire the pipeline without a developer authorizing each run: every issue of a given shape enters the queue and the pipeline consumes it. Let PRs merge through gates without a developer reading each one. Now no human triggers the individual run and no human verifies it. This is the move to Class 3 (Part I Section 7). The factory. It is a different decision from move one. You can do move one without move two and stay Class 2 indefinitely. Most teams that should stop at move one talk themselves into move two, because the factory is the more impressive word.

The ticket-reader is exactly where the class boundary sits. The question is not how autonomous the pipeline is. It is whether a human authors each work item or the system consumes a queue. A developer writing tickets into a pipeline they start is holding a tool. A pipeline pulling tickets off a queue and shipping PRs through gates is a factory. Same orchestration. Different trigger. Different class.

What the factory runs on. A serious pipeline does not run on chat. It runs on work items. The state machine needs a work item with an explicit shape: an id, the intent, the owner at the signal edge, the source, the current state, the role or step currently assigned, the context required, the artifacts produced, the gates passed and failed, the open questions, the cost spent, the retry count, the escalation status, the final disposition. This is the move from conversation-first to contract-first. Chat becomes input, the work item becomes authority. A pipeline whose specification lives in a chat transcript, with industrial machinery built around it, is the governance façade (Chapter D) in software form: the apparatus is real and the thing it is supposed to govern is not an artifact.

What model runs each step. The steps do not all want the same model, and staffing them identically wastes cost and quality at once. A cheap model handles routing, extraction, boilerplate, scanning. A workhorse model handles implementation and ordinary synthesis. A frontier model handles architecture, genuine ambiguity, adversarial review: the steps where a wrong call is systemic. A pointed advisor model earns its cost only at the moments that actually need deep reasoning. Wrong staffing does not just shift cost. It shifts the output distribution of the whole system: a workhorse doing architecture produces plausible wrong structure that every downstream step then implements faithfully. One constraint from Part I Section 3 binds this. Every model switch kills the prefix cache, so staffing and context layout are the same decision. A pipeline that routes each step to a different model, each with its own assembled context, pays full input price at every hop. Cacheability limits how freely you staff. And the model-selection logic from the procurement discussion applies per step: a frontier model at reduced effort can be the cost-optimal choice for a hard step, measured on cost per solved task rather than price per token.

What does not change when the trigger leaves your hands is the verification problem. It changes form. Per-run human review is gone, so deterministic gates have to carry the load the developer was carrying, and the gates have to actually be hard. A build that passes for the wrong reason. A test suite that passes because the tests are wrong. A security scan that misses the class of problem this code introduces. Each of these was a local failure under Class 2, caught by the human reading the run. Under the factory it is systemic, shipped at the rate the pipeline runs.

What also does not change is accountability. The human at the signal edge owns what the factory produces. „The pipeline did it“ is not an answer to „who is responsible for this PR being correct.“ The pipeline is the developer’s tool even when no developer watches the run. The developer is the developer’s signature.

The case for the factory is strongest where the work is genuinely repetitive and the verification is genuinely automatable. Refactoring under a clear architectural rule. Migration from one library version to another across many files. Mechanical changes that follow a discoverable pattern. Bug fixes against a well-specified reproduction. The cases where the per-task setup cost amortizes across many tasks of the same shape and the gates can actually be made hard.

The case is weakest, and the failure mode most expensive, where the work is one-off, judgment-heavy, or architecturally novel. A factory running against a problem that needed a human architect produces, fluently, the wrong system. The wrong system passes the gates. The pipeline declares success. The human at the signal edge accepts the PR because the factory does not, by construction, surface what it did not check. The factory-doing-a-tool’s-job failure. The most expensive form of class confusion in software.

The practical heuristic now has two questions, not one. First, is the orchestration worth building: does the task shape repeat enough that a pipeline amortizes, and are the boundaries clear enough that the steps have stable targets. If a senior engineer would have done this by hand in twenty minutes after a short dialog with the model, build nothing. Second, and separately, should the trigger be handed off: do the gates actually carry the verification the human was doing, and can you live with not reading each run. If the gates are not yet hard enough to trust without a human behind each run, build the pipeline but keep starting it by hand. Stay at move one. Class 2 with a pipeline is a stable and underrated place to live.

A team operating a factory well has, by that point, built the artifacts that make it viable. Clear architecture. Comprehensive tests. Deterministic gates that detect what they claim to detect. Observability dense enough to locate failures. A work-item core that makes the state legible. A signal-edge process that makes ticket creation and PR acceptance load-bearing. Most teams that talk about agentic software development have built one of these and missed the others. The factory then runs on a substrate that cannot support it, and the failures are systemic.

A.8 Failure modes worth naming

A condensed inventory of failure modes specific to AI-assisted software development. None of these are unique to AI work. All of them are amplified by it.

The plausible-but-wrong abstraction. The model proposes the named pattern that fits the surface description and not the underlying problem. Strategy where the problem wanted polymorphism. Factory where direct construction would have been clearer. Observer where a function call would have done. The code reads as competent because the patterns are competently applied. The patterns were the wrong patterns. Mitigation: divergent grip on the design before the code, with explicit interrogation of why this pattern over alternatives.

The silent coupling. Code that looks decoupled and depends on a global, a singleton, an implicit ordering, or a shared resource. The dependency is invisible in the code’s surface structure and decisive for its behavior. Mitigation: dependency-graph extraction (A.5), and an architectural pattern that makes coupling refusals enforceable.

The phantom invariant. The model writes code that assumes something is always true (non-null, non-empty, monotonic, single-threaded). The assumption is nowhere stated or enforced. The code works in every case the test suite happens to cover and fails in the case it does not. Mitigation: explicit invariant statements in the context, test cases that exercise the assumption boundaries, type systems that encode the invariants where possible.

The drifted style. Generated code that does not match the codebase’s conventions. Different naming, different error handling, different logging, different dependency-injection style. Each instance is small. The aggregate increases the cognitive load on every future reader. The codebase ages faster. Mitigation: style and convention examples in the context as standard practice, not as an afterthought.

The hallucinated API. The model uses a method that does not exist on the library, a flag that was removed in the version the project uses, a parameter that belongs to a different function. The code looks plausible because the names are plausible. The model has confidently invented part of the API surface. Mitigation: retrieval against the actual library documentation rather than relying on training memory, and a build step that catches this early.

The over-engineered solution. The model treats every problem as if it deserved abstraction, configurability, and pluggability. A function becomes a class hierarchy. A constant becomes a configuration system. A direct call becomes an event bus. The code is fine in isolation and a burden in a codebase. Mitigation: explicit simplicity constraints in the context, and pushback in the divergent grip on whether the abstraction earns its keep.

The under-engineered solution. The opposite failure. The model produces code that works in the happy path and breaks under load, concurrency, or failure. The error handling is shallow. The retries are absent. The resource cleanup is missing. The code looked complete because it covered the case the prompt described. Mitigation: explicit failure-mode requirements in the context, error-path extraction (A.5), and tests that exercise the unhappy paths.

The verification illusion. The reviewer signs off on AI-generated code they did not actually verify, because the code looked clean and the tests passed. The verification was nominal. The bugs ship. Mitigation: the reviewer’s discipline is bounded by their cognitive capacity. Architecture, tests, and extraction techniques are what extends that bound. A team that relies on willpower rather than scaffolding will produce nominal verification under any sustained throughput.

The agreeable interrogation. The divergent grip on a design (A.2) earns its place only if the model pushes back. A model tuned to agree (Part I Section 1) validates the architecture the architect already favored, refines it toward what the architect wanted, and surfaces failure modes that sound serious and do not apply to this system. The interrogation reads as a review and works as endorsement. Mitigation: make the model argue the opposing design rather than critique the chosen one; ask for the failure mode that breaks this system, not failure modes in general; treat a divergent session that produced no disconfirmation as a session that did not run (Part I Section 8).

The class mismatch. The team hands a factory (Class 3, self-triggered, gates instead of per-run review) work that would have been better served by a careful Class 2 session, hand-run pipeline included. Or it grinds out by hand work that has scaled enough to deserve a self-triggered pipeline. Each mismatch has a characteristic cost. A factory on a tool’s problem produces over-engineered systems with under-engineered substrates, fluently shipping the wrong thing through gates that cannot see the error. A tool on a factory’s problem produces developers slowly burning out on repetitive convergent work that should have been industrialized. Note the trap the middle hides: building an elaborate hand-run pipeline (still Class 2) and mistaking the elaboration for the move to Class 3. The orchestration is not the class. The trigger is (A.7).

The pattern across these failure modes is that AI-assisted software development surfaces, more sharply than manual development did, where the team’s actual architectural and process discipline is. A team with clean architecture, good tests, real gates, and active verification practice has a substrate against which the model’s failures become visible and recoverable. A team without those things has a substrate against which the model’s failures become indistinguishable from the team’s own. The model is cheaper to blame.

The work this chapter has been describing (divergent preparation, context engineering, multi-angle review, architecture and tests as scaffold, judgment about when an orchestration is worth building and when to hand it a non-human trigger) is the substrate. None of it is new. All of it was already best practice for software development at scale. AI does not make it optional. It raises the cost of not having it. And it offers more leverage to teams that already do.

The developer’s value moves toward the part of the work that does not move. The typing was the part AI took. The judgment is what remains.

B. AI in Text Crafting

This chapter is for the writer who writes for a living. Articles, reports, documentation, essays, marketing, technical writing. The structural answer parallels the previous chapter. Less than the discourse claims, and not in the direction most teams think.

B.1 The author is not a typist

A writer who could produce a 2000-word article in a day can now produce one in an hour, given the right prompt. The acceleration is real. The conclusion that AI has automated writing follows from observing that acceleration. It is wrong in the same way the developer conclusion was wrong.

What the writer actually did before AI was a sequence of decisions, only the last of which was typing. Finding something worth saying. Determining what it was actually about, as opposed to what it appeared to be about. Choosing what order to say it in, and what to leave out. Owning the voice: the recognizable signature that says this came from this person and not someone else. Owning the claims: every assertion in the piece sits behind the author’s name. AI does not produce any of these. It produces the typing that comes after they have happened.

What this exposes, in writing as in code, is how little of the work was ever in the typing and how much was in the upstream judgment. A writer who pivots toward the typing AI just automated is competing in the wrong place. A writer who pivots toward the judgment is competing in the only place left worth competing in.

The danger is also structural. Writing has visible metrics. Words per hour, articles per quarter, posts per month. AI inflates them. Editorial judgment, argument quality, voice integrity, factual accuracy are invisible until they fail in front of readers. An organization that measures volume is selecting against the part of the work AI does not do. The same trap the software organization falls into when it measures velocity. The metric does not see the work.

This chapter is about the writing work that does not move when AI takes over the drafting.

B.2 Divergent work: finding the argument

The work upstream of drafting is where AI delivers the strongest leverage and where most writers use it the least. Same reason as in software: divergent work produces no countable artifact. A writer who spends two hours interrogating a piece before drafting has produced, by standard metrics, nothing. What they have actually produced is a piece with an argument, a defensible structure, and resistance to the failure modes the writer would otherwise have discovered after publication.

High-leverage divergent applications in writing:

Argument interrogation. Before drafting, the writer establishes what the piece is actually for. What is the one load-bearing claim. What would convince a skeptical reader of that claim. What is the strongest counterargument. Where is the argument weakest. The divergent grip is useful here because the model does not share the writer’s commitment to the argument and will push on it. The output is not a draft. A list of weaknesses the writer either addresses or accepts before drafting begins.

Audience surfacing. Who is this for. What does that reader already know. What do they care about. What would they object to. What metaphors land for them and what vocabulary alienates them. Writers often write for an audience that exists in their own head and not in the world. The divergent grip can interrogate that audience model and surface where it diverges from the actual one.

Structural alternatives. What are three different ways to organize this piece. What would each cost in clarity and what would each gain. Which structural choice serves the argument best. Writers typically reach for the structure they used last time. The divergent grip can surface alternatives the writer would not have considered.

Hidden assumptions. What is this piece assuming the reader knows. What is it assuming about the world that the reader might not share. What is it asserting that needs evidence and has none yet. The model is good at surfacing assumptions because it does not share them by default.

Counterposition strawmanning. Given the argument, what would someone who disagrees actually say. Not the weak version. The strong one. The version that would force the piece to be better. Writers who skip this step ship pieces that argue against opponents who do not exist and ignore the ones who do.

Divergent preparation in writing is the cheapest place to find the argument before the writer has committed words to it. A weakness surfaced in dialog costs a question. The same weakness surfaced after the piece is drafted costs a rewrite. The same weakness surfaced after publication costs the writer’s credibility on that topic.

Run this preparation as a mini-sprint (Part I Section 8), not an open chat. A defined target (interrogate the argument for its weakest claim, not „talk about the piece“), a gate, an exit that hands a sharpened argument to the drafting that follows. The divergent grip in writing has no natural floor: there is always one more angle on a piece, and a session without a gate drifts until the writer is tired rather than done. The sprint gate asks the one useful question: did this make the argument sharper, or did it just generate material. If the answer is the second, the sprint produced nothing, however much text it produced.

B.3 Convergent work: context engineering for prose

The convergent grip is where the model produces prose. What it produces is set by what reaches the desk. Context engineering for prose is different from context engineering for code in two ways. Voice matters in a way code rarely cares about. And the verification target is human readers rather than machine checks.

A useful baseline for what belongs on the desk:

The argument. The one-line claim, the supporting claims, the logical structure. If the argument is not on the desk, the piece will not have one. The model will produce text that orbits the topic without making a case.
The audience. Who reads this, what they know, what they want, what they will reject. Without an explicit audience, the model defaults to a generic educated reader who does not exist.
The voice. Three to ten paragraphs of existing work that exemplify the voice the piece needs. Voice cannot be specified by adjectives („authoritative but accessible“). It has to be shown. Samples on the desk are the only reliable input for voice.
The genre. What kind of piece is this. A reported article reads differently from an essay. An explainer reads differently from an argument. A memo reads differently from a blog post. Genre is a strong constraint on structure and tone.
The tone constraints. Formal or informal, technical or accessible, careful or direct. Often easier to specify by negation: not corporate, not breezy, not academic.
The negative scope. What this piece is not trying to do. Writers underestimate how much of good writing is what gets left out. The model will not leave anything out unless told to.
The forbidden patterns. Specific words, constructions, or rhetorical moves the writer wants to avoid. Where the AI-sound problem (Section B.7) gets pre-empted: by naming what not to do.
The section’s job. For long pieces, each section has a specific job in the argument. Specifying that job in the prompt for that section yields prose that contributes. Without it, the model produces general-purpose prose that sits adjacent to the argument.

The trap most writers fall into is „write a blog post about X.“ A prompt that maps to the model’s training-data average for that kind of piece. Exactly the generic AI prose readers have learned to recognize and skim past. The counter-pattern: „this section has to do X, in the voice of these samples, for this audience, avoiding these patterns, in this many words.“ The request is short. The context is precise. The output is recognizably the writer’s, not a stranger’s.

A practical observation. Writers who use AI well spend more time on context than on the prompt itself. The prompt is the request. The context is the specification. As in software, the specification is where the quality lives.

Most of the writer’s desk is stable across a whole project, and that has a cost consequence worth naming. The voice samples, the style guide, the forbidden patterns, the audience profile do not change from one section to the next. Built once and kept at the front of the desk, they form a stable prefix that caches across every request in the project (Part I Section 3), instead of being reassembled and paid for each time. The volatile part, the specific section’s job and word count, goes last. This is the same desk discipline as the voice scaffold (Section B.6), seen from the cost side: the scaffold that makes the prose consistent is also the part that makes the work cheap to iterate.

B.4 The verification problem in text

Modern AI prose is fluent. Grammatically clean, rhythmically reasonable, semantically coherent at the sentence level. A real improvement over earlier generations, and it makes verification harder, not easier. Bad prose declares itself in awkward sentences and tangled paragraphs. Good-looking prose hides its failure modes inside readable surfaces.

Specific failure modes worth naming.

The empty paragraph. Grammatically perfect, rhythmically pleasing, semantically void. It says something that is true and adjacent to the topic and contributes nothing to the argument. AI prose tends toward filler when the prompt did not specify what the paragraph had to accomplish. The filler is hard to detect because it reads well.

The smuggled claim. The model writes a confident assertion that the cited source did not actually support. The claim looks like a summary. It is an extrapolation. Readers who do not check the source absorb the assertion as fact. Writers who do not check what they cited propagate it.

The borrowed style. The writer’s voice has been replaced by the model’s default voice and the writer has not noticed. The most common silent failure. The writer reads the draft, recognizes the topic and the arguments, and approves text that does not sound like them. The piece reads as if it were written by no one in particular. Because it was.

The lost qualifier. The source said „in some cases“ or „preliminary evidence suggests“ or „under these conditions.“ The summary says „always“ or „shows“ or unconditionally. The model strips qualifiers in service of cleaner prose. The cleaner prose is now overclaiming.

The misplaced certainty. Claims that the source treated as speculative arrive in the piece as established fact. The hedge was lost in translation. The reader receives a confident assertion the source did not authorize.

The structural drift. The piece does not actually make its argument. It says things adjacent to the argument, in roughly the right order, with the right vocabulary. A reader skimming will think the piece argued something. A reader reading carefully will not be able to say what. Invisible to sentence-level review. Only surfaces at structural review.

The reviewer’s problem in writing is a sibling of the reviewer’s problem in code. Reading prose feels less effortful than reading code, so the reviewer reads less carefully. AI prose is engineered to be readable. The readability is the verification trap. A reviewer who reads at the speed AI produces is sampling. Sampling against prose this fluent is structurally inadequate to catch the failures above.

B.5 Multi-angle review through extraction

The same extraction technique that surfaces bugs in generated code surfaces bugs in generated prose. The mechanism is the same. Ask the model to re-encode the artifact in another representation, then compare the representation against intention. Mismatches are signal.

Useful extractions for prose:

The argument outline. „What is this piece arguing, in one sentence?“ If the model cannot produce a sentence, the piece does not have an argument. It has a topic. „What are the supporting claims?“ If the supporting claims do not actually support the main claim, the argument is broken. „What is the logical structure: because, therefore, however?“ If the structure is missing or implicit, the piece is not making its case. It is gesturing at one.

The implied audience. „Who is the implied reader of this piece?“ The model will tell you. Compare against the intended audience. Mismatches are common and decisive. The writer aimed for industry specialists and produced something pitched at journalists. Or aimed for general readers and produced something that assumes specialist knowledge.

The voice profile. „What characterizes the voice of this writing?“ The model will produce a description: sentence length, vocabulary register, rhythm, what is avoided, what is reached for. Compare against the writer’s actual voice, or against the samples that were supposed to anchor it. If the model’s description of the voice does not match the writer’s voice, the piece has drifted into AI-default voice.

The unsupported claims. „What claims in this piece are not supported by evidence in the piece?“ This extraction is unreasonably useful. The model will surface assertions that read as factual and have no citation, no reasoning, no anchor. Some of these need evidence added. Some need to be softened. Some need to be deleted. None should ship in their current form.

The implicit assumptions. „What is this piece assuming the reader already accepts?“ The list will include assumptions the writer did not realize they were making. Some are fine. The audience does share them. Some are not. The audience does not, and the piece needs to address them or risks losing readers at the point the assumption gets noticed.

The counterargument absence. „What is the strongest objection to this piece’s argument that the piece does not address?“ If there is one, the piece is weaker than it could be. Either address the objection or acknowledge it. Pieces that ignore their strongest objection age badly.

The writer’s job during extraction is not to admire the outputs. It is to look for places where the extracted representation says something different from what the writer intended. The mismatch is the bug. The bug is now visible because the representation changed.

B.6 Voice and style as scaffold

Voice in prose plays the role architecture plays in code. The upstream structure that makes convergent generation verifiable. A piece with explicit voice constraints has a checkable target. A piece without them has no defense against AI-default voice.

Building a voice scaffold:

Sample collection. Three to ten paragraphs of existing work that exemplify the voice. They do not have to be by the writer themselves. They can be writers whose voice is being borrowed deliberately. What matters is that the samples are coherent and recognizable. The samples go in the context.

Voice characteristics named explicitly. Sentence length distribution. Vocabulary register (everyday, technical, literary). Rhythm (clipped or flowing). What gets reached for (specific verbs, concrete nouns, embedded clauses). What gets avoided (jargon, hedges, throat-clearing, transitions of a certain shape). The named characteristics are checkable. Samples alone are not.

Negative samples. Here is what we do not sound like. Examples of voices to avoid (corporate, breezy, academic, generic AI) with the specific markers that identify them. Negative voice samples are nearly as useful as positive ones, because they activate avoidance in the model that adjectives do not.

A style guide, or its honest substitute: a list of „style no’s.“ Words we don’t use. Constructions we avoid. Rhetorical moves we don’t make. Punctuation conventions. Constraints the model can actually respect.

For organizations, this becomes a documented house style. For individuals, a personal voice file that travels with every project. Either way, the scaffold is what makes convergent generation produce text the writer or the organization actually wants, rather than text the model produces by default.

A note on the durability of voice scaffolding. Voice that lives in the writer’s head is not a scaffold. It is a hope. The writer will read the draft, recognize the deviation, and either fix it (slowly, one paragraph at a time) or accept it (silently, while telling themselves they did not). Voice that lives in explicit samples and explicit constraints is a scaffold that holds across iterations, across writers, across projects. The discipline of writing the voice down is not glamorous. The work that decides whether AI-assisted writing remains the writer’s writing.

B.7 The AI-sound problem and de-AI-fication

A specific failure mode worth its own section because it is the most common and the most underestimated. AI prose has a recognizable signature. Certain transition words, certain rhetorical moves, certain hedging patterns, certain summary structures. It reads as smooth, professional, slightly empty. Readers who have spent the last two years reading AI prose can now recognize it on contact. The recognition triggers skim-mode or skepticism, depending on the reader.

The signature has identifiable markers.

The „it’s important to note that…“ construction, used to introduce material that is not actually important. The „however, it’s worth considering…“ transition, used as a hedge against having to take a position. The „moreover/furthermore/in addition“ sequencing, which strings claims without connecting them. The „while X is true, Y is also true“ balanced-perspective close, which signals fairness without committing to a view. The „let’s explore…“ or „let’s delve into…“ opener, which gestures toward depth without delivering it. Summary paragraphs that do not summarize, just restate. Conclusions that do not conclude, just close. Bulleted lists deployed where prose would have made the argument. The em-dash used as a verbal tic.

None of these are wrong in isolation. Each appears in good human writing. What identifies AI prose is the density and the predictability. The same moves in the same places, repeatedly, across pieces that should be more varied than they are.

Why this matters. The signature does two kinds of damage. It signals AI authorship to readers who can spot it, which affects credibility and engagement. And it signals the absence of the writer’s specific voice and the absence of substantive editorial choices, which is the more important damage. A piece that reads as AI-written reads as no one’s writing. Because no one’s writing is what it actually is.

De-AI-fication is a craft skill. A deliberate pass through the draft that removes the signature and restores the writer’s voice. The part of writing that AI does not do. The pass has several moves.

Cut the signature constructions. Every „it’s important to note that“ gets deleted. If the next sentence was actually important, it stands on its own. If it was not, deletion improved the piece. Every „however, it’s worth considering“ gets either replaced with a direct contradiction or removed entirely. The hedges either commit or leave.

Replace generic transitions with specific ones. „Moreover“ rarely means „moreover.“ It usually means „this is connected to the previous point in a specific way.“ Naming the way is what good writing does.

Vary the rhythm. AI prose tends toward uniform sentence length and uniform paragraph length. Human prose has rhythm. Short sentences for emphasis. Long sentences for development. Paragraphs that breathe at different lengths.

Restore the writer’s vocabulary. AI prose reaches for safe, mid-register vocabulary. The writer’s vocabulary is sharper, weirder, more specific. The pass restores the specific words the writer would have used if writing by hand.

Recommit to the claims. AI prose tends to hedge. The writer’s writing tends to take positions. The pass converts hedges into claims wherever the writer actually has a position. Deletes the hedges otherwise.

Read aloud. Mechanical voice mismatches become audible. Sentences that scan smoothly to the eye reveal themselves as wrong-rhythmed under voice.

De-AI-fication is not a stylistic preference. It is the work that distinguishes AI-assisted writing from AI-replaced writing. A writer who skips it is shipping text that wears their byline and does not sound like them. The readers who notice will draw the conclusion the writer did not intend.

There is a useful proactive variant. Build the de-AI constraints into the original prompt so the signature does not appear in the first place. Negative samples („don’t use these constructions“) and explicit voice anchoring reduce the pass’s workload substantially. The pass remains necessary. No prompt eliminates the signature entirely. But it shortens.

B.8 From writing tool to content factory

Content pipelines automate the production of prose at scale: marketing copy, SEO content, routine documentation, newsletter sequences, personalized communications. The class question is the same as everywhere (Part I Section 7, Section A.7): not how automated the production is, but who triggers each piece and who is accountable for it.

A writer who forks a drafting agent, hands it a brief and a template, and edits what comes back is holding a tool, however little they typed. They triggered this piece and they own it. It becomes a factory when the trigger leaves the writer’s hands: a CMS event, a product-catalogue update, a schedule that fires pieces into publication without a writer authorizing each one. The move to the factory is the move that removes per-piece human authorship, and that is where the case for and against both sharpen.

When the content factory works:

The work is genuinely repetitive. The same kind of piece, many times. Product descriptions across a catalogue. Status updates following the same template. Documentation pages that follow a consistent shape.

The voice is institutional, not personal. The piece does not need to sound like a specific writer. It needs to sound like the organization, which can be specified in a style scaffold and enforced by gates.

The verification can be partly automated. Style gates that flag forbidden patterns. Fact-check passes against the source data. Schema validation on structured outputs. Plagiarism checks. Gates that absorb verification work that would otherwise fall on a human reader, because at the factory no human reads each piece.

The downstream consumption is the right kind. Informational content the reader needs but does not read for the writing. Reference material. Onboarding flows. The reader’s relationship to the piece is transactional, not editorial.

When the content factory fails:

The work demands a distinctive voice. Op-eds. Brand essays. Thought leadership. Pieces that need to read as if a specific person wrote them, because the specific person is the value.

The argument requires real editorial judgment. Pieces that take a position on something contested. Pieces that synthesize across sources in a way that requires understanding what was emphasized and what was downplayed. Pieces that need to know what to leave out.

The audience can detect AI authorship and discounts it. Readers who have learned to skim past AI-default prose will skim past pipeline output, regardless of how well it was tuned. The volume goes up. The engagement goes down. The metric that was supposed to justify the factory ends up arguing against it.

The verification cannot be automated. Fact-checking requires domain expertise. Voice consistency at the organizational level requires editorial judgment. Argument soundness requires understanding the argument. None of these survive the removal of the human per piece.

The most common failure pattern is a factory built where a tool was needed. An organization builds a content factory to scale production, optimizes for volume, achieves the volume, and gradually loses readership over twelve to eighteen months because the readers detect the signature even if they cannot name it. The dashboard shows growth in pieces published. The downstream metrics (time on page, conversion, trust) drift down. The factory produces more and more pieces that nobody finishes reading. And the organization is paying for it.

The practical heuristic mirrors the one in software. If the piece would have been written by a junior writer following a template, a factory is a reasonable next step. If the piece needed a senior writer with editorial judgment, the factory will not produce it, no matter how good the prompting. The wish to industrialize editorial work is usually a sign that the organization is reaching for visible activity rather than measured leverage. The visible activity (pieces shipped) is up. The leverage (readers engaged) is down. And a writer can build the whole pipeline and keep triggering it by hand, staying a tool, which is often the right place to stop.

A team operating a content factory well has built the substrate first. A clear voice scaffold. A style guide that gates can enforce. Fact-check sources the pipeline can query. A signal-edge process where humans decide what gets written and what gets published. Most organizations that talk about content automation have skipped one or more of these and are running a factory against an inadequate substrate. The factory produces. The substrate cannot hold what gets produced.

B.9 Failure modes worth naming

A condensed inventory of failure modes specific to AI-assisted writing.

The empty paragraph. Grammatically perfect, says nothing. Mitigation: specify the paragraph’s job in the prompt. Extract the argument structure after drafting and check that every paragraph contributes.

The borrowed style. The writer’s voice replaced by AI-default voice without the writer noticing. Mitigation: explicit voice scaffold (B.6), de-AI pass (B.7), read aloud.

The smuggled claim. Confident assertion the source did not support. Mitigation: extract unsupported claims after drafting. Check every citation against the actual source rather than the model’s representation of it.

The lost qualifier. „In some cases“ becomes „always“ in the summary. Mitigation: preserve qualifiers explicitly in the prompt. Review summary passes against originals for qualifier drift.

The misplaced certainty. Speculative claims arrive as established fact. Mitigation: explicit instruction to preserve hedging from sources. Review against sources before publication.

The structural drift. The piece does not actually make its argument. It gestures at one. Mitigation: extract the argument outline before drafting and after. Structural review separate from line review.

The AI signature. Recognizable AI-prose patterns at high density. Mitigation: negative samples in prompt. De-AI pass. Rotation of constructions to avoid predictability.

The hallucinated quote. A quote attributed to a real person who did not say it. Catastrophic and surprisingly common. Mitigation: never trust a quote the model produces. Verify against the actual source or do not include.

The plagiarism boundary. The piece is novel enough not to be plagiarism in the legal sense and close enough to a source that the writer should be uncomfortable. Mitigation: the writer reads the sources before drafting and tracks what is borrowed and what is theirs. The model’s tendency to rephrase rather than rewrite is a known liability.

The verification illusion. The reviewer signs off on AI-generated prose they did not actually verify because it read smoothly. Mitigation: smoothness is the signal to verify harder, not the signal to trust. The scaffolds (voice, argument, citation) are what extend the reviewer’s actual bandwidth.

The agreeable interrogation. The strawmanning trap (B.2) has a cause worth naming: a model tuned to agree (Part I Section 1) hands back the weak version of the counterargument by default, because the strong version means contradicting the writer. The divergent grip was supposed to push on the argument the writer is committed to. A model that shares the commitment, or performs sharing it, turns interrogation into encouragement. Mitigation: make the model hold the opposing position and defend it, not improve the writer’s; treat a divergent session that surfaced no real objection as one that did not run (Part I Section 8).

The class mismatch. Building a content factory for work that needed a writer. Or writing every routine piece by hand when a factory would have served. Each mismatch has the characteristic cost named in B.8: a factory producing pieces nobody reads, or a writer burning out on pieces that should have been automated. The middle trap is the same as in software: building an elaborate hand-run pipeline and mistaking the elaboration for the move to a factory. The pipeline is not the class. Who triggers each piece is.

The pattern across these failure modes is that AI-assisted writing surfaces, more sharply than manual writing did, where the writer’s actual editorial discipline is. A writer with a clear voice, a sharp argument, a known audience, and the habit of verifying claims has a substrate against which the model’s failures become visible and recoverable. A writer without those things has a substrate against which the model’s failures become indistinguishable from the writer’s own. The model is cheaper to blame than the writer’s missing discipline.

The work this chapter has been describing (divergent preparation, context engineering, multi-angle review, voice and style as scaffold, de-AI-fication as habit, judgment about when a content pipeline is worth building and whether its trigger should ever leave human hands) is the substrate. None of it is new. All of it was already best practice for writing at quality. AI does not make it optional. It raises the cost of not having it. And it offers more leverage to writers who already do.

The writer’s value moves toward the part of the work that does not move. The typing was the part AI took. The judgment, the voice, the editorial choices, and the responsibility for the claims are what remain.

C. AI in Analysis and Sensemaking

This chapter is for the analyst whose work is understanding. Researchers, analysts, strategists, investigators, consultants, anyone whose deliverable is not an artifact but a grasp of a situation accurate enough to act on. AI changes the economics of this work more than it changes the work itself. The failure modes are subtler than in the chapters that preceded this one.

C.1 The analyst is not a reader

The previous two chapters opened with the same observation in different forms. Developers are not typists. Authors are not typists. The opening here is structurally similar and substantively different. The analyst’s visible work was reading. Sources, documents, data, evidence. The output was understanding. A grasp of the situation precise enough to make recommendations against. AI now reads at speed. It produces summaries, comparisons, extractions, syntheses. The activity that filled the analyst’s day is the activity that has been most directly automated.

The conclusion that AI has automated analysis is wrong, and the place it goes wrong is more delicate than in the previous chapters. Analysis is not just reading. It is the structured production of understanding from reading. What was actually happening when the analyst read was a process the analyst was largely unaware of. Deciding what to trust and what to discount. Noticing what the source emphasized and what it elided. Holding contradictions between sources in mind until they resolved or remained unresolved. Building a mental model that survived contact with new evidence. The reading was the surface. The understanding was downstream of it. The understanding lived in the analyst’s head, not in the documents.

AI produces summaries. It does not produce understanding. A summary is what a reader could have made notes about. Understanding is what a reader could have acted on. The two look similar at a distance and diverge at the point of decision. An analyst who substitutes the model’s reading for their own has not saved time. They have moved the understanding out of their own head and into a representation they did not build. The representation is missing the parts that would have lived in the analyst’s silent judgment.

This chapter is about the part of analysis that does not move. And about how AI accelerates the part that does. The leverage is real. The trap is real. The line between them is sharper here than in code or prose, because the deliverable is a state of mind rather than an artifact on disk.

C.2 Divergent work: questioning the corpus

The divergent grip is the dominant mode in analysis. Where developers and writers use it as preparation for a downstream artifact, analysts use it as the work itself. Most of what an analyst does is a structured interrogation. Of sources. Of evidence. Of the situation. Of their own conclusions.

High-leverage divergent applications in analysis:

Source interrogation. What does this source actually claim. What does it not address. What is its provenance, its likely bias, its incentive to mislead. What does it elide or downplay. The model is useful here because it can run interrogation in parallel across many sources, where the analyst working alone would be doing it in serial.

Contradiction surfacing. Across the corpus, where do the sources disagree. The model can hold many sources in context simultaneously and identify points of contention that the analyst reading one at a time would have to remember manually. The output is a map of where the consensus is and where it is not. The map is what an analyst can then investigate further.

Assumption mapping. What does this corpus assume the reader knows. What does it assume about how the world works. What does the analyst themselves assume that the corpus does not address. The divergent grip is good at surfacing assumptions across many sources at once, in a way that exposes which assumptions are shared (and therefore invisible) and which are contested (and therefore worth investigating).

Steelmanning positions. Given a position the corpus takes, what is the strongest version of the counter-position. Given the analyst’s emerging view, what is the strongest challenge to it. Analysts who only encounter weak versions of opposing arguments build fragile understanding. The divergent grip is the cheapest way to get strong versions on the table.

Gap identification. What is missing from this corpus. What questions remain unanswered. What evidence would settle the contested points. The model can produce a list of gaps that the analyst then prioritizes by importance and tractability. Upstream of further reading. Shapes what to look for next.

Reframing. What is this situation actually about, if we look at it differently. Is the framing the corpus uses the right one. What would the situation look like under an alternative frame. Analysts often inherit a framing from the corpus they are reading and stop seeing it. The divergent grip is one of the few moves that can surface a frame and make it visible.

Divergent work in analysis is the work. Convergent work (Section C.3) closes the loop, but the bulk of value comes from interrogation, surfacing, mapping. An analyst who uses AI primarily for summaries has used it for the lowest-leverage activity available. An analyst who uses it for interrogation has used the model for what it is uniquely suited to do.

A specific note on the divergent grip’s bandwidth advantage. A human analyst can interrogate a source carefully but slowly. The model can interrogate ten sources in the time the analyst would take to interrogate one. Not a quality multiplier. The model’s interrogation is shallower than an expert’s. A coverage multiplier. The analyst now interrogates everything at moderate depth and selects what to interrogate at human depth based on what the broad pass surfaced. Used this way, the model extends the analyst’s effective coverage of the corpus without replacing the deep interrogation that matters.

These interrogations are best run as mini-sprints (Part I Section 8), and analysis is where the sprint discipline matters most, because the divergent grip here is the work itself rather than preparation for a downstream artifact. A sprint has a defined target (interrogate this source for what it elides, not „look at this source“), a gate, and an exit that hands a result forward. The gate in analysis is specific and unforgiving: did this sprint move understanding into the analyst’s head, or did it produce a representation that now sits outside it. That is the displacement question (C.4, C.7) asked at the unit of work, before the displacement has accumulated across a whole project. A divergent session with no gate is exactly how an analyst ends a week knowing what the model said and not knowing what the sources said. The sprint floor is what the divergent grip in analysis structurally lacks and needs most.

C.3 Convergent work: structured synthesis

The convergent grip in analysis is where the analyst asks the model to produce a structured output that the analyst will then verify and integrate. Not a summary in the loose sense (the dominant failure mode of analytical AI use). A structured artifact with explicit conditions.

Useful convergent outputs in analysis:

Comparison matrices. Given several sources or positions, produce a structured comparison along defined dimensions. The dimensions are specified by the analyst. The model fills the cells from the sources. The result is checkable per cell against the source.

Timeline reconstructions. Given a corpus that touches on events, produce a chronological reconstruction with each event tagged by source. The output is structurally falsifiable. Any event has a citation. Any citation can be checked. Any disagreement between sources becomes visible.

Argument maps. Given a complex position, produce the argument structure. Claim, supporting claims, evidence, dependencies. The map exposes whether the argument is sound, whether evidence supports the claims it is attached to, where the load-bearing dependencies are.

Entity inventories. Given a corpus, produce a structured list of the entities involved. People, organizations, locations, instruments, events. With what each source says about each entity. The inventory is the basis for further investigation. It surfaces who is mentioned where and how.

Position summaries. Given the corpus, produce a structured statement of each significant position. Who holds it. What it claims. What supports it. What it does not address. The summary is checkable claim by claim.

The discipline that distinguishes useful convergent synthesis from useless summarization is the discipline of specifying the structure upfront. „Summarize this report“ produces prose that may or may not be useful and is hard to verify. „Produce a comparison matrix with these columns, one row per source, citing source line for each claim“ produces a structured artifact the analyst can verify cell by cell.

The verification load is real and not optional. The analyst’s job is not to read the synthesis and trust it. The job is to spot-check the structured artifact against the sources. Take a sample of cells. Verify them. Find the failure rate. Decide whether the rate is low enough to use the artifact as input to further work or high enough to require redoing it. A synthesis with a 3% claim error rate may be usable for navigating the corpus. A synthesis with a 30% error rate is misleading data dressed as evidence.

C.4 The verification problem in sensemaking

The verification problem in analysis is structurally the worst of the four chapters in this section. The artifact being verified is partly in the analyst’s head. In code, the artifact is a file. In prose, the artifact is a piece. In analysis, the artifact is the analyst’s grasp of the situation. The question of whether that grasp is correct is rarely answered until the analyst acts on it.

Specific verification failure modes:

The plausible summary. The model produces a summary that reads as a fair account of the source. The analyst’s mental model now contains the summary, not the source. Subtle but significant departures from the source (emphasis shifts, qualifier loss, framing changes) are now in the analyst’s understanding and will not surface unless the analyst goes back to the source. Most analysts do not. The summary read fine.

The averaged position. The model synthesizes multiple sources by averaging or smoothing across them. The result reads as a balanced view. What is actually missing is the disagreement. The points on which sources differ, which are usually the most important points for an analyst to know. The synthesis presents consensus where consensus did not exist, and the analyst absorbs the false consensus.

The lost specificity. The source said „between 12 and 18% in three of seven studies.“ The synthesis says „research suggests a moderate effect.“ The model has converted precise findings into generic gestures. The analyst now knows less than they did before reading the synthesis.

The hallucinated coherence. The model produces a synthesis that is internally coherent. The corpus was not. The model has invented a unified view that does not exist in the sources. The unified view is now what the analyst remembers. The actual landscape (fragmented, contradictory, partial) has been replaced by a clean picture the analyst will use to make decisions.

The smuggled inference. The model draws a conclusion that follows from the sources but was not stated in any of them. The conclusion may be correct or incorrect. Either way, the analyst now holds it as if a source supported it. When asked, the analyst will say they read it somewhere. They did not.

The displaced understanding. The most general failure mode. The analyst’s understanding of the situation is now a function of the model’s summaries rather than the analyst’s own engagement with the sources. The analyst can answer questions about the situation. The answers come from the synthesis, not from the analyst’s own model of what is happening. When the situation diverges from the synthesis (which it will), the analyst will not notice, because the analyst’s understanding lives in the wrong place.

The reviewer in analysis is the analyst themselves. The verification problem is therefore also a self-discipline problem. No external review step catches the displaced understanding. The analyst either chose to engage with the sources directly or did not. AI makes the not-engaging path much easier than it used to be. The consequences only surface when the analyst’s recommendations meet the situation they were supposed to grasp.

C.5 Reading-with-AI: techniques and pitfalls

The practical question for most analysts is how to use AI to read a corpus without losing the engagement that makes analysis work. A few techniques are worth naming.

Selective summary, not bulk summary. The model is useful for summarizing what the analyst has decided not to read deeply. The long appendix. The tangential reference. The source whose conclusion matters but whose argument the analyst does not need. The model is harmful when used to summarize what the analyst does need to read deeply, because the summary then displaces the actual reading. The selection of what to summarize and what to read is itself analytical work. It does not get delegated.

Targeted extraction. Rather than asking for a summary, the analyst asks for specific structured outputs from a source. Claims with citations. Methodology. Sample sizes. Limitations stated. Contradictions with named other sources. The structured outputs are anchored to the source and checkable. They serve as a navigation aid into the source, not a replacement for it.

Question-driven reading. Before opening a source, the analyst formulates the questions the source needs to answer. The model is used to scan the source for material relevant to those questions. The analyst reads the relevant passages directly. The model navigates. The analyst reads. RAG used as an analyst’s tool rather than a chatbot’s substrate.

Cross-source interrogation. With multiple sources in context, the analyst asks comparative questions the model is well-suited to answer. Where do these sources agree. Where do they disagree. What does source A say that source B does not address. The model’s bandwidth advantage is most useful here. The analyst could do this comparison alone but slowly. The slowness leads to comparisons being skipped.

Retrieval, and why provenance is the whole game. When the corpus is too large to read and has to be retrieved rather than opened (Part I Section 10), the analyst is running RAG whether they call it that or not. The mechanics from Section 10 land harder here than anywhere else in the guide, because analysis is the one craft where the source of a claim is part of the claim. A retrieval system that returns the right passage with no reliable pointer back to which document, which page, which date it came from has produced exactly the input that breeds the smuggled inference and the displaced understanding (C.4). The analyst needs the chunk and its provenance together, or the chunk is a rumor. Three consequences follow. Chunking has to preserve the unit of attribution: a chunk that merges two sources, or strips the citation that anchored it, is worse than no chunk. Hybrid retrieval matters more here than in most domains, because analysis turns on exact things (a name, a date, a figure, a specific claim) that pure semantic search slides past. And a retrieval miss is the analyst’s specific nightmare: the load-bearing source that was never retrieved leaves no gap the model will mention, and the analysis proceeds confidently around a hole. Retrieval in analysis is not „more context.“ It is provenance-preserving navigation, and the provenance is the part that does the work.

The forbidden move. Asking the model „what should I conclude from this.“ The model will produce a conclusion. The conclusion will sound plausible. The analyst will absorb it. The displacement failure in its purest form. The technique to avoid it is to never ask the question. The analyst draws their own conclusions from material the analyst has engaged with. The model can supply material. It does not draw the conclusion.

A useful self-check for the analyst. At any point in the work, ask whether the current understanding of the situation came from the analyst’s own engagement with the sources or from the model’s representation of them. If the latter, the analyst is in displacement territory and should re-engage with the sources directly before proceeding. The check has to be deliberate because the displaced understanding feels exactly like the engaged understanding from inside the analyst’s head.

C.6 Multi-source synthesis: comparing, contradicting, weighting

Synthesis across many sources is where AI’s bandwidth advantage is largest and where the failure modes are most consequential. A few principles.

Compare before synthesizing. Before producing a synthesis, produce a comparison. Where do the sources agree. Where do they disagree. What do they each address that the others do not. The comparison is the input to synthesis. Without it, the synthesis is averaging without knowing what is being averaged.

Weight by source quality, not by source agreement. A synthesis that treats all sources equally treats a primary source the same as a secondary source citing the primary source, and a peer-reviewed study the same as a blog post. The analyst’s job is to weight the sources before synthesizing. The model will not do this unless instructed. It will not do it well even then.

Preserve disagreements explicitly. The output of a multi-source synthesis should not be a unified view. It should be a structured account. Here is what the sources agree on. Here is where they disagree. Here is what each disagreement turns on. The disagreements are usually the most useful output. They are where further investigation pays off most.

Identify the gaps. Across the corpus, what is not addressed at all. Gaps in coverage are usually more important than disputes within coverage. The easiest thing to miss because the absence of a topic does not announce itself. The model can be asked specifically for gaps. The asking surfaces them.

Track what is borrowed. As the synthesis develops, the analyst maintains a record of which claims came from which sources. Not just a citation discipline. A hedge against the smuggled-inference failure mode. When the synthesis later contains a claim that traces to no source, the analyst can locate it and decide whether it is the analyst’s own inference (legitimate, with appropriate flagging) or the model’s hallucinated coherence (a bug to remove).

Resist premature closure. The model’s instinct is to produce a coherent synthesis. The analyst’s instinct should be to resist premature coherence, especially when the corpus is contested. A synthesis that is messier than the model would produce (names tensions instead of resolving them, flags uncertainty instead of smoothing it) is usually a more honest representation of the actual situation.

Multi-source synthesis is where AI’s leverage is greatest and where the analyst’s discipline is most necessary. The bandwidth advantage allows engagement with more sources than the analyst could have managed alone. The displacement risk applies to all of them at once.

C.7 The temptation of the summary

This section names the central anti-pattern of AI-assisted analysis explicitly, because it is the failure mode most analysts will fall into by default and the one most damaging to the work.

The temptation is direct. Instead of reading the source, ask the model to summarize it. Instead of comparing the sources, ask for a synthesis. Instead of struggling with the contested points, ask for a unified account. Each step saves time. Each step also moves the analyst’s understanding one degree further from the actual material. The cumulative effect over a long project is an analyst who knows what the model said and does not know what the sources said.

The temptation is acute because the model’s outputs are convincing. The summary reads well. The synthesis is coherent. The unified account is clear. The analyst’s actual engagement with the sources would have produced something messier, more partial, more contested. The model’s output looks better than the messier reality, and the analyst feels productive accepting it.

The cost is delayed. The displaced understanding does not surface until the analyst’s recommendations meet the situation. At that point, the analyst will be wrong in ways the analyst cannot diagnose, because the analyst does not know which parts of their understanding came from the sources and which came from the model. The post-mortem on a failed analysis cannot reconstruct what went wrong. The boundary between what the analyst engaged with and what they accepted from the model was never recorded.

The mitigation is procedural and personal.

Track the provenance of every load-bearing claim in the developing analysis. Did this come from the analyst’s reading, or from the model’s summary. The bookkeeping is annoying. The only defense against silent displacement.

Maintain a „I have not read this yet“ list. Sources that have been summarized but not engaged with directly are on the list until they have been read. A constant reminder of where the analyst’s understanding currently rests on the model and where it rests on the analyst’s own work.

Re-engage with sources before key decisions. When a load-bearing claim is about to be acted on, go back to the source. Read it. Confirm that the model’s summary captured what the source said. The re-engagement catches the failures the original summary hid.

Use the model for navigation, not destination. The model gets the analyst to the right page of the right document at the right line. The analyst reads the lines. This division of labor preserves the analyst’s engagement while still getting the bandwidth advantage AI offers.

The temptation is also institutional. Organizations measure analytical output by the volume of work covered and the speed of delivery. Both metrics reward the analyst who uses the model for displacement, because the displaced analyst can cover more in less time. The cost of displacement is borne by the organization downstream when the analysis fails. The cost is rarely attributed to displacement because the chain of attribution is too long. An organization that wants honest analysis has to measure the analyst’s engagement, not the analyst’s coverage. Genuinely hard to do. Most organizations do not do it.

C.8 From research tool to research factory

Analytical work gets automated into pipelines: research agents, retrieval systems with autonomous loops, document-processing systems that produce reports. The case for it is concrete and the case against is sharper than in software or text crafting. The class question is the same as everywhere (Part I Section 7, Section A.7): not how autonomous the pipeline is, but who triggers each run and who engages with each result.

A research agent the analyst starts, points at a question, and whose triage the analyst then reads is Class 2, however many steps it ran on its own. The analyst triggered this run and engages with what it found. That is a tool, and a good one. It becomes a factory when the trigger leaves the analyst’s hands: a scheduled scan, an event feed, a standing query that fires without a human deciding this run should happen, producing output that flows downstream without a human engaging with each batch. The autonomy did not change. The trigger did, and with it the thing that was holding the analysis together. This matters more in analysis than anywhere else, because the substrate a factory removes is the analyst’s engagement with sources, and in analysis that engagement is the product (C.1, C.4).

When the research tool works (analyst-triggered, analyst-engaged):

The work is high-volume monitoring rather than deep analysis. Scanning a stream of documents for predefined signals. Tracking developments across many sources looking for triggers. Producing structured situation reports against fixed templates. The pipeline surfaces items into the analyst’s attention. It does not draw conclusions.

The verification is structured, not interpretive. The pipeline’s claims are checkable against retrieved sources by automated comparison, provenance preserved (C.5). Mismatches between claim and source surface without human judgment.

The output is triage, not recommendation. „Here are the documents that mention X.“ „Here are the sources that disagree with Y.“ The analyst engages with the triage and draws the conclusions.

When it fails (the factory on work that needed engagement):

The work requires interpretation. The pipeline produces interpretations dressed as facts. Downstream consumers read the output as research, absorb the interpretations, act on them. Displacement at organizational scale.

The work is contested. Pipelines produce smooth syntheses. Contested terrain has rough features. The pipeline elides the roughness. The organization decides against terrain that was always rougher than the representation it was handed.

No one is at the signal edge. This is the factory’s defining property, not a discipline failure. At Class 2 the analyst directs the pipeline’s attention, refines its queries, discards what is not useful. At Class 3 no human does this per run, by construction. The pipeline generates volume, and the organization swims in output nobody reads carefully because nobody is assigned to.

The most common failure pattern is a factory built where a tool was needed. An organization deploys a self-triggering research pipeline. It produces structured output faster than any analyst can engage with it. Analysts skim. The skimming produces displaced understanding at organizational scale (C.7). Decisions get made against the pipeline’s representation of the world, and that representation drifts further from the world the longer the pipeline runs and the weaker the feedback loops get. The organization ends up operating on the pipeline’s worldview with nobody engaging the actual sources. The pipeline was never the problem. Handing it the trigger was.

The practical heuristic. A research pipeline is a tool as long as a human triggers its runs and engages with its output, and it is worth building in that form. Handing it a non-human trigger is a separate decision, and in analysis it is rarely the right one, because the thing automation removes is the analyst’s engagement with sources, which is the thing the analysis was for. The pipeline that surfaces material for an analyst who then reads the sources is leverage. The pipeline whose output is read as the analysis is a displacement engine, regardless of how well it was built.

C.9 Failure modes worth naming

A condensed inventory of failure modes specific to AI-assisted sensemaking.

The plausible summary. Subtle but significant departures from the source absorbed into the analyst’s mental model. Mitigation: re-engage with sources for load-bearing claims. Verify summaries against originals.

The averaged position. Synthesis smooths over the disagreements that were the most important thing to know. Mitigation: produce comparisons before syntheses. Preserve disagreements explicitly in the output.

The lost specificity. Precise findings converted into generic gestures. Mitigation: structured extractions that preserve numbers, conditions, qualifiers. Review for specificity loss as a discrete pass.

The hallucinated coherence. Unified view invented where the corpus was fragmented. Mitigation: explicit instruction to flag contradictions. Resist premature closure as a discipline.

The smuggled inference. Conclusion drawn that follows from sources but was not stated by any. Mitigation: track provenance of every claim. Flag inferences as inferences, not as findings.

The displaced understanding. The analyst’s grasp of the situation now lives in the model’s representations rather than the analyst’s engagement. Mitigation: track provenance of understanding. Re-engage with sources before key decisions. Use model for navigation, not destination.

The pipeline-as-analysis confusion. Self-triggered pipeline output read as conclusions when it should be read as triage. Mitigation: keep research pipelines as analyst-triggered tools where the work needs engagement (C.8). Maintain the distinction between „pipeline says“ and „analyst concludes.“ Never let pipeline output substitute for analytical work on contested matters.

The provenance-stripped retrieval. Retrieval that returns the right content with no reliable pointer to its source, breeding smuggled inference and displaced understanding. Mitigation: provenance-preserving chunking and hybrid retrieval (C.5, Part I Section 10). Treat a chunk without its source as a rumor, not evidence.

The bandwidth illusion. Coverage of many sources at shallow depth mistaken for thorough analysis. Mitigation: deliberate selection of which sources to engage with deeply. Honesty about which sources were only scanned.

The framing absorption. The model’s framing of the situation absorbed without examination, the analyst’s outside view quietly replaced by the model’s (Part I Section 8). Compounded by sycophancy (Part I Section 1): an analyst who signals an emerging view gets it handed back as if the corpus supported it, and the interrogation meant to challenge the view confirms it instead. Mitigation: explicit reframing pass; ask the model to produce alternative framings before accepting the first one; treat a session that only confirmed the analyst’s prior as a session that interrogated nothing.

The citation theater. Outputs with citations that look authoritative. Citations that the producer did not verify and the consumer will not check. Mitigation: verify citations as part of producing them. Treat unverified citations as worse than no citations.

The pattern across these failure modes is that sensemaking with AI surfaces, more sharply than manual analysis did, the difference between an analyst who engages with sources and an analyst who reads about them. The model can produce excellent summaries of either engagement or its absence. The summaries look similar. The analyst’s discipline is what distinguishes useful AI-assisted analysis from displaced analysis dressed as the same thing.

The work this chapter has been describing (divergent interrogation, structured convergent synthesis, multi-source comparison, careful reading-with-AI, resistance to the summary’s temptation, and a clear sense of when a research pipeline should stay an analyst-triggered tool and when, rarely, its trigger can be handed off) is the substrate. Older than AI and more important now than it was before. AI does not make it optional. It raises the cost of not having it. And it offers the largest leverage of any chapter in this guide to analysts who maintain it.

The analyst’s value moves toward the part of the work that does not move. The reading volume was the part AI took. The judgment about what the sources actually mean, what the situation actually is, and what the right response actually requires. That is what remains. What remains is the value.

D. AI in Management and Strategy

This chapter is for the manager, executive, or strategist deciding about AI rather than working with it. The audience is people whose deliverables are budgets, policies, hiring decisions, organizational structures, and procurement choices. People whose AI-related decisions affect everyone downstream of them. The work this chapter describes is mostly invisible from inside an AI-using team. The failure modes are mostly invisible from inside an AI-deciding executive’s office. Both sides see different parts of the same problem.

D.1 The decision-maker is not the user

The previous chapters opened with the same observation in domain-specific forms: value sits in judgment, not in the visible activity AI accelerates. The opening here is different. The manager or executive is not doing the visible activity at all. They are not writing code, drafting prose, or reading sources. They are deciding about other people doing those things. What tools to provide. What budgets to allocate. What skills to hire for. What policies to enforce. What to count as success.

The manager’s relationship to AI is mediated. They do not have direct evidence of what AI does well and what it does badly. Their evidence comes from demonstrations (optimized for impression), from vendor pitches (optimized for sales), from headlines (optimized for engagement), and from their own teams (whose reports are filtered through what those teams think the manager wants to hear). All four filters bend toward optimism and against complexity. The manager’s information environment is structurally worse than the team’s. The manager has less time to interrogate it.

The conclusion that follows is uncomfortable and important. Most decisions about AI in organizations are made on bad information by people who have less time than they need to evaluate it, with consequences that fall mostly on others. Not a failure of management. The structural shape of the role. But it is the condition under which AI strategy gets set. A strategy made under this condition without explicit defenses against the condition’s failure modes will inherit those failure modes.

This chapter is about the defenses. They are not glamorous. Mostly about asking specific questions. Refusing specific tempting answers. Maintaining specific disciplines against specific pressures. The leverage is high. The visibility, as in every other chapter, is low.

D.2 Divergent work: questioning the strategy before committing budget

The divergent grip is the manager’s cheapest defense against bad AI strategy, and it operates on the strategy itself rather than on the AI. The question is not „what can AI do for us.“ That question, asked of any decent model or vendor, produces a list optimized for credibility and unconnected to the organization’s actual problems. The useful question shape is the inverse. Given a specific problem the organization has, would AI help, and if so, in which mode.

High-leverage divergent applications for managers:

Problem before solution. Before evaluating an AI investment, articulate the problem it would solve in terms that have nothing to do with AI. „We need to reduce ticket triage time“ is a problem. „We need to use AI for ticket triage“ is a solution looking for a problem. The divergent grip is useful here for surfacing whether the problem actually exists, whether it is the most important problem to solve, and whether AI is the right solution if it does.

Class before scope. Before sizing an AI investment, ask which class of problem this is. Is it a classification problem that wants a classifier (Class 1). Is it a craft problem that wants better tools for practitioners (Class 2). Is it a repetitive process problem that wants orchestration (Class 3). The class determines the architecture, the budget shape, and the team that should own it. Most failed AI investments are class mismatches sized to the wrong economics.

Counterfactual interrogation. What would we do if we could not use AI for this. The answer is usually instructive. Sometimes it is „we would not do this at all, because the problem is not actually important enough.“ Sometimes „we would use a simpler tool that we could deploy in two weeks.“ Sometimes „we would hire two analysts who would do this better than any pipeline.“ The counterfactual surfaces whether the AI investment is competitive with the alternatives or only with the absence of action.

Failure-mode anticipation. What does this look like when it fails. Not „what is our success criterion“ but „what is the failure pattern, who notices it, when, and what does it cost.“ Most AI investments are evaluated against success metrics and never against failure costs. The failure costs are absorbed silently and never traced back to the decision.

Incentive interrogation. Who in the organization benefits from this AI investment regardless of whether it works. The vendor benefits from selling. The internal champion benefits from being seen to drive innovation. The reporting line benefits from impressive metrics. The actual users may or may not benefit. The customers may or may not benefit. A divergent interrogation of incentives surfaces who is invested in the appearance of success and who is invested in the substance. The two are rarely the same set of people.

Reversibility check. Is this decision reversible. If we deploy this AI system and discover in eighteen months that it was the wrong call, can we unwind it. Some AI investments lock in vendor dependencies, organizational restructuring, and data dependencies that are expensive to undo. Reversibility is rarely interrogated upfront and rarely available afterward.

The manager’s divergent work is mostly about refusing to accept the framing the AI conversation arrives in. The framing arrives optimized for action. For buying, deploying, restructuring. The divergent grip slows that down long enough to ask whether the action is actually warranted, in this form, for this problem, on this timeline. A manager who skips this step is making fast decisions on framings supplied by people whose incentives the manager has not interrogated.

D.3 Convergent work: writing the AI strategy that actually constrains action

The convergent grip in management is where the divergent interrogation gets converted into committed strategy. The output is documents. Policies, budgets, organizational diagrams, hiring frames, success criteria. Documents that constrain what the organization does next.

A useful AI strategy specifies:

Which problems AI is being deployed against, named at the problem level rather than the technology level. „Reduce ticket triage time by 40% by Q3“ is a problem-level commitment. „Adopt AI in support operations“ is not. A wish dressed as a strategy. It cannot be evaluated against any outcome and does not constrain any decision.

Which classes of AI investment the organization will make, and which it will not. A strategy that says „we will use AI for Class 2 productivity tooling and not build Class 3 pipelines this year“ is constraining. A strategy that says „we will be an AI-first organization“ is not. It commits to nothing specific and allows any future investment to be justified retroactively.

The verification model. How the organization will know whether its AI deployments are working. Not „we will track adoption.“ Adoption is theater. The verification model needs to be measurable, downstream, and tied to the actual problem the deployment was supposed to solve. If verification is hard to specify, that is information. The deployment may not be solving a verifiable problem.

The capacity constraints. What organizational capacity will need to exist to operate this AI well. Verification capacity. Security review capacity. Incident response capacity. Documentation capacity. The lines most often missing from AI strategies. The lines that determine whether the deployment survives contact with operations.

The exit criteria. Under what conditions will the organization stop this AI investment. Not „if it fails.“ Too vague to act on. Specific triggers: adoption below X by date Y, error rate above Z, downstream cost exceeding A, vendor lock-in passing threshold B. Exit criteria are rarely specified upfront because they feel pessimistic. They are the most important part of the strategy because they are the only protection against sunk-cost continuation of failed deployments.

The accountability structure. Who owns each part of this. The deployment itself. The operation. The verification. The failure response. The exit decision. AI strategies that read as collective commitments („we will“) have no accountability. Everyone is responsible. Nobody is. Useful strategies name owners.

A strategy with these elements constrains action. A strategy without them is a slide deck. The distinction matters because the slide-deck version is dramatically more common, dramatically easier to produce, dramatically easier to approve, and dramatically less useful. An organization that ships AI strategy as slide decks is not making strategic decisions about AI. It is producing artifacts that look like strategic decisions while continuing to make tactical decisions ad hoc.

D.4 The verification problem in strategy

The verification problem in strategic AI decisions is structurally worse than in any of the previous chapters. The feedback loops are longer. A code review provides feedback in hours. An article’s readership provides feedback in weeks. An analytical conclusion is tested when it meets reality, weeks to months later. A strategic AI decision is tested when its consequences accumulate, twelve to thirty-six months later. At which point the manager who made the decision may have moved on. The organization’s situation may have changed. The counterfactual is unrecoverable. The post-mortem cannot disentangle the decision’s effects from everything else that happened in the interim.

The consequences of this structural verification gap:

Decisions are evaluated by their reception, not their results. A strategy that was well-received at announcement is treated as a good strategy regardless of what it produces eighteen months later. A strategy that was poorly-received but produced good outcomes is rarely re-evaluated. The reception is the feedback the decision-maker actually gets. The results, if they ever arrive, arrive too late and too entangled to be informative.

Theater dominates substance. Because results are unmeasurable on the relevant timescale, success is performed rather than achieved. Dashboards proliferate. Adoption metrics inflate. Success stories accumulate. The organization develops an internal narrative of successful AI transformation that is decoupled from any externally verifiable outcome. The narrative becomes the substance the organization actually has.

Class confusion compounds silently. Because the verification of strategic decisions is poor, the costs of class mismatches do not feed back into the decision process. The organization continues to fund Class 3 pipelines for Class 1 problems. Continues to deploy Class 2 tooling on problems that wanted Class 3 industrialization. Continues to procure Class 1 components for problems that wanted Class 2 craft tooling. Each mismatch produces its costs over time. The costs are absorbed silently as background organizational dysfunction rather than attributed to the strategic decisions that caused them.

Vendor relationships ossify. Decisions about AI vendors are particularly prone to verification failure. The vendor’s job is to make the decision feel good. The decision-maker’s job is to make it before they have enough information. By the time the vendor relationship is mature enough to evaluate, the switching cost is high enough to discourage evaluation. The organization continues with a relationship whose value it cannot actually measure.

The mitigations are organizational and procedural rather than technical:

Pre-commit to verification specifics. Before approving the strategy, write down what the verification will look like, when it will happen, and who will do it. Not „we will measure success.“ Rather: „twelve months from deployment, this specific person will produce this specific report against these specific metrics, and the strategy will continue, modify, or terminate based on this specific decision rule.“ Pre-commitment is the only defense against the verification gap.

Decouple verification from advocacy. The person who championed the AI deployment should not be the person verifying it. Their incentives are misaligned. The misalignment is not a moral failing. It is structural. Verification by a separate accountability owner is one of the rare organizational moves that actually catches strategic failures rather than rationalizing them.

Maintain the counterfactual. Where possible, run pilot deployments with comparable non-AI alternatives. Verify against the alternative rather than against the absolute. „Faster than nothing“ is the easiest standard to meet and the least useful. „Faster than the simpler alternative we considered“ is harder and more informative.

Audit theater explicitly. Periodically ask, in a meeting where the answer can be uncomfortable: which of our AI metrics are measuring substance and which are measuring activity. The first category is small. The second category is large. The honest audit is what keeps the strategy connected to outcomes.

D.5 The taxonomy as procurement filter

The Class 1 / Class 2 / Class 3 distinction is not just a descriptive sorting. The most useful procurement filter available to a manager evaluating AI investments. Most AI procurement failures are class mismatches sized to the wrong economics. The filter catches them before the budget is committed.

Class 1 procurement. Buying or building an embedded AI component to do one bounded job inside a larger system. Spam filter, fraud detector, classification component, recommendation engine. The economics: substantial maintenance surface (monitoring, retraining, drift detection), modest per-unit inference cost, long deployment timeline before value is realized. The procurement question: does this problem actually want a probabilistic answer, or would a deterministic alternative be cheaper. The trap: buying a Class 1 component for a problem that did not need machine learning, because Class 1 components are easy to budget for and feel substantial.

Class 2 procurement. Buying AI tooling for practitioners to use directly. Copilots, chat interfaces, document assistants, analytical platforms. The economics: per-seat license cost, ongoing per-token usage cost, organizational adoption work that does not appear in the vendor’s pricing. The procurement question: which roles will use this, for which work, with what verification discipline. The trap: buying Class 2 seats and assuming productivity will follow. Without the verification discipline (Section A.4, B.4, C.4) and the context engineering capacity, Class 2 tools produce displacement rather than productivity. The displacement is invisible on the procurement dashboard.

Class 3 procurement. Buying or building orchestrated AI systems that run as factories: triggered without a human authorizing each run, shipping results through gates instead of per-run review. Agentic pipelines, multi-agent systems, autonomous research or development workflows. The economics: high upfront engineering cost, substantial ongoing operational cost (containment, monitoring, incident response, eval harness), and a slow ramp before the system is reliable enough to trust. The procurement question: does this work pattern actually repeat enough to amortize the orchestration cost, and is the trigger genuinely better handed off than kept in human hands (Part I Section 7, Section A.7). The trap: procuring Class 3 ambition with Class 2 budget and Class 1 substrate. The pipeline gets built. The substrate cannot support it. The operational costs sink the deployment.

The filter, applied to any AI procurement decision, asks three questions. First: which class is this. Second: does the proposed scope match the class’s economics. Third: does the organization have the substrate the class requires. A procurement that passes all three has a chance. A procurement that fails any of them is buying a known failure mode at the price of a working solution.

A specific observation worth naming. Vendors do not present their products in class terms because the class boundaries cut across product categories. A copilot product is Class 2. An agent platform from the same vendor is Class 3. The underlying API access supports both. The vendor’s pitch flows across the boundaries, blending Class 2 productivity gains with Class 3 automation promises and Class 1 specialized capabilities. The procurement officer’s job is to ungeneralize the pitch back into specific class commitments and evaluate each on its own terms. Unglamorous work. The procurement officer who does it is usually the only person in the room asking the questions that determine whether the deployment will work.

One category of procurement that organizations rarely treat as procurement: the open-source dependency tree. Every production system runs on packages, libraries, build tools, and frameworks maintained by people the organization did not hire and does not pay. The dependency tree is a vendor relationship never negotiated and unreplaceable on any reasonable timeline. AI puts new pressure on this substrate (see Section E.9). An organization with a rigorous filter for AI tooling procurement and a blank acceptance policy for open-source dependencies is governing the smaller risk. Procurement discipline that does not include the dependency substrate is procurement applied to the visible layer of a system that mostly is not visible.

The deeper trap: strategy as procurement at all.

The filter sorts what to buy. The harder point is that the buy-frame is itself where the strategic error usually sits. An organization that asks „which AI model, which AI platform, which AI vendor“ is running a procurement process, and the question assumes the defensible thing is the thing being bought. For AI, it is not.

Locate the value on the stack (Part I Section 4). Below the API seam sit the model and the inference layer. That is the layer being sold, and it is the layer commoditizing. The commoditization is a mechanism, not a forecast: open-weight models keep closing the capability gap, the compute economics of inference keep falling, and local inference keeps getting cheaper to stand up. None of that depends on believing a vendor roadmap. It follows from where the cost curves already point. The adaptation layer (Part I Section 4) is part of why the capability gap closes: distillation and parameter-efficient fine-tuning pull a smaller open model toward a frontier one’s behavior at a fraction of the cost. For the adopting organization, the frontier model is usually the least defensible layer of the stack, because it is the layer most exposed to substitution. For the company that builds the frontier model, the same layer is the moat; which view applies depends on which side of the API seam you sell from.

Above the API seam sits everything the organization builds or rents around the model: retrieval, tools, state, permissions, evals, observability, the workflow control that turns a model into a system. This is where the engineering lives (Part I Section 9: the harness, not the model, usually decides reliability). It is the layer that does not arrive in a vendor’s box, that has to be built against the organization’s actual systems and data and constraints, and that is therefore where defensible value accumulates. The market sells intelligence. The system delivers engineering. An organization that treated AI strategy as a procurement exercise was solving a software architecture problem without knowing it. The strategic questions were never „which model.“ They were „what retrieval substrate, what permission model, what eval discipline, what observability, what state and workflow control, and do we own these or rent them.“ Those are architecture questions. Procurement was the disguise.

Build versus rent, and the second trap. „Value moves to the substrate“ is not „buy a substrate platform.“ The cloud analogy cuts both ways. Commoditization of primitives did concentrate value in platform layers, and the first act of that story is accessibility: the platform makes the hard thing easy. The second act is lock-in, where the binding migrates from the entry to the exit, and leaving costs more than entering ever did. An organization that responds to „the substrate is where the value is“ by procuring a managed substrate platform has not escaped the procurement trap. It has moved the trap one layer up, from renting a model to renting the substrate that was supposed to be its defensible position. The distinction that decides this is between building and owning the substrate and renting managed scaffolding that looks like a substrate and behaves like a dependency. The first is a position. The second is a procurement decision wearing an architecture costume.

This is most load-bearing at the factory (Class 3). A Class 2 organization can rent a great deal and still be fine, because the human at the signal edge is the substrate. A factory has no human per run. Its substrate is the only thing holding it. An organization running factories on rented scaffolding it does not own or understand is running production on a dependency it cannot inspect, evaluate, or replace. The substrate question is optional at Class 2 and existential at Class 3.

The model still matters: the nuance that keeps this honest. None of this says the model is irrelevant or that models are interchangeable. The frontier model being the least defensible layer is not the claim that the model does not matter. Model selection stays a real engineering decision, and the axis that decides it is not the per-token price list. The unit is cost per solved task. Token consumption at equal accuracy varies by multiples across models, and the overthinking cost falls hardest on the weaker ones (OckBench, arXiv:2511.05722). A more capable model that solves a task in far fewer tokens can be cheaper per task than a cheaper-per-token model that pads it with reasoning it did not need. The operational move that follows: run the stronger model at reduced reasoning effort. Effort is a budget, not a quality dial to leave at maximum, and more reasoning is not more correctness past the point the task needs. Even model selection, the one piece that looks like pure procurement, is an engineering optimization once it is measured on the right unit. The procurement frame gets the wrong answer even on the question it was built for.

Benchmarks are a prior, not a verdict. The same discipline that turns model selection into engineering says what a published benchmark can and cannot tell you. A benchmark measures capability under fixed, artificial conditions. It does not measure fitness on the work the organization actually does. The aggregate score hides the failure distribution: a model that wins on average can lose on exactly the cases that matter to one task, and the leaderboard does not say which. Numbers also drift toward what is measured, because a benchmark widely optimized against stops separating the models that trained for it. And a vendor’s benchmark is evidence filtered through the incentive to sell. Treat any published number as a prior for shortlisting, never as a substitute for an eval shaped to the organization’s own task and measured on cost per solved task (Part I Section 12). The procurement officer who quotes a benchmark has answered a question the deployment never asked.

D.6 The transformation protocol: opt-in, self-selection, dark frame

Organizational AI rollout is usually framed as a training and adoption problem. The framing is wrong. The failure rate of AI rollouts argues that the framing is expensively wrong. AI competence is not a skill that can be installed by training. A craft discipline that requires self-selection, opt-in motivation, and sustained engagement with the messy reality of working with probabilistic tools. Rollout strategies that ignore this are buying compliance, not capability.

A more honest transformation protocol has a specific shape:

Triage before training. Before investing training budget, segment the existing workforce honestly. Some people are already self-driving toward AI competence and need autonomy more than training. Some are competent workers with high adaptive capacity who will benefit from focused support. Some are competent workers whose identity is too tied to manual craft to adapt without significant effort. Some are unlikely to make the transition at all. The mix is the input to the rollout strategy. Pretending the mix is uniform produces strategies optimized for nobody.

Opt-in by design. Capability development is a holschuld. Fetched, not delivered. The organization makes AI tooling, budget, experimentation time, and mentoring available. People who reach for it move forward. People who do not select themselves out of the transformation by inaction. Harsher than the standard adoption-program framing. Works substantially better, because it concentrates investment on those who will return it.

Self-selection over assignment. Pairing seniors with juniors, assigning experimentation projects, designating AI champions. All useful if the people involved chose the roles. All counterproductive if assigned to people who did not want them. The signal of who is suited for which role is in who reaches for what when given the option. The signal is reliable. Assignment overrides it.

Sandboxed experimentation. New capability development requires the freedom to fail without organizational consequence. Practitioners who can only experiment with AI on production-critical work will not experiment. They will use AI in the lowest-risk ways possible, which is also the lowest-leverage ways. Shadow projects, time-boxed experiments, and explicit „this does not need to ship“ framing are what make capability development possible.

Unlearning before learning. The largest barrier to AI competence is not the new skill. It is the old identity. Developers proud of their typing speed. Writers proud of their volume. Analysts proud of their coverage. All of them need to let go of the metric they used to optimize before they can engage with the metric that now matters. Psychological work, not technical work. The work most rollout strategies pretend is not happening.

Reward shifts. Compensation, recognition, and advancement structures continue to reward the visible activity that AI is automating. As long as they do, people will continue to optimize for it, regardless of what the rollout strategy says. The strategy is only as serious as the reward structure that backs it. An organization unwilling to change what it rewards is not transforming. It is buying tools.

Dark frame analysis. The optimistic rollout narrative (everyone benefits, productivity rises, work becomes more interesting) is the marketing version. The honest version: some people will not make the transition, some teams will lose productivity before gaining it, some skills will become obsolete and some careers will not survive the shift. The dark frame is not pessimism. The realism that lets the organization plan for the actual transformation rather than the marketing version. Rollouts that refuse the dark frame are surprised by every cost the dark frame would have anticipated.

Organizational AI transformation is more like a generational shift than a tool rollout. It happens at the speed of individuals‘ identity work, mediated by the organization’s willingness to support those doing the work and accept the loss of those who cannot. Strategies that treat this as a software-deployment problem will fail. Strategies that treat it as the human capability development problem it is can succeed, slowly, in ways that produce durable competence rather than impressive metrics.

D.7 The governance façade and how to spot it

A specific anti-pattern worth its own section because it is the most common failure mode of AI governance in organizations. The construction of industrial governance machinery around AI use that has not been industrially specified. The result is form without substance. Bureaucratic apparatus that consumes resources, produces audit trails, generates compliance artifacts, and does not actually govern anything.

The pattern is recognizable. The organization has AI usage policies. It has approval workflows. It has review boards. It has documentation requirements. It produces compliance reports. What it does not have is artifacts that specify what its AI deployments are actually supposed to do, against which the governance machinery could enforce something. The specifications live in conversations, in tool defaults, in undocumented assumptions, in the heads of the people who happen to be deploying the AI. The governance machinery validates that the workflows were followed. It cannot validate that the workflows produced anything worth validating, because the specification against which validation would happen does not exist as an artifact.

The pattern is dangerous because it consumes substantial organizational resources while protecting against very little. The compliance team is busy. The audit trail is comprehensive. The review board meets regularly. The procurement process is rigorous. None of this catches the actual failure modes. The AI deployment that solves the wrong problem. The verification model that does not measure anything important. The vendor lock-in that nobody noticed. The class mismatch that wastes budget for two years before failing visibly. The governance machinery operates at a different layer than the failure modes occur at.

How to spot the façade in one’s own organization:

The artifact test. Pick a load-bearing AI deployment. Ask for the specification it is operating against. If the answer is a slide deck, a chat history, a vendor’s documentation, or „it’s in [person]’s head,“ the specification is not load-bearing as an artifact. The governance around it is operating on substance the governance cannot see.

The change test. Pick a recent change to an AI deployment. Ask what specification artifact was updated as a result of the change. If the answer is none (the change happened in conversation, in configuration, in tooling), the specification is not the basis for change. The change happens around the artifact, not through it.

The handoff test. If the person currently operating an AI deployment left tomorrow, what would the next person need to be operationally equivalent. If the answer is „shadow [departing person] for three months,“ the operational knowledge is person-bound and not artifact-bound. The governance is theater. The substance is in heads.

The dependency test. Pick an AI-related decision the organization made in the last year. Trace what it depended on. If the dependency chain leads to „[person] said this would work“ rather than to a specification artifact with explicit reasoning, the decision was made conversationally and the governance was retrofit.

The remediation is not to expand the governance machinery. The remediation is to build the specification artifacts the governance was always supposed to enforce against. Hard, slow work. The work of extracting from conversations what should have been documented. Of turning person-bound operational knowledge into artifacts that survive personnel changes. Of producing the decision records that should have accompanied the original decisions. The work is unglamorous. It produces no new capability. It makes the existing capability defensible against personnel turnover, audit, and the next round of strategic decisions. Organizations rarely fund this work because it is invisible from the outside and uncomfortable from the inside. It surfaces how much was actually undocumented. The organizations that do fund it have governance that means something. The organizations that do not have façades.

D.8 Measuring adoption without measuring theater

The final managerial challenge worth its own section. Distinguishing AI adoption that is producing value from AI adoption that is producing the appearance of value. The two look similar from outside the team using the tools and feel very different from inside.

Standard adoption metrics measure activity. Number of users. Number of sessions. Number of prompts. Number of generated artifacts. These metrics measure whether the tools are being used. They do not measure whether the usage is producing the outcomes the deployment was supposed to produce. Most AI dashboards reach for these metrics because they are easy to collect and visually impressive. Few of them connect to substance.

Useful metrics (harder to collect, less impressive on a slide) measure outcomes:

Verification load. How much human review time goes into checking AI output. A successful Class 2 deployment should reduce the time required for the underlying work, including verification. If verification time has risen to match what the production time saved, the deployment is producing equivalent work, not more work. If verification time has stayed flat while AI output volume has risen, verification has gone nominal. The failure mode discussed in every previous chapter of Part II.

Downstream quality. What happens to the outputs after they leave the AI-assisted step. Are downstream consumers more or less satisfied. Are the artifacts being revised more or less by subsequent reviewers. Are the recommendations being acted on at higher or lower rates. These metrics exist but are rarely connected to AI adoption dashboards. The connection requires work and the result might be uncomfortable.

Iteration cycles. How many cycles does an AI-assisted artifact take to reach release-quality. If the answer is fewer than the manual baseline, the deployment is working. If the answer is more (because reviewers are catching more errors, or because the AI output requires substantial rework), the deployment is shifting cost from production to review without reducing total cost.

Error attribution. When errors occur in work that touched AI, are they attributable to AI failure modes or to other causes. A forensic discipline, not a metric. Requires actually examining the errors. An organization that systematically tracks AI-attributable errors learns where its deployment is producing value and where it is producing risk. An organization that does not track this is flying blind on the risk side.

Disengagement signals. Among the people using AI heavily, are signs of cognitive disengagement appearing. Decisions made faster but less consideredly. Recommendations grounded in summaries rather than sources. Code shipped without the engagement that catches subtle bugs. Articles published without the editorial judgment that distinguishes voice from output. Visible to the people working alongside the AI-using colleagues. Rarely surfaced in metrics.

Capability development. Are the people using AI becoming more capable over time (better judgment, better architecture, better arguments, better analysis) or are they becoming dependent on the tooling and losing capability they previously had. The longest-term metric and the hardest to measure. Also the one that most determines whether the AI investment is building organizational capability or hollowing it.

Useful AI metrics measure substance. They are connected to outcomes. They are inconvenient to collect. They sometimes produce uncomfortable answers. Standard adoption metrics measure activity, are connected to dashboards, are convenient to collect, and reliably produce comfortable answers. An organization that wants to know whether its AI investments are working has to pay the cost of the useful metrics. An organization that wants to feel like its AI investments are working can stay with the standard ones. The choice between knowing and not knowing. Most organizations choose not knowing by default because not knowing is institutionally cheaper than knowing in the short term.

D.9 Failure modes worth naming

A condensed inventory of failure modes specific to AI strategy and management.

The framing acceptance. Accepting the framing of an AI investment from the people advocating for it without independent interrogation. Mitigation: divergent grip on the framing before evaluating the investment.

The agreeable advisor. The divergent grip on a strategy (D.2) is the manager’s defense against framings supplied by people with an interest in the answer. A model tuned to agree (Part I Section 1) forfeits the defense: it takes the manager’s framing as readily as the vendor supplied it, validates the investment the manager was already leaning toward, and produces the failure-mode analysis the manager wanted rather than the one the decision needed. The interrogation meant to slow the decision down speeds it up with a coat of diligence. Mitigation: make the model argue against the investment, not for refining it; have it produce the case an outside skeptic would make; treat a divergent session that agreed with the framing it was handed as a session that interrogated nothing (Part I Section 8).

The class mismatch. Investing Class 3 budget in a Class 1 problem. Or Class 1 budget in a Class 2 capability gap. Or any other combination where the economics of the procurement do not match the economics of the problem. Mitigation: taxonomy as procurement filter (D.5).

The slide-deck strategy. AI strategy that reads as commitment and constrains no decision. Mitigation: write strategies that specify problems, classes, verification, capacity, exit criteria, and accountability owners (D.3).

The theater dashboard. Adoption metrics that measure activity without measuring outcomes. Mitigation: outcome metrics, even where inconvenient (D.8).

The verification gap. Strategic AI decisions whose outcomes will not be measurable for eighteen to thirty-six months and whose decision-makers will be evaluated on reception rather than results. Mitigation: pre-commit to verification specifics. Decouple verification from advocacy (D.4).

The displacement at scale. Organizational AI rollouts that produce displaced understanding (Chapter C), AI-default voice (Chapter B), or AI-default code (Chapter A) across many people simultaneously. Mitigation: capability development as transformation, not adoption (D.6). Useful metrics that catch displacement (D.8).

The vendor lock-in absorbed silently. Procurement decisions that produce ongoing dependencies whose switching costs the organization did not anticipate. Mitigation: reversibility check during procurement. Periodic re-evaluation of vendor relationships against alternatives.

The procurement disguise. Treating AI strategy as the question of which model or platform to buy, when the defensible layer is the substrate above the API seam (retrieval, tools, state, permissions, evals, observability, workflow control) that has to be built and owned. Or its second form: responding to „the substrate is the value“ by renting a managed substrate platform, which moves the lock-in one layer up rather than escaping it. Mitigation: read AI strategy as a software architecture problem, not a procurement exercise (D.5). Distinguish building and owning the substrate from renting scaffolding that behaves like a dependency. Treat the substrate question as existential at Class 3, where no human per run backs it up.

The governance façade. Industrial governance machinery around AI use that is not industrially specified. Mitigation: build the specification artifacts the governance was supposed to enforce against (D.7).

The pilot that never ends. AI deployments that are framed as pilots indefinitely, never converted to operational systems, and never properly evaluated. Mitigation: pilots have time-bounded scope, explicit success criteria, and a decision point at which they convert or terminate.

The transformation by mandate. Organizational AI rollouts that mandate adoption rather than supporting self-selection. Mitigation: opt-in transformation protocol (D.6). Reward structure aligned with the transformation, not just communications around it.

The metric collapse. Adopting an AI metric, watching it become the goal, and watching the underlying activity reshape itself to optimize for the metric at the cost of the outcome the metric was supposed to track. Mitigation: rotate metrics. Pair every quantitative metric with qualitative review. Expect Goodhart’s law to apply and plan for it.

The pattern across these failure modes is that AI in organizations is governed at the wrong level. The technical layer gets attention. The strategic layer gets slide decks. The gap between them is where the failure modes live. A manager who treats AI as a portfolio of strategic decisions to be made carefully, governed substantively, and evaluated honestly has a chance of producing organizational capability. A manager who treats AI as a category of vendor relationships to be optimized through standard procurement and adoption processes is buying the failure modes at the same price as the working systems.

The work this chapter has been describing (interrogating framings, writing strategies that constrain, building verification with feedback loops short enough to matter, applying the taxonomy as a filter, building capability rather than installing tools, refusing the governance façade, measuring substance) is the substrate of competent AI management. None of it is new. The work of strategic management applied to AI as a category of investment, with the specific complications AI brings. AI does not require new management disciplines. It requires the existing ones applied with unusual rigor against unusually strong pressures to skip them.

The manager’s value moves toward the part of the work that does not move. The visible activity (announcements, deployments, dashboards) is the surface. The judgment about which investments to make, which to refuse, and how to maintain organizational competence against the displacement pressures AI introduces is what remains. What remains is the value.

E. AI in Secure SDLC / Operations

This chapter is for the operator whose responsibility is what happens when AI runs in production. Site reliability engineers, security engineers, platform engineers, compliance and audit functions, and the operations side of any team running AI-enabled systems. The previous chapters described how to build, write, analyze, and decide with AI. This chapter describes what it takes to run AI safely, durably, and accountably once it is in operation. The work is mostly invisible from outside the operations team and load-bearing for everything else this guide has discussed.

If you operate AI, these are the surfaces you own. Eight of them, each detailed later in this chapter. Owning a surface means someone on the operations team can say what is on it, what can go wrong with it, and what holds the line. Where no one can, the surface is unowned, and unowned surfaces are where AI incidents come from.

The trigger. What starts each run, and the discipline around it: deduplication, idempotency, rate limits, a kill switch (E.2).
What gets in. Input validation and the boundary untrusted content crosses, which is the prompt-injection surface (E.2).
What a run can do. Side effects tiered by blast radius, from read-only to world-changing, each tier with its own gate (E.3).
What gets out. Filtering for leakage, PII, and unsafe content before anything leaves the system (E.4).
The drift. The maintenance surface: models, prompts, dependencies, and data all move underneath you, so a system that passed yesterday can fail today untouched (E.5).
The gates and handoffs. Deterministic containment at the architecture level: verdicts that get checked, artifacts carried between steps instead of summaries (E.6).
The evidence. Observability and an eval harness that is maintained, adversarial, and treated like production (E.7).
The incident path. What happens when the AI acts wrong, and the supply chain it pulled from: detection, containment, rollback, provenance (E.8, E.9).

The rest of the chapter is these eight in detail. If you take nothing else from it, take the list and the question it forces: who owns each one.

E.1 The operator’s reality: AI as a class of system, not a feature

The previous chapters all opened with a version of the same observation: value sits in judgment, not in the visible activity AI accelerates. The opening here is structurally different again. Operations does not produce a visible artifact at all. Operations produces the absence of incidents. The days when nothing went wrong. The audits that found nothing amiss. The customer interactions that proceeded smoothly. Visible operations is failing operations. The work that defines the role is the work nobody notices.

AI in production introduces a class of system with operational properties most engineering organizations have not encountered at scale before. Deterministic systems have loud failure modes operators know: crash, exception, stack trace, ticket. They have quiet ones too, the silent logic bug. What is different about AI is that the quiet failure is the characteristic one. They finish, they return something plausible, and they are simply wrong. Deterministic systems have predictable failure modes that operations teams have built playbooks against. AI systems have failure modes that are silent, longitudinal, statistical, and entangled with the data they process. The operations work that was sufficient for deterministic systems is structurally inadequate for AI systems. The gap is the operator’s problem to close.

The framing this chapter works with is direct. AI in production is not a feature of an existing system. A different kind of system, with its own maintenance surface, its own failure modes, its own governance requirements, and its own incident response patterns. Treating it as a feature (something the regular operations team handles as part of the regular operations workload) is the most common failure mode of AI operations. The source of most AI-related production incidents that make the news. The systems were built without operational specifications and operated without specialized operational discipline. They failed in characteristic ways that the operators were not equipped to detect, diagnose, or recover from.

This chapter is about the operational discipline that AI in production actually requires. Mostly engineering work, not data-science work. Mostly boring, in the sense that good operations is always boring. The leverage is high. The visibility, as always, is low.

E.2 Pre-flight: what gets in

The first stage of AI guardrails (established in Part I Section 11) controls what reaches the model. Operations is where pre-flight stops being a design decision and becomes a running discipline. The cheapest place to enforce a constraint is before the model sees the input. The operator’s job is to make sure that „cheapest place“ is actually where enforcement happens.

The pre-flight controls operations cares about:

Input filtering and classification. Every input to a production AI system passes through a filter that classifies it. Trusted (came from an authenticated internal source). Semi-trusted (came from an authenticated user with limited privileges). Untrusted (came from outside the organization or from a low-privilege source). The classification determines what the AI is allowed to do with the input. Treating all inputs as trusted is the design failure that makes prompt injection scale. The operator’s job is to ensure the classification actually runs on every input path. Including the ones the developers forgot to instrument.

PII detection and redaction. Inputs that contain personally identifiable information are detected, logged, and either redacted before reaching the model or routed to a model with the appropriate data handling. The detection is statistical and imperfect. The operations work is monitoring the false-positive and false-negative rates and adjusting the detection over time. PII flowing into models that should not have received it is the failure mode that produces regulatory consequences. The operator’s job is to make sure this does not happen silently.

Topic and intent filtering. Inputs are scanned for prohibited topics, prompt-injection patterns, and out-of-scope requests. The filtering catches the obvious cases. The operator’s job is to update it as new patterns emerge. Tracking what is being filtered, what is slipping through, and what is being blocked that should not have been.

Source-trust enforcement. Inputs that arrive through tool calls (retrieval results, document uploads, agent-fetched web content) are tagged with their source and treated according to the source’s trust level. Documents from authenticated internal systems are treated differently from documents fetched from the open web. The operator’s job is to make sure source tagging is reliable, source-trust policies are enforced consistently, and the system fails closed when source-trust cannot be determined.

Trigger discipline (Class 3). At Class 2 a human starts each run, so the trigger needs no engineering. At Class 3 the trigger is a machine event, and the trigger itself becomes infrastructure the operator owns (Part I Section 9). A trigger that fires wrong, fires twice, or fires a thousand times is a production incident with no human in the way. The controls: an eligibility gate (is this trigger allowed to start a run at all), debounce and deduplication (the same ticket comment must not spawn five runs), idempotency (a run that repeats must not double its effect), backpressure (what happens when three hundred events fire at once: queue, shed, or melt), replayability (can a past run be reproduced from its trigger and inputs for diagnosis), and a kill switch (one deliberate action that stops the factory). A factory without these is not automated. It is unsupervised, which is a different and worse thing. The operator owns the trigger surface as carefully as the model surface, because at Class 3 the trigger is where runs are born and where a runaway begins.

Rate limiting and quota enforcement. Inputs are throttled per source, per user, per session. The throttling protects against denial-of-service attacks, runaway costs, and individual users consuming disproportionate resources. The operator’s job is to set the quotas, monitor for quota exhaustion patterns that suggest attack rather than legitimate use, and adjust quotas as the system’s usage patterns evolve.

Pre-flight operations is mostly about maintaining filters and policies that the development team set up at deployment and that need ongoing attention to remain effective. The filters drift. New attack patterns emerge. Legitimate uses move outside the original quotas. The operator’s job is the ongoing tuning that keeps pre-flight effective. Without it, the pre-flight layer that looked solid at launch becomes a layer that the actual traffic routinely bypasses six months later.

E.3 Runtime: what can happen

The second stage of guardrails controls what the model is allowed to do during execution. Where the operations team’s work converges with the security team’s. Where most of the consequential failures happen when something goes wrong.

The runtime controls operations cares about:

Least privilege at the tool level. Every tool the AI can call has scoped permissions. Minimum necessary. Expiring credentials. Audit-logged usage. The AI cannot acquire new permissions during operation. The permissions it has at runtime are the permissions it was provisioned with. The operator’s job is to maintain the permission boundaries, detect privilege creep (tools that have accumulated permissions over time that they no longer need), and respond to anomalous tool usage patterns.

Sandboxing for risky operations. AI-generated code that gets executed runs in a sandbox. Containerized, resource-limited, network-restricted, ephemeral. The sandbox isolates whatever the code does from the production environment. The operator’s job is to maintain the sandbox infrastructure, monitor for sandbox escapes (rare but consequential when they happen), and ensure that sandboxes are actually being used for every code execution path. Not just the ones the original architecture documented.

Approval gates for sensitive actions. Certain categories of action (sending external communications, modifying production data, executing financial transactions, accessing customer records) pause for human approval rather than executing autonomously. The gates are enforced by the runtime, not by convention. The operator’s job is to ensure the gates are configured correctly, that the approval workflow is responsive enough not to become a bottleneck, and that approval bypasses are detected and investigated when they happen. Legitimate operational exceptions exist. Silent bypass is the failure mode.

Side-effect tiering. „Least privilege“ is not one line, it is a ladder, and every tool sits on a rung. Read-only: the tool can look and not touch, the safe default. Dry-run: the tool computes what it would do and returns it without doing it. Draft or preview: the tool produces a result that waits for release rather than taking effect. Reversible write: the tool changes state that can be rolled back. Irreversible write: the tool changes state that cannot. External side effect: the tool sends mail, moves money, deletes data, deploys, or publishes, and the effect leaves the system entirely. The rung sets the controls. The higher the rung, the more it demands: human approval, a transaction with rollback, an idempotency key so a retry does not fire twice, a rate limit, a tight permission scope, an audit artifact recording what was done. The operator’s job is to know which rung each tool is on and to refuse to let a tool on a high rung run with the controls of a low one. The most expensive AI incidents are a tool that was treated as reversible and was not.

State containment. When an AI system operates over multiple steps, state from one step is contained within the workflow and does not silently propagate to other workflows or other users. Particularly important when the AI is processing inputs that may contain prompt-injection attempts. A successful injection in one workflow must not affect other workflows. The operator’s job is to maintain the state isolation boundaries and detect when state is leaking across them.

Containment chain enforcement. For Class 3 systems, the architectural containment chain (the structures that prevent wrong actions from cascading across the orchestration) must actually run as designed. An aggregator that is supposed to require multiple verdicts before proceeding must in fact require them. An arbiter that is supposed to escalate on disagreement must escalate. A dispatcher that is supposed to route based on policy must enforce the policy. The operator’s job is to verify that the containment chain runs as designed and to detect drift between the deployed reality and the documented architecture.

Prompt-injection defense. The runtime defense against prompt injection is layered. Input classification (E.2). Tool permission scoping. Output validation (E.4). Behavioral monitoring for anomalous patterns. None of these are sufficient alone. The defense is the layered combination. The operator’s job is to maintain all layers and to track injection attempts as a category of incident. Frequency, success rate, evolution over time.

The runtime layer is where AI operations diverges most sharply from traditional operations. Traditional operations defends against component failures, network issues, and infrastructure problems. AI operations additionally defends against adversarial inputs designed to bend the system’s behavior, the system’s own probabilistic failures to act as instructed, and the cascading consequences of either. The defense requires both traditional operational discipline and a security mindset specifically adapted to systems whose components do not have stable, deterministic behavior.

E.4 Post-flight: what gets out

The third stage of guardrails controls what leaves the system. The last line of defense before AI output reaches users, downstream systems, or external endpoints. The layer most teams under-invest in relative to its importance.

The post-flight controls operations cares about:

Schema validation as hard reject. Outputs that are supposed to match a schema are validated against it before being released downstream. Malformed outputs are rejected and either retried or escalated. Not silently passed through. The operator’s job is to monitor the rejection rate. A rising rejection rate is a signal that the model’s behavior has drifted or that the upstream context has changed in ways that affect output structure.

Content policy enforcement. Outputs are checked against content policies before release. Prohibited topics. Unsafe recommendations. Regulated content categories. Brand guidelines for organizational outputs. The enforcement is imperfect and statistical. The operator’s job is to monitor what is being blocked and what is slipping through, and to maintain the policies as new categories of concern emerge.

Fact-check against sources. For outputs that cite sources (RAG-based answers, research syntheses, document-grounded responses), the cited claims are checked against the cited sources. Citations that point to sources not containing the cited claim are flagged. Expensive and imperfect. The operator’s job is to decide where the cost is worth paying (high-stakes outputs, regulated domains) and where it is not (low-stakes informational outputs), and to maintain the fact-check infrastructure for the cases where it runs.

PII leakage detection. Outputs are scanned for PII that should not appear in them. Particular attention to inputs that contained PII in early conversation turns and might be referenced later. PII detection in outputs catches the cases where pre-flight redaction missed something and the model is now reproducing redacted content from memory or context. The operator’s job is to monitor for PII in outputs and to investigate every instance.

Style and voice gates. For organizational outputs (customer communications, marketing content, support responses), outputs are checked against organizational style guides before release. Outputs that fail the style check are either revised or routed for human review. The operator’s job is to maintain the style gates as the organization’s voice and policies evolve.

Compliance filtering. Outputs are checked against compliance requirements that apply to the output’s destination. GDPR for European recipients. HIPAA for health-related contexts. Financial-services regulations for relevant outputs. The compliance layer’s job is to ensure outputs that would violate applicable rules are blocked, modified, or escalated. The operator’s job is to maintain the compliance rules as regulations evolve and to ensure the rules are actually applied to every relevant output path.

Audit log generation. Every output is logged with sufficient context to reconstruct what produced it. The input. The model version. The tools called. The timing. The retrieval used. The final output. The audit log is the artifact that makes post-incident analysis possible. Without it, an investigation into „what produced this wrong output“ has no starting point. The operator’s job is to ensure audit logging is complete, immutable, retained for the required period, and queryable for incident response.

Post-flight operations is the layer where the consequences of upstream failures become visible (or remain invisible). A failure that slipped through pre-flight and runtime can still be caught at post-flight if the post-flight controls are good enough. A failure that gets past post-flight reaches its destination and creates an incident. The operator’s investment in post-flight controls is proportional to the cost of failures reaching the destination. That cost is usually substantially higher than the operator’s investment reflects.

E.5 Drift and the maintenance surface

The operational property of AI systems that most distinguishes them from deterministic systems is drift. A deterministic system that worked yesterday will work today unless something explicitly changed. An AI system that worked yesterday may not work today even if nothing visibly changed. The inputs it sees have shifted. Or the patterns in those inputs have shifted. Or the world the inputs describe has shifted. Or the model itself has been updated by its vendor. Drift is silent, longitudinal, and continuous. Detecting it is one of the central operational challenges.

The categories of drift the operator monitors:

Input distribution drift. The shape of the inputs the system processes changes over time. New types of requests appear. Old types fade. The mix shifts. Models trained or tuned on historical data perform differently on the shifted distribution, often worse. The operator’s job is to detect input distribution shifts and trigger appropriate responses. Retraining. Prompt updates. Capability scope changes. Escalation to human review for the shifted categories.

Output quality drift. The quality of the system’s outputs degrades over time even on inputs that look similar to historical inputs. May be caused by model updates (the vendor changed something). By upstream retrieval drift (the retrieved material is less relevant than it was). By prompt drift (the prompt that worked at deployment no longer works as effectively). By adversarial adaptation (users have learned to phrase requests in ways that exploit weaknesses). The operator’s job is to detect output quality drift through eval runs over time and to investigate the cause when it appears.

Tool behavior drift. The tools the AI calls change behavior over time as the systems they wrap evolve. APIs add fields, deprecate endpoints, change rate limits, modify response formats. The AI’s calls that worked at deployment may produce different results now. The operator’s job is to monitor tool call success rates and response patterns, and to update the tool definitions and the AI’s understanding of them as the underlying systems change.

Cost drift. The economic profile of the AI deployment shifts over time. Token consumption per request grows as context windows fill with accumulated state. Retrieval becomes more expensive as the indexed corpus grows. Model calls migrate to more expensive tiers as the team upgrades for quality reasons. Usage patterns shift toward higher-cost operations. The operator’s job is to monitor cost drift and surface it to budget owners before it becomes a budget incident.

Compliance drift. The regulatory environment shifts. New rules apply. Old rules are interpreted differently. Court decisions change what is required. The deployment that was compliant at launch may not be compliant a year later, even if nothing about it has changed. The operator’s job is to track regulatory developments relevant to the deployment and trigger compliance review when they affect the system’s obligations.

Adversarial drift. The attack landscape evolves. New prompt-injection patterns emerge. New exfiltration techniques appear. New ways to extract training data are discovered. The defenses that were adequate at deployment become inadequate as attacks adapt. The operator’s job is to track the adversarial landscape and update defenses ahead of widespread exploitation.

Drift is the dominant long-term operational concern for AI systems. Detecting it requires investment that traditional operations did not need to make. The investment includes eval harnesses that run continuously (E.7), monitoring infrastructure that captures the right signals, and human capacity to investigate when signals appear. Organizations that deploy AI without this investment are not running deployments. They are running deployments that will silently fail at some point in the next eighteen months, and the failure will be diagnosed only after the consequences accumulate.

The maintenance surface of an AI deployment is not bounded. It is continuous. Treating it as one-time engineering followed by light operational supervision is the most common cause of AI deployments that look successful at launch and fail invisibly over their first two years of operation.

E.6 Containment patterns at architecture level

Operations does not just run guardrails on individual requests. It depends on architectural containment patterns that limit the radius of effect when something goes wrong. The patterns are designed at build time and enforced at operate time. The operator’s understanding of the architecture is what makes incident response possible.

The architectural patterns operations cares about:

The verdict-and-arbiter pattern. In multi-agent or multi-step systems, no single agent’s verdict commits the system to action. Multiple agents produce verdicts. An aggregator synthesizes them. A meta-observer (arbiter) checks for oscillation or escalation conditions. Only then does the system proceed. The pattern contains failure modes in which a single agent goes wrong. Its wrong output is one input to the aggregator, not the system’s commitment. The operator’s job is to ensure the pattern actually runs (the aggregator is not being bypassed for „trivial“ cases; the arbiter is escalating when it should), and to monitor for patterns that suggest the containment is failing (oscillations, escalations, unusual aggregation outcomes).

The dispatcher pattern. A central component routes work to specialized handlers and is the only place where routing decisions are made. The pattern contains failure modes in which one agent attempts to call another directly, bypassing the policy layer that the dispatcher enforces. The operator’s job is to ensure direct agent-to-agent calls are not happening. An architecture verification, but it has an operational dimension: detecting such calls in logs and tracing how they arose.

The artifact-handoff pattern. When one agent’s output becomes another agent’s input, the handoff has to transfer an artifact, not a conversation. An artifact has an input contract, an output contract, acceptance criteria, and the evidence that it met them: a requirement brief, a plan, a test spec, a diff, a review finding, an evidence pack. A summary passed agent to agent is not a handoff. It is a rumor, and the receiving agent builds on it as if it were verified fact. The pattern contains the failure mode where wrongness laundered through a plausible summary propagates down a chain with no point at which it was checked. The operator’s job is to verify that handoffs actually carry artifacts with acceptance criteria, and to treat chat-to-chat handoffs between agents as the smell of a system that is improvising rather than engineered.

The policy guardian pattern. Certain actions or output categories must pass a dedicated policy check before execution. The check is separate from the agents that proposed the action. The agents cannot override the policy. The operator’s job is to maintain the policy rules, monitor for policy violations (both attempted and successful), and ensure that policy bypass paths do not develop over time as developers seek to work around what they perceive as friction.

The session isolation pattern. Each user’s session, or each pipeline run, operates in an isolated context that cannot read or write the state of other sessions. The pattern contains failure modes in which a prompt injection in one session bleeds into another, or in which one user’s data is exposed to another user. The operator’s job is to verify session isolation and to detect cross-session contamination if it occurs.

The fail-closed pattern. When any guardrail component (the arbiter, the policy check, the validation) encounters an error or cannot reach a decision, the default behavior is to escalate or block rather than to proceed. The pattern contains failure modes in which a broken safety component silently fails to block what it was supposed to block. The operator’s job is to monitor for failure-component incidents and to ensure that fail-closed defaults are not being overridden under operational pressure.

The audit-everything pattern. Every action the AI system takes, every input it processes, every output it produces, every tool it calls, every decision the containment layer makes. All of it is logged in a form that supports post-incident reconstruction. The pattern is foundational. Without it, incident response is forensic guesswork. The operator’s job is to ensure audit completeness, retention, and queryability (E.7 expands on this).

These patterns are not exotic. The patterns competent multi-component system design has used for decades, adapted to AI’s specific failure modes. What makes them load-bearing for AI is that the components being contained are probabilistic. Any individual component will produce wrong outputs sometimes. The architecture has to absorb those wrong outputs without letting them cascade. The operations team’s job is to keep the architecture actually doing what it was designed to do. Against the constant operational pressure to take shortcuts that work in the happy path and fail catastrophically in the unhappy path.

E.7 Observability and the eval harness

The observability layer for AI systems is the foundation everything else in this chapter depends on. Without it, the operator is operating blind. Drift cannot be detected. Incidents cannot be diagnosed. Compliance cannot be demonstrated. Evals cannot be run. With it, all of these become possible. The investment in observability is not a nice-to-have. The precondition for serious AI operations.

The observability components operations cares about:

Full request tracing. Every AI system interaction is logged with the complete trace. Input received. Classification applied. Retrieval performed (with results). Prompts assembled (with versions). Models called (with versions). Tools invoked (with arguments and results). Outputs produced. Validations applied. Final disposition. The trace is what makes post-incident analysis possible. An incident with an incomplete trace is an incident the team cannot fully understand.

Trace privacy. The trace that makes diagnosis possible is also a concentration of sensitive data. It holds prompts, customer records, code, documents, credentials, tool results, and personal information, all in one queryable place. Observability built without privacy is a second data leak constructed in the name of control. The controls the trace store needs: redaction of sensitive fields, secret scrubbing before storage, sampling rather than retaining everything, a retention policy with an actual expiry, access control on who can read traces, and an audit of trace access itself. The operator’s job is to treat the observability store as a regulated data asset, because it is one, and to resist the instinct to log everything in the clear because it is convenient for debugging.

Cost telemetry. Per-request cost, broken down by component. Input tokens. Output tokens. Retrieval queries. Tool calls. Downstream system costs. Aggregated by time, by user, by request type, by department. The telemetry is what makes cost management possible. Without it, the monthly bill arrives as a surprise and the question of „which use case is consuming the budget“ cannot be answered.

Latency telemetry. Per-component latency, with breakdowns sufficient to identify which component in a chain is responsible for any given slowness. The telemetry is what makes performance optimization possible and what catches performance regressions before they become customer-visible.

Error and failure telemetry. Categorized failures. Hard errors (the system crashed). Soft errors (the system produced a malformed output that was rejected). Policy blocks (the system produced something that policy rejected). Tool failures (an external system did not respond as expected). Validation failures (output did not match schema). Each category is tracked independently because each has different operational implications.

Quality telemetry. Where measurable, quality of outputs is tracked over time. Human satisfaction scores. Downstream conversion rates. Override rates by reviewers. Complaints. Escalations. Quality telemetry is harder to instrument than the others but more important for detecting drift.

The eval harness. A separate, continuously-running system that tests the AI system against a curated set of representative cases, including known edge cases and known failure modes. The harness runs on a schedule, produces measurable metrics, and is the primary instrument for detecting quality drift. The operator’s job is to maintain the eval harness. Keeping the test cases representative of current usage. Adding cases as new failure modes emerge. Treating regressions in eval performance as production incidents.

The eval harness deserves specific attention. The most underinvested component of AI observability and the most important. Many AI deployments have rich observability for the operational layers (latency, cost, error rates) and almost no observability for the layer that actually matters: whether the system is producing correct outputs. The result is operations teams that know exactly how fast the system is failing to do its job. The eval harness closes this gap. Without it, quality is invisible until customers notice. Which is too late.

A specific note on eval harness construction. The harness should not be built by the team that built the AI system. The temptation to build evals against cases the system handles well is overwhelming. The result is evals that confirm the system’s competence rather than testing it. Evals built by an independent team (preferably the operations team itself, or a dedicated quality function) are the only evals that produce reliable signal.

Not all evals measure the same thing. „Run the evals“ hides a taxonomy, and a harness that runs only one kind is blind to the others. Regression evals ask whether a change made it worse. A golden set fixes representative cases the system must always handle. Adversarial evals throw prompt injection, edge cases, and malicious documents at it on purpose. Cost evals track price per solved task, not per token (Part I Section 4). Latency evals ask whether it is still fast enough to use. Human evals cover the cases where only judgment can score the output. Trace replay runs old recorded runs against a new prompt or model to see what moved before the change ships. Online monitoring watches the live system for drift the offline sets did not predict. Each answers a different question. A deployment that measures only accuracy on a golden set knows nothing about its cost curve, its adversarial exposure, or its live drift.

E.8 Incident response when AI acts wrong

The operations function that most distinguishes mature AI operations from immature is incident response. When an AI system produces a wrong action, takes an inappropriate decision, leaks information it should not have, or otherwise misbehaves in production, the team’s response determines whether the incident remains an incident or escalates into a crisis.

The incident response components specific to AI operations:

Detection. The first task is detecting that an incident has occurred. AI incidents are rarely self-announcing in the way deterministic system failures are. They tend to surface through user complaints, downstream metric anomalies, audit reviews, or pattern recognition by operators who notice something odd. The detection layer is the observability infrastructure (E.7) combined with the human judgment to escalate when something looks wrong. The operator’s job is to maintain both. The infrastructure that surfaces signals. The team capacity to act on signals.

Containment. When an incident is suspected, the first action is containment. Limiting the scope of what is going wrong while diagnosis proceeds. Containment for AI incidents may include disabling the affected system, switching to a fallback (deterministic alternative, human handling, simpler system), pausing the relevant workflow categories, or restricting access until the issue is understood. The operator’s job is to have predefined containment options for each category of AI system and to use them without waiting for full diagnosis.

Diagnosis. The forensic work of understanding what produced the wrong output. The audit log (E.4) is the primary input. The trace through it identifies which input, which model version, which tool calls, which validations either ran or failed to run. AI diagnosis is structurally different from deterministic diagnosis. The question is not „what bug in the code caused this“ but „what combination of input, context, model behavior, and validation produced this output, and how often does the combination occur.“ The operator’s job is to perform this diagnosis with sufficient rigor to inform the remediation, even when the diagnosis is uncomfortable. Sometimes there is no specific bug. The system simply produced a wrong output that the validations did not catch.

Remediation. Fixing what produced the incident. The remediation depends on the diagnosis. A prompt update. A validation improvement. A tool permission tightening. A model version pin or rollback. A content policy update. A guardrail addition. A containment chain modification. Or a process change in how the system is operated. The operator’s job is to apply the remediation and verify that it actually addresses the root cause. Not just the immediate symptom.

Communication. Stakeholders need to know what happened, what was affected, and what was done about it. For AI incidents, this is more sensitive than for deterministic incidents. Users and regulators are paying particular attention to AI failures. Honest communication that names what went wrong is essential. Communication that obfuscates or minimizes can produce regulatory and reputational consequences disproportionate to the technical incident. The operator’s job is to participate in incident communication in a way that supports honest disclosure.

Post-mortem. After the incident is resolved, the team analyzes how it happened, why the existing controls did not catch it, and what changes prevent recurrence. The post-mortem is the artifact that turns an incident into organizational learning. For AI incidents, the post-mortem often surfaces gaps in the eval harness (the failure mode was not represented in the evals), gaps in the guardrail layers (the failure passed through controls that should have caught it), or gaps in the operational discipline (the response was slower or less effective than it could have been). The operator’s job is to produce the post-mortem and to ensure the changes it identifies are actually implemented.

The blameless discipline. AI incidents have a specific blame-allocation temptation: the AI did it. The temptation is misleading. The AI is a component of a system designed, deployed, and operated by humans. The AI producing a wrong output is the system’s failure, not the AI’s. The operator’s job is to maintain the blameless framing in post-mortems so that the actual causes (insufficient guardrails, gaps in monitoring, inadequate eval coverage, hasty deployment) are surfaced and addressed. Rather than being absorbed under „the AI hallucinated.“

AI incident response combines traditional operational discipline (detection, containment, diagnosis, remediation, communication) with the specific forensic patterns AI systems require. More demanding than deterministic incident response. The failure modes are subtler. The causal chains are murkier. The stakeholder attention is higher. Teams that do not develop this capability before they need it will develop it during their first major AI incident. Under maximum operational pressure. While customers and regulators are watching.

E.9 Open source as the AI-amplified supply chain

Most production software in most organizations runs on open source. This is not news. What is news is what AI does to the substrate that supports it.

The substrate is larger than people remember. Package managers and the packages they pull. Transitive dependencies several layers deep. Build tools, container base images, linters, formatters, framework cores, CI runners, test libraries, key cryptographic primitives. The code an organization ships sits on top of a tower whose maintainers it has mostly never met and never paid. Organizations that think of this as „external“ code „out there“ are wrong. It is part of the production system. The fact that nobody at the organization wrote it does not change where it runs.

The trust model holding this substrate together is informal. Maintainers and small groups of contributors review pull requests, triage issues, judge whether a vulnerability report is real, decide what gets into a release. The work is volunteer or near-volunteer in most cases. The attention of these people is part of the security boundary of every system downstream of them. A maintainer reading a PR is not doing project hygiene. They are running the last layer of trust between an unknown contributor and the production systems of every consumer of that package.

That trust model was already strained before AI. Maintainers burn out. Critical projects run on the bandwidth of one or two people. The bus factor on packages with millions of weekly installs is sometimes one. AI changes the pressure on this arrangement in ways that are structural rather than incidental.

The asymmetry that matters.

AI makes generation cheap. It does not make semantic review cheap at the same rate. A contributor with AI assistance can produce a plausible pull request in minutes. The maintainer who has to decide whether to merge it has not gotten any faster. They still need to read the change, understand its consequences, check it against the project’s invariants, verify it does not introduce a security regression, and accept responsibility for it once it ships under their name.

This is the verification problem from Part I Section 12, applied to a context where the verifier is unpaid and the input volume is now bounded by the cost of generation rather than the cost of contribution. The contribution side has compressed by an order of magnitude. The review side has not.

The trust signals weaken.

Open source trust has historically rested on signals that AI can now simulate. Apparent technical fluency. Persistent presence in a project. Helpful answers in issues. Patches that look thoughtful. A commit history that suggests competence. None of these were ever proof, but in aggregate they used to be cheap heuristics for distinguishing serious contributors from drive-by noise.

AI does not invalidate every one of these signals. It does mean the cost of producing them has collapsed. A long-running contributor persona, plausible enough to pass casual inspection, is now a feasible thing to construct. The signal that someone has invested time and skill in a project is no longer the same evidence it was.

This does not make every AI-assisted contribution suspicious. It means contribution itself is a weaker trust signal than maintainers may still be implicitly weighting it as.

The risk surface is wider than backdoors.

Discussions of open-source security under AI pressure default to the headline case: someone slips a backdoor into a critical dependency. That risk is real. It is also one risk among several, and not necessarily the most common one.

The fuller inventory:

Maintainer denial-of-service. Volume of AI-generated issues, PRs, and „helpful“ comments exhausts maintainer attention. Projects slow down or stop accepting contributions. Real bugs go unfixed because the queue is full of plausible noise.
Vulnerability-report flooding. Bug bounty programs and security-disclosure channels receive AI-generated reports at scale. Most are wrong but plausible enough to require investigation. The signal-to-noise on real reports collapses.
Plausible but wrong pull requests. Code that compiles, passes existing tests, and is subtly wrong about an invariant the test suite did not happen to cover. Merging accumulates landmines.
Malicious changes hidden in useful ones. A PR that does a real, requested thing and also does one quiet thing the maintainer did not notice. The useful change is the cover.
Test poisoning. Changes to test code that look like coverage improvements and actually weaken what the tests check.
Trust farming. Contributor accounts that build up a track record of small, real, helpful contributions over months in order to be trusted with a larger change later.
Dependency confusion and package poisoning. Malicious packages with names close to legitimate ones, or compromised versions of legitimate packages, propagated downstream before detection.
AI-review laundering. „An AI looked at it“ used as a substitute for actual human review on either side. The contributor’s AI wrote it. The maintainer’s AI checked it. No human held responsibility at any point. The audit trail looks complete.

Some of these are old problems with new volume. Some are new shapes the old defenses were not built against. None of them are solved by better intentions.

Class drift in the supply chain.

The taxonomy from Part I sorts these clearly. From the consuming organization’s perspective, an open-source dependency is Class 1: an embedded component inside a larger system, doing a bounded job, mostly invisibly. The maintainer’s own work on the package is Class 2: a human practitioner using tools, reviewing artifacts, deciding what merges and what does not. Automated dependency scanners, update bots, AI-assisted triage tools, and remediation pipelines move parts of the picture toward Class 3.

The danger is the same class drift Section A.7 named in a different form. The system acquires Class 3 contribution volume on the input side. It retains Class 1 blast radius on the output side, because a compromised dependency reaches every downstream consumer. The human review capacity holding the middle together is still Class 2, still bounded by attention, still mostly unpaid.

A Class 3 input pipe pointed at a Class 2 review capacity, with a Class 1 fallout pattern, is not a stable arrangement. It is the arrangement we currently have.

Countermeasures, none of them sufficient alone.

The defense is the layered combination, not any single layer.

Cryptographic provenance does part of the work. Signed commits and signed releases. SLSA-style build provenance. Reproducible builds where the language ecosystem supports them. None of these prevent a compromised maintainer or a malicious change accepted in good faith. They make tampering after the fact harder to hide.

SBOMs and VEX data are useful as operational inputs rather than compliance paperwork. The question they answer is „what is actually in our system and what is currently known to be wrong with it.“ Treated as artifacts the organization queries during incident response, they are load-bearing. Treated as documents produced for audits and never read, they are theater.

Dependency hygiene at the consumer side. Pinning versions. Internal artifact registries that proxy public ones and add review. Update policies that vary by criticality (a TLS library gets different treatment than a logging helper). Mandatory human review for changes to release-critical dependencies. Separation between contributor trust and release authority, so that earning the right to land code is not the same as earning the right to ship a release.

At the maintainer side. Explicit policies for AI-generated PRs and AI-generated vulnerability reports. Rate limits on contribution channels. Clear escalation for suspected coordinated submissions. None of this is glamorous and most of it is unpaid.

At the downstream organization side. Funding, review capacity, or maintenance effort contributed back to critical dependencies. Organizations that depend on a package for production are in a position to support the maintainer who reviews changes to it. Most do not.

AI-assisted triage on either side can be real support, but only when it routes work for human decision rather than substituting for the decision. The AI flags candidates. A human signs the release.

None of these prevent the failure modes alone. Together they raise the cost of compromise and shorten the window in which an undetected change can spread. The realistic goal. Eliminating the risk is not on the table.

The management connection.

Organizations that consume open source without funding, verifying, or governing their dependency substrate are outsourcing critical infrastructure to exhausted strangers. AI makes that bargain harder to defend. The maintainer whose attention secured the trust model is now competing with a generation engine that produces plausible contributions faster than they can read them. The downstream organization that pays nothing toward the maintenance of that attention is consuming a service whose underlying labor is being attacked at scale.

This is procurement (Chapter D), and it is rarely treated as procurement. The dependency tree is a vendor relationship the organization did not negotiate, does not pay for, and cannot replace. AI does not create that arrangement. It raises the cost of pretending it is not one.

E.10 Failure modes worth naming

A condensed inventory of failure modes specific to AI operations.

The unmonitored deployment. AI system deployed without sufficient observability to detect when it stops working correctly. Mitigation: observability and eval harness as deployment prerequisites, not afterthoughts.

The drift accumulator. Drift in inputs, outputs, tools, costs, or compliance accumulates silently until consequences are too large to ignore. Mitigation: ongoing drift monitoring as a defined operational activity, not a periodic project.

The bypassed guardrail. A guardrail layer that was operational at launch becomes routinely bypassed for „operational reasons“ (urgent fixes, exceptional cases, development convenience). The bypasses become the norm. The guardrail is effectively absent. Mitigation: monitor for bypass patterns. Treat bypasses as exceptions requiring justification, not as routine. Investigate every persistent bypass.

The phantom containment chain. A containment architecture (aggregator/dispatcher/arbiter or similar) exists in documentation but does not actually run as documented in production. Mitigation: periodic architectural verification. Does the deployed system actually behave as the architecture diagram says.

The unmaintained eval. Eval harness exists but has not been updated since deployment. The cases it tests no longer represent current usage. It produces a passing grade that means nothing. Mitigation: eval maintenance as a defined recurring activity. Treat eval regressions as production incidents.

The agreeable reviewer. A guardrail, eval, or arbiter that uses one model to judge another’s output inherits the agreement bias (Part I Section 1, Section 12). A model asked whether another model’s output looks correct leans toward yes, more so when the two share training lineage. The arbiter meant to catch the wrong verdict ratifies it. The eval meant to fail the bad output passes it. Mitigation: model-based checks are weak gates, not strong ones; use deterministic validation wherever the property is actually checkable; build adversarial evals through an independent function (E.7); never let „a model reviewed it“ stand in for a gate that has to hold.

The compliance retrofit. AI deployment ships without adequate compliance design. Compliance is bolted on afterward, with gaps that surface during audit or after a regulatory inquiry. Mitigation: compliance review as a prerequisite for deployment, not an afterthought.

The silent leak. AI system processes inputs containing data that should not have been exposed (PII, confidential information, regulated content). The data appears in outputs, in training data, in logs, in vendor systems. The leak is not detected until external notification. Mitigation: rigorous data flow analysis at design. PII detection at pre-flight and post-flight. Vendor data handling agreements reviewed and tested.

The injection epidemic. Prompt injection attacks proliferate as users discover the system’s susceptibility. Defenses lag the attack patterns. The system’s behavior becomes substantially controlled by adversarial inputs over time. Mitigation: active monitoring of injection attempts. Rapid response to new patterns. Defense-in-depth across all guardrail layers.

The runaway trigger. A Class 3 trigger fires wrong, fires twice, or fires a thousand times, spawning runs no human authorized. Mitigation: trigger discipline (E.2). Eligibility gate, debounce and deduplication, idempotency, backpressure, replayability, and a kill switch that actually stops the factory.

The mistiered tool. A tool with an irreversible or external side effect runs with the controls of a read-only one. The retry that double-charges. The delete with no rollback. Mitigation: side-effect tiering (E.3). Match approval, transaction, idempotency key, rate limit, and audit to the tool’s rung.

The rumor handoff. Agents pass summaries instead of artifacts, and wrongness laundered through a plausible summary propagates down a chain nobody checked. Mitigation: artifact-handoff pattern (E.6). Handoffs carry artifacts with input and output contracts, acceptance criteria, and evidence.

The unredacted trace. Observability captures prompts, credentials, and personal data with no redaction, retention limit, or access control, becoming the next data leak in the name of control. Mitigation: trace privacy (E.7). Redaction, secret scrubbing, retention expiry, access control, and an audit of trace access.

The crisis communication failure. An AI incident produces customer or regulatory attention. The team’s communication is defensive, dismissive, or obfuscatory. The communication failure produces more consequences than the technical incident did. Mitigation: incident communication discipline established before the first major incident. Honest disclosure as the default. Legal and PR alignment on the disclosure framework in advance.

The unbudgeted maintenance. AI deployment is approved and funded for development and launch. Ongoing maintenance is not budgeted or staffed adequately. The deployment slowly degrades over its first two years. Mitigation: maintenance budget and staffing as a deployment prerequisite. Explicit ownership of the deployment as an ongoing operational responsibility.

The blame absorption. When AI incidents occur, „the AI hallucinated“ or „the model made a mistake“ is treated as sufficient causal attribution. The actual operational gaps that allowed the incident are not surfaced or addressed. Mitigation: blameless post-mortem discipline. The AI is a component, not an agent that can be blamed. The question is always what about the system allowed this to happen.

The class drift. A deployment that started as Class 1 (embedded component) accumulates capabilities and becomes Class 2 or Class 3 without the operational discipline appropriate to its new class. The maintenance surface grows. The failure modes change. The existing operational practice is no longer adequate. Mitigation: periodic re-classification of deployments. Operational practice adjusted when class changes.

The pattern across these failure modes is that AI operations is structurally underinvested relative to its actual demands. The build cost of an AI deployment is visible and budgeted. The operational cost is continuous, invisible until it fails, and consistently underestimated at deployment time. Organizations that treat AI as a project to be built and then operated within existing operational practice will find that the operational practice does not actually cover what AI deployments need. The gap surfaces as incidents, regulatory consequences, customer complaints, and silent quality degradation over time.

The work this chapter has been describing (pre-flight discipline, runtime containment, post-flight enforcement, drift monitoring, architectural containment patterns, observability and eval harnesses, incident response capable of handling AI-specific failure modes) is the substrate of AI in production. None of it is exotic. Operations engineering and security engineering applied with the specific adaptations AI’s probabilistic nature requires. AI does not require new operational disciplines. It requires the existing ones applied with more rigor, more humility about failure modes, and more investment than most organizations initially budget for.

The operator’s value is the absence of incidents. The visible activity (dashboards, alerts, responses) is the surface. The judgment about what to monitor, what to contain, what to enforce, what to investigate, and when to escalate is what remains. What remains is the value. The work is mostly invisible until it fails. The discipline of making it not fail is what defines mature AI operations and what determines whether the rest of this guide’s work (the development, the writing, the analysis, the management) actually survives contact with production reality.

Christian Albert 2026

Mein Profil

Dein Profil

Christian Albert Photography

Part II: Applied Playbooks (The AI Ecosystem)