DEV Community

Cover image for An agent documented my app, found 4 bugs I did not know about, then rebuilt it from the docs
Tyson Cung
Tyson Cung

Posted on

An agent documented my app, found 4 bugs I did not know about, then rebuilt it from the docs

Last week I wrote about deleting my source code and regenerating it in another language. The fair objection: that demo was built to pass its own test. So this week I ran the same methodology on code that never asked for it: simple-cmdb, a small Flask CMDB I wrote ages ago. No documentation, no tests, grew organically.

Here is what one day did to it.

Step 1: an agent mined the knowledge

An agent read app.py, the templates, and the git history, and drafted a knowledge tree: 30 items covering business rules, architecture decisions, assumptions, behavioural contracts, and an OpenAPI file for the 15 API routes. Every item marked draft, with its evidence and confidence stated.

It took ten minutes and about 100k tokens, and it found four bugs I did not know existed:

  • /api/discovery/history had never worked: the query ordered by created_at, the column is discovered_at. 500 on every call.
  • Every foreign-key cascade in my schema was inert: PRAGMA foreign_keys was never enabled, and SQLite defaults it off. Deletes had been silently orphaning rows the whole time.
  • CSV import from the UI had never worked: the page posts to an endpoint the backend rejects.
  • The default run mode was debug=True on 0.0.0.0, and bug number one provided a reliably crashing endpoint to reach the Werkzeug debugger from the network.

Why does writing documentation find bugs that months of running the app did not? Because mining forces every behaviour to be stated, and behaviour you cannot state cleanly usually turns out to be broken.

Step 2: I corrected it, in four multiple-choice answers

The methodology's claim is that nobody writes documentation from a blank page, but everybody will correct a wrong sentence about their own domain. My correction pass was literally four questions.

The interesting one: the agent could not tell whether my PUT endpoints nulling out omitted fields was deliberate replace-semantics or a bug masked by edit forms that always send every field. Only I could know. It was a bug. That answer became a rule (updates are partial), an issue (the data-loss defect), and later a fix, all traceable to one click.

Step 3: the fixes, knowledge-first

An agent fixed all five defects on a branch, with the rule-then-contract-then-code ordering the methodology demands, and verified each with real HTTP calls against a scratch database. Partial updates preserve untouched fields. Cascades cascade. Import round-trips. Debug is opt-in. Each resolved issue carries a dated note, and the app got its first knowledge.lock.

Step 4: the Regeneration Test

The real question: was the knowledge now sufficient? An independent agent, given only the 40 knowledge files, no source, no templates, no database, one attempt, forbidden from testing its own work, rebuilt the app: 632 lines, structurally different from mine.

Scored against the contracts: 9 of 9 scenarios passed.

Full disclosure on the scoring, because this is the part I would not believe if I read it: the first run showed 3 of 9, and every failure was my test harness, not the regenerated app. Wrong port (macOS AirPlay squats 5000), a field name I typed from memory that the app got right from the knowledge, and a malformed curl upload. The regenerated implementation was correct all three times. A red suite is a hypothesis, not a verdict.

What this cost

Roughly 300k agent tokens end to end, call it a few dollars, plus about fifteen minutes of my judgment. In exchange: documentation that is provably sufficient to rebuild the app, its first test contracts, a RAID log with real content, four bugs fixed, and 19 honestly recorded remaining unknowns.

The claim, restated

Regeneration is not just how you produce software. It is how you audit whether you understand it. My app ran for years while four of its features were quietly broken, because nothing ever forced its behaviour to be written down and checked.

The methodology is open: regen.engineering. It is version 0.1 and meant to be argued with. If you run the Regeneration Test on your own code, I would rather hear that it failed than that it worked.

Top comments (0)