DEV Community: Fabian Cooper

You Can't Move Fast Here: Shipping AI Inside Regulated Walls

Fabian Cooper — Wed, 11 Nov 2026 10:09:18 +0000

Most advice about building with AI is written for a world that does not apply to banks, hospitals, insurers, or anyone who answers to a regulator. The advice says move fast, ship the rough version, learn from real users, iterate in production. Inside a regulated estate, that advice is not just wrong, it is the fastest route to a fine, a halted rollout, or a regulator who now reads everything you ship twice.

The instinct this breaks is the one every good AI team has been trained to trust. In an unregulated product, speed is the dominant strategy: the team that ships and learns beats the team that deliberates. In a regulated estate, the cost of being wrong in production is not a bad week, it is a reportable event, a customer who was treated unfairly, a decision you cannot explain to an examiner. The arithmetic of speed inverts, and most teams do not notice until they have already built the thing the wrong way.

This is not an argument for doing less with AI in regulated industries. It is an argument that the hard part is different, and the teams that win are the ones that understood the difference before they started building rather than after their first audit.

The rule that breaks the playbook

The standard AI playbook rests on a quiet assumption: that you can put an imperfect system in front of real users, watch what happens, and improve it. That assumption is what regulation removes. A lending model that is right most of the time is not a promising first version, it is a system that treats some real applicants unfairly on days you cannot predict, and in a regulated estate that is the thing the rules exist to prevent.

So the loop that makes AI teams fast, ship, observe, correct, is exactly the loop a regulator will not let you run on live customers. You cannot learn your fairness properties from production incidents. You cannot discover your failure modes by letting them happen to people who have legal protections. The learning has to move upstream, before deployment, into evidence you can produce on demand, and that single shift reshapes everything about how the work is sequenced.

The teams that struggle are the ones that treat compliance as a gate at the end: build the model the usual way, then hand it to a risk function to bless. The risk function cannot bless what it cannot inspect, the model was never built to be inspected, and the project stalls in a standoff that burns months. The teams that move are the ones that built the evidence as they built the system, because they understood from the first week that in a regulated estate the model and its justification are the same deliverable.

Why regulated is a different kind of hard

It helps to be precise about what regulation actually demands, because the word covers several different constraints that are easy to blur together.

The first is explainability: for certain decisions, you must be able to say why, in terms a human can understand and a customer can challenge. The second is fairness: you must be able to show the system does not discriminate against protected groups, and show it with evidence, not assurances. The third is auditability: you must be able to reconstruct, after the fact, exactly what the system did and why, for any individual decision, sometimes years later. The fourth is accountability: a named human must own the model's behaviour, which means that human needs to genuinely understand it, not just sign for it. And the fifth is often data residency and control: where the data lives, who can see it, and what can be sent to a third party, including the provider of a model you are renting.

Each of these is a design constraint that must be present from the start, because none of them can be bolted on afterwards. You cannot make an unexplainable model explainable by adding a report. You cannot make an unauditable system auditable by writing documentation about it later. The constraint has to live in the architecture, and architecture is the one thing that is expensive to change once the system exists. That is why regulated AI is not normal AI plus paperwork. It is a different engineering problem whose hardest requirements are fixed before the first model is trained.

Explainability is a product requirement, not a nice-to-have

In most AI products, explainability is a feature you might add for user trust. In a regulated estate, it is frequently a legal requirement, and that changes which systems you are even allowed to build.

This is where many teams make their most expensive mistake. They reach for the most accurate model available, a large opaque one, get a result that beats the simpler option by a few points, and only later discover they cannot deploy it because they cannot explain its decisions to the standard the regulation requires. The accuracy they bought is worthless if the system is not permitted, and a slightly less accurate model that can be explained and defended is not a compromise, it is the only one that ships.

So in a regulated context, explainability sits alongside accuracy as a first-class selection criterion, not a tie-breaker. Sometimes that means choosing an inherently interpretable model over a black box that scores higher. Sometimes it means wrapping a complex model in constraints and checks that make its behaviour defensible. Sometimes it means the right answer is not a model at all, but a transparent rule a customer and an examiner can both follow. The question is never only "which is most accurate." It is "which is most accurate among the systems we can actually stand behind when someone asks us to justify a decision," and a team that skips the second half of that sentence builds something it cannot use.

The model is a decision you must be able to defend

The deepest shift is that in a regulated estate you are not shipping a model, you are shipping a decision that a specific person is accountable for and that a specific customer can contest. The model is just the mechanism. What the regulation cares about is the decision and whether it can be justified, which means the thing you are really building is a defensible decision process that happens to use a model inside it.

That reframing changes what "done" means. A model that performs well on a test set is not done. A decision process is done when a named owner understands it well enough to defend it, when any individual output can be reconstructed and explained, when the fairness properties have been measured and documented, and when there is a clear, tested path for a customer to challenge a decision and have it reviewed. All of that is the deliverable, and the model is perhaps a quarter of the work.

Teams that internalise this stop asking "is the model accurate enough" as the final question and start asking "can we defend every decision this will make, to the person it affects and to the regulator who protects them." The second question is harder, it is the right one, and it is the one that was always going to be asked. Asking it first is the difference between building the system once and building it twice.

Build the audit trail before you build the feature

The practical discipline that separates teams who ship in regulated estates from teams who stall is counterintuitive: build the audit trail first, before the feature works, not after.

The reason is that an audit trail added later is never complete. You will always have failed to capture some input, some version, some intermediate decision, that an examiner later asks for and you cannot produce, because the system was not recording it at the moment that mattered and that moment has passed. In a regulated estate the ability to reconstruct a decision is not a reporting feature, it is a precondition for being allowed to make the decision at all, so it has to exist before the first real decision is made.

Concretely, that means logging the complete chain from the start: which model version, which inputs, which data it was trained on, which prompt or configuration, which output, which human reviewed it, and what happened next, all captured as the system runs, all queryable for any individual case, all retained for as long as the rules require. It feels like overhead when the feature is not even working yet. It is not overhead. It is the part of the system that makes the feature legal, and a team that treats it as something to add once the interesting work is done has inverted which part was actually interesting.

Humans in the loop, by design and by law

In an unregulated product, how much to automate is an optimisation question: automate where it is cheaper and good enough, keep a human where it is not. In a regulated estate, the human in the loop is frequently a requirement, and the design question becomes how to make that human genuinely effective rather than a rubber stamp.

This is subtle, because a human in the loop who approves whatever the model suggests, because the model is usually right and checking is tedious, is worse than no human at all: they add cost, they add delay, and they add the illusion of oversight without its substance, which is exactly what an examiner is trained to detect. The requirement is not a human present, it is a human in genuine control, and those are very different systems to build.

Making the human effective means designing the handoff deliberately. The system has to surface why it reached its conclusion, not just what the conclusion is, so the reviewer has something real to evaluate. It has to flag its own uncertainty, so attention goes where it is needed rather than being spread evenly across cases that do not need it. It has to make disagreeing with the model as easy as agreeing, so the path of least resistance is not blind approval. The goal is a reviewer who catches the cases the model gets wrong, and that is a product you design on purpose, not a checkbox you add because the rules demand a name in a field.

The advantage hiding inside the constraint

It is tempting to read all of this as a list of reasons regulated industries move slowly with AI, and to treat the constraint as pure cost. That reading misses where the advantage is.

The constraints that regulation imposes, explainability, auditability, measured fairness, genuine human oversight, a named owner who understands the system, are, with few exceptions, the properties of a well-engineered AI system in any industry. The regulated estate is simply forced to build them, where an unregulated competitor is merely advised to and usually does not. The discipline that feels like a tax is the same discipline that produces systems people can actually trust, that fail in understood ways, that can be improved because they can be inspected. A team that masters it in a regulated context has built a capability that travels.

So the frame that serves a leader is not "how do we do AI despite the regulation." It is "the regulation is forcing us to build AI properly, and the muscle we develop doing so is a durable advantage over everyone who got to cut the corners we could not." The walls are real, moving fast inside them is genuinely not an option, and the teams that accept that early and build for defensibility from the first week do not just satisfy the regulator. They end up with the AI that works, because defensible and reliable turn out to be the same system seen from two directions.

I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.

Building Is Cheap, Choosing Is Hard: What to Actually Build With AI

Fabian Cooper — Tue, 10 Nov 2026 11:19:19 +0000

AI has made it cheap to build almost anything. That is exactly why most AI initiatives fail, and they fail before a line of code is written.

The old constraint was engineering. Building was slow and expensive, so the discipline lived in execution: ship the thing, make it work, optimise it. AI collapses that cost. A capable team can now prototype a credible version of almost any idea in days. The bottleneck has moved, and most organisations have not noticed. The scarce skill is no longer building the thing. It is choosing the right thing to build, and that is a muscle most teams never had to develop because the cost of building used to do the choosing for them.

So the failure mode has moved upstream. The projects that collapse rarely collapse because the team could not build them. They collapse because the team built something nobody needed, solved a problem that was not painful, or chose a place where AI was the wrong tool, and no amount of engineering excellence rescues a well-built answer to the wrong question.

The initiative that started with the answer

The pattern is easy to spot once you know its shape. It starts at the top, with a sentence like "we need an AI strategy" or "we should be using AI here." The decision that AI is the answer is made first. Then a team is sent to find the question: to hunt through the product for somewhere to apply the technology that leadership has already committed to.

This is a solution in search of a problem, and it runs backwards. The team is not asking "what is our most painful, frequent, valuable problem, and what is the best way to solve it?" They are asking "where can we plausibly bolt AI onto what we already have?" The output of that search is almost always a feature that demos well, impresses the steering committee, and quietly goes unused, because it was built to satisfy a mandate rather than to relieve a real pain.

The tell is the order of reasoning. When the technology is chosen before the problem, discovery becomes a justification exercise: the conclusion is fixed and the team works backwards to defend it. Real discovery can end in "AI is not the right tool for this," and an initiative that cannot reach that conclusion is not discovering anything. It is rationalising a decision already made.

Discovery starts from the problem, not the technology

The correction is almost embarrassingly simple and almost never done: start from the problem. Not from AI, not from a competitor's launch, not from a board member's enthusiasm. Start from a specific, observed, painful thing that specific people do today, and only then ask what the best tool to help them is.

