Your Team Doesn't Need to Learn to Prompt. It Needs to Define “Good.”

The quiet thing the best AI operators stopped doing

The most important change in how people work with AI this year didn't arrive as a model release or a product launch. It arrived as an absence. Sometime in June, the people who use AI most seriously started saying, out loud, that they had stopped doing the thing everyone else is still scrambling to learn. They stopped writing prompts.

That deserves a second read, because it inverts the entire "learn to prompt" industry that has grown up over the last three years. The prompt — the carefully engineered instruction, the thing every course and cheat-sheet and LinkedIn thread has been optimizing — is being quietly retired by the exact people who were best at it. Not because prompting stopped working. Because they found something that sits one level above it.

They started writing loops. And once you understand what replaced the prompt, you understand something more useful than any prompting technique: the last thing a human writes is no longer the instruction. It's the definition of good. That single shift changes what your people need to learn, what your best hires are actually for, and — if you run a company — what your own job becomes. This piece is about that shift, where it came from, and why it lands hardest not on your engineers but on you.

Where this came from — and who said it first

An honest argument names its sources, so let me lay out the lineage before building on it, because bosio is standing on other people's shoulders here and it would be cheap to pretend otherwise.

In early June 2026, Addy Osmani — who spent fourteen years at Google and now directs AI developer experience at Google Cloud — published a piece called "Loop Engineering." He named the practice and systematized it, and he was careful to credit the people it was emerging from. A day later, Peter Steinberger, the developer behind OpenClaw, posted the two-line version that made it a phenomenon.

It went viral — and, worth noting, the reaction split hard. A large share of the responses called it premature or overstated. Hold onto that; a field arguing with itself in real time is more interesting than a settled consensus, and we'll take the objections seriously later.

