Breken works a bug the way a maintainer does: read the report, find the cause in the source, build a reproduction someone else can run, then open the fix with a test attached. On 3 September 2026 a TanStack Router maintainer asked a reporter for a minimal reproducer; Breken published one twenty-six minutes later.
- 26Maintainer request to published reproductionElapsed time on 3 September 2026 between a TanStack Router maintainer asking for a minimal reproducer on issue #8224 and the reproduction repository being created. · as of 3 Sep 2026
- 23Codebases exercisedUpstream open-source repositories forked by the public breken-ai account, each carrying a named work branch, spanning TypeScript, Python, Go, Java, Clojure, PHP and Node. · as of 5 Sep 2026
The problem
Most bug reports arrive without the artefact that makes them useful. The maintainer's reply on that TanStack Router issue is the whole problem in one line — a request for a complete minimal reproducer, because the issue template already said one was required — and until somebody builds it, a real production bug sits still.
The answering half of engineering did not get cheaper the way the building half did. A root cause has to be found in code the responder did not write, in whatever language that project happens to use, and the cost is paid in reading rather than in typing.
The system
A per-repository grant, a fork with the whole tree in it, a reproduction that runs itself, and a pull request carrying its own regression test.
What it is made of
- Scope by grant. Access is per repository: you pick the repositories, and it reads and writes only those you grant. Read-only would not do, because the agent pushes branches and opens pull requests rather than only commenting.
- A fork per project, worked on a named branch, so a change is developed against the callers and tests that actually exist rather than against an isolated diff.
- A standalone reproduction repository — a handful of files plus a script that drives a browser, records the failing state and screenshots both sides of it, so the failure is executable rather than described.
- An upstream pull request that names the mechanism in the library's own terms — file, effect, dependency array — and adds a regression test the pull request states fails without the change.
My role
Breken is the second product I build at Brekfuz, and the fairest account of it is what it leaves in public rather than my description of it. The forks, the branches, the reproduction repositories and the pull requests are all readable by a stranger with a browser. That was the standard I wanted to hold it to: an agent whose output only exists inside a customer's account cannot be checked by anyone, including me.
The decisions
Ship the reproduction as its own repository, not a paragraph in a comment. The reproduction is a runnable project with pinned dependencies and a verification script that drives a browser and prints a verdict — the CSS repro pins an older React on purpose, because the newer version's stylesheet hoisting masks the bug. The alternative was describing the failure in the issue thread and leaving the maintainer to reconstruct it. It answers the request maintainers actually make, and it is falsifiable: anyone can clone it and watch it fail. It also means each reproduction carries version pins that will rot as the library moves.
Work inside a fork of the whole project, not against the diff. Fork the upstream repository and do the work on a named branch inside it. One branch runs seven commits across five files, alternating fix and test, and includes a commit reverting an earlier attempt of its own. Generating a patch from the issue text and the changed lines alone is cheaper and blind. The change is written against the real tree, and the false starts stay in the history where a reviewer can see them. The cost is a fork and a working copy per bug.
What is unresolved
The output is currently measured in artefacts produced rather than in changes accepted, and those are not the same thing. A maintainer's inbox is a scarce resource, and speed is a throughput number, not a quality one. There is also no independent account of the agent being wrong: the reproductions ship a verification script anyone can run, but the fix pull requests carry the agent's own claims about the suite it ran, unchecked by anyone outside it. The product is invite-only while that is still true, and the honest claim stops at the artefact that was asked for.