How to Vibe Code a SaaS with the Karpathy Loop (2026 Guide)

You open Claude Code. You type a prompt. You read the output, spot the problem, type another prompt. You do this forty times before lunch, and your SaaS is still mostly a login page.

That's not how the fast builders work anymore. In 2026 the people shipping real products with AI stopped prompting turn by turn and started running loops: a cycle that plans, executes, verifies, and re-runs the agent while they make the decisions that matter. The community calls the pattern the Karpathy loop, and the discipline of designing these cycles picked up its own name in June: loop engineering.

Boris Cherny, who leads Claude Code at Anthropic, put the shift in one line:

"I don't prompt Claude anymore. I have loops running that prompt Claude."

This guide covers what the loop is, why hand-prompting breaks on a real SaaS build, and the exact steps to run the loop on your own product this week.

What is the Karpathy loop?

Andrej Karpathy coined vibe coding: you describe what you want, AI writes most of the code, you steer. The pattern now named after him is vibe coding grown up. Instead of you pushing every cycle forward by hand, the loop runs itself:

Reason → Act → Observe → Decide.

The agent reasons about the current state, acts with real tools, observes what happened, and decides between three exits: a verifier confirms the goal is met (success), progress stalls or the budget runs out (escalate to you), or neither (go around again).

The load-bearing word is verifier. A loop without real verification is an agent agreeing with itself. Tests, type checkers, and build steps make the best verifiers because the model can't charm them.

What is loop engineering?

Loop engineering is the practice of designing that cycle: the goal it chases, the tools it uses, the memory it keeps, and the conditions that stop it. Peter Steinberger kicked off the term in June 2026 with a post arguing developers should design loops, not write prompts; Addy Osmani's "Loop Engineering" essay gave it structure a day later. The research behind it is older: ReAct (2022), Reflexion (2023), Anthropic's "Building Effective Agents" (December 2024).

It caps a stack you already know, and each layer contains the one before it:

1. Prompt engineering (2022–2024): choosing the right words
2. Context engineering (2025): curating everything the model sees
3. Harness engineering (early 2026): giving the agent tools, files, constraints
4. Loop engineering (2026): designing the repeating cycle itself

A loop still needs good prompts, good context, and a good harness. The loop is what makes them run without you.

Why hand-prompting breaks on a real SaaS build

A SaaS is a multi-week project with hundreds of decisions. Drive it by hand-prompting and three things fail, every time:

Context dies. Your chat fills up, the session compacts or resets, and the agent forgets the decision you made on Tuesday. You re-explain your own product to your own tools.

Nothing verifies. The agent says "done," you believe it, and two days later you find the webhook handler it stubbed out. Hallucinated success is the default failure mode of unverified AI work.

You are the loop. Every cycle waits on you to read output, judge it, and type the next instruction. The agent works at machine speed. The project moves at yours.

The fix is structural: move goals, memory, and verification out of the chat and into files the loop reads on every run. And one more thing the naive version gets wrong: don't run one giant loop over the whole project. A loop that chases "build the whole SaaS" accumulates the same garbage a chat does. The unit that works is the phase: split the project into phases on a roadmap, and run a complete loop inside each one.

