Engineers stopped prompting their AI. Content teams should too.

Loop engineering is the shift the best AI teams are obsessing over right now. Here's what it means for content — and how we've started running our own loops at Frase.

If your timeline looks anything like mine lately, it's packed full of engineers discussing loops.

The phrase doing the rounds is "loop engineering." Peter Steinberger, who founded PSPDFKit, put it most cleanly: you shouldn't be prompting your coding agents anymore — you should be designing the loops that prompt them. He's not a lone voice. Addy Osmani, an engineering leader at Google, wrote the guide on it; Boris Cherny, who leads Claude Code at Anthropic, has said much the same. Half of engineering on X is nodding along. It can read a little like jargon to those less in the know. But it isn't. It's the biggest change in how people actually work with AI since ChatGPT launched, and it's already starting to make waves in content and marketing. (Spoiler: content loops are the core of how Frase is built.)

So — what is it, why did it hit code first, and what does it mean for marketers.

Loop engineering, in one line

Most people use AI the slow way. You type a request, wait, read the answer, fix it, ask again. Every step runs through you. The AI is a tool in your hand, and the second you stop pushing, it stops.

A loop flips that. You hand the AI a goal and a way to know when it's done, and it runs the steps itself: work out what's needed, do it, check its own result against the goal, fix the weak part, repeat — until it clears the bar or hits a limit you set. You log off. The work keeps going.

Read that list again, because one word in it does all the lifting. Check. Verify. Every engineer in that conversation lands on the same point: the verifier is the key element. Without a hard test — does it pass, yes or no — you don't have a loop. You have an agent nodding along to its own work, which it'll happily do until your bill runs out. Look at Ralph, a coding-agent loop from engineer Geoffrey Huntley — a cheerfully crude technique that's barely more than the same prompt run over and over in a bash loop. It ships real software, but only because a test sits inside the loop to fail the bad passes. Take the test out and it just gets confidently, expensively wrong.

So a solid gate is very much a key component in any sophisticated loop.

Why this happened to code first, and not to us marketers

Loops took off quickly in engineering because code is easier to check. A test passes or it fails. There's no arguing with red or green. The agent always knows whether it's done, so you can walk away and trust it to run.

Content never had that. "Is this blog post any good?" has always been a judgment call — taste, or a senior editor's gut. And you can't build a loop around a judgment call. That's the real reason "AI content" has meant in part a flood of mediocre drafts nobody asked for: people wired up the make half of the loop and skipped the check half, because there was nothing to check against. An agent grading its own writing is the most generous grader alive.

That's the gap closing. The moment content has an objective gate — a score a page either clears or doesn't, before it ever goes live — the same loop the engineers are running becomes available to the rest of us. Not as a metaphor. As an actual workflow.

The five pieces, translated for content

Engineers break a real loop into a handful of parts. Almost all of them map straight onto content work — and, since this is the thing we build, straight onto how Frase already runs.

The verifier is the one that matters — the gate that fails the work automatically. For code it's the test suite. For content it's a score a page has to clear before it publishes: whether it's genuinely answer-ready, whether it'll hold up in search and in AI answers. In Frase that gate is literal. A page isn't flagged ready until it's cleared every item on the publish checklist, the way a build won't ship until the tests go green. No gate, no loop. This is the piece content was missing, and it's the one to get right before anything else.

Then a maker and a checker that aren't the same model. The agent that wrote the thing is far too kind about it. Split the writer from the reviewer (one drafting, a stricter one grading) and you catch the things the first one talked itself into. Most of your quality lives in that separation. The part people get wrong is how much rope to give the checker on day one. We treat it like a new junior hire: at first it proposes and you approve everything, because you haven't seen its work yet. Once it's earned it, you loosen the reins; let it handle the low-stakes fixes itself and only wave you down for the calls that actually need you.

That loosening is a dial, not a switch — which is where the next two pieces come in, and in Frase they're the same feature.

A loop needs a heartbeat (something that keeps watching after you've moved on) and connectors (so it acts, instead of just telling you what it'd do). Content Guard is both. It watches your published pages, catches the handful quietly slipping in Google or AI answers, and then does something about them — surfaces the fix for your approval, or, when it's the kind of low-risk change readers never notice (a meta description, a page title), publishes it itself. You set how far that autonomy runs: everything waits for you, or the safe stuff ships on its own, or you draw the exact line by hand. The junior colleague again with as much rope as you've decided it's earned.

Last, a skill: the rules saved once (your brand voice, what's on-brand, the brief) so the loop reads them every run instead of you pasting a wall of context each time.

The traps the engineers already hit — they're worse for us

The one upside of arriving late is you get to skip the expensive mistakes. Two of them apply double to content.

First, what they call cost per accepted change — the only number that actually matters. Not how much the loop produced. How much you kept. If an agent hands you ten posts and you bin six, you're doing the review work the loop was meant to save, and you'd have been better off writing three by hand. Content teams are about to learn this the way engineering already did: volume isn't the metric. Accepted, published, still performing in three months — that's the metric. And that's why your gates and verifications (both human and AI) are so important.

Second, the build order, and this one is critical. Get one run working by hand. Then save it as a repeatable skill. Then wrap it in a loop with a gate and a stop condition. Then (and only then) put it on a schedule. Jumping straight to "automate it" before you've proven it once by hand is exactly how you wake up to a hundred published pages and a mess.

What we're actually doing with this at Frase

At Frase, this isn't just theory for us — the whole product is built on the loop, so we've been living inside one for a while. And, of course, the Frase marketing team uses Frase to run our very own marketing loops.

Nothing gets published here until it clears a score. That's our gate, and it settles arguments that "does this feel good enough?" never could. Our content doesn't get forgotten the day it ships, either — Content Guard is running on it, meaning manual analysis of old content or scheduled, time-consuming, bi-annual updates are no longer needed. Instead, we get handed the articles that are slipping down the rankings exactly when it's happening, along with a fix ready to improve them.

And the SEO agent I wrote about last week, wired into Claude over MCP? That's a loop too. It's the maker half, with the score as its checker.

None of it is the heavy engineering rig. We don't have fleets of agents and a token budget the size of a salary. We've got a solid gate, a couple of loops that run after we publish, and a rule that we prove a thing by hand before we let it run on its own.

Where this leaves you

If you take one thing from the engineers, take this: the loop was never the final point. The check was. They got there first only because code came with a check built in. Content now has that too. So the real question isn't "should we use AI to make content" — everyone already does, often badly.

It's the two things the engineers sorted for themselves first:

• what fails your work before it ships
• what keeps watching it after.

Answer those and you've built a loop delivering genuine value. Skip them and you've built an expensive way to publish things nobody keeps.

We built Frase around those two answers, so take my bias as read. But you can assemble it anywhere. Just don't run the maker without the checker — that's the whole lesson, and it cost the engineers a lot of tokens to learn it.