--- title: Loop Engineering for CXOs: What Changes When Engineers Stop Prompting and Start Designing Loops slug: loop-engineering-for-cxos canonical_url: https://blog.juscode.co/loop-engineering-for-cxos published_at: 2026-07-05T09:00:00+00:00 author: jusCode tags: loop engineering, leadership, ai strategy tldr: Loops move engineering from a labor line to a capacity line. You stop approving each piece of work and start approving the machine that makes it, with budgets, kill switches, and audit trails. key_takeaways: - Payroll buys attention. Loops buy throughput. Engineering quietly moves from a labor line to a capacity line. - Governance inverts: you stop approving each piece of work and start approving the machine that makes the work. - Token spend becomes a real operating line item, and the metric that matters is cost per completed unit of work, not cost per token. - The risk isn't the AI. It's an unattended system without budgets, kill switches, and audit trails. Loops need change control like any production system. --- ## 259 merged contributions, zero typed by hand Late last year, the engineer who created the most widely used AI coding tool shared a number that should be in every board deck this quarter: over one 30-day stretch, every one of his 259 merged contributions to his own product was written by the tool itself, steered by loops he had designed. His summary of the new job description : "My job is to write loops." By mid 2026 this had a name, loop engineering, and a viral debate to go with it. Most of that debate is written for engineers. Almost none of it answers the questions that land on your desk: what does this do to capacity, to cost, to risk, and to what you should be measuring? That's this post. ## What a loop is, in one paragraph A loop is a small system wrapped around an AI agent. It has a trigger (a schedule, or an event like a failed build), a goal (a checkable end state, like "all tests pass"), a gate (an automated verification that decides whether the work is truly done), a memory (progress saved outside the AI), and a budget (a spending and time limit it cannot exceed). The engineer's job shifts from typing each instruction to designing that system once and letting it run, including overnight. For the technical deep dive, hand your team our anatomy of an agent loop . For this post, one property matters: the work continues when no one is watching. ## What one engineer produces just changed denominators For the entire history of software, engineering output has been bounded by attention: one person, one problem, eight focused hours on a good day. Every planning ritual you run, from headcount models to sprint velocity, silently assumes that bound. Loops break it. An engineer who designs five reliable loops has output that scales with loops times runs times success rate , while their attention moves to the two places machines can't go: deciding what's worth building, and reviewing what the loops produce. That last part deserves emphasis, because it's where naive adoption fails. Loops don't eliminate the human. They relocate the human to specification and review. The teams winning with loops didn't fire their reviewers. They made review the job. > Same engineer. The bound moves from focus hours to loops times runs times success rate. ## Payroll buys attention. Loops buy throughput. Every capacity model you own treats engineering as a labor line: output scales with people, so you plan in headcount. Loops introduce something your spreadsheet has never seen: production capacity attached to an engineering team, the way servers attach to a product. It behaves like a capacity line. It has utilization (are the loops running?), yield (what share of runs pass the gate?), unit cost (dollars per merged change, a number we derived in the previous post ), and maintenance (loops decay as codebases change). Executives who keep treating this as "developer productivity tooling" will measure it with survey scores and miss it entirely. Executives who treat it as capacity will ask the right questions within a week, because they already know how to run a factory. - **LABOR LINE** Output = people × hours: plan in headcount, measure in velocity, review every piece of work. - **CAPACITY LINE** Output = loops × runs × yield: plan in loops, measure in cost per merged change, review the system. ## You no longer approve the work. You approve the machine that makes the work. Here's the governance shift nobody briefs the board on. In a prompting world, a human touches every output before it ships, so your controls live at the output. In a loop world, output volume makes that impossible by design, so control moves one level up: to the loop itself. A loop is a production system, and it deserves exactly what your change-control process already gives production systems: a named owner, a spend budget with a hard stop, an audit trail of every run, an approval gate for sensitive actions, and a rollback plan. None of this is new machinery. It's your existing governance, pointed at a new kind of asset. The risk register entry writes itself: the danger is not that the AI is clever. It's that a system runs at 3am with no budget, no kill switch, and no log. Every loop horror story you'll hear this year reduces to one of those three absences. - Which loops run tonight, and who owns each one? - What is the stop condition on each, and can the AI fake it? - What is the per-run spend cap, and what happens when it's hit? - What was last month's cost per merged change? - What share of loop output gets human review, and who does it? If the answers come back crisp, you're ahead of most of the market. If they don't, you just found this quarter's priority. ## Four numbers that replace the old ones - **Loops in production** (count, with owners): Your new capacity inventory. Zero means you're reading about this a year early. Unowned loops mean you're reading it a year late. - **Yield** (runs passing the gate): The health of your loop designs. Falling yield means specs or gates have drifted from the codebase. - **Cost per merged change** (dollars per outcome): The unit economics. Compare against the fully loaded cost of the same change done by hand. - **Human review rate** (% of output reviewed): Your quality dial. It should start near 100 and fall deliberately, never accidentally. ## Ninety days, three moves Days 1 to 30: one loop, one free gate. Pick a workload where verification already exists and costs nothing, like fixing failing CI checks. One owner, one per-run budget, one kill switch. The goal is not savings; it's learning what a loop looks like in your audit log. Days 31 to 60: instrument. Put the four dashboard numbers on a page someone actually looks at. You cannot govern what you cannot see, and with loops you will not see it by walking the floor, because the floor is asleep when the work happens. Days 61 to 90: write the policy. One page: what a loop must have before production (owner, budget, gate, audit, rollback), who approves new loops, and which actions always require a human. Congratulations: you now govern the machine that makes the work, which is the whole game. ## For the technical appendix of your board deck - Jimenez et al., 2024. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (ICLR 24). How the field verifies agent work: real test suites, not self-report. The intellectual basis for gated loops. arXiv:2310.06770 - Yao et al., 2023. ReAct: Synergizing Reasoning and Acting in Language Models (ICLR 23). The research origin of the loop cycle your teams are now industrializing. arXiv:2210.03629 Part of our loop engineering series: The Anatomy of an Agent Loop · Loops Are Layer 04 · The Cost of a Loop . Next and last in the series: why loop engineer is shaping up to be the job title of 2026 H2. ## FAQ ### Does this reduce headcount? It redeploys attention before it reduces anything. The bottleneck moves from producing work to specifying it and reviewing it, and both of those are senior skills. Organizations that treat loops as a layoff tool discover that firing the reviewers is firing the quality control of an unattended factory. The near-term effect is the same people shipping considerably more, with the mix of their day changed. ### What's a realistic expectation for the first quarter? One loop in production with clean unit economics and a boring audit log. That sounds modest until you notice what it proves: your organization can safely operate work that happens while everyone sleeps. Scaling from one governed loop to twenty is an engineering exercise. Getting from zero to one governed loop is the organizational change. ### How do we keep quality without reviewing everything? Two mechanisms. First, gates that can't be sweet-talked: the field's own benchmarks judge agent work by whether real test suites pass, not by the model's self-assessment [1]. Second, the human review rate as an explicit dial: start at 100 percent, lower it per loop as its track record earns trust, and never let it hit zero for consequential actions. ### Is this only an engineering story? Engineering went first because its verification is free: compilers and tests are gates nobody has to build. But the pattern, goal plus gate plus budget, applies to any work with a checkable definition of done: reconciliations, report generation, data pipeline repair, compliance checks. Wherever your organization can define done, it can eventually run a loop.