Các tiêu đề báo chí cứ liên tục nói rằng AI sẽ khiến các nhà phát triển phần mềm trở nên lỗi thời. Tôi không tin điều đó. Rủi ro thực sự không phải là máy móc sẽ tiếp quản việc kỹ thuật. Rủi ro là các kỹ sư sẽ ngừng thực hiện công việc tư duy khó khăn.

Phần mềm chưa bao giờ chỉ là việc gõ cú pháp. Nó luôn là việc nắm giữ sự phức tạp trong tâm trí, hiểu các chế độ lỗi (failure modes) và đưa ra các đánh đổi khi không có lựa chọn nào là hoàn hảo. AI đã thay đổi tốc độ chúng ta tạo ra mã nguồn, nhưng nó không thay đổi lý do tại sao chúng ta cần con người tham gia vào quy trình. Nếu có gì thay đổi, thì nó đã làm cho tư duy mạch lạc trở nên giá trị hơn và khan hiếm hơn.

Bản thảo đầu tiên không phải là kỹ thuật

Tôi thấy ngày càng nhiều lập trình viên junior coi ChatGPT hay Claude như một kỹ sư senior ngồi ở chiếc ghế bên cạnh. Họ dán mô tả ticket vào, sao chép câu trả lời, chạy thử nghiệm và commit. Nếu nó biên dịch được, nhiệm vụ coi như xong. Quy trình này diễn ra nhanh chóng, không chút trở ngại, nhưng cũng đầy nguy hiểm.

Sử dụng AI không phải là vấn đề. Tôi có dùng nó. Hầu hết các kỹ sư năng suất nhất mà tôi biết đều dùng nó. Vấn đề bắt đầu khi AI trở thành kỹ sư duy nhất trong phòng. Chấp nhận giải pháp đầu tiên chỉ vì nó hoạt động không phải là làm kỹ thuật. Đó là việc phó mặc sự phán đoán cho một mô hình vốn không hiểu người dùng của bạn, các ràng buộc kinh doanh của bạn, hay lần cuối cùng hệ thống của bạn bị sập lúc 2 giờ sáng.

Các mô hình ngôn ngữ lớn đưa ra câu trả lời với sự tự tin đến mức đáng lo ngại ngay cả khi chúng hoàn toàn sai. Một kỹ sư đã yêu cầu AI thiết kế một kiến trúc có khả năng mở rộng. Mô hình đã trả về một đề xuất chi tiết, đầy uy tín nhưng lại được xây dựng hoàn toàn dựa trên một tính năng không hề tồn tại trong sản phẩm thực tế. Nó trông có vẻ đúng. Nó nhất quán về mặt nội bộ. Nhưng nó cũng vô dụng. Nguy hiểm không chỉ nằm ở việc AI ảo tưởng (hallucinate). Nguy hiểm là quá nhiều người hiện nay tin vào những sự ảo tưởng đó vì họ không còn đủ ngữ cảnh để nhận ra lời nói dối.

Bạn học hỏi từ những trở ngại

Khi nghĩ về điều gì đã biến tôi từ một lập trình viên junior thành một người có thể làm chủ một hệ thống, tôi không nhớ những cú pháp mà mình đã học thuộc lòng. Tôi nhớ những lần hệ thống ngừng hoạt động (outages). Tôi nhớ những truy vấn chậm mà tôi phải tự tay dò tìm, những lỗi tranh chấp (race conditions) chỉ xuất hiện dưới tải thực tế (production load), và những lần triển khai (deployments) bị lỗi vì môi trường cục bộ của tôi chẳng giống gì với thế giới thực.

Gỡ lỗi (Debugging) chính là nơi việc học diễn ra. Khi bạn thực hiện từng bước qua mã nguồn một cách thủ công, bạn sẽ thấy tại sao các hệ thống thực sự thất bại. Bạn khám phá ra nơi các nút thắt cổ chai (bottlenecks) xuất hiện. Bạn học được cách một kiến trúc vận hành khi bạn chuyển từ một bản demo với mười người dùng sang một hệ thống thực tế xử lý mười nghìn yêu cầu đồng thời. Bạn thấm nhuần, bằng chính trải nghiệm xương máu, sự khác biệt giữa môi trường thực tế và một bản demo được lập trình sẵn một cách mượt mà.

