← Blog

loop-engineering · agentic-engineering · vibe-coding · aios · release

Vibe Coding Has a Ceiling. Loop Engineering Is What's Above It.

Karpathy named vibe coding, then declared the next stage himself. The unit of work is no longer the prompt, it is the loop, and the craft is knowing when to stop. We ran ours on a real release, and the failures were the interesting part.

John Ellison

John Ellison

13 min read

Sometime in the past eighteen months you did something that would have sounded absurd in 2022: you described what you wanted in plain English, and working software appeared.

Andrej Karpathy saw it coming before it had a name. In January 2023 he wrote, “The hottest new programming language is English.” By February 2025 he had named the feeling: “There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” He was talking about throwaway weekend projects, and said so. He accepted every change without reading it, and said that too.

The internet dropped the caveats and kept the word, because the word named something real. A month later, Y Combinator’s Jared Friedman told TechCrunch that a quarter of the startups in the current batch had 95 percent of their code generated by AI. Not hobbyists: Friedman stressed these were highly technical founders. Building by describing had gone from party trick to default.

If you run a company and work with AI every day, you have lived this shift. You have built something over a weekend that your team then actually used. This post is not going to tell you that was naive. It was the correct first move. It is just not the last one.

A circular agent loop with a single gate breaking the circle, the gate highlighted as the point of interest.
Anyone can start a loop. The craft is the gate: how it knows it is done, wrong, or stuck.

The ceiling you have already felt

In the same TechCrunch piece, YC’s Garry Tan drew the line that matters. Get a vibe-coded product in front of a hundred million users, and the question becomes blunt: “does it fall over or not?”

Simon Willison, one of the most careful independent voices on AI-assisted work, drew the line more precisely: “If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that’s not vibe coding, it’s software development.” That distinction is not snobbery. It is the difference between a demo and an asset.

At company scale the ceiling shows up in the ugliest statistic in enterprise AI. An MIT study reported by Fortune in August 2025 found that about 95 percent of enterprise generative AI pilots were failing; only about 5 percent achieved rapid revenue acceleration. The report’s diagnosis was not the models. It was the learning gap: how the AI was integrated into the way people actually work. In other words, process. The models were ready. The companies’ way of working with them was not.

You have felt this even if you never read the studies. It is the prototype that dazzles on Friday and cannot be trusted on Monday. It is the AI-drafted analysis nobody checked, quietly wrong in paragraph four. A demo that dazzles is a prompt problem. A product you can trust is a loop problem.

From vibes to loops: the discipline emerging

Karpathy closed his own arc. In February 2026, one year after the original post, he wrote that “programming via LLM agents is increasingly becoming a default workflow for professionals, except with more oversight and scrutiny,” and offered his own name for the next stage: agentic engineering. Agentic because you are orchestrating agents and acting as oversight. Engineering because, in his words, “there is an art & science and expertise to it.” The man who named stage one declared stage two himself.

The tools moved first. In February 2025 Anthropic shipped Claude Code, created by Boris Cherny, and introduced it not as autocomplete but as “an active collaborator that can search and read code, edit files, write and run tests, commit and push code to GitHub.” A colleague you delegate to, not a suggestion box. By early 2026, per Cherny, it had grown from a quick internal hack to 4 percent of all public code changes on GitHub.

Underneath the renaming is one reframe worth carrying into every AI decision you make this year. The unit of work is no longer the prompt. It is the loop: plan, build, check, fix, repeat. And the engineering is in the stopping rule: how the loop knows it is done, knows it is wrong, or knows it is stuck and should ask a human.

Anyone can start a loop. Ask an agent to keep going until it is finished and it will keep going. The hard part, and the entire discipline, is what stops it.

A three-stage arc from vibe coding, a single prompt-to-app arrow, through agentic engineering with human oversight, to loop engineering, a closed plan-build-check-fix loop with an explicit stopping gate.
The arc so far: describe and hope, then supervise, then engineer the loop and its stopping rule.

A small set of people are defining this discipline in public, and they are worth your reading time. Karpathy named both ends of the arc. Boris Cherny runs many agents in parallel and calls verification the single biggest lever: “give Claude a way to verify its work.” Simon Willison calls designing agentic loops the emerging core skill, and admits the bottleneck in his own setup is that a human, him, still reviews everything. Geoffrey Huntley proved how far a bare loop can go: his “Ralph” is a one-line loop that reruns an agent until the task list is empty, and it once delivered a $50,000 contract for $297 in AI costs. It also has no checks at all; a human eyeballs the output. And Anthropic’s patterns essay described the shape we build on: one AI generates while a second AI critiques, looping until the critic is satisfied.

Notice what they disagree about. Not the loop. Everyone has a loop. They disagree about what stops it.

We ran the loop on a real release. The failures were the interesting part.

Claims need proof, so here is ours. This week we shipped version 0.6.0 of AIOS, our open-source toolkit (introduced properly below), as nine pieces of work in four batches, and AI agents did both the building and the checking. We tuned the rules after every batch and kept score.

The setup, in plain language:

  • One AI built. Anthropic’s Opus model planned each batch and wrote the code.
  • A second AI from a different vendor was paid to find problems. OpenAI’s GPT-5.5 reviewed every plan and every batch of changes adversarially, meaning its explicit job was to attack the work, not approve it. The system refuses to run if the builder and the reviewer are from the same family of AI models, so the builder never marks its own homework.
  • Automated checks that cannot be sweet-talked ran first. Tests, formatting, and a scan for leaked credentials pass or fail mechanically, before any AI opinion is spent. An AI reviewer can be argued with. A test cannot.
  • Hard budgets, with a rule for running out. Planning gets at most three review cycles, building four, fixing two. When a budget runs out, the loop does not grant itself more time. It stops and asks a human.

