MLog
Back to posts
AI生成#AI编程#Loop Engineering#AI Agent#开发工具

Prompt Engineering Is Dead in 2026 — How Loop Engineering Is Reshaping AI-Assisted Coding

Published: Jul 21, 2026Reading time: 6 min

In June 2026, Google Cloud AI Director Addy Osmani's 'Loop Engineering' concept ignited the AI coding community. This article traces the four paradigm shifts from Prompt to Loop Engineering, breaks down the five core components, and discusses the boundaries and risks of autonomous coding loops.

A Quiet Paradigm Shift

In the second week of June 2026, Addy Osmani, Director of AI at Google Cloud, published a blog post titled Loop Engineering. Within days, it crossed 6.5 million views.

He said something that made a lot of people pause: "You no longer prompt your coding agent directly. You design the system that prompts it for you."

Boris Cherny, the creator of Claude Code, was even more blunt: "I no longer prompt Claude directly. I run loops that prompt Claude and decide what to do next. My job is now writing those loops."

What made this land so hard was that it declared an era over. Prompt engineering — the skill that defined AI practitioner competence just two years ago — is being replaced by a different way of working.

Four Paradigm Shifts: Incrementally Handing Over Control

To understand why Loop Engineering matters, we need to trace the evolution of AI coding over the past two years. This was not a sudden mutation. It was a clear progression.

First Generation: Prompt Engineering

Developers wrote every instruction by hand, telling the AI what to do line by line. The bottleneck was obvious: people who wrote good prompts produced massively more; people who wrote bad prompts were worse off than not using AI at all. AI didn't close the gap between people — it widened it.

Second Generation: Context Engineering

Developers stopped writing isolated prompts and began systematically designing context: which files to include, which rules to inject, how to describe the project structure. The core move was engineering the act of "teaching AI to understand the project."

Third Generation: Harness Engineering

Developers started orchestrating multiple AI calls into workflows — one agent generates code, another reviews it, a third runs tests. Akshay, a former Lightning AI engineer, captured it perfectly: "A raw LLM is just a CPU without memory and a hard drive. Harness is the operating system — it manages memory, I/O, and drivers."

Fourth Generation: Loop Engineering

Harness is passive: you trigger it, it runs. Loop is active: it decides when to trigger itself, evaluates its own output, fixes its own mistakes, and writes what it learned back to persistent storage — waiting for the next wake-up.

The key shift: the human moves from the operator's console to the design table. You no longer operate the AI directly. You design the rules that operate the AI.

The Five Core Components of Loop Engineering

Addy Osmani breaks Loop Engineering down into five components, plus one memory storage mechanism. Both Claude Code and OpenAI Codex now have all five.

1. Automations

This is the heartbeat of the loop. You create an automation task: pick a project, write a prompt, set the frequency. It runs in the background on a schedule, filing problems into a triage inbox and archiving clean runs automatically.

Claude Code's /loop runs at fixed intervals. Its /goal command runs continuously until a verifiable condition is met. Codex has the exact same mechanism under the same name.

2. Worktrees

Once you run multiple agents, file conflicts will break things. Git Worktree solves this: independent working directories on separate branches built from the same repository history. One agent's changes never collide with another's.

3. Skills

Skills free you from explaining your project from scratch in every session. A folder containing a SKILL.md file with instructions, conventions, build steps, and hard-won lessons. Write it once, and it loads automatically every time.

4. Plugins and Connectors

Connectors built on the MCP standard let loops read issue trackers, query databases, call staging APIs, and message Slack. This upgrades the loop from "can only touch the file system" to "can interact with your actual tools."

5. Sub-agents

The most important structural design decision: separate the executor from the reviewer. The model that writes code is too lenient when grading its own homework. A second agent with different instructions — sometimes even a different model — catches what the first one rationalized away.

What a Typical Loop Looks Like

Wire these components together, and a single execution flow becomes a small control panel. Addy Osmani describes his common pattern:

An automation runs every morning against a repository. Its prompt invokes a triage skill that reads yesterday's CI failures, open issues, and recent commits, writing the analysis to a file. For every actionable item, it creates an isolated worktree, dispatches a sub-agent to draft a fix, and sends a second sub-agent to review that draft against the project's skills and existing tests.

Connectors let the loop automatically create PRs and update ticket status. Anything the loop cannot handle lands in a triage inbox for manual review. A state file tracks what was attempted, what passed, and what remains — so tomorrow's run picks up where today's left off.

You designed once. You didn't issue a single per-step instruction.

What Loops Still Cannot Do for You

Loops change how you work, but they don't remove you from the work. Addy Osmani calls out three risks explicitly:

Verification is still on you. An unattended loop can make mistakes unattended. "Done" is a claim, not a proof.

Comprehension debt. The faster a loop delivers code you didn't write, the wider the gap between your codebase and your actual understanding. Unless you read what the loop produces, an efficient loop only accelerates the accumulation of this debt.

Cognitive surrender. When the loop runs autonomously, it's tempting to stop thinking critically and accept whatever it produces. The exact same loop mechanism can produce opposite outcomes: one person uses it to accelerate work they deeply understand, another uses it to avoid understanding entirely. The loop cannot tell the difference. You can.

Final Thoughts

Loop Engineering is not a lazier shortcut. It's a shift in where the work happens — from writing instructions to designing systems.

Addy Osmani gave the best advice: "Go build the loop. But build it like an engineer who intends to stay one, not someone who just learned where the start button is."

This might be the most important rethinking of AI-assisted coding in 2026. Prompt engineering hasn't disappeared, but it's no longer what separates great developers from the rest. The people designing loops are picking up the new ticket.