There's a thread on V2EX that stuck with me. A developer confesses he's basically stopped doing code review, testing, and on-call triage himself, handing all of it to agents, and the project isn't just surviving, it's moving faster. Then he ends with the request everyone eventually makes: what treasure Agent prompts do you all use to squeeze the model?
Share a few, point the lost cyber-souls in the right direction.
I get the instinct. But collecting prompts is the wrong hunt. A prompt someone swears by is worthless to you until you can tell whether it works on your tasks, and worse, once you start editing it, you have no way to know if your tweak helped or quietly made things worse. You change a line, the output feels better, you keep it. That's not engineering, that's vibes. And the same thread crowd knows it: another discussion has people arguing over whether Grok 4.6 at max thinking is still "a pile" compared to GPT, whether deepseek-flash is fine for execution, which model to plan with and which to run cheap. Everyone has a strong opinion and almost nobody has a bench to settle it.
The actual need: comparison grounded in real outputs
What's missing isn't better prompts. It's a way to say, with receipts, this version of the prompt produced these outputs on this fixed set of tasks, and that version produced those. When you can lay two runs side by side, the argument ends. When you can't, you're just relitigating feelings.
So the thing worth building is small and boring: a prompt regression bench. Version every prompt. Replay a fixed task set through one model. Write every single run to a ledger you can open and read. Nothing exotic, but it turns "I think the new prompt is better" into "here are the 20 outputs, judge for yourself."
What this looks like on VicroCode
The backend is plain Python, and you can run Python online without standing up your own server. The loop is short: read your task set, for each task send the prompt through a model, capture the raw output, timestamp it, and append a row. You call a model through the Model Center APIs, but only a model that's already available on the platform. That boundary matters and I'll come back to it.
The ledger is a SQLite database, which is the part that makes the whole thing honest. One table for prompt versions (id, name, the full prompt text, a note on what you changed and why). One table for tasks (id, the input, and optionally an expected-answer or a rubric). One table for runs, where each row ties a prompt version to a task, stores the exact output, the model name, and when it ran. That's it. Because it's SQLite, you can open the file in the SQLite editor and actually look at the outputs, fix a mangled row, or hand-label whether a run passed. No dashboard theater, just the data.
Run version A across all tasks, run version B across the same tasks, then query the runs table filtered to both versions and read them in parallel. If you added a pass/fail label column, a one-line count tells you the score delta. If you didn't, you eyeball the diffs, which is often enough to catch a regression you'd have shipped otherwise.
When you want others to poke at it, publish the whole thing as an HTML front end over your Python backend and share it. A teammate picks two versions, hits replay, reads the ledger. The comparison is the product.
Why the model boundary is a feature here
The V2EX cost thread is one long anxiety spiral about quotas, plan tiers, and which account to rotate. A bench doesn't solve pricing, but it does something useful: it pins your comparison to one model available through the platform, so you're testing the prompt, not smearing prompt changes and model changes together. If you swap models and the prompt in the same breath, you've learned nothing. Hold the model fixed, vary the prompt, and the ledger means something.
Be honest about what this is not. It won't drive your existing agent framework, your CI, or whatever coding tool you already live in. It doesn't reach out to models the platform doesn't already offer, and it isn't a general eval harness with fancy scoring. It's a controlled replay-and-log bench for prompts you can run against an available model, and its whole value is that every claim traces back to a row you can read. Whether it improves your specific outputs is unverified until you run your own tasks through it. That's the point, actually. You stop guessing and go check.
The bigger shift
The thread author is only half joking when he asks what the prompt engineer becomes, cybernetic priest chanting at a black box. But the useful read is the other half: as more of the work moves to prompts and agents, the discipline that survives is the one that can measure. If you're going to hand review and triage to a model, the least you can do is keep a ledger proving the instructions you gave it are getting better and not worse. That habit is worth more than anyone's treasure prompt, and it pairs naturally with the fundamentals in any decent guide to AI coding.
Start with three tasks and two prompt versions. You'll learn more from that tiny bench than from a hundred copied prompts.