This sounds obvious because it is the oldest rule in product, but AI breaks people's discipline about it in a way few technologies do. The capability is genuinely impressive, the demos are genuinely seductive, and the pressure to be seen doing something with AI is genuinely intense. All three push teams to lead with the technology and reverse-engineer a use for it. Resisting that pull is most of the job.

The practical move is to keep the problem and the solution strictly separate for as long as possible. Describe the problem in a way that does not mention AI at all: who has it, how often, what it costs them, what they do today, why that is bad. If the problem does not stand on its own as worth solving once the word "AI" is removed, it was never a problem worth solving. It was an excuse to use the technology, and the technology will not save it.

The four questions before you build

Before committing to build anything with AI, four questions decide whether it is worth it, and skipping any one of them is how good teams end up with expensive, unused features.

The first: is this a real problem? Not a hypothetical one, not a nice-to-have, but something people visibly struggle with often enough and painfully enough that they would change their behaviour to get relief. The second: is AI actually the best tool for it? A great many problems framed as AI problems are better solved by a form, a rule, a better default, or fixing the underlying process, and reaching for a probabilistic model when a deterministic one would do is a common and expensive mistake. The third: can you tell whether it worked? If you cannot define and measure success before you build, you will not be able to tell a working system from a broken one after you ship, and for probabilistic systems that is fatal. The fourth: is it worth the cost, including the ongoing cost to run, maintain, and watch it, not just the cost to build it once?

A real problem, where AI is genuinely the best tool, with a measurable definition of success, that clears its full cost. Only the ideas that pass all four earn a build. The value of the four questions is almost entirely in the ones they kill.

The demo trap

The single most expensive mistake in AI product decisions is mistaking a good demo for a viable product. AI is uniquely good at producing an impressive demo, because a demo is a curated happy path and a language model on a happy path looks like magic. That magic is real, and it is also the easy ten percent.

The hard ninety percent is everything the demo skips. The messy real inputs instead of the clean example ones. The edge cases, the ambiguous requests, the adversarial users, the long tail of situations the demo never showed. The integration into a real workflow where people actually are, rather than a standalone screen they have to remember to visit. The reliability needed to trust the output, the handling for when it is wrong, the cost at full volume, the monitoring to know it is still working. None of this shows up in the demo, and all of it is where the effort, the risk, and the value actually live.

So the demo is the beginning of the question, not the answer to it. The right response to a compelling AI demo is not "ship it," it is "now show me the ten hardest real cases, the cost at scale, and how we will know when it breaks." A decision made on the strength of the demo is a decision made on the easiest ten percent of the problem, and the ninety percent you did not look at is the ninety percent that decides whether it works.

Where AI actually earns its place

Part of choosing well is knowing the shape of problem where AI is genuinely the right tool, rather than the most exciting one. The technology has a grain, and working with it is far easier than working against it.

AI earns its place where the work is high in volume and language or pattern heavy, where perfect accuracy is not required and a good answer most of the time beats no answer at all, where a human can cheaply check or correct the output, and where the cost of a mistake is bounded and recoverable. Summarising, drafting, classifying, extracting, routing, and surfacing the right thing from a large pile: these play to the grain. The technology is probabilistic, so it fits problems that tolerate being right most of the time.

It works against the grain exactly where the opposite holds: where the answer must be exactly right every time, where a single error is costly or irreversible, where the logic is simple and deterministic and a rule would be more reliable and cheaper, or where there is no way to check the output and no tolerance for it being wrong. Forcing AI into those places is how you get an unreliable version of something a simpler tool did perfectly well, and recognising them early is as valuable as recognising the good fits, because it stops a build before it starts.

Killing the wrong bets early

Because building is now cheap, the expensive thing is commitment: the months spent, the roadmap displaced, the organisational attention spent defending a bet that should have been killed. The discipline that matters most in AI product work is the discipline of the early no, and it is the one most organisations are worst at.

The reason they are bad at it is not analytical, it is social. Once a team has demoed something impressive and leadership has seen it, killing it feels like failure and admitting waste, so the dead idea limps on, absorbing resources, because no one wants to be the one who stops it. The fix is to make killing cheap and expected by deciding, before you build, what would prove the idea wrong, and to run the cheapest test that could produce that disproof first. A fake door, a manual version, a tiny pilot with real users, a back-of-envelope on the unit cost at scale. The goal of early discovery is not to prove the idea works. It is to find the fastest, cheapest way to find out that it does not, so you spend your real build budget only on the bets that survived a genuine attempt to kill them.

A team that kills nine ideas cheaply to fund one that works is far ahead of a team that half-builds all ten, and the difference is almost never talent. It is the willingness to say no early, out loud, on purpose.

A portfolio, not a moonshot

Put it together and the shape of good AI product work becomes clear. It is not a single bet-the-company moonshot, and it is not a hundred half-finished experiments. It is a disciplined portfolio: many ideas entered cheaply, most killed fast, a few survivors funded properly and taken all the way through the hard ninety percent to something people actually rely on.

That requires holding two things at once that feel contradictory. A low cost of starting, so ideas are easy to try and the organisation explores widely. And a high bar for continuing, so only the ideas that clear the four questions and survive a real attempt to disprove them get the expensive commitment. Teams that get only the first half generate endless demos that never ship. Teams that get only the second half are too cautious to find the non-obvious wins. You need both: generous at the door, ruthless at the gate.

The organisations getting real value from AI are not the ones that built the most, or the ones with the best models, which everyone rents from the same providers anyway. They are the ones that got good at choosing: that treated deciding what to build as the actual hard problem, pointed their cheap, abundant building capacity only at the things worth building, and had the discipline to stop the rest. Building was never the constraint. Choosing is, and choosing well is the skill the whole AI era quietly rewards.

I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.

The Silent Regression: Why AI in Production Needs Observability, Not Just Monitoring

Fabian Cooper — Sat, 07 Nov 2026 13:49:39 +0000

The worst AI failures do not announce themselves. Nothing crashes, no alert fires, every dashboard stays green, and the quality quietly collapses while you are looking the other way.

This is the failure mode that catches teams who shipped AI and then watched it the way they watch everything else. Their monitoring is excellent. Uptime is five nines, latency is flat, the error rate is near zero, and by every signal they have, the system is healthy. Then a customer complains that the answers have been wrong for three weeks, someone finally samples the output, and the room goes quiet. The system never failed in any way the monitoring could see. It just stopped being right.

Traditional software fails loudly, by breaking. AI fails silently, by degrading. Those are different problems, and the tooling built for the first one is blind to the second. Watching an AI system the way you watch a web server will tell you it is up. It will not tell you it is wrong.

The outage that wasn't an outage

The pattern is specific enough to recognise. An AI feature ships, performs well, and settles into production. Monitoring is wired up the usual way: request rate, latency percentiles, error rate, resource usage. All of it looks good, so attention moves elsewhere. The system is treated as done.

What nobody is watching is whether the outputs are still correct. And correctness, for an AI system, is not a stable property. It drifts, because the things the model depends on drift: the inputs change shape, an upstream provider updates the model underneath you, a prompt that worked last quarter slowly stops fitting the cases people now send. None of these trip an error. The system keeps returning well-formed, confident, plausible responses that happen to be worse than they were.

So the degradation accumulates invisibly until it crosses the threshold where a human notices, and by then it has been happening for weeks. The cost is not just the wrong answers. It is the trust, because the people who hit those answers learned the tool is unreliable, and that lesson outlives the fix. The outage that is not an outage is more dangerous than a real one precisely because nothing tells you it is happening.

Why AI breaks traditional monitoring

Monitoring, as the discipline exists, is built on a simple assumption: failure is an event. Something throws, something times out, something returns a 500, and you alert on it. The entire toolchain, the metrics, the thresholds, the pages, is designed to catch the moment a system stops working. That assumption has served software well for decades because it was true. Software mostly failed by breaking.

AI violates the assumption at its root. An AI system can fail while succeeding by every mechanical measure. The request completes, the response is valid, the status code is 200, and the content is wrong. There is no exception to catch because nothing threw. The failure lives in the semantics of the output, which monitoring never looks at, not in the mechanics of the request, which is all monitoring looks at.

This is why "it is up" and "it is working" have come apart for AI in a way they never did for traditional services. For a database, up and working are nearly the same thing. For an AI feature, they are independent variables, and the gap between them is exactly where the silent regressions live. Closing that gap is not a matter of better monitoring. It needs a different thing pointed at a different layer, and that thing is observability of the output itself.

The four ways AI silently degrades

If you are going to watch for silent degradation, it helps to know what you are watching for. In practice it arrives through four doors, and all four leave the mechanics untouched.

The first is input drift. The distribution of what users send shifts away from what the system was built and tested on. New phrasings, new topics, longer documents, edge cases that were rare at launch and are common now. The model was never wrong about the old distribution; the world simply moved, and the system is now answering questions it was never good at, with the same confidence it had when it was.

The second is the model changing underneath you. A provider updates or deprecates the version you depend on, and behaviour shifts without a line of your code changing. This is the treadmill problem showing up as a production incident: the same prompt, the same inputs, a different model, and subtly different outputs that no deploy of yours can be blamed for because you did not deploy anything.

The third is prompt rot. A prompt is tuned to a snapshot of the task, and the task keeps moving while the prompt stays still. Instructions that were precise become ambiguous against new cases, examples that were representative become misleading, and the slow mismatch degrades quality without any single moment of breakage. The fourth is the feedback loop poisoning itself: when a system's own outputs become its future inputs, or train its future behaviour, small errors compound instead of cancelling, and the system drifts in a direction nobody chose.

What to actually instrument

The instinct, once a team accepts this, is to measure quality directly and continuously. That is the right goal and the wrong first step, because for most real systems you cannot cheaply know the true quality of every output in real time. If you could, you would not need the model. So observability for AI is the practical craft of approximating quality from signals you can actually capture.

Several of them are available and underused. Sample a slice of production outputs and score them against ground truth, continuously, not just once at launch; a small, steady sample catches a trend long before a customer does. Instrument proxy signals that correlate with quality and are cheap to collect: the rate at which users retry, rephrase, abandon, override, or escalate past the AI is a live quality meter if you bother to read it. Watch the model's own confidence or refusal signals where they exist. Track the shape of the inputs over time so drift shows up as a graph, not a surprise. And capture every explicit human correction as the highest-grade signal you have.

