Vibe coding is dead: enter UltraCoding

When the inventor buries his own word

On 2 February 2025, Andrej Karpathy (co-founder of OpenAI, former director of AI at Tesla) posted a message on X that went viral within hours. In it he described a new way of programming: describe what you want in natural language, let a model write the code, accept whatever comes back, run it again if it does not work. His phrasing hit the mark: “fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists” [1]. The term vibe coding was born. Within months, it entered Merriam-Webster as a “trending” expression, then was crowned word of the year 2025 by the Collins Dictionary [3].

It is worth reading the rest of the original message, which collective enthusiasm often forgot. Karpathy specified that the practice was meant “for throwaway weekend projects”. The practitioner Simon Willison set out the most rigorous definition a few weeks later: doing vibe coding is not “using AI to code”: it is building software without reading the code the AI writes [2]. The move that defines vibe coding is not generation. It is the renunciation of review.

Yet, in early 2026, that same Karpathy has turned the page. He now declares vibe coding “passé” and proposes another term to describe the future of software: agentic engineering [4][5]. The distinction he draws is clear: vibe coding consists of describing and accepting; agentic engineering consists of designing the system, specifying the constraints, and reasoning about the architecture up front, then orchestrating agents that implement, under supervision [5].

The inventor has buried his own word. This is not a disavowal: it is a diagnosis. Vibe coding was not a mistake. It was a prototyping technique that the market mistook for a production method. And the bill for that misunderstanding can now be quantified.

The bill for vibe coding

Three serious studies, published in 2025, allow us to move beyond impressions and look at the figures.

Security first. In July 2025, the software vendor Veracode published its GenAI Code Security Report: 80 development tasks submitted to more than 100 different models. The result is stable and troubling: when a model has the choice between a safe and an unsafe way to write a piece of code, it picks the vulnerable version in 45% of cases [6]. The detail matters: the rate climbs to 72% in Java, and above all it does not improve from one model generation to the next, a finding stable across every family tested (OpenAI, Anthropic, Google). Veracode’s March 2026 update extends the finding: after two years of releases billed as revolutionary, the rate stays at 45%, including on GPT-5.1/5.2, Gemini 3 and Claude 4.5/4.6 [6]. In other words, waiting for “the next, more intelligent model” will not solve the security problem. A more capable model writes more impressive code, not necessarily safer code.

Productivity next. In July 2025, the independent laboratory METR published a randomised controlled trial, the gold standard of scientific proof. Sixteen experienced open-source developers, 246 real tasks on projects they had known for five years on average. The verdict: with the AI tools of early 2025, they took 19% longer to complete their tasks. The most troubling part is not the slowdown. It is the perception gap: those same developers estimated that AI had made them 20% faster [7]. The machine does not merely slow you down: it gives the illusion of acceleration. This is exactly the trap of vibe coding: the sense of fluidity masks the real cost, which is paid later, in debugging.

Delivery last. Google Cloud’s DORA 2025 report, the annual reference for measuring software performance, confirms the shift at the organisational level: adopting AI does increase throughput (you ship more), but it also increases the instability of production releases [9]. Its formulation says it all: “AI does not fix a team; it amplifies what is already there”. The following edition (Google Cloud/DORA, May 2026) confirms it by drawing a “J-curve”: the verification and instability tax comes before the gains. Without a control system (robust automated tests, continuous integration, small batches, fast feedback loops), more code shipped faster mechanically produces more breakage.

The common thread across these three findings is clear. The problem is not AI’s ability to generate code. It has never been stronger. The problem is the absence of a verification system around that generation. Vibe coding removed review without putting anything in its place. This is precisely the void that the next practice fills.

From “agentic engineering” to UltraCoding

Karpathy’s agentic engineering describes a stance: no longer writing the code yourself 99% of the time, but orchestrating agents that do it, while keeping control of design, constraints and supervision [4][5]. This is right. But a stance is not a method. “Keeping control” and “supervising” do not say how, nor how far, nor at what point you are allowed to ship.

It is this shift from stance to production line that we call UltraCoding. The word is deliberately strong, because the practice is. UltraCoding is an agentic software production line whose sole exit condition is a measured quality level, and which accepts consuming more resources to reach that level: more tokens, more compute, more machine time. Over-consumption is not a side effect to be corrected. It is the entry price of a quality that vibe coding structurally could not deliver.

UltraCoding comes down to four moves, plus one cross-cutting audit:

1. Multi-agent orchestration: several specialised AIs rather than a single generalist one.
2. Adversarial review: an AI whose job is to break another’s code.
3. Three-layer testing: from the classic automated test to AI-driven visual inspection of the interface.
4. The threshold deployment loop: you start over until you reach the bar, then you ship.

