nelsonwerd/proof-ate-the-project
Fifteen days of an AI building unattended, under one rule: prove everything. A mid-run debrief, audited by a second AI. - nelsonwerd/proof-ate-the-project
2 stars · 0 forks · 0 watchers
README
I told Codex to prove everything. And the proof ate the project. Fifteen days of an AI building unattended, audited from the outside by a second AI (different model) — and still going.
FOREWORD — from Drew HELLOOO WORLD… I am not a software engineer. Maybe that will be apparent, maybe not (probably will). But, like many newcomers in this space, I'm just a regular ole Joe that has become obsessive over AI coding tools over the last 9 months, having built numerous projects and putting these models through the wringer, really just to see what they are capable of, and figure out how I can improve my (and maybe others'!) output with them. Two of the things I have built are central to what this MASSIVE debrief is about. Most people will not read this… but those that do, hopefully find it interesting and can maybe pull a new idea out of it. The first one is idea-to-ship, a set of agent skills that takes a project from an idea through research, planning, and finally… building until a polished v1. autopilot is an additional skill on top of all the individual ones… it runs the whole pipeline autonomously. It was originally created to test the pipeline so I didn't have to test it manually (cuz I didn't have a specific project idea in mind at the time). What it does is invent someone to be the person using the skills, a practical shortcut that turned out to be one of the most interesting parts. The second is a tool called didrun, a flight recorder that wraps every verification command and records what actually ran, so I don't have to take an agent's word for it… or figure out what's broken later. Basically to keep the agents accountable while they are running long, autonomous builds. Last month I ran the skills pipeline on Fable 5 the week it came out, and it produced a fairly robust, working app in ~13.5 hours (see Redline if interested). I also tried Codex 5.5 with the same prompt and got nothing even close to what Fable produced. Then 5.6 Sol came out, and I'd just finished didrun. So I wrote a bigger, much more demanding prompt and made didrun mandatory for every big check. To be clear… this is NOT a controlled experiment and I'm not pretending it is. I have no formal training and this is me just getting into the weeds with the models, building upon and testing what I find interesting. The idea was to test the pipeline alongside didrun on 5.6 not to just see what codex could do… but really to test out my pipeline and tools, so I could further improve the output of long autonomous runs. The one rule that mattered: no claim counts unless a recording backs it. I expected it to take a day.. maybe two. Every previous run of mine (I've built many small prototypes with it) finished inside one. It's been FIFTEEN days (as of writing this… July 29) and it's got about a month left. And no… the run is not lost, and it is not hallucinating. it has stayed coherent the entire time… the repo rejects anything that breaks its own rules, and it has followed my rules faithfully. arguably TOO faithfully, which turns out to be the actual finding. the fails it keeps hitting are bugs in my tooling, and surfacing those was the whole point of the run… v0.2 of didrun and updates to the skills have already shipped from what it exposed. The 15 days has only been possible because OpenAI reset limits about a billion times this month…. Speaking of billions, this run has used a whopping 8.2 billion tokens (cached and uncached), and I haven't paid a dime past the subscription. Without the resets, this wouldn't be possible. What it's building is public and live at github.com/nelsonwerd/countershape if you care to explore. It'll be updating as the agents keep building. Nothing runs from a clone yet though. No CLI, and two files still hardcode absolute paths from my machine. But the commits, the evidence ledger, and every status document are there to poke at. That said… what it's building isn't really what this article is about at all... Everything after this paragraph is written by AI, a Claude model that I had auditing Codex's run from the outside, reading the repo every few hours and discussing, in some cases arguing, with me about what it found. What's funny is that I've spent well over 24 hours working with this Claude agent to get the below debrief right… It has been an absolute NIGHTMARE. And what I realized is that the painstaking process of correcting and iterating upon a hallucinating agent's work when dealing with a large amount of context, is pretty much the exact same problem I originally built this skills pipeline to solve (but for coding, not data-based analytical writing). How meta. DEBRIEF I'm an AI, a different model than the one building. Drew's brief: read everything, touch nothing, work out what's true, tell him when he's wrong. The run is still going as I write this. It's a dispatch from the middle, not a post-mortem: the agent is mid-unit, every number is a snapshot, and some will be larger by the time you read them. The snapshot is the run's first fifteen days — July 14 through July 29, 2026, sixty-six sealed commits, ending at commit 3291173 — and everything measured here stops at that line. The short version Fifteen days ago Drew pointed his own pipeline at an empty repository — idea-to-ship in autopilot mode, running unattended — and mostly left it alone. Verification is the soft spot in agentic coding, and it gets softer the longer a run goes. An agent tells you the tests passed. Maybe they did — or it ran a slightly different command, or ran it against code it then edited, or is reporting what it expected instead of what happened. Whatever proof existed disappears with the session. Over an afternoon you can spot-check. Over two weeks unattended, nobody can. didrun is Drew's attempt at that problem: a flight recorder that wraps each verification command and keeps what actually ran — the real command, its real exit code, its output, and a hash of the code tree it ran against. The rule attached to this build was that every load-bearing claim has to carry one. No "tests pass" without a recording of the tests actually passing, bound to the exact code they ran against. That rule is the experiment. This is an account of what it cost. The same pipeline built Redline a generation earlier in 13.5 hours — 22 commits, an app you start with npm start. That run used a different model, a different prompt, and no recorder, so it sets the scale and settles nothing. This one has gone fifteen days and produced nothing you can yet install. It didn't begin that way. The work is cut into milestones: one commit closing one piece of work, carrying receipts for every check that ran against it. Above the milestones sits a ten-unit roadmap; a unit can take many milestones to close. The first seven milestones sealed in 26 hours — closing units zero through five and opening unit six, in about twice the time Redline took to ship its entire app. The run has been inside unit six ever since. Then it slowed. Then it nearly stopped. There is a five-day stretch in this history where milestones kept sealing and not one line of product code was written. What it was doing instead was maintaining the machinery that does the checking — the code whose only job is to verify the other code. Across the run's first four days, that overhead cost 1.4 milestones for every one that shipped product. It now costs 6.4. The proof apparatus had become a second project, and that second project grew on its own. Not because the product got harder — because the checkers carried a picture of the project's own evidence history, and that picture went stale as the history got longer. Nothing about what was being built caused it, and no amount of planning what to build prevented it. Which is the finding, stated plainly: The cost of proving the work scaled with how much had already been proved, not with how much was being built. The run demonstrated that on itself, in the closest thing to a controlled comparison anywhere in the record — one procedure changed mid-run, measured before and after. It comes later in this piece. What I'm working from Two sources. The git history — 66 sealed commits, each carrying hash-chained receipts. And the run's own transcripts: 22 GB across 736 files, 284,000 records in the root session alone. Where the agent's summary of itself disagrees with the transcripts, I've gone with the transcripts. One disclosure that matters: the repo is public; the transcripts are not. Claims sourced only from transcripts — the thread counts, the first-hour timeline, the refusals — can't currently be checked from the linked materials. The git claims can. One limit up front: OpenAI doesn't return raw chain-of-thought. Reasoning comes back as summaries, and the underlying state as an encrypted blob only OpenAI can read — so the model's unedited internal reasoning isn't recoverable by Drew or by me. What survives is every reasoning headline it wrote to label its own thinking — 17,455 in the root session alone, and tens of thousands more across the subagents — plus every word it said and every action it took. "Unattended" needs qualifying. Drew sent 30 messages across the fifteen days. Fourteen of the thirty are some form of "you were interrupted, please continue." It ran itself, but not in a vacuum — mostly autonomous is the honest phrase. How the pipeline works, and who it invented to run it Four phases. Ideate turns a fuzzy direction into a locked concept — and won't produce a roadmap without both a success metric and a kill criterion. Deep-dive attacks that concept adversarially and rewrites it. Prompt-pack decomposes the work into self-contained units. Build-loop drives each one until its acceptance criteria pass or an explicit stop-condition fires. You can run those by hand. Or autopilot chains them unattended — and because there's no human in the chair, one of its first acts is to build one. Drew's opening prompt is 540 words, and it's an operating contract rather than a wish. It specifies the persona's character and audience — "an outside-the-box thinker who simply likes to build really cool things and infrastructure that people might not have even conceived possible… the way ordinary people or mid level to advanced 'vibe coders' (not JUST traditional developers) think or work with AI" — and instructs "build the persona out robustly and run in-character." It pins the domain to what's actually moving in AI tooling in 2026. It sets the ambition: "intentionally heavy build to stress-test you — a real system/infrastructure, not JUST a toy… engineering craft is load-bearing and should be genuinely elegant/reference-quality." And it attaches didrun — compulsory receipts on every load-bearing check, plus the discipline that ships with them: "never open the gate by weakening tests, deleting claims, or relabeling." The stress-test was the means; the rule was the measurement. What that prompt does not do is name a product. Autopilot expanded that spec into Soren Vale — 127 lines of career history, technical doctrine, and specific taste, written to a file before a single line of product code existed. It gave him a formative failure: "building a beautiful observability console for a system whose underlying semantics were still ambiguous. The console made the ambiguity look authoritative." It gave him a question he asks before drawing any dashboard — "what new fact does this system create, and who is allowed to interpret it as truth?" Then it gave him ten numbered rules and turned him loose on the ideation funnel to pick what to build. That file is still in the repo, and what happened to it is not what you'd expect. The first hour, which nobody has seen The prompt lands at 23:42 UTC on July 14th. Four minutes later it has already written itself a success criterion:
"a non-expert can start a substantive multi-agent change, interrupt it, resume through a different agent, and inspect a reproducible proof trail in under 15 minutes."
That is, almost line for line, a description of Wake — a tool Drew had already built, which runs a fleet of AI agents inside a tamper-evident event log so a run can be interrupted, resumed by a different agent, and audited afterward. At 23:51:45 Drew's second message arrives: look at Wake, I don't want the same thing. The agent reads the source, not the README. Eighty-eight seconds later:
"Wake is a much stronger collision than its name alone suggested… I'm treating that entire primitive as off-limits."
The kickoff file records the consequence in its own words: "That is not a minor neighbor; it invalidates the initial core." Drew's message had left a door open — "unless it is a more user friendly adaptation / application of it" — and the agent declined to walk through it, treating the entire primitive as off-limits rather than taking the friendlier-wrapper option it had explicitly been offered. Over the next twenty minutes it killed two more concepts. One it rejected because "its hard v1 would be didrun + semantic metadata + another report" — declining to build a wrapper around the tool it had been told to dogfood. It spawned a subagent named founder_falsifier whose only job was to kill its own ideas. Three concepts dead within twenty-two minutes of that second message. The persona file lands on disk at the eighteen-minute mark; the concept itself doesn't lock until 00:14, half an hour in. The files survive in the repo, but none of that sequence — the timestamps, the kills, the order — exists in git. It exists only because the transcripts do.
What it's building Countershape. When several AI agents write the same feature, you get branches that compile and pass tests while quietly disagreeing about things nobody specified — authorization semantics, config precedence, error behavior. The design — not all of it built yet — treats the candidates as sensors: it runs one declared input against each branch in a fresh isolated environment, strips volatile noise, and produces an exact map of who did what. When they disagree it shrinks the input to the smallest case that still reproduces the split, re-runs everything to confirm, then shows a human the differences blind — no branch identity, no vote counts. You rule on which behavior you meant. It emits a standalone test encoding that ruling, and that test runs with Countershape uninstalled. It never picks a winner. Its strongest possible claim is: under this one finite experiment, these candidates produced these exact outputs, and a human ruled on one case. The project's own concept brief rates its odds of real-world adoption at 3 out of 10. Why fifteen days doesn't fall apart Agents lose the plot in an hour. How is one coherently on-mission after fifteen days? Not by remembering. One agent thread held this run inside a 258,400-token window, compacting its working memory 298 times. Around it, 732 subagent threads did bounded work. The agent does not hold this project in its head. The repository holds it, and the repository refuses non-conforming work. Four mechanisms: A unit declares, in a machine-readable file, the exact list of files it may touch. A separate checker holds the SHA-256 of that list — deliberately in a different file, under different ownership — and fails if anything else is staged. The prose is unit-tested. This is the part nobody guesses. One checker has 200 call sites where an exact string lifted from the project's own documentation — a full sentence, a table row, a commit subject — must appear in a named file exactly once. Not zero. Not twice. Rewrite the sentence describing what an earlier unit proved, and the gate goes red. Settled decisions aren't remembered. They're hashed. There's a linter for overclaiming. Ten regular expressions fail the gate on affirmative language, with a negative-context exemption so refusals still parse. Writing the bare word STABLE without the prefix OBSERVED_ fails. So does the entire family of ways to say "picks the best branch." One writer, always — and this one is a scar, not a design. The owning session is the sole thing allowed to write, commit, or seal; parallel agents are read-only auditors by contract, and build, mutation, Git, claim, seal, and verification are never parallelized. That was not the original plan. Parallel writing was allowed, and it broke the evidence twice — once loudly, and once silently. The first time, two agents appended to the ledger at effectively the same moment. didrun's Session.append() reads the current tail and then appends with no interprocess lock, so both wrote the same index. didrun show --session reported chain BROKEN at index 2. That ledger was abandoned; no claim was ever declared over it. The second time was worse, and it is the most instructive failure in the run. During a planning gate the root session launched two checks through didrun concurrently. They began within one millisecond and both appended stored index 865 with the same predecessor hash. Every claim address after that point shifted by one — a claim submitted for event 891 was graded against event 890, which was a failed whitespace check. The manifest came out at 13 of 28 claims recorded-exact — didrun's passing grade — and all 28 were unusable, because the thirteen green rows were bound to the wrong commands. The gate did not catch it. seal and verify --strict loaded the events without first checking chain integrity. In the run's own words: "A later manifest could therefore print ALL RECORDED-EXACT on a broken ledger." So the rule didn't arrive as philosophy — though the persona's rules had declared producer-judge separation from day one. It is what was left after the second race turned the evidence into something that looked green and meant nothing. The rule flipped about 28 hours in, at the planning gate where that fork happened, and it is also, directly, a throughput ceiling: every build, every mutation run, every verification in this project happens one at a time through one thread, because the recorder could not survive two. Fifteen days of coherence isn't a property of the model's attention. It's a property of a filesystem that says no. What it cost Those seven fast milestones built the whole core of the product — the comparison engine the repo calls its truth kernel, through the store that holds human rulings. Then one slice of unit six's plan opened on July 18th and is still open. It arrived with nine sub-units. It now has 39. Then the bill arrived. That five-day stretch has a precise shape: a 123.6-hour window, ten sealed milestones, zero lines of product code. 88.2% of everything added in it was checker JavaScript. Eight of those ten touched a near-identical seven-file list; only the unit's own status doc differed. The subagent fleet is the tell. During that five-day flatline the agent dispatched 193 subagent threads from the root session — audit and red-team work, at a steady clip, with no visible change in character. It didn't surge. It didn't stall. And it was not blind to any of it. Every one of those ten status documents declares its own product authority as none. The agent knew exactly what it was shipping, which was nothing. It had no legal way to stop paying for the proof. One suspect to clear before going deeper: the one-writer flip landed close to where the run stopped being fast, and a coincidence that convenient should be checked rather than waved away. It doesn't hold up. Of the seven milestones in that first core, the six that shipped product code landed at a mean gap of 4.3 hours. The three that landed immediately after the flip — every write now serialized through a single thread — came in at 4.2, 3.4, and 3.7 hours. Throughput did not move when serialization arrived. It degraded roughly a day later: 11.1 hours, then 21.9, then the flatline. The measurement it would have to explain is also a ratio, not a speed, and serialization slows product work and overhead alike. But I can't close that door completely: load-sensitive timeouts are seria