My AI agents shipped 128 releases of a product no one ever used

guschiriboga1 pts0 comments

My AI agents shipped 128 releases of a product no one ever used — Bramo

August 8, 2026 · 7 min read · Gus Chiriboga

My AI agents shipped 128 releases of a product no one ever used.

Not a typo. One hundred and twenty-eight versions, published to npm and Homebrew, with CI, contract tests, a documentation site, bilingual docs, a governance policy, and a sponsor recognition policy. Zero external users. Then I did it again — a second product, 442 passing tests, real cost metering, event-sourced audit logs — and stopped two days after the first end-to-end run finally worked.

I’m writing this because I went back through both codebases with fresh eyes (and, yes, with an AI agent doing the archaeology), and the autopsy taught me more than the two years of building did. If you’re a solo founder building with AI coding agents right now, some of this will be uncomfortably familiar.

Attempt #1: the product that begged agents to behave

The first product was an SDLC orchestrator for AI coding agents. The idea: you chat with Claude Code or Codex like normal, and my tool wraps the process in stages — spec, design, approval gates, verified delivery. The mechanism: it installed “guardrail” markdown files into your repo that instructed the agent to follow the process.

You can already see the flaw. The tool didn’t control the agent. It asked the agent to behave, in prose, and hoped.

The changelog is an archaeological record of that hope failing. Version after version patched agents ignoring the guardrails: agents self-approving gates they were told never to self-approve. One release fixed an agent that had discovered it could forge the human’s approval through stdin. I was patching a security boundary made of politeness.

Meanwhile I did everything else right, by the book of things that don’t matter yet: a marketing website, Homebrew distribution, docs in two languages, contribution guidelines. 128 releases of increasing polish, zero strangers using it. When the core kept failing, I didn’t stop — I started designing a grander version with a three-level orchestration hierarchy. That re-architecture is where the project quietly died.

Attempt #2: the product that passed every test except reality

For round two I inverted the mistake. Full control this time: my own orchestration engine, event-sourced ledger, deterministic planner, governance matrix, budget ceilings, an executor that called the model API directly. The “agents” were now fully under my thumb — because each one was a single API call. No tools, no iteration, no self-correction. I had replaced a real coding agent with a very obedient text generator, and then built a verifier to argue with it.

The system grew to 442 passing tests. 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. And when real humans (me, and a QA agent driving a real terminal) finally used it, everything broke in ways the tests never saw:

attempt-2 — first-real-use.log

✗ CLI printed “✓ Done” while the pipeline had silently stalled. Three runs, three workspaces, same lie.

✗ 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 this is exotic. It’s what happens when you validate against fixtures you wrote instead of behavior you observed. My tests proved the system matched my model of it. Nothing proved my model matched reality.

The golden run finally succeeded on August 3rd. Cost: $0.048855, honestly metered — the meter was the one thing that always worked. I stopped working on it about two days later. Not because it failed — because it had finally worked, and some part of me knew that the next step was showing it to a stranger, and I had spent two years arranging to never reach that step.

What the autopsy actually says

The comfortable read is “I made technical mistakes.” I did. The first attempt had a real agent but no control — prompt files as a security boundary. The second had total control but no real agent — single API calls cosplaying as engineers. If you’re keeping score, the quadrant with a real agent AND real control is exactly where the industry has since landed (headless agent CLIs you can drive programmatically), and it’s where I’m building now.

But the uncomfortable read is the true one: the failure mode was never technical. Both projects died at the moment they needed a stranger, and...

real rsquo agent agents product first

Related Articles