The people best at AI just stopped prompting
Boris Cherny leads the team at Anthropic that builds Claude Code. He is, by any reasonable measure, one of the best-positioned people on earth to be good at prompting. Here is how he described his own workflow this year: "I don't prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops."
An OpenAI engineer said the same thing within weeks. By summer, the practice had a name — loop engineering — and a small canon of essays behind it. The shift is real: the most advanced AI users no longer craft instructions and read outputs. They design systems that do the work, check the work, fix the work, and only interrupt a human when something genuinely needs judgment.
Every word written about this so far is addressed to software engineers. The examples are API migrations, test suites, and code backlogs. Which leaves a strange gap: the people who run marketing, sales, and operations — the people whose teams produce recurring, checkable deliverables all day long — have not been told that the game changed.
This piece closes that gap. Loop design is not a technical skill. As I will argue, you already know how to do it. You have been doing a slow, expensive version of it your entire management career.
You already know this — it's called management
Strip the engineering vocabulary away and a loop is a familiar thing: delegation with a written definition of done.
Think about what you do when you delegate work to a person. You set an objective. You explain what a good result looks like. You hand over the procedure, or trust them to know it. They bring you a draft; you review it against your standard; you send it back with notes. After a round or two it passes, and if something comes up that neither of you anticipated, it lands on your desk as an exception. Eventually the lesson gets folded into how the team does it next time.
That is a loop. Every part of it maps one to one:
| The loop | You already know it as |
|---|---|
| Goal | The objective |
| Done-Test (the eval) | The definition of done — the standard you review against |
| Worker | The SOP — the procedure that does the job |
| Iteration rule | The review cycle — draft, notes, redo |
| Escalation | Exception management — what lands on your desk |
| Write-back | The process update — what the team learns |
| Owner and cadence | Accountability — whose name is on it, and when it runs |
You already run loops. You run them on people, slowly, at meeting speed. Loop design is the act of writing your management practice down precisely enough that an AI can run it on itself — draft, check, fix, and re-check in minutes instead of days, and come to you only with the exceptions.
The anatomy of a loop
A designed loop has six parts, plus one wrapper that makes it an organizational asset rather than a personal trick.
1. The goal. The outcome, stated as a testable claim. Not "improve our case studies" — "every closed-won enterprise deal has a publishable case-study draft within two weeks." If you cannot tell whether the goal happened, it is a wish, not a goal.
2. The Done-Test. What good looks like, written down before the work starts. This is what engineers call an eval, and it is the part that changes everything, so it gets its own section below.
3. The worker. The procedure the AI runs — what I have called a skill in earlier pieces: a documented, versioned way of doing the job. A loop without a defined worker is just hoping out loud, repeatedly.
4. The iteration rule. The engine: do the work, check it against the Done-Test, feed the failures back as instructions, and try again — up to a set number of rounds. This is the part people miss when they treat AI as a one-shot tool. The first draft is not the product. The loop is the product.
5. Escalation. The rule for stopping. When the work cannot pass the Done-Test — a fact is missing, a claim cannot be sourced, a judgment call exceeds the loop's authority — the loop stops and routes the problem to a named human, with a precise statement of what is missing. A loop that never escalates is either doing trivial work or hiding its failures.
6. The write-back. Where the lesson lands. When a human resolves an escalation, the answer gets written into the knowledge base, the skill, or the Done-Test itself — so the next run inherits it. This is what makes a loop compound instead of merely repeat.
The wrapper: an owner and a cadence. A loop is not an experiment; it is an operating asset. It has a name on it and a schedule — weekly, per-deal, per-release. The moment a loop has an owner and a cadence, it stops being someone's clever workflow and becomes part of how the organization runs.
The eval is the whole game
Here is the uncomfortable part, and the reason most corporate AI adoption disappoints: the constraint was never prompt quality. It is that most teams have never written down what good looks like.
Working with AI well is not about being a good prompt engineer. It is about being ruthlessly clear on two things: the business outcome you want, and the criteria you would use to accept or reject the work. That second thing — the Done-Test, the eval — is a definition of done you actually committed to paper. Most teams have never done it, for anything. The standard lives in a senior person's head and gets applied in review meetings, one draft at a time, forever.
Writing a Done-Test is not technical. Four patterns cover most business work:
The checklist. Binary checks: every claim has a source; the CTA appears above the fold; no competitor is named; the legal line is present. Best for compliance-shaped work.
The rubric. Scored dimensions with a threshold: clarity 1–5, evidence 1–5, voice 1–5; ship at 4 or better on all. Best for judgment-shaped work.
The golden example. "Match the structure and standard of this one" — your best case study, your best launch brief — with the differences called out. Best when quality is easier to recognize than to specify.
The claims audit. Every number traces to a source, correlation is never written as causation, and every qualifier travels with its number. Best for anything a skeptical reader will see. If you have read my earlier work, you will recognize this — it is the discipline that runs through everything I publish.
And a force multiplier: the reviewer. A second AI, given only the Done-Test and the work, grading it cold. Separating the doer from the checker is the oldest quality trick there is, and it works just as well when both are machines.
If you can brief a junior hire, you can design a loop. An eval is just a definition of done you actually wrote down.
Three loops, worked
The real one. At my last company I ran a competitive-intelligence loop in production. Trigger: weekly. Workers: AI agents that swept roughly 24 competitors — pricing pages, reviews, product announcements, positioning language. Done-Test: an adversarial verification pass that checked every claim against its source before anything was published. Escalation: a human reviewed what went in, so the repository stayed accurate rather than just large. Write-back: the run refreshed the sales battlecards and the data sources behind the reps' AI assistants. Nobody prompted anything on Monday mornings. The loop ran, the field stayed current, and humans touched only what needed judgment. That system is why I trust this method: I did not read about it — I operated it.
The case-study factory (hypothetical, to show the shape). Goal: every closed-won enterprise deal has a publishable case-study draft within two weeks. Trigger: deal marked closed-won. Worker: a case-study procedure that drafts impact-first from the interview transcript, CSM notes, and usage data. Done-Test: the claims audit — every metric traced to a source, honest verbs, qualifiers attached; unsourced numbers are moved to a questions list, never into the draft. Escalation: the questions list goes to the account team; quote approvals go to the customer. Write-back: every approved metric joins a reusable proof library. Iteration: up to three passes before a human sees it. What used to be a quarter's backlog becomes a standing capability.
The launch-comms QA loop (hypothetical). Goal: no release ships with notes a reader can't act on. Trigger: release candidate cut. Worker: a release-notes procedure that classifies changes and writes per-audience notes. Done-Test: a checklist — breaking changes first, action stated for each affected audience, terminology matches the docs, no behavior announced that the source notes don't establish. Escalation: every ambiguity returns to engineering as a written question. Write-back: each resolved question updates the product glossary. The eval is doing the work a senior editor used to do at 6 p.m. the night before launch.
Both hypotheticals use procedures I have published free in the PMM Skill Stack — the point is not the specific tools, it is that the workers already exist for much of GTM work. What is missing in most orgs is the loop around them.
What the COO sees: loops are auditable, prompting is not
Here is the organizational case, for the executive deciding what "AI adoption" should mean this year.
Individual prompting — even skilled prompting — is invisible productivity. It lives in personal chat histories. It cannot be audited, inherited, scheduled, or improved by anyone but its author, and it walks out the door with them. Multiply it across a department and you have real output gains with zero institutional accumulation.
A loop is the opposite kind of object. It has an owner, a schedule, a written standard, an escalation path, and a log of what it shipped and what it escalated. You can review a loop the way you review a team: is the Done-Test still right, what escalated this month, what did we write back. You can govern it — my last role included leading the AI governance task force with IT and Security, and the difference between governing "employees use chatbots" and governing a portfolio of designed loops is the difference between guessing and managing. And loops compound: every escalation resolved makes the next run smarter, which is a property no amount of individual prompting has.
The strategic question for a COO is not "are our people using AI." It is "how many of our recurring deliverables run as designed loops, and who owns each one."
Stop teaching typing
Most corporate AI training teaches prompting. Phrasing tricks, template libraries, "50 prompts for marketers." I have written before about credentialing theater — training designed to check a box rather than build a capability — and prompt training is becoming its newest wing. It is teaching typing in the age of the word processor: not wrong, just not the skill that moves anything.
The capability that moves things is the one this piece has been circling: the discipline of defining the business outcome and writing the success criteria before the work starts. Outcome definition and eval writing. That is a management skill — arguably the management skill — and it is trainable. A team that learns to write Done-Tests gets better at delegating to AI, and, quietly, better at delegating to people, because the vagueness that AI exposes ruthlessly is the same vagueness humans have been absorbing politely for years.
If I were building a corporate AI curriculum today, week one would not touch a chatbot. It would be a room of managers turning "improve our follow-ups" into testable goals and writing the checklist they would accept the work against. The AI part is the easy part.
The ladder: prompt → skill → loop
There is a maturity path here, and if you have followed my writing, you have seen its first two rungs.
A prompt is a one-shot instruction — useful, unversioned, gone tomorrow. A skill is a procedure written down — versioned, shareable, opinionated about how the job is done; that was the argument of the PMM Skill Stack. A loop wraps a skill in a goal, a Done-Test, an iteration rule, and an escalation path — and that is where AI stops being an assistant and starts being an operation. My earlier piece on competitive positioning described one loop in full before I had the vocabulary: extract the buyer's criteria, generate positioning from documented facts, escalate the unknowns to humans, write the answers back. The method was a loop. This piece is the general case.
One deliverable, one canvas
Do not start with a platform, a pilot committee, or a tool evaluation. Start with one recurring deliverable that is checkable — a weekly report, release notes, case studies, QA on anything — and design its loop on one page.
I have made that page: the Loop Design Canvas — loop name, owner, trigger, goal, Done-Test, worker, iteration limit, escalation, write-back. Free download, no gate. Fill it in with your team in an hour; the argument about what the Done-Test should say is the work, and it is the most productive argument your team will have this quarter.
If you want help with the interview, I also built a free skill that does it with you: loop-design-skill asks you the management questions — what is the deliverable, how would you judge a junior hire's version, what would make you reject it — and it will refuse to hand you a canvas until your success criteria are actually testable. It produces the completed canvas and a plain-language loop spec you can run in any AI tool your company already uses. That refusal is not a bug; it is the whole lesson in miniature.
The Loop Design Canvas
One page, nine fields, your team's first loop. The two amber fields — the testable goal and the Done-Test — are where the real work happens.
The skill that designs loops with you
Interviews you in management language, refuses vague success criteria, and outputs the completed canvas plus a runnable loop spec. Free, MIT-licensed, installs in about a minute.
The higher-leverage seat
The people best at AI stopped prompting. Not because prompting got harder, but because they found the higher-leverage seat: designing the system that does the work and knows when to ask for help. That seat does not require engineering. It requires what good operators have always had — clarity about outcomes, and the discipline to write down what good looks like.
The canvas and the skill are free, like everything else I publish. If you want this capability built in your organization rather than just read about — I design these with teams. Leave your email below, or reach me at daniel@cmoconfessions.com. No gate, no sequence.