The Loop Without a Brake

The Method That Got Too Slow

The software development lifecycle was an answer to a real problem. Enterprise systems were expensive to change, painful to deploy, and unforgiving of mistakes discovered late. Waterfall, then agile, then dual-track agile imposed discipline on that reality: plan, design, build, test, deploy, maintain, with feedback loops bolted on to catch errors before they compounded. The entire value of the model came from one assumption, that writing the code was the expensive, slow, irreversible step worth protecting with process.

Product management built its own layer on top of that assumption. Marty Cagan and Jeff Patton formalized dual-track agile around 2012 to run discovery and delivery in parallel, so the team could validate what to build while engineering built the last validated thing (Productboard, n.d.). Teresa Torres added continuous discovery and the opportunity-solution tree (Product School, 2026). The premise underneath all of it was scarcity of build capacity. You did discovery precisely because building the wrong thing was costly, so you spent cheap research hours to avoid expensive engineering ones.

That premise is now false, and the failure mode it created was visible even before AI arrived. Teams that took discovery seriously discovered they could not stop discovering. One account from the field describes teams that wrote their first line of code months into a project, paralyzed by the demand for evidence before any decision, idling delivery while they processed data they had no efficient way to act on (Teixeira, n.d.). The careful method, practiced literally, produced its own kind of waste: validation theater that delayed learning instead of accelerating it.

The deeper problem is that discovery was always a proxy. You did not actually want interviews and prototypes and opportunity trees. You wanted to know whether the real thing would work, and you accepted proxies because building the real thing was too expensive to use as the test. When the real thing becomes cheap to build, the proxy loses its reason to exist. A clickable prototype that simulates behavior was a clever substitute for a working product in a world where working products took a quarter to make. It is a strange thing to insist on when the working product takes an afternoon.

So the careful method is disqualified, not because care is wrong, but because most of its machinery was designed to ration a resource that is no longer scarce. The discipline optimized for a constraint that has moved.

The Method That Cannot Be Trusted

The replacement arrived fast and named itself badly. Andrej Karpathy coined “vibe coding” in February 2025 to describe building by describing intent in natural language, accepting what the model produces, and prompting away the problems rather than reading the code. Karpathy framed it as fully giving in to the vibes, a deliberate departure from the disciplined reading and reasoning that traditional programming required (Cloud Security Alliance, 2026b). Collins named it Word of the Year (Wright, 2026). The promise for product managers was intoxicating and specific: the prototype in your Figma file could be live by Friday, and you no longer needed an engineering queue to find out if an idea had legs (Aggarwal, 2026).

The promise is real. The iteration cycle genuinely tightened, and when the cost of trying something drops, assumptions surface earlier and trade-offs become concrete instead of theoretical (Agile Insider, 2026). Carnegie Mellon now requires vibe-coded prototypes from its product students rather than wireframes, on the reasoning that the workplace will demand it (Ott, 2026). Naval Ravikant went further and declared that vibe coding simply is the new product management, that taste and opinion now flow directly into product without engineers in the middle (Ravikant, 2026). For a category of work, validation and prototyping and internal tools, this is a clean and large win.

Then the bill arrived, and it is documented in numbers that are hard to wave away. Roughly 84% of developers adopted AI coding tools while trust in their accuracy fell from 43% to 29% over eighteen months, and independent research converged on accelerating quality degradation, security vulnerability growth, and maintenance burden (Pixelmojo, 2026). Veracode’s testing across more than 100 models found that 45% of AI-generated samples failed security tests, with 86% failing to defend against cross-site scripting and 88% vulnerable to log injection, and the pass rate stayed flat from 2025 into early 2026 even as coding benchmarks improved (Cloud Security Alliance, 2026a). These are not exotic flaws. They are the OWASP Top 10, the failures any competent review would catch, and vibe coding is the practice of skipping that review (Kyros, 2026).