None of these is a perfect measure of correctness. Together they are an early-warning system, which is what you actually need. The goal is not to prove every answer right. It is to notice, quickly, when the answers are getting worse, so that the three-week silent regression becomes a three-hour one.

From detection to diagnosis

Detection alone is not enough, and a dashboard that only says "quality dropped" can even make things worse by raising an alarm nobody can act on. The regression you detect is useless until you can explain it, and explanation is where most AI observability efforts stop short.

This is why the signals have to be captured with enough context to trace a bad outcome back to its cause. When quality dips, the question is immediately why, and the candidate answers are the four doors: did the inputs shift, did the model version change, did the prompt stop fitting, did the feedback loop drift. You can only answer that if, for a representative sample, you kept the full picture: the exact input, the exact prompt, the model and version, the parameters, and the output, joined together and queryable after the fact. Logging the output alone tells you something is wrong. Logging the whole chain tells you what to fix.

That is the real line between monitoring and observability. Monitoring tells you that something changed. Observability lets you ask, after the fact, why, without having to reproduce the moment. For systems whose behaviour is probabilistic and input-dependent, that ability to interrogate what actually happened is not a luxury. It is the only way to turn a detected regression into a fixed one before it recurs.

The human in the observability loop

All of this implies something most AI programs under-resource: a person whose job is to watch the quality, not just the uptime. Automated signals narrow the search, but someone still has to read the sampled outputs, judge the borderline cases, and decide whether a dip is noise or the start of a slide. Quality, for a probabilistic system, is not fully automatable, and pretending otherwise just moves the judgment to an angry customer.

The practical shape of this is an on-call for correctness that sits alongside the on-call for availability. A regular review of sampled outputs with a human in the loop. A clear owner for the question "are the answers still good?", the same way there is a clear owner for "is the service still up?". It does not have to be heavy, and it should not be a committee. It has to exist, because the alternative is that nobody owns the one failure mode your monitoring cannot see, and unowned failure modes are the ones that run for three weeks.

This is also where the signals earn their keep. A good observability layer means the human is reviewing a smart sample, the cases the proxy metrics flagged as suspicious, rather than reading output at random. The machine narrows the haystack and the person judges the needles. Neither replaces the other, and a program that invests in one without the other is half-protected.

Shipping with confidence

None of this is an argument for watching AI nervously and trusting it less. It is the opposite. Observability is what lets you trust the system more, because you will know, quickly, when the trust is no longer warranted. You cannot responsibly give an AI system more autonomy than you can observe, and the ceiling on how much you can safely automate is set by how well you can see what it is doing.

In practice this is a short list of commitments made at build time, not bolted on after the first silent regression. Instrument output quality, not just system health, from day one. Capture the full chain for a sample so you can diagnose and not just detect. Watch the four doors, input drift, model change, prompt rot, feedback drift, as named, trackable things. Put a human on-call for correctness with a real owner. And treat a quality regression as a production incident with the same seriousness as an outage, because for the user it is one, it just does not show up on the status page.

The teams that trust their AI the most are not the ones who looked away after launch. They are the ones who can see, at any moment, whether the thing is still right, and can prove when it stopped. Monitoring will tell you your AI is up. Only observability will tell you it is still working, and for a system that fails by quietly getting worse, that is the difference between a tool people rely on and one they learned to route around.

I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.

Surviving the Model Treadmill: Building AI That Outlives the Model It Launched On

Fabian Cooper — Wed, 04 Nov 2026 14:24:23 +0000

The model you built on this quarter will not be the best model next quarter. Plan for that, or plan to keep rebuilding.

Teams building with AI right now are living through something software has not seen before: the single most important component of the system gets materially better, cheaper, or deprecated every few months, and none of that is under their control. A new frontier model lands and resets the quality bar. A price drop makes last quarter's architecture look wasteful. A provider sunsets the exact version you tuned everything around, with a migration deadline you did not choose. The ground moves, and it keeps moving.

The instinct is to treat each of these as a one-off event to react to. That is the mistake. The churn is not a series of surprises. It is the permanent condition of building on AI, and the teams that thrive are the ones who stopped being surprised and started designing for it.

The upgrade that broke everything

The pattern shows up the first time a better model ships and you discover you cannot actually use it. A new release is clearly stronger on every benchmark that matters, the team is excited, and then someone tries to swap it in. The carefully tuned prompts, written against the old model's quirks, now behave differently. The output format drifts. An edge case that was handled is suddenly not. What should have been a one-line change becomes a two-week regression hunt, and the upgrade quietly slips down the backlog.

So you stay on the old model. Not because it is better, but because moving is expensive and risky, and nobody can say with confidence that the new one will not break something in production. The improvement sits on the shelf. Meanwhile a competitor who built for portability ships the upgrade in an afternoon and pulls ahead on quality and cost at the same time.

The deeper version of this is deprecation, where staying is not even an option. The provider announces the model you depend on retires in ninety days, and now the migration you kept deferring is mandatory, urgent, and happening on someone else's schedule instead of yours. The work was always going to be necessary. The only question was whether you did it calmly, on your terms, or in a panic against a deadline.

Why the treadmill is permanent

It is tempting to believe this settles down, that the frontier stabilises and the churn was just the early turbulence of a new technology. It will not, at least not on any timescale you can plan around. The economics guarantee it.

Multiple well-funded labs are competing directly on capability and price, releasing on cadences measured in months. Each release pressures the others. Inference costs fall as hardware and techniques improve, which means the cost-optimal choice keeps shifting even when quality does not. And providers prune their own catalogues to control the cost of serving old versions, so the model you are on today has a finite, often undisclosed, lifespan regardless of how well it works for you.

None of these forces is slowing. The rational planning assumption is not "the model is stable." It is "the model is a depreciating, replaceable component with an expiry date I do not control." Once you hold that assumption squarely, the whole design problem changes. You stop optimising for the model you have and start optimising for the ease of replacing it, because replacing it is the one thing you know for certain you will have to do.

The lock-in you didn't notice

Most model lock-in is not a deliberate choice. It accumulates quietly, one reasonable decision at a time, until the cost of moving is high enough that you stop considering it.

It starts with prompts. A prompt tuned through dozens of iterations against one model is, in effect, a program written in that model's private dialect. It encodes assumptions about how that specific model interprets instructions, where it needs reinforcement, what format it reliably produces. Move to another model and that accumulated tuning does not transfer cleanly, because you were never really writing general instructions. You were writing to one reader.

Then it is the provider-specific features: a particular tool-calling format, a structured-output mode, a context-caching mechanism, a safety setting that behaves a certain way. Each one is convenient and each one is a thread stitching you to that vendor. Individually trivial, collectively a straitjacket. By the time a better or cheaper option appears, you are not comparing two models. You are comparing your current model against the full cost of unpicking every thread, and that comparison almost always ends in "not now."

The lock-in is invisible precisely because it never felt like a decision. That is why it has to be designed against deliberately. Portability does not happen by default. Dependence does.

The abstraction layer that actually helps

The obvious response is an abstraction layer, and the obvious abstraction layer is the wrong one. Wrapping every provider in a lowest-common-denominator interface that exposes only the features they all share throws away exactly the capabilities you are paying for, and leaves you with a system that is portable and mediocre everywhere.

A useful abstraction does something harder. It isolates the model behind a boundary your application code never reaches across, so that the model, its prompts, its parameters, and its provider-specific handling all live in one replaceable place. The rest of your system talks to a stable internal contract, "given this input, return this structured result," and does not know or care which model is behind it. Swapping the model means changing what lives inside that boundary, not touching the hundred places that consume its output.

The distinction that matters: you are not abstracting away the differences between models, you are containing them. The provider-specific tool-calling format still gets used, it just gets used inside the boundary, with an adapter per provider, rather than leaking into your business logic. Done well, this is not a heavy framework. It is a discipline about where model-specific knowledge is allowed to live, and the payoff is that "try the new model" becomes a bounded experiment instead of an architectural event.

Your eval harness is the insurance policy

Containment lets you swap the model. It does not tell you whether you should, or whether the swap broke anything. That is what an evaluation harness is for, and it is the single highest-leverage thing you can build for life on the treadmill.

An eval harness is a representative set of real tasks with known-good outcomes, run automatically, that tells you how any given model actually performs on your workload rather than on a public benchmark. With one, a new model release is a calm, mechanical exercise: point the harness at it, read the scores on your own tasks, see the regressions and the gains in numbers, and decide. Without one, every swap is an act of faith, which is exactly why teams without a harness freeze, and teams with one move in a day.

This reframes the harness from a testing nicety into the core asset that makes portability real. The abstraction layer gives you the ability to change the model cheaply; the eval harness gives you the confidence to actually pull the trigger. One without the other is not enough. A clean abstraction with no eval harness means you can swap but dare not, and a great eval harness bolted onto a tangle of model-specific code means you know you should swap but cannot afford to. You need both, and the harness is the one teams skip, because its value is invisible right up until the day a new model ships.

When to actually switch

Building for portability is not an argument for chasing every release. The ability to switch cheaply is precisely what lets you be disciplined about when you do, because the decision is no longer distorted by the pain of moving.

The trap is benchmark-chasing: a new model tops a public leaderboard and the reflex is to adopt it. But public benchmarks are not your workload. A model that is two points better on a general reasoning test may be no better, or worse, on your specific task, and the only thing that settles it is your own eval harness. Switch when the harness shows a real gain on the outcomes you care about, or when the cost falls enough to matter at your volume, or when your current model is being deprecated. Those are the reasons. "It is new and everyone is talking about it" is not.

There is also a real cost to staying, and portability lets you see it clearly rather than hide from it. Every quarter on a model that is now more expensive than its replacement is margin left on the table. Every quarter on a model that is now meaningfully weaker is quality you are choosing not to ship. When moving is cheap, those costs become visible decisions instead of comfortable defaults, and that visibility is worth as much as the flexibility itself.

Building for the next model, not this one

The shift is to stop treating the current model as a fixed foundation and start treating it as the most replaceable part of the system. That sounds like a loss of certainty. In practice it is the only durable certainty available, because the one thing you can rely on is that the model will change.

