The Prompting Paradigm Is Ending
Most developers still interact with AI the same way they interact with a search engine: type a question, get an answer, move on. Ask it to write a function. Ask it to explain an error. Ask it to draft a commit message. One shot, one response, next task.
That pattern made sense when LLMs were autocomplete engines. It makes less sense now that they can hold context across thousands of tokens, call tools, write files, run tests, and check their own output. We've been treating sports cars like grocery carts.
The shift that's happening — quietly, in the work of a handful of researchers and practitioners — is from prompting to looping. From one-shot requests to systems that run autonomously toward a goal, iterate when they hit failures, and report back when they're done.
This is not a distant capability. It's available today. The tooling is already in your editor.
What a Loop Actually Is
At its simplest, a loop is an AI workflow that runs more than once. But the interesting version is more specific: a loop is a system with a target state, an action, and a check.
- The target: "this test suite passes"
- The action: "write or modify code to make progress"
- The check: "run the tests and see if we're done"
If the check fails, the loop iterates. If the check passes, the loop exits. The AI is not just answering a question — it's driving toward an outcome and self-correcting along the way.
This is fundamentally different from prompting. Prompting says "give me your best answer." Looping says "keep working until you get it right."
The Spectrum of Loop Complexity
Not every loop needs to be a multi-day autonomous agent. There's a spectrum, and different points on it are useful for different tasks.
Experiment-Driven Systems
At one end are research-oriented loops — systems designed to explore a space and report findings. Andrej Karpathy's Auto Research project is a clean example of this pattern: a loop that generates hypotheses, runs experiments, evaluates results, and synthesizes insights. The human sets the research question; the system does the iterative work of testing it.
A related idea is parameter golf: automated sweeps that try combinations of model parameters, prompts, or configurations against an evaluation function, looking for the best-performing setup. Instead of manually tuning a prompt for two hours, you define what "better" means and let a loop find it overnight.
These systems share a structure: a search space, a scoring function, and a loop that navigates toward better scores. They're particularly powerful for tasks where the right answer is hard to specify in advance but easy to recognize in hindsight.
Interval-Based Automations
In the middle of the spectrum are automations triggered on a schedule. Claude Code ships a /loop command that does exactly this — run an AI task every N minutes (default: every five minutes).
/loop 5m "check the issue tracker and triage anything new into Linear"This turns your AI assistant into something closer to a daemon: a background process with ongoing responsibility for a task. The examples that work well here are things that would be tedious to do manually but are clearly defined:
- Inbox triage: Scan a YouTube channel's comment inbox or support queue and sort items into a project management board, tagging by priority and category.
- Doc generation: Every time a new file is committed, summarize it and update the project's auto-generated documentation.
- Vulnerability scanning: At a regular interval, run a security scan against new code and file issues for anything that looks like an injection vector, exposed secret, or insecure default.
- Daily summaries: At end of day, pull together what was committed, what issues were closed, and what's still open, and write a standup-ready summary into a shared doc.
The common thread is repetitive, well-defined work that doesn't need creative judgment but does need consistent execution. Exactly the kind of thing that drains humans and doesn't drain machines.
Goal-Oriented Long-Running Tasks
At the far end of the spectrum are goals: tasks with a clear success condition that may take hours or even multiple sessions to complete. Claude Code's goal feature is designed for exactly this. You define the outcome, the agent works toward it autonomously, and it stops when it gets there.
A parser is a good example. Say you're building a parser for a binary protocol spec. The success condition is clear: a test suite that validates the parser against known-good inputs and catches malformed ones. You hand the agent the spec, the test stubs, and a /goal directive:
/goal build a parser for the v2 message format. success = all tests in parser.test.ts pass. use the spec in docs/protocol-v2.mdThe agent writes code, runs tests, reads failures, updates the implementation, re-runs, and iterates. If it hits something it can't resolve — an ambiguity in the spec, a test that seems wrong — it surfaces the question rather than guessing and moving on.
What makes this different from just asking for code is the built-in verification loop. You're not reviewing an AI-generated file and hoping it's right. You're specifying what "right" means in runnable code, and the agent is obligated to prove it before calling the task complete.
Building Memory Into Loops
One pattern worth highlighting is using loops to build persistent context over time. The interval-based daily summary isn't just about reporting — it's a form of external memory.
Each day, a loop captures: what changed, what decisions were made, what's still unresolved. Over weeks, this becomes a searchable record of why the codebase looks the way it does. New team members can query it. The AI can reference it in future tasks. The project accumulates institutional knowledge rather than letting it evaporate.
This is the "continual learning" use case: not fine-tuning the model, but building a structured knowledge base that the model can access. The loop does the writing; humans and AI do the reading.
Where This Breaks Down
It's worth being honest about the failure modes, because they're real.
Loops need good exit conditions. A loop without a clear success check will either run forever or stop arbitrarily. The /goal pattern works because "all tests pass" is unambiguous. Vaguer goals like "improve the codebase" create agents that thrash rather than converge.
Long-running tasks lose the why. When you delegate an outcome to an agent and come back hours later, the intermediate decisions are buried in the session log. The code works, but you may not understand why it was structured the way it was. For anything architecturally significant, you want checkpoints — moments where the agent surfaces its approach before diving into implementation.
Interval loops can accumulate noise. If your triage loop misfires for two days and mis-categorizes a hundred issues, you have a cleanup problem. Rate-limit and audit your automations, especially early on.
Models can get stuck. Agents hitting errors in a loop sometimes get into patterns where they repeat the same failed fix. Good loop design includes a circuit breaker — if the agent hasn't made progress in N iterations, it escalates rather than spinning.
How to Start
The shift from prompting to looping doesn't require a new infrastructure investment. Start with what you have:
Use /goal for your next well-defined task. Pick something with a clear output that can be verified by tests or a known-good output file. Let the agent work. Evaluate the result. If it gets stuck, look at where it stopped and tighten the success condition.
Set up one interval automation. Pick a repetitive task from your current workflow — something you do every day that feels mechanical. Write a loop prompt for it. Run it for a week and see what breaks.
Define your success conditions before you start. This is the discipline that makes loops work. "Build me a parser" is a prompt. "Build me a parser where parser.test.ts passes" is a goal. The test file is the spec; everything else is implementation.
The underlying shift is from AI as an answering machine to AI as a coworker with delegated responsibility. That requires more upfront thought about what you actually want — but it pays out in leverage that one-shot prompting never will.
The /goal and /loop commands are available in Claude Code today. If you're using Kodo, the same patterns apply — set a goal, define a verification step, and let the loop do the work.