Program as Code

Program management, as most organizations practice it, is a collection discipline. Someone gathers information that already exists somewhere, reconciles the versions that disagree, assembles it into a representation, and narrates that representation to people who make decisions.

That work is real and genuinely hard. It’s also increasingly the part of the job a machine can do.

The argument on this site is that the discipline is moving from collecting and narrating work toward designing, observing, and governing the systems in which work gets executed. Program as Code remains my shorthand for the implementation philosophy behind that shift. The deeper model underneath it is starting to come into focus.

A program is a dynamic network of commitments under uncertainty.

The problem came first

I started with simulation bias.

Reading Jean Baudrillard’s Simulacra and Simulation gave me a way to describe something I had watched programs do for years. The status deck begins as a representation of the work. Over time, the organization makes decisions against the deck, rewards the deck, and repairs the deck. The representation can become more operationally real than the work it was supposed to describe.

AI raises the stakes. It can produce the account continuously, make it unusually persuasive, and act on it before a person notices that it has drifted. If we do nothing, we automate the gap between reported reality and observed reality. Everything else in this thesis is an attempt to keep that from happening: represent the program more faithfully, preserve uncertainty, trace claims to evidence, make authority visible, and keep execution capable of correcting its own model.

The program underneath the plan

A dependency is usually represented as a row with a team and a date. The row is only an artifact. Underneath it is a commitment by one actor to make something true, under some condition, by some time, for another part of the system.

The same model connects objects we usually manage separately:

• A requirement is a commitment about an intended outcome or behavior.
• A dependency is a commitment from a provider to a consumer.
• An interface is a commitment about the form and condition of a handoff.
• A supplier date is an external delivery commitment.
• A schedule is a network of temporal commitments.
• A decision or approval creates, changes, or retires commitments.
• A milestone becomes true when a set of commitments is satisfied.

Each commitment has an actor, a beneficiary, conditions, evidence, timing, authority, and some degree of uncertainty. A change to one can propagate through the network. A new supplier date changes an interface commitment, which moves an integration window, which can invalidate a milestone without any task changing status.

I call this the Commitment Network. It is a working model, not established organizational science. Its value depends on whether it explains real program behavior better than a task graph and whether it produces better interventions. The full essay sets out how I think that could be tested.

The emerging architecture

Once the program is modeled as commitments, the rest of the stack becomes easier to separate.

Program Observability is the sensing and reconciliation layer. It turns evidence into claims, reconciles the claims, and produces derived state while preserving provenance, freshness, authority, and uncertainty.

Program as Code is the implementation philosophy. Requirements, commitments, dependencies, interfaces, decisions, policies, evidence references, authority boundaries, and state become explicit enough to version, inspect, and operate against.

Program Runtime is the persistent execution environment. Deterministic systems, agents, accountable humans, and external actors sense, reconcile, reason, decide, act, and observe against program state.

Program Control Plane governs that execution. It carries policy, authority, prioritization, escalation, autonomy limits, overrides, intervention, sequencing, and risk acceptance.

Program Operating System is the provisional umbrella term connecting those layers. It is a working architectural model I am beginning to test, not an established category and not a product I am claiming already exists.

The operating-system analogy is about execution infrastructure. A computer operating system provides the environment through which computation executes. A Program Operating System would provide an environment through which organizational execution occurs.

The analogy stops there more often than it continues. Organizations are not computers. Humans are not processes. Politics is not packet loss. Judgment is not an algorithm waiting for a clever enough implementation. A TPM also has nothing like the centralized authority a network control plane has over a data plane.

The model we’re leaving

The current operating model runs on a specific loop. Work happens in repos, tickets, capacity plans, vendor threads, hallway conversations, and an engineer’s head. None of those places agree by default. A program manager samples them on a cadence, resolves contradictions using judgment and relationships, then produces an artifact. Leadership makes decisions against it.

Three properties of that loop matter:

It samples. A status snapshot describes a moment. A green on Monday can be false by Wednesday and nobody finds out until the next sample.

It compresses. Turning 40 claims into 1 color is lossy by design. The loss is usually fine and occasionally catastrophic, and the artifact rarely distinguishes between the two.

