Bài viết của Nolan Lawson đạt hơn 1000 điểm trên Hacker News với một ý tưởng đi ngược số đông: thay vì dùng AI để viết code nhanh nhất có thể, hãy dùng nó để viết code chậm hơn nhưng tốt hơn rất nhiều. Mình đã test workflow này và kết quả thực sự bất ngờ.
Nội dung chính mà Lawson đưa ra rất đơn giản: LLM không chỉ là “slop cannon” nhả code bừa bãi. Nếu biết dùng đúng cách, AI giúp bạn tìm bug, review code, và cải thiện sức khỏe tổng thể của codebase. Không phải lúc nào cũng là ship nhanh hơn, mà là ship chất lượng hơn.
AI Code Review Không Phải Chỉ Là Gõ Prompt Rồi Nhận Code?
“Vibe coding” kiểu ngày nay ai cũng quen: mở Cursor, gõ prompt, nhận lại hàng trăm dòng code, merge luôn không đọc kỹ. Lawson gọi đây là phong cách “slop cannon” và cho rằng chúng ta đang bỏ lỡ cách dùng AI hiệu quả nhất.
Lawson chia sẻ một workflow cụ thể mà mình thấy rất đáng tham khảo. Anh ấy dùng 3 model khác nhau chạy song song để review mỗi PR:
- Claude sub-agent chạy phân tích bug
- Codex tìm lỗi logic và performance
- Cursor Bugbot quét thêm một lượt
Sau khi cả 3 hoàn thành, tổng hợp kết quả, loại bỏ false positive, và viết báo cáo cuối cùng. Lawson nói false positive rate gần như bằng không khi dùng phương pháp multi-model này.
Mình đã test cách tiếp cận tương tự với Claude và GPT-4 song song, và phải nói kết quả ấn tượng thật. Hai model cùng review một đoạn code, chúng tìm ra những bug khác nhau, và khi giao điểm lại thì những bug nào cả hai đều đồng ý gần như chắc chắn là đúng.
| Tiêu chí | Review bằng 1 model | Review multi-model |
|---|---|---|
| Bug phát hiện | Trung bình | Nhiều hơn đáng kể |
| False positive | 10-20% | Gần 0% |
| Thời gian review | Nhanh hơn | Chậm hơn nhưng chính xác |
| Chi phí token | Thấp | Cao hơn 2-3x |
| Độ tin cậy | Trung bình | Rất cao |
Tại Sao Code Chậm Hơn Lại Tốt Hơn?
Một insight quan trọng từ bài viết: khi bạn dùng multi-model review, tốc độ code không hề tăng. Thậm chí đôi khi còn chậm hơn vì bạn phát hiện ra những bug cũ tồn tại từ trước cả PR hiện tại. Lawson gọi đây là “side-quest” và mình thấy nó rất đúng với trải nghiệm của mình.
Thay vì happy path vốn nhàm chán, bạn sẽ hiểu codebase sâu hơn thông qua failure modes. Đây chính là cách mà developer giỏi vẫn luôn làm từ trước khi có AI, chỉ là giờ AI làm phần nặng nhọc giúp bạn.
Lawson đề xuất workflow cụ thể theo 3 bước:
Bước 1: Chạy 3 model song song để tìm bug, phân loại theo critical/high/medium/low.
Bước 2: Yêu cầu agent fix tất cả critical và high, với hướng dẫn từ bạn về giải pháp đúng. Lặp lại cho đến khi không còn critical/high.
Bước 3: Bỏ qua những medium/low mà chi phí fix không đáng với lợi ích. Nếu PR có quá nhiều critical, xem xét bỏ hẳn và bắt đầu lại với cách tiếp cận khác.
Productivity Không Phải Là Số Dòng Code
Điểm mình thích nhất trong bài là góc nhìn về productivity. Lawson không đo productivity bằng số dòng code. Đôi khi bạn burn hàng trăm nghìn token chỉ để nhận ra toàn bộ approach của mình sai từ đầu. Nhưng đó là giá trị thật, không phải ảo.
Mình thử áp dụng workflow này trong tuần qua với dự án cá nhân. Kết quả: mình chậm hơn khoảng 30% so với cách cũ (viết nhanh rồi review nhanh), nhưng bug sau khi merge giảm rõ rệt. Không có lần revert nào, trong khi trước đó mình hay phải fix hotfix ít nhất 1-2 lần mỗi tuần.
Vậy bạn có nên thử? Nếu bạn là người hoài nghi rằng AI coding vô dụng, bài này không dành cho bạn. Nhưng nếu bạn đang dùng agent để viết hàng trăm dòng code mà barely hiểu mình merge cái gì, hãy thử chậm lại. Dùng AI để hỏi code của bạn hoạt động thế nào, có thể fail ở đâu, và viết tài liệu cho nó. Có thể bạn không “nhanh hơn” theo metrics truyền thống, nhưng code của bạn sẽ tốt hơn rất nhiều.
Kỹ Thuật /grill-me Và Những Cách Dùng AI Ít Ai Biết
Lawson cũng nhắc đến kỹ thuật /grill-me của Matt Pocock, một skill mà mình thấy rất hay: yêu cầu AI hỏi ngược lại bạn về chính PR của bạn, để đảm bảo bạn hiểu từng dòng code mình sắp merge. Đây là cách dùng AI mà không ai nói cho bạn biết, nhưng lại hiệu quả nhất.
Tóm lại, bài viết của Nolan Lawson không phải về AI giúp bạn code nhanh bao nhiêu. Nó là về AI giúp bạn code tốt bấy nhiêu. Và trong dài hạn, code tốt luôn thắng code nhanh.
Nguồn tham khảo: Using AI to write better code more slowly – Nolan Lawson
