The Compiler Your Company Never Had

My first real lesson about feedback came at Yahoo, and it came in two halves.

The first half: when my code was wrong, the machine told me. Fast, precisely, without politics. A build broke, a test failed, a graph spiked, a pager went off. Being wrong was cheap because being wrong was visible. You fixed it and you got better, and everyone around you got better the same way, compile after compile, incident after incident.

The second half took me years to see. In that same building, people were making decisions that mattered a thousand times more than my code: which products to fund, which partners to sign, how to price, whom to promote. And for those decisions there was no compiler. Nobody got a red X. Outcomes arrived months later, tangled with everything else that had happened in between, and by then the organization had already told itself a story about why things went the way they went. The engineers were wrapped in a feedback loop. The organization was wrapped in a narrative.

I have spent most of my career since then inside that asymmetry, at Cask, inside Google, at DataRobot, and now building with AI every day. This series is my attempt to finally write down what I think it means, because AI has just made the asymmetry the most important open problem in enterprise software.

Here is the puzzle that motivates everything that follows. The most impressive AI systems in the world right now are coding agents, and the honest reason is not that models suddenly understand software better than they understand sales or supply chains. It is that a coding agent operates inside an unusually favorable environment.

The state of a coding agent's world is largely explicit: files, repositories, dependencies, runtime state, test fixtures. Its actions are machine-executable. Feedback is fast. A compiler or a test suite is usually an objective verifier. Failed actions are comparatively cheap to reverse, and the agent simply tries again. Wrap a strong model in that loop and it improves at a rate that still startles me, and I build with these things daily.

Human enterprise work has almost none of those properties. The state of a customer negotiation is spread across CRM fields, email, a call transcript, a spreadsheet, the salesperson's memory, the customer's internal politics, and facts nobody has written down. Decisions get made implicitly rather than declared. An action may not produce an observable result for months. Several people act at once. The outcome can depend more on external circumstance than on the decision itself. And there is rarely a single "test passed" signal.

Read that table the way an engineer reads a diff. Every row is a reason the naive plan, "just point agents at the enterprise," keeps disappointing people. And the disappointment is measurable: McKinsey's latest global survey finds AI use widespread and scaling, yet only 37% of respondents say AI has contributed positively to EBIT, and the small group of high performers is distinguished mostly by redesigned workflows and defined processes for measuring impact.¹ Stanford researchers who examined 51 enterprise implementations reached the same uncomfortable conclusion from the other direction: wildly different outcomes with similar technology, explained mostly by organizational readiness, process, and willingness to change, not by the model.²

AI can perform the task. The enterprise cannot reliably observe whether the task led to the right downstream result. That gap is the next major problem in enterprise AI.

The temptation, once you see the table, is to conclude that enterprises simply cannot have what coding agents have. I spent a long time believing a version of that. I no longer do, and the reason is a distinction that took me an embarrassing number of years to articulate.

We should not try to reproduce the coding loop literally. We should reproduce its learning properties.

Strip the compiler and the test suite away, and the coding loop teaches its agent because it does seven specific things. It maintains enough state to understand what was attempted. It knows, or estimates, the goal being pursued. It preserves what decision was made. It observes the action that followed. It captures intermediate and final consequences. It compares the trajectory with prior trajectories or controlled alternatives. And it feeds the evidence back into the next decision.

Nothing in that list says "compiler." Nothing in it says "deterministic." Those seven properties are a specification, and the rest of this series is about what it takes to satisfy that specification in a world made of people.

Here is the shape of the loop when you translate it to the analog world:

The obvious objection is the verifier. There is no pytest for a sales negotiation. That is true, and it is also the wrong standard. Instead of a compiler, the enterprise gets a portfolio of weak verifiers: Was the customer response positive? Was the item reopened? Did a manager override the recommendation? Did the case move to the next state? Was there rework? Did an SLA improve? Was margin preserved? Did a risk event occur? Was the action later reversed? Did the same problem recur?

No one signal is the truth. Together they close surprisingly useful loops. I have watched this work in miniature my whole career: the best operators I have known, at Yahoo, at Cask, inside Google, carried exactly this portfolio in their heads. They just could not scale it past the size of one human memory.

So here is the claim I will spend five more essays defending, refining, and stress-testing:

The right objective is not a perfect causal digital twin of the enterprise. It is a decision-and-outcome observability layer that turns enough real work into reconstructable trajectories that AI can compare, evaluate, learn from, and gradually act on.

This is not a hypothetical direction. Without using a common name for it, the market is converging on exactly this architecture: process mining is being wired to agents, task mining is capturing human-computer activity in detail, Microsoft is building a semantic workplace context layer for agents, Palantir describes the enterprise as a decision-centric ontology with lineage, and orchestration products are putting agents, automations, systems, and humans into the same governed workflows.³⁴ The pieces are assembling in public, under six different product-category names, and I do not think most of the builders have noticed they are building the same thing.

What that thing must actually capture, and the trap that ruins it if you capture too much, is where this series goes next. The unit of organizational learning is not a document, a meeting, or a click. It is something smaller than a project and bigger than a keystroke, and getting it right is the difference between building a learning organization and building a surveillance machine that learns nothing.