Prompting Isn't Dead. It's Just Not the Job Anymore.
A clip did the rounds on X this week claiming “prompting is basically over” and that the next move is loops and graphs. That’s a big headline, and the source is unverified, but the idea underneath it is right. I’ve felt it myself building Recepticon, my AI receptionist for tradies.
For a while, my whole game was the prompt. I’d tweak a word, add an example, shout in capitals, and rerun. Sometimes it got better and sometimes it got weirder. Either way I was sitting in the chair, checking every output by hand. That isn’t engineering. That’s babysitting.
Why prompting hits a ceiling
A prompt is a one-shot bet. You describe what you want, the model takes its best swing, and you judge the result. The quality ceiling is whatever the model gets right on the first try, plus however much attention you have left to catch the misses.
The trap is that a good prompt makes the output look right. When a receptionist bot gives a confident, friendly reply with the wrong price, the problem isn’t that the prompt needed one more sentence. The problem is that nothing in the system could tell it was wrong.
Loops: start with a check that can fail
Strip it back and a loop is four steps: produce, check, correct, repeat until it passes.
The check is the whole thing. Without something that can fail the work while you’re out of the room, you don’t have a loop. You’ve just got a scheduler.
Most people build the work first, then bolt a review on the end, usually another model asked “does this look good?” That’s two optimists agreeing with each other. Write the check first, and write it so a program could evaluate it:
- The test suite passes.
- Every claim points to a source.
- The change only touches the files that were planned.
These are not checks:
- “The output looks good.”
- “The model says it’s confident.”
- “No errors were raised.”
That last one fools careful people. No error doesn’t mean the result is correct. Build a loop on it and you get a system that confidently repeats the same mistake until the budget runs out, with a clean log the whole way.
For Recepticon, the check is boring and brilliant. Is the quoted price actually in the client’s price list? Is the booking slot actually free in the calendar? Did the reply include the business name? A program can fail any of those, no vibes required.
Graphs: decide what runs at all
A loop makes one piece of work correct. It can’t decide which pieces should exist, what order they run in, or notice that two of your five steps never needed to wait for each other. You end up with a very good agent doing the wrong three things, in the wrong order, one at a time.
A graph is the shape of the work. A node is one bounded job, with one input and one output. An edge is a real dependency: this node’s output feeds that node’s input.
The sneaky mistake is treating “and then” as an edge. If step two doesn’t actually read step one’s output, there’s no edge, and the wait is pure waste. Go through any pipeline you already have and ask, for every arrow, what actually gets passed across it. If you can’t name it, run those steps in parallel.
In practice there are only four kinds of node:
- Splitter: cuts the job into units. It matters most, because cutting along the wrong line wastes everything downstream.
- Worker: does one unit, with one focus, in its own context, so parallel workers don’t just echo each other.
- Code node: handles merging, ranking, deduplicating and comparing. If you can describe the step without the words judge, decide or assess, it’s code, not a model call.
- Gate: decides what passes.
The loop lives inside a node. The graph lives between nodes. You need both.
Self-improving: the edge everyone skips
A graph with no way back is just a pipeline. It produces output and forgets, so next week it starts with the same blind spots.
Working systems have two return paths:
- The correction edge (short). A gate sends one failed unit back to the step that made it. That fixes this run. Send back only the broken piece, never the whole batch, because redoing work that was already right doesn’t make it better, it just makes it different. Cap it at about three retries. If something fails three times, the problem is the plan, not the worker.
- The learning edge (long). An accepted result goes back to the splitter as a rule. That fixes every future run. “Prices must come from the client’s uploaded list” stops being a lesson I keep re-teaching and becomes a constraint the system starts from.
That second edge is what self-improving means. It’s not magic, and it’s not the model rewriting itself. It’s your system writing down what it learned in the place where the next job gets planned.
Where the human goes
Gate on how bad a mistake would be, not on how confident the model is. Confidence is the one input the model can inflate.
Small, reversible changes like copy tweaks, a test or an isolated function can flow through automatically. Wider changes get deterministic checks. Anything that’s hard to undo, like deleting data, moving money, or texting a real customer, doesn’t auto-pass, no matter the score.
That’s where I sit now: one approval at the highest-stakes, least reversible step, instead of checking every step along the way. A human in the middle of a graph just becomes its slowest node.
Try it: the Loop Lab
Click around to feel the difference. Start on Beginner for a single loop, move to Mid for a graph, and try Expert for the learning edge and blast-radius gates. It’s a simulation with made-up numbers, built to show the idea rather than measure anything.
So is prompting over?
No. Prompts are still how you talk to each worker. But the prompt is now one part of a bigger system, not the system itself. The skill that matters now is designing the checks, the shape of the work, and the way lessons get fed back in.
Making music works the same way for me. One great synth patch doesn’t make a set. The sequencing, the feedback, and knowing when to let a loop run and when to step in are what make it a set.
If you’re still tweaking prompts and wondering why it plateaus, pick one thing you do over and over. Write the check first. Draw the splitter, the workers, one gate and one way back. Then get out of the chair.