The Cost of Saying Yes Has Changed: Why Fast MVPs Beat Endless Estimates
The economics of software development have inverted. GitHub's engineering team recently outlined a profound shift: the meeting where you decide whether to build a feature now costs more than generating the first working implementation with AI. That upends decades of process design built on the assumption that writing code was the expensive part.
For founders, this changes everything about how you validate ideas. The old playbook—estimate effort, debate scope, argue about edge cases, then maybe commit engineering time—optimized for a world where code was scarce. In 2025, code is abundant. Judgment about what to own is what's scarce.
The Old Calculus Versus the New Reality
Traditional feature development started with a question: "Should we build this?" That question triggered rounds of estimation, feasibility analysis, and stakeholder alignment. Teams spent hours—sometimes days—modeling complexity before a single line of code existed. The implicit assumption: once we commit, the code will be expensive to produce, so we'd better get the decision right upfront.
AI agents have collapsed that timeline. Today, you can ask an LLM to generate a working first draft of almost any well-scoped feature in minutes. The meeting now costs more than the prototype. GitHub's framework argues that this inversion means you should flip the process: generate the code first, then use the concrete artifact to inform whether you should keep it.
Abstract debates about "how hard would it be to..." become concrete code reviews. Instead of estimating difficulty, you're reading a diff. Instead of imagining edge cases, you're evaluating how the implementation handles them. Prototyping is no longer a decision bottleneck—it's a scoping tool.
The Hidden Cost That Hasn't Changed
But here's the discipline required: cheap to write does not mean cheap to own. The real expense in software has always been maintenance—understanding what code does six months later, fixing bugs that surface in production, onboarding new team members to a codebase. AI-generated code that ships without human review and refactoring for clarity is deferred cost, not savings.
GitHub's engineers are explicit about this. The framework isn't "ship everything agents write." It's "use agents to collapse discovery, then apply strict ownership standards before merging." Speed up the front end of the decision cycle, but gate production on the same question you always asked: can we confidently own this code over time?
For founders building an MVP, that distinction is existential. You want to move fast—faster than competitors, faster than your runway burns—but an MVP full of code you don't understand is a time bomb. The goal isn't to generate features quickly; it's to test hypotheses quickly with production-grade implementations you can iterate on.
Key Takeaways
- The meeting costs more than the prototype: AI agents generate working code faster than teams can debate whether to build it, so prototype first and use the artifact to drive decisions.
- Concrete beats abstract: Reading a real diff reveals effort and edge cases better than any estimation session.
- Ownership is the real gate: Code that's cheap to generate but unclear to maintain is technical debt, not velocity—review and refactor before merging.
- Speed and discipline: Founders can collapse decision cycles by generating implementations as scoping tools, but only if they apply strict standards to what ships.
The MVP Advantage
This framework is why the three-day MVP model works. When you can rapidly generate working implementations to test hypotheses, the question shifts from "can we afford to build this?" to "is this the right thing to own?" A full, working, sellable MVP lets you validate the market fit, the user workflow, and the technical approach in days—then decide what to keep based on real usage, not projected estimates.
The discipline required is having senior engineers who understand the difference between fast code and maintainable code. AI agents are extraordinary at generating the former. Experienced developers are irreplaceable for ensuring the latter. That's the guardrail: speed through generation, rigor through human review, production readiness through craftsmanship that knows what "owning it long-term" actually means.
The cost of saying yes to a feature has changed. The cost of owning one hasn't. Move faster by prototyping first—but only ship what you can confidently maintain.
Sources: https://github.blog/engineering/the-cost-of-saying-yes-has-changed/