Prompting was the easy part.
the loop is the job.
Prompt engineering got the agent to answer. Context engineering got it to answer about your codebase. Neither tells you whether the answer is right. That takes a loop: build → test → independent review → fix, run until it passes or a human is genuinely needed.
$ ptln crank$ brew install partyline-sh/tap/partylinehow it works
a prompt is a wish
A good prompt raises the odds. It can’t detect its own mistake — the model that misread the task also grades the result. That’s not a review, it’s a self-assessment.
context is the ante
Your conventions, your architecture, the decision made last Tuesday. Necessary, and still not sufficient: a well-informed agent writes plausible code. Plausible isn’t verified.
the loop is the proof
A harness runs the work in an isolated worktree; the loop closes it. Your tests, then a reviewer that didn’t write the code, then the fix — bounded rounds, then a human.
what you're wondering
how is this different from just prompting better?
A better prompt changes what the agent tries. A loop changes what you accept. The first is a probability, the second is a gate — and only the gate produces evidence you can point at when you merge.
why does the reviewer have to be separate?
An agent grading its own work is blind to exactly the things it got wrong — the misreading that produced the bug also produces the confident sign-off. partyline runs the review as a distinct, tool-less step so it criticizes rather than repairs, and the builder does the repairing.
doesn't looping forever just burn tokens?
Which is why it doesn't loop forever. Repair rounds are bounded (two by default, 0–5 per project). A task the reviewer still rejects after honest attempts is a disagreement retrying won't settle — an ambiguous task, or a wrong reviewer — so it quarantines with its full attempt history for a human.
close the loop on agent work.
$ brew install partyline-sh/tap/partylinethe gates that run it — see build, test, review, fix →