Loop Engineering, and Why a New "X Engineering" Keeps Showing Up

My feed's been flooded with loop-engineering posts lately. Most of them are just Twitter threads run through a translator—here's the concept, here are the technical details.

They somehow manage to feel like hype and be unreadable at the same time. So I'd rather start from what I've actually been building at work and talk about loop engineering as plainly as I can.

I'd been doing this kind of thing for about a month before anyone called it "loop engineering." When the term finally showed up, it felt oddly fitting—the work I was already doing now had a name.

01 What loop engineering is

The term has two halves, loop and engineering. Start with loop.

A loop is simple enough: take the work that repeats, over and over, and hand it to AI to run on its own. When I started, that was the whole ambition—get the repetitive parts of my job off my plate.

Engineering is the part that makes the loop hold up. It's what keeps AI hitting the bar of "me doing it myself" on every pass, even as the inputs keep shifting and it runs into things it's never seen.

Here's the gap it closes. Turn even the strongest model loose and the first results drift all over the place—call it 20 or 30 out of 100. Put in the engineering and you can get to 80 or 90, and hold there, run after run. That's what finally takes the repetitive work off your hands for good.

02 The two loops I built

Over the past month I built two of them.

An automated data-analysis loop, to cover for not having a data analyst on the team. It runs on three cadences—daily, weekly, and monthly:

• Daily: core product metrics, new-subscriber cases and analysis, churned-user cases and analysis, and so on.
• Weekly: the weekly report—data overview, user composition, segment drill-downs, how product changes moved the numbers and why—plus token-cost analysis, and so on.
• Monthly: the monthly report, month-level cost analysis, and so on.

An Agent self-iteration loop, to cover for an algorithm test engineer who'd just left. It started as a benchmark harness and grew into something like this:

benchmark run → AI reads the server logs from bad cases and low-scoring tests to find bugs on its own → define tasks and priorities by each bug's blast radius and severity → each task yields a fix proposal and a spec → a human signs off on the bug and the proposal → AI writes the fix → another round of benchmark verification

That whole pipeline.

None of it was easy to build—it earned the "engineering" in loop engineering. A good loop really is an engineering problem.

03 How to build a good loop

So, concretely, how? Here's the workflow I pulled out of building those two.

Step 1. Break each stage into the smallest unit that can run on its own.

Any piece of work is a chain of stages. Take a simple analysis task: how did last week's product changes move the core metrics? To write that report, you need at least three things:

• What shipped last week
• What the core metrics are
• How to turn the changes plus the data into a report worth reading

Those three are the smallest executable units of the task.

Step 2. Teach AI by hand, and iterate each unit until it's actually good.

The catch is that the simpler and more familiar a step is to you—pulling some number under a particular definition, say—the more details you skip when you hand it off, and the worse AI does with it. Walking through the same three:

• What shipped last week. You could automate this end to end by reading the changelog off the repo's PRs. Let AI do it cold, though, and it drowns in code detail and can't lift the changes up to a product view. So the PM has to sit with it and align, round after round, until the feature log matches how you actually think about the product—how code maps to features, what each feature is for, which core metrics it moves. Put another way: you have to spell out the code → feature → metric chain as explicitly as you can, write it down as a knowledge base in the repo, and keep it current.
• What the core metrics are. AI needs to know what the metrics are and why they matter, how each one is defined and computed, and which column in which table it comes from. And since AI is usually the one pulling the numbers now, checking them matters more than anything—it has to return the same figure you'd have gotten by hand, every time. (Anthropic has a good piece on this, How Anthropic enables self-service data analytics with Claude.)
• Writing the report itself. You'd think stacking the first two steps is enough for a solid draft—it gets close, but something's usually still off. You still have to tell AI the drill-down dimensions for each metric, how to segment and bucket, where the supporting numbers come from. And the writing needs rules too: lead with the conclusion, how to break up sections, how to use headings, what evidence each claim has to stand on.

Polishing every one of these to something near your own bar is, honestly, close to handing over every trick you've picked up—the deliberate ones and the ones you don't even notice you do.

Step 3. Wire the stages together, and keep a human in the loop wherever AI can't clear the bar or real judgment is needed.

The data-analysis loop is easy: once it's running, I'm rarely pulled back in. The Agent self-iteration loop—or any product self-iteration loop—is a different story. Almost every round still needs a person.

If there's a right answer, hand it over. That's the data loop: pull, compute, format to spec, and the output checks out against hard numbers. So I can walk away.

If there's no right answer, or it's genuinely complex, keep a human in. In the self-iteration loop, once it produces a proposal for changing the Agent, I review it and make the call. Partly because AI's proposals tend to tunnel on "fix the problem in front of me." But also because designing an agent usually isn't only an engineering or algorithm question—it's a product question, sometimes a business one. You're constantly trading off agent generalization, product impact, and token cost to land on what fits the product right now. That's rarely a clean answer; it's a balance. And the call comes down to your taste for the agent and the product.

People assume that as models get stronger, every step eventually goes to AI. But on the calls that are pure trade-offs with no right answer, the human doesn't drop out of this self-evolving loop—and shouldn't.

Finally: actually start, and a few things to watch.

Before you turn anything into a loop, forget the vocabulary you think you have to study first—subagent, worktree, hook, all of it. How to use them is AI's job; let it call them.

Once you've told AI what you want, there are only three things left to mind:

• Write everything to files. Whatever the loop touches, have AI save it into the project. That pile of files is your knowledge base, and it compounds.
• Get it working before you make a skill. Build the skill after the loop runs, not on day one.
• Keep iterating. As you ship features, keep sanding down the loop.

Scheduling is up to you: put the fixed-time jobs on a timer, fire the rest by hand. Since every task is its own smallest unit, you can trigger any single one of them whenever you need.

04 Why a new "X engineering" keeps appearing every so often

Beyond the hands-on stuff, I want to use loop engineering as a way into a bigger question: why, since last year, a new "X engineering" shows up every few months.

Line them up against model releases and the pattern is hard to miss—each new "X engineering" lands right after a new model raises the ceiling.

So I don't think "X engineering" is just buzzword-mongering. Every time models get more capable, people point them at new kinds of work, and in the process they map out where that model's limits are. Getting a model to perform reliably in those new places—and to actually lift efficiency and output—takes real engineering: the work of dragging it from 20 to 80 or 90 so it does the job the way you need.

Eventually that scaffolding gets absorbed into the model itself, and it just handles those cases more and more naturally.

Which is why people half-joke that "if you don't learn it now, you won't have to in a while"—and they're not entirely wrong. But it doesn't mean prompt, context, or harness stopped mattering. If anything, the opposite: the system prompt is still one of the most important parts of any agent. It just shouldn't be hand-typed character by character anymore—AI already writes a better one than we do.

As for the accounts that declare "X is dead" and "X is back" every time a new term drops—not worth the breath. Unfollow and move on.

05 Closing thoughts

Loop engineering is a precondition for models getting good at long-horizon work. And it nudges us one step closer to AI that can own an entire job function end to end—more on its own, and at higher quality.

As models keep climbing, new "X engineering" terms will keep coming. From here to "AGI," we might be just one or two of them away.