And, cutting across each of these moves, an audit: security, internationalisation (i18n), accessibility.

Let us take each move in turn, with what justifies it.

Move 1: Multi-agent orchestration

The dominant intuition of 2023-2024 was that a single model, ever larger, would eventually do everything. The practice of 2025-2026 says the opposite: you get better results with several specialised agents working together than with a single overloaded one.

The most thoroughly documented demonstration comes from Anthropic. In the field report published in June 2025 on its multi-agent research system, the architecture is of the orchestrator-workers type: a lead agent plans, launches 3 to 5 specialised sub-agents in parallel, each with its own context window, then synthesises their work. Measured result: this arrangement outperforms the single agent (Claude Opus 4 alone) by 90.2% on their internal evaluation [8].

The same field report gives the price of this performance, and it is essential for a business leader: the system consumes roughly 15 times more tokens than an ordinary conversation, and the quantity of tokens used alone explains nearly 80% of the performance variance [8]. In plain terms: quality is paid for in resources, in an almost linear fashion. The economic rule Anthropic draws from this is the right compass for UltraCoding: the multi-agent architecture makes sense only when the value of the task exceeds the cost of the tokens. To produce software destined for production, for customers, for money in transit, this condition is almost always met.

In concrete terms, an UltraCoding team does not launch “an AI that codes”. It orchestrates an architect that breaks the work down, several implementers that write in parallel, a tester that stress-tests it, a reviewer that challenges it. Each has a role, a scope, and a context window of its own.

Move 2: Adversarial review

This is the heart of UltraCoding, and it is what most clearly separates it from vibe coding. An AI must never be its own judge. Asking it “is your code correct?” amounts to asking a candidate to mark their own paper: they will give themselves a good mark.

The countermeasure has been known to research since 2023 and has a name: the generator-critic loop. One agent produces; another agent, independent, has the sole mission of finding the flaw. OpenAI trained a model dedicated to this purpose, CriticGPT, specifically to critique and flush out the bugs in code written by other models [10]. The academic frameworks Self-Refine (generate → critique → correct) and Reflexion (remembering one’s failures so as not to repeat them) formalised this mechanism of self-improvement through confrontation [11]. Code has a unique advantage here over text: it is executable. The feedback is not an opinion, it is a compilation or test result, an objective fact on which the loop can rely.

Adversarial review does not stop at functional correctness. It extends to security: a “red team” agent whose role is to think like a malicious actor: hunting for prompt injection, data leakage, the missing authorisation. Given the 45% rate of vulnerable code measured by Veracode [6], this confrontation is not a luxury: it is the only credible defence against a flaw that models, left to themselves, reproduce generation after generation.

The rule, in UltraCoding, admits no exception: the generator never validates its own output.

Move 3: Three-layer testing

Testing, in UltraCoding, does not mean “running the unit tests”. It means stacking three layers of verification, from the most mechanical to the most subtle.

Layer 1: the classic automated tests. Unit, integration, end-to-end tests. This is executable truth: does the code do what it claims to do? This layer is necessary but insufficient: it checks the logic, not the experience or the safety.

Layer 2: the audit. Two checks that vibe coding almost always ignores. First, security: static analysis, detection of secrets in plain text, verification of headers and of protections against classic attacks, the direct answer to Veracode’s 45% [6]. Then internationalisation and accessibility: pseudo-translation to flush out hard-coded text, handling of right-to-left languages, date and currency formats, and compliance with accessibility criteria (WCAG) so that the interface remains usable by everyone. These audits are not “felt” in a demo; they reveal themselves in production, often at the worst possible moment.

Layer 3: AI-driven visual inspection of the interface, with UX/design critique. This is the most recent and most spectacular layer. Until 2024, testing an interface came down to comparing pixels: fragile, noisy, blind to meaning. The arrival of vision-language models (VLMs) changed the game. These models look at the rendered screen and understand it as a human would: no longer “this pixel moved by 3 points”, but “the Buy button is partly hidden by a banner, so the primary action is compromised” [14]. The tool Percy launched, in late 2025, a visual review agent that makes review roughly 3 times faster and filters out nearly 40% of false positives [14]. Beyond rendering, academic work such as UXAgent (CHI 2025) simulates panels of users and runs automated heuristic evaluations of usability before any real human test [12].

A note of honesty is required here, because this is the least mature layer. AI UX critique is not infallible: in March 2025, two Microsoft UX researchers measured accuracy rates of only 50 to 75% for heuristic evaluations conducted by AI, whereas specialised, trained systems such as Baymard’s claim up to 95% [13]. The operational conclusion is clear: AI-driven visual inspection speeds up and broadens review; it does not replace human design judgement. It flags, it pre-sorts, it documents. The aesthetic decision and the experience call remain human.

