Nguy hiểm nhưng cần thiết: Khi lập trình viên ngừng đọc mã nguồn do LLM tạo ra?

Nguy hiểm nhưng cần thiết: Khi lập trình viên ngừng đọc mã nguồn do LLM tạo ra?

Trong bài viết trước, tôi từng kết luận rằng việc giả định chúng ta không còn cần lo lắng về việc đọc và gỡ lỗi (debug) mã nguồn là một hành động thiếu trách nhiệm. Chúng ta không thể mặc định rằng mọi vấn đề phát sinh đều sẽ được các Mô hình Ngôn ngữ Lớn (LLM) khắc phục. Điều này cảm thấy thiếu trách nhiệm vì cho đến nay, việc hiểu và duy trì mã nguồn一直是 nhiệm vụ của lập trình viên, như một đại diện cho việc hiểu và duy trì hệ thống phần mềm. Chúng ta phải chịu trách nhiệm về đầu ra của LLM.

Tuy nhiên, điều gì sẽ xảy ra nếu giả định đó không còn đúng nữa? Điều gì sẽ xảy ra nếu chúng ta tận tụy thông báo các rủi ro và sự đánh đổi cho lãnh đạo tổ chức, nhưng họ vẫn muốn chấp nhận những rủi ro đó? Đây không phải là điều unheard of: các công ty, đặc biệt là các startup công nghệ, thường xuyên đưa ra các sự thỏa hiệp ngắn hạn để cải thiện năng suất, về đích trước đối thủ, thu hút nhà đầu tư, v.v.

Nếu có một yêu cầu từ cấp tổ chức là tận dụng LLM để giảm thiểu thời gian viết code, thì đó là một ràng buộc mới mà chúng ta có thể làm việc cùng. Chúng ta có thể tìm ra hình ảnh của một kỹ thuật tốt trong bối cảnh đó. Chúng ta có thể ngừng đọc mã do LLM tạo ra, giống như cách chúng ta không đọc assembly, bytecode, hay JavaScript đã biên dịch (transpiled); mã nguồn ngôn ngữ cấp cao của chúng ta bây giờ sẽ trở thành một dạng mã máy khác.

Mã nguồn trở thành "mã máy" mới

Điều này thực sự hợp lý sau khi tôi đọc báo cáo của Thoughtworks. Các LLM tạo ra đầu ra không xác định (non-deterministic) và tạo mã nhanh hơn nhiều so với tốc độ đọc của chúng ta, vì vậy chúng ta không thể nghiêm túc kỳ vọng xem xét, hiểu và phê duyệt hiệu quả mọi thay đổi (diff) nữa. Nhưng điều đó không nhất thiết có nghĩa là chúng ta ngừng sự nghiêm ngặt, nó có thể có nghĩa là chúng ta nên chuyển sự nghiêm ngặt sang nơi khác.

Tuy nhiên, điều cơ bản cần hiểu là đây không phải là quyết định của cá nhân hay đội nhóm: nó phải là một quyết định của tổ chức. Không chỉ vì quản lý rủi ro và trách nhiệm giải trình, mà còn vì Định luật Amdahl. Nếu chúng ta chỉ tối đa hóa tốc độ tạo mã mà không sắp xếp lại các cấu trúc và quy trình tổ chức mà công việc của chúng ta được nhúng vào, sẽ không có bất kỳ lợi ích năng suất hữu hình nào.

Chúng ta không thể có một số lập trình viên tạo ra 20.000 dòng code "rác" mỗi ngày và kỳ vọng phần còn lại vẫn đọc và hiểu chúng, chứ chưa nói đến việc phê duyệt. Chúng ta không thể tận dụng các tác nhân AI (agents) nếu đơn vị công việc của chúng ta vẫn là "thêm một endpoint mới vào RESTful API". Chúng ta không thể kỳ vọng một Product Owner cung cấp đủ công việc để giữ một nhóm "hai chiếc pizza" bận rộn nếu mỗi kỹ sư có thể đảm nhận bốn nhiệm vụ cùng lúc và chạy các tác nhân vào giờ ngoài.

Thay đổi quy trình và chuyển dịch sự nghiêm ngặt

Thay vào đó, chúng ta cần loại bỏ sự can thiệp của con người (humans-in-the-loop), giảm thiểu sự phối hợp, ma sát, quan liêu và các khâu kiểm soát (gate-keeping). Chúng ta cần một nguồn yêu cầu gần như vô hạn, các kỹ sư đóng vai trò như những nhà thiết kế sản phẩm giả lập, sở hữu toàn bộ luồng công việc, với quyền hạn để đưa ra quyết định tự chủ. Việc làm lại (rework) gần như miễn phí, vì vậy chúng ta không nên nỗ lực ngăn chặn công việc không chính xác xảy ra.

Vậy sự nghiêm ngặt sẽ đi đâu? Tương tự như báo cáo của Thoughtworks, lựa chọn đầu tiên của tôi sẽ là các đặc tả kỹ thuật (specifications) (khác với prompts) và bài kiểm thử (tests) (khác với TDD). Nếu tôi phải triển khai quy trình phát triển như vậy hôm nay, tôi sẽ biến một đặc tả Markdown chuẩn hóa thành đơn vị kiến thức mới của dự án phần mềm.

Chủ sở hữu sản phẩm và kỹ sư ban đầu có thể hợp tác trên đặc tả này và trên các trường hợp kiểm thử để thực thi các quy tắc kinh doanh. Những thứ này nên được kiểm tra vào các kho lưu trữ dự án cùng với mã triển khai. Sẽ cần các kiểm tra pull-request tự động để xác minh không chỉ các bài kiểm thử vượt qua mà mã còn tuân thủ đúng đặc tả.

Chính đặc tả kỹ thuật này, chứ không phải mã nguồn hiện thực hóa nó, là thứ mà đội ngũ cần phải hiểu, xem xét và chịu trách nhiệm giải trình.