AI Viết Code Chậm Hơn, Chất Lượng Hơn: Tại Sao Cơn Sốt '10x Productivity' Đang Bị Thách Thức
Mặt Trái Của "10x Developer" Bằng AI
"Vibe coding" — viết code bằng AI, gần như không đọc lại, merge PR ào ào — đang là trào lưu hot nhất trong giới developer năm 2026. Khẩu hiệu "10x productivity" xuất hiện khắp nơi, từ marketing của GitHub Copilot đến các video YouTube ca ngợi AI coding agents.
Nhưng có một bài viết vừa đạt 1.219 điểm trên Hacker News khiến giới developer dừng lại suy nghĩ. Nolan Lawson, một developer kỳ cựu, đặt ngược câu hỏi: nếu AI không dùng để viết code nhanh hơn, mà để viết code tốt hơn thì sao?
Không Phải "Slop Cannon", Mà Là Quality Engine
Thuật ngữ "slop cannon" (súng phun code rác) đang được cộng đồng dùng để mô tả cách nhiều developer dùng AI: ném prompt vào, nhận PR vài trăm dòng, merge không review. Kết quả là một codebase đầy bug, logic lỏng lẻo, và nợ kỹ thuật chồng chất.
Lawson lập luận rằng LLM rất linh hoạt. Có thể dùng chúng để review bug thay vì tạo bug mới.
Theo kinh nghiệm của Lawson, các model mới nhất từ Anthropic và OpenAI có khả năng tìm bug tốt đến mức vấn đề không còn là tìm ra bug nữa, mà là ưu tiên và xác nhận bug. Một codebase chưa được rà soát kỹ thường có quá nhiều bug được phát hiện — developer sẽ chán trước khi sửa hết.
Phương Pháp: Nhiều Model, Nhiều Góc Nhìn
Lawson xây dựng một workflow dựa trên insight cốt lõi: càng nhiều model khác nhau review cùng một PR, càng ít bị hallucination.
Pipeline cụ thể:
- Gửi PR cho nhiều agent cùng lúc: Claude sub-agent, Codex, và Cursor Bugbot
- Mỗi agent xếp hạng bug theo mức: critical / high / medium / low
- Tự review lại toàn bộ các phát hiện, gạch bỏ false positives
- Chỉ sửa critical + high, lặp lại cho đến khi hết critical/high
Kết quả theo Lawson: false positive rate gần như bằng 0.
Điểm thú vị: workflow này còn giúp phát hiện bug có sẵn từ trước — những bug đã tồn tại trong codebase trước khi PR được tạo. Lawson thường xuyên rơi vào "side-quest" viết unit test và sửa những lỗi cũ.
"Slow" Không Có Nghĩa Là Kém Hiệu Quả
Có một nghịch lý thú vị ở đây. "10x productivity" về mặt số dòng code không đồng nghĩa với 10x giá trị. Một PR 500 dòng merge trong 30 phút nhưng tạo ra 3 bug production có thể gây thiệt hại gấp nhiều lần thời gian "tiết kiệm" được.
Ngược lại, một PR 100 dòng mất 3 giờ review kỹ bằng AI có thể:
- Không có bug critical nào
- Phát hiện và sửa luôn 2 bug cũ trong codebase
- Tạo unit test đầy đủ
- Để lại tài liệu Markdown + Mermaid diagram cho đồng đội
Luồng phát triển này chậm hơn nhưng tích lũy chất lượng. Mỗi PR không chỉ thêm tính năng mới — nó còn cải thiện sức khỏe tổng thể của codebase.
Khi Nào Nên Dùng AI "Chậm"?
Flow này phù hợp nhất với:
- Dự án production có rủi ro cao khi bug lọt qua
- Codebase phức tạp mà developer chưa quen hết mọi ngóc ngách
- Pull request lớn cần người review nhưng team thiếu người
- Refactor lớn — AI tìm những chỗ giả định bị phá vỡ
Ngược lại, prototype nhanh hoặc dự án cá nhân không cần mức review này.
Một Số Kỹ Thuật Cụ Thể
Ngoài pipeline review đa model, Lawson gợi ý thêm vài kỹ thuật bổ trợ:
Yêu cầu AI giải thích PR của chính nó. Trước khi merge, hỏi agent: "Giải thích cách PR này hoạt động và nó có thể fail ở đâu?" Nếu AI không giải thích được rõ ràng — đó là dấu hiệu nguy hiểm.
Dùng Mermaid diagram. Yêu cầu AI vẽ sequence diagram hoặc flow chart cho logic phức tạp. Một bức hình đáng giá ngàn dòng code — và giúp người review sau này hiểu nhanh hơn.
Skill "grill-me". Matt Pocock tạo một skill cho phép AI "chất vấn" code của chính nó — như một reviewer khó tính. Kỹ thuật này giúp phát hiện giả định sai trước khi code vào production.
Định nghĩa "bug" rõ ràng. Prompt của Lawson còn bao gồm các tiêu chí KISS (Keep It Simple, Stupid), DRY (Don't Repeat Yourself), HTML/JSX chuẩn accessibility, SQL query phải có index phù hợp.
Go: Ngôn Ngữ Được AI "Yêu Thích" Nhất?
Một insight thú vị khác từ cộng đồng: Go đang nổi lên như ngôn ngữ lý tưởng để làm việc cùng AI. Lý do không phải vì Go "tốt nhất", mà vì:
- Corpus huấn luyện đồng nhất: Chỉ có một cách viết Go chuẩn (gofmt, go vet, golangci-lint)
- Concurrency model đơn giản: Goroutines — không phải lo "màu sắc hàm" như async/await
- Standard library mạnh:
net/httpchạy phần lớn microservices trên internet - Ít fragmentation: Không như JavaScript với hàng chục framework chồng chéo
Coding agent làm việc với Go cho ra đầu ra nhất quán hơn hẳn so với JavaScript hay Python — hai hệ sinh thái bị phân mảnh nặng.
Tổng Kết
AI coding không có một cách dùng duy nhất. "Vibe coding" — code nhanh, ít review — phù hợp cho prototype. Nhưng với production, cách tiếp cận của Nolan Lawson đưa ra một tầm nhìn khác: AI là reviewer, không phải code monkey.
Dùng AI để tìm bug, phân tích code, và đảm bảo chất lượng. Chậm hơn — nhưng code tốt hơn. Đồng đội biết ơn hơn.
Câu hỏi đặt ra: dùng AI để viết code nhanh hơn, hay viết code tốt hơn?
Tham khảo: