Field note 09

The Last Ten Percent Is the Product

Agents can make the first working version arrive quickly. Shipping still begins where the demo ends.

By Codex Rules EditorialJune 20, 20266 minute read

AI coding tools have made the first visible version of a product startlingly fast. A screen appears. The button works. The database has rows in it. For a few minutes, it can feel as if the whole distance between an idea and a finished product has collapsed.

Then somebody signs in with the wrong account, uploads a strange file, loses their connection halfway through checkout, or asks how to delete their data.

That is where the product begins.

What is confirmed

A recent discussion in the Codex community asked a fair question: how are people building complete apps so quickly? The most useful answer was not a secret prompt. It was a vocabulary lesson. A demo, an MVP, a beta, and a production product are four different promises.

The invisible work between them includes validation, fixtures, accessibility, failure states, security review, deployment, monitoring, support, backups, migrations, permissions, and documentation. An agent can help with every item on that list. It cannot make the list disappear.

The gap is visible in the projects people share. In another community thread, a developer linked an App Store product called Quick Carnivore. That link is evidence of a shipped distribution artifact, but it does not tell us how its operations, support, or business are run. A separate builder reported making a Flutter app for drafting German administrative letters with OCR, explicit confirmation before AI analysis, PDF output, a Worker backend, and more than 300 tests. Those details are self-reported, but they show what “almost beta” looks like when the builder is thinking beyond a screenshot.

OpenAI's official Codex use cases tell a similar story from the tooling side. They include QA with Computer Use, browser games, deep codebase scans, deployment, reusable skills, and command-line tools. The interesting pattern is not that Codex can produce code. It is that the useful workflows include review and verification around the code.

Four honest labels

Use these labels plainly with yourself and with users:

Demo

The happy path works well enough to explain the idea. Data may be fake. Failure states may be absent. It is allowed to break.

MVP

A narrow group of real users can solve one real problem. The scope is intentionally small, but data and authentication need responsible handling.

Beta

The product is ready for broader use with known limitations. Feedback, observability, recovery, privacy, and support are now part of the system.

Production

The team has accepted an ongoing obligation. That means maintenance, incident response, security updates, backups, migrations, and clear ownership.

None of these labels is embarrassing. Confusing them is expensive.

My take

Agents change the cost of implementation more than they change the meaning of responsibility. That is still a huge change. It means a solo builder can afford to write better tests, explore more edge cases, and build internal tools that once felt too expensive.

The healthiest workflow is to spend some of the saved implementation time on proof. Ask the agent to list assumptions. Ask it to break the happy path. Test a clean account, a slow connection, a malformed import, a missing permission, a full database, and a failed deploy. Make backups restorable, not merely present.

Speed is useful when it buys more chances to learn. It becomes dangerous when it encourages us to rename a fast prototype as a finished product.

A rule worth copying

Every feature request needs a matching proof request: tests, visible validation, failure handling, or a recovery check.