Loop Engineering in 2026: Why the Best Developers Don't Prompt AI Agents Anymore - They Design Loops

Boris Cherny, the guy who runs Claude Code at Anthropic, said something last week that made me stop scrolling:

"I don't prompt Claude anymore. I have loops that are running. My job is to write loops."

Peter Steinberger put it even more directly: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

And Addy Osmani, who leads Chrome engineering at Google, gave the whole thing a name: loop engineering.

If you have been heads-down building, this might be the first time you are hearing the term. But it is already the dominant workflow among the developers shipping the most AI-assisted code right now. Here is what it is, why it matters, and the one piece of the setup almost nobody is talking about yet.

What is loop engineering?

For the past two years, working with a coding agent meant typing a prompt, reading the output, deciding what to do next, and typing another prompt. The agent was a tool and you were holding it the entire time.

Loop engineering flips that. Instead of you prompting the agent turn by turn, you design a small system that finds the work, distributes it to agents, checks the output, records what got done, and decides what to do next. You wake up to results.

Osmani breaks it down into five pieces plus one persistent state layer:

1. Automations - the heartbeat. Scheduled tasks that handle discovery and triage on their own. They run on a timer, look for work like open issues, failing tests, stale PRs, and either act or file a report. OpenAI uses these internally for daily issue triage, CI failure summaries and bug hunting.

2. Worktrees - isolated workspaces so two agents working in parallel do not step on each other. If one agent is fixing a bug and another is refactoring a module, they each get their own checkout.

3. Skills - codified project knowledge. Instead of pasting the same context into every prompt, you write it once as a skill file the agent loads when it needs it. Architecture rules, API patterns, testing conventions. The agent stops guessing and starts knowing.

4. Plugins and connectors - MCP servers that plug the agent into your actual stack. GitHub, Linear, Slack, your database, your monitoring. The agent can read a ticket, check the logs, and open a PR without you playing telephone between tools.

5. Sub-agents - one agent ideates, a different one verifies. The ideator writes the code, the reviewer reads it fresh with no context of how it was produced, and flags what does not make sense. This cuts hallucination dramatically.

6. Persistent memory - a markdown file, a Linear board, anything that lives outside a single conversation. The agent forgets everything between runs. The repo does not.

All the major platforms now ship some version of these primitives. Claude Code has them. Codex has them. The names differ slightly but the capability is the same thing. Once you see the shape, you stop arguing about which tool and just design loops that work regardless of where you happen to be sitting.

The piece nobody is talking about

Here is what struck me reading Osmani's breakdown: every one of these six pieces involves you communicating with agents. You are writing automations, writing skills, writing prompts, reviewing output, giving feedback.

And almost everyone is doing it by typing.

Typing is the bottleneck. Most people type at 40 to 60 words per minute. You speak at 150. That is a 3x difference in input bandwidth. But the real tax is not speed - it is friction. When you have to switch from thinking to typing, you edit as you go. You truncate. You write shorter, less complete prompts because typing full context is a chore.

This is exactly why developers give AI agents thin, underspecified instructions and then wonder why the output feels shallow. The agent isn’t bad at reasoning. You gave it a tweet-length prompt when what you actually needed was a paragraph of context.

Dictating to your agents

I have been using DictaFlow to talk to my agents instead of typing to them. It sounds like a small change but it changes the dynamic entirely.

Instead of typing "fix the login bug in auth.ts" and hoping the agent figures out which bug and which edge case, I speak:

"The login flow in auth.ts throws a 500 when the session token expires mid-request. We need a retry with a fresh token before failing. Also check the error boundary in the React component because right now it shows a white screen instead of redirecting to login."

That took eight seconds to say. Typing it would have taken two minutes, and honestly I would have stopped after the first sentence.

When I’m reviewing agent output, I usually dictate my feedback while scrolling through the diff. Comments that would’ve been “looks good” turn into actual observations, because speaking a full thought is fast enough that I don’t skip it.

When I am writing a skill file - those codified project knowledge docs agents load - I dictate the structure, the rules, the conventions. The output is richer because the input was richer. I described what I actually wanted instead of what I had the patience to type.

How to wire it up

The setup is straightforward. DictaFlow runs on Mac, Windows, and iOS, so it works wherever your development environment lives. It uses a hold-to-talk trigger - you hold a key, speak, release, and your words appear in whatever field your cursor is in. No copy-paste, no switching windows.

Here is the workflow I landed on:

• Agent instructions: Open Claude Code or Codex, hold the trigger, speak the full prompt. Release. The agent gets a complete, well-structured instruction instead of a rushed sentence fragment.
• Code review: Open a PR, scroll through the diff while holding the trigger. Speak observations as you read. "This null check is redundant because we already guard it on line 42." "This variable name is misleading - it is not a user ID, it is a session ID." Your feedback lands in the comment box as you think it.
• Skill authoring: Open a SKILL.md file, dictate the project conventions, rules, and patterns the agent should follow. What took 15 minutes of typing now takes 5 minutes of speaking.
• Loop design: When you are designing the automations and sub-agent chains that make up a loop, dictate the full architecture into a planning doc. The loop design is the hard part. Speaking it forces you to think it through out loud, which has a side benefit of producing better designs.

The throughline is the same in every case: you give your agents richer input. The loops get smarter because the instructions got better. Not because the model changed. Because you stopped truncating your thoughts.

The bottom line

Loop engineering is real, and it is going to separate the developers who get 10x leverage from AI agents from the ones still prompting one turn at a time. But the quality of your loops depends on the quality of what you feed into them. If you are still bottlenecked at 40 words per minute of typing, your loops will reflect that.

Talking to your agents at 150 words per minute - full sentences, full context, no truncation - is one of those things that sounds like a gimmick until you try DictaFlow for a day. After that, going back to typing feels like texting with one thumb.

The best loops are the ones where the agent actually understands what you meant. That stops being a prompt engineering problem and becomes an input bandwidth problem. DictaFlow solves the input bandwidth problem. You have had the hardware for it your whole life.

Try DictaFlow free and start talking to your agents today.