Trong bối cảnh tốc độ triển khai ngày càng tăng, nút thắt cổ chai thực sự không còn nằm ở việc viết code mà đã dịch chuyển sang khâu đánh giá và kiểm duyệt lượng lớn code được tạo ra bởi AI. Chúng ta không chỉ nói về các 'pull request' (PR) của đồng nghiệp, mà còn là chính những thay đổi (git diff) mà công cụ lập trình AI của bạn vừa hoàn thành.
Ngay cả khi đã tuân thủ các thực hành tốt nhất – như bắt đầu với kế hoạch rõ ràng, chia nhỏ công việc thành nhiều giai đoạn, và gửi các thay đổi nhỏ – lập trình viên vẫn cảm thấy quá tải về mặt nhận thức khi phải đánh giá một đoạn code mà bản thân chưa thực sự suy nghĩ sâu sắc từ đầu. 🤔
Trước và Sau Kỷ Nguyên Trợ Lý Code AI 🤖
Trước khi có các trợ lý code AI, khi được giao một nhiệm vụ, tác giả thường dành thời gian khám phá codebase, suy nghĩ về các giải pháp khác nhau, thử nghiệm và sau đó mới bắt tay vào triển khai. Quá trình này có thể mất nhiều ngày để đúc kết mọi ngữ cảnh cần thiết. Khi cuối cùng tác giả gửi PR, sự tự tin cao hơn hẳn, và việc giải thích từng thay đổi cho đồng nghiệp cũng dễ dàng hơn. 🤝
Phải thừa nhận rằng, ngay cả với sự hỗ trợ của AI, việc hoàn thành các nhiệm vụ lớn vẫn có thể tốn của tác giả nhiều ngày. Thường thì, tác giả sẽ từ chối tất cả các thay đổi do AI tạo ra và bắt đầu lại từ đầu. Sự khác biệt giữa lần làm việc đầu tiên và lần thứ hai không phải là mô hình LLM, mà chính là người đứng sau màn hình. Với nhiều thời gian hơn để củng cố vấn đề mà tác giả đang cố gắng giải quyết, tác giả có thể dẫn dắt AI đến một giải pháp tốt hơn thay vì bị nó dẫn dắt. Đây chính là yếu tố then chốt! 💡
Tại Sao Tôi Lại Từ Chối Code AI? 🚫
Càng ngày, tác giả càng từ chối code AI vì những lý do then chốt sau:
* Không thể giải thích cách tiếp cận bằng lời của mình: Nếu không thể diễn đạt rõ ràng logic và phương pháp của đoạn code, tôi sẽ không chấp nhận nó. Điều này ngụ ý rằng tôi chưa thực sự hiểu sâu sắc giải pháp đó. 🧐 * Diff lớn hơn cả vấn đề: Khi sự thay đổi trong code (git diff) quá lớn so với quy mô của vấn đề cần giải quyết, đó thường là dấu hiệu của một giải pháp không tối ưu hoặc quá phức tạp. * Giới thiệu các tầng trừu tượng (abstractions) khi chưa cần thiết: AI đôi khi có xu hướng tạo ra các tầng trừu tượng phức tạp mà chưa được chứng minh là cần thiết, khiến hệ thống trở nên rườm rà hơn. * Chạy tốt cục bộ nhưng làm hệ thống khó hiểu hơn: Một đoạn code có thể hoạt động hoàn hảo trên máy cục bộ và vượt qua các bài kiểm tra cơ bản, nhưng nếu nó khiến kiến trúc tổng thể khó hiểu, khó bảo trì, thì nó là một giải pháp tồi. 🏗️ * Tin tưởng vào đầu ra của AI hơn là sự hiểu biết của bản thân: Đây là một cạm bẫy lớn. Khi lập trình viên tin tưởng mù quáng vào AI mà bỏ qua sự thẩm định của chính mình, rủi ro tiềm ẩn sẽ rất cao.
Không hiếm khi chúng ta thấy các kỹ sư chấp nhận những thay đổi do AI tạo ra một cách quá nhanh chóng. Đó là lý do tại sao tác giả luôn ủng hộ việc yêu cầu thẩm định bởi con người song song với các công cụ đánh giá của AI. Thực tế cho thấy, code có thể chạy, vượt qua CI (Continuous Integration) một cách xanh mượt, nhưng vẫn có thể là một giải pháp tồi. Kỹ thuật phần mềm từ trước đến nay luôn hướng đến việc triển khai các giải pháp phù hợp, có khả năng mở rộng và dễ dàng phát triển trong tương lai. 🌟
Tác giả đã sử dụng các trợ lý code AI được một thời gian, và dù chúng ấn tượng đến mức nào, chúng vẫn cần một kỹ sư giỏi dẫn dắt để tạo ra những giải pháp thực sự xuất sắc. Đúng vậy, các công cụ này có thể hỗ trợ bạn trong nhiều khía cạnh hơn là chỉ viết code, nhưng điều đó không có nghĩa là chúng có thể hoạt động một cách tự chủ và bền vững ở thời điểm hiện tại. Vai trò của con người – với sự tư duy phản biện và kinh nghiệm – vẫn là không thể thay thế trong kỷ nguyên AI. 🧑💻➡️🚀