Prompt to Deployed Product in One Evening: What Held Up

The claim worth testing is not "AI can write code". It is that the gap between an idea and a deployed, publicly usable thing has collapsed. So: one evening, a hard stop at four hours, one real deployed product, and a written record of every shortcut taken.

The scope, written before any code#

The single most useful thing in this experiment happened before the timer started: writing down what was in and, more importantly, what was out.

In
  - Paste a JSON payload, get a formatted, collapsible tree view
  - Detect and pretty-print common date and timestamp formats inline
  - Copy any subtree as JSON or as a TypeScript interface
  - Share button that puts the payload in the URL hash (never on a server)
  - Works offline after first load
 
Out
  - Accounts, saving, history
  - Files larger than 2 MB
  - Anything that sends the payload anywhere
  - Mobile-first polish (usable on mobile is enough)

"Out" is the part that makes a four-hour build possible. Every time the agent proposed something outside that list — and it did, repeatedly, helpfully — the answer was already written down.

How the four hours went#

Shortcuts that were fine#

No tests. For a client-side tool with no data persistence and no auth, where the whole product is visible on screen, manual testing of the four core paths was proportionate.

No error monitoring. Nothing to monitor. There is no server.

Hardcoded design tokens. A handful of CSS variables instead of a design system. For a single-screen tool this is the right amount of infrastructure.

Capping input size instead of virtualising the tree. The honest fix would be windowed rendering. The four-hour fix was a limit and a clear message. A year later, that would still be the right call for a tool this size.

Shortcuts that were not fine#

Skipping keyboard navigation until the last 40 minutes. A tree view that cannot be operated with arrow keys is broken, not unpolished. Getting to it late meant it nearly did not happen — and if it had shipped without, the fix would have required rethinking the component's focus model rather than adding to it.

Accepting the first type-generation implementation. It looked right on the test payload and was wrong on arrays containing objects of different shapes. It took a deliberate second look to catch, and if it had shipped it would have produced confidently incorrect types — the worst kind of bug in a developer tool.

Conclusion#

One evening to a deployed, genuinely usable tool: yes, that held up. But the parts that made it work were not AI-specific.

Writing the scope — especially the "out" list — did more for the timeline than the code generation did. Deploying in the first twenty-five minutes removed the classic last-hour panic. And the two things that nearly went wrong went wrong because they were deferred, not because they were generated.

The realistic version of the claim: AI collapses implementation time, and leaves judgement time untouched. A four-hour build is possible because you spend a much larger share of those four hours deciding rather than typing. If you do not have the judgement to spend, the speed does not help.