Program as Code: The Full Argument

Every program I’ve ever run has had 2 versions of itself. There’s the work, which happens in repos and racks and vendor threads and somebody’s head. And there’s the account of the work, which lives in a status field, a slide, and a sentence I said in a review.

The account is not the work. Everybody knows this. We say it out loud and then we make decisions against the account anyway, because for most of the history of the discipline the account was the only thing that could be held in one place and looked at.

That was the starting point for this site. Reading Jean Baudrillard’s Simulacra and Simulation gave me a name for the failure mode: simulation bias. A representation begins as a useful account of reality, then becomes the thing the organization manages. AI does not create that problem. It makes the account cheaper, more convincing, and capable of triggering action before anybody checks the work beneath it.

That constraint is dissolving. Not because reporting got better, but because the work itself is becoming legible to machines. Requirements can carry structure. Dependencies can emit signals. Decisions can carry provenance. And for the first time, something other than a human can read all of it, reason over it, and change the state of the program.

This essay is the long version of the argument the rest of this site is built on. I’ll try to be specific about what I think is changing, honest about what I’m guessing at, and clear about the parts I think will go badly.

Since first publishing it, I’ve found a deeper model underneath Program as Code: a program is a dynamic network of commitments under uncertainty. Program as Code is the implementation philosophy for making enough of that network explicit, typed, versionable, and inspectable that software can reason and act against it. The distinction clarifies the argument without replacing it.

1. The reporting-centered model

Start with what we actually built, because it’s a coherent system and it deserves to be described accurately before it gets replaced.

The discipline is organized around producing a periodic, authoritative account of a program’s state. Every ritual serves that: the standup samples, the status template normalizes, the review broadcasts, the steering committee ratifies. Underneath all of it is one assumption. Getting information out of where work happens is expensive, so we do it on a schedule and we compress hard.

That assumption produced 4 structural properties.

Sampling. State is observed at intervals rather than continuously. Anything that changes between samples is invisible until the next one, and the interval is set by human availability rather than by how fast the program actually moves.

Compression. 40 signals become 1 color. This is not a flaw, it’s the product. An executive reviewing 30 programs cannot hold 1,200 signals. But compression discards the variance, and variance is where risk lives.

Human routing. Every hop from work to decision passes through a person who has an interest in how the information lands. Not fraud, mostly. Rounding. A yellow that could defensibly be a green, held for one more week because the fix is nearly in.

Recomputation from scratch. Nothing accumulates. Last quarter’s dependency map is a stale artifact, not a data structure. The reasoning behind a decision lives in a thread nobody will find again. The program has no memory that outlives the people in it.

Every one of those is a rational response to expensive information. Change the cost of information and all 4 stop making sense at once.

2. Why AI changes more than administrative efficiency

The common version of the AI story in this discipline is a productivity story. The tool drafts your status, summarizes the channel, cleans up the deck. You get 4 hours back.

That’s real, and it’s the least consequential part.

The loop I described has 3 stages: collect, narrate, decide. AI hits them unevenly, and the unevenness is the whole story.

Once work is sufficiently instrumented, the marginal cost of querying program state collapses. The difficult work moves upstream into instrumentation, semantics, provenance, and governance. Sampling can become querying where the execution surface permits it. Supplier knowledge, physical work, regulatory approvals, and facts held in a person’s head keep the system partially observable.

Narration collapses toward zero and gets more persuasive at the same time. Here’s the problem. A generated summary arrives fluent, structured, and confident. It reads like a careful analyst wrote it. It does not carry the analyst’s hesitation, because there wasn’t any. The 3 months of hallucinated analytics I wrote about in February weren’t caught by a control. They were caught because somebody happened to ask for a sanity check. The output had been indistinguishable from correct that entire time.

Decision separates into 3 kinds. Deterministic decisions can become policy. Bounded decisions and actions can increasingly be delegated to agents. Accountable judgment remains human where there is genuine ambiguity, conflict, strategic tradeoff, values, material consequence, or authority that cannot legitimately be delegated.

The durable human responsibility is accountable judgment and authority where the system cannot legitimately own the consequence. It is not every decision. The center of gravity moves toward designing those boundaries and keeping the cheaper stages connected to reality.

3. Commitment networks made machine-readable

The underlying program model is a network of commitments among actors about what will become true, by when, under what conditions, for whom, with what evidence, and with what degree of uncertainty. A dependency is not fundamentally a row with a team and a date. It is a provider’s commitment to a consumer. Requirements, interfaces, schedules, supplier dates, decisions, approvals, and milestones are other views into the same network.

