Work a ticket backlog with a Makefile agent that checks git history first

Schwartz took the next five tickets in his team's Flutter monorepo backlog and ran each through a workflow he calls the Commitment Machine. A Makefile defines numbered targets (archaeology, plan, code, critic, commit, push, PR checks, close), and the agent keeps its state in numbered Markdown files on disk, 00_governance.md to 99_next_action.md, so it can recover after a context reset. Before promising code, a read-only subagent checks every claim in the ticket against git log. Every edit is paired with a separate critic subagent, and bot review comments on the pull request are answered in one triage table. The models were Claude Sonnet 4.6 and Gemini 4 inside an IDE agent. He also ran a follow-up ticket with GPT-OSS 120B in the same setup as a comparison.

Across 926 steps and 18 subagents, all five tickets finished with no nudges from him. One high-priority ticket asked for a wrapper that had already been built and rejected in an earlier PR; the agent proposed closing it instead, and it was done in 8 minutes 29 seconds with no code. Two other tickets were cut down after the check found part of the work already on main. A critic caught a Flutter bug that the linter missed. When Claude hit its quota at step 432 of a 960-step UI run, he switched to Gemini 4, which read the state files and finished. GPT-OSS 120B failed: it ignored the state files, compacted six times, ran parallel git commits and was stopped at step 791.

The IDE agent is not named, only the models. The setup depends on a frontier model that obeys the first-turn rules; the open-weight model never wrote the state files, so the scaffolding did nothing for it. The article is part of a series, and the step counts and timings come from his own transcripts with no independent check.