Chi phí để nói ‘có’ đã thay đổi: Tư duy kỹ thuật trong kỷ nguyên AI

Trong nhiều năm, bản năng của các kỹ sư phần mềm khi đối mặt với những yêu cầu tính năng nhỏ là sự thận trọng. Chúng ta thường đặt câu hỏi: Liệu nó có thực sự cần thiết? Nó có làm thay đổi các cam kết hệ thống hiện tại không? Bởi lẽ, một thay đổi nhỏ cũng có thể kéo theo hàng loạt công việc như viết test, lập kế hoạch triển khai và gánh vác trách nhiệm vận hành lâu dài.

Khi cuộc tranh luận đắt đỏ hơn cả bản patch

Trước đây, việc bắt tay vào viết code là bước tốn kém nhất. Bạn phải dừng công việc hiện tại, nạp ngữ cảnh vào đầu, thực hiện thay đổi, viết test và dò lỗi. Tuy nhiên, hiện nay, các AI agent có thể tạo ra bản patch đầu tiên chỉ trong vài phút. Thay vì dành hàng giờ tranh luận về rủi ro, tại sao không sử dụng AI để tạo ra một bản nháp (diff) thực tế?

Bản patch đầu tiên là công cụ kiểm chứng, không phải sản phẩm

Sai lầm phổ biến là coi code do AI tạo ra là sản phẩm cuối cùng. Thay vào đó, hãy xem nó là một công cụ kiểm chứng (probe) để trả lời các câu hỏi thực tế:

• Nó có làm thay đổi cấu trúc hệ thống hay chỉ gói gọn trong các file dự kiến?
• Các test case có dễ dàng thực hiện không?
• Nó có tuân thủ các abstraction hiện tại hay không?

Nếu bản diff chỉ gồm vài dòng code và vượt qua các bài kiểm tra, việc chấp nhận nó trở nên đơn giản hơn nhiều. Nếu nó tác động đến các phần nhạy cảm như auth middleware, bạn đã xác định được độ phức tạp thực sự của yêu cầu chỉ trong 30 phút thay vì hai ngày tranh luận.

Viết code rẻ, nhưng sở hữu thì không

Đây là sự khác biệt cốt lõi trong kỷ nguyên AI: Một thay đổi chỉ thực sự rẻ khi con người có thể tự tin review và chịu trách nhiệm về kết quả đó.

AI giúp giảm chi phí sản xuất code, nhưng không làm giảm chi phí sở hữu. Những thay đổi liên quan đến chính sách bảo mật, thanh toán, quyền riêng tư hoặc các hợp đồng sản phẩm vẫn luôn đòi hỏi sự kiểm soát chặt chẽ. AI không thay thế tư duy con người, nó chỉ giúp việc đưa ra quyết định dựa trên bằng chứng trở nên rẻ hơn.

Định giá sự không chắc chắn

Kỹ sư giỏi trong thời đại mới không phải là người nói ‘có’ với mọi thứ, cũng không phải người phản đối mọi yêu cầu. Họ là những người biết cách định giá sự không chắc chắn một cách nhanh chóng. Thay vì đoán định, hãy yêu cầu một bản thử nghiệm có giới hạn (constrained attempt). Nếu AI không thể tạo ra một bản patch sạch trong các ràng buộc đó, bạn đã biết yêu cầu đó phức tạp hơn vẻ ngoài của nó.

Chi phí để sản xuất code đã giảm, nhưng chi phí để hiểu, review và sở hữu nó thì vẫn vậy. Đã đến lúc chuyển dịch trọng tâm từ việc hỏi ‘đây có phải là thêm việc không?’ sang ‘chi phí thực sự nằm ở đâu?’ và đôi khi, cách tốt nhất để tìm ra câu trả lời là thử nghiệm nó một cách có kiểm soát.

Nguồn tham khảo: GitHub Blog