“Program as Code” is the implementation philosophy, not a literal claim and not the deepest layer. Nobody is compiling an organization. The aim is to make enough of the commitment network explicit, typed, machine-readable, versionable, and inspectable that software can reason and act against it.

Here’s the list I keep coming back to.

Machine-readable requirements. A requirement written so a system can check it against a build is also a requirement 2 humans can argue about precisely. Most requirement defects are ambiguity defects, and ambiguity is currently discovered in the review where somebody says “wait, I read that differently.” Structure moves that discovery to the left.

Explicit dependencies. Today a dependency is a row in a spreadsheet with an owner and a date, maintained by hand, wrong within 2 weeks. A dependency with an interface definition, an owner, an evidence source, and a freshness timestamp is an object the system can watch.

Versioned decisions. Software has been doing this for a decade with architecture decision records. Programs mostly don’t. The consequence is that 6 months later nobody can reconstruct why the region was cut, so the argument gets relitigated from zero by people who don’t know it already happened.

Derived state. Status becomes a function over evidence rather than a value somebody types. If the inputs are stale, the output says so rather than quietly aging.

Feedback that changes execution. The last one, and the one that makes it a system rather than a database. When a pattern of failure is detected, the rule that prevents it gets written back into how work is intake’d, reviewed, or gated.

4. From status collection to observability

Software operations solved a version of this problem 15 years ago and the vocabulary transfers better than I expected.

A service used to be monitored: a fixed set of checks, defined in advance, answering questions somebody thought to ask. Then systems got complicated enough that the interesting failures were the ones nobody predicted, and the discipline moved to observability. Emit enough structured signal that you can ask a question you didn’t anticipate, after the fact, without shipping new instrumentation.

Program status is monitoring. It’s a small fixed set of predefined checks (are we on schedule, are we on budget, is anything red) reported on a cadence, and it answers only the questions the template thought to ask.

Program observability would be the ability to ask an unanticipated question about the state of the work and get an evidence-backed answer without convening anyone.

The analogy has limits and I want to name them rather than ride it too far. Services emit their own telemetry honestly because a service has no incentive to look good. Organizations have incentives all the way down, and any signal that becomes a performance measure will be optimized against. That’s Goodhart’s law and it doesn’t care how good your pipeline is.

Still, the reframe changes what you build. Under monitoring you ask “what’s our status.” Under observability you ask “what evidence supports that status, how old is it, and what would have to be true for it to be wrong.” I’ve sketched a first pass at what those signals could be in Program Observability.

5. A working architecture, not a category

A working architectural model I am beginning to test connects the commitment network to sensing, execution, and governance. Program Observability reconciles evidence into state. Program Runtime is where humans, agents, and deterministic systems act. A Program Control Plane carries authority, policy, and intervention.

I am using Program Operating System as the provisional name for the complete architecture. Program as Code enables it by making the relevant parts of the program machine-legible. The name has not earned category status, and the architecture has not been validated. It is useful right now because it forces claims about sensing, execution, and governance into separate boxes that can fail separately. The initial system page describes the model and the planned test.

The analogy is limited. Organizations are not computers, humans are not processes, and authority is not a permission bit. The useful part is the environment through which execution occurs across software systems, agents, humans, suppliers, and physical work.

6. Agents as participants in execution

Agents make familiar coordination defects happen faster. Without shared ownership state, they duplicate work. Without explicit authority, they either push executable work back to a person or act beyond the boundary anyone intended. Without integration design, locally correct changes collide at the interfaces.

Those are standard program failures: unclear ownership, unnecessary handoffs, and work crossing boundaries without an integration plan. The useful lesson is architectural. Agent capability does not remove the need for intake rules, interface contracts, definitions of done, and a shared account of claimed work. It makes weaknesses in those structures more expensive.

Agents belong inside the Program Runtime as bounded execution participants. The surrounding system still has to determine what they can observe, what they may change, when a person must decide, and how their actions become evidence.

7. The TPM as a systems engineer for organizational execution

As querying gets cheaper and execution partially automates, the durable work is engineering the system through which the organization executes. Agent orchestration is one part of that runtime, not the job thesis.

System designer. You decide what counts as evidence for this program, which signals are load-bearing, what the interface between 2 teams actually is in a form both sides can be held to, where the gates sit, and what a gate is allowed to block. This is architecture applied to an organization instead of a codebase.

Governor. When an agent can file a dependency, accept a requirement, or close a task, somebody has to decide what an agent may commit on the organization’s behalf, what needs a human signature, how an automated decision gets reversed, and who’s accountable when it isn’t caught. Most teams are answering this right now by accident, through whatever their tooling happens to permit by default.

