Prompt Engineering Is Dead. Long Live Loop Engineering.

The quote that shattered the illusion

A few days ago, a single quote from Boris Cherny — the engineer leading the development of Claude Code at Anthropic — quietly sent shockwaves through the software community.

On a public panel, Cherny pulled back the curtain on how the people who build the world’s most sophisticated coding AI actually work with their own models. What he said didn’t just challenge the status quo — it declared an entire emerging discipline obsolete:

Let that sink in.

The man with both hands on the wheel of the best developer model in the world is telling you he took his hands off the wheel. He doesn’t sit in a chat window crafting the perfect paragraph of instructions. He writes code that forces the AI to talk to itself, judge its own mistakes, and fix them inside a closed, autonomous circuit. He builds the machine that steers the model — and then he lets it drive.

If you’re still spending your days fine-tuning prompts to coax the right block of code out of an LLM, his message is brutally clear: you’re optimizing a world that is already gone.

The paradigm shift: from micromanagement to system architecture

To see why this is a tectonic shift, look at how our relationship with generative AI has evolved in just a couple of years.

Phase 1 — The linear prompt (the human bottleneck)

Until recently, the whole industry was obsessed with prompt engineering. We treated LLMs like brilliant but easily-distracted junior developers. The workflow was linear, fragile and entirely manual:

you prompt  ─▶  AI writes code  ─▶  you find the bug  ─▶  you fix the prompt  ─┐
     ▲                                                                          │
     └─────────────────────────  by hand, again  ◀─────────────────────────────┘

In this paradigm, the human is the bottleneck. You write a prompt, read the output, spot a syntax error, paste it back into the chat, and pray the model hasn’t forgotten the context five steps later. It feels productive. It is exhausting, unscalable micromanagement — and it absolutely cannot run while you sleep.

Phase 2 — Loop engineering (the autonomous circuit)

What Cherny is describing is loop engineering — agentic workflows where the human steps out of the execution loop entirely. You stop driving the car. You build the track, and let the machine run the laps.

Instead of writing a prompt to solve a problem, you write a programmatic loop that embeds the AI inside an automated cycle of execution and verification:

1. The goal. A human sets one high-level objective — “build this API endpoint and reach 98% test coverage.”
2. The action. The AI generates a first draft of the code.
3. The verification. An automated environment — compilers, linters, unit tests, your CI — runs the code and catches every error.
4. The self-correction. On a failure, the system captures the stack trace, feeds it back to the AI as a fresh instruction, and orders it to try again.

you set the goal
     │
     ▼
AI writes code  ─▶  CI runs every check  ─▶  green?  ─▶  ✦ shipped
     ▲                      │
     │                      ▼  (red)
     └──  AI reads the logs and re-prompts itself

The loop runs at machine speed, churning through dozens of iterations, self-correcting and self-healing until the verification criteria are met. You never typed a single follow-up. You didn’t write the prompts — you built the track, and the model ran every lap by itself.

The real skill isn’t writing code. It’s writing the judge.

Here’s the part almost everyone misses — and it’s the whole game. The hard part of a loop is not generating the code. Models are already frighteningly good at that. The hard part is the thing that decides whether the code is any good.

Give the loop a strong, ruthless verifier — real tests, static analysis, a compiler that refuses to lie — and it converges on something that genuinely works. Give it a weak one, and that exact same loop will cheerfully produce an infinite river of confident, beautifully-formatted garbage, hallucinating its way to a green checkmark that means nothing.

So the skill of the next decade isn’t prompt-craft. It’s designing the verification — the bulletproof validation systems that let an AI safely talk to itself without driving off a cliff. That’s a harder, rarer and far more valuable kind of engineering than finding the right words.

From philosophy to production: how we architected the loop

While the rest of the tech world breaks down Cherny’s quote on social media, the real challenge is unglamorous: how do you build loop-engineering infrastructure that actually works in production — outside Anthropic’s internal labs?

Close a loop around a single model and you hit the real-world walls fast: context-window degradation, hallucinatory death spirals, and no memory across a project. At Fractera, we spent the last year treating Cherny’s philosophy not as a prediction but as an architectural blueprint — and built the loop this workspace runs on.

The anatomy of a production-grade loop

To make loops viable for real software, you have to stop admiring the model and start building the three unglamorous things around it — the judge, the memory, and the hand that ships:

• A verifier that cannot be sweet-talked. The judge is not a second model with an opinion; it is a set of scripts that fail the build. Do the language signals exist on every public page? Does every post have the markdown twin an AI reader needs? Is a picture referenced that nobody committed? Each check exists because that exact defect shipped once, and each one answers with an exit code rather than a paragraph.
• Memory that outlives the session. The amnesia effect is real: loop fifteen times on a stubborn bug and the agent loses the architecture. Here the memory is not a service that can be offline — it is files beside the code that travel with the repository: the working instruction, the lessons appended the moment the owner corrects something, the list of anti-patterns, the confirmed user cases. A new session starts by reading them, so the fifteenth iteration knows what the first one learned.
• A closing act that does not belong to the agent. The loop ends in the control panel: it builds the project, keeps a journal of deployments and can return to the last working build. Settings, texts and images change there with no rebuild at all — so the loop is never asked to solve what was never a code problem.

Notice what is not in that list: a swarm of models supervising each other. That was our first architecture, and we removed it. Orchestration is the most exciting part of an agentic diagram and the least load-bearing part of a working one — a weak judge is not fixed by adding a second opinion, and a strong judge rarely needs one.

The software engineer’s new job description

We’re moving away from writing code, past writing prompts, and straight into building cognitive pipelines. The craft is no longer the instruction — it’s the system the instruction runs inside.

And it isn’t free. Two new costs arrive with the loops. Comprehension debt: when an agent writes and rewrites a file three hundred times behind the scenes, your grasp of your own codebase quietly erodes — it works, you’re just no longer sure why. And raw compute: a loop can burn real money in tokens chasing one bug across a hundred silent attempts. The engineers who win this era treat cost-versus-quality as a deliberate design decision, not a surprise on the invoice.

The era of prompt engineering is officially behind us. The only question left is the one Cherny already answered for himself: are you still trying to talk to your AI — or are you building the loops that let it run?

Source: a widely-shared LinkedIn post by Guillermo Flor surfacing Boris Cherny’s remarks. The quote is reproduced as it circulated; the architecture and the analysis are our own.