Move 4: The threshold deployment loop

Here is what makes UltraCoding a method and not a collection of tools. The three preceding moves run in a loop (generate, confront, test, correct) and this loop does not stop when the developer is tired or when the deadline looms. It stops when an explicit, measurable quality threshold is reached: test coverage, zero critical vulnerabilities, accessibility compliance, visual review score. As long as the threshold is not crossed, the loop starts over. As soon as it is, deployment is triggered.

This inversion runs deep. In vibe coding, you ship when “it looks like it works”. In UltraCoding, you ship when the bar is reached, not when the human is spent. This is exactly the prescription of the DORA 2025 report: pairing AI’s increased throughput with automated guardrails, small batches, fast feedback loops; failing which speed is paid for in instability [9]. The threshold makes the decision to ship objective, reproducible and defensible.

The honest counter-argument: it is expensive, but it can be internalised

It must be said plainly: UltraCoding consumes. Fifteen times more tokens for multi-agent orchestration as measured by Anthropic in 2025 [8], compute for each test layer, time for each turn of the loop, latency. The 2026 measurements put the agentic-workflow range at 5 to 30 times (TechCrunch, June 2026). It is not free, and pretending otherwise would be dishonest.

The consequence is that there are cases where UltraCoding is a waste. For a throwaway script, a macro you will run once or a weekend prototype meant to validate a hunch and then be deleted, vibe coding remains perfect, and Simon Willison is right to say that it “rocks” in that register [2]. Deploying a three-layer adversarial pipeline for that would be like putting a car through its MOT the day before it is sent to the scrapyard.

UltraCoding, by contrast, becomes non-negotiable as soon as the cost of a bug exceeds the cost of the tokens: software in production, an interface facing customers, a regulated system, a flow that touches money or personal data. There, saving 15 times the tokens in order to risk a security flaw (45% probability by default, as measured by Veracode in mid-2025 [6]) or an unstable production release [9] is not a saving. It is a transfer of cost to later, with interest.

And this cost is not even inevitable: it can be internalised. The 15-fold consumption is only a problem as long as you pay for it by the unit, as a running expense (OpEx), to a frontier API billed by the token. Nothing dictates this model. A dedicated inference server, an open-source model well calibrated to its domain, and an agentic loop developed in-house turn this over-consumption into an amortised investment (CapEx): a fixed hardware asset that runs without a meter, on infrastructure you own. The amortisation calculation often tips in favour of internalisation as soon as the volume is there, and it brings what billed cloud will never give: sovereignty. The company’s code, data and secrets no longer leave its perimeter.

Better still: these loops have no reason to run at peak hours. They can execute in hidden time, when the servers are not tied up with real-time tasks: at night, at the weekend, in the troughs of load. The compute cost then becomes a hidden cost: you draw on capacity that is already paid for and otherwise unused. All that remains, at the margin, is energy, itself optimisable (off-peak hours, load management, low-carbon electricity). UltraCoding thus ceases to be a variable expense imposed upon you and becomes an owned industrial capability. The honest trade-off is that it takes sufficient volume to amortise the hardware and internal skill to calibrate the model and keep the loop running: this path is not for everyone, but it is open to anyone who wishes to escape renting.

And the human, in all this? The METR study is a salutary guardrail [7]: AI left to itself can slow things down and mislead about its own speed. UltraCoding does not remove the human. It moves them to where they create the most value: defining the threshold, writing the specification, adjudicating the cases the machine does not settle, and signing off the delivery. The developer no longer types every line; they become the architect of the standard and the judge of last resort.

What this changes for a business leader

One can read this article as a matter for engineers. That would be a mistake. UltraCoding is first and foremost a quality requirement that any business leader can, and should, formulate, without writing a single line of code.

You do not have to build the pipeline yourself. What you have to know is how to demand the bar and budget the resources when the stakes justify it. Three questions are enough to reveal the maturity of a supplier or an internal team: Who reviews the code your AI produces, and with which other tool? How do you test the interface and the security before delivery? What measurable threshold triggers a production release, and who signs it off? A team that “does vibe coding” has no answer to these three questions. A team that practises UltraCoding has them all.

This is exactly how we build Junyr Suite. Our conviction, in the MATIA Method™, is that in the AI era scarcity does not shift towards the generation of code (that becomes abundant) but towards verification: the ability to guarantee, prove and hold a level of quality. This is where the AI transformation of companies is now decided: not “producing faster”, but “producing to a standard that can be defended before a customer, an auditor or a regulator”.