Auditor of the representation. The dashboards get better and the gap between the dashboard and the work gets harder to see, not easier. A confident wrong answer is more dangerous than a hedged wrong answer, and the systems are getting more confident. Somebody has to keep pulling threads.

Resolver of ambiguity. Agents execute under-specified tasks readily and rarely notice they should have refused. The undefined case is still where a human has to go, and the volume of undefined cases goes up as throughput goes up.

Accountable owner. Authority and consequence do not distribute cleanly across a fleet. Somebody still accepts the outcome.

8. What must remain human

I want to be careful here because the failure mode of this genre is a story where people become polite overhead standing near the machines. That’s not what I think, and I don’t think the evidence supports it either.

Ambiguity that isn’t a defect. Some ambiguity is a bug in the requirement. Some of it is 2 executives who haven’t agreed and are using vague language on purpose so the disagreement stays deferred. A system will treat both as the same missing field and try to resolve them the same way. Only one of them is resolvable by writing a clearer sentence.

Incentives. A system trained on an organization’s artifacts learns the organization’s incentives along with everything else, including the padding, the optimism, and the things nobody writes down. Reading an estimate correctly often means knowing that the team got burned last time. That context lives in relationships.

Conflict. Arbitrating between 2 directors who both need the same quarter is not an information problem. Getting more accurate data does not make it easier and sometimes makes it harder.

Ethical and strategic tradeoffs. Whether shipping on the date is worth the reliability risk, or whether a shortcut is acceptable, has an answer that depends on values and consequences somebody has to own.

Deciding the system is wrong. This is the important one. Any system built to derive truth from evidence will, at some point, derive a confident wrong answer from evidence that was itself wrong. Recognizing that requires standing outside the system, which by definition it cannot do for you. The ability to say “the model says green and I’m telling you it’s red” has to survive, and it has to survive politically, which is harder than making it survive technically.

9. New risks and failure modes

Some of these are old problems with a new coat. Some are genuinely new.

Simulation bias at machine speed. The core one, and the reason I keep writing about it. When the representation is generated faster and reads better than any human could produce, the incentive to verify it drops exactly when the need to verify it rises.

Evidence laundering. A stale input flows through 3 transformations and comes out the other side as a clean number with no visible age. Provenance is easy to lose and nobody misses it until they need it.

Agent-to-agent failure modes. The duplicated-branch problem I hit is the toy version. In an organization, agents negotiating with agents means failures that no human ever reads, in a chain no human ever sees, at a speed no human review cadence catches. The 2035 essay imagines an agent framing a large dependency as a small one because it was optimizing for its own date. I don’t think that’s far-fetched. I think it’s the default behavior of any optimizer with a local objective.

Accountability diffusion. A decision with 6 automated inputs and 1 human signature. When it goes wrong, the human signed something they could not have fully evaluated, and the automated inputs cannot be held responsible. This is unsolved and I don’t have an answer.

Instrumented work driving out uninstrumented work. Whatever the system can see becomes what the organization manages. Anything outside the telemetry stops existing for planning purposes, which is how you end up optimizing the measurable half of a program into the ground.

Governance theater. The approval gate exists, a human clicks it, and the human has no realistic ability to evaluate what they’re approving. This is the most likely outcome for most organizations, because it satisfies the audit requirement at close to zero cost.

10. What this means for technical organizations

If any of this is right, a few things follow that are not primarily about tooling.

Requirement quality becomes an engineering concern with a budget. Ambiguity currently costs time in reviews. In a system where agents execute against requirements, ambiguity costs shipped work built against the wrong reading. That moves requirement quality from a soft skill to a measurable input.

Interfaces between teams need to be written down the way API contracts are. What one team can expect from another, in what form, on what latency, with what happens on breach. Most cross-team “dependencies” today are a name, a date, and a hope.

Decision latency becomes a visible cost. When execution runs fast and continuously, the pauses where work sits waiting for a human to decide become the dominant term. Organizations that have never measured how long a decision takes are going to find out.

Evidence infrastructure is a real investment. Somebody has to own the pipes that make execution data trustworthy. That’s a platform team’s job, and it competes for funding against features, which means it usually loses until something breaks badly.

And the physical world still sets the pace. Programs with hardware in them, capacity in them, or a regulator in them cannot be sped up by making the software half more legible. Long lead times don’t compress because your dashboard improved. I’d rather over-state this than under-state it, because this genre routinely forgets that some constraints are made of atoms.

11. Open questions

I’d rather leave these open than pretend the framework is finished.

I’ll be working these out in public. If a piece of this is wrong, I’d genuinely rather find out early, so tell me.