Different emails. That is the entire bug, and it belongs to the person who coined the term this article is about: Andrej Karpathy built a small app called MenuGen where users signed in with a Google account and bought credits through Stripe, and the agent writing the code decided to match the two systems by email address. Both have an email field. The agent was not confused and it was not hallucinating, it produced working code that did exactly what the stated intent implied, and a paying customer could quietly never receive the credits they had just paid for.
The diagnosis, published after the Sequoia AI Ascent event on 30 April 2026, runs one line: "Why would you use email addresses to cross-correlate funds? You need a persistent user ID." Obvious in hindsight. Nobody had written it down anywhere, and that omission is the part worth sitting with, because 2026 has spent most of its argumentative energy on the format of the document that would have contained that sentence rather than on who was supposed to know it in the first place.
Why is the developer world suddenly calling vibe coding over?
Because the person who named it moved on, and plenty of people read the move as an obituary. It was not one. In February 2026, roughly a year after coining the original term, Karpathy proposed a successor label for what professionals were already doing with coding agents: agentic engineering. The trade press compressed that into "vibe coding is passé" inside a week, which makes a tidier headline than the thing that actually happened, and tidier headlines are how a useful distinction gets flattened into a verdict.
The distinction survives intact in the original writing. Vibe coding, per that April 2026 summary, "is about raising the floor for everyone in terms of what they can do in software", while agentic engineering "is about preserving the quality bar of professional software." Two different jobs. Nothing got buried: one activity was given a floor and the other was given a ceiling, and the professional version arrived carrying a short list of practices that the tooling market recognised instantly as a product category, starting with the instruction to write a detailed spec before you prompt.
So specs got tooling. Microsoft's developer blog published its spec-first framing of AI-native engineering on 10 June 2026, and the post is unusually candid about the failure it exists to prevent: "Teams often ship software that works but still misses the original intent." GitHub Spec Kit, OpenSpec and Kiro all ship variations of one lifecycle. A conceptual paper submitted on 31 August 2026 pushes the claim furthest, arguing that spec-driven development "reconstitutes, in specification-centric form, the contracts that vibe coding dissolves: accountability, verifiability, and transferability." Strong claim. Also, by the authors' own account, one built "predominantly on gray literature" because "peer-reviewed evidence and a shared academic-industrial vocabulary are not yet established", which is an honest admission that the discipline is currently ahead of its evidence.
46.41%
of the code fixes proposed by four named coding agents, Copilot, Devin, Cursor and Claude, were rejected rather than merged. A qualitative reading of 306 of those rejected pull requests produced 14 distinct reasons, and the largest category was an implementation that was incorrect, incomplete, or took the wrong approach. This measures fix-type pull requests specifically, not all AI-generated code.
Source: Abujadallah, Arabat and Sayagh, Understanding the Rejection of Fixes Generated by Agentic Pull Requests: Insights from the AIDev Dataset, published in the Proceedings of the 23rd International Conference on Mining Software Repositories (MSR 2026), preprint submitted 11 June 2026. Mined from agent-authored pull requests in public GitHub repositories; qualitative sample of 306 non-merged pull requests.
The paper's own recommendation reads like a spec advocate wrote it: hint at the approach to take, name the constraints to avoid, tell the agent how to validate its work. All correct. Every word of it presupposes that somebody in the building already knows which approach is right and which constraint is real, which is a far larger assumption than that sentence makes it sound.
What can a spec gate actually verify?
Four things, and every one of them is a property of the document rather than of the world: completeness, internal consistency, testable acceptance criteria, and a signature. Useful things. We argued back in June that moving a requirement out of a loose prompt into a structured spec at least puts it somewhere a named human can be asked to look at it, and that argument still holds. What a gate cannot do is step outside the document and check whether the claim inside it was ever true, and the most pro-spec text of 2026 concedes exactly that limit in a single sentence: "AI can accelerate those steps, but it cannot correct ambiguity that was never resolved."
Read that twice. Microsoft is not hedging there, it is drawing the honest boundary of its own product category, and the boundary is the whole subject of this piece: a specification is a transport mechanism for decisions somebody already made upstream, so if the decision was wrong when it was made, the spec carries it faithfully, numbered, traceable, testable and wrong. The post's summary line is "Spec quality = output quality." True. It leaves open the question of what sets spec quality, and the answer is not the template.
Take MenuGen again, because it is the cleanest available proof and it costs nobody's reputation to use. A rigorous spec for that app would have produced a section headed Credit Assignment, with acceptance criteria under it and edge cases enumerated beneath those, and every one of those criteria would have been perfectly testable. Would it have said "match on a persistent user ID, never on email"? Only if somebody had already understood that Stripe identity and Google identity are two separate identity systems that happen to share a string format. That is a finding. It is not a documentation format, and no amount of Markdown discipline generates it on its own.
What does the debate over human spec gates keep missing?
The gate itself. Both camps are arguing about how much document to write, authored when and signed by whom, which keeps the whole dispute pointed at the instrument rather than at what the instrument is aimed at. The argument is real, mind you, and both sides are serious about it. François Zaninotto at Marmelab called spec-driven development "The Waterfall Strikes Back" in November 2025, and it landed hard on Hacker News because working engineers recognised the complaint: detailed up-front specs assume a determinism software development has never had, and maintaining them spends reading time that used to be thinking time. The other camp answers that agents turned loose without a written contract produce exactly the review overload everyone has complained about since 2025. Both have a point.
One camp wants the human spec gate kept and hardened, the other wants it thinned or removed entirely, and neither position requires anybody to look at what is actually written on the page. Neither reads it. Birgitta Böckeler at Thoughtworks caught the drift early, writing in October 2025 that the term "isn't very well defined yet, and it's already semantically diffused", with people using "spec" as a synonym for "detailed prompt." A gate that checks a detailed prompt against nothing is a formatting review with a ceremony attached.
The skipped question sits upstream of both positions. It is embarrassingly simple. Where did the content inside the document come from? A spec gate can confirm that a document is complete, internally consistent, testable and signed, and it can do all four in an afternoon. It cannot confirm that the requirement inside it was ever checked against the person who would have said no. Both AI-era failure modes now have public paper trails, and at the top they look identical: something plausible was produced, nobody can point at the moment it was validated, and it shipped anyway.
From the field
The United States Government Accountability Office went looking for this pattern in public procurement and found it sitting in the open. Its report on artificial intelligence acquisitions, published 13 April 2026, reviewed 13 acquisitions across four federal agencies: the Department of Defense, the Department of Homeland Security, the General Services Administration and the Department of Veterans Affairs. One sentence in it describes the whole disease: "industry sometimes introduces capabilities, some of which are commercial, to agencies to meet their needs in the absence of specific AI requirements." Then the example. The General Services Administration bought facility and equipment maintenance tracking software that arrived with a customer-service chatbot bundled in, and officials told the GAO plainly that "the vendor offered the chatbot as an added capability and not in response to a defined requirement." Nobody wrote a bad spec there. Nobody wrote one at all, and the capability shipped anyway, which is the same failure spec-driven development exists to prevent, arriving from the direction nobody was watching.
Source: United States Government Accountability Office, Artificial Intelligence Acquisitions: Agencies Should Collect and Apply Lessons Learned to Improve Future Procurements, GAO-26-107859, 13 April 2026. Review covered 13 AI acquisitions at four federal agencies.
Where does requirements validation sit in agentic engineering?
Before the first heading. Validation is a different act from writing, and drafting a specification is an act of expression: you already believe something, and you are choosing structure and words to carry that belief accurately to an agent. Validation is an act of interrogation, where the belief itself is the thing on trial, and the two get conflated constantly because they produce artifacts that look similar on a screen. One asks how do I say this clearly. The other asks how do I know this is true, and only the second one would have caught the email-matching decision before an agent implemented it beautifully.
The mechanics matter more than the label. One analyst interviewing one stakeholder produces one framing, filtered through whatever that analyst walked in already believing, which is how a workaround gets recorded as a requirement and a hard regulatory constraint gets recorded as a nice-to-have. One lens. Several specialists interrogating the same interviews, tickets and policies from deliberately different expert positions produce something sturdier, because the questions collide and the collisions are where the unstated assumption finally surfaces. Specira runs five agents: four analysts working the material from distinct angles, plus a Red Team Critic whose entire job is to attack what the other four produced. Disclosure time, because that is the product I am building, so weigh the pitch accordingly and check the mechanism rather than the brand. The critic is the piece that matters for this argument. It is the one that asks why a rule exists rather than whether the rule is written clearly.
Then write the spec. Genuinely write it, with Spec Kit or OpenSpec or whatever your team settled on, and remember that the ceiling on what a spec can achieve is set by the discovery underneath it, because doing the validation work and then stranding it in somebody's meeting notes would be its own species of waste. The sequence is the argument. Validate first so the certainty in the document is earned, then let the spec carry it to an agent without losing fidelity.
Key takeaway
Vibe coding did not die, it got a professional sibling, and the sibling runs on specs. Real progress. Adopt it, but notice that a specification transports certainty rather than manufacturing it, so a perfectly structured spec built on an unvalidated assumption is still wrong, only now it is wrong with better formatting and a clean audit trail. Validation is the upstream act that decides whether there is anything worth specifying.
What should the gate check if not the shape of the spec?
Whether the requirement holds. A spec gate reads structure; Specira reads the line itself, giving every requirement a quality score, a source and an owner, and holding an AI proposal for a human decision instead of letting it merge into the set. Open the line and the check becomes explicit: promised outcomes as acceptance criteria, supporting sources, a review checklist with steps still outstanding. The PRD renders from what survived that.
What you are looking at. The requirements list is the gate that reads content rather than format, the requirement detail is what the gate is checking, and the PRD is what renders once the check passes.
Show us the spec gate you are relying on. We will show you the requirement it will pass without reading.
Book a DemoScreens are from a seeded Specira demo workspace; counts and scores are sample data.
What are the most common questions about the shift away from vibe coding?
