Loop engineering is the emerging practice, popularized in June 2026 by Claude Code creator Boris Cherny, OpenAI engineer Peter Steinberger, and Google Cloud’s Addy Osmani, of designing recurring agent workflows that prompt, check, and redirect AI systems without a human typing every instruction. That sounds like a small shift in vocabulary, but it is really a change in who—or what—operates the keyboard. Prompt engineering made the user responsible for squeezing a useful answer out of a model; loop engineering makes the user responsible for building the conditions under which an agent keeps working. The stakes are obvious for developers, but they are just as real for administrators, managers, and anyone who thought AI automation would stop at the chat box.
For the first two years of mainstream generative AI, the prompt was treated as the magic spell. Better wording meant better output. Entire cottage industries formed around prompt libraries, prompt marketplaces, and “AI whisperer” advice that promised to turn vague model behavior into predictable productivity.
Loop engineering is a repudiation of that era, or at least its demotion. The prompt still exists, but it is no longer the central artifact. It becomes one part of a larger machine: a scheduled task, a repository watcher, a test runner, a second agent acting as reviewer, a connector to external tools, and a memory system that records what worked last time.
That is why Cherny’s remark lands with such force. When the person behind Claude Code says he is not mostly writing prompts anymore, but writing loops that cause Claude to prompt itself, he is describing a shift from instruction craft to workflow architecture. The human no longer stands at the console issuing commands one at a time. The human designs the conveyor belt.
This is also why the phrase has caught fire among agentic coding enthusiasts. A coding agent that waits for a single instruction is still a very fancy autocomplete. A coding agent that wakes up, inspects a repo, opens a branch, writes code, runs tests, asks another model to critique the result, and repeats until a goal is satisfied is something closer to a junior developer with a pathological appetite for tokens.
That makes loop engineering both familiar and unnerving. A script either succeeds, fails, or exits with some intelligible error. An AI agent may succeed after seven strange detours, fail while sounding confident, or produce a fix that passes tests while smuggling in a future maintenance problem. The loop gives it persistence; persistence gives it leverage; leverage gives it risk.
The current enthusiasm is strongest in software development because code provides something many other knowledge-work domains lack: a feedback harness. Tests can pass or fail. Linters can complain. Compilers can refuse to build. Git can isolate experiments. Pull requests can be reviewed. A coding loop has a way to discover that yesterday’s clever idea broke today’s build.
That is why one of the most repeated loop patterns splits generation from evaluation. One agent writes the code; another reviews it. The slogan is simple because the problem is real: the model that wrote the answer is often too generous when grading it. In human terms, this is peer review. In agent terms, it is a token-expensive but increasingly necessary guardrail.
That distinction matters because it moves AI literacy away from clever phrasing and toward systems thinking. The question is not “What should I type?” It is “What should happen every time this condition appears?” A loop can be scheduled, event-driven, or goal-driven. It can run every five minutes, every hour, whenever a ticket enters a queue, whenever a build fails, or whenever a repository changes.
For WindowsForum readers, this should sound suspiciously like the long history of automation on the desktop and in the enterprise. Task Scheduler, PowerShell, Group Policy, Intune remediation scripts, Azure Automation runbooks, GitHub Actions, and CI/CD pipelines all embody the same basic insight: repeatable work belongs in a repeatable system. AI agents simply add a new, fuzzier executor to that old pattern.
The difference is that managers are expected to handle ambiguity, while scripts are expected to obey. Loop engineering asks administrators and developers to treat AI like something in between. It is not a person, but it benefits from role definition. It is not a script, but it needs boundaries. It is not a teammate, but it can create work that other systems must verify.
Automation gives the loop its heartbeat. Without a trigger, the agent is still waiting for a human. The trigger may be time-based, event-based, or goal-based, but it is what turns a one-shot prompt into an ongoing process.
Worktrees matter because concurrency is where agentic coding gets messy. If multiple agents are touching the same repository, isolation is not a luxury. Git worktrees and branches give each agent a sandbox, reducing the chance that parallel efforts trample each other before a human or another automated check has a chance to reconcile the results.
Skills are the institutional memory of the system. They encode preferred practices, project-specific conventions, deployment rules, and domain context. A prompt can remind an agent once; a skill can remind it every time. For an enterprise, this is where internal policy and engineering culture start to become executable.
Connectors are what make loops powerful and dangerous. Once an agent can touch issue trackers, email, cloud consoles, calendars, documentation systems, shell environments, and browsers, the loop stops being a coding toy. It becomes an actor in the organization’s workflow. That is the point, and it is also the reason security teams should be paying attention.
Sub-agents provide specialization and separation of duties. One agent can implement, another can test, another can summarize, another can challenge assumptions, and another can prepare a pull request. The practical question is not whether this sounds elegant. It is whether the extra cost and complexity buy enough reliability to justify themselves.
That matters because much of the public loop evangelism comes from people operating near the frontier of AI access. Engineers at major AI labs live in a world where models are close, tokens are plentiful, and experimentation is part of the job. Most users do not live there. Most teams have budgets, rate limits, compliance rules, and managers who become very interested when automation quietly starts behaving like a new line item.
The more sensible advice is to use loops where persistence is valuable and bounded. A loop that checks a repository once an hour for stale dependencies may be reasonable. A loop that wakes every five minutes to invent work for itself across a production estate is a different creature. The first looks like automation. The second looks like an incident waiting for a ticket number.
Cost is not only financial. There is also attention cost. If a loop produces ten pull requests a day, someone or something must review them. If it comments on every issue, someone must decide whether those comments help. If it files tasks, updates docs, and proposes refactors, the organization can drown in plausible output. Automation does not eliminate work when its output becomes another queue to triage.
Loops make this worse because they add repetition and autonomy. A compromised agent session is bad. A compromised loop that runs on a schedule, reads sensitive context, and has access to external connectors is a standing invitation. It can quietly retry, adapt, and persist long after the human user has stopped watching.
This is where traditional IT instincts become valuable. Least privilege is not optional. Logs are not optional. Approval gates are not optional. Secrets should not be casually exposed to tools whose behavior depends on natural-language context. The same organizations that learned to treat macros, browser extensions, OAuth grants, and CI tokens with suspicion should bring that suspicion to agent loops.
The problem is that AI products are often marketed with the language of delegation rather than the language of control. “Let the agent handle it” is appealing. “Grant a probabilistic system recurring access to your operational substrate” is less catchy, but it is closer to what is happening. Good loop engineering will require the second sentence to be taken seriously.
What AI adds is flexibility at the edge of ambiguity. A remediation script can restart a service or clear a cache. An agent loop might inspect logs, compare a failure to recent changes, draft a fix, open a ticket, and suggest a rollback plan. That is more powerful, but also harder to validate.
This is where the near-term opportunity lies for Windows-heavy environments. Agent loops are unlikely to replace mature endpoint management overnight. They are more likely to appear first as assistants around the edges: summarizing alerts, drafting PowerShell, reviewing configuration baselines, explaining Intune policy conflicts, preparing change documentation, and checking whether a proposed script matches internal standards.
The danger is not that every admin will immediately hand production to a chatbot. The danger is that small loops will proliferate invisibly. A developer creates one to maintain a repo. A help desk lead creates one to summarize tickets. A security analyst creates one to enrich alerts. Individually, each loop looks useful. Collectively, they become an unmanaged automation layer.
That can be fine. Humans should not have to approve every trivial action if the system is well bounded. Nobody wants to manually bless every dependency check, formatting fix, or documentation update. But the phrase “human in the loop” becomes meaningless unless the industry specifies which loop and at what level of authority.
There is a big difference between a human who reviews a pull request before merge and a human who receives a weekly summary of what an agent already changed. There is a difference between an agent that can draft an email and one that can send it. There is a difference between an agent that can suggest a PowerShell command and one that can execute it across a fleet.
The next serious phase of loop engineering will be less about clever agent choreography and more about permission design. Which actions are read-only? Which require approval? Which can be performed only in a sandbox? Which are forbidden entirely? The organizations that answer those questions early will have fewer surprises than the ones that discover their policy boundaries after an agent crosses them.
Every loop still contains prompts. The difference is that they may be generated, templated, revised, chained, or hidden inside skills and agent instructions. The user no longer experiences the prompt as the main interface, but the system still depends on language to guide model behavior. The prompt did not disappear. It became infrastructure.
That shift resembles what happened to search engine optimization, configuration management, and DevOps. The early phase rewarded tricks. The mature phase rewarded process. Prompt engineering’s most useful lessons—specificity, context, constraints, examples, evaluation criteria—will survive. They will just be encoded into reusable workflows rather than typed into a chat window from scratch.
This is why the “forget prompt engineering” framing is both useful and misleading. It is useful because it tells users to stop obsessing over one-off incantations. It is misleading because bad instructions inside a loop are worse than bad instructions in a chat. A flawed prompt that runs once wastes time. A flawed prompt that runs every hour becomes policy.
The least encouraging part is the speed with which the vocabulary can outrun the practice. The AI world loves naming phases before they have stabilized. Prompt engineering, vibe coding, agentic workflows, harness engineering, context engineering, and now loop engineering all describe real phenomena, but they also serve as badges of belonging. A phrase becomes fashionable, and suddenly every automation script wants a new title.
IT pros should neither dismiss the trend nor swallow the branding whole. The underlying pattern is real: AI agents are becoming more persistent, more tool-connected, and more capable of operating without constant human prompting. That will change software development first, then operations, support, documentation, security analysis, and administrative work.
But the winning organizations will not be the ones with the most poetic terminology. They will be the ones that treat loops like production systems. They will ask what triggers them, what they can touch, how they fail, who reviews them, what they cost, and how to shut them down.
The Prompt Is No Longer the Unit of Work
For the first two years of mainstream generative AI, the prompt was treated as the magic spell. Better wording meant better output. Entire cottage industries formed around prompt libraries, prompt marketplaces, and “AI whisperer” advice that promised to turn vague model behavior into predictable productivity.Loop engineering is a repudiation of that era, or at least its demotion. The prompt still exists, but it is no longer the central artifact. It becomes one part of a larger machine: a scheduled task, a repository watcher, a test runner, a second agent acting as reviewer, a connector to external tools, and a memory system that records what worked last time.
That is why Cherny’s remark lands with such force. When the person behind Claude Code says he is not mostly writing prompts anymore, but writing loops that cause Claude to prompt itself, he is describing a shift from instruction craft to workflow architecture. The human no longer stands at the console issuing commands one at a time. The human designs the conveyor belt.
This is also why the phrase has caught fire among agentic coding enthusiasts. A coding agent that waits for a single instruction is still a very fancy autocomplete. A coding agent that wakes up, inspects a repo, opens a branch, writes code, runs tests, asks another model to critique the result, and repeats until a goal is satisfied is something closer to a junior developer with a pathological appetite for tokens.
Coding Agents Were Always Waiting for a Scheduler
The idea behind loops is not new in computing. Every sysadmin already understands the basic shape: cron jobs, CI pipelines, watchdog services, health checks, retry logic, scheduled scripts, event triggers, and background workers. What is new is that the thing inside the loop is no longer a deterministic script. It is a probabilistic agent that can read, plan, revise, and sometimes wander off into the weeds.That makes loop engineering both familiar and unnerving. A script either succeeds, fails, or exits with some intelligible error. An AI agent may succeed after seven strange detours, fail while sounding confident, or produce a fix that passes tests while smuggling in a future maintenance problem. The loop gives it persistence; persistence gives it leverage; leverage gives it risk.
The current enthusiasm is strongest in software development because code provides something many other knowledge-work domains lack: a feedback harness. Tests can pass or fail. Linters can complain. Compilers can refuse to build. Git can isolate experiments. Pull requests can be reviewed. A coding loop has a way to discover that yesterday’s clever idea broke today’s build.
That is why one of the most repeated loop patterns splits generation from evaluation. One agent writes the code; another reviews it. The slogan is simple because the problem is real: the model that wrote the answer is often too generous when grading it. In human terms, this is peer review. In agent terms, it is a token-expensive but increasingly necessary guardrail.
The Managerial Metaphor Is Doing Real Work
Claire Vo’s description of loops as a management problem is more than a tidy analogy. If prompting is asking an employee to do one task, loop engineering is writing the job description, setting the cadence, defining escalation paths, and deciding how performance will be evaluated. The user becomes less like a typist and more like an operations designer.That distinction matters because it moves AI literacy away from clever phrasing and toward systems thinking. The question is not “What should I type?” It is “What should happen every time this condition appears?” A loop can be scheduled, event-driven, or goal-driven. It can run every five minutes, every hour, whenever a ticket enters a queue, whenever a build fails, or whenever a repository changes.
For WindowsForum readers, this should sound suspiciously like the long history of automation on the desktop and in the enterprise. Task Scheduler, PowerShell, Group Policy, Intune remediation scripts, Azure Automation runbooks, GitHub Actions, and CI/CD pipelines all embody the same basic insight: repeatable work belongs in a repeatable system. AI agents simply add a new, fuzzier executor to that old pattern.
The difference is that managers are expected to handle ambiguity, while scripts are expected to obey. Loop engineering asks administrators and developers to treat AI like something in between. It is not a person, but it benefits from role definition. It is not a script, but it needs boundaries. It is not a teammate, but it can create work that other systems must verify.
The Five-Part Stack Is Really a Control System
Osmani’s breakdown of loop engineering into automations, worktrees, skills, plugins or connectors, and sub-agents is useful because it stops the conversation from floating away into vibes. Each component solves a specific operational problem. Together, they form a control system for agentic work.Automation gives the loop its heartbeat. Without a trigger, the agent is still waiting for a human. The trigger may be time-based, event-based, or goal-based, but it is what turns a one-shot prompt into an ongoing process.
Worktrees matter because concurrency is where agentic coding gets messy. If multiple agents are touching the same repository, isolation is not a luxury. Git worktrees and branches give each agent a sandbox, reducing the chance that parallel efforts trample each other before a human or another automated check has a chance to reconcile the results.
Skills are the institutional memory of the system. They encode preferred practices, project-specific conventions, deployment rules, and domain context. A prompt can remind an agent once; a skill can remind it every time. For an enterprise, this is where internal policy and engineering culture start to become executable.
Connectors are what make loops powerful and dangerous. Once an agent can touch issue trackers, email, cloud consoles, calendars, documentation systems, shell environments, and browsers, the loop stops being a coding toy. It becomes an actor in the organization’s workflow. That is the point, and it is also the reason security teams should be paying attention.
Sub-agents provide specialization and separation of duties. One agent can implement, another can test, another can summarize, another can challenge assumptions, and another can prepare a pull request. The practical question is not whether this sounds elegant. It is whether the extra cost and complexity buy enough reliability to justify themselves.
The Cost Curve Is the First Reality Check
The most obvious problem with loops is money. A human prompt costs a few seconds of attention. A loop can spend tokens indefinitely. Add multiple agents, tool calls, repository scans, test runs, summaries, and critiques, and the bill can rise faster than the quality of the output.That matters because much of the public loop evangelism comes from people operating near the frontier of AI access. Engineers at major AI labs live in a world where models are close, tokens are plentiful, and experimentation is part of the job. Most users do not live there. Most teams have budgets, rate limits, compliance rules, and managers who become very interested when automation quietly starts behaving like a new line item.
The more sensible advice is to use loops where persistence is valuable and bounded. A loop that checks a repository once an hour for stale dependencies may be reasonable. A loop that wakes every five minutes to invent work for itself across a production estate is a different creature. The first looks like automation. The second looks like an incident waiting for a ticket number.
Cost is not only financial. There is also attention cost. If a loop produces ten pull requests a day, someone or something must review them. If it comments on every issue, someone must decide whether those comments help. If it files tasks, updates docs, and proposes refactors, the organization can drown in plausible output. Automation does not eliminate work when its output becomes another queue to triage.
The Security Model Has Not Caught Up
The loop engineering boom arrives at a moment when the industry is already struggling with agent safety. Prompt injection, malicious tool output, poisoned documentation, insecure plugins, and overbroad permissions are not theoretical problems. The more an agent can do, the more attractive it becomes as a target.Loops make this worse because they add repetition and autonomy. A compromised agent session is bad. A compromised loop that runs on a schedule, reads sensitive context, and has access to external connectors is a standing invitation. It can quietly retry, adapt, and persist long after the human user has stopped watching.
This is where traditional IT instincts become valuable. Least privilege is not optional. Logs are not optional. Approval gates are not optional. Secrets should not be casually exposed to tools whose behavior depends on natural-language context. The same organizations that learned to treat macros, browser extensions, OAuth grants, and CI tokens with suspicion should bring that suspicion to agent loops.
The problem is that AI products are often marketed with the language of delegation rather than the language of control. “Let the agent handle it” is appealing. “Grant a probabilistic system recurring access to your operational substrate” is less catchy, but it is closer to what is happening. Good loop engineering will require the second sentence to be taken seriously.
Windows Shops Should Recognize the Pattern Before the Branding
For Windows administrators, the loop engineering story should feel less revolutionary than the AI industry wants it to sound. Enterprises have spent decades building loops around Windows endpoints: detect drift, apply policy, remediate configuration, report compliance, escalate failure. The tooling changes, but the operational logic remains.What AI adds is flexibility at the edge of ambiguity. A remediation script can restart a service or clear a cache. An agent loop might inspect logs, compare a failure to recent changes, draft a fix, open a ticket, and suggest a rollback plan. That is more powerful, but also harder to validate.
This is where the near-term opportunity lies for Windows-heavy environments. Agent loops are unlikely to replace mature endpoint management overnight. They are more likely to appear first as assistants around the edges: summarizing alerts, drafting PowerShell, reviewing configuration baselines, explaining Intune policy conflicts, preparing change documentation, and checking whether a proposed script matches internal standards.
The danger is not that every admin will immediately hand production to a chatbot. The danger is that small loops will proliferate invisibly. A developer creates one to maintain a repo. A help desk lead creates one to summarize tickets. A security analyst creates one to enrich alerts. Individually, each loop looks useful. Collectively, they become an unmanaged automation layer.
The Human-in-the-Loop Slogan Is Wearing Thin
AI companies have spent years reassuring customers that humans remain “in the loop.” Loop engineering complicates that promise. If the point is to stop humans from typing every prompt, then the human is no longer in the operational loop in the old sense. The human is in the design loop, the approval loop, or the exception loop.That can be fine. Humans should not have to approve every trivial action if the system is well bounded. Nobody wants to manually bless every dependency check, formatting fix, or documentation update. But the phrase “human in the loop” becomes meaningless unless the industry specifies which loop and at what level of authority.
There is a big difference between a human who reviews a pull request before merge and a human who receives a weekly summary of what an agent already changed. There is a difference between an agent that can draft an email and one that can send it. There is a difference between an agent that can suggest a PowerShell command and one that can execute it across a fleet.
The next serious phase of loop engineering will be less about clever agent choreography and more about permission design. Which actions are read-only? Which require approval? Which can be performed only in a sandbox? Which are forbidden entirely? The organizations that answer those questions early will have fewer surprises than the ones that discover their policy boundaries after an agent crosses them.
Prompt Engineering Did Not Die; It Got Buried in Infrastructure
It is tempting to declare prompt engineering dead because that makes for a cleaner story. The truth is more interesting. Prompt engineering is being absorbed into systems engineering.Every loop still contains prompts. The difference is that they may be generated, templated, revised, chained, or hidden inside skills and agent instructions. The user no longer experiences the prompt as the main interface, but the system still depends on language to guide model behavior. The prompt did not disappear. It became infrastructure.
That shift resembles what happened to search engine optimization, configuration management, and DevOps. The early phase rewarded tricks. The mature phase rewarded process. Prompt engineering’s most useful lessons—specificity, context, constraints, examples, evaluation criteria—will survive. They will just be encoded into reusable workflows rather than typed into a chat window from scratch.
This is why the “forget prompt engineering” framing is both useful and misleading. It is useful because it tells users to stop obsessing over one-off incantations. It is misleading because bad instructions inside a loop are worse than bad instructions in a chat. A flawed prompt that runs once wastes time. A flawed prompt that runs every hour becomes policy.
The Agent Era Needs Boring Engineering
The most encouraging part of the loop engineering conversation is that it drags AI enthusiasm toward boring, necessary disciplines. Scheduling. Isolation. Testing. Review. Logging. Rollback. Cost control. Permissioning. These are not glamorous, but they are how useful systems survive contact with reality.The least encouraging part is the speed with which the vocabulary can outrun the practice. The AI world loves naming phases before they have stabilized. Prompt engineering, vibe coding, agentic workflows, harness engineering, context engineering, and now loop engineering all describe real phenomena, but they also serve as badges of belonging. A phrase becomes fashionable, and suddenly every automation script wants a new title.
IT pros should neither dismiss the trend nor swallow the branding whole. The underlying pattern is real: AI agents are becoming more persistent, more tool-connected, and more capable of operating without constant human prompting. That will change software development first, then operations, support, documentation, security analysis, and administrative work.
But the winning organizations will not be the ones with the most poetic terminology. They will be the ones that treat loops like production systems. They will ask what triggers them, what they can touch, how they fail, who reviews them, what they cost, and how to shut them down.
The Loop Hype Contains a Practical Warning Label
The useful lesson from the loop engineering moment is not that everyone should immediately unleash agents across their repositories and inboxes. It is that the interface to AI work is moving from conversation to orchestration. That shift rewards people who can define outcomes, constraints, feedback, and accountability.- A loop is best understood as a recurring agent workflow, not as a better prompt.
- Coding is the first strong use case because repositories, tests, branches, and build systems provide feedback that agents can use.
- The safest loops separate generation from review, especially when code, configuration, or external systems are involved.
- Token cost, tool permissions, and review burden are practical limits, not footnotes.
- Windows and enterprise IT teams should inventory agent loops the same way they would inventory scripts, scheduled tasks, service accounts, and CI jobs.
- Prompt quality still matters, but the more important question is whether the surrounding system catches bad output before it becomes real action.
References
- Primary source: aol.com
Published: 2026-06-20T10:10:09.949455
Forget prompt engineering: 'Loop engineering' is all the rage now - AOL
Claude Code creator Boris Cherny says he doesn't "write the prompt anymore." Here's how loop engineering is changing coding.www.aol.com - Related coverage: thenewstack.io
- Related coverage: gate.com
- Related coverage: blog.dailydoseofds.com
Loop Engineering: Design the System That Prompts Agents
...explained visually.blog.dailydoseofds.com - Related coverage: escape-engineering.tistory.com
프롬프트는 끝났다, 이제는 '루프'다: Claude Code 제작자가 IDE를 지운 이유 (Boris Cherny: From Prompts to Loops)
TL;DR (요약) Anthropic의 Claude Code 제작 리더 보리스 체르니가 밝힌 프롬프트 엔지니어링의 종말과, 테스트 하네스 기반 자율 루프(Loop) 코딩 패러다임을 해설합니다. 목차 1. 프롬프트 엔지니어링의 종말과 '루프(Loops)'의 정의 2. 자율 루프의 길잡이: CLAUDE.md 가이드 파일 설정 3. 개발자의 진짜 새로운 본업: 테스트 하네스 엔지니어링 4. 다중 병렬 세션(Pa..escape-engineering.tistory.com