The Corpus Contains Itself
In one day in May, from a little after midnight to a little after ten in the morning, an agent built a multi-tenant data-request platform from a spec it had not written and I had not written either.
The spec came from a different app of mine. That app interviews you about what you want built and climbs through three model tiers until it has a specification it trusts. Then it runs a planner that turns the spec into a phased build plan. Three phase files and a README, each phase written so that an agent can run it with nothing but that file and the requirements document. No other context. No follow-up questions.
I handed those files to Claude Code. It built the thing in exactly those phases, one branch per phase, no squashing, with a commit body at the end of each one that walked the phase's done-criteria against the running system.
And here is the part I keep turning over. The sessions that did the building are files. They live under the same home directory folder that the first app harvests to learn what I work on. The next scan picks them up by modification time. The session where I wrote the description this post is based on ran inside the new repo, reading both. It is a file there now too.
The spec factory specced the app. The app's build sessions are now inputs to the spec factory. The corpus contains itself.
What Got Built
I should say what the thing is, because "data-request platform" is the kind of phrase that means nothing.
Inside a large company, a business person who needs data does not know how to ask for it. They say "I need the churn numbers" and an analyst spends a week finding out that they meant something specific about one region and one plan year. This app puts an interview between those two people. It asks one clarifying question per turn, based only on the client's actual uploaded schema, with the instruction not to invent tables or columns. It scores the request as it goes for how clear it is and whether it can be done. When the request is hard enough, it becomes a structured spec. An analyst takes the spec, and the app generates a single read-only SQL statement and a Power BI template from it. The SQL gets checked against a mirrored database before anyone sees it, using synthetic data made inside a transaction that is always rolled back. Nothing is left behind.
Four services behind one gateway. Go for the public edge, Node for the model flows and the data model, React in front, Postgres underneath. Tenant isolation enforced server-side from the verified token, never from the request body.
None of that is novel. What is new to me is that the app is a rebuild of the app that specced it. Interview, harden into a spec, plan against the spec. Same shape, new domain. The spec factory's design was the template, and the planner produced a plan for building a copy of itself pointed at a different problem. I did not ask for that. It is just what came out.
The Fingerprint
The plan files themselves are not in the repo. They lived in a gitignored folder and were never committed. So I cannot show you a byte-level diff proving that the planner's output was the agent's input. I want to be clear about that, because the rest of this post rests on it.
What I can show is structural. The planner pins its output filenames: foundation, core build, hardening. Each carries preconditions and done-criteria. The repo's history is three feature commits with those exact names in that exact order, and each commit body verifies that phase's done-criteria. Phase one is 39 files and 1,322 insertions. Phase two is 59 files and about 4,400 insertions, the whole data model and every screen. Phase three is 72 files and about 3,100 insertions: tests at 86.5 percent backend line coverage, race-clean Go tests, prompt-injection wrapping, SELECT-only enforcement, encrypted connection strings, CI, and a compliance notes file.
The match is exact and it is not a coincidence. It is also not proof. It is a fingerprint.
The Agent Argued With the Spec
The commit body for phase three has a section called "Flagged deviations." Three places where the agent overrode the plan and said why.
The plan wanted a Docker Compose test profile. The agent called that an anti-pattern for this stack and did it differently. The plan's secrets-audit grep was too loose, so the agent tightened it. The plan assumed server-sent events would use the browser's EventSource. The agent pointed out that EventSource cannot carry the auth token, so it used fetch instead.
I have read a lot of agent output that is transcription with extra steps. This was not that. It was execution with judgment, against a written plan, with the disagreements logged where I could find them. The plan said each phase had to run with no follow-up questions, and the agent honored that by not asking. It just wrote down where it departed and kept going.
I think that is the right contract. I also think I got lucky that all three deviations were correct, and I do not have a good answer for the day one is not. Probably I find out from a user.
The Money
A dashboard I built for this shows the family of sessions as a graph. The spec factory: 67 sessions, 622 prompts, about 1,700 dollars of estimated spend to build. The three sessions in which it specced the new app: 35 dollars. The thirteen sessions in which the agent built the new app: 941 dollars. Altogether, with a logging tool that fed the same corpus, about 2,700 dollars.
Those numbers come from the dashboard, not from anything in either repository, and the dashboard estimates cost from token counts. Take them as the shape, not the invoice.
The shape is what interests me. Thirty-five dollars of interview and planning produced a plan that a thousand dollars of agent time executed in ten hours. That ratio is the whole argument for spending on the spec. I did not design that ratio. I found it afterward, in the exhaust.
Where It Ends
I do not have a clean ending, because the loop does not have one. Every session I run inside this repo becomes a row in the next harvest. The harvest feeds the tool that would spec the next app. If I build that app, its sessions land in the same folder.
At some point this stops being a dogfooding story and becomes a question about what the corpus is for. Right now it is for me, a private record of how I work that gets more complete every time I work. I like that. I also notice that the thing being harvested is increasingly the harvester, and I do not yet know whether that ends in something useful or in a very well-documented circle.
I will find out. The session where I find out will be in the folder, which is either reassuring or the punchline.
-- Justin Higgins. Software Engineer, Midwest. Built a tool that specs tools, then let it spec one.
Companion pieces: The Work Looks Like Nothing - the folder this post is harvested from. The Rules Are Downstream of the Work - the harness that bootstrapped on its own output.
Reactions, disagreements, war stories: jchigg2000.dev@gmail.com