It routes through incentives. Every hop between work and decision is a place where someone’s rating, headcount, supplier relationship, or launch date sits in tension with an accurate account.

Given manual inputs, this is close to the best available design. The inputs are what changed.

What machine-legible execution changes

Once work is sufficiently instrumented, the marginal cost of querying program state falls sharply. The difficult work moves upstream into instrumentation, semantics, provenance, and governance. That qualification matters for hardware, suppliers, physical execution, regulation, and knowledge that still lives only in a person’s head.

Narration gets cheap and more persuasive. A generated summary arrives with the fluency of a careful analyst and can quietly lose the analyst’s hesitation. My clearest example is a company that ran 3 months of leadership decisions on hallucinated analytics and caught it only because someone asked for a sanity check by accident.

Execution also starts to move. Deterministic rules can enforce exact gates. Agents can interpret ambiguous material, prepare work, and take bounded actions. Humans can make authority-bearing calls and accept consequences. Once multiple kinds of actor can change program state, their shared environment needs explicit rules.

That is the purpose of the runtime and control plane. Agents are participants inside it, not the foundation of the theory.

What becomes possible

Requirements become structured inputs. A requirement written so a machine can check it against a build is also one 2 humans can argue about precisely.

Dependencies become observable commitments. “Is the storage team still on track?” becomes a claim backed by evidence, with an asserting actor and an age.

Decisions get versions. Who decided, under what authority, on which evidence, with what alternatives rejected, and what would cause reconsideration.

State gets derived instead of merely declared. A program’s state becomes a function over claims and policy. A stale input can visibly degrade the result.

Uncertainty becomes a first-class output. UNKNOWN, UNVERIFIED, CONTRADICTED, STALE, SUPPORTED, AUTHORIZED, and OVERRIDDEN can remain distinct instead of being sanded down into a color.

The TPM becomes a systems engineer for organizational execution

The durable responsibility is engineering the execution system itself. Agent orchestration is one implementation detail inside it.

Represent and instrument the work. Define commitments, interfaces, dependencies, decisions, and authority in forms humans can contest and software can inspect. Decide what counts as evidence, how old it may become, and which blind spots the system must admit. This is architecture applied to an organization instead of a codebase.

Design execution and feedback. Assign work to deterministic systems, agents, humans, and external actors according to capability and consequence. Build the loop through which actions produce events, events produce evidence, and observed failures change future controls.

Govern authority. Make autonomy limits, escalation, overrides, and decision rights explicit without pretending organizational authority maps neatly onto software permissions.

Keep the model honest. Preserve ground truth, resolve ambiguity and conflict, and own outcomes where the system cannot legitimately own the consequence. A cleaner dashboard makes drift harder to notice, not easier.

I do not think every TPM will do all of this, or that the transition lands evenly across industries. I do think this description is more durable than “AI orchestrator.” The person who designs the representation, sensing, runtime, and controls is engineering how an organization executes.

The limits

Automation is weakest where programs are hardest. It has no standing to arbitrate between 2 directors who both need the same quarter. It cannot carry a supplier’s material consequence, accept a reliability risk on behalf of a customer, or make politics disappear by typing them into a schema.

A system built on an organization’s data also inherits the organization’s blind spots. If a category of work is not instrumented, it can disappear from the program’s derived reality. This is simulation bias with better plumbing.

And all of this costs engineering effort that competes with shipping the actual product. The system has to earn its keep. A 2-year observability platform that produces a more ornate status review has failed, even if every box in the architecture exists.

Where I am on this

This is an open research program: build → break → measure → revise → reproduce → publish. The terms are working terms. The architecture is proposed. The observability model is a concept. Some small experiments are underway. No validated conclusion earns the Program Operating System name yet.

The planned Orion experiment is the first attempt to make it earn that name. It will test whether a structured runtime beats unstructured LLM reasoning when supplier commitments conflict, Jira state is stale, engineering language is ambiguous, dependencies are incomplete, and evidence changes over time.

The essays work through the argument. The systems make pieces of it concrete enough to be wrong about. The field notes are where results and failures land.