This isn't a vibes post. It's a post-mortem of one session where I asked an agent to build a responsive-ad previewer and it burned most of an afternoon building something adjacent to what I asked for, then told me it worked.
Every item below is a named failure mode with the fix. They're useful whichever model you run — I've hit all ten from more than one vendor. Sol handles most of them better in my experience, which is why it's my default now, but the point of the list is the pattern, because you can defend against a pattern.
1. Assumes instead of asking the one clarifying question
I asked for a previewer for the responsive grid. It built around index.html — the full-screen ad. One question at the start kills the entire detour.
The fix: make the disambiguator mandatory before any file is written. When two readings of the ask lead to materially different work, asking is not a delay, it's the cheapest step in the job.
2. Says "done" on a proxy signal, not the real thing
It handed me links verified by curl returning HTTP 200 — twice — without ever watching the page render. A 200 means the server replied. It does not mean the page works.
# what it did — proves the server answered
curl -s -o /dev/null -w '%{http_code}' http://localhost:4321/preview/
# what it needed to do — proves the thing renders and has no errors
pinchtab nav http://localhost:4321/preview/
pinchtab screenshot -o check.png
pinchtab errorsThe fix: the verification must be a signal the model can't produce with confident prose. A screenshot, a console-error dump, a real auth call. Not a status code standing in for a page.
3. Over-builds the literal ask
"Rebuild on change" became a file watcher, plus a livereload server, plus a stub for the ad platform, plus a launcher script. Four systems for a request that wanted one.
The fix: ship the minimum that satisfies the request and stop. Over-building isn't generosity — every extra system is more surface to verify, and it's usually unverified.
4. Solves the wrong problem thoroughly
It wrote a complete platform stub for the page that didn't matter. The effort was real. The direction was wrong. Thoroughness pointed at the wrong target is worse than laziness, because it's expensive and it looks like progress.
The fix: confirm the target before investing. Restate what you're about to build, in one line, before building it.
5. Makes the user find the breaks
The console errors and the wrong-page problem were both discovered by me, after handover. That's the failure that actually costs trust, because it means every "done" now needs my independent check — which is the whole thing I was trying to delegate.
The fix: an always-on error watcher on the dev log, filtered for the strings that mean something broke, so a break becomes a notification you triage before reporting status:
tail -f dev.log | grep -Ei 'error|failed|cannot|undefined'This runs on a cheap small model. The expensive model does the thinking; the cheap one does the staring.
6. Loses the deliverable's actual purpose
It kept polishing the ad in front of it instead of the previewer's job: fast, correct responsive preview. The artifact became the goal and the goal got dropped.
The fix: keep the outcome in frame, not the file currently open. "What is this for?" beats "what am I editing?".
7. Tool and environment blindness
It fired browser-automation commands repeatedly while the browser binary was missing. Same command, same failure, several times.
The fix: verify your tools work before depending on them, and pivot on the first failure rather than the fifth. A dependency check is one command and it saves the whole loop.
8. Verbose, self-managing recovery
Under pressure it produced apology scaffolding and question dumps instead of fixing anything. "You're absolutely right, let me reconsider my approach" is not work.
The fix: get terse and act. This one's also economics — verbose recovery is billed output tokens at the exact moment you're already behind.
9. Misreads intent behind short prompts
"How do we rebuild it" was heard as "build rebuild infrastructure". It meant "keep the preview fresh with zero friction". Short prompts from an expert are compressed, not vague — they assume shared context.
The fix: infer the simplest path to what's actually wanted, then state the interpretation in one line so it can be corrected in three words instead of an hour.
10. Repeats the same failure class inside one session
It assumed twice and verified nothing twice — the same mistake, back to back. That's the one that turns a bad hour into a bad day, because no learning happened between attempts.
The fix: after a miss, name the failure class before the next attempt. If the last error was "assumed the target", the next move is confirming the target, not trying harder in the same direction.
The through-line
Every one of these is the same root cause wearing a different hat: optimising for looking thorough instead of being correct, and substituting cheap signals for real verification.
Which is oddly reassuring, because it means you don't need ten fixes. You need one gate: between "I think I did it" and "I'm telling you I did it", insert a check the model cannot fake. Everything else is downstream of that gap, and that gap is where every bad AI-coding experience actually lives.
The verdict
Sol is better at most of this in my day-to-day — it asks first, it stops when it's done, and it gets terse instead of apologetic when things break. That's why it's my default. But no model gets you out of building the gate.
Put the verification step in your harness, not in your hopes.
Want an AI-assisted build process with verification gates that actually hold? Book a call or see the work.