Uphoff on Media Podcast
A few posts ago, I made the case that Vibe Coding [https://tonyuphoff.substack.com/p/vibe-coding]eliminates the queue: the wait for an engineer to build the thing you need. Last post, Solo Scale [https://tonyuphoff.substack.com/p/solo-scale-the-new-business-model] showed what happens when you remove the ceiling on how much one expert can supervise. Neither one, by itself, changes how your business actually works. Loop Engineering is what does. It’s the bridge between “I can build this” and “this runs the business.” And it’s the part most business leaders haven’t discovered yet, even as it’s already quietly reshaping how businesses operationalize Agentic AI. That quieter shift is starting, and the people closest to the technology have already made it. In June, Boris Cherny, who leads Claude Code at Anthropic, said he no longer prompts the model at all. He writes loops that do the prompting for him, and his job now is to write the loops. Engineers at Google and OpenAI have been saying versions of the same thing. The shorthand term is “loop engineering.” Here is why it matters to you, even if you never write a line of code: the move from prompting to loops is not a coding story. It is an operating story. And it is the piece that turns everything agentic AI has promised into something a business can actually run on. From Running the Tool to Designing a System Start with the plainest version. Prompting asks a model for an answer. You type a request, read what comes back, refine it, ask again. You are running the tool the entire time, one turn after another, and the quality of the work depends on your skill at the exchange and your patience for it. You are the bottleneck. A loop is different. A loop is a short set of instructions that says what you are trying to accomplish, what the system may use to get there, what counts as evidence it succeeded, what to do when it fails, what to remember between runs, and when to stop. Then it runs: checking its own output against your standard and continuing until the result is good enough to use. Prompting gets you one good answer. A loop builds the thing that produces good answers without you in the room. What a loop really is Strip the code away and a loop is something every good operator already carries in their head: a standard for what good looks like, and the judgment to know when work meets it. What you have never had is a way to enforce that standard at scale, on many fronts at once, without being present for every step. That is what a loop gives you. You define the goal, the tools, the evidence, the failure response, the memory, and the stopping point once. The system carries your standard forward every time it runs. The scarce thing just moved For two years the value lived in the interaction: knowing how to prompt well, working the tool skillfully turn by turn. That skill is being commoditized. The new scarcity sits upstream of it: knowing what good looks like, and being able to specify it precisely enough that a system can hold to it without you. The premium is moving from doing the work to knowing what good looks like, and being able to say so precisely. That reallocation changes what each of you should do next. Here is where to start, depending on where you sit. If you run the work: deploy Pick one process you run over and over that leans on your judgment: a weekly competitive brief, lead qualification, a first-pass content review, campaign QA. Something with a clear standard for good that you currently apply by hand. Write that standard down: the goal, what the system may draw on, what a good result looks like, what to do when it isn’t. Then let a loop run it while you check the output instead of producing it. Start with one. Get it right before you add a second. The skill you are building is not technical. It is learning to state a standard clearly enough that a system can hold it. If you run the company: reallocate If value is moving from execution to judgment, your org chart is about to feel it. Ask yourself three questions. What are you staffing, promoting, and paying for today that is execution capacity about to get cheap? Who on your team can author standards, not just follow them, because that is the scarce talent now. And the pointed one: which part of the business would you most want running on your standard instead of your headcount, and what is keeping you from starting there? The executives I watch most closely are not asking whether this is real. They are asking where to apply it first, and how fast they can move. If you fund the work: evaluate When execution is cheap and judgment is scarce, the shape of a good business changes. The moat is no longer how much a company can build, or how fast. It is the quality of the standard encoded in its systems: proprietary judgment about what good looks like in a specific domain, enforced by loops a competitor cannot easily copy. In diligence, the question moves from how big is the team to whose judgment is in the loop, and will it hold. And learn to tell a real loop from loops-as-lipstick: genuine encoded expertise versus a thin prompt in a nice interface. If you’re starting something: build This is the part that should keep you up at night, in the good way. If one expert, armed with the right standards and a set of loops, can produce what used to take a department, then a single person with deep domain knowledge can start and run a business that used to require a team and a raise. Not by writing code. By encoding what they know about their field into systems that run. The barrier to starting has never been lower for the person whose real asset is expertise. So the question is simple: what would you build if execution were no longer the thing in your way? One hard truth first A loop running unattended is also a loop making mistakes unattended. The skill of loop engineering is not the loop. That part is simple. It is knowing where the system will be confidently wrong, feeding it inputs you can trust, and keeping a human on the standard. The people learning this the hard way keep arriving at the same lesson: the model rarely fails because it is dumb. It fails because it was handed bad inputs or a fuzzy standard, and it faithfully delivered exactly what it was told to. Verification stays human. That is not a limitation to engineer away. It is the job. Three posts, one argument Now step back. Vibe Coding removed the constraint on who can build. Anyone who can describe software can produce it. The queue disappeared. Solo Scale named what becomes possible at the far end: an expert-led, agent-powered business running at software margins, one person, or a very small team, producing what once took many. Loop engineering is the bridge between them. It is the mechanism that turns “anyone can build” into “one expert can run a whole business.” Without loops, Vibe Coding gives you faster one-off builds, impressive, but still one turn at a time, still bottlenecked by your bandwidth. With loops, those builds become systems that run: your judgment, encoded, working on many fronts at once. That is the machinery beneath Solo Scale. It is what makes the margins real. And the same mechanism, pointed at an organization instead of a solo operator, opens a much larger door. When you stop automating single tasks and start encoding judgment into loops that run across a whole process, you are no longer improving a workflow. You are transforming it, rethinking how work moves through the business from end to end. That is the next frontier, and loop engineering is the way in. So: three posts, one argument. Vibe Coding opened the door. Solo Scale showed the room on the other side. Loop engineering is how you walk through, and it is the same threshold every business will cross on the way to changing how work actually gets done. The queue is gone. The ceiling is going. What is left is the standard, and whether you can name it clearly enough for a system to carry it. That is the work now. The views expressed in Uphoff on Media are entirely my own. They don’t represent the opinions of any company I’ve led, any board I’ve sat on, or any investor who’s had the pleasure of debating strategy with me over the years. If something I write here sounds brilliant, I’ll take full credit. If it turns out to be wrong, I was clearly misquoted by myself. “Uphoff on Media” is published by Tony Uphoff, Founder and Managing Partner of Uphoff Advisory, LLC [https://uphoffadvisory.com/]: a strategic advisory practice for founders, CEOs, and investors in B2B information, marketing, and technology. The businesses that drive business. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit tonyuphoff.substack.com [https://tonyuphoff.substack.com?utm_medium=podcast&utm_campaign=CTA_1]
26 episoder
Kommentarer
0Vær den første til at kommentere
Tilmeld dig nu og bliv en del af Uphoff on Media Podcast-fællesskabet!