{"slug": "writing-loops-not-prompts-explained", "title": "Writing Loops, Not Prompts, Explained", "summary": "A growing consensus among AI coding tool users advocates for writing loops instead of prompts, shifting from manual agent steering to designing systems that automate repetitive tasks. The approach aims to free human attention for judgment and prioritization by moving repeatable execution into loops with stop conditions.", "body_md": "# Writing Loops, Not Prompts, Explained\n\nPosted June 24, 2026\n\nEverybody is suddenly saying you should be writing loops, not prompts.\n\nPeter Steinberger put it bluntly on X: you should stop prompting coding agents and start designing loops that prompt them. Boris Cherny, who leads Claude Code, has been saying a nearby thing: he does not prompt Claude directly as much anymore; he has loops doing that work. Addy Osmani wrote a good explainer calling loop engineering the move from being the person who prompts the agent to designing the system that does it instead. NeetCode has posted the same frame too, so the idea is clearly traveling beyond the people building the tools.\n\nI think the idea is right.\n\nI also think the slogan lands a little wrong.\n\nIt can sound like one more way to be behind. You learned prompting last year, and now the people spending the most time with agentic coding tools are saying the next step is to prompt less directly.\n\nThat framing is not where the value is.\n\nThe more useful version is more precise:\n\nIf you keep doing the same agent-steering work over and over, move that work into a loop, a skill, a script, a test, a checklist, a scheduled run, or a goal with a real stop condition.\n\nThat is it.\n\nIt is not really \"prompts are dead.\" Prompts are still the interface for a lot of intent. The change is that prompting is no longer only a thing you do manually, one turn at a time.\n\nYou can make the system do more of the prompting.\n\nThe question is when that is worth it.\n\n## A loop is a machine for not being there\n\nThe simplest definition:\n\n```\nloop = intent + context + action + evaluation + memory + a stop condition\n```\n\nA prompt says:\n\n```\ndo this\n```\n\nA loop says:\n\n```\nkeep doing this class of work until this condition is true,\nremember what happened,\nand stop or ask me when judgment is required\n```\n\nThat distinction matters because the scarce resource is not only model intelligence. The scarce resource is your attention inside the loop.\n\nIf you have to inspect every step, re-explain the repo, paste the same constraints, remember the same deployment checklist, rerun the same tests, and ask the same follow-up question every time, then the model may be doing the typing but you are still carrying the process in your nervous system.\n\nSometimes that is fine. Sometimes the fastest thing is still a normal prompt.\n\nBut if a task repeats, every manual steering move becomes a tax.\n\nYou pay the tax in minutes, yes, but also in context switches. You pay it in \"wait, where was I?\" You pay it in half-finished branches, tabs, chats, and little piles of almost-work. You pay it in the fact that you cannot be thinking clearly about the next judgment while you are babysitting the current execution.\n\nThe loop is a machine for not being there.\n\nNot a machine for not caring. That part is important.\n\n## The execution horizon\n\nIn my [Friday.land](https://www.friday.land/) notes I have been using the phrase **execution horizon**:\n\nthe point where your supported execution rate exceeds the rate at which you can generate, prioritize, and review good ideas.\n\nThat is the agency shift I care about.\n\nBefore that horizon, your bottleneck is execution. You have more ideas than hands. You know what should happen, but the work is too sticky. You have to gather context, make the edits, run the checks, write the update, fix the weird edge case, and remember the whole thing again tomorrow.\n\nPast that horizon, the bottleneck changes. You are no longer asking, \"Could I do this if I had more hands?\" You are asking, \"Which of these possible moves is actually worth doing?\"\n\nThat is a very different life.\n\nThis is also why the \"loops, not prompts\" thing is not just an AI coding trick. It is a general agency trick. You are trying to move your attention out of repeatable execution and toward judgment, taste, prioritization, and review.\n\nThe dream is not that the machine runs away and does everything. The dream is that the things you care about stop getting stuck behind the things you have already learned how to do.\n\n## The math\n\nHere is the basic break-even equation I keep coming back to:\n\n```\nP * N * (S + R) > F\n```\n\nWhere:\n\n`F`\n\nis the time or money to build the loop or foundation.`N`\n\nis the number of future tasks that benefit.`S`\n\nis the attention saved per task.`R`\n\nis the risk or failure cost avoided per task.`P`\n\nis the probability the loop actually works and keeps being used.\n\nThe loop is worth building when the expected future savings are larger than the cost of building it.\n\nThis sounds obvious, but it helps separate two common failure modes.\n\nThe first is \"automate everything.\" If the work happens once, if the evaluator is weak, or if the model is bad at the task, the loop may cost more than it returns.\n\nThe second is \"I can do it faster myself.\" Sometimes that is true. But the question is not only whether you can beat the loop once. The question is whether you want to keep paying the same attention tax forever.\n\nExample:\n\n```\nF = 90 minutes to write a shipping skill\nS = 10 minutes saved per PR\nR = 5 minutes of avoided CI/review thrash per PR\nP = 0.8 because the skill is simple and likely to keep being used\n```\n\nBreak-even:\n\n```\n0.8 * N * (10 + 5) > 90\nN > 7.5\n```\n\nSo if you expect to ship eight PRs through that workflow, the skill is probably worth it.\n\nAnother example:\n\n```\nF = 4 hours to make a daily repo triage automation\nS = 25 minutes saved per workday\nR = 10 minutes of avoided \"I missed this\" cleanup\nP = 0.7 because automations drift\n```\n\nBreak-even:\n\n```\n0.7 * N * 35 > 240\nN > 9.8\n```\n\nTen workdays. After that, the expected savings exceed the setup cost.\n\nThe continuous version is the same idea:\n\n```\nNetSaved(T) = integral from 0 to T of lambda(t) * P(t) * (S(t) + R(t)) dt - F - M(T)\n```\n\nWhere:\n\n`lambda(t)`\n\nis how often the task class shows up.`P(t)`\n\nis the probability the loop still works at time`t`\n\n.`S(t)`\n\nis attention saved per task.`R(t)`\n\nis risk avoided per task.`F`\n\nis upfront build cost.`M(T)`\n\nis maintenance cost over the time window.\n\nLoops decay. Tools change. Repos change. Models change. Your taste changes. That is what `M(T)`\n\nand `P(t)`\n\nare for.\n\nThis is also why \"write loops\" is not automatically good advice. A loop with a weak evaluator, high maintenance cost, and low recurrence is just a more expensive prompt.\n\n## Minecraft understood this years ago\n\nThe best metaphor is still vanilla Minecraft.\n\nAt first you wander around punching trees.\n\nThen you make tools.\n\nAfter a while, you stop treating wood as a wandering-around problem. You collect saplings. You replant them near your base. You make the resource renewable and local.\n\nYou still have to cut the trees down. That is the important part. The point is not that the game suddenly hands you infinite wood. The point is that you removed the repetitive part: walking farther and farther from base, searching for another forest, losing time to the same setup cost every time you need a basic material.\n\nThe work did not disappear. The loop got shorter.\n\nThat is a better metaphor for most agent automation than the fully automated version. A lot of useful loops do not eliminate the task. They make the next execution obvious, local, renewable, and less dependent on you remembering the whole ritual.\n\nThis is also why factory games and clicker games are weirdly good intuition pumps for agent work. You buy or build little machines. The machines produce resources. You spend those resources on better machines. Eventually the game is not about clicking the cookie. It is about designing the production system.\n\nAgent loops are like that, except the resource is not wood or cookies.\n\nThe resource is finished work.\n\nA good loop turns a recurring class of work into something that can proceed without your attention at every step. A better loop returns with evidence. A great loop improves the environment so the next run is cheaper.\n\nThat last part is the compounding move.\n\nIf an agent makes a mistake and you only fix the mistake, you got one fix.\n\nIf an agent makes a mistake and you add a test, a CI check, a repo instruction, a skill, a screenshot comparison, or a better stop condition, you changed the future.\n\nYou planted the saplings by the base.\n\n## The loop does not have to be code\n\nThis is the part I think gets lost.\n\nPeople hear \"write loops\" and imagine a cron job with a bash script chewing through their repo. Sure, that can be a loop.\n\nBut a loop can also be:\n\n- a Codex goal with a clear done condition;\n- a carefully written\n`AGENTS.md`\n\n; - a shipping skill the agent invokes every time;\n- a CI check that catches repeated slop;\n- a browser smoke test;\n- a PR template with required evidence;\n- a spreadsheet import workflow with visible lineage;\n- a human review queue that batches decisions;\n- a scheduled agent run that triages issues and writes findings into a board.\n\nThe shared move is that you stop re-performing the same steering work manually.\n\nThis is why skills matter so much. A skill is just a durable place to write down project knowledge the agent would otherwise rediscover badly every time. But that is the whole trick. Intent written outside the chat can compound.\n\nSame with CI. CI is not just for humans. CI is an agent steering surface. A failing test is a prompt the agent did not need you to write.\n\nThe loop is the whole system around the model.\n\n```\nCapability = model x harness x tools x environment x evaluator\n```\n\nThe model matters. But the loop lives in the rest of the equation.\n\n## A small Codex goal pattern\n\nOne practical way to try this in Codex is Goal mode. The current Codex docs describe `/goal`\n\nas a persistent objective that Codex works toward until it finishes, pauses, or needs more input. If the command is not visible, the docs say to enable `features.goals`\n\nin config or run `codex features enable goals`\n\n.\n\nI would not start with \"make my app better.\"\n\nStart with a goal card:\n\n```\nOutcome:\nShip the draft blog post into Sanity as an unlisted draft.\n\nDone when:\n- The Sanity draft exists with title, slug, description, tags, image, publish date, and markdown body.\n- The local draft file exists in drafts/.\n- The preview URL loads the draft content.\n\nAllowed work:\n- Read the repo publishing scripts and Sanity schema.\n- Use the local Sanity write token without printing it.\n- Start a local dev server if needed.\n\nStop for human:\n- Missing write token.\n- Unclear public-vs-draft publishing choice.\n- Any destructive content migration.\n\nVerification:\n- Fetch the document back from Sanity.\n- Open the preview URL locally or provide the production preview URL.\n```\n\nThen run:\n\n```\n/goal <paste the goal card>\n```\n\nOr, better, start with `/plan`\n\n, ask Codex to turn your rough intent into a goal card, edit the stop conditions, and then run `/goal`\n\n.\n\nScreenshot placeholder: Codex composer with\n\n`/goal`\n\nand a short goal card.\n\nScreenshot placeholder: active Codex goal progress row with pause, resume, edit, and clear controls.\n\nThe important thing is not the slash command. The important thing is that the goal has an evaluator. Codex needs to know what \"done\" means without asking you to re-decide it at every step.\n\n## The token part\n\nHere is the practical part: you are trading time for tokens.\n\nRight now, that trade can be unusually favorable. The current ChatGPT Pro documentation says the $200 Pro tier remains the highest-usage tier and gives 20x the usage allowance of Plus. OpenAI also documents flexible credits for Codex once you hit included plan limits, and the Codex rate card has moved toward token-based pricing, with actual usage depending on input, cached input, and output tokens.\n\nThat is the direction of travel.\n\nThe current economics may not last forever. Or at least you should not build your whole workflow on the assumption that they will.\n\nSome people online are going to spend enormous numbers of tokens because they have unusually good access, unusually high willingness to pay, unusually strong reasons to experiment, or all three. That is not a moral standard. You are not behind because you are not maxing out every agentic surface all day.\n\nHigh usage is not the same as progress.\n\nA weak loop can let the model thrash for an hour and return a pile of confident unfinishedness.\n\nA good loop spends enough compute to save your attention on a task that matters and returns evidence you can review.\n\nThe unit is not tokens.\n\nThe unit is:\n\n```\nvaluable output per dollar per unit of human attention\n```\n\nSometimes the model is unreliable enough at the task that the right move is to do it yourself.\n\nSometimes the task is so judgment-heavy that a loop should only prepare options.\n\nSometimes the task is so repeatable and verifiable that not building a loop is the expensive choice.\n\nThe practical question is which case you are in.\n\n## What I would actually automate first\n\nIf you are trying to make this real, start with the boring repeated pain.\n\nDo not start with the most ambitious autonomous setup. Start with the thing you already trust yourself to judge but hate manually redoing.\n\nUseful first loops:\n\n- \"When CI fails, summarize the failing check, inspect the logs, and propose the smallest fix.\"\n- \"Before every PR, run the repo shipping skill and produce the required evidence.\"\n- \"Every morning, look for stale branches and tell me which ones need a decision.\"\n- \"When a blog draft is created, check frontmatter, links, description length, and preview render.\"\n- \"After an agent fix, run the browser smoke path and attach the screenshot.\"\n- \"When I repeat an instruction twice, suggest whether it belongs in\n`AGENTS.md`\n\nor a skill.\"\n\nLess useful starting points:\n\n- \"Run forever until my product is good.\"\n- \"Refactor the whole app and merge it.\"\n- \"Find opportunities.\"\n- \"Improve design.\"\n- \"Do marketing.\"\n\nThose are not impossible. They are just too wide until you build the smaller machines underneath them.\n\nThe move is:\n\n``` php\nrepeat pain -> explicit rule -> automated check -> delegated loop -> review evidence -> improve the rule\n```\n\nThat is how the execution horizon moves.\n\n## This article is itself the example\n\nThis post started as me rambling into my computer.\n\nThat used to be a dead end a lot of the time. Not because I did not have anything to say, but because turning a spoken pile of thoughts into a real article takes a bunch of tiny annoying steps: preserve the voice, find the references, pull in the [Friday.land](https://www.friday.land/) notes, write the math, create the CMS document, keep the post unlisted, generate the preview link, and leave the draft somewhere editable.\n\nNow the workflow is closer to:\n\n```\nramble for 20 minutes\ndelegate the first draft\ndo one serious editorial pass\npublish or kill it\n```\n\nThat is the whole thing.\n\nThe loop did not make the taste decision for me. It did not decide that this was worth saying. It did not know which parts of my own philosophy mattered. But it carried a bunch of execution that used to be expensive enough to stop the article from existing.\n\nI am taking that trade.\n\n## The better slogan\n\n\"Write loops, not prompts\" is catchy.\n\nThe more precise version is:\n\nAutomate the parts of prompting that you keep repeating, and keep judgment close to the parts that matter.\n\nPrompts are still useful. Loops are useful when the work repeats, the stop condition is clear, the evaluator is strong, and the saved attention is worth the token spend.\n\nThat longer sentence is less catchy than the slogan.\n\nIt is also the part you can actually use.\n\nThe goal is not to become the person with the largest token bill.\n\nThe goal is to move your own execution horizon: less repeated steering, more finished work, more room for judgment, and fewer good ideas dying in the gap between \"I should\" and \"done.\"\n\n## Sources worth reading\n\n- Peter Steinberger's\n[X post](https://x.com/steipete/status/2063697162748260627)that kicked a lot of this off. - Addy Osmani's\n[Loop Engineering](https://addyosmani.com/blog/loop-engineering/)explainer. - O'Reilly's republished version of Addy's\n[Loop Engineering](https://www.oreilly.com/radar/loop-engineering/)piece. - OpenAI's Codex docs on\n[Goal mode](https://developers.openai.com/codex/prompting#goal-mode)and the[Codex app](https://developers.openai.com/codex/app/commands#set-or-manage-a-goal-with-goal).`/goal`\n\ncommand - OpenAI Help on\n[ChatGPT Pro tiers](https://help.openai.com/en/articles/9793128-about-chatgpt-pro-tiers),[flexible usage credits](https://help.openai.com/en/articles/12642688-using-credits-for-flexible-usage-in-chatgpt-freegopluspro), and the[Codex rate card](https://help.openai.com/en/articles/20001106-codex-rate-card).", "url": "https://wpnews.pro/news/writing-loops-not-prompts-explained", "canonical_source": "https://rico.codes/loops-not-prompts", "published_at": "2026-06-24 12:00:00+00:00", "updated_at": "2026-06-24 13:17:45.273321+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "generative-ai", "large-language-models"], "entities": ["Peter Steinberger", "Boris Cherny", "Claude Code", "Addy Osmani", "NeetCode", "Friday.land"], "alternates": {"html": "https://wpnews.pro/news/writing-loops-not-prompts-explained", "markdown": "https://wpnews.pro/news/writing-loops-not-prompts-explained.md", "text": "https://wpnews.pro/news/writing-loops-not-prompts-explained.txt", "jsonld": "https://wpnews.pro/news/writing-loops-not-prompts-explained.jsonld"}}