For about two years, the unit of work with a coding agent was the prompt. You wrote a good one, gave it enough context, read what came back, and wrote the next one. The agent was a tool, and you were holding it the entire time, one turn after another.
That part is ending. In 2026, the conversation around AI-assisted operations has shifted from “How do I write a better prompt?” to “How do I design the loop that runs without me?” This is not just a semantic distinction. It is a fundamental reframing of what infrastructure engineering looks like when the machines do not merely assist—they iterate.
The Leverage Moved Up a Layer
Google Cloud’s Addy Osmani has a name for what replaces manual prompting: loop engineering. You stop being the person who prompts the agent. You design the loop that prompts it for you.
Peter Steinberger, founder of PSPDFKit, has made it a monthly reminder: you should not be prompting coding agents anymore. You should be designing loops that prompt your agents. Boris Cherny, who leads Claude Code at Anthropic, operates the same way. He does not prompt Claude anymore. He has loops running that scan issue trackers, team chats, and timelines, then decide what to build next. “My job is to write loops.”
A loop, in this context, is a goal that prompts itself. You set the purpose, and the system keeps iterating until it is met. In practice, it finds the work, hands it out, checks the result, writes down what got finished, decides the next thing, and pokes the agent instead of you. You build that small system once and let it run.
Strip loop engineering down and you get roughly five building blocks:
- Automations are the heartbeat. They are what make a loop an actual loop and not one run you did once. A scheduled task, a CI job that keeps running after you close the laptop, or a hook that fires at a point in the agent’s lifecycle.
- Worktrees keep parallel work from turning into chaos. Two agents writing the same file is the same headache as two engineers committing to the same lines. Git worktrees give each agent its own branch so edits do not collide.
- Skills are intent, written down. An agent starts every session cold. A skill records conventions, build steps, and tribal knowledge once, where the agent reads it every run.
- Connectors let the loop touch real tools. Built on MCP (Model Context Protocol), they let agents read issue trackers, query databases, hit staging APIs, and drop messages in chat.
- Sub-agents keep the maker away from the checker. The model that wrote the code is far too generous grading its own homework. A second agent with different instructions catches what the first one talked itself into.
The sixth element—often overlooked—is memory. A markdown file, a state file, anything that lives outside the single conversation and holds what is done and what is next. The model forgets everything between runs. The repo does not.
Why Infrastructure Is the Perfect Place for Loops
Most of this thinking grew up around application code, where a bad run costs you a revert. When the loop reaches into infrastructure, the blast radius is larger—but so is the verification surface.
Infrastructure hands the loop a better oracle than application code does. A plan diff is deterministic and machine-readable. A policy check returns a hard verdict. Drift and cost are numbers you can threshold. Pulumi’s Neo platform reasons over the state graph directly, so the checker grounds every claim in what the change actually does, not in what the writer says it does.
This is why platform engineering and loop engineering are converging in 2026. The platform becomes the loop’s runtime. GitOps—using Git as the single source of truth for infrastructure state—provides the memory layer that loops need. ArgoCD and Flux watch repositories and reconcile clusters automatically. The loop does not need to invent state management; it inherits it from the platform.
Consider what happens when a loop manages a fleet of Kubernetes clusters. The outer loop watches for new releases, compliance changes, or security patches. It delegates to inner loops that roll updates across clusters in stages. Each inner loop reports back: drift detected, policy passed, tests green. The outer loop then decides whether to proceed to the next stage or halt and alert a human. This is not futuristic. Teams at scale are already running variations of this today.
What the Tools Actually Ship Today
The pieces are not theoretical. They are shipping now.
Pulumi Deployments recently added tag-based triggers. Push a version tag like v1.2.0, and Pulumi automatically runs pulumi up for your stack. Your release tag is the deployment. Connect this to a loop that watches for tagged releases, runs policy checks, and opens pull requests for review, and you have an infrastructure loop that operates end to end.
GitLab Orbit provides what GitLab calls “full code and lifecycle context, in one query.” Software agents using Orbit are reportedly up to eleven times faster and use up to 4.5 times fewer tokens. The platform is becoming the context layer for agentic work.
OpenTofu 1.12 shipped with dynamic prevent_destroy, simultaneous human-readable and machine-readable output via --json-into, and provider checksum improvements. These are not features for human operators clicking through a UI. They are features for loops that need to programmatically understand what changed and whether it is safe.
Backstage 1.51 added an alpha TracingService and ExtensionPointFactoryMiddleware, letting backend extension outputs be replaced at creation time. The internal developer portal is becoming programmable infrastructure—something loops can query, modify, and extend.
Cline’s SDK—rebuilt from the ground up as a pluggable agent runtime—demonstrates that the loop abstraction is portable across surfaces. The same agent harness powers VS Code, JetBrains, and CLI. Sessions survive UI restarts. The runtime is durable and product-agnostic.
CircleCI’s Smarter Testing is another piece of the puzzle. By running only the tests that matter—those affected by code changes—it reduces CI cycle times dramatically. When a loop is making changes at machine speed, you need CI that keeps up. Running only relevant tests means the loop gets feedback fast enough to course-correct in the same session.
FluxCD’s Terraform bootstrap capabilities show GitOps reaching deeper into infrastructure management. The Terraform Flux Operator manages Terraform resources through the GitOps workflow, bringing the same declarative, version-controlled approach to infrastructure that has long governed application deployments.
Platform Engineering Meets Agentic Operations
Industry surveys suggest platform engineering will reach roughly eighty percent adoption by the end of 2026. The reason is straightforward: developers express intent, and the platform translates that intent into resources, policies, and workflows. GitOps has become the dominant control mechanism.
But the next phase is not just self-service portals and paved paths. It is platforms that can run their own loops. A developer opens an issue requesting a new environment. The loop reads the issue, validates the request against policy, provisions the infrastructure, opens a pull request with the changes, links the ticket, and pings the channel when CI goes green. The developer never touches Terraform.
This is the difference between an agent that says “here is the fix” and a loop that ships the fix, verifies it, and communicates the result.
The convergence is visible in how platform teams are restructuring. Instead of a ticketing queue for infrastructure requests, they are building APIs that loops consume. Instead of runbooks for incident response, they are writing playbooks that agents execute. The platform team becomes the team that designs and maintains these loops, curating the skills and policies that govern them.
The Risks Nobody Talks About
A loop running unattended is also a loop making mistakes unattended. The one thing that keeps it honest is verification, and verification needs an oracle—passing tests, a clean build, a green pipeline, a real production signal. Without an oracle, the loop compounds confidently wrong work faster than you can read it.
The bill comes in two currencies: tokens and attention. A single unattended run can burn through millions of tokens. The quieter trap is memory rot. The faster the loop ships code you did not write, the wider the gap between what exists in the repo and what you actually understand. Two engineers can build the exact same loop and get opposite results—one moving faster on work they understand deeply, the other avoiding the work entirely. The loop cannot tell which one you are.
There is also the question of observability. When a loop makes decisions, you need an audit trail. What did it see? What did it decide? Why? Platform engineering teams are increasingly treating loop observability as a first-class concern, building dashboards and alerts not just for the infrastructure, but for the agents managing it.
Where to Start
If you are building or operating a platform today, the transition does not require a rewrite. It requires a shift in what you automate.
Start where “done” is unambiguous. CI triage, dependency bumps, a flaky-test hunt, a failing job you keep rerunning by hand. Loops need an oracle, so begin where the oracle already exists.
Write the memory file before the loop. One markdown file, or a project board. What is done, what is next, what was tried and failed. This is the spine, and everything else hangs off it.
Split the checker from the maker. Use verifiable conditions or a second agent with its own instructions. Never let the agent that did the work be the one that decides the work is finished.
Cap it, then read everything. A maximum iteration count, a token budget, a teardown step. Run it once, end to end, then read every line it shipped. The first run is the measurement, not the payoff.
Invest in platform observability early. If you cannot see what the loop is doing, you cannot trust it. Treat loop telemetry as infrastructure telemetry—it belongs in the same pipelines and dashboards.
The Bottom Line
DevOps in 2026 is not about replacing engineers with agents. It is about replacing one-shot prompts with durable loops. The platform provides the runtime, GitOps provides the memory, and the engineer provides the judgment.
The loop will do the typing. The thinking is still the work.