You can wire all of that yourself, and the good write-ups take a weekend to copy. Or you run it pre-built. PropelKit packages the whole system: half production boilerplate (the 90% you shouldn't rebuild), half an AI Product Manager that runs a Karpathy loop per phase through Claude Code commands. The steps below show the system using those commands; the structure is the same if you build your own.

Step 1: Turn your idea into a testable goal

Every loop needs a goal a verifier can check, and "build my SaaS" is not one.

Run /pk:new-project. It interviews you about the product in a real conversation: what it does, who pays, how teams and permissions work, what's v1 and what's later. Then it writes the answers down as structure, not chat history: REQUIREMENTS.md with scoped requirement IDs, a ROADMAP.md that splits the build into phases and maps every phase to the requirements it delivers, success criteria per phase, and a STATE.md that becomes the project's memory.

The roadmap is the move most people miss. It turns "build my SaaS" into eight or ten phase-sized goals, each small enough for a loop to actually close. Steps 2 through 4 below are that per-phase loop; you run them once per phase, not once per project.

STATE.md matters more than it looks too. Durable state outside the model is what lets the system survive context resets, new sessions, and your weekend off.

Step 2: Plan the phase before any code exists

Each phase opens its own loop, and two commands split its thinking from its doing.

/pk:discuss-phase captures how you imagine this phase working, into a CONTEXT.md the agent reads on every run inside the phase. This is where your taste enters the loop.

/pk:plan-phase turns the phase into two or three concrete plans with verification criteria written into each one. Plans are deliberately sized to fit a fresh context window, so execution never runs on a degraded, half-full session. Every task ships with its own definition of done before execution starts.

Step 3: Let the loop execute

/pk:execute-phase runs the phase's plans. Independent plans run in parallel as separate agents; dependent ones run in ordered waves. Each plan gets a fresh context dedicated purely to implementation, zero garbage accumulated from earlier work. Every completed task gets its own commit, so a crashed session costs minutes, not days. When the waves finish, the phase goal gets checked against the roadmap before the next phase opens.

Your involvement during this step is a setting, not a vibe. Interactive mode pauses at major decisions for approval. YOLO mode auto-approves everything except critical checkpoints. Same loop, different escalation threshold, changeable anytime in .planning/config.json.

Step 4: Verify like you don't trust it

/pk:verify-work is the phase loop's exit condition. It walks you through what got built one feature at a time, in plain yes/no/describe-the-issue answers. Pass, and the phase closes with its goal confirmed and the next phase opens with clean context. Fail, and it diagnoses the gap and writes fix plans that feed straight back into Step 3. That's the revise beat of the Karpathy loop: failure becomes input, not a restart.

This per-phase granularity is why the system beats one big loop. Problems surface at the end of a phase, while they're small and local, instead of at the end of the project, when they're load-bearing. Each phase gets your input before, fresh context during, and your sign-off after. Then the cycle starts again on the next phase, all the way down the roadmap.

Step 5: Debug without losing the investigation

Real projects hit bugs the loop can't fix in one pass. /pk:debug investigates with an evidence → hypothesis → test method and writes the entire investigation to .planning/debug/. Clear your context mid-hunt, run /pk:debug again, and it resumes from the file. The investigation outlives the session, which is the whole point of keeping state outside the model.

Step 6: Stop and resume like it's infrastructure

/pk:pause-work writes a handoff. /pk:resume-work restores full project context in a fresh session. /pk:progress shows where you are and routes you to the next action. Between them, the project stops living in a chat window and starts living in .planning/, where nothing evaporates.

What the loop won't do for you

The hype version of this gets people hurt, so the honest limits:

• A loop can't fix a vague goal. If you can't state what "done" looks like, no cycle count will find it. The interview step exists because of this.
• Judgment stays yours. Pricing, what ships in v1, whether the dashboard feels right: the loop pauses for those, and it should.
• One-off tasks don't need loops. Renaming a component? Just prompt. Loops pay off on multi-session work with real failure modes.
• Verification is the whole game. Building with Claude works when the checks are real. A loop that grades its own homework ships homework.

Start with the loop already wired

You can build the state files, planning format, verification gates, and debug persistence yourself. Builders do.

Or you start where it's already connected to a production codebase. PropelKit is $69, one time: Next.js 15, Supabase auth, Stripe, Razorpay, DodoPayments, Resend, Inngest, and multi-tenancy on one side; /pk:new-project → /pk:plan-phase → /pk:execute-phase → /pk:verify-work on the other. A roadmap that splits your idea into phases, a Karpathy loop running inside each one, and the infrastructure already underneath it.

Get PropelKit →