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.
What "free to trash" really buys is bigger than sunk cost. When a prototype costs nothing to discard, you no longer have to run an idea through the prioritization-and-deprecation gauntlet that used to kill anything playful or unproven before it could exist. The scarce permission was never the code — it was organizational license to try. Two xAI designers run this in practice: a shower-thought idea becomes a working prototype through a 'Devbot' or 'experiments' bot, no spec and no review queue. The counter they flag themselves: a throwaway that ships still accrues maintenance and tech debt.
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.
Nathaniel Whittemore pushes the same logic past engineers to every knowledge worker: "we wouldn't have taken the time to build disposable software before." Building something useful for one goal, for one period, then throwing it away was never worth the effort — now the cost equation flips, and disposable personal software becomes a whole tier of single-purpose tools you'd never have bothered to write. It's the PR-as-probe aimed at your own recurring work instead of the codebase.
Durable convictions, disposable features
Claire Vo's Lenny & Friends Summit 2026 talk sharpens the trash-can method into a GTM contract. Keep 1–2 year beliefs plus the evidence that would prove or stop you — but treat features as probes, durable experiments, or promises, and be honest about which.
You need to have durable convictions but disposable features.
Claire Vo
"Code is abundant. Customer trust is not." Her near-oneshot Product Graph (ChatPRD's semantic product graph) stayed feature-flagged off because it was competitive but not differentiated enough for her conviction — shipping it would have burned trust for a probe. Disposable without a conviction is the churn trap: ship, see noise, abandon, never learn.
Where disposable sits on the durability ladder
"Disposable" isn't a verdict on all software — it's the bottom of a ladder. Whittemore's map runs prototype → personal → production → product, and the durability class is set by who depends on the thing and what its failure costs. The prototype and personal tiers are the disposable ones: optimize for speed, keep them alive only as long as they're useful. Production and product are not — a market of strangers needs the security, access, and support that a throwaway never earns.
The practical read: match the rigor to the tier. Most "it's not secure enough" objections are really the product tier applied to a prototype job. Over-engineer a throwaway and you've spent away the collapse in cost that made building it worth doing at all.
Build to learn is disposable by design
Marty Cagan (Lenny Summit 2026) draws the same cheap-code line from the product-model seat: there are two kinds of building — building to learn and building to earn. Discovery prototypes exist to falsify; delivery ships for outcomes. AI makes build-to-learn dramatically cheaper.
Pairs with Claire Vo's durable convictions / disposable features: learning without a conviction is churn; learning as discovery is the job.
Throwaway personal software gets a host and live data
Kath Korevec, who leads product for ChatGPT Sites at OpenAI, builds a site for a single business trip: “I'll build a site for that week and then I'll throw it away at the end of the week.” Others build custom calendar views and transit guides for a city they're visiting.
The change at DevDay 2026 is plugins in Sites. Each visitor approves their own connectors and sees only their own data on the same URL. At the June launch, OpenAI's own guide said Sites could not connect directly to live data. So disposable no longer means static: a tool you'll delete on Friday can read your real Slack, Notion or calendar while it lives.
Treat it as a launch-day demo from the product's own lead. The pattern is real; the breadth of what works in practice is still to be tested.