The production evidence is worse than the lab evidence. One firm scanned over 1,400 vibe-coded production applications and found 65% had security issues and 58% contained at least one critical vulnerability, including hundreds of exposed secrets and instances of exposed personal data such as bank account information (Cloud Security Alliance, 2026b). A separate sample of fifteen production applications built with major AI tools found that every single one lacked CSRF protection and shipped without security headers, and every tool introduced server-side request forgery vulnerabilities (Cloud Security Alliance, 2026b). Georgia Tech’s tracking project watched CVEs formally attributable to AI-generated code climb from six in January 2026 to thirty-five in March, and the researchers believe the true count runs five to ten times higher because most tools leave no trace in commit history (Cloud Security Alliance, 2026a).

The quality erosion compounds in a way that ordinary technical debt does not. GitClear’s analysis of 211 million lines found refactoring dropped from a quarter of changes to a tenth, copied code rose, and code churn climbed, with 2024 the first year copy-paste exceeded moved lines (Rekhi, 2026). The reason this matters is structural. A security backlog used to be a static list you might clear before the next audit. Now those unresolved patterns shape the code the model writes tomorrow, because the model learns the house style from the house, and the house style is now insecure by default (Taft, 2026). The debt is not sitting still. It is teaching.

There is a quieter cost that will outlast the breaches. Reading unfamiliar code with comprehension was the apprenticeship that produced senior engineers, and vibe coding inverts it: you generate and accept rather than read and reason (SolidAITech, 2026). The predictable result is a cohort that produces working code quickly and cannot debug complex failures, because debugging requires the comprehension that generation skips. More than half of engineering leaders plan to hire fewer juniors, which means the people who would eventually clean up this debt are the people not being trained to exist (Pixelmojo, 2026). So the fast method is disqualified too, not because speed is wrong, but because it externalizes its costs onto a future it cannot see and a workforce it is not building.

The two disqualifications are worth reading side by side, because they fail in mirror-image ways.

Why This Is Not a Tooling Problem

The comfortable response is that the models will get better and the security numbers will improve. The evidence says otherwise on the timeline that matters. Veracode’s pass rate stayed flat while functional capability rose, which tells you the optimization pressure is pointed at making code that works, not code that is safe, and those are different targets (Cloud Security Alliance, 2026a). Better models raise the floor of what works without raising the floor of what is secure, because nothing in the training signal rewards the second thing the way it rewards the first.

Karpathy himself drew the line a year after coining the term. At Sequoia’s AI Ascent in April 2026 he declared the vibe era effectively over and named what comes after it: agentic engineering, the disciplined practice of orchestrating fallible, stochastic agents against a spec while a human stays accountable for security, architecture, and the quality bar (AI Builder Club, 2026). His framing is precise and worth keeping. Vibe coding raises the floor of what any individual can build; agentic engineering preserves the ceiling of professional software, and you are still not allowed to introduce vulnerabilities just because an AI wrote the code fast (AI Builder Club, 2026). The man who named the fast method spent his next public act explaining why it is insufficient on its own.

This is the tell. The frontier is not resolving the tension by making vibe coding safe. It is resolving it by wrapping vibe coding in something older: specifications, review, evals, accountability, the disciplines that the careful method spent two decades building and that the fast method threw out. Boris Cherny, who leads Anthropic’s Claude Code, reports writing none of his production code by hand since late 2025, and describes engineers reviewing, directing, and governing agents rather than typing (Agentic MSP, 2026). That is not the death of engineering discipline. It is engineering discipline relocated to a higher altitude, from writing lines to governing the thing that writes them.

Which means the real lesson of the last decade was not the specific practices. Discovery tracks and sprint ceremonies and validated backlogs were implementations, and implementations are disposable when their constraint moves. The durable thing underneath was a single principle, and it is the argument in small.

Throwing out the principle along with the methods is the actual mistake, and it is the mistake both poles make in opposite directions. The careful pole kept the rituals and lost the speed. The fast pole kept the speed and lost the governance.

Does ADAM Actually Solve This?

I have been building a framework that claims to resolve exactly this bind, so the honest thing is to test it against the same standard that disqualified the other two. I used to call it a lifecycle, and I have stopped, because the word inherits the linear DNA that the first half of this essay just disqualified. The thing I am describing does not pass through stages toward a finished state. It runs, continuously, with a control function holding it. So the name is now the Adaptive Development and Assurance Machine, ADAM, the governed machine for building AI-native software and agents.

