Last month I sat down to build a demo generator for my work as a solution architect. The brief in my head was ambitious: an app that provisions cloud infrastructure with Terraform, generates synthetic data tailored to a customer’s industry, stores it in a relational database, trains a model on it, and wires the result into a dashboard. I described exactly that to the AI. Nothing happened — or rather, something happened, but not the thing I had imagined. Tokens burned, scaffolding appeared, and after an afternoon I had perhaps ten percent of the picture in my head, none of it usable. The model was not the problem. The problem was that I had tried to skip a step nobody talks about enough.

This will sound familiar to anyone who has read Eliyahu Goldratt’s The Goal. Every system has one true constraint, and speeding up anything else only produces a queue in front of it. For thirty years, that constraint in software was obvious: engineers were scarce, and the entire discipline of product management, agile delivery and sprint planning grew up around managing that one bottleneck. A decade-old shorthand in the software community already knew this before AI arrived: “Typing is not the bottleneck.” Writing the code was rarely the hard part. What AI has changed is that it removed the last excuse to postpone the harder question.

Over the past two years we have named this shift several times without quite admitting what it means. First came prompt engineering — the craft of asking well. Then context engineering — making sure the model has the right information at the right moment. Now, in the middle of 2026, a third layer has entered the vocabulary: loop engineering, the practice of letting an autonomous agent push its own development forward, verifying and retrying with only a human checkpoint at the edges. Boris Cherny, who built Claude Code, described the shift in four words that travelled further than most engineering blog posts ever do: “I don’t prompt Claude anymore.” Every one of these disciplines answers the same question: how do we reduce human effort and expand what the agent can do alone?

But does reducing human effort in the loop tell the agent what “done” should look like? A loop can prompt, verify, retry and stop — and still stop at the wrong destination, because nobody defined which destination mattered. Addy Osmani, the Google engineer whose essay gave the practice its name, is characteristically direct about what a loop actually replaces: “you design the system that does it instead.” I would go further. Designing the system is not the same as designing the product. If the system does not know what to build in the first place, autonomy simply multiplies the wrong first draft, faster.

The core of the problem was never how much of the loop we can automate. It is product design — deciding, before a single prompt is written, what the next tangible increment of value actually is. This is the discipline that prompt engineering, context engineering and loop engineering were never built to replace, because none of them were ever meant to answer “should we build it?” — only “how fast can we build it, once we know?”

Go back to my demo generator. “Deploy reusable cloud infrastructure with Terraform, generate synthetic data for the customer’s industry, store it in a relational database, train a model, integrate it into a dashboard” is not a specification — it is a table of contents for a book I had not yet written. Every clause hides a dozen decisions I had not made: which industries, which schema, which cloud provider, which model, which chart. Compare it with “create a data simulator that takes a customer scenario and stores the result as CSV files.” Smaller, yes — but concrete enough that the AI and I could actually converge on something real. I wrote perhaps two pages of requirements; the model complemented them with reasonable defaults, and within the same afternoon I had something I could show a customer and take ownership of. The data simulator, incidentally, is not a detour from the bigger vision. It is a mandatory part of it — the same demo generator, entered through a door small enough to walk through.

This is what product design has always meant, long before anyone gave it that name: breaking ambition into increments where each one produces something you can inspect, use and defend. AI does not remove that discipline — it raises the price of skipping it, because it will happily generate ten unusable directions for every one well-scoped step you hand it. Andrew Ng has compared these tools to the typewriter: it sped up the writing, but, as one product commentary summarising his point puts it, “it didn’t help us know what to write.” The same gap is opening in software — deciding what to build has only become harder now that almost everything is technically buildable within a day.

Concretely, this leaves a short set of questions worth sitting with before any prompt is written:

• What is the smallest slice of this that produces something a customer could actually see or use today?
• Which of my “big picture” ambitions is secretly already contained inside that slice?
• If I cannot answer either question with confidence, is that a sign to specify more — or to shrink the scope until I can?

Loop engineering will keep maturing. Agents will hold longer chains of context, verify their own work more rigorously, and need fewer human checkpoints along the way. None of that changes where the real leverage sits. The craft that decides whether all that autonomy produces something worth having is still product design — patient, incremental, and stubbornly human. Start small, make it tangible, and let the agent handle everything downstream of that decision. That is not a limitation of vibe coding. It is the whole point of it.

---

Further reading, for those who want to follow the threads pulled on above:

• Addy Osmani, “Loop Engineering” — the essay, republished by O’Reilly Radar, that named the practice and set out its core components.
• WorkOS, “Key takeaways from Boris Cherny on building Claude Code” — the shift from prompting to designing loops, straight from Claude Code’s creator.
• airfocus by Lucid, “Is product management becoming a bottleneck for AI?” — Malte Scholz on why decision-making, not delivery, is where teams now get stuck.