Vibe Coding Best Practices: Who Gets to Say Done
Vibe coding best practices are not about better prompts. Learn why a definition of done, checked by something other than the agent, is the practice that
Vibe coding best practices are about how you phrase prompts. They are not. The best practice is a definition of done that exists before the agent starts and that something other than the agent checks. A prompt can steer the draft. It cannot accept the draft.
Are vibe coding best practices really about prompts?
No. Prompt advice survives because it is easy to grade. Acceptance is harder.
Three randomized controlled trials with more than 4,000 developers found that participants using AI-assisted coding tools completed approximately 26.08% more pull requests per week than developers without the tool, across 2022 and 2023 trials summarized in the linked field-experiment report. That number measures throughput. It says nothing about correctness, security, or what happens after the change lands.
So vibe coding best practices have to name a second party that can reject the work. Speed alone is a poor definition of done.
Why can the agent not judge its own work?
An agent that says it is finished is the one party that cannot tell you whether it is. Better prompts and shared conventions make the draft easier to read, and that part of the advice is worth keeping. They do not turn the author into a fair examiner.
A cook who tastes the dish and then signs the health certificate will pass the plate they meant to serve. An agent that reports finished sits in that same chair. Brief it well. It still cannot inspect itself. In a queue of agents it gets worse, because an unchecked "done" becomes the next agent's starting assumption.
In a 186-task benchmark spanning 79 CWE categories, the strongest tested configuration solved 57% of tasks, yet 79.3% of those functionally correct solutions were insecure, agents failed more than 70% of security tests, and vulnerability hints in the prompt did not reliably fix that, according to a benchmark of agent security failures.
A green functional run is not a security result. The model that wrote the happy path is a weak witness against its own patch. A second pass, the sort described for automated code review tools, has to sit outside the run that produced the change.
How does AuricIDE define done before the agent starts?
AuricIDE puts that definition on the goal, before any agent is dispatched. You write the success criteria there. Tickets hang off the goal, and test cases hang off the tickets.
That writing is the convention worth standardizing, in the same spirit as spec-driven development. A one-line tweak may not repay it. A chain of steps will. Each later step inherits the goal text instead of a fading prompt. Skip the criteria, and a later judge has nothing independent to compare the ticket against. Once agents start taking tickets, a gap in the plan becomes a gap in every later verdict.
A goal counts as satisfied only when its linked requirements are verified, so an agent finishing one ticket does not satisfy the goal. The summary can read as confident as it likes. The goal still waits.
Goals, tickets, requirements and test cases sit in one project database, and AuricIDE exposes them to agents over MCP. Desktop view and agents read the same backlog. Git ignores the database folder, so a clone will not bring the criteria to another machine. Copy the folder yourself.
What happens when a ticket finishes in AuricIDE?
The ticket does not become Done on the agent's word. With the judge switched on, it moves to In review and waits for a verdict.
The judge is off by default. You switch it on with a checkbox in the settings of the Conductor, the part of AuricIDE that hands tickets to agents. That has to happen before a run starts. The tooltip says finished tickets pass an independent judge before counting as done. The checkbox stays greyed out until a Judge model is set or an agent CLI is available to review with.
Two ways the judge can run
One LLM call. It sees the ticket text, the goal's success criteria, and the test cases. It does not see the diff.
A review agent. A separate agent inspects the code under the provider's default permission mode and reports pass or reject with a reason.
| Judge outcome | Ticket status | What happens next |
|---|---|---|
| Pass | Done | The ticket counts as done |
| Reject | Open | The ticket is requeued, at most 2 attempts |
| Crash, no verdict, or a 10 minute timeout | Treated as a rejection | The ticket returns to Open the same way a written reject does |
When the implementing agent finishes, the Conductor does not take that as acceptance. The ticket stays In review until a verdict comes back. Silence counts as a no. A pass moves it to Done. A reject sends it back to Open, and the queue may pick it up again. The Conductor puts the reason in its log, but the ticket does not show it. A retry starts from the ticket, the goal and the test cases again, without that reason. If the first agent missed a condition nobody wrote down, the next agent learns nothing from the rejection. After the second failed attempt the Conductor stops retrying and leaves the ticket Open. The goal above it still waits until its linked requirements are verified.
What does the judge gate cost?
You have to write criteria first. The judge can check only what it sees.
Vague test cases give the judge little to check, even when its verdict sounds sure. A tiny sketch may not repay the effort of writing more.
AuricIDE chose an LLM-call judge that never sees the diff. The call can pass work that only reads fine on paper, because the verdict rests on the ticket text, the criteria, and the test cases.
AuricIDE also chose a review agent that is not locked to read-only. It inspects the code with the provider's default permission mode, so a review step can still change files when that mode allows writes.
Past verdicts appear only in the conductor log. Nothing in the UI lists them. The ticket card shows no verdict history. To see why a ticket bounced, open the log. The retry never sees the reason. Read it yourself, then change the criteria or the ticket.
Switch the gate on when a false done would send the next agent down the wrong path. Leave it off when you are sketching and you will read the diff yourself in the next minute.
Which rule still holds outside AuricIDE?
Write down what done means before the run. Then let a separate step decide whether the work meets it. Any tool can host that split: one step implements, another step accepts, and a missing verdict counts as a no. The same split is what AI agent testing asks of checks you can rerun. Match the check to what it can see: a judge that reads text can test the written criteria, and only a look at the code can test the change. Write the success criteria before you dispatch the next agent, whether or not that agent runs inside AuricIDE.