What is YAGNI Code and how does a /go run work?

How do you install YAGNI Code?

Two doors, one agent. In the terminal: npm install -g @yagni-app/code, then yagni login with the device code, then yagni inside any repo. Or download the desktop app for Apple Silicon Macs. One YAGNI login connects either to your workspace, and your workspace admin turns YAGNI Code on for the team. With nothing else connected, the CLI still works on day one.

What happens on a /go run?

You type /go and the task, and the run moves through named stages: map, plan, build, adversarial review, pull request. The repo gets mapped, an implementation plan is staged, and the run waits there. Checkpoints are yours: nothing is built until you approve the plan. Then the change goes in behind a flag, the adversarial reviewer attacks it through up to three fix rounds, tests run, and the PR opens for your review. The meter prints the cost of every step as it happens.

How does routing keep the cost down?

An advisor model sizes up each task and routes it: mapping a codebase goes to a fast model, implementing a plan to a standard one, a hard refactor or final review to the strongest. Routine work never pays top rates, and that is how the floor holds at 60% or more under comparable frontier API rates, across the board rather than just on the easy runs.

What makes it a team harness rather than a personal tool?

When one developer corrects an agent, every developer’s agents learn it. Review rules and Playbooks are shared, usage and budgets are visible per developer, and every run writes to one decision ledger: what was chosen, what was rejected, and why. Your agents read it before they plan, your engineers read it instead of asking around. Not thirty copies of a personal tool that happen to share a bill.

What grounds the code in your business?

As code completes, the agent checks the change against the record: the Jira ticket, the Confluence page, the Slack thread where scope changed. An extra reviewer with the context the developer might not have had open, so the code fits the decision, not just the diff. The grounding is optional and arrives with your Connections; the agent works without it from day one.

Where do you go next?

Two setup lessons finish the harness: bring your team’s MCP servers along from the tool you used before, and export the traces to Datadog so the meter is queryable in the observability stack you already run.

Where does the org story pick up?

A /go run is one engineer delegating one task. The same machinery, held by a Team with Responsibilities and a record, is how a whole lane of engineering work gets carried: PR review, production watch, the proposals your backlog was missing. That is the rest of this Academy.