« I don’t write prompts anymore. I build loops. »

Several major figures in AI have been repeating some version of this sentence for a few months now, and it’s worth pausing on.

Boris Cherny, the creator of Claude Code, explained in an interview that he barely writes prompts himself anymore. His work now consists of building loops — systems that generate and execute their own prompts, autonomously.

Peter Steinberger, creator of Open Claude (one of the most followed general-purpose agents right now), goes further. On X, he sums up the idea in one line: we shouldn’t « prompt » an agent anymore, but design the loops that drive it automatically.

And then there’s Andrej Karpathy, with his Auto Research project: a system that runs experiments, evaluates the results, adjusts its own behavior, and starts again — until it reaches a goal set in advance.

Three different signals, one direction. So are we witnessing the end of Prompt Engineering… or the birth of a new paradigm, Loop Engineering?

To answer seriously, we first need to understand where we came from.

When everything came down to Prompt Engineering

In the beginning, interacting with an LLM was simple:

You’d ask a question — « What color is the Ferrari? » — and the model would answer from its internal knowledge. The whole challenge was framing that answer well: defining a role (« you are a lawyer, » « you are a front-end developer »), giving precise instructions, illustrating with examples (the famous few-shot prompting), fine-tuning the system prompt.

This discipline has come a long way. System prompts published by some vendors now run to tens of thousands of tokens, with rules, examples of good and bad answers, and detailed guardrails. Prompt Engineering was never a gimmick — it was, and still is, a solid foundational skill.

But this approach had a structural limit: it only worked for one-off tasks, with no interaction with the outside world.

Then came agents: Context Engineering

The shift happened when models gained access to tools: files, the web, APIs, the MCP protocol.

The model is no longer just an answer box: it becomes an agent capable of reading, searching, writing, calling functions. Every interaction with a tool fills up its context window — that working memory which bounds what the model can « see » at any given moment.

Frontier models today handle up to a million input tokens. A comfortable margin, on the surface. Except a well-documented phenomenon complicates everything: context rot. Past a certain threshold (often around 200,000 tokens), the model’s performance degrades noticeably — too much information, too much noise, and the model starts « getting lost » in its own context.

Context Engineering is precisely the art of managing that scarce resource: compacting, summarizing, keeping the context as clean as possible to preserve response quality.

Harness Engineering: getting an agent to work for hours

The next problem came naturally: some tasks are too big to fit in a single context, even repeatedly compacted.

Take a concrete example: « Clone the Ferrari website. » A task like that involves structure, components, multiple pages — impossible to handle in one block, even with an XXL context window.

The answer is called Harness Engineering: instead of endlessly summarizing the same context (with the quality loss that implies), you build an external scaffolding that breaks the task into subtasks, with checkpoints and persistent memory — usually stored in Markdown files (CLAUDE.md, agents.md, history logs).

Each step resets the working context, but the agent picks up exactly where it left off, by re-reading its own notes. This has become the foundation of nearly all modern autonomous agents, including the long-term memory systems found in today’s best general-purpose agents.

What if the agent could work all on its own?

Before going further, let’s be honest about one thing: we’ve already been running loops for a while, without necessarily calling them that.

The very first one is us. When we send a prompt, wait for the answer, then follow up with a new request — « fix that, » « go further, » « try a different way » — that’s already a loop. A loop with a human inside it, closing the cycle each round. It’s the one we know best, the one from pure Prompt Engineering: we ourselves are the mechanism that triggers the next iteration.

Context Engineering has one too, a quieter one. When the context window fills up and the model summarizes, compacts, then keeps working before compacting again a bit later — that’s a cycle running to keep the context manageable, even if nobody calls it a « loop » at the time.

And then there are the two we saw above: when an agent calls a tool, gets a response, then calls another one to complete its answer, that’s a loop. The model cycles through its own tools until it has enough to go on. And Harness Engineering, with its subtasks chained one after another toward the overall goal, is another one.

So in reality, we never stopped looping — whether it was us holding the pen, or the model managing its own context, or the agent chaining its subtasks.

Loop Engineering isn’t about inventing some brand-new loop from scratch. It’s about taking all of this existing machinery — the manual follow-up, the context compaction, the tool-calling that loops, the harness that loops over its subtasks — and taking it out of the human’s hands to enclose it, in turn, inside one encompassing, autonomous loop. A loop over a loop over a loop.

