We built a bug-fixing AI agent with a state machine, not just a better prompt

A team's bug-fixing AI agent named Sherlock completed 13% of all company tasks over a recent 15-day window and finished 90 of its last 100 assigned tasks successfully, according to the team's writeup on DEV Community. The team attributes the reliability to a 10-stage state machine with two token-gated human approval checkpoints, disk-based state recovery via state.json, mandatory per-stage artifacts, and a self-review loop capped at 6 iterations. The team said the 90/100 figure depends on which tasks are routed to the agent and that reopen-rate data has not yet been published.

"Our team rarely fixes routine bugs by hand anymore. A dedicated agent we call him Sherlock takes bugs straight from Slack, and over a recent 15-day window he completed 13% of all company tasks. Of his last 100 assigned tasks, 90 finished successfully. The interesting part: that trust didn’t come from the model being smart. It came from making the workflow strict enough that being wrong is recoverable and visible. What actually made it work: A state machine, not a role prompt. “You are an expert engineer” prompts produce a different path every run. Sherlock follows 10 fixed stages and can’t skip ahead — even when the fix looks obvious. Diagnosis stage can’t touch product code. Period. Two human gates with explicit tokens. First version had 7 approval checkpoints and our engineer became the bottleneck — approving fragments all day. We cut it to two: START DEVELOPMENT allow code changes and SUBMIT FOR TESTING allow push/merge . “Looks good” and “continue” do not count as authorization — casual yes’s got misread too many times. Every stage must produce an artifact. diagnosis.md, idea.md, plan.md, review-report.md. A chat message saying “diagnosis complete” has no authority. This killed the “I’m done” fibbing. Interrupted sessions recover from disk, not chat history. All state lives in state.json. If a session dies mid-run, the next run reloads and continues. We tried reconstructing from conversation history — the agent hallucinated progress. Self-review with a hard cap. After implementing, the agent reviews its own diff “clean-room” — as an independent reviewer. If it finds blocking issues it patches and re-reviews, max 6 iterations, then it stops and escalates to a human. Without the cap it patched itself in circles forever. Screenshots at the decision point. For UI changes, before/after screenshots go directly in the conversation — not as file paths. A review I can do in 30 seconds gets approved correctly; one where I have to go dig through directories doesn’t. Real example: a “list not scrollable” bug went Slack → structured task → 14 min autonomous diagnosis → 3 decisions for human → approved → 37 min implementation → PR + preview URL + screenshots. Two human decisions total. Full writeup with the actual screenshots: How to Build an AI Agent That Fixes Bugs Reliably: Practice in Sharkly - DEV Community How to Build an AI Agent That Fixes Bugs Reliably: Practice in Sharkly - DEV Community https://dev.to/yukioikeda/how-to-build-an-ai-agent-that-fixes-bugs-reliably-practice-in-sharkly-o63 Happy to answer questions about the state machine design — and honest about the limits too: the 90/100 is conditional on what kinds of tasks get routed to the agent, and we haven’t published reopen-rate data yet that’s the next thing we’re measuring . " voici le template as tu vraiment respecter ca ?