Loop engineering with Next.js: the agent loop that verifies its own routes

You ask the agent for an API route. It returns 200 in dev, you deploy, and it 500s in prod because an env var was never wired. Or the route works and quietly returns the wrong shape, and the bug surfaces in a client three components away. The agent shipped faster than you could verify it. That gap is the whole reason to care about loops.

Loop engineering has been the phrase in every other AI newsletter this month. Here is what it actually means for a Next.js app, and how to wire one that does not deploy a broken route.

Where the term comes from

The lineage is short. Andrej Karpathy made the case for "context engineering" over "prompt engineering," because the real work is filling the context window with the right things for the next step. Then the agent crowd pushed it a floor higher. Boris Cherny, who built Claude Code at Anthropic, says he doesn't prompt Claude anymore, he runs loops that prompt Claude and figure out what to do. Geoffrey Huntley runs a coding agent inside a plain while loop he calls Ralph. Same shape everywhere: stop prompting the agent every turn, build the thing that prompts it for you.

The four parts of a loop

A loop is the thing that runs your work without you re-prompting it each time. It has four parts.

A memory it reads before it acts and writes to after. A set of rules it cannot cross. A verifier that confirms the output before it counts. A schedule that kicks the whole thing off. Memory, rules, verify, schedule. You wire them once, then you step out of the middle.

A worked example: a loop that adds a route

Here is the loop running on something every Next.js app has, adding an endpoint. Watch where the verifier earns its place.

The goal, written as checkboxes before any code:

/goal Add a /health endpoint to the app.
End-state (true/false checkable):
- [ ] GET /health returns HTTP 200
- [ ] the response body is {"status":"ok"}
- [ ] npm test exits 0 and next build succeeds

Run 1. The worker reads the memory and rules, adds the route handler under app/health/route.ts, and reports success. The verifier ignores the report and runs the checks literally:

RESULT: FAIL
EVIDENCE: GET /health -> 200; body {"ok":true}; npm test -> exit 0; build ok
FAILED_CHECK: body must be {"status":"ok"}, got {"ok":true}

Three checks passed. The worker returned the wrong shape, and that is the kind of thing that compiles, deploys, and breaks a consumer three components downstream. The checker caught it before it left the loop.

The ratchet. The failure becomes a new rule:

- Health and status responses use {"status":"ok"}, never {"ok":true}.

Run 2. Worker fixes the body, the verifier re-runs every check, all pass. The loop logs it and stops. Two runs, nobody in the middle, one shipped bug avoided.

The part everyone skips

The verifier is the one people leave out, and it's the one that matters most. Memory plus rules plus schedule gives you an agent that runs a lot. It doesn't give you one you can trust to run alone. Skip the verify step and you don't have a loop, you have a very confident intern with a cron job.

There is a second payoff on the web specifically. A codebase the agent can verify against is also a codebase the agent can keep building on without drifting, which is most of what makes a project "AI-buildable" instead of a one-shot demo that rots.

What this needs to stand on

A loop is only as good as the rules and structure it builds against. If every run rediscovers your routing conventions, your test setup, and your types, the loop burns its budget reinventing the project instead of moving it forward.

That is the foundation AI Web Launcher ships: a Next.js 15 boilerplate built so agents can actually build on it, with typed routes, a test harness, and the conventions written into an AGENTS.md the loop reads first. The rules and the verifier are there from run one. You bring the goal.

One warning before you wire one

The loop doesn't know what you're using it for. Two people build the identical setup and get opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. Build the loop like someone who intends to stay the engineer, not just the one who presses go.

*First published on Code Meet AI, where i write about building with AI, receipts included.*