The two words flanking Development carry the argument. Adaptive is the part the fast method had right, a loop that learns and moves at machine speed. Assurance is the part it discarded, control that can be trusted and shown to hold under load. The wager in the name is that these do not have to be traded against each other, that one machine can run fast and stay governed in the same pass. The five forward moves still hold, Signal, Shape, Build, Prove, and Govern, arranged as a cycle rather than a line, with every pass ending in Govern and beginning again in Signal.

ADAM is a discipline for building, and the same discipline runs at every scale. A single pass can govern one feature, a wider pass can govern a product, and the widest pass governs an entire venture thesis, which is the same loop run with higher stakes and more of the work handed to the systems inside it. This is the layering that matters, and it is worth stating plainly. The machine is how you build, while venture and product creation is the reason the building has to be governed at all. Nobody installs a brake for a throwaway script. The brake earns its place when something real is riding on the loop, and it matters more, not less, as the stakes climb.

The spine of the framework is the part that matters here, and it is the part that distinguishes it from a renamed agile. The Governor is a two-speed control function. The first speed is automated, running routine brakes at machine pace because the loop runs at machine pace: drift halts, evaluation gates, anomaly rollback, action ceilings, contamination filters. The second speed is human, a single emergency override held where a wrong call is catastrophic, which the system cannot countermand. The governing claim of the whole framework is blunt. A learning loop that feeds production outcomes back into design is the most powerful configuration in software and the most dangerous one when ungoverned, so the loop must be braked, not merely built.

Here is the case for it, stated as strongly as I can make it. The framework gets the diagnosis exactly right, which most frameworks do not. It identifies that the problem is not speed and not care but the absence of a brake on a loop that now runs faster than human review, and it puts the brake at the center instead of bolting governance on at the end the way classic SDLC did with its testing phase. It matches Karpathy’s agentic engineering and Cherny’s relocated discipline, but it goes one step further by making the control architecture explicit and identity-bound rather than leaving it as a hiring profile and a set of good habits. A maturity model ties loop automation to brake trust, so a team can only earn more autonomy as far as its brakes have proven they can be relied on. That is the correct shape for the problem the evidence describes.

Now the case against it, which I owe the reader and myself. ADAM is in active practice in venture building at 451 Ventures, and the early results are promising enough that I am committing to it rather than hedging, which is a reason for my conviction and not a substitute for evidence. It is not yet evidence, and I will not dress it up as evidence. Every disqualification in this essay rested on numbers: 45% security failure rates, 1,400 scanned applications, CVE counts climbing month over month. ADAM has no equivalent body of evidence yet, only a working practice and a founder’s read on it, which is the weakest kind of proof and the easiest to fool yourself with. The honest status is that it is a well-formed hypothesis being tested in the open, not a proven solution. We expect to publish numbers as the practice matures, and the framework should be judged then, on those, against the same independent standard that condemned the alternatives.

There are three specific places it could fail, and naming them is more useful than defending them.

So my answer is qualified rather than triumphant. ADAM is the right kind of answer, because the bind is genuinely a governance problem and not a process problem, and a framework that puts an explicit, identity-bound brake on a self-modifying loop is addressing the actual disease rather than its symptoms. Whether it is the right answer is an empirical question that the framework has not yet earned the right to claim it has settled. The thing that would make it true is the thing it does not yet have, which is brake health demonstrated under load, repeatedly, with the same kind of independent measurement that condemned the alternatives.

What This Means for the Person Doing the Job

The product manager caught in this bind should stop looking for the correct method and start looking for the correct brake. The methods are downstream of the constraint, and the constraint has moved, so any method copied from the last decade or borrowed from the loudest voice this quarter will be solving the wrong problem with confidence. The durable questions are smaller and harder.

A team that can answer those three questions has governance. A team that cannot has either a slow ritual or a fast accident, regardless of which framework’s vocabulary it uses to describe itself.