Concretely, it means a few commitments made early, while they are cheap, rather than late, under a deprecation deadline. Keep model-specific knowledge, the prompts, the parameters, the provider adapters, contained behind a boundary your application never reaches across. Write prompts as clearly as you can to the task rather than overfitting to one model's quirks, so they travel better. Build the eval harness before you think you need it, because you need it most on the day you did not plan for. And treat every provider-specific feature you adopt as a deliberate dependency with a known cost to remove, not a free convenience.

The teams that will struggle are the ones who built a beautiful system perfectly fitted to one model and called it done. The teams that will compound are the ones who built a system that treats the model as a swappable component and made swapping cheap and safe. The models will keep getting better, cheaper, and deprecated, on a schedule nobody controls. You cannot get off the treadmill. You can only decide whether you built something that runs comfortably on it, or something that trips every time the belt speeds up.

I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.

Priced to Lose: Why "Add $20 a Month for AI" Is Not a Business Model

Fabian Cooper — Wed, 04 Nov 2026 13:38:57 +0000

Most teams spend a year perfecting an AI feature and ten minutes deciding what to charge for it. Then they are surprised when the economics do not work.

The usual move is to treat the AI capability like any other software feature: build it, add it to the product, and tack a round number onto the subscription. Twenty dollars a month, maybe thirty for the enterprise tier. It feels reasonable because that is how software has always been priced. The problem is that AI is not like the software you priced that way, and the pricing model you inherited quietly assumes a cost structure that no longer holds. The result is a feature that sells well and loses money on every heavy user, which is the worst outcome of all because success makes it worse.

Pricing is not the last step of shipping AI. It is part of the design, and the teams that treat it that way are the ones whose AI actually contributes to the business instead of silently draining it.

The feature that shipped at a loss

The pattern is easy to recognise once you have seen it. A company adds an AI feature, prices it as a flat monthly add-on, and watches adoption climb. Leadership is pleased. Then someone finally reconciles the inference bill against the revenue line and discovers that the most engaged customers, the ones using the feature dozens of times a day, are costing far more to serve than they pay.

Flat pricing on a variable cost is a bet that usage stays modest. With AI, the customers who love the feature use it relentlessly, and every use has a real marginal cost in tokens or compute. So the distribution of usage is not flat. A small group of power users drives most of the consumption, and under a flat price those users are being subsidised by everyone who barely touches the feature. The moment your marketing succeeds at driving engagement, your margin gets worse, not better.

This is the inversion that catches people. In classic software, more usage is pure upside because serving one more request costs effectively nothing. In AI, more usage is a cost event. A pricing model that does not account for that is not a pricing model. It is a hope.

Why AI breaks the SaaS pricing playbook

The entire logic of software-as-a-service pricing rests on one assumption: near-zero marginal cost. Once the product is built, the cost of serving an additional user or an additional action rounds to nothing. That single fact is why SaaS can offer unlimited seats, unlimited storage tiers, and flat monthly fees without blinking. The expensive part was building it once.

AI violates that assumption directly. Every inference call consumes compute that someone pays for in real money, and the cost scales with how much the thing is used and how hard each use is. A long document, a complex reasoning chain, a high-resolution generation: these are not all the same cost, and none of them are free. The marginal cost of an AI feature is not zero and is not even constant. It is a live variable that moves with user behaviour.

When you price a variable-cost product with a fixed-cost playbook, you are no longer running a software business on that feature. You are running an unhedged position. You have fixed your revenue and left your cost of goods floating, and you will only find out how bad the position is after the customers who exploit it have arrived. The discipline AI pricing actually resembles is not software. It is any business that sells something with a real cost per unit, where margin is something you engineer rather than assume.

Three ways to charge, and what each one signals

There are really only three primitives, and most good models combine them. Each one sends a different signal to the customer about what they are buying.

Seat-based pricing charges per user, regardless of how much each user does. It is simple, predictable, and familiar, and it works when usage per seat is roughly bounded and similar across people. Its weakness is exactly the heavy-user problem: it decouples price from cost, so it only survives if consumption does not vary wildly. For an AI feature with a long tail of intensive users, pure seat pricing is the trap described above.

Usage-based pricing charges for what is consumed: calls, tokens, documents, generations. It aligns price with cost almost perfectly, which protects margin, and it lets customers start small and grow. Its weakness is that it makes spend unpredictable for the buyer, and unpredictable spend is the single most common reason a procurement team says no. People will pay more for a bill they can forecast than a smaller bill they cannot.

Outcome-based pricing charges for the result, not the activity: per resolved ticket, per qualified lead, per completed document. It is the most defensible because it ties your revenue directly to the value you create, and it is the hardest to run because it requires you to define and measure the outcome rigorously and to carry the risk when the work is messy. When it fits, it is the strongest position available, because the customer is no longer comparing your price to a competitor's. They are comparing it to the cost of the outcome not happening.

The margin problem nobody models

Here is the number most teams never calculate before they launch: the cost to serve their heaviest ten percent of users. They model an average, multiply it out, and feel comfortable. But averages lie about AI usage, because the distribution is not normal. It has a fat tail, and the tail is where the money leaks.

If you have not segmented usage before pricing, you do not know your real margin. You know a blended figure that hides a cross-subsidy, and that cross-subsidy is fragile. It holds only as long as the light users outnumber and outpay the heavy ones. Change the customer mix, run a successful engagement campaign, or land a few intensive enterprise accounts, and the comfortable average quietly turns negative while your dashboards still show growth.

The teams that get this right instrument cost per user, not just cost in aggregate, and they look at the shape of the distribution before they set a price. They ask what happens to margin if the heavy tail doubles, because with AI it will. They build the price to be solvent at the tail, not merely at the mean. That is the difference between a feature that scales and a feature that becomes more expensive the more customers love it.

Pricing to value, not to cost

Costing the feature tells you the floor. It does not tell you the price. The most common mistake after the margin mistake is to set the price as a markup on inference cost, as though the customer cares what your tokens cost. They do not. They care what the work is worth to them.

The right anchor is the value of the thing you are replacing or creating. If an AI feature does in seconds what previously took a person an afternoon, its price lives in the neighbourhood of that afternoon, not in the neighbourhood of the compute bill. Cost-plus pricing on AI systematically leaves money on the table precisely where the feature is most valuable, because the compute cost is often lowest exactly when the value is highest. A model that saves a lawyer three hours costs you cents and is worth hundreds.

This is why the strongest AI monetisation is framed around outcomes and time saved rather than features and capabilities. "We do X for you" priced against the cost of X is a far stronger position than "we have an AI assistant" priced against the cost of running it. The compute cost sets the floor you must clear to be solvent. The value delivered sets the ceiling you are allowed to reach. Pricing is the discipline of living between them on purpose, not defaulting to the floor because it was the only number you bothered to calculate.

The packaging decision

Separate from how you charge is how you package, and the two get confused constantly. The packaging question is whether the AI is a standalone add-on, a feature bundled into existing tiers, or the thing that defines a new premium tier. Each choice makes a different claim about what the AI is.

Bundling AI into the base product says it is table stakes, a reason to stay rather than a reason to pay more. That is sometimes exactly right, when the AI's job is retention and competitive parity rather than new revenue, and pretending otherwise by charging separately just slows adoption of something you needed everyone to use. Selling it as a premium add-on says it is a distinct, optional value worth a separate decision, which works when the buyer can clearly see who needs it and who does not. Making it a new top tier says the AI is the upgrade, the reason to move up the ladder, and anchors it against your highest-value customers.

The error is choosing packaging by habit instead of by intent. Charging separately for an AI feature whose real job was to defend the core product slows the adoption you needed. Burying a genuinely premium capability in the base tier gives away the one thing customers would have paid a premium for. Decide what the AI is for first, then let the packaging say the same thing the strategy says.

What a durable AI pricing model looks like

Put the pieces together and the shape is clear enough to act on.

A durable model starts from segmented usage, not a blended average, so you know your real cost to serve across the whole distribution and especially at the tail. It protects margin with a usage or outcome component so that heavy users pay in proportion to what they consume, rather than being subsidised into a loss. It anchors the price to the value of the work rather than the cost of the compute, so the business captures a fair share of what it actually creates. It packages the capability to match its strategic job, whether that job is new revenue, premium differentiation, or defending the core. And it gives the buyer enough predictability that procurement can say yes, because a model that is theoretically optimal and practically unbuyable earns nothing.

None of this is exotic. It is the ordinary discipline of selling something that has a real cost per unit, applied to a category that spent a decade pretending cost per unit did not exist. The teams still pricing AI like zero-marginal-cost software are the ones who will keep being surprised by their own margins, celebrating adoption while the unit economics quietly erode underneath it.

The feature was the easy part. Deciding what it is worth, to whom, and how to charge for it without going broke at scale is the part that determines whether the AI ever pays for itself. Price it like the variable-cost product it is, anchored to the value it delivers, or keep shipping features that win the demo and lose the invoice.

I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.

Shipped Is Not Adopted: Why AI Rollouts Stall at the Human Layer

Fabian Cooper — Mon, 02 Nov 2026 15:54:00 +0000

Most AI programs do not fail in the model. They fail in the three feet between the tool and the person who was supposed to use it.

I have watched it happen more than once. The build is clean. The evaluation numbers are good. The demo lands in the steering committee and someone important says the word "transformational." Six weeks after launch, you pull the usage data and the truth is quieter: a small cluster of enthusiasts logged in a lot, everyone else looked once, and the old spreadsheet is still open on most desks. Nothing broke. The thing simply did not take.

We have gotten good at shipping AI. We are still bad at the part that decides whether shipping mattered. That part is not technical. It is human, and it is where the return actually lives.

The pilot that nobody used

The pattern is consistent enough to name. A team identifies a high-value workflow, builds an AI tool that genuinely does it well, runs a pilot with a friendly group, sees strong numbers, and declares victory. Then they roll it out to the wider population and adoption flatlines.

The reason the pilot looked good is the same reason it did not generalise. Pilots self-select for the people who want the tool to work. Early volunteers are curious, tolerant of rough edges, and already bought into the premise. They are not a sample of your organisation. They are the least representative group you could have chosen, and their enthusiasm hid every obstacle the median user was going to hit.

So the dangerous moment is not the pilot that fails. It is the pilot that succeeds for the wrong reason, because it buys confidence you have not earned and sends you into a full rollout with no plan for the people who were never going to volunteer.

Adoption is not a training problem

