What is program engineering?
Program engineering gives individuals in human-agent teams more responsibility and flexibility by establishing an easy way for humans to turn discussions into constraints, shared rules, shared goals, and high-level plans that span stakeholders, disciplines, and workstreams.
The "engineering" is literal. Intent that used to live in meetings, slides, and individual memories becomes a written, shared artifact that humans and agent loops can both read and act on. A program gives the work a name and an owner; program engineering gives it explicit shape: what the goal is, what the rules are, what must not break, and how the workstreams fit together.
The payoff is autonomy. When the constraints and goals are explicit and shared, an individual doesn't need a meeting or permission to act on them, and neither does their agent. People and loops move independently with shared goals, shared constraints, and perfect awareness of where others are at in real time, instead of queuing on the one person who holds the picture and on the next meeting to hand off statuses to each other.
Why is program engineering suddenly an every-company problem?
It used to be a large-company problem. You hit it somewhere around 80 engineers, when the org got complex enough that coordination started breaking down. Before that, a good senior engineer or EM could hold the picture in their head.
That threshold is gone. AI has decoupled team size from execution capacity: a 10-person engineering team today moves at a speed and breadth that would have required 80 people five years ago. Ambition expands to meet the new capacity. And headcount undercounts it: a team of five running standing agent loops is, for coordination purposes, already a team of twenty.
The moment you're running eight things at once with a team of ten, you have an 80-person company's coordination problems, with none of the organizational infrastructure that large companies built to handle them.
That makes program engineering the holy grail of velocity engineering. Execution is no longer the bottleneck; coordination is. The team that removes it doesn't move 10% faster, it moves at the speed of however many workstreams it can run in parallel without losing coherence.
How is program engineering different from feature engineering?
Feature engineering optimizes the next deliverable: scope it, build it, ship it, move on. It is the right mode when the team's goals fit inside single deliverables.
Program engineering optimizes the outcome across deliverables. "Ship SSO" is feature work; "Enterprise Readiness" is a program that will outlive SSO, the next compliance audit, and the deal that prompted both. The deliverables change quarter to quarter; the goals, constraints, and accumulated context persist, written down where every stakeholder and every agent can act on them.
This is the shift described in Welcome to Program Engineering: as execution gets cheap, the scarce skill stops being shipping the next thing and becomes keeping many shipped things pointed at the same outcome.
What happens when a program isn't engineered?
It still gets run. When the goals and constraints live in nobody's document and everybody's meetings, whoever has enough context to hold the picture becomes the accidental program engineer: coordinating on top of their actual job, holding the institutional knowledge in their head, and taking it with them when they leave.
The cost isn't just the lost knowledge. Everyone else queues on that one person to know whether they're allowed to act, and nobody can see the program's real state while it's running, so drift surfaces as a surprise instead of a signal.
How do agents change program engineering?
The workstreams are no longer all human. With autonomous loops, agents stopped being tools you invoke and became standing participants in programs. A loop wakes up on its own schedule, reads program state, pulls signals, writes memory, posts digests, flags blockers, and decides for itself when to run again. Nobody is prompting it.
Agents make the explicit artifact non-optional. A human can absorb unwritten rules from hallway context; a loop acting at 3 a.m. can only follow what was written down. The team's discussions have to become constraints and plans the agent can read, or the agent acts without them.
What is the primary use case of program engineering?
Programming the governance of human-agent loops. Which decisions a loop makes autonomously, which it escalates, what context it's allowed to act on, who reviews what it wrote overnight, and who is accountable when it acts on stale memory. These are program-level decisions, not prompt-level ones.
The team that turns those discussions into written, shared rules, in the same place it declares its programs' owners and sources, is doing program engineering. The team that doesn't has unaccountable workstreams running unattended.
Learn more
- What Is a Program?: the unit this discipline runs on
- Welcome to Program Engineering: the full essay on this shift