The line that gave the idea its authority came from inside Anthropic. Boris Cherny, who leads Claude Code, described his own workflow in a June 2026 talk in words that have been repeated everywhere since: "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." (The exact venue and phrasing vary across retellings; we're citing it as it was popularized rather than claiming a single definitive transcript.)

And the piece that packaged all of this for people who run businesses rather than repositories was Shelly Palmer's "Write Loops, Not Prompts," on June 28. Palmer's definition is the cleanest, and it's the hinge for everything that follows: "Loop engineering designs the conditions under which the system can keep working until the answer is good enough to use."

Read that last clause again — good enough to use. That is the whole story hiding in plain sight. Somebody has to define "good enough." That somebody is you.

What a loop actually is (and why the prompt vanishes)

Strip away the vocabulary and a loop is not exotic. It's a running process that hands the AI a task, checks the result against some standard, and — if the result falls short — sends it back around to try again, adjust, or gather what it was missing, until the output clears the bar or hits a limit. The human isn't in the middle typing the next instruction. The human set the thing in motion and defined when it's allowed to stop.

Compare that to prompting. A prompt is a single turn: you ask, the model answers, you read the answer and decide what to type next. You are the loop. Your attention is the thing that carries the work from one step to the next, judges each output, and decides whether to push further. That's why prompt engineering became a skill — you were hand-operating the feedback cycle, one message at a time.

Prompting makes you the loop — your attention carries the work from one step to the next and judges each result. Loop engineering takes you out of that middle seat. The machine runs the cycle; you no longer author the next instruction. What you author instead is the standard the machine is looping toward.

Here's the consequence almost everyone misses. When you automate the loop, the individual prompts stop being something a human writes — the system generates them, on the fly, in response to what it finds. The prompt dissolves into the machinery. It becomes an internal, disposable artifact, like a compiler's intermediate code. Nobody saves it. Nobody perfects it. And so the skill that everyone spent three years building — crafting the perfect instruction — quietly stops being the thing that matters.

What's left for a human to write is the part the loop can't generate for itself: the definition of when the output is good enough to stop. The bar. The standard. The rubric. That is not a smaller job than prompting. It is a different, and frankly harder, one — and it's the one that was always the actual work.

The reframe: the rubric is the artifact now

This isn't only a coding-world observation, and it isn't only Palmer's. It's a convergence, and the two labs with the most to gain from more AI usage arrived at it independently — which, precisely because they're interested parties, is worth noting rather than hiding.

In November 2025, OpenAI published its case that evals — structured definitions of what a good output looks like — function much like product requirement documents: they take a fuzzy goal and make it specific, explicit, and checkable. Two months later, in January 2026, Anthropic went further and said the quiet part directly. In its engineering guidance on building AI agents, it stated that the people closest to the product and the users — not the engineers — are "best positioned to define success," and that writing evals early "forces product teams to specify what success means." Anthropic even encourages non-engineers — product managers, customer-success people, salespeople — to contribute the definitions of good, because they're the ones who actually know what good is.

Sit with what that means, because it's the reframe the whole piece turns on. The durable artifact of AI work is no longer the prompt, the code, or even the output. It's the rubric — the written, explicit definition of what "good" means for a given piece of work. Everything downstream of it can be automated. It cannot. And it can only be written by someone with the judgment to know what good actually is.

The durable artifact of AI work is no longer the prompt or the output — it's the rubric: the explicit definition of what "good" means for the work. Everything downstream of it can be looped and automated. The rubric can't. It's the one input that still requires a human who knows what good actually is.

We've made a version of this argument before, when two Anthropic engineers reframed the field around building skills instead of chasing agents, and again when we described what a genuinely self-improving AI system looks like from the inside. This is the next turn of the same screw. Skills taught the system your expertise. Loops let it run on that expertise without you. And what you're left holding — the thing that was always yours — is the judgment about whether the result is any good.

Why this is a leadership problem, not a prompting problem

Here is where most coverage of "loops not prompts" stops, treating it as a developer-tooling story. That's the part bosio thinks is wrong, and it's the part that matters most if you run a company.

If the scarce, un-automatable input is the definition of good, then the bottleneck in an AI-driven organization is not prompting skill. It's judgment. It's the ability to say, with precision, what a good proposal, a good hire, a good analysis, a good customer response actually looks like — and to stand behind that definition when the system produces something that technically complies with it but obviously misses the point.

That is not a skill you send your team to a workshop to acquire. It's the thing leadership was always supposed to be. And it reframes the entire anxiety most executives carry about AI. The worry has been: I don't understand the tools well enough; I need to learn to prompt. The truth is closer to the opposite. You don't need to learn to prompt. You need to do the harder thing you may have been avoiding — to define, explicitly and in writing, what good looks like in your business, once, so a system can execute against it a thousand times.

The executive anxiety about AI has been "I need to learn to prompt." The real shift is the opposite: you don't need to learn to prompt — you need to define, in writing, what good looks like in your business, once, so the system can run toward it a thousand times. AI adoption was never a skill problem. It's a leadership problem wearing a technical costume.

This is why we keep insisting AI adoption is a human problem, not a tooling one. The company that wins the agentic era isn't the one with the most prompt-fluent staff. It's the one whose leaders can articulate the standard — and whose organization has written those standards down where a machine can run against them. Most companies have never done this. Their definition of "good" lives in a few senior people's heads, applied by feel, never made explicit. That was a tolerable inefficiency when humans did all the work by hand. It is a hard ceiling on everything the moment you try to let AI loop. This is the same territory we mapped when we described what separates the companies that see real AI ROI from the ones that don't — the organizations that pull ahead are the ones where humans sit above the loop, owning the standard, not inside it running each step.

What this looks like from inside a firm that runs loops

We don't write this from theory. We run our own firm on the thing we're describing, so let me show you one loop concretely — because the abstract version ("let AI run loops") is exactly where it goes wrong, and the specific version is where the lesson lives.

Every week, the operating system we run our own business on audits itself. Without anyone prompting it, it regenerates an inventory of its own moving parts, health-checks the routines that are supposed to run on schedule, reads back through the week's decisions, failures, and lessons, and produces a list of concrete proposed improvements — this rule should be tightened, that routine is silently broken, these two documents now contradict each other. It runs the entire investigative loop on its own.

And then it stops.

It does not change anything. Not one rule, not one routine, not one line. It hands the proposals to a human, and nothing ships until that human reads them and approves. That gate is not a technical limitation we haven't gotten around to removing. It is the point. The loop generates the candidates; a person supplies the judgment about which ones are actually right. The machine runs the loop. The human owns the rubric.

What does the human actually catch at that gate? Almost never errors of fact — the system is better at those than we are. What it catches are errors of fit. Most weeks, a few of the proposals get declined, and rarely because the system was wrong that something could change. It's because the system optimizes for what it can see — consistency, tidiness, resolving a contradiction between two documents — and it cannot feel what it can't: that a rule we look "inconsistent" about is inconsistent on purpose, because the exception is exactly where our judgment lives; that a change is a genuine improvement and also not worth the disruption this month; that a tidier process would quietly remove the friction that keeps a human in a decision we don't want automated. None of those are data problems. They're taste, timing, and knowing what the firm is actually for — and none of it lives in any log the loop can read. The loop is a tireless analyst who has read everything and understood the business's character not at all.

That's not a knock on the tool; it's the precise shape of the division of labor, and it's the same shape it will take in your business. An AI loop will reliably propose the locally optimal move — the thing that's cleaner, faster, more standardized in isolation. What it cannot do is know when locally optimal is globally wrong for you: when the "inefficiency" it wants to remove is a deliberate choice, when "faster" costs you something that doesn't show up in the metric it's optimizing. Catching that is judgment, and judgment is the rubric applied in real time. Which is why the gate isn't bureaucracy. It's where the value concentrates.

That division of labor is doing something specific and worth naming. The system is genuinely good at the parts that are conceptual and mechanical — noticing drift, cross-referencing, drafting, checking consistency. It is not the thing that should decide whether a proposed change is wise, because wisdom about our own business isn't in the training data; it's in the felt, accumulated sense of what this firm is for. The most valuable thing a human does in that loop takes about twenty minutes a week, and it is pure judgment. Everything else — the hours of scanning and drafting — the machine does. That ratio is the future of a lot of knowledge work, and it is not a demotion of the human. It's a concentration of the human into the one place a human is irreplaceable.

The objections — taken seriously

A thesis this clean invites suspicion, and it should. The strongest pushback against "loops not prompts" is real, and an honest piece has to meet it rather than route around it.

"This is just cron with extra steps." The most cutting version of the critique is that a loop is nothing new — it's a scheduled process plus a decision-maker, and we've had scheduled processes since the 1970s. That's fair, and it's worth conceding cleanly: the loop itself is not the innovation. The innovation is where the human moves. Old automation looped through deterministic steps a human had fully specified in advance. What's new is that the steps are now generated by a system reasoning about an open-ended task, which means the human can no longer specify the steps — only the standard the steps are judged against. The novelty was never the loop. It's that the definition of good became the last human input standing.

The economics don't obviously favor loops — especially for you. This is the objection that matters most for a mid-market company, and the evangelists rarely mention it. A loop that runs unattended can consume dramatically more compute than a single well-crafted prompt, and unpredictably so — it burns tokens every time it goes around, and it goes around more when the task is hard or the edge cases pile up. For a large lab with effectively unlimited budget, that's a rounding error. For a company watching its AI spend, "just build a loop" can be more expensive and less predictable than a sharp prompt written by someone who knew what they wanted. The honest guidance is not "loop everything." It's: loop the work that genuinely repeats and where the definition of good is stable enough to be worth writing down. A rubric you'll use a thousand times pays for itself. A rubric for a one-off doesn't.

A wrong rubric is worse than a wrong prompt. This is the deepest objection, and it cuts toward something we've written about before. When a human ran every step, a bad instruction produced one bad output the human immediately saw and corrected. When a loop runs against a flawed rubric, it produces a thousand outputs that all technically satisfy the definition while missing what actually mattered — and it does so confidently, at scale, without anyone in the loop to feel that something is off. This is the same failure mode as AI that tells you what you want to hear: a system optimizing a proxy for good rather than good itself. It is precisely why the rubric can't be a form someone fills out to check a box. Writing a good rubric is an act of judgment, and judgment is exactly the human capacity that doesn't survive being rushed or outsourced. Which is the whole argument, arriving from the other direction: the more the machine loops, the more everything depends on the quality of the one thing only a human can write.

And it isn't settled. The field is openly arguing about how real and how premature this is. We're not claiming the debate is over. We're claiming the direction is clear enough that a leader should start preparing for it now — because the preparation (learning to define good, in writing) is valuable whether or not every workload ends up in a loop.

What to actually do about it

If the rubric is the artifact, then the work in front of a leadership team is not "get everyone prompting." It's four different moves.

Stop grading prompt skill. Start writing standards. The internal metric that matters is not how clever your people's prompts are. It's whether the recurring, high-value judgments in your business have been written down as explicit definitions of good — the kind a reviewer, a new hire, or a machine could apply and get the same answer you would. Most of that lives in senior heads today. Getting it out of those heads and onto the page is the highest-leverage AI-readiness work you can do, and none of it requires a single line of code.

Pick the work that repeats, and define good for it — once. Don't try to rubric the whole company. Choose the handful of processes that run constantly and where the standard is stable: the proposal, the first-draft analysis, the customer reply, the weekly report. Write down, precisely, what makes each one good. That written standard is what makes it safe to let AI loop on that work — and it's reusable a thousand times.

Put your judgment at the gate, not in the middle. The lesson from running loops ourselves is that the human belongs at the approval boundary — reviewing the proposal, owning the yes — not hand-operating each step. Design the human role as the one who defines good and approves against it, and free them from the mechanical middle the machine now handles. That's where the twenty-minutes-of-pure-judgment ratio comes from. This is the same architecture we described when we mapped what responsible enterprise agent deployment actually requires — human control at the boundary, not friction in the middle.

Keep the rubric a living thing. A definition of good written once and never revisited becomes a definition of good that's slowly wrong. The strongest version of this practice treats the rubric as the thing you actively maintain — the artifact your best people invest in — while the loop handles everything downstream. The rubric is where your competitive judgment now lives. Protect it accordingly.

The part that's actually yours

Strip everything else away and here's what the shift is really telling you. For three years, the story of AI at work was about acquiring a skill — prompting — that would let you operate the machine. That story is ending. The machine can operate itself now; it runs the loop.

What it cannot do is know what good looks like in your business, for your customers, against your standards. That knowledge isn't in any model. It's in the accumulated judgment of the people who've done the work and can feel the difference between an output that complies and an output that's right. The great irony of the most automated moment in the history of work is that it hands the most human capacity — discernment — back to the humans, and makes it the thing everything else depends on.

So the last thing you write is not a prompt. It's the rubric. It's the definition of good. And writing it well was always the job — AI has just stripped away everything else until that's the only thing left in your hands. The leaders who see that clearly won't be asking their teams to get better at talking to the machine. They'll be doing the harder, older work of deciding, precisely, what they're willing to call good — and standing behind it when the machine takes them at their word.

Frequently Asked Questions

What does "write loops, not prompts" actually mean?

It means moving from single-turn instructions (you ask, the AI answers, you decide what to ask next) to designing a self-running process where the AI keeps working — trying, checking, adjusting — until the output meets a standard you defined. The term "loop engineering" was named by Addy Osmani (June 2026) and popularized by Peter Steinberger and Anthropic's Boris Cherny; Shelly Palmer translated it for business audiences. Once the loop runs, individual prompts are generated by the system, so the human's job shifts to defining when the output is "good enough to stop."

If AI runs the loop, what's left for people to do?

Define "good." When the AI generates and runs its own prompts, the one thing it can't author for itself is the standard it's working toward — the rubric. Anthropic's January 2026 engineering guidance states that the people closest to the work are "best positioned to define success." So the scarce human input becomes judgment: articulating, in writing, what a good result looks like, and approving against it.

Is this just automation / cron jobs with new branding?

Partly, and that's a fair critique. A loop is a scheduled process plus a decision point, which isn't new. What's new is where the human sits: old automation ran steps a human fully specified in advance; a modern loop generates its own steps by reasoning about an open-ended task, so the human can only specify the standard, not the steps. The novelty isn't the loop — it's that "the definition of good" became the last human input.

Should a mid-market company put its AI work into loops?

Selectively. Loops can consume far more compute than a single prompt, and unpredictably — for a budget-conscious company, "loop everything" can be more expensive and less predictable than a well-crafted prompt. The guidance: loop the work that genuinely repeats and where the definition of good is stable enough to write down. A rubric you'll reuse a thousand times pays for itself; a rubric for a one-off doesn't.

What is a "rubric" or "eval" in this context?

It's an explicit, written definition of what a good output looks like for a specific task — specific enough that a reviewer, a new hire, or a machine could apply it and reach the same judgment you would. OpenAI (November 2025) compared evals to product requirement documents. The shift this article describes is that the rubric — not the prompt or the output — is becoming the durable, human-authored artifact of AI work.

Why is this a leadership issue rather than an IT one?

Because the bottleneck becomes judgment, not tooling. Defining "good" for the proposals, analyses, and decisions your business runs on is a leadership act — most of that standard currently lives unwritten in senior people's heads. Getting it explicit is the highest-leverage AI-readiness work, and it requires business judgment, not technical skill. AI adoption reframes as a leadership problem wearing a technical costume.

What's the risk if we get the rubric wrong?

It's the sharpest risk in the whole shift. A bad prompt produces one bad output you catch immediately; a bad rubric produces a thousand outputs that technically satisfy it while missing what mattered — confidently, at scale, with no human in the middle to notice. It's the same dynamic as sycophantic AI optimizing a proxy for "good" instead of good itself. That's exactly why writing the rubric is an act of judgment, not a box-ticking exercise — and why it stays human.

Sources

• Shelly Palmer (2026). Write Loops, Not Prompts. shellypalmer.com, June 28, 2026 — "designs the conditions under which the system can keep working until the answer is good enough to use."
• Addy Osmani (2026). Loop Engineering. addyosmani.com, June 7, 2026 — named and systematized the practice; credits Cherny and Steinberger.
• Peter Steinberger (@steipete) (2026). X post. X.com, June 8, 2026 — the viral "design loops that prompt your agents" provocation.
• Anthropic Engineering (2026). Demystifying evals for AI agents. anthropic.com, January 9, 2026 — "the people closest to product requirements and users are best positioned to define success."
• OpenAI (2025). How evals drive the next chapter in AI for businesses. openai.com, November 2025 — evals framed as product requirement documents.
• TechCrunch (2026). The AI world is getting "loopy". techcrunch.com, June 22, 2026 — context on the loops moment.
• The New Stack (2026). Coverage of loop engineering and Claude Code. thenewstack.io, 2026.
• Anthropic (2026). Claude Sonnet 5. anthropic.com, June 30, 2026 — context on the model generation Claude Code's loop workflows run on.