The work that survives this transition is not prototyping, which the machine now does, and not validation theater, which the machine makes pointless. It is judgment about what is allowed to act on unverified belief and what is not, and the design of the brakes that enforce that line. That work is appreciating in value precisely as the typing depreciates to zero. The last decade was not thrown in the trash. The rituals were. The principle they were clumsily trying to express, that production is dangerous and learning must be governed, is the only thing worth keeping, and it is now the entire job.

A note on sources

The security and quality figures in the other two methods come from independent research bodies, principally Veracode’s model testing, the Georgia Tech Vibe Security Radar project, GitClear’s code-base analysis, and scans by Escape.tech and Tenzai, several of which I accessed through the Cloud Security Alliance research notes that compiled them. Where a primary research organization is named in the text, the citation points to the source where I read the figure. The trade and practitioner sources (Karpathy’s Sequoia remarks, the Cherny interview, the practitioner accounts of discovery breaking down) are weaker as evidence than the empirical studies and are cited as testimony rather than proof. Readers who want to verify the strongest claims should go to the originating studies named in the prose.

References

Aggarwal, M. (2026, February 17). Why every product manager needs to learn to vibe code in 2026. Medium. <https://medium.com/@mohit15856/why-every-product-manager-needs-to-learn-to-vibe-code-in-2026-049e723ad28a>

Agentic MSP. (2026, May 16). From vibe coding to agentic engineering: What the shift means for MSPs. Substack.

Agile Insider. (2026, February 26). Vibe coding as a product manager. Medium. <https://medium.com/agileinsider/vibe-coding-as-a-product-manager-d14e597b26a6>

AI Builder Club. (2026). Agentic engineering: Karpathy’s new framework for AI-assisted development. <https://www.aibuilderclub.com/blog/karpathy-agentic-engineering>

Cloud Security Alliance. (2026a, April 4). Vibe coding’s security debt: The AI-generated CVE surge (CSA research note). <https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/>

Cloud Security Alliance. (2026b, March 31). Vibe coding security crisis: Credential sprawl and SDLC debt (CSA research note). <https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-security-vibe-coding-202/>

Kyros. (2026, March 26). The vibe coding crisis: How AI-generated technical debt is costing companies millions. <https://usekyros.ai/blog/vibe-coding-crisis-ai-technical-debt>

Ott, A. C. (2026, January 27). How AI and vibe coding transform product management. Carnegie Mellon University, Integrated Innovation Institute. <https://www.cmu.edu/iii/about/news/2026/how-ai-and-vibe-coding-transform-product-management.html>

Pixelmojo. (2026, March 30). Vibe coding hit 84% adoption. 45% has vulnerabilities. <https://www.pixelmojo.io/blogs/vibe-coding-technical-debt-crisis-2026-2027>

Product School. (2026, January 22). The definitive guide to product discovery and frameworks. <https://productschool.com/blog/product-fundamentals/what-is-product-discovery>

Productboard. (n.d.). What is dual-track agile? <https://www.productboard.com/glossary/dual-track-agile/>

Ravikant, N. [@naval]. (2026). Vibe coding is the new product management [Post]. X.

Rekhi. (2026, February 23). Why vibe coding is going to create the worst software crisis in history. Medium. <https://medium.com/@Reiki32/why-vibe-coding-is-going-to-create-the-worst-software-crisis-in-history-1a0b666a9b0c>

SolidAITech. (2026, May). Vibe coding in 2026: The hidden risks nobody covers. <https://www.solidaitech.com/2026/05/vibe-coding-hidden-risks.html>

Taft, D. K. (2026, January 20). Vibe coding could cause catastrophic ‘explosions’ in 2026. The New Stack. <https://thenewstack.io/vibe-coding-could-cause-catastrophic-explosions-in-2026/>

Teixeira, P. (n.d.). When dual-track and product discovery go wrong. LinkedIn. <https://www.linkedin.com/pulse/when-dual-track-agile-product-discovery-go-wrong-pedro-teixeira>

Wright, A. (2026, April 6). Vibe coding as a product manager: Risks and opportunities. <https://alaniswright.com/blog/vibe-coding-as-a-product-manager-risks-and-opportunities/>