What is YAGNI Code and how do you work with it?

How do you install YAGNI Code?

Two doors, one agent. In the terminal:

npm install -g @yagni-app/code
yagni login
yagni

yagni login authorizes your workspace with a device code, and yagni launches the agent inside any repo. The desktop app is the same agent with a window around it: download it for Apple Silicon from the YAGNI Code page. Your workspace admin turns YAGNI Code on for the team, and with nothing else connected it still works on day one.

What does a session actually look like?

You work it by hand, the way you work with a good engineer. You describe the change. The agent reads the repo and comes back with a plan. You read the plan, argue with it, and approve it. Then it implements, runs the tests, and reviews its own diff before it hands the work back to you.

Plan, implement, review, and you drive every step. Nothing gets built off a plan you have not read, and nothing leaves the machine you did not send it from. Sessions are resumable: yagni -c continues the last one, yagni -r browses previous ones, and yagni -w opens a worktree so a long change never blocks your main checkout.

Do your skills, plugins, and MCP servers come along?

Yes, and that is deliberate. A repo with a .mcp.json at its root works as-is, because the schema is the one your team already writes. Personal servers move over with yagni mcp add-from-claude. Claude Code plugins install from a marketplace with yagni plugin, and their skills, commands, agents, and bundled MCP servers load on launch.

The full setup is its own lesson: MCP servers in YAGNI Code.

What does it run on, and what shows up on the bill?

Vetted open weight models, US-hosted under zero data retention, routed per task. A router sizes each piece of work before it runs, so mapping a repo never pays what a hard refactor pays, and the floor holds at 60% or more under comparable frontier API rates across the board.

Developers and the Workers on your Teams bill on the same rate card and sit beside each other on the Usage report. That is the point of one meter: you can read what a developer spent this week next to what a Worker spent, without reconciling two systems.

What does YAGNI Code share with your Teams?

One login, one meter, one record. The decision ledger your Teams write is the same ledger your terminal reads: why queues instead of cron, what the retry rule is, which flag gates this path. The agent reads it before it guesses, and the judgment calls a session settles go back into it, so the next person to open that file inherits the answer instead of asking around.

That is the difference between a team harness and thirty copies of a personal tool that happen to share a bill.

Where do you go next?

Three lessons finish the developer’s side. Manage the same Teams from Claude Code or Codex without leaving the harness. Bring your MCP servers across. Then export the traces to Datadog so the meter is queryable in the stack you already run.

For the org story, a session is one engineer delegating one task. The same machinery, held by a Team with Responsibilities and a record, is how a whole lane of work gets carried.