A minimal Zen-style illustration of tangled demand passing through three torii gates and emerging as ordered parallel lines feeding clean briefs.

Intent Engineering

Code became a byproduct. The scarce input is well-formed intent. Notes on a year of building and daily-driving a post-IDE workstation.

TL;DR

  • Code became a byproduct; the scarce input is well-formed intent
  • Prompt engineering and context engineering are real, but both are downstream; the upstream bottleneck is malformed demand
  • Intent engineering: turning vague demand into briefs a competent stranger could execute
  • The pipeline has three stages, AUGMENT, REFINE, EGEST, and what each stage actually does is raise the density of intent until an executor can act without asking
  • Supervision works by exception: three kinds of decision cross to the human; everything else is arbitrated with a recorded rationale
  • Done is a claim until it is read from the remote; a status field and evidence are different things
  • What the work found but did not do re-enters through the same intake as demand, and a per-mode cost ledger makes the economics legible
  • Throughput now scales with the quality of briefs, not hours at a keyboard

The file stopped being my unit of work

For twenty years my unit of work was the file. Open it, edit it, run it, commit it. The IDE is a magnificent machine built around that unit, and every one of its descendants, including the AI-assisted ones, still assumes it: a human, looking at code, typing.

That assumption broke for me sometime last year. On a normal working day I do not look at most of the code produced under my direction. Agents write it, test it, and open the change for review.

My actual work moved one level up, and I found there were no tools there. So I built the workstation I needed, and I have been daily-driving it since. This essay is about what that level contains, because I think it is where a lot of software work is about to live.

Intent is the input, code is a byproduct

Call the discipline intent engineering: the practice of turning vague demand into execution-ready work definitions, and supervising fleets of agents that execute them.

The name matters because of what it displaces:

Discipline Optimizes Position
Prompt engineering A single utterance Downstream
Context engineering What a model sees Downstream
Intent engineering Demand itself, into executable briefs Upstream

Both prompt and context engineering are real. But the upstream problem, the one that actually gates throughput, is that demand arrives malformed: a Slack message, a feeling that the release is risky, a half-remembered promise to a customer. Nothing a fleet can execute.

The pipeline that emerged in my workstation has three stages:

  1. Augment: attach everything the demand silently references: the codebase area, the prior decisions, the constraints that live in someone’s head.
  2. Refine: force the ambiguities to the surface and resolve them BEFORE execution, because an ambiguity resolved by an agent mid-flight is a decision made by whoever cares least.
  3. Egest: emit task briefs with acceptance criteria, dependency structure, and the workflow mode each task should run under.

The stages have a single underlying job, and naming it changed how I think about the whole level. Each stage raises the density of intent. A raw signal is nearly empty: most of what it means lives in the head of whoever produced it. An augmented signal carries its silent references. A refined one carries its resolved ambiguities. A brief carries everything an executor would otherwise have to stop and ask for, which is the working definition of executable. Density is not a metaphor here; it is the gate condition. Execution begins at the first stage where nothing is left to ask.

? ? ? signal augmented refined brief a message, a feeling context attached ambiguity resolved executable execute, without asking density is the gate condition

The same demand, four readings. Each stage adds what the demand silently referenced, and the executor starts at the only stage with nothing left to ask.

The output of intent engineering is not a prompt. It is a brief a competent stranger could execute. Agents are competent strangers at scale.

What the supervisor plane needs

Below intent, the workstation runs an orchestration plane. A year of daily use converged on a few load-bearing mechanisms, none of which existed in any tool I could buy.

Workflow modes with gates. Exploration, research, planning, implementation, validation are different regimes with different permissions. The dangerous transition is between them: an agent that slides from exploring into implementing without a gate has silently spent your review budget. Mode transitions are checkpoints where a human can be cheap and decisive. The gates carry a second job too: model capability improves with every release, but model discipline oscillates, a distinction I have written about separately, and a gated workflow is what insulates the work from that oscillation.