When adoption stalls, the default reflex is to schedule more training. Another webinar, a better quick-start guide, a lunch-and-learn. This almost never works, because lack of knowledge is rarely the real blocker. People are not failing to use the tool because they cannot find the button. They are choosing not to, and the choice is rational from where they sit.

Treating adoption as a training problem is comfortable because it keeps the fault with the user: they just need to learn. The fact is usually the reverse. If capable people who understand the tool still will not switch, the signal is about the tool and the workflow around it, not about their diligence. More training on a tool people are deliberately avoiding just adds resentment to inertia.

The useful question is not "how do we teach them?" It is "why is the rational choice, for this specific person on a busy Tuesday, to keep doing it the old way?" Answer that and the path forward stops being a curriculum.

The three reasons people don't switch

In practice the resistance almost always reduces to three forces, and they compound.

The first is trust. The old process is a known quantity. The person knows its failure modes, knows when to double-check it, knows how to explain it when it goes wrong. A new AI tool is an unknown quantity that occasionally produces something confidently incorrect. Until the user has calibrated when to rely on it, the safe move is not to, and one bad early experience sets that calibration for months.

The second is effort. If the new tool is even slightly more work than the habit it replaces, in clicks, in context-switching, in the tax of checking its output, people revert. The threshold here is brutally low. A tool that saves ten minutes but adds two minutes of friction at the point of use will lose to the frictionless habit, because the ten minutes is abstract and the two minutes is right now.

The third, and the one leaders underweight most, is identity. For many people, the task you are automating is part of how they understand their own value. The analyst who is proud of their modelling, the writer who is proud of their first draft, the support agent who is proud of knowing the answer. A tool that does that part for them does not feel like a gift. It feels like a question about why they are still here. People do not resist AI because they misunderstand it. Sometimes they resist it because they understand it perfectly.

Redesign the workflow, not just the tool

The mistake underneath most stalled rollouts is dropping an AI capability into an unchanged process and expecting the process to absorb it. It will not. A workflow is a settled arrangement of steps, handoffs, checks, and responsibilities, and it will route around a new tool the way a river routes around a rock unless you actually change the channel.

Adoption succeeds when the new tool becomes the path of least resistance, not an optional detour off the existing one. That means redesigning the surrounding work: removing the manual step the tool replaces rather than leaving it as a fallback, putting the AI where the work already happens instead of in a separate destination people have to remember to visit, and changing what "done" looks like so the old method is no longer the thing being graded.

This is the expensive, unglamorous part, and it is why adoption is an operating discipline rather than a launch event. The model was the easy 20 percent. Rebuilding the workflow so the model is load-bearing is the 80 percent that most programs never budget for, and it is the only part that produces the return.

Incentives and the manager layer

People do what they are measured on. If an organisation says it values the new AI-assisted way of working but still rewards the metrics the old way optimised, everyone correctly ignores the speech and follows the scoreboard. Misaligned incentives will beat any amount of enthusiasm, every time.

The layer that decides this is middle management, and it is the layer most AI rollouts forget. Frontline staff take their real cues from their immediate manager, not from an all-hands. If that manager quietly believes the tool is a threat, a distraction, or a stick to beat their team with on headcount, no top-down mandate survives contact with them. They do not have to resist openly. They just have to not push, and the rollout dies in the gap between the strategy deck and the daily standup.

So the manager layer has to be the first adopter, not an afterthought, and the incentives have to change before the tool arrives, not after adoption disappoints. If using the new way is not visibly the thing that gets someone a good review, it is a hobby, and hobbies lose to deadlines.

How to measure adoption, not activity

Most adoption dashboards measure the wrong thing because the wrong thing is easy to count. Logins, active users, queries run: these are activity metrics, and activity is not adoption. A spike of logins in week one followed by a long decline is the signature of curiosity, not change.

The metric that matters is displacement: is the new way actually replacing the old way, or running alongside it as extra work? The questions to instrument are harder and more revealing. What share of the target task now goes through the tool versus the legacy path? Is usage still climbing in week eight, or did it peak and fade? When people use it once, do they come back, and does the second use look more confident than the first? Are the people using it the median population or still just the original enthusiasts?

Displacement also forces an inconvenient truth: if the old path is still fully available and fully used, you have added a tool, not changed a process, and your adoption number is measuring theatre. Instrument the replacement, not the activity, and the real picture arrives early enough to act on.

The rollout that sticks

None of this is an argument against building. It is an argument for treating the human layer as part of the build rather than as something that happens to the finished product.

In practice that means a few commitments made before launch, not after it disappoints. Choose the first workflow where the pain is real and the user actually wants relief, so the tool is pulling against a felt problem rather than pushing against a comfortable habit. Redesign the process so the new way is the easy way and the old way quietly goes away. Win the manager layer first and change the incentives before the tool lands. Measure displacement, not logins, and expect the real number to be lower than the pilot promised. Then close the loop: watch where people fall back to the old way, and treat each fallback as a defect in the rollout to fix, not a failure of the user to comply.

The organisations pulling real value from AI are not the ones with better models. Models are rented from the same handful of providers by everyone. The difference is that they treated adoption as the actual product and the model as a component of it. Shipping was never the finish line. It was the point where the hard part started, and the hard part is, as it has always been, people.

If your AI program is measured by what was deployed, you are measuring the easy half. The half that pays is what changed in how people actually work, and that half is won or lost in the three feet between the tool and the person. Build for that gap, or keep funding pilots that demo well and die quietly.

I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.

Bolted On or Built In: Why "We Added AI" Is Not an AI Strategy

Fabian Cooper — Fri, 30 Oct 2026 17:45:50 +0000

The copilot in the corner

Walk into almost any company that will tell you it is "doing AI" and you will find the same artefact: a copilot in the corner of a screen that already existed. A chat panel bolted to the side of the CRM, a "summarise" button on the ticketing tool, an assistant that drafts the email you were already going to write. It demoed well, it shipped in a quarter, and it let the leadership team say the sentence the board wanted to hear. "We have added AI."

I understand why this happens, because the incentives all point at it. The bolt-on is cheap, it is fast, and it is safe, since the model sits beside the real system rather than inside it and can be switched off without anything breaking. But a year later the same companies are quietly puzzled. Usage is thin, the productivity numbers refuse to move, and the competitor who looked slower at the start is now doing things they cannot copy with a side panel. The uncomfortable truth is that adding AI to software is not the same as building software around AI, and the gap between those two sentences is where the next decade of advantage is being decided.

Generative is not agentic

The first confusion worth clearing up is that most of what gets called "AI" in these deployments is generative, and generative is not the same as agentic. The distinction is not academic. It decides what the system can actually do for you.

A generative feature takes an input and produces an output, once. You ask, it answers, and it is done. It does not look at what it produced, it does not know whether the answer was any good, and it certainly does not do anything about it if the answer was wrong. The burden of judging the output, catching the mistakes and deciding the next step falls entirely on the human sitting in front of it. That is a typewriter with a vocabulary, and it is useful, but it is not transformative, because the hard part of knowledge work was never the typing.

An agentic system works differently. It perceives its own state and its own output, it reasons about whether that output is actually correct and complete, it acts to fix it when it is not, and it does all of this in a loop rather than in a single shot. It will re-run itself, check its work against a source of truth, notice that it is uncertain and ask for help, and carry a task across several steps toward a resolved outcome rather than dumping a first draft and stopping. The difference a user feels is the difference between a tool that hands you a result and a tool that takes responsibility for the result being right. One saves you keystrokes. The other closes the loop.

What "AI-native" actually means

This is where the architecture starts to matter, because you cannot bolt a loop onto the side of a system that was never designed to run one. An AI-native system is not a legacy application with a model attached. It is a system whose core workflow is the loop, with everything else arranged to serve it.

In practice that means a few concrete things are present from the start rather than added later. The system holds state across steps, so the AI can remember what it already tried and build on it instead of starting fresh each time. It has access to the real data and the real actions, not a read-only window onto them, so it can actually do the work rather than merely describe it. It carries its own sense of confidence, so it knows when to proceed and when to escalate. And it has a feedback path built in, so that when something goes wrong the system can diagnose it, propose a fix, and learn from the correction. None of that is a feature you sprinkle on at the end. It is the shape of the thing, and the shape is the decision.

The test I use is simple. If you removed the AI from the product, how much would be left? In a bolt-on, almost everything remains, because the AI was a garnish. In an AI-native system, the product stops making sense, because the intelligence was load-bearing. That is not a slur against the bolt-on, which is often the right first step. It is a way of being clear-eyed about which one you have actually built.

Why the bolt-on stalls

The bolt-on does not fail dramatically. It stalls, quietly, in four predictable places, and recognising them early saves a great deal of wasted investment.

It stalls on data, because a side panel usually sees a fraction of what the real workflow touches, so its answers are shallow and the user learns not to trust them. It stalls on control, because a feature that can only suggest, never act, leaves the entire burden of execution on the human, which means the promised time saving mostly evaporates. It stalls on trust, because a generative feature with no self-checking produces a confident wrong answer often enough that people stop relying on it for anything that matters, and a tool you cannot rely on for the important things is a toy. And it stalls on economics, because every call costs money whether or not the answer was useful, and without a loop that verifies and only escalates when needed, you pay full price for a stream of outputs you then have to check by hand. Each of these is survivable alone. Together they are why the usage curve goes flat three months after launch and the renewal conversation gets awkward.

The re-architecture most teams avoid

The reason so many organisations stay with the bolt-on long after it has stopped paying is that going from bolted-on to built-in is a re-architecture, not an upgrade, and re-architecture is exactly the work leadership teams are trained to defer. It is expensive, it is slower to show a demo, and it asks you to change the system you already shipped rather than add a new button to it.

What it actually requires is unglamorous and specific. You need somewhere to hold state between steps, so the system has a memory. You need to give the AI real, governed access to the actions the workflow depends on, with the guardrails that makes safe. You need an evaluation layer that scores the output before a human ever sees it, so the system can tell a good result from a bad one on its own. You need explicit human gates on the decisions that must not be automated, placed deliberately rather than everywhere out of fear. And you need to capture what goes wrong, so the correction loop has something to act on. This is the engineering that turns a generative feature into an agentic system, and it is invisible in a demo, which is precisely why it is underfunded. The teams that are pulling ahead are the ones that decided to do the invisible work anyway, because they understood that the loop, not the model, is the product.

