AI viết code nhiều hơn, nhưng kỹ sư vẫn phải làm chủ hệ thống

Khi người ta nói AI đã "thay đổi" phát triển phần mềm, điều quan trọng là phải xác định chính xác phần nào đã thay đổi. Tạo ra một đoạn mã, khám phá một thiết kế hay quyết định một hệ thống có giải quyết đúng bài toán hay không — đó là những hoạt động khác nhau. Tự động hóa một khâu không có nghĩa là các khâu còn lại sẽ tự giải quyết.

Minh họa về kỹ thuật phần mềm có AI hỗ trợ

Tự động hóa sinh mã không xóa bỏ trách nhiệm

Các tác nhân AI (agent) ngày càng có thể đảm nhận nhiều công việc triển khai hơn, đồng thời hỗ trợ phân tích, thiết kế và kiểm thử. Tuy nhiên, kỹ sư vẫn là người chịu trách nhiệm quyết định xây dựng cái gì và bằng chứng nào là đủ để chấp nhận kết quả.

Cách mô tả "AI thay thế người viết code" là thiếu chính xác. Nó thu gọn vai trò lập trình viên vào việc gõ phím, đánh giá thấp những gì agent có thể hỗ trợ, và biến việc tự động hóa tác vụ thành một tuyên bố về công ăn việc làm. Những tuyên bố về thay thế lao động cần bằng chứng vượt xa một bản demo ấn tượng.

Câu hỏi thực tế đáng quan tâm hơn: làm sao dùng những công cụ này mà vẫn giữ được quyết định kỹ thuật minh bạch và vòng phản hồi hữu ích?

Cấp "nơi cư trú" cho các quyết định kỹ thuật

Một cuộc trò chuyện rất tiện để khám phá các lựa chọn, nhưng lại là nơi mong manh để lưu giữ kỷ lục duy nhất về một quyết định kiến trúc.

Ngữ cảnh của mô hình có giới hạn. Một phiên dài có thể bị tóm tắt, nén hoặc khôi phục với thông tin có chọn lọc. Bản tóm tắt có thể giữ lại kết luận nhưng đánh mất điều kiện khiến kết luận đó hợp lý. "Dùng cache cục bộ" khác với "dùng cache cục bộ vì màn hình này phải dùng được khi không có kết nối mạng".

Giải pháp được đề xuất là tạo cho các quyết định lâu dài một "ngôi nhà" nhỏ gọn và có thể xem xét lại — ví dụ một tệp PROJECT_GUIDE.md chứa:

• Mục đích và phạm vi hiện tại của sản phẩm, bao gồm cả những thứ bị loại trừ rõ ràng.
• Ranh giới hệ thống quan trọng và lý do phía sau các lựa chọn kiến trúc.
• Kỳ vọng về chất lượng và các lệnh dùng để kiểm tra.
• Liên kết tới những quyết định sâu hơn khi cần thêm không gian giải thích.

Tên tệp không có phép màu nào. Agent sẽ không tự động nạp nó. Cần kết nối nó qua cơ chế hướng dẫn dự án mà công cụ hỗ trợ hoặc chủ động đưa vào tác vụ, rồi kiểm tra lại cách agent diễn giải.

Markdown một mình không bảo đảm việc truy xuất lẫn việc tuân thủ. Gửi mọi tài liệu trong mọi tác vụ có thể làm tăng ngữ cảnh và chi phí.

Đặc tả hành vi tiếp theo, không viết cả hệ thống

Hãy hình dung một màn hình tìm kiếm trên ứng dụng di động. Câu chuyện người dùng có thể là: "Là người dùng, tôi muốn tìm kiếm các mục đã lưu để tìm một mục mà không phải cuộn qua toàn bộ danh sách." Với bước tăng đầu tiên, phạm vi là tìm kiếm cục bộ trên các mục sẵn có. Tìm kiếm từ xa và thay đổi cơ chế lưu trữ bị loại trừ.

Trước khi triển khai, cần làm rõ các trường hợp chấp nhận:

• Truy vấn khớp hiển thị đúng các mục mong đợi.
• Truy vấn không khớp hiển thị trạng thái kết quả rỗng.
• Xóa truy vấn khôi phục danh sách đầy đủ.
• Nếu lọc là bất đồng bộ, kết quả cũ không được ghi đè lên kết quả của truy vấn mới hơn.

Những trường hợp này làm lộ ra một câu hỏi kỹ thuật: việc lọc có cần xử lý bất đồng bộ hay không? Agent có thể giúp đánh giá, nhưng quyết định phải dựa trên kích thước dữ liệu và yêu cầu về độ phản hồi, chứ không phải vì một mẫu thiết kế nào đó mặc định cần có.

Sau mỗi bước tăng, kỹ sư cần xem diff, chạy các kiểm tra liên quan và thực nghiệm màn hình. Nếu agent viết lại cơ chế lưu trữ dù đã bị giới hạn phạm vi, việc test pass cũng không làm thay đổi bị mở rộng trở nên hợp lý. Nếu trạng thái rỗng trông đúng nhưng tìm kiếm khớp sai trường, một ảnh chụp màn hình cũng không chứng minh được tính đúng đắn.