WIP limits for agents. Kanban discovered this for humans decades ago and it transfers intact: unlimited parallel work does not raise throughput, it raises the cost of every context switch the supervisor makes. The scarce resource is no longer typing, it is supervision bandwidth. Budget it explicitly.

Work exists above sessions. A task’s context (its brief, its state, its history, its artifacts) persists independently of any device, session or agent instance. Agents die, contexts do not. This sounds abstract until an agent dies mid-task at 3am and its successor resumes from the persistent context in minutes, which is a thing that has happened to me more than once and is the difference between a fleet and a collection of chats.

The human is a supervisor, not an operator. The interface problem is genuinely new: not “show me the code” but “show me what changed while I slept, what is blocked on a decision only I can make, and what evidence supports each claim of done”. Status claims from agents lag, or lie; the supervisor plane has to verify against external evidence (diffs, test runs, logs) rather than trust self-reports.

A minimal Zen-style diagram of four stacked planes, INTENT, SUPERVISION, EXECUTION and IDE, with a meditating figure on the top plane and work streams multiplying as they flow down past the fading IDE layer.

Arbitration is not interruption

The naive reading of “the human is a supervisor” is presence: watch the dashboards, approve the steps, stay in the loop. That version does not survive contact with a fleet, because watching is the old choreography wearing a new name. If every decision waits for me, I am the scheduler again, with better scenery.

What survived a year of practice is supervision by exception, and the load-bearing part is that the exception boundary is closed. Three kinds of decision cross to me, and only three:

  • a decision about scope or product, because that is intent, and intent is my job;
  • a decision resting on a fact only I know, because a recommendation built on a missing fact is a guess, and the system will not sign my name to a guess;
  • an outward-facing effect, a push, an issue opened, a message sent, because the world outside the workstation cannot be un-touched.

Everything else the run decides for itself, and this is the part that took discipline to accept: it decides and writes down why. Every arbitration leaves a receipt: the action, the object, the criterion applied, and a pointer back to the exact session that made the call, so any decision taken in my name can be reopened and inspected on the day I stop trusting it.

the human's territory the boundary scope a fact only you know an outward effect the run arbitrated, rationale recorded three kinds of decision cross; everything else continues, receipted

Every decision the run meets, one line. Three kinds cross the boundary to the human; the other four continue with a receipt. The line itself is never interrupted.

When something does cross, it does not wait politely in a tab. It notifies me wherever I am, desktop or phone, and the rest of the line keeps working around the held question. A typical run now reaches the end without my touching it once. The zero is not the achievement. The achievement is that the zero is trustworthy, because the boundary is stated in advance and the record shows which side of it every decision fell on.

Done is a claim until it is read

The most expensive lesson of the year fit in one incident. Early on, a batch of tasks reported done: state files said done, the orchestrator agreed, the work was marked complete. On the remote there was nothing. The worktrees had been deleted. About thirteen dollars and change of agent work had been destroyed, silently, and the only reason I knew was that I went looking.

Thirteen dollars is a cheap tuition for the generalization: a status field is a cache of a claim, and a claim is not a reading. An agent that says it finished and an agent that finished are indistinguishable if all you consult is what the agent wrote about itself.

The correction has two halves. First, verdicts are computed against the remote, never against the local checkout, because the local copy is somebody’s last pull, a cache wearing the costume of ground truth. The verdict prints which ref it read, at which commit, at what time, so the verdict itself is inspectable. Second, the reading is honest about its own limits: a check that could not be performed reports as could not be read, a gap, never as a pass and never as a failure. A gap is actionable. A gap silently rounded to a zero, in either direction, is how false confidence compounds.

the state file says the remote holds task one, done task two, done task three, done task four, done nothing arrived the verdict is read here a file can say done; only the remote can show it

The state file and the remote are two readings of the same work, and only one of them can lie. The verdict is read from the remote; no arrow leaves the claim.

