Bug dễ chịu nhất là bug crash.
App trắng màn hình. Command fail. Build đỏ. Database báo lỗi. Bạn biết có vấn đề.
Bug nguy hiểm hơn là bug không crash. App chạy. Số hiện ra. Chart đẹp. Report xuất được. Nhưng logic sai.
Đó là silent failure: code chạy đúng cú pháp nhưng sai nghiệp vụ.
AI rất giỏi tạo thứ trông hợp lý
Với vibe coding, bạn thường không đọc từng dòng code. Bạn nhìn output:
- Form submit được.
- Dashboard có số.
- Email template render đúng.
- Calculator trả kết quả.
- Safety checklist có trạng thái.
- Schedule tự động xếp ca.
Nếu output “có vẻ đúng”, não người dễ thở phào.
Nhưng AI có thể bịa biến còn thiếu, chọn công thức gần đúng, giả định sai domain, đổi đơn vị, bỏ edge case, hoặc dùng rule cũ. Tất cả vẫn có thể chạy.
Syntax pass không phải correctness.
Silent failure đặc biệt nguy hiểm ở domain có đáp án thật
Một paper về LLM-generated code cho construction safety gọi thẳng rủi ro này: code có thể compile và execute nhưng áp dụng mathematical safety logic sai. Paper cũng chỉ ra prompt/persona ít formal hơn có thể làm tăng data hallucination, tức AI tự bịa biến đầu vào còn thiếu.
Đây không chỉ là chuyện xây dựng.
Silent failure nguy hiểm trong:
- Finance: tính phí, thuế, lãi, discount sai.
- Healthcare: phân loại triệu chứng sai.
- Scheduling: xếp ca vi phạm constraint.
- Education: tính điểm sai.
- Compliance: bỏ rule bắt buộc.
- Logistics: tính tồn kho hoặc lead time sai.
- Safety: threshold sai nhưng report vẫn xanh.
Nếu app chỉ là todo list cá nhân, silent failure ít nguy hiểm hơn. Nếu app đưa ra quyết định thật, silent failure là vùng đỏ.
Non-tech dễ test nhầm
Người không code thường test bằng câu hỏi:
Nó có chạy không?
Câu hỏi đúng hơn:
Nó có trả đúng đáp án đã biết không?
Nếu bạn không có đáp án mẫu, bạn chỉ đang kiểm UI. Bạn chưa kiểm logic.
Ví dụ app tính giá booking cần test:
- 1 khách, 1 ngày, không coupon.
- 2 khách, weekend surcharge.
- Coupon hết hạn.
- Refund một phần.
- Tax rounding.
- Currency khác.
- Booking bị cancel.
Mỗi case cần expected result viết trước. Không viết sau khi AI trả output.
Golden cases trước, prompt sau
Trước khi nhờ agent build logic, viết vài golden cases:
Use these fixed examples as acceptance tests:
- Input A must return 120
- Input B must return 0 because user is not eligible
- Input C must fail validation
- Input D must round down to 2 decimal places
Do not change expected outputs unless I explicitly approve.
Sau khi agent build xong:
Run the golden cases.
For each case, show input, expected output, actual output, and pass/fail.
If any expected value is ambiguous, mark unknown.
Điểm quan trọng: expected output phải đến từ bạn hoặc domain expert, không phải từ AI tự tạo rồi tự chấm.
Đừng để AI tự viết đề rồi tự chấm
Một anti-pattern rất phổ biến:
- Nhờ AI viết feature.
- Nhờ AI viết test.
- Nhờ AI chạy test.
- AI nói pass.
Nếu test cũng dựa trên cùng assumption sai, pass không có nhiều nghĩa.
Với business logic, cần tách vai:
- Builder agent: viết code.
- Skeptic agent: tìm assumption sai.
- Human/domain owner: cung cấp expected examples.
- Tooling: chạy test thật.
Ngay cả khi chỉ có một agent, hãy prompt nó đổi vai:
Now act as a skeptical domain reviewer.
Do not edit code.
Find assumptions in this implementation.
List cases where the code can run but return a wrong business result.
Dấu hiệu silent failure
Cẩn thận nếu thấy:
- AI tự thêm default value cho field chưa có.
- Logic có nhiều magic number.
- Không có unit conversion rõ.
- Không có rounding rule.
- Không có timezone rule.
- Không có ownership hoặc tenant rule.
- Test chỉ kiểm component render.
- Report không có expected vs actual.
- Agent nói “should work” thay vì đưa evidence.
Những dấu hiệu này không chứng minh bug. Nhưng chúng nói rằng bạn chưa verify đủ.
Chốt lại
Vibe coding không hỏng nhất khi app crash. Crash còn dễ thấy.
Nó hỏng nhất khi app chạy mượt, UI đẹp, output hợp lý, và logic sai trong im lặng.
Muốn tránh silent failure, đừng chỉ test “có chạy không”. Hãy test bằng golden cases có đáp án biết trước. Với domain quan trọng, đừng để AI tự bịa đề, tự làm bài, rồi tự chấm mình pass.