What really changes is that we stop treating the agent as someone we need to walk through every step. We no longer feed it a series of prompts, one after another, waiting for it to finish before telling it what to do next. Instead, we give it, just once, three things:

• a goal — the « what »: what we actually want to achieve
• constraints — the « how »: the limits to respect along the way
• a stopping condition — the « until when »: the signal that tells it it’s done

And from there, we let go. A single event triggers the full cycle — tool calls included, compaction included, harness subtasks included — the agent executes, checks for itself whether the result holds up, notes down what it learned somewhere so it doesn’t start from zero next time, and starts again. All on its own, cycle after cycle, with no need for us to go back over it every round.

Why this is a real break

For years, we worked with an LLM like this:

Me → Prompt → Answer → New prompt → Answer → New prompt → ...

In plain terms: me, sitting at my screen, relaunching, correcting, refining, starting over. At every step, I’m in the loop. I am the loop, really. The model waits for me to tell it what to do next, and I spend my time playing go-between, between the idea in my head and the result it hands me.

With Loop Engineering, the pattern becomes:

Me → Goal → Autonomous agent

And this apparent simplicity hides a real shift in posture. I’m no longer the one giving instructions as I go. I’m the one who sets the frame once — « here’s what I want, here are the limits, here’s how you’ll know it’s done » — and then lets the system run without hovering over it.

This doesn’t just change day-to-day comfort. It changes the job. An AI Engineer doing Loop Engineering no longer writes a conversation prompt by prompt: they build a system that can evaluate itself, correct itself, and keep moving forward even when nobody’s watching.

It’s a bit like moving from being the driver to being the engineer who designs the self-driving car. You’re no longer the one driving the route — you’re the one who designed the system capable of doing it correctly, on its own, all the way to the destination.

Three concrete examples

Application maintenance. A GitHub issue automatically triggers an agent that diagnoses, fixes, tests, and opens a pull request — without a human writing a single « fix this bug » prompt.

Code optimization. Goal set: execution time under 100 ms. The loop modifies, tests, measures, starts again — until it succeeds or runs out of a maximum number of attempts.

Content generation. Goal: reach 300 reactions on a LinkedIn post. The loop publishes, measures the results afterward, learns, adjusts the format of future posts.

This last example illustrates a particular, very instructive case: delayed ground truth. The outcome of an action (a post, an ad campaign, a deployment) can’t be measured immediately — sometimes it takes several days. The loop is then triggered at regular intervals (« every morning, look at the results of previous posts and adjust your strategy »), rather than continuously.

The real challenge: evaluation

This whole system only works if success is measurable. That’s where the real difficulty of Loop Engineering lies.

There are roughly five levels of verification, from simplest to trickiest:

• Deterministic verification: the code compiles or it doesn’t, true/false.
• Numeric rules and constraints: latency under 100 ms, accuracy above 90%, memory usage capped.
• Delayed ground truth: the result exists, but can only be measured later (engagement, customer satisfaction).
• LLM-as-a-Judge: the model evaluates its own output — for example, comparing the visual rendering of a cloned page to a reference image, until it reaches a satisfactory similarity score.
• Human checkpoint: when none of the above is enough, it’s the human who validates or invalidates each iteration.

The further down this list you go, the less Loop Engineering can run in full autonomy — and the more it becomes necessary again to have a human, or an external judge, in the loop.

This is exactly why a goal like « make a viral post » doesn’t work as-is: « viral » is neither deterministic nor quantifiable. It has to be reframed into something measurable — « reach 300 reactions » — for the loop to make sense.

My take

No, Prompt Engineering isn’t dead.

But it has become a baseline skill — a prerequisite, not a job in itself. Just as knowing how to write a clean SQL query doesn’t make you a data engineer.

The skill that’s actually emerging today is the ability to design systems capable of working, evaluating themselves, and improving on their own — by defining verifiable goals, clear constraints, and stopping conditions that avoid infinite loops and runaway token bills.

Tomorrow, the best AI Engineers will be the ones who know how to design the best loops.

One question remains open, and I’d genuinely like your take in the comments: is Loop Engineering a real new paradigm, or just a new name for orchestration concepts we’ve already been practicing for years?