Context

Petra Wille and Teresa Torres tackle a claim they hear on every call right now: "now that AI makes delivery free." They pull it apart from two angles, what actually gets cheaper when coding agents write code, and what stays expensive no matter how good those agents get. The conversation matters to PMs because the "delivery is free" narrative is usually the setup for a bigger claim, that only taste or only discovery still matters, and both hosts think that conclusion doesn't hold up.

The Big Idea

Building a single feature has gotten dramatically cheaper with AI, but building a real, production-quality product has not, and it never will be free.

Cheaper single features tempt teams to ship far more of them, which degrades the codebase, the product's maintainability, and its performance faster than the savings show up. The gap between a good AI-generated prototype and a trustworthy production product is the last 30%, and that 30% still takes months to years of unglamorous work.

Key Insights

Cheap features add up to an expensive product

Teresa walks through a simple thought experiment: a zero-to-one product ships with one feature, then adds five more features a week for three weeks straight because each individual feature is now nearly free to build. By feature seven, the data model looks like "a Frankenstein strategy": the same logic gets rewritten in a dozen-plus places, so any future change means editing code in that many spots, and speed and performance both degrade. The team walks away with 16 features and a codebase that's terrible to maintain, because "free to build" was never the same thing as "free to own."

Build to learn versus build to earn

• What: a distinction Teresa credits to the SVPG team: build to learn is writing throwaway code for an interactive prototype you put in front of people; build to earn is writing code a paying customer will actually rely on.
• Why it matters: delivery genuinely is close to free in the build-to-learn bucket, since the code gets discarded. It is not free in the build-to-earn bucket, where maintainability, security, reusability, and scalability still have to be engineered, and AI helps with that work without making it free.
• Example: a designer built an entirely new marketing design system (new logo, new design language, an interactive tool letting stakeholders explore its extremes) in a very short time with AI. It sped up an internal discussion, but it's squarely build-to-learn, not a shippable product.

Apps released is spiking; apps actually used is flat

Teresa cites a chart showing app-store releases climbing sharply while the number of apps people actually keep using stays stable. Cheaper delivery means more products get shipped, but it does not mean more of them earn real usage, since users are getting better at sensing which apps were "thoughtfully built and designed" versus assembled as AI app slop. A PM shipping a lot of AI-assisted features should treat rising release volume as a vanity signal, not evidence the product is winning.

Deterministic code is easier than AI-native features

Coding agents are genuinely strong at writing deterministic code, so if a team has done its discovery and knows exactly what to build, delivery for that kind of feature really has gotten a lot cheaper. But most teams in 2026 are building AI products, not just AI-assisted deterministic ones, and AI products don't inherit that same discount. Teresa says she's spent months building AI features and it still takes real error analysis, building evals that measure the right thing, and iterating on prompts and orchestration, work current AI tools are "not very good" at automating for you.

The last 30% is where the real cost lives

Across the products Teresa has seen doing well, the pattern is the same: the team has deep domain expertise in the problem, and they spend enormous effort training the AI to apply that expertise well. The first 60 to 70% of a product comes together fast and looks like a solid prototype. Closing the remaining 30%, the part that makes a product trustworthy and genuinely useful rather than just demo-ready, takes months to years, and customers increasingly expect that last stretch (Teresa puts the real bar closer to 95%) before they'll rely on the product.

Debugging AI products is a hard data science problem, not a checklist

Teresa describes trying to improve her own AI-generated opportunity solution trees: she can visually spot quality issues (a poorly framed opportunity, one that duplicates another), but turning that into a fix means running error analysis, then building an eval, often an LLM-as-judge, to detect the issue at scale. The complication is that a single part of the tree can have four competing errors at once, so she can't isolate and measure one without accounting for the others. Even a frontier model she tested did shallow analysis and mixed up the failure modes, so the debugging work still falls to a human running real experiments over days.

Mental Models & Frameworks

Build to learn vs. build to earn

A two-bucket test for whether "AI made this free" actually applies to what you're building.

• Build to learn: code written to create a prototype you'll put in front of people and then throw away. Delivery here is genuinely close to free with AI.
• Build to earn: code meant for a paying customer to rely on. It still needs maintainability, security, reusable design, and scalability, the same engineering principles that always applied, and AI speeds up writing it without making any of that free.

Use it whenever someone claims a build got cheap: ask which bucket the artifact actually falls into before agreeing "delivery is free" applies.

The river and stepping stones for AI maturity

Petra's image for where AI tooling stands right now: picture a river in flood, and as the water recedes, stepping stones become visible, the parts of the AI stack (like context engineering, or evals as a discipline) that are starting to feel stable enough to build on. Most of the river is still high water, meaning most of the surrounding practice is still being figured out in real time, the way "command line has been invented and now everybody is figuring out how to use the internet." Use it to calibrate how much to standardize versus keep experimental in your own AI workflow: build durable process only on the stones that have actually surfaced.

Trade-offs & Nuance

Delivery is free enough, but only for discovery

Both hosts agree the "delivery is free" claim is basically true within the build-to-learn, discovery bucket: a working prototype in front of 10 to 15 people to spark a richer conversation is genuinely cheap now, and that's valuable on its own terms. The trade-off is that this cheapness doesn't transfer to production-quality, scalable, maintainable code, and Teresa argues it doesn't even fully hold yet for deterministic production code, let alone AI-native features. Treating a cheap prototype's speed as a preview of production speed is the mistake to avoid.

Discovery is not the only thing that matters

Teresa names the two claims people usually attach to "delivery is free": either "taste is all that matters" or "discovery is all that matters." She's on record that taste alone doesn't hold up, and she says she'd like to tell listeners discovery is now the only lever left, since that would flatter her own opportunity-solution-tree product, but she doesn't believe it's true. Delivery, discovery, and taste all keep mattering; none of them has gone to zero, even as their relative weight shifts.

Practical Application

Sort every AI-sped-up build into its real bucket

Before treating a fast AI build as evidence delivery is cheap, ask whether it's build-to-learn (a throwaway prototype meant to inform a decision) or build-to-earn (something a paying customer will depend on). Only trust the "it's basically free" instinct for the first bucket.

Watch feature count as a maintainability warning sign

If a team is shipping features quickly because "AI makes it free," track how fast the count is climbing (Teresa's example goes from 1 to 16 features in three weeks) against how much a skilled engineer is actually reviewing the resulting architecture. Rapid feature growth with thin engineering oversight is the leading indicator of the Frankenstein data model failure mode described above.

Budget real time for the last 30%

When scoping an AI feature or product, plan the timeline around the idea that the first 60 to 70% (a working prototype) is fast, and the remaining 30%, the part that makes it trustworthy and production-ready, is where months to years of the real work happens. Don't let a fast, good-looking prototype set stakeholder expectations for the ship date.

Treat AI-assisted error analysis as still manual

If you're building an AI feature and trying to measure its quality, expect to do real error analysis and hand-build evals yourself rather than delegating that work to an AI assistant. Even a frontier model gave shallow, mixed-up failure analysis when Teresa tried using it to help debug her own product's quality issues.

Bottom Line

AI has made building a single feature significantly cheaper, but it has not made delivery free, and building a real, trustworthy product still requires the same engineering rigor, plus new AI-specific work like error analysis and evals, that the last 30% of any product has always demanded.