Sinh mã phải chịu sự kiểm chứng

Đầu ra của agent mang tính xác suất. Việc chấp nhận phải dựa trên bằng chứng có thể xem xét và, khi thực tế cho phép, có thể tái lập.

Một lệnh kiểm chứng cục bộ có thể chạy kiểm tra định dạng, phân tích tĩnh, biên dịch và các bài test tập trung. Mỗi loại trả lời một câu hỏi khác nhau:

• Trình định dạng kiểm tra quy ước.
• Trình biên dịch kiểm tra ngữ pháp và quy tắc kiểu dữ liệu.
• Bài test đánh giá hành vi được chọn trong điều kiện được chọn.

Không loại nào chứng minh rằng chúng ta đã chọn đúng hành vi sản phẩm.

Kiểm chứng có kiểm soát cũng cần đầu vào có kiểm soát. Phiên bản công cụ, dữ liệu giả lập và điều kiện thực thi đều quan trọng. Các bài test liên quan tới thời gian, thiết bị, mạng hoặc dịch vụ bên ngoài có thể không ổn định. Gọi một bộ test là "tất định" không làm nó trở nên tất định.

Thậm chí một kiểm tra lặp lại hoàn hảo vẫn có thể xác minh sai thứ. Một bài test tìm kiếm có thể khẳng định rằng có kết quả xuất hiện mà không kiểm tra đó là kết quả nào. Một bài test do AI sinh ra có thể mã hóa trung thành chính sự hiểu lầm giống như phần triển khai do AI sinh ra. Cần đối chiếu khẳng định với trường hợp chấp nhận và dùng các ví dụ được chọn có chủ đích, bao gồm cả trường hợp thất bại.

Tài liệu phải xứng đáng với công sức duy trì

Điều đáng hoài nghi là khi một thay đổi nhỏ đòi hỏi cả một chuỗi tài liệu được sinh ra trước khi có ai nhìn thấy hành vi đang chạy. Mỗi tài liệu trở thành thứ phải xem xét, đối chiếu và cập nhật. Sinh văn bản rẻ không có nghĩa là đọc hiểu nó cũng rẻ.

Đặc tả tăng dần có thể hỗ trợ phản hồi nhanh. Agile không có nghĩa là tránh tài liệu: các nguyên tắc của nó nhấn mạnh phần mềm chạy được thường xuyên, sự xuất sắc về kỹ thuật và khả năng thích ứng. Một trường hợp chấp nhận ngắn gọn có thể phục vụ những mục tiêu đó; một thiết kế chi tiết cũng vậy khi mức rủi ro đòi hỏi.

Đặc tả mạnh mẽ có giá trị với các ràng buộc an toàn, công việc chịu quản lý, giao diện công khai, tương thích di trú và phối hợp giữa nhiều nhóm. Trong những bối cảnh đó, một hướng dẫn ngắn gọn là điểm vào dẫn tới chi tiết cần thiết, chứ không thể thay thế chi tiết đó.

Phép thử thực tế cho một tài liệu: nó hỗ trợ quyết định, triển khai hay kiểm chứng nào, và ai sẽ duy trì nó?

Giữ quyết định chấp nhận luôn minh bạch

Một bước tăng nhỏ vẫn có thể chứa một giả định sai. Lợi thế của nó là mang lại cơ hội phát hiện sớm hơn và trong phạm vi hẹp hơn.

Vòng lặp được khuyến nghị khá đơn giản: xác định hành vi tiếp theo, cung cấp ngữ cảnh cần thiết, kiểm tra cách diễn giải, xem xét thay đổi, thu thập bằng chứng và quyết định chấp nhận hay không. Cập nhật hướng dẫn lâu dài khi một quyết định thay đổi. Nếu việc xem xét trở nên quá tải, hãy giảm quy mô bước tăng hoặc cải thiện các kiểm tra trước khi yêu cầu agent sinh thêm.

Cách tiếp cận này có giới hạn. Nó phụ thuộc vào hiểu biết của kỹ sư, chất lượng bằng chứng và chi phí duy trì hướng dẫn. Đây là một quan điểm làm việc, không phải một nghiên cứu có kiểm soát hay một mức tăng năng suất đã được chứng minh. Để chứng minh điều đó cần các tác vụ tương đương và tính đến cả thời gian xem xét, làm lại, lỗi phát sinh và bảo trì — không chỉ thời gian sinh mã.

Có thể yên tâm giao nhiều việc hơn cho AI khi giải thích được đã yêu cầu gì, đã thay đổi gì và vì sao bằng chứng đủ để chấp nhận. Đó là chuẩn mực kỹ thuật cần mang theo vào kỷ nguyên phát triển phần mềm có AI hỗ trợ.

Với các đội ngũ phát triển tại Việt Nam đang ngày càng đưa trợ lý AI vào quy trình làm việc, việc xây dựng thói quen ghi lại quyết định, đặc tả hành vi và kiểm chứng bằng chứng ngay từ đầu sẽ quyết định chất lượng sản phẩm về lâu dài — hơn là tốc độ sinh mã tức thời.