Skip to content
Arnel Robles edited this page Oct 20, 2026 · 7 revisions

Lean agent

A method for running AI coding agents over a ticket backlog, shipped as a Claude Code plugin. Tickets are shaped for the agent, a fast model finds code and runs the gates, a cheaper model drafts, scripts run the mechanical checks, a critic reviews what the diff says needs review, and the stronger model only sees what the critic could not close.

On one .NET codebase in September 2026 that took model use from about 13 dollars per change to about 9, at list prices, with no drop in what got caught. Treat the numbers as a shape, not a benchmark. The README is the short version. This wiki has the method in full, one page per section, and the reference for what the plugin ships.

claude plugin marketplace add arnelirobles/lean-agent
claude plugin install lean-agent@lean-agent

Why three models

Each step goes to the cheapest model that can do it without losing a defect.

Model Runs List price per million tokens, in and out
Haiku (fast) finding code, running the gates and pasting their output, collecting the retro's numbers 0.10 and 0.50
Sonnet (cheap) spec review, every draft, the critic's hunt and refute, the first fix round 2 and 10
Opus (strong) a finding not fixed in one round, an unsure answer on core code 4 and 20

Haiku is 20 times cheaper than Sonnet and faster, so work that only reads and reports costs almost nothing. It never answers a yes or no about code: a small model that wrongly throws out a finding drops a real defect with no trace, so the critic stays on Sonnet. The Haiku split has not been measured on a batch yet. lean-stats report prints cost by role after one, and search, gate and retro are the Haiku roles. Models and the Cascade has the detail.

Start here

  • Installation: install, update, and use the scripts without the plugin.
  • The Loop: every step from idea to merged change, in order.
  • Settings: every environment variable in one table.

The method, section by section

Section Page In one line
0 Shape the ticket for the agent Write each ticket so one agent pass finishes it with nothing else to read.
1 Triage inline, no agents Sort the backlog yourself into three tiers and do tier 0 by hand.
2 The cascade A fast model reads and reports, a cheap model drafts, a cheap critic reviews, the strong model sees only what stays open.
3 The diff decides whether a critic runs Rules over the diff, not the ticket title, decide whether a critic runs.
4 to 4a Scripts, not instructions Mechanical checks live in scripts. Reasoning an agent does twice becomes a script.
5 to 6 Rework and concurrency Fixes go back to the agent that wrote the change. At most four changes in flight.
7 Measure every batch Cost per change and what the critic missed, after every batch.
8 Attack your own method Test the method against real defects before you trust it.
9 Half of what an agent makes is not text Gate images and other bytes that text checks cannot read.
10 A check that passes having checked nothing Make every check fail when it is handed nothing to check.
11 The machine has a ceiling too Queue heavy commands per toolchain and run agent work at the lowest priority.
12 The adversarial critic One agent hunts, a second tries to prove each finding wrong. Repository rules first.
13 Every finding is an interaction Look at what the diff touches but did not write, before you push.
14 Cheap drafting works, and it stops short Where a cheaper drafter holds up and where it stops.
14a to 14h Field notes from parallel agents Leftover processes, shared scratchpads, wait loops, stacked pull requests, deploys, rehearsals, local CI, steps for a person.
15 What a reader should observe The six results to look for, and the two goals that poison themselves.
16 The method improves itself A scheduled retro that turns the numbers into changes to the method.

Brain and the test queue

Agents lose what they knew when the context compacts, and they wait badly. Brain is one local SQLite file that holds what is still open (test failures, deferred minors, questions for you, blockers, running agents) and the test queue. A session queues a test job and ends its turn; one drainer runs the jobs, on this machine and on SSH hosts, and writes the failures back.

  • Brain: the items, brain resume after a compaction, and how a question you answer goes back to the session that asked.
  • Test Queue: brain queue add, the test-phase drainer, tiers, reruns, stalls, and what lands in brain.
  • Remote Lanes: drain the queue on SSH hosts in capped containers.
  • Brain MCP: brain as tools for a Claude session, and what they refuse.
  • Lean Brain Extension: the VS Code dashboard over brain and the queue.

How the plugin runs it

Reference

  • Hooks: what each hook checks, whether it blocks, and its off switch.
  • Scripts: every script in bin/, with usage and exit codes.
  • Development: self-tests, versioning, platforms.

What it does not fix

A backlog with no definition of finished refills faster than it drains. Decide what done means first.

Clone this wiki locally