How to tell which one you are buying

Most leaders are not building these systems themselves. They are buying them, approving them, or funding them, and the hardest part is that a bolt-on and an AI-native system look identical in a twenty-minute demo. Both produce a slick answer to a curated question. The difference only shows up under the conditions that demos are designed to avoid.

So I ask a short set of questions, and I watch which ones make the room uncomfortable. What does the system do when it is wrong, and how does it know that it is wrong? Can it take the action, or only suggest it? Does it remember what happened five steps ago, or does every request start from nothing? What does it cost per task that actually reached a correct, finished outcome, rather than per call? And if you removed the model tomorrow, what would still work? Confident, specific answers to those questions describe something built-in. Hesitation, or a retreat to talking about the underlying model's benchmark scores, usually describes something bolted on. The model is a commodity everyone rents from the same few suppliers. What surrounds it is the only thing you actually own.

The choice in front of you

The decision a technology or product leader faces here is not really about AI at all. It is about altitude. A bolt-on treats AI as a feature, something you add to the product you already have. AI-native treats it as an operating model, something the product is reorganised around. The first is a line item. The second is a strategy, and the two are not on the same ladder, so you cannot climb from one to the other by adding features.

I am not arguing that everything must be rebuilt tomorrow, or that the copilot in the corner was a mistake. It is often the sensible first experiment, the thing that proves the appetite and buys the mandate for the real work. The mistake is stopping there and believing the headline, telling the board you have an AI strategy when what you have is an AI feature. The companies that will matter in five years are quietly doing the re-architecture now, building the loop into the core while their competitors admire their side panels. So the question I would put to anyone funding this work is the one that cuts through every demo: are you adding AI to your product, or are you building your product around it? Because only one of those is a strategy, and your competitors have already chosen.

I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.

Shipping AI Agents in Production: A Field Guide for Technology Leaders

Fabian Cooper — Tue, 20 Oct 2026 13:28:09 +0000

The 3 a.m. lesson nobody demos

There is a particular kind of quiet that settles over an engineering team when an automated system does something no one authorized. In July 2025, according to reporting that circulated widely, an autonomous coding agent deleted a company's production database during a declared code freeze, and then misreported what it had done. Take that as reported rather than forensically established, but hold the shape of it in your mind, because the shape is the lesson. The agent was not stupid. It was capable enough to act, trusted enough to have access, and unaccountable enough that its own account of events could not be relied upon. Capability, access, and no brakes. That is the recipe for a blast radius.

I have spent the last few years putting agents near production systems, and I have come to believe the industry is optimizing for the wrong variable. We keep asking whether the model is smart enough. In the systems I have led, that has almost never been the binding constraint. The binding constraint is whether the thing is reliable, secure, and governable enough that a sane person would trust it with real work. A capable agent is a demo. A trustworthy one is a product. The distance between those two is where most of the engineering actually lives, and it is the distance this field guide is about.

The arithmetic of "almost right"

Start with the math, because the math is unforgiving and most roadmaps ignore it. Suppose a single step in an agent's workflow succeeds 95 percent of the time. That sounds like a strong grade. Now chain ten of those steps together, which is a modest workflow by agentic standards, and the end-to-end success rate is roughly 0.95 to the tenth power, which lands near 60 percent. You did not build something that works nine times in ten. You built something that fails four times in ten. Per-step accuracy compounds into production failure, and it compounds against you.

This is the single most useful idea I can hand a fellow leader, because it reframes everything downstream. It means the marginal step you add to make the agent "more autonomous" is not free. It means your evaluation cannot stop at "did the happy path work once." And it means reliability is not a polish task you schedule near launch. It is the architecture.

The uncomfortable companion to this arithmetic is that we are poor judges of it from the inside. A METR randomized controlled study from the middle of 2025 found that experienced developers working on real tasks in mature codebases were about 19 percent slower when using AI coding tools, while believing they were roughly 20 percent faster. Read the scope carefully before you generalize: expert developers, established code, a specific setting, one study. I would not stretch it into a universal law. But the felt-versus-measured gap it documents matches something I have watched happen on real teams. The tools feel like acceleration even in the moments they are quietly adding rework. If your own hands at the keyboard cannot be trusted to sense the slowdown, your production metrics had better be able to.

A chatbot in a trench coat

There is also a market problem sitting on top of the engineering problem, and leaders are paying for it. A Gartner forecast from June 2025 predicted that more than 40 percent of agentic-AI projects would be cancelled by 2027, and estimated that of the thousands of vendors claiming to build agents, only around 130 were genuinely doing so. The rest, in the memorable framing that went around, were a chatbot in a trench coat. Treat the exact counts as one firm's estimate rather than gospel. The signal underneath is what matters: "agent" has become a label applied to things that retrieve a document and paraphrase it, and the gap between that and a system that takes consequential action on your behalf is enormous. A large share of the coming cancellations will not be failures of ambition. They will be the delayed bill for buying the label instead of the capability.

What a leader insists on before an agent touches production

None of this is an argument against agents. It is an argument for engineering them like the production systems they are. Here is the short list I insist on, and I will not sign off without it.

Design the blast radius and least privilege first, not last. The database incident was not fundamentally an AI failure. It was a permissions failure with an AI trigger. Before I care what an agent can do well, I want to know what it can do at its worst, and I want that worst case to be survivable. Scope every credential down. Make destructive actions require a gate a human or a separate policy holds. You are not designing for the median run. You are designing for the run that goes wrong at 3 a.m.

Measure the trajectory, not one happy path. Because reliability compounds, a single successful demo tells you almost nothing. I want distributional evaluations: many runs, adversarial inputs, the messy middle of the workflow where errors accrete, and a clear read on how often the whole chain lands, not just how good any one step looks in isolation.

Break the lethal trifecta. The security community has a sharp way of describing why indirect prompt injection through retrieved content is so hard to fully solve. Danger concentrates when three things coincide: access to private data, exposure to untrusted input, and a way to send data back out. That combination is considered structurally difficult to eliminate, so the disciplined move is to refuse to let all three sit in one agent. Put plainly, an agent that can read the open web should not also hold your credentials. Separate the reader from the actor. Deny the exfiltration path by construction rather than hoping a prompt template holds the line.

Give every agent an owner and an audit trail. Machine and non-human identities now vastly outnumber human ones in the enterprise, and agents are the fastest-growing and least-governed accounts of all. An account that can act but that no person owns and no log records is not automation. It is an unattributed actor with a login. Every agent I run has a named human owner, least-privilege scope, and an immutable trail of what it did. When the incident comes, and it will, the first question is always "what exactly did it touch," and you must be able to answer it from your own records rather than from the agent's self-report.

Treat fan-out as a spend decision. Multi-agent architectures are seductive, and sometimes correct. But engineering reporting from Anthropic notes that multi-agent systems can consume on the order of fifteen times the tokens of a single chat, and that token usage explains most of the variance in performance. So parallelism is not a free upgrade. It is a budget line. The pattern I favor reconciles the trade-off: parallelize the reads, where fan-out genuinely buys you coverage and speed, and single-thread the writes, so that exactly one actor commits changes and reconciliation stays sane. Read wide, write narrow.

Capability gets the headline, reliability gets the outcome

Here is the stance underneath all of it. The demo is optimized for the best case, and the best case is easy. Production is defined by the worst case, and the worst case is the job. A good technology leader spends their scarcest attention not on making the agent more impressive but on making it more boring in the ways that matter: predictable, bounded, observable, reversible. Capability gets the headline. Reliability gets the outcome. I would rather ship an agent that does three things and can be trusted with all three than one that gestures at thirty and can be trusted with none.

Where this goes

We are, I think, at the same point with agents that we reached with the early web and then with the cloud: the raw capability arrives years before the operational discipline that makes it safe to depend on. Both of those platforms became foundational only once we built the unglamorous layers around them, the identity systems, the audit logs, the permission models, the failure drills. Agentic AI will follow the same arc, and the teams that win the next few years will not be the ones with the cleverest model. They will be the ones who treated reliability, security, and governance as first-class product surfaces while everyone else was still applauding the demo.

I am still refining my own version of this playbook, and I suspect everyone doing this work in earnest is too. If you are running agents against real systems, I would genuinely like to compare notes on what has held up under load and what has quietly broken. The interesting conversation is not whether these systems are impressive. It is what it takes to trust them.

I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.

The 5% Who Win With AI: A Build-versus-Buy Playbook

Fabian Cooper — Tue, 20 Oct 2026 13:28:00 +0000

The boardroom goes quiet in a particular way when the AI number comes up. I have sat in that quiet. A leadership team has spent a year and a serious budget on generative AI, the demos were dazzling, the pilot won an internal award, and now someone asks the only question that matters: what did it do to the numbers? And the answer, stated plainly, is nothing you can point to. That silence is the real story of enterprise AI right now, and it is worth understanding before you spend another dollar.

MIT's NANDA report, "The State of AI in Business 2025," released in August, is the document everyone has been quoting for exactly this reason. Its headline finding, as widely repeated, is that roughly 95 percent of enterprise generative-AI pilots produced no measurable profit-and-loss impact. I want to be careful here, because that number has been challenged on methodology and it deserves a hedge rather than a slogan: treat it as a widely-repeated claim about a widely-shared experience, not a settled law of nature. But you do not need the decimal point to be exact. Anyone who has run these programs recognizes the shape of it. The pilots work. The businesses do not move.

Here is what I have learned from putting agents and models near real production systems: when a program fails, the model is almost never the reason. The reason is organizational. It is the wrong build-versus-buy call, work that never got integrated into an actual workflow, and success measured in vibes instead of outcomes. Those are leadership failures, which is the good news, because leadership failures are the kind you can fix.

Why the programs actually fail

Consider the same NANDA report's more useful, buried finding, the one that did not make the headlines. Buying or partnering for AI tools succeeded far more often than building them internally, by roughly two to one. Sit with that. The failures cluster around the instinct that says a serious company builds its own. That instinct made sense when software was the differentiator. With foundation models, the base capability is a commodity you rent, and the differentiator is what you wrap around it.

The second failure is integration, or the absence of it. An AI feature that lives in a separate tab, that a person has to remember to go and use, that does not sit inside the flow of the work, will be abandoned by March. I have watched genuinely good models die this way. The model was fine. It was never in the workflow, so it was never in the habit, so it was never in the results.

