Agentic Developer Workflow
Building software with AI, under human control.
This is a plain-language walkthrough for leadership. It explains what the Agentic Developer Workflow is, why it is safe to scale, and where we take it next.
The same briefing is also a presentable slide deck (use the arrow keys, press F for fullscreen, S for speaker notes) and a one-page PDF you can hand out.
The idea in one line
AI agents do the building. People approve every change.
Two rules hold no matter what:
- Local-first. It runs on flat, unmetered developer subscriptions before any metered cloud spend.
- Human-gated. Every change ships as a draft pull request that a person reviews and merges.
Why it matters
We get more output from the same team, without giving up control of quality, cost, or security. And it compounds. Every project that adopts the workflow makes the next one faster, because the company's knowledge is shared.
How the process works
A task becomes working software through the same repeatable steps every time. It runs on demand or overnight.
Everything to the left of that last box is automated. The last box is the one step that is never an agent. Nothing ships without it.
What keeps it safe
Three controls run on every change, and they scale with autonomy rather than away from it:
- An independent maker-checker verifies the work against the spec.
- An evidence gate refuses to call anything done without proof that it works.
- A human merges every change. Agents draft; people sign off.
Every run is traced end to end, so there is a full audit trail of what each agent did.
Who decides what gets built
Work enters one queue from two places: an estate watcher that proposes tasks, or a person who adds one. Nothing builds unless it enters that queue, so the team stays in charge of what gets worked on.
Why the output is trustworthy
Agents read each project's own documented intent, plus a company-wide knowledge atlas, and build to the spec instead of guessing. A broken or missing reference cannot pass the gate, so the documentation stays honest over time.
One terminal, many projects
This is the next step for us. Today one engineer runs one loop. A single orchestration hub lets one lead oversee many projects at once: one place to watch every project's status, its task queue, and its open pull requests, and to dispatch work to the right repository.
Many builds run in parallel, and the hub picks the right execution model for each repository without the operator thinking about it. This is how we go from a pilot to a portfolio.
Cost is a choice
Day-to-day work runs on flat, unmetered subscriptions. The metered cloud path is opt-in, only for unattended work, and even then the throwaway steps use a cheaper model. The routine commit-message step alone costs about 98% less that way. Spend is tracked from day one, so scale stays a deliberate decision rather than a surprise.
From one engineer to a software factory
The adoption plan moves in earned stages: learn and pilot, then orchestrate and fan out, then atlas and software factory. It is gated by readiness, not by dates, and each stage is proven before the next begins. The full plan and a visual timeline live in the Academy roadmap.
Where we are today
The foundation is already built:
- The Academy that teaches this workflow.
- The standards and CI gates that enforce it.
- The knowledge atlas that grounds it.
- This reference orchestration hub, which proves the "many projects, one terminal" model.
We are not asking to build a platform. It exists. We are asking to adopt it.
The ask
Two decisions for leadership: which teams pilot first, and at what pace. We prove each rung before climbing to the next. Everything else is ready.