Không có kiến thức nào trong số đó đến từ việc chấp nhận một câu trả lời được tạo sẵn. Nó đến từ việc vật lộn với vấn đề. Nếu AI loại bỏ mọi sự khó khăn, nếu nó viết mã, sửa lỗi và giải thích các thất bại, thì chính xác thì thế hệ lập trình viên tiếp theo sẽ tích lũy kinh nghiệm như thế nào? Kinh nghiệm không phải là một chứng chỉ bạn có thể tải về. Nó là những vết sẹo bạn xây dựng được từ các sự cố thực tế và những lần triển khai thất bại. Loại bỏ đi những trở ngại cũng chính là loại bỏ đi sự trưởng thành.

Sự phán đoán quan trọng hơn việc tạo lập

Trong một thời gian, ngành công nghiệp này đã coi kỹ thuật đặt câu lệnh (prompt engineering) là một kỹ năng mới mẻ và "hot" để đưa vào sơ yếu lý lịch. Điều đó đã hoàn toàn sai lầm. Khả năng giá trị nhất trong một môi trường bão hòa AI không phải là tạo ra các lựa chọn. Mà là biết nên bác bỏ những gợi ý nào.

Những kỹ sư giỏi nhất mà tôi làm việc cùng không phải là những người viết nhiều prompt nhất. Họ là những người đặt ra những câu hỏi khó nhất. Họ biết khi nào một lần tái cấu trúc (refactor) sẽ tạo ra một sự phụ thuộc ẩn. Họ nhận ra khi nào một bài kiểm tra được tạo ra chỉ bao phủ các trường hợp thông thường (happy path) mà bỏ qua các trường hợp biên (edge case) có thể làm hỏng dữ liệu khách hàng. Họ có thể nhìn vào một đoạn mã hoàn toàn hợp lệ và nói: "Đoạn mã này đúng, nhưng kiến trúc thì sai."

Câu nói cuối cùng đó chính là ranh giới phân chia giữa hai nền văn hóa rất khác biệt. Kỹ thuật có sự hỗ trợ của AI (AI-assisted engineering) có nghĩa là bạn sử dụng máy móc để phác thảo khung sườn, khám phá các khuôn mẫu hoặc tự động hóa các mã lặp lại (boilerplate), trong khi bộ não của bạn xử lý các quyết định. Kỹ thuật phụ thuộc vào AI (AI-dependent engineering) có nghĩa là bạn tin tưởng để máy móc cầm lái. Nhiều tổ chức đang âm thầm trôi về phía sự phụ thuộc vì nó mang lại cảm giác nhanh hơn trong ngắn hạn. Nhanh không đồng nghĩa với đúng.

Những công việc vẫn thuộc về con người

AI có thể đẩy nhanh hầu hết mọi giai đoạn trong vòng đời phát triển, nhưng vẫn có những thực hành cốt lõi cần phải do con người nắm giữ một cách vững chắc. Thiết kế hệ thống đòi hỏi việc cân bằng giữa các ràng buộc đối nghịch nhau: chi phí, độ trễ, độ tin cậy và khả năng bảo trì trong tương lai. Việc đánh giá kiến trúc phụ thuộc vào trí nhớ tổ chức và khả năng dự đoán các tác động bậc hai. Việc cố vấn đòi hỏi một người đã thực sự trải qua những kịch bản lỗi mà họ đang cảnh báo bạn. Sự hiểu biết sâu sắc về sản phẩm đến từ việc trò chuyện với người dùng và quan sát hành vi thực tế, chứ không phải từ việc đọc dữ liệu huấn luyện.

Phán đoán kỹ thuật là tổng hòa của những trải nghiệm đó. Đó là tiếng nói thầm lặng mách bảo bạn rằng một đợt di chuyển (migration) là quá rủi ro để triển khai vào một chiều thứ Sáu, ngay cả khi quá trình kiểm duyệt mã (code review) đã vượt qua. Đó là trực giác cho thấy một sự tối ưu hóa hiệu suất lúc này có thể tạo ra một lỗ hổng bảo mật về sau. Một LLM không có trực giác. Nó chỉ có các khuôn mẫu. Các khuôn mẫu thì hữu ích, nhưng chúng không phải là sự phán đoán.

Các công ty đang tuyển dụng hiện nay cần ngừng việc tối ưu hóa để tìm kiếm những người chỉ đơn thuần là giỏi sử dụng các công cụ AI. Hãy tuyển những người có thể thách thức AI. Hãy tìm kiếm những ứng viên biết dừng lại, đọc kỹ kết quả được tạo ra và giải thích lý do tại sao họ không đồng ý với nó. Đó chính là những kỹ sư sẽ giữ cho hệ thống của bạn hoạt động ổn định khi mã nguồn được tạo ra phải đối mặt với thực tế hỗn loạn của môi trường production.

Tăng tốc mà không có la bàn

Hãy coi AI như một bàn đạp ga. Trong một chiếc xe có a