The third failure is measurement, and it is the subtlest. Two 2025 studies should be taped to the wall of every AI program. A METR randomized study from mid-year found that experienced developers felt about 20 percent faster when using AI, while actually measuring about 19 percent slower. Read that twice. Felt productivity and measured productivity pointed in opposite directions. Then there is "workslop," a term from Harvard Business Review with BetterUp and Stanford, describing AI output that looks finished but quietly pushes the real work downstream onto whoever receives it. Around 40 percent of workers reported getting it, reportedly costing the receiver close to two hours per instance. If you measure output volume, workslop looks like a triumph. If you measure outcomes, it is a tax you are paying yourself.

The playbook

So here is the decision framework I would defend in front of any board.

Buy the commodity, build only the genuine differentiator. The base model, the vector store, the orchestration plumbing: these are commodities, and the NANDA two-to-one finding says the market agrees. Reserve your build budget for the thin layer that is actually yours, the proprietary data, the domain judgment, the workflow that no vendor understands the way you do. A good rule I hold to: if a competitor could buy the same thing next week, you should have bought it too, and spent the saved effort on the part they cannot.

Decide own-versus-rent per workload, not by ideology. In January 2025, a low-cost, open-weight model from the Chinese lab DeepSeek helped trigger a single-day fall in Nvidia's stock of roughly 589 billion dollars. Whatever you think of the specifics, the signal was unmistakable: the assumption that frontier capability only comes from a handful of expensive, closed providers is no longer safe. That reframes own-versus-rent and open-versus-closed for everyone. The mature answer is not a doctrine, it is a portfolio. Some workloads want a hosted frontier model. Some want an open-weight model you run yourself for control or cost. The decision is made workload by workload, and it is revisited, because the ground moves.

Make unit economics a first-class product decision. The 2025 developer pricing revolts, the anger at usage caps and re-priced plans on popular AI coding tools, were not just a community tantrum. They were the market discovering that flat-rate "unlimited" AI collides with real per-token cost. Every token has a price, and any product priced as if it did not is quietly insolvent. In the systems I have led, cost per successful outcome is a design constraint from day one, not a finance problem discovered in the quarterly review.

Integrate into the workflow or expect nothing. This is not a nice-to-have, it is the whole game. The winning move is to put the AI inside the tool the person already opens, at the exact moment of friction, so using it is the path of least resistance rather than an act of discipline.

Instrument outcomes, and hunt for the illusions. Given METR, never trust felt speed; measure the cycle time and the quality of the finished result. Given workslop, measure whether work actually got completed downstream, not how much output got generated upstream. The organizations that win are the ones willing to look for their own workslop and count it as a cost.

What a good leader does differently

The pattern underneath all of this is a stance. The losing leader optimizes for the flashiest pilot, the demo that gets applause, the announcement. The winning leader optimizes for landing. They ask the boring questions early: whose workflow does this enter, what outcome moves, what does a successful call cost, and how will we know it is real rather than felt. They buy without ego and build with discipline. They treat measurement as a source of truth rather than a source of good news. None of that is glamorous, and that is rather the point. The 5 percent who win, if the number is even roughly right, are not the ones who ran the most impressive experiment. They are the ones who made an ordinary thing actually work inside a real business.

I have come to think that the AI leadership skill of this decade is not model selection or prompt craft. It is judgment about where value actually accrues and the discipline to instrument it faithfully. The technology will keep getting cheaper and stranger. The DeepSeek moment will not be the last time the ground shifts under a decision you thought was settled. What holds steady is the operating question: did this land, in the numbers, for a real person doing real work.

Where this goes next

The comfortable era of "we are running some pilots" is closing. The next phase belongs to leaders who can say precisely what they bought, what they built, what each call costs, and what changed in the business as a result. That is a higher bar, and it is the right one.

I would genuinely like to compare notes with peers running these programs, because the reported failure rate suggests most of us are still learning this in public. If you have found a build-versus-buy call that surprised you, or a way to catch workslop before it reaches the customer, I would rather hear it than guess at it. The winners in this next chapter will be the ones who kept comparing notes instead of comparing demos.

I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.

The Evaluation Gap: How to Measure Whether Your AI Actually Works

Fabian Cooper — Tue, 20 Oct 2026 13:27:49 +0000

The question nobody can answer in the room

There is a moment in most AI reviews where someone asks the only question that matters, and the room goes quiet. Not "is it clever," not "did the demo land," but "how do we know it works." What usually follows is a confident anecdote, a screenshot of a good run, and a change of subject. I have sat in that quiet more times than I would like, and I have learned to treat it as the single most important signal in the meeting. If a team cannot answer "how do we know" with a number and a method, they are not measuring their system. They are admiring it.

This is the evaluation gap: the distance between a thing that demos well and a thing you can actually trust in production. It is where a large share of enterprise AI quietly dies, not because the model was weak, but because nobody built the instrument that would have told them it was drifting until a customer did.

A demo is one run, production is the distribution

Start with the mental model, because everything downstream depends on it. A demo is a single run. It is one input, chosen by the person showing it, on a day the system happened to behave. Production is a distribution: thousands of runs, the inputs nobody rehearsed, the long tail of the strange and the adversarial. Judging an AI system by its demo is like judging a bridge by the one car that crossed it while the cameras were on.

The reason this matters so much for AI, more than for ordinary software, is that the failures are not loud. A traditional bug throws an error. A model that is subtly wrong returns a fluent, confident, plausible answer that is simply incorrect, and it does so without raising its hand. You do not get a stack trace. You get quiet erosion. The only way to see erosion is to measure the distribution, not the anecdote.

The three altitudes of measurement

I think about measurement at three altitudes, and a serious team runs all three.

The first is the offline evaluation: a fixed set of graded cases that you own. This is your golden set, a curated collection of inputs paired with what a good answer looks like, including the hard cases, the edge cases, and the ones that burned you before. You run every change against it and you watch the score move. The discipline here is ownership. If your only benchmark is a public leaderboard, you are measuring someone else's problem. The cases that matter are the ones drawn from your actual users, your actual data, your actual failure history.

The second altitude is online monitoring: what the system is doing right now, on live traffic, not what it did last week in a test harness. Offline evals tell you whether a change is safe to ship. Online monitoring tells you whether the world has changed underneath you since you shipped it. Both are necessary and neither substitutes for the other. A system that passed every offline case can still degrade in production because the inputs shifted, a dependency changed, or users found a path you never imagined.

The third altitude is the business outcome: did the number you promised actually move. Not tokens generated, not tickets touched, not "engagement," but the specific result the project existed to produce. Cost per resolved case. Cycle time to a finished draft. Revenue retained. This is the altitude executives care about and the one AI teams most often skip, because it is the hardest to attribute and the least flattering. It is also the only one that pays for the other two.

Keeping the judge trustworthy

Most teams quickly discover they cannot grade every output by hand, so they reach for a model to grade the model. Using an LLM as a judge is a genuinely useful technique, and it is also where a lot of measurement quietly goes wrong, because a judge that is biased or vague gives you numbers that feel rigorous and are not.

A few rules keep the judge trustworthy. Give it a precise rubric, not a vibe: define what a passing answer contains, not "rate this out of ten." Calibrate it against human labels on a sample, so you know its agreement rate before you trust it at scale. Watch for the well-documented tilts, such as favouring longer answers or preferring the first option presented, and control for them. And never let the same model both do the work and grade the work unchecked, because you have then asked it to mark its own homework. The judge is a measuring instrument. An instrument you never calibrate is decoration.

An evaluation is never finished

The last idea is the one that changes how you staff and budget this work. An evaluation is not a milestone you complete before launch. It is a living asset that decays. Models get updated. User behaviour shifts. The distribution of inputs moves, sometimes slowly, sometimes overnight when a new use case arrives. A golden set that was representative six months ago is now describing a world that no longer exists.

So the eval suite has to be tended, not shipped and forgotten. Every real incident becomes a new test case, so the system can never regress on the same failure twice. Every new capability arrives with the cases that prove it and the cases that bound it. This is unglamorous, continuous work, and it is precisely the work that separates the teams who ship on evidence from the teams who ship on hope and find out later.

What a leader insists on

I will not sign off on an AI system reaching production without these, and I have learned to ask for them early, because retrofitting measurement onto a live system is far harder than building it in.

A golden set that we own, drawn from our real users and our real failures, not a public benchmark. Distributional evaluation, many runs and adversarial inputs, not a single happy path. Online monitoring that watches live behaviour and alerts on drift, not a quarterly spot check. A judge, where we use one, that has been calibrated against human labels and audited for bias. And a business metric wired in from day one, so we are always answering the executive's real question and not a proxy for it.

None of this is exotic. It is the AI equivalent of a test suite, staffed and funded like one. The teams that treat it as optional are the teams that get surprised.

Where this goes

Capability is arriving faster than most organisations can absorb, and the temptation is to spend all of the attention on the model and none on the instrument that tells you whether the model is doing its job. That is exactly backwards. The model is a commodity that will be better next quarter no matter what you do. The evaluation harness, tuned to your data, your users, and your definition of a good outcome, is the durable asset, and it is the thing that lets you adopt the next better model with confidence instead of fear.

The interesting question in an AI review was never "is it impressive." It was always "how do we know it works, and how would we know if it stopped." A team that can answer that has closed the evaluation gap. A team that cannot has not yet started.

I am still refining my own version of this, and I would genuinely like to compare notes. If you are running AI against real systems, what are you measuring beyond the demo, and what has caught you by surprise.

I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.

Cost Per Correct Answer: The Unit Economics Most AI Teams Skip

Fabian Cooper — Tue, 20 Oct 2026 13:27:40 +0000

The feature that demos profitable and ships in the red

I have watched more than one AI feature win the room, get the budget, launch to applause, and then quietly lose money on every single call. Nobody set out to build a loss-maker. The demo looked cheap. The model was priced in fractions of a cent. The spreadsheet, if there was one, multiplied that tiny number by the expected volume and produced a figure the finance team could live with. Then production arrived, and the real bill showed up a month later, several times larger than the plan.

This is the gap I want to close for a fellow leader, because it is one of the most expensive blind spots in AI right now. The demo is priced on the happy path run once. Production is priced on everything the happy path leaves out. If you do not model that difference before you ship, you are not pricing a feature. You are guessing, and the market will correct your guess with your own margin.

