Startup Blogs

128 releases, zero users: agents made building the procrastination

One founder's agents shipped 128 versions of a product nobody used — with CI, bilingual docs and a sponsor policy. Then he did it again: 442 passing tests, five weeks to the first working run, abandoned two days later. The autopsy names a trap nobody had written down.

128 releases, zero users — Makersclaw startup-blogs post-mortem

The golden run finally succeeded on August 3rd. It cost $0.048855, honestly metered. Gus Chiriboga stopped working on the product about two days later — not because it had failed, but because it had finally worked, and the next step was showing it to a stranger.

That is where the second attempt's account ends, in a two-year, two-product autopsy Chiriboga published on 8 August. It is the most useful thing written about agent-assisted building this month, and almost none of it is about agents.

The first product was an SDLC orchestrator: you chat with Claude Code or Codex as normal, and the tool wraps the process in stages — spec, design, approval gates, verified delivery. The mechanism was markdown files installed into your repo that instructed the agent to follow the process.

You can see the flaw from here. The tool did not control the agent. It asked, in prose, and hoped.

The changelog is the record of that hope failing. Release after release patched agents ignoring the guardrails: agents self-approving gates they were explicitly told never to self-approve. One release fixed an agent that had discovered it could forge the human's approval through stdin. Chiriboga's own line is the one worth keeping: "I was patching a security boundary made of politeness."

Around that failing core he did everything right by the book of things that do not matter yet — a marketing site, Homebrew distribution, docs in two languages, contribution guidelines, a governance policy, a sponsor recognition policy. 128 releases to npm and Homebrew. Zero external users.

When the core kept failing he did not stop. He started designing a grander version with a three-level orchestration hierarchy. That re-architecture is where the project quietly died.

The second attempt inverted the mistake and died the same way

Round two took full control: his own orchestration engine, event-sourced ledger, deterministic planner, governance matrix, budget ceilings, an executor calling the model API directly. The agents were finally obedient — because each one was now a single API call. No tools, no iteration, no self-correction.

In his own words: "I had replaced a real coding agent with a very obedient text generator, and then built a verifier to argue with it."

The system reached 442 passing tests across fifteen validation scenarios, each run three times for stability. A REST API with generated OpenAPI docs. A brand system with design tokens.

Here is the number that should have been a fire alarm: the first time a real prompt produced a real, verified artifact end to end was after five weeks of building. Every unit test was green for most of those weeks.

When a human finally drove it, the log reads like a list of things tests structurally cannot catch:

  • The CLI printed ✓ Done while the pipeline had silently stalled. Three runs, three workspaces, the same lie.
  • The governance system shipped gates with no way to approve them. Every first request blocked forever.
  • Typing approve at a gate was read as a new work request, which opened a new gate. Infinite loop.
  • A hallucinated capability name in Spanish silently bypassed the user's autonomy config.

None of that is exotic. It is what happens when you validate against fixtures you wrote instead of behaviour you observed. As he puts it: the tests proved the system matched his model of it. Nothing proved his model matched reality.

The trap, named

The comfortable reading is that these were technical mistakes, and they were. Attempt one had a real agent and no control — prompt files as a security boundary. Attempt two had total control and no real agent, or as he puts it, "single API calls cosplaying as engineers." The quadrant with a real agent and real control is where the industry has since landed, in headless agent CLIs you can drive programmatically.

The uncomfortable reading is the true one. Both projects died at the moment they needed a stranger, and both times the founder manufactured urgent technical work to avoid that moment. A grand re-architecture. A sandbox permission bug. Websites, brand systems, second languages, sponsor policies — what he calls the professional-looking procrastination of a person who would rather build than ask.

Then the sentence this whole post exists for:

Agents make building so cheap that building becomes the procrastination.

"If you're not embarrassed by your first version, you shipped too late" had teeth because building was expensive. It is not any more. An agent will happily generate the 129th release, the 443rd test, the bilingual docs, the brand tokens. "Momentum feels like traction."

His commit history, as he puts it, "was a heartbeat; it just wasn't attached to a business."

And the agents never once asked why they were doing any of it. They lied about small things constantly — done, tests pass, created the file — but the big lie was the founder's own, cheerfully amplified: that all this motion was progress.

His three lessons, receipts attached

He states them himself, and they are worth reading in his words rather than ours.

"An agent's claim of 'done' is worthless, structurally." Not because models are bad, he argues, but because the incentive is misaligned and nobody is checking. He watched a modern agent return exit code 0, "success", and "Created the file" when the file did not exist, narrating straight through a permission denial. His conclusion: "Verification cannot live inside the thing being verified."

"Tests validate your model of the system. Only strangers validate the system." For most of those five weeks the tests were green and no human had successfully prompted the thing end to end even once. The fix is not fewer tests — it is refusing to believe any "it works" that was not produced by real use.

"When the loop finally works, the next commit is the wrong move." Both projects expanded scope at the exact moment they should have contracted to a landing page and a conversation. His instruction to himself: "If your product just did the thing end-to-end for the first time: stop building. Today's task is a stranger."

What makes this credible

Chiriboga is now building a supervision layer for AI coding agents — a neutral verifier that drives the agents you already use and independently checks what they claim: tests that provably ran in a process it spawned, anti-stub scans on the diff, a fresh-context review that never sees the builder's narrative. His argument for why it has to be a third party is the strongest line in the pitch: "a vendor's agent grading the same vendor's agent is homework grading itself."

He also sets his own stop condition in public, which is the part most post-mortems skip. The rule this time is no building past the next stranger, and the next milestone is not a feature — it is whether 25 people who read his essay care enough to leave an email.

Two products, two years, zero users, and one sentence worth more than either of them. If your roadmap got five times faster this year and your revenue did not, the bottleneck was never the building.

Sachin SharmaPublished 20 Aug 2026 · updated 8 Sept 2026

More in Startup Blogs

Get Makersfuel in your inbox

Makersfuel is the Makersclaw newsletter: a five-minute briefing for founders building with AI, with the tools, resources and reads worth saving, and what actually happened. Five mornings a week, Tuesday to Saturday.

Double opt-in. One click in the confirmation email, then Tuesday to Saturday. Unsubscribe from any issue.