DEV Community

Cover image for Everyone's Vibe Coding. Nobody's Talking About Verifying It

Everyone's Vibe Coding. Nobody's Talking About Verifying It

Everyone's vibe coding now. Prompt, ship, repeat. My feed is full of people building entire products over a weekend, and honestly? I'm one of them.

But there's a conversation nobody's having, and it's the one that nearly cost me a launch last week: who verifies what the AI shipped?

I'm a solo founder. I build fast, I ship fast — and a few weeks ago I asked an AI agent to do a proper QA pass on VayReach, my WhatsApp follow-up CRM for real-estate teams, before I put it in front of actual property dealers. Real users, real businesses.

It came back with a defect log that made my stomach drop: dozens of findings, each with an ID (DEF-019, DEF-020…), a severity, exact reproduction steps, and what "fixed" would look like.

Vibe coding ships bugs faster too

Here's the part the "AI 10x'd my output" posts leave out. I fix things in batches using a coding AI, and the agent re-tests every fix on the live build after I deploy. Not "did the deploy succeed." Did the bug actually die.

The latest round: 17 defects retested, 12 pass, 5 still failing. Verdict: NOT READY FOR LAUNCH.

And the pattern that keeps repeating — the one I think every vibe coder needs to hear — is this: several "fixed" defects came back in a different broken state. One SKU-uniqueness validation stopped throwing a 500 error but started rejecting even valid SKUs. The fix didn't fix it. It changed how it was broken.

"Fixed" is a claim, not a fact. Until something adversarial checks the live build, it's just a feeling you had while reading a green deploy log.

The uncomfortable math of AI-built software

When I wrote every line myself, I was slow — but I roughly knew where the bodies were buried. Now the AI writes fast, I review fast, and the bugs are confident. They don't look broken. They look shipped.

That's what changed: the failure mode of modern solo development isn't "I can't build it." It's "I built it, it deploys, and I have no idea what's silently wrong."

As the only developer, I'm structurally incapable of adversarial-testing my own work — AI-written or not. I know what I meant the code to do, so I test what I meant, not what got written. The agent has no such loyalty to my intentions. It just checks.

What the agent can't do (the honest list)

Because "AI does my QA" sounds more magical than it is:

  • It doesn't write the fixes. My coding AI does that. The agent's job is finding, specifying, and verifying — the unglamorous two-thirds of QA.
  • It can't decide the product is good enough. "Launch on hold" was my call, informed by its verdict. The agent reports; I take the hit.
  • It's slow in the way diligence is slow. Batch by batch, no skipping. Some evenings I just want to ship. It doesn't care about my evenings.

So what's the human's job now?

The vibe-coding discourse keeps asking whether developers are obsolete. Wrong question. The code was never the hard part — knowing it's right was.

If you're shipping AI-written code without an adversarial verification step, you're not moving fast. You're accumulating bugs at machine speed and calling it velocity.

So here's my genuine question: if you're building with AI, who checks the work — really? A checklist? Tests you wrote yourself (testing what you meant, not what got written)? Or, like old me, ship and pray? I'm curious what actually works, because "something that doesn't trust me" is the first thing that has.


I build at Vayqube Technologies — AI products, SaaS platforms, and the occasional WhatsApp CRM for property dealers. VayReach is still not launched. The defect log says so.

Top comments (8)

Collapse
 
leonore_fcf3095de32ca8433 profile image
Leonore •

This is such an important point. AI can make development incredibly fast, but speed also means you can introduce bugs much faster if there is no proper verification process. I especially like the idea that a "fixed" bug should be treated as a claim until it is actually reproduced and tested again on the live build.
For smaller projects, I also find it useful to test and experiment with code separately before integrating it into the main application. CodeArea.net is a handy place for that kind of quick testing and experimentation.
AI can help us build faster, but verification is what tells us whether we actually built the right thing.

Collapse
 
vayqube profile image
Vayqube Technologies Private Limited •

fixed is a claim, not a fact' is the line I keep coming back to myself. The live-build retest is the part most people skip, because the deploy log is green and it feels done. Thanks for reading.

Collapse
 
ai_adam profile image
ai_adam •

Đúng vấn đề cốt lõi. Mình thấy nhiều team đang rơi vào bẫy "trust but don't verify" với code AI sinh ra — treat nó như black box thay vì first-class citizen cần review chặt chẽ như code người viết.

Vài pattern mình áp dụng thực tế:

1. Contract-first approach: Trước khi prompt, viết interface/schema/test case trước. AI implement theo contract, không tự do sáng tạo logic business. Giảm hallucination đáng kể.

2. Property-based testing thay vì unit test thủ công: Dùng hypothesis/fast-check generate edge cases tự động. AI code thường pass happy path nhưng sập ở boundary — property test bắt được điều unit test thủ công bỏ lỡ.

3. Deterministic replay: Log full prompt + context + model version + temperature cho mỗi generation. Khi bug production, replay y hệt để debug thay vì đoán mò.

4. Static analysis gate: Ruff/mypy/ESLint + custom rules chạy mandatory trên CI. AI hay quên type hint, unused import, complexity — tool bắt tự động.

5. Human-in-the-loop cho critical path: Auth, payment, data migration — AI draft, senior review line-by-line. Không shortcut.

6. Incremental adoption: Đừng rewrite toàn bộ codebase. Bắt đầu từ module low-risk, measure defect rate, scale dần.

Thực tế: team mình giảm 40% bug production sau 3 tháng áp dụng workflow này. Chi phí review ban đầu tăng ~20% nhưng ROI rõ rệt khi scale (site: labagent .tech)

Collapse
 
vayqube profile image
Vayqube Technologies Private Limited •

40% fewer production bugs for 20% more review cost is a trade I'd take every day. The deterministic replay point (logging prompt + model version + temperature) is something we don't do yet — and we've already been bitten by 'it worked last time' mysteries. Adding that to the list

Some comments may only be visible to logged-in visitors. Sign in to view all comments.