TL;DR
The short version
When an agent can write a feature in minutes, code stops being an asset to protect and becomes a probe you throw away. The pull request — fully reviewed, production-quality — is the spec, and you merge it or trash it on the spot.
Gusto's CTO Eddie Kim rebuilt a tier-one product with four engineers and one designer in 10 weeks by deleting the whole process — no docs, no Figma, no Jira — and treating every artifact upstream of the PR as dead weight. The method only works because the code is genuinely cheap now. Told on How I AI.
Source: Eddie Kim (CTO & co-founder, Gusto) with Claire Vo on How I AI. Both speakers are evangelists for this way of working; the claim is scoped to zero-to-one builds.
The cost of code went to near-zero — so the method changes
The premise is an economic one: writing a feature now costs minutes, not days. Once that's true, the artifact you build around stops being the document that describes the code and becomes the code itself. Features ship as fully reviewable production pull requests — not drafts — discussed live, then merged or trashed.
The PR is the unit of work and the spec at once. You reason about the product by reading real, runnable code, not a Figma or a Jira ticket describing what the code might do. That only holds when meeting the quality bar is cheap enough to do repeatedly — which is the whole claim.
The trash-can method — and why it isn't slop
Eddie Kim deleted his own working prototype on day one to restart in a different stack. In hindsight, "absolutely the best decision." The instinct to protect code you've written is sunk-cost reasoning — and the cost was never high.
You can actually trash all the code, start a /v2 branch, and rebuild it from scratch, and it's totally reasonable to do because the cost of the code is so low.
Claire Vo
Disposable is not the same as careless. The trashed PR is real, working, review-ready code: "You actually spent time to make sure this code works… and then you just close it sometimes." The point isn't lowering the bar — it's that clearing the bar is now cheap enough to do over and over and throw the result away.
Ship the fake, then breathe life into it
The sharpest move on the team: the designer pushed a canned, pure-front-end experience straight to production behind a feature flag. Engineers then swapped real data models and the agent loop in underneath — without changing the UI.
The disposable front-end was the spec for the real system. A working artifact replaced a written one: instead of a document arguing for an interaction, you ship the interaction (faked) and build the truth in behind it. Prototyping collapses into production.
Process by subtraction — and you have to forbid the old way
"We had no meetings. We had no Figmas. We had no Jira board… no stand-ups, no retros. We had nothing." The only structural artifact was a single whiteboard photo; the only ritual a 24/7 "perma-zoom" for live PR review, with median review around nine minutes. When the PR carries the spec, every document that used to align people upstream is pure latency.
Permission has to be explicit. As a co-founder, Eddie could break process implicitly. For other teams, he wouldn't just allow disposable code — he'd forbid docs, Figma, and specs, so the team feels licensed to actually work differently. Without the ban, people default back to protecting artifacts.
The honest caveat: both speakers are evangelists, and the "kill docs" claim is scoped to zero-to-one work. Specs as alignment and memory still matter at large-org interfaces — and once a PR is merged or trashed, a whiteboard photo is not a durable record of why.
The disposability scales past code — design for ephemerality
The same cheap-artifact logic climbs a level. In the agentic enterprise, the scaffolding around the code — the harness, the interaction patterns, customer expectations, even policy — is itself changing every few months. So the move isn't only disposable pull requests; it's disposable systems. Build the thing this quarter expecting to replace it next quarter, and optimize for cheap replacement over durability.
Nathaniel Whittemore calls it designing for ephemerality: assume planned obsolescence rather than engineering for permanence. It's the org-scale version of the trash-can method — not only individual PRs are throwaway, the surrounding system is too. The same tension carries up with it: throwaway systems still need somewhere durable for product memory to live, or the knowledge goes out with the code.
The new bar: not "can you build it" but "can you maintain it"
There's a flip side to code being cheap. When anyone can one-shot a working app, having built it signals nothing. Writer Craig Mod's read: the marker of substance moved from "can you build it at all" to "are you maintaining it?" — sustained upkeep over time is the new proof of quality.
The metric of quality or substantiality has gone from 'can you build it at all' to 'are you maintaining it?'
Craig Mod
The same cheap-code economics unlock N-of-1 software — tools built for exactly one user. Mod rebuilt Quicken for himself, cloned his newsletter vendor (dropping a reported ~$67k/yr to ~$150/yr), and built his own ephemeral social network. The rule that keeps it from becoming wheel-spinning: the tool has to feed the core purpose, not become it. Disposable code is the right method for throwaway probes; the things that earn a place in your daily loop are the ones you keep alive.
