Home/Blog/We Pointed a Camera at Our Own Product and Fixed Five Bugs in a Day
OutcomeDev Team

We Pointed a Camera at Our Own Product and Fixed Five Bugs in a Day

What happened when we recorded a real OutcomeDev run end-to-end: every take that failed, the production bugs each failure exposed, and why dogfooding with a camera running is the most honest QA we know.

We wanted a simple thing: a screen recording of OutcomeDev doing a real job, start to finish. Type a prompt, watch the agent build an invoice generator, end on a working app and a pull request. One take, maybe two.

It took four takes. And every failed take exposed a real production bug, the kind that had been sitting quietly in paths our tests didn't stress and our own daily usage didn't hit. Here's the honest ledger.

Take 1: the sandbox that refused to exist

The task errored at 25% with the least helpful message in distributed systems: Status code 400 is not ok.

The cause was an interaction between two correct-seeming decisions. Our auto mode derives each task's time ceiling from the user's plan and remaining balance, and it had granted 60 minutes. Our sandbox infrastructure caps a single sandbox's runtime at 45. Every manually-configured task in history had defaulted to 30 minutes and sailed under the limit; auto mode was the first thing ambitious enough to ask for more than the infrastructure could give.

Fix: the requested duration is now clamped to the provider ceiling at every path that creates a sandbox, including scheduled tasks and retries. The billing pre-check and the infrastructure can no longer disagree.

Take 2: the agent that worked hard on the wrong plan

Take 2 "completed successfully." The agent built a genuinely good invoice generator, and then spent minutes wrestling a deployment CLI, never created the repository the prompt asked for, and finished with the app existing only inside a sandbox scheduled for reclamation. Green checkmark, no outcome.

The root cause was embarrassing in the way only architectural gaps are: one of our agent execution paths ran with no platform context at all. The agent didn't know a live preview pane existed. It didn't know the platform auto-commits and pushes its work. So when the prompt said "deploy it so I can use it," it reached for the only mental model it had: external hosting.

Fix: every agent now receives platform context on every path: the preview URL and port, the rule that a running dev server is the deliverable, and an instruction to end with an outcome handover. We also taught the task pipeline to honor "create a repo called X" in plain language. The platform now creates the repository up front and runs the task against it.

Take 3: right room, wrong desk

With context injected, take 3 nearly landed. The agent built the app, started the dev server, verified it with curl, and handed over the preview URL. Textbook. One problem: it did all of this in a sibling directory it invented, while the pre-created repository sat cloned and ignored a few paths away. Nothing pushed. No pull request.

Fix: the platform context now includes repository context: you are inside a clone, all work happens here, "create a repo" has already been fulfilled, the platform handles push and PR. We also made repo creation idempotent: retrying a task whose repo already exists reuses it instead of silently downgrading.

Take 4: three minutes, receipts attached

Prompt typed on camera. Repository created from the sentence. Agent builds in the clone, starts the dev server, verifies the page responds, hands over the preview. Platform commits, pushes the branch, prepares the pull request. Elapsed: about three minutes of a 45-minute ceiling.

Then, reviewing the footage, we found a bug in the app the agent built: a money-formatting slip that turned a $900 line item into $90,000. So we did the most on-brand thing possible: sent the agent a one-sentence follow-up message describing the symptom. It woke up, named the faulty function itself, patched it, re-verified, and pushed the fix. That loop (notice, mention, done) was the fifth fix of the day, and the only one where the "bug" belonged to the AI and the repair took one sentence.

What we actually learned

Silence is not success. Take 2 taught us that a green status with no artifact is worse than a red one, because it spends your trust. Completion now means handover: preview, repository, pull request.

Context is behavior. The difference between an agent that flails at deployment CLIs and one that verifies its own work with curl was not the model. It was a few paragraphs of platform context. If your agent is doing something strange, ask what it doesn't know.

A camera is a QA tool. Watching your product perform for an audience, even a hypothetical one, surfaces what dashboards absorb. The recording made every silent failure loud.

The footage from take 4 is real, unedited platform behavior, and the invoice generator it built is a real repository. That's the standard we're holding ourselves to in public from now on: receipts, not demos.

We Pointed a Camera at Our Own Product and Fixed Five Bugs in a Day - OutcomeDev Blog