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

Intent Engineering

Working Above the IDE

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 (attach silent context), REFINE (resolve ambiguity before execution), EGEST (emit executable briefs)
  • The supervisor plane needs mode gates, WIP limits for agents, and work that persists above sessions
  • 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 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.

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.

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.

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
  • Resolve ambiguity before execution, or an agent resolves it mid-flight for you
  • 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