This is the downstream mirror of the upstream problem. Malformed demand gates throughput on the way in; unverifiable completion gates trust on the way out. Intent engineering owns both ends, and the middle, the part every tool on the market is racing to accelerate, turns out to be the part that least needs a human.

The loop closes, and the ledger stays

Work generates work. Every run turns up things it was not asked for: a defect noticed in passing, a refactor that should happen someday, a question nobody owns. In the session era those observations died with the window, or worse, moved into my head for safekeeping.

The correction is almost embarrassingly simple: what the work found but did not do re-enters through the same intake as any other demand. It is captured, it queues, it gets refined or discarded on its own merits. Nothing depends on my remembering, which was the entire point of the exercise. The system even files observations about its own defects this way; a clean run files nothing.

one door, entered twice demand intake the work briefs, execution what it found but did not do the run's leftovers queue like any other demand

One door, entered twice. Demand comes in from outside; the run’s leftovers come back around to the same intake. There is no second entrance, and nothing rides home in the supervisor’s head.

Underneath the loop sits a ledger. Every session records its mode, its turn count, and its cost, so the record accumulates into something no amount of instinct provides: where the money goes, per stage of work. A full mid-sized task lands around two dollars of agent spend, end to end. The number is pleasant; the legibility is the point. Which mode is expensive, whether a task was badly sized before anyone started it, where last week actually went: these became questions with answers. A supervisor can be wrong about their own system, and, for the first time in my working life, find out from the system itself.

What this is not

  • Not no-code. More code ships under this model, not less; humans just stop being its typists.
  • Not autonomy worship. The entire design exists to place human judgment at the few points where it is irreplaceable (intent formation, ambiguity resolution, mode gates, acceptance) and remove it from everywhere else.
  • Not a product pitch. My workstation is personal infrastructure, tuned to one person’s cognition, and some of its value comes precisely from that fit.

Why I think the level is real

Three observations from a year of practice, offered as evidence rather than prophecy.

First, throughput now scales with the quality of briefs, not with hours at a keyboard. A well-formed intent executes overnight; a malformed one wastes a fleet by morning. My leverage moved to a document.

Second, the operational failures are all supervision failures, distributed-systems shaped: lifecycle, verification, isolation, memory. I wrote a separate post-mortem on running thirteen agents in parallel; every incident was ops, none was intelligence.

Third, and the one that convinced me: when the workstation is down, going back to the IDE feels like being demoted to hand-assembly. Not because the IDE is bad, but because the unit of work I actually think in no longer fits in a file.

The tooling industry is currently racing to make agents better operators. Fine. The bottleneck I hit daily is one level up: nothing helps a human be a good intent engineer, a good supervisor of thirteen concurrent strands of judgment.

That level is buildable now. I know because I am typing this from it.

The workstation has a name

It is called Continuum. Everything this essay describes, the refinery, the gates, the arbitration boundary, the ledger, the reading of done off the remote, runs there daily. If the level described here is where you work, or where you suspect you are about to be: github.com/daviguides.

Key Takeaways

  • The scarce input is well-formed intent; code is a byproduct
  • Prompt and context engineering are downstream; malformed demand is the upstream bottleneck
  • A brief a competent stranger could execute is the real unit of output, and each pipeline stage exists to raise the density of intent until that bar is met
  • Resolve ambiguity before execution, or an agent resolves it mid-flight for you
  • Supervise by exception: a closed boundary (scope, facts only you hold, outward effects) crosses to the human; everything else is arbitrated with a receipt
  • Done is a claim until it is read from the remote, and a check that could not run is a gap, not a zero
  • Close the loop: what the work found but did not do queues like any other demand, and a per-mode ledger makes the economics legible
  • Supervision bandwidth is the scarce resource: gate modes, limit WIP, persist work above sessions
  • The next tooling frontier is the supervisor layer, not better agents

Authored by Davi Guides
Visit daviguides.github.io for more insights