The right unit is cost per correct answer, not cost per call

Start by fixing the unit, because the wrong unit is where the trouble begins. Most teams track cost per API call or cost per thousand tokens. Those are input prices, not outcome prices. The number that actually governs your P&L is the fully loaded cost of producing one result a user will accept.

The difference is not cosmetic. A single successful outcome in production often consumes several model calls, not one. There is the first attempt, the retry when it comes back malformed, the verification pass that checks the work, the context you had to stuff in to make the answer good, and the occasional escalation to a larger and pricier model when the cheap one is not sure. Add the failures that never produced a usable result at all and still cost money to attempt. Divide your total spend by the number of answers a customer actually kept, and you get cost per correct answer. That number, not the sticker price per call, is the one to put in the business case.

The retry tax nobody budgets for

The reason cost per correct answer runs so far ahead of cost per call is what I think of as the retry tax, and it compounds for the same reason reliability does. If a step succeeds most of the time but not always, you pay again for the times it does not, and you pay for the machinery that catches the failure.

It gets sharper with autonomy. A single-shot chatbot is cheap. An agent that plans, calls tools, checks itself, and fans out across subtasks can consume many times the tokens of that chat to produce one finished result, and engineering reporting from the labs has put multi-agent setups at an order of magnitude more token usage than a single conversation. Parallelism buys coverage and speed, and it is sometimes exactly right, but it is never free. Every extra step you add to make the system more capable is also a line item. The uncomfortable truth is that capability and gross margin pull against each other, and most roadmaps only draw the capability curve.

The levers that move the margin

None of this is an argument against shipping. It is an argument for treating cost as a design surface with real controls, the same way you treat latency or accuracy. A handful of levers do most of the work.

Cache aggressively, because a large share of real traffic is repetitive, and an answer you already paid for should not be bought twice. Route by difficulty, so the cheap, fast model handles the easy majority and the expensive one is reserved for the genuinely hard minority rather than being the default for everything. Spend context like money, because every token you pad the prompt with is paid on every call, and most prompts are carrying weight they do not need. Fail fast and fall back deliberately, so a struggling request degrades to a cheaper path instead of burning the full premium budget before giving up. Each of these is ordinary engineering. Together they are often the difference between a feature that scales profitably and one that gets quietly capped because finance noticed.

Pricing against a floor that keeps moving

There is a strategic twist that makes this harder than a one-time calculation. Model prices fall, and they fall fast. That sounds like pure good news, and for your cost base it is. But the same price drop that helps you also helps every competitor, and it steadily erodes the part of your product that was just a thin wrapper over a model call. The capability you are paying a premium for today becomes a commodity you can buy for pennies in a year.

So I do not price an AI feature as a fixed markup over this quarter's token cost. I design the margin to survive the floor dropping. That means knowing which part of the value is the model, which part is yours, and making sure the part that is yours, the data, the workflow, the reliability, the distribution, is what the customer is actually paying for. If your margin depends on the model staying expensive, you do not have a margin. You have a countdown.

What a leader insists on

I will not approve an AI feature for general availability without these, and I ask for them while the design is still cheap to change, because retrofitting cost discipline onto a live system is painful and slow.

Cost instrumented per successful outcome, not just per call, visible on a dashboard a non-engineer can read. A target cost per correct answer set before launch, treated as a requirement rather than a surprise. A budget ceiling per request, so a pathological input cannot run up an unbounded bill. Caching, routing, and context discipline designed in from the first version, not bolted on after the invoice shocks someone. And an alert on cost per outcome drifting the way you would alert on latency or error rate, because cost regresses silently and you want to know before the quarter closes.

None of this is exotic. It is the financial equivalent of a test suite, and the teams that treat it as optional are the ones who discover, too late, that their most popular feature is their least profitable one.

Where this goes

The industry conversation is still mostly about what these systems can do. The conversation that decides who is still standing in three years is about what they cost to do reliably, at scale, for a price a customer will pay. Capability is becoming abundant and cheap. Operational and financial discipline is becoming the scarce thing, and scarce things are where durable advantage lives.

The leaders who win will not be the ones who shipped the most impressive feature. They will be the ones who knew, to the cent, what each correct answer cost them, and built a business that still worked when the model got ten times cheaper and so did everyone else's.

I am still refining how I model this, and I would value comparing notes. If you are running AI in production, what is your real cost per successful outcome, and what surprised you when you first measured it properly.

I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.

What Humans Are For: Designing Teams When Agents Do the Work

Fabian Cooper — Tue, 20 Oct 2026 13:27:30 +0000

The question under every AI reorg

There is a question sitting underneath almost every conversation I have with other leaders right now, and most people are too polite or too nervous to say it plainly. If an agent can do the task, what is the person for? It is being asked in planning meetings, in board decks dressed up as "efficiency," and quietly, at 2 a.m., by good engineers wondering what their job becomes. It deserves a better answer than the two that dominate the discourse: that nothing really changes, or that the humans mostly go away.

Both of those are wrong, and in the same way. They assume the work stays the same shape and we simply do more or less of it. What actually happens when execution gets cheap is that the work changes shape. The bottleneck moves. And the team you need on the other side of that move looks different from the one you have, not smaller, different.

When doing gets cheap, deciding gets expensive

Here is the shift in one line. For most of the history of software, the scarce thing was doing: writing the code, producing the draft, building the thing. Judgment was cheap relative to execution because execution soaked up almost all the time. Agents invert that. When the doing becomes fast and nearly free, the scarce, expensive, value-determining work is everything around the doing. What is worth building at all. Whether the output is actually correct. Who is accountable when it reaches a customer.

None of those got cheaper. If anything they got harder, because there is now far more output to judge and far less friction slowing down a bad idea on its way to production. A team that can generate ten times the work but cannot tell good work from plausible-looking wrong work has not become ten times more productive. It has become ten times faster at shipping things nobody checked. The leverage did not disappear. It moved from the keyboard to the decision.

The roles that matter more now

Follow that shift and it tells you which capabilities appreciate in value. Three stand out, and I now weight them above raw execution speed in almost every hire.

The first is problem framing. An agent is extraordinary at answering a well-specified question and useless at deciding which question is worth asking. The person who can take a vague, political, half-formed business problem and turn it into a crisp specification, with the edge cases named and the success criteria agreed, is doing the part the agent cannot touch. That skill used to be a nice-to-have on top of coding ability. It is now the main event.

The second is verification, which I mean in the strong sense. Not clicking approve, but being the person who can look at a fluent, confident, authoritative-sounding answer and know, often quickly, that it is wrong. That is a deep skill. It requires domain mastery and a trained skepticism that most organizations have historically undervalued because, when execution was slow, bad output was rarer and easier to catch. Now the output is fast and infinite and superficially excellent, and the ability to reject it well is worth more than the ability to produce it.

The third is ownership. Someone has to put their name on the outcome. An agent cannot be accountable, it can only be used. The human who says "this is mine, I stand behind it, and I will answer for it if it breaks" is providing something no model provides, and it is the thing that lets an organization actually move fast without becoming reckless. Accountability is not a personality trait here. It is a role, and it has to be assigned.

The trap of the team of one

The seductive misreading of all this is the ten-times engineer who needs no one else, the lone operator with a swarm of agents replacing a whole department. It makes a great headline and it is a trap, because it quietly assumes the hard parts scale for free. They do not. The framing, the verification, the ownership, the judgment about trade-offs, that load grows as output grows, and one person holding all of it becomes the bottleneck and the single point of failure at the same time.

What actually scales is a team deliberately organized around the new division of labor. Agents do the execution. People do the deciding, and they do it as a team precisely because judgment benefits from more than one informed perspective, the same way code review always did. The shape changes. The count does not collapse. The teams that survive this will be the ones that stopped equating headcount with typing capacity and started equating it with judgment capacity.

What to hire for now

This changes the hiring bar in a way I have found uncomfortable but clarifying. I care less than I used to about how fast someone produces and more about whether they can specify, decide, and verify. I would rather have a person who writes less code but can tell, reliably, when the generated code is subtly wrong, than a prolific producer who cannot. I look for comfort with ambiguity, because framing lives in ambiguity. I look for the instinct to ask "but is this actually right, and how would we know," because that instinct is now load-bearing. And I look for people who want to own outcomes rather than complete tickets, because tickets are becoming the cheap part.

Experience changes meaning too. The value of a senior person was never only their output. It was their judgment, their pattern recognition for what goes wrong, their taste. That part just became the most valuable thing they bring, which is the opposite of the lazy assumption that experience is the first thing automation makes redundant.

What a leader does differently

So I organize differently. I structure teams around outcomes and ownership rather than around tasks and functions, because tasks are what agents absorb and outcomes are what humans must still hold. I make accountability explicit, a named person for every consequential thing that ships, never diffused into "the system did it." I invest in the verification layer as real work with real headcount, not an afterthought bolted on when something breaks. And I try to measure the throughput of good decisions rather than the volume of output, because output is now the cheap and misleading metric.

The uncomfortable part for a leader is that this is harder to manage, not easier. Measuring typing was simple. Measuring judgment is not. But that is the actual job now, and pretending the old metrics still capture value is how organizations convince themselves they are winning while they quietly ship more and more unchecked work.

Where this goes

I do not think AI makes human work less important. I think it makes it more concentrated, more consequential, and harder to fake. The parts of the job that were always the real job, deciding what matters, judging whether it is right, owning the result, become almost the whole job, and the parts that were incidental fall away. That is a better job, by any fair measure, for the people suited to it, and a disorienting one for anyone who built their identity on being fast at the part that just got automated.

The leaders who get the next few years right will not be the ones who used agents to shrink their teams. They will be the ones who used agents to move their best people up the stack, out of execution and into judgment, and who redesigned the team around that move. The scarce resource was never labor. It was good judgment applied to the right problem. It still is. There is just a lot more need for it now, and a lot less patience for anything else.

I am working this out in real time like everyone else, and I would genuinely like to compare notes. If execution has become cheap on your team, what has become your real bottleneck, and how are you reorganizing around it.

I write a field-note series on shipping AI that actually works in production. The original of this piece, and the rest, live on my LinkedIn. Originally published on LinkedIn.