Khá nhiều người tin rằng điểm của AI coding là viết code chất lượng thấp nhanh nhất có thể: tuôn ra slop vừa đủ pass, mở PR khổng lồ và merge không review. Ship it!
Nhưng vấn đề là — LLM rất linh hoạt. Và bạn có thể dùng chúng hiệu quả không kém để viết code chất lượng cao chậm hơn.
Điều này nghe hiển nhiên với tôi ở thời điểm này, đến mức suýt không viết bài. Nhưng có đủ nhiều người tin LLM chỉ tốt cho slop cannon, nên xứng đáng có bài đối chứng.
Mythos đã dạy gì
Nếu Mythos dạy chúng ta điều gì, thì đó là agent LLM rất giỏi tìm bug. Throw chúng vào một codebase đủ nhiều lần, bạn sẽ chìm trong bug đến mức không biết xử lý đâu trước.
Giống nhiều người khác, tôi cũng thấy điều này đúng với non-Mythos model — một số tốt hơn về subtle bug hoặc tránh false positive, nhưng các public model mới nhất từ Anthropic và OpenAI đều đủ giỏi tìm rất nhiều bug trong codebase chưa được scrutinize.
Vấn đề không phải tìm bug, mà là prioritize và validate chúng. Vì lý do đó tôi có Claude skill adapt từ bài viết Milvus — core insight là càng nhiều, càng khác model throw vào PR review, càng ít hallucinate hoặc bug bogus.
Skill multi-agent review
Skill nói (đại ý):
Chạy một Claude sub-agent, Codex, và Cursor Bugbot để tìm bug trong PR này, rank theo critical/high/medium/low. Khi tất cả xong, review findings của chúng, tự research để loại false positive, và viết final report.
Đó là về cơ bản. Bạn có thể thêm định nghĩa “bug” riêng — của tôi có stipulation về KISS, DRY, accessible HTML/JSX, dùng proper index cho SQL query, v.v.
Thực tế của tôi: skill này luôn tìm ra tons bug trong PR, false positive rate gần bằng 0. Tìm nhiều đến mức bạn sẽ chán nản nếu cố fix hết. Range từ critical security/correctness bug đến mundane medium-level perf bug đến low-level “comment này misleading”.
Workflow điển hình
- Có một agent fix tất cả critical và high (với guidance về solution đúng), lặp lại đến hết critical/high
- Skip high/medium chỗ juice không xứng squeeze (vd: 100 dòng code để fix edge case hẹp)
- Abandon PR nếu critical nhiều đến mức cả approach sai từ đầu
Khi dùng technique này, tôi không thấy velocity tăng. Nếu có gì, review process thường tìm ra pre-existing bug, kéo tôi sang side-quest viết unit test và fix subtle flaw có từ trước PR. Đây là ngược với “10x productivity” slop-cannon style mà hầu hết mọi người tưởng tượng khi nghĩ về vibe coding, nhưng tôi thấy rất thỏa mãn.
Cách hay để cải thiện overall codebase health đồng thời học về odd corner của nó. Theo experience của tôi, happy-path của một kiến trúc phức tạp không thú vị bằng failure mode. Và pre-LLM, đây vốn là cách tôi familiar với codebase: hiểu nơi assumption broken, rồi xắn tay áo fix.
Cho ai
Nếu bạn là người skeptical rằng AI coding tốt cho bất kỳ điều gì, tôi nghi bài này không thuyết phục được. Nhưng nếu bạn là dev dùng agent viết PR multi-hundred-line mà chính bạn không hiểu, tôi mời bạn chậm lại và thử style “vibe coding” chậm hơn này. Hỏi agent PR hoạt động ra sao và có thể fail như thế nào. Bảo nó viết Markdown doc với Mermaid chart nếu cần. Dùng skill /grill-me của Matt Pocock cho đến khi bạn hiểu toàn bộ PR front-to-back.
Bạn có thể không “productive” hơn về raw line of code. Bạn có thể đốt một ton token chỉ để biết toàn bộ plan sai từ đầu. Nhưng tôi thấy style coding này là phiên bản super-powered hơn của kiểu programming tôi vốn cố làm trước LLM: cẩn thận, methodical, quality-obsessed, focus vào việc làm tốt hơn cho next coder.
Vậy hít sâu, chậm lại, thử technique này, và xem bạn có thích viết code tốt hơn chậm hơn không.