How it works
Four questions cover the whole job: what the Workers are, how you set them up, how you train, monitor, and manage them, and what you do when one gets it wrong. It all ends in one artifact: a merged pull request with the plan, the critique, the review, the test video, and the decisions attached.
baileyproposal · from Jira NMT-214 · accepted by Sam
reevecritique · index the lookup table · applied
proctorreview · 2 findings, security and db · both fixed
fletcherbrowser test · 6 steps · video and 9 screenshotsII · What the Workers are
Each Worker reads something, produces something, and has a ceiling it cannot climb past. The ceiling is what makes it safe on day one.
Product Manager
runs weekday mornings, or when you ask
Staff Engineer
runs when a plan is ready
Builder
runs the queue, capped by throughput
Reviewer
runs when a pull request opens
QA
runs when a pull request changes
Chronicler
runs weekday mornings
III · How a work item moves
A work item is one page, the case file: the proposal, the plan, the runs, the pull request, the review, the test evidence, the gates a person answered, and what it cost. Every decision resolves on it, never in a second queue, and a comment on it becomes a line in the plan or a Playbook rule.
The four gates are the same at every rung of the Ladder. Promotion changes which of them the Team may answer for itself on reversible work. Accepting the result, and the merge behind it, stays with a person.
pulled from the backlog with evidence. Tag the PM in Slack for the business read.
gateaccept the proposal
drafted in a sandbox with the questions it could not answer from the ledger surfaced for you. Reeve critiques it in place.
gateapprove the plan
commits, tests, and a draft pull request on a branch. Nothing touches the trunk.
one review through its checks, then Wright answers each finding until the PR is clean, up to the rounds you allow.
boots the app in the Team's sandbox, walks a test plan in a browser, attaches the video.
gateunblock, if it needs something only you have
read the PR with everything attached, merge or send it back.
gateaccept the result
the standup and the Brief say what shipped, with the receipts, and what still needs a person.
IV · How you set them up
Shaped like onboarding a new team, not configuring a pipeline. Nobody writes a workflow graph or tunes prompts, and every Engagement starts at Training.
Install the GitHub App for the workspace; Workers reach repositories only through it. Attach Jira or Linear for the backlog, Slack for the gates and standups. Nothing is migrated.
Name it after one of your engineering teams, never a repository. Describe the outcome in plain words and YAGNI drafts its Responsibilities. Attach the repos, the backlog, and the one person it reports to.
Pick from the roster. Each Engagement is the same triple: when it runs here, what it may do alone here, what it knows here. For Fletcher, Begin setup reads the repo and fills in the environment; you add secrets and the auth mode.
V · How you train, monitor, and manage
Review the work, correct it in the moment, promote on the record, read the report in the morning. The management you already do, pointed at Workers.
The Ladder and the track record
Every Engagement starts at Training. Its record shows proposals accepted unedited, plans approved, PRs merged, reviews acted on, and the misses. When it supports a promotion, you press the button. The record advises; a person decides.
The Playbook
Corrections become rules. When your decisions show a pattern, the Team proposes a rule, active until you adopt or dismiss it inline. Domain experts write the business rules; engineers write the guardrails.
The Brief, the standup, and Work
Harper composes the Brief each weekday morning and posts the standup where your team reads. Work is one queue across Teams with the case file as the detail, and the gates that need you are counted on the Front.
Usage, caps, and Authority
Spend by developer, Worker, Team, and day on the one rate card. Caps per Worker and per day, items in flight, review rounds, and what each Engagement may do alone, set on the Team and inherited unless you override.
Training: every step waits for you. Supervised: reversible work proceeds with a visible stop window. Autonomous: you review outcomes. And the floor: merges, deploys, and anything irreversible stay gated at every rung, forever.
VI · When it gets it wrong
A Worker that is never wrong is a demo. A Worker you can correct in thirty seconds, with the correction sticking, is a teammate.
Every step on the case file links to the run behind it: the model calls, the files it touched, what it read from the ledger, what it cost. Proctor's dismissed findings sit one click behind the review, with the reason.
Answer on the case file, in the PR, or in the Slack thread. The correction lands in the item now, and if it should outlive the item, the Team proposes it as a Playbook rule. Nothing waits for a retraining cycle.
A provider outage or a flaky sandbox is a retry button, not a support ticket. The run resumes from the last settled step with the same context.
Promotion is a button. So is demotion. And reversing something an Engagement shipped on its own lowers it one rung automatically, on the record.
VII · We meet you where you are
The web app
Front, Work, the case file, the Workers directory, Usage. Where an engineering lead runs the Teams and reads the record.
Claude Code or Codex
Connect the harness you already use to the YAGNI MCP server: pull the queue, ask Reeve for a critique or Proctor for a review, read Fletcher's evidence, publish a review as a recorded Decision, engage a Worker.
Slack
Bailey tags the product manager at the proposal, Harper posts the standup, and a reply in the thread lands on the record.
And a harness of your own
YAGNI Code runs 60% or more under frontier API rates.
The desktop and CLI coding agent your engineers run by hand, tailored to your company: the same decision ledger the Teams write, the same vetted US-hosted open weight models, the same meter. Skills, plugins, and MCPs slot straight in. Already on Claude Code or Codex? One command routes it through YAGNI's models when the bill turns to usage rates.
VIII · Under the hood
Open weight models, routed per task
A router sizes each step before it runs: a repo map on a fast model, a hard plan or a final review on the strongest. Every release is evaled on our harness before it serves a request and ships behind a rollback flag.
US-only inference, zero retention
Every model runs on US-hosted providers under zero data retention agreements, with a failover lane that stays in the US. A BAA is available for teams that need one.
One sandbox per Team, one door into GitHub
Builds and browser tests run in isolated sandboxes, one per Team, so parallel Teams never collide. Workers reach repositories only through the GitHub App you install, scoped to the repos a Team attaches.
The knowledge is yours
Plans, decisions, and Playbook rules export to Confluence or Drive on request. The system of context is a record you can take with you.
Get YAGNI Code
YAGNI Code is the coding agent your engineers run, as a desktop app or straight in the terminal. One YAGNI login connects it to your workspace.
The desktop app needs an Apple Silicon Mac running macOS 13 or later. There is no Intel, Windows or Linux build yet. If that is not your machine, the CLI is the same agent and runs anywhere Node 22.19 or newer runs.
Installs the yagni command. Log in with the device code, then launch it inside any repo. Your workspace admin turns YAGNI Code on for your team.
Agent teams, managed like your engineering team
On the call we connect the repository, engage the first Workers at Training, and leave the first work item at your proposal gate.
30 minutes with Jack, the founder · no migration project on the other side