And this is where UltraCoding goes beyond software. The logic that underpins it (generate, pit against an adversary, stress across three layers, ship only at the threshold) has nothing specific to code about it. It is a loop of trust transposable to any work produced by an AI. This is precisely what we do with the MATIA Method™: we implement UltraCoding in companies, then we apply the same loop to agents across every function: sales, finance, marketing, support, HR. An agent that drafts a proposal, qualifies a prospect or prepares a report follows the same cycle as an agent that writes code: production, adversarial review, control, quality threshold before any action. Generation becomes abundant everywhere in the company; verification, for its part, becomes the standard everywhere. That, at bottom, is the AI transformation: not plugging in models, but installing the loop that makes their work reliable.

Vibe coding promised to forget that code exists. UltraCoding makes the opposite bet: to remember that, behind every smooth interface, there is code that someone answers for. This responsibility cannot be delegated to a “vibe”. It is organised.

In one sentence

Vibe coding taught the world that AI can write anything. UltraCoding teaches it the only thing that matters now: how to know that what it has written is good, before shipping it.

To turn UltraCoding into a quality standard across your software projects, see the MATIA Method™ and the AI Express Audit & Roadmap.

---

Sources

[1] Andrej Karpathy, post on X, 2 February 2025 (origin of the term vibe coding), synthesis and quotation via Vibe coding, Wikipedia. https://en.wikipedia.org/wiki/Vibe_coding [2] Simon Willison, “Not all AI-assisted programming is vibe coding (but vibe coding rocks)”, 19 March 2025. https://simonwillison.net/2025/Mar/19/vibe-coding/ [3] Collins Dictionary, vibe coding, word of the year 2025; Merriam-Webster, “slang & trending” mention, March 2025 (via Wikipedia). https://en.wikipedia.org/wiki/Vibe_coding [4] “Vibe coding is passé. Karpathy has a new name for the future of software”, The New Stack, 2026. https://thenewstack.io/vibe-coding-is-passe/ [5] “Andrej Karpathy Has Renamed Vibe Coding. Here’s What Engineering Leaders Need to Do About It”, SD Times, 2026. https://sdtimes.com/ai/andrej-karpathy-has-renamed-vibe-coding-heres-what-engineering-leaders-need-to-do-about-it/ [6] Veracode, 2025 GenAI Code Security Report, 30 July 2025 (45% vulnerable code; 80 tasks, 100+ models; Java 72%; stability GPT-4→GPT-5/Claude/Gemini); confirmed by the Spring 2026 GenAI Code Security update, 24 March 2026 (pass rate still ~55%, 150+ models evaluated, plateau held through GPT-5.1/5.2, Gemini 3 and Claude 4.5/4.6). https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/; https://www.veracode.com/blog/spring-2026-genai-code-security/ [7] METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, 10 July 2025 (arXiv 2507.09089), 19% slowdown, perception gap. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ [8] Anthropic, “How we built our multi-agent research system”, June 2025 (orchestrator-workers, +90.2% vs single agent, ~15× tokens, ~80% of the variance). https://www.anthropic.com/engineering/multi-agent-research-system [9] Google Cloud / DORA, 2025 State of AI-assisted Software Development Report (throughput up, instability up; “AI amplifies what is already there”). https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report [10] OpenAI, CriticGPT, model trained to critique and find bugs in code generated by other models (2024), via LLMs-as-Judges: A Comprehensive Survey (arXiv 2412.05579). https://arxiv.org/pdf/2412.05579 [11] Self-Refine (Madaan et al., 2023) and Reflexion (Shinn et al., 2023), generate→critique→correct loop and verbal reinforcement through memorisation of failures (via arXiv 2412.05579). https://arxiv.org/pdf/2412.05579 [12] UXAgent: An LLM Agent-Based Usability Testing Framework for Web Design, CHI 2025 (arXiv 2502.12561; Amazon Science), simulated personas and automated heuristic evaluation. https://arxiv.org/abs/2502.12561 [13] Baymard Institute, “AI Heuristic UX Evaluations with a 95% Accuracy Rate” (and caveat: Microsoft UX researchers, March 2025, accuracy 50-75% depending on the case). https://baymard.com/blog/ai-heuristic-evaluations [14] Vision-language models for interface testing and agentic visual review (Percy AI Visual Review Agent, late 2025: ~3× faster, ~40% of false positives filtered out; semantic reading of the screen), TestMu (LambdaTest). https://www.testmuai.com/blog/visual-testing-ai-agent/ [15] A Survey of Vibe Coding with Large Language Models (arXiv 2510.12399, 2025), academic framing of the practice and its limits. https://arxiv.org/pdf/2510.12399