Here is what the score said.

Planning cycles fell from 7 to 2 once we wrote down what “good enough” means. The first batch took seven rounds of plan-and-critique, because a reviewer paid to find problems will always find another problem, and our only stop condition was the reviewer’s satisfaction. When I supervise the work myself, I am the stopping rule: I say “good enough” and work proceeds. Nobody had taught the automated loop that rule. So we wrote it down: stop when there are no showstoppers and no objections to the approach itself, and let polish wait for the later review of the actual work. The next two batches planned in two rounds each. Same AI models, same kind of work. The gain was pure process.

Two panels: planning rounds falling from 7 to 2 to 2 across three batches of work, and rounds per piece of work falling from a supervised baseline of about 3 to 1 in the tuned automated loop.
Same AI, same kind of work. Planning cycles fell 7 to 2 to 2 after we taught the loop what 'good enough' means.

The worst failure was 75 minutes of silence. At the end of the second batch, with the work built and only final checks left, the loop sat idle from 18:36 to 19:50. An external check had timed out, the agent had no instruction for that specific case, and so it did the worst possible thing: nothing. It did not crash. It did not ask for help. It waited, on nothing. The fix became a rule we now treat as fundamental for anyone running agents unattended: every signal, including a timeout, is a decision point, never a reason to idle, and a supervisor now checks for signs of life and steps in if nothing has moved for ten minutes. If you take one operational lesson from this post, take this one: when an AI system fails, it often fails silently, and you have to engineer the silence away.

A timeline showing active work interrupted by a 75-minute idle stall, with a marker showing where the new supervision rule now intervenes within ten minutes.
The 75-minute failure was not an error. It was silence. Unattended AI has to be engineered so that silence is impossible.

Once, the loop correctly gave up. That was the system working. The third batch hit its fixing budget with one known problem still open. Instead of granting itself another round, it stopped and flagged a human, exactly as designed, with its full written record attached. Resolution took about fifty minutes. An agent that knows when to stop and ask is worth more than an agent that never stops.

And one honest number to close the section: checking cost more than building. On the first batch, the verification tail, waiting for reviews, running checks, fixing findings, took 67 percent of the total time. That is the price of output you can trust without re-reading it, and it is worth saying plainly, because the vibe-coding era priced verification at zero.

The frontier nobody has solved: agents on a team

Everything above is one person, or one automated loop, running agents. That problem is now reasonably well understood, and the discipline around it is forming fast. The open problem is what happens at company scale.

Maggie Appleton of GitHub Next put it exactly: “At this point, in early 2026, all coding agents are designed as single player experiences. But building software isn’t a single player game.” Her sharper follow-on: “Agreeing on what to build is the new bottleneck.”

Play it forward in your own company. Ten people, each running agents, each agent working from its own picture of reality. Whose agent knows about the pricing decision made on Tuesday? What is an agent allowed to share with the team, and what must never leave one person’s machine? What is safe to show a client? At most companies today the answer is a policy document that no agent has read and no software enforces. GitHub’s own answer is a research prototype, not a shipped product. One person with agents is close to solved. A team of people, each with agents, sharing context safely, is genuinely open.

One person with orbiting agents inside a single clean boundary, next to five people whose separate agent clusters connect only by broken lines marked with question marks.
One person with agents works. A company of people, each with agents, is where context sharing breaks down.

What we built for this: AIOS

This is the problem AIOS exists for. We built it during a real AI transformation engagement, working inside a team adopting agents, and open-sourced what worked.

AIOS is an AI-powered operating system for agentic teams. Every person gets a structured agent workspace. The team gets one shared brain. Two parts, and deliberately no third moving part to manage:

  • The individual workspace is your agent-native environment: the same simple structure for every person, so any agent always knows where things are and where results go. It runs on your machine, and nothing leaves your machine until you decide.
  • The team brain is the one shared memory your team’s people and agents can query in plain English: what has been decided, what is in motion, and what is actually true right now.

Between them sits the tier model, which fits in one sentence: everything you create is marked private, team, or client, and machinery, not a policy document, enforces which of those ever leaves your machine.

Individual workspaces, each containing its own small gated loop, push team-tier work into one shared brain, while private work stays home and a single client-tier flow runs outward.
Every person runs their own loops. Private stays home, team flows to the one shared brain, client moves only on an explicit push.

And as of this week, version 0.6.0 ships the loop tooling described above. One command, aios ship, runs the whole gated loop for a piece of work: plan, adversarial review, build, mechanical checks, a cross-vendor review, a bounded fix cycle, and the stop-and-ask-a-human rule when budgets run out, with a written record of every step kept on disk. It is the loop that shipped its own release.

It’s MIT-licensed and self-hosted, and you decide what leaves your machine.

Where to start

If you have felt the ceiling, the move is not to retreat from AI. It is to graduate from prompts to loops, and from loops to loops with stopping rules, and to give your team one shared memory instead of ten private ones. Get started with AIOS. It is free, open source, and runs on machines you control.

If you want to go deeper into the discipline first, we keep two public resources current: the watchlist of practitioners we track systematically, and the pattern library, 24 named ways of working with agents, including every pattern the loop above is built from. The project lives on GitHub.

Vibe coding taught a generation of builders that describing is enough to begin. It is. The next stage is the one your company will actually run on: the loop is the unit of work now, and the stopping rule is the craft.