Lập Trình Cùng AI: Một Quy Trình Thực Tế
Câu trả lời trung thực cho câu hỏi “AI có viết code cho bạn không” là: đôi khi, cho một phần công việc, và chỉ khi bạn thiết lập để nó thất bại một cách rõ ràng thay vì âm thầm. Đây là một ngày làm việc thực tế, không phải phiên bản trong slide thuyết trình.
Nơi nó thực sự phát huy tác dụng
Dựng khung, không phải kiến trúc. Component mới, endpoint mới, file test mới — những phần nhàm chán, lặp khuôn mẫu trong một codebase chính là thứ các công cụ này làm tốt, vì chúng đã thấy hàng nghìn phiên bản của cùng một dạng cấu trúc. Nếu bạn nhờ nó thiết kế ranh giới giữa các service, bạn sẽ nhận được thứ gì đó nghe có vẻ hợp lý nhưng sai. Nếu bạn nhờ nó dựng khung một endpoint CRUD khớp với ba endpoint có sẵn, nó sẽ làm rất tốt.
Bước đầu tiên với một lỗi bạn có thể tái hiện. Đưa cho nó một test đang fail và một stack trace, nó thường nhanh hơn bạn trong việc khoanh vùng lỗi nằm ở đâu, đặc biệt trong một codebase bạn không viết. Nó yếu hơn nhiều với các lỗi chỉ xuất hiện dưới tải cao, trên production, hoặc do race condition — bất cứ điều gì đòi hỏi suy luận về thời gian, không chỉ về code.
Đọc code bạn không viết. Đây có thể là cách dùng có giá trị cao nhất: đưa nó vào một module lạ và hỏi “giải thích cho tôi cái này làm gì và vì sao được cấu trúc như vậy” biến 45 phút đọc code thành 5 phút trò chuyện với các câu hỏi tiếp theo.
Viết test cho các trường hợp nhàm chán. Edge case, kiểm tra null, các test validate input mà không ai thích viết — đây chính xác là loại công việc lặp lại, theo khuôn mẫu, được hưởng lợi từ việc không phải do một người mệt mỏi viết lúc 5 giờ chiều.
Nơi vẫn cần dây cương
- Bất cứ gì liên quan đến xác thực, thanh toán, hoặc migration đều phải đọc từng dòng, không ngoại lệ. Kiểu thất bại ở đây không phải là “code hơi sai”, mà là “code sai một cách tự tin, trông hoàn toàn bình thường khi review.”
- Refactor nhiều file cần một con người thực sự lần theo call graph, không tin vào bản tóm tắt những gì đã thay đổi.
- Code nhạy cảm về hiệu năng — gợi ý của AI tối ưu cho “trông có vẻ đúng chuẩn”, không phải “chạy nhanh với tải thực tế của bạn.”
Quy trình thực sự hiệu quả
- Tự viết chữ ký hàm và một dòng comment mô tả ý định — đây là 10% đòi hỏi thực sự hiểu vấn đề.
- Để công cụ soạn phần thân hàm.
- Đọc từng dòng trước khi chạy. Không lướt qua — đọc thật sự.
- Nhờ nó viết test sau khi bạn đã chỉnh sửa phần triển khai, không phải trước, để test phản ánh đúng những gì code thực sự làm thay vì những gì bản nháp đầu tiên đoán rằng nó nên làm.
- Với bất cứ thứ gì nhạy cảm, làm thêm một lượt hỏi riêng “cái gì có thể làm hỏng cái này” — nó thường giỏi tự “công kích” kết quả của chính mình hơn là làm đúng ngay từ đầu.
Phiên bản thực tế của “AI viết code” gần giống với việc lập trình cặp đôi với một kỹ sư junior rất nhanh, đọc rất nhiều, nhưng không có bối cảnh gì về hệ thống cụ thể của bạn và sẽ tự tin đoán bừa khi không biết. Đối xử với nó đúng như vậy, nó sẽ là một trong những công cụ có đòn bẩy cao nhất hiện có. Đối xử với nó như một nhà tiên tri, và bạn sẽ ship một lỗi với commit message rất gọn gàng.