Nhóm kỹ thuật của Agoda đã dành nhiều thời gian để thúc đẩy các công cụ lập trình AI, sau đó tiến hành đánh giá lại. Kết luận khiến nhiều người không khỏi bất an:
Năng suất của từng lập trình viên tăng lên, nhưng tốc độ bàn giao tổng thể của dự án hầu như không thay đổi.
Đây không phải vấn đề riêng của Agoda. Faros AI đã tổng hợp dữ liệu từ nhiều công ty và đưa ra những con số đáng chú ý:
Các nhóm có tỷ lệ áp dụng AI cao, số lượng PR được merge tăng 98%, số lượng nhiệm vụ hoàn thành tăng 21%. Nhưng đồng thời, thời gian review PR tăng 91%.
Sản lượng tăng, nhưng Review chậm lại. Hai hiệu ứng gần như triệt tiêu lẫn nhau.
Điểm nghẽn thực sự là gì
Nhóm kỹ thuật Agoda nhận định: vấn đề nằm ở chỗ "viết code chưa bao giờ là điểm nghẽn chính trong bàn giao phần mềm".
AI hoàn thiện code giúp việc viết code nhanh hơn. Nhưng viết code chỉ là một khâu trong dây chuyền, phía trước nó có phân tích yêu cầu, thiết kế hệ thống, thống nhất giải pháp kỹ thuật, phía sau nó có Code Review, kiểm thử, tích hợp, triển khai.
Bạn tăng tốc khâu ở giữa lên ba lần, không có nghĩa là cả dây chuyền nhanh gấp ba.
Khi AI khiến sản lượng code bùng nổ, khả năng "tiêu hóa lượng code này" lại trở thành điểm nghẽn mới:
- Lượng code trong mỗi PR lớn hơn (code do AI tạo ra thường không được tinh gọn)
- Code Review phải xem xét nhiều thứ hơn
- Nhưng thời gian của các kỹ sư cao cấp là có hạn
Điểm nghẽn từ "viết code chậm" chuyển sang "review code chậm", nhịp độ bàn giao thực tế không được cải thiện.
Vấn đề sâu xa hơn: Specification
Kỹ sư Leonardo Stern của Agoda đi xa hơn, cho rằng tài nguyên thực sự khan hiếm đã dịch chuyển lên trên: không phải Review, mà là Specification — khả năng chuyển đổi các yêu cầu kinh doanh mơ hồ thành các đặc tả kỹ thuật rõ ràng, khả thi.
Trước đây, kỹ sư dành nhiều thời gian để viết code, specification có thể mơ hồ một chút, vì "viết rồi sẽ rõ dần".
Bây giờ, bạn đưa một yêu cầu mơ hồ cho AI, AI sẽ tạo ra code "trông có vẻ dùng được" nhưng đi sai hướng. Sau đó bạn quay lại sửa spec, AI lại tạo lại, lặp đi lặp lại nhiều vòng. Bề ngoài sản lượng code rất cao, nhưng thực chất là đang dùng code để thử sai, hiệu quả không cao.
Đặc tả yêu cầu có độ trung thực cao đang trở thành sản phẩm bàn giao kỹ thuật cốt lõi. Không phải bản thân code, mà là "cách mô tả cần cái gì".
Phương pháp "Hộp xám" của Stern
Stern đề xuất một phương pháp làm việc gọi là "hộp xám", nằm giữa hai thái cực:
- Hộp trắng: Xem xét từng dòng code do AI tạo ra, bạn hoàn toàn chịu trách nhiệm về chi tiết triển khai
- Hộp đen: AI viết xong đưa thẳng lên môi trường production, bạn chịu trách nhiệm về kết quả nhưng không quan tâm quy trình
- Hộp xám: Can thiệp ở hai điểm mấu chốt — viết spec chính xác và xác minh kết quả có đúng spec hay không
Logic cốt lõi của hộp xám là: bạn không cần hiểu AI dùng phương pháp nào để giải quyết vấn đề, nhưng phải có khả năng nói rõ "thế nào là giải quyết xong" và xác minh được nó thực sự đã giải quyết xong.
Bản chất của phương pháp này là tập trung thời gian và sự chú ý của kỹ sư vào phần "AI kém nhất" — định nghĩa ý định và xác minh kết quả, thay vì chi tiết triển khai.
Vai trò của kỹ sư đang đi về đâu
Trong giả định truyền thống về vai trò kỹ sư phần mềm, "viết code tốt" là năng lực cốt lõi.
Giờ đây giả định này đang bị lung lay. Khi AI có thể viết ra code chất lượng chấp nhận được, sự khan hiếm của kỹ sư đến từ đâu?
Từ thực tiễn của các công ty như Agoda, câu trả lời đang đi theo hướng này:
- Người có thể chuyển đổi vấn đề kinh doanh thành đặc tả kỹ thuật chính xác
- Người có thể thiết kế phương án xác minh hiệu quả
- Người có thể đánh giá code do AI tạo ra có thực sự giải quyết đúng vấn đề hay không
Đây không phải là "khả năng viết code không còn quan trọng" — mà là khả năng viết code từ tài nguyên khan hiếm đã trở thành ngưỡng cơ bản, sự khác biệt thực sự nằm ở thượng nguồn.
Theo lời Stern: Quyền lực của con người đang dịch chuyển từ "viết code" sang "định nghĩa ý định". Đây là sự dịch chuyển lên tầng trừu tượng cao hơn, không phải sự biến mất của kỹ năng.
Quản lý nên nhìn nhận vấn đề này thế nào
Đối với các nhà quản lý kỹ thuật, nghiên cứu của Agoda đưa ra một gợi ý hành động trực tiếp: Đừng dùng sản lượng code để đo lường giá trị của AI.
Số lượng PR, số dòng code, số nhiệm vụ hoàn thành — tất cả các chỉ số này sẽ trở nên đẹp hơn nhờ công cụ AI. Nhưng nếu chức năng bàn giao không nhiều hơn, không nhanh hơn, chất lượng không tốt hơn, thì những con số này chỉ là con số.
Các chỉ số thực sự đáng theo dõi là: chu kỳ đưa tính năng lên production, tỷ lệ lỗi trên môi trường production, thời gian từ yêu cầu đến bàn giao đầu cuối. Những con số này mới cho bạn biết AI có thực sự giúp ích cho nhóm hay không, hay chỉ giúp nhóm "làm đẹp số liệu" trên GitHub.
Lần tới nếu ai đó mang số lượng PR merge để báo cáo ROI của công cụ AI, bạn có thể hỏi lại: Vậy thời gian Review thì sao?
Nguồn tham khảo: CocoLoop, AI Coding Assistants Haven't Sped Up Delivery Because Coding Was Never the Bottleneck (InfoQ)