Đơn vị tôi vừa thử nghiệm đưa AI vào nhiều bước của quy trình phát triển phần mềm tại FPT IS. Không phải kiểu “có AI là vứt vào cho vui”, mà chúng tôi thử thật, đo thật, để xem chỗ nào ăn, chỗ nào không?
Kết quả phần lớn đúng như kỳ vọng. Lúc thiết kế và viết code, AI tăng tốc rõ rệt: sinh ra khung sườn nhanh, gợi ý cấu trúc hợp lý. Lúc review code, AI bắt được nhiều lỗi nhỏ mà mắt người dễ bỏ sót sau một ngày dài. Lúc test, AI sinh test case (kịch bản kiểm thử) nhanh hơn nhiều so với ngồi liệt kê thủ công.
Nhưng có một bước, càng đưa AI vào sớm và sâu, kết quả lại càng tệ đi: viết user story - đặc tả yêu cầu.
 |
| Anh Trần Đức Duy, kỹ sư mảng chăm sóc sức khỏe, FPT IS (ở giữa) cùng đồng đội thử nghiệm đưa AI vào quy trình phát triển phần mềm |
Nghe thì có vẻ ngược đời. Đặc tả yêu cầu được viết bằng chữ, là ngôn ngữ tự nhiên, tưởng như đúng “sân nhà” của AI. Nhưng thực tế đây lại là... cái bẫy. AI có thể viết đặc tả rất trôi chảy, câu chữ mượt đến nỗi chúng tôi đọc xong gật gù đồng tình. Chỉ khi đọc kỹ mới nhận ra nội dung chung chung, hời hợt. Quan trọng hơn cả, AI bỏ sót yếu tố cốt lõi nhất: ngữ cảnh nghiệp vụ thực tế.
Có thể hình dung một cách đơn giản: viết đặc tả yêu cầu giống như thiết kế bản vẽ cho một ngôi nhà, còn việc lập trình, vận hành hệ thống là quá trình thi công. AI là công cụ giúp tăng tốc quá trình thi công, kiểm tra lỗi kỹ thuật hay đề xuất cách sử dụng vật liệu tối ưu. Nhưng AI không thể thay thế kiến trúc sư vẽ bản thiết kế đầu tiên. Bởi AI không hiểu gia chủ thực sự cần gì, có thói quen sinh hoạt nào cần được ưu tiên hay những bất tiện mà họ không muốn đưa vào không gian sống của mình.
Trong việc phát triển phần mềm cũng vậy, AI khó nắm bắt được những kiến thức ngầm ít khi được nhắc đến trong tài liệu: vì sao một quy định tồn tại, ai sẽ bị ảnh hưởng nếu làm sai, trường hợp ngoại lệ nào hay xảy ra trong thực tế,... Chính vì thiếu ngữ cảnh nên AI sẽ tạo ra những bản đặc tả đúng về câu chữ nhưng chưa chắc đúng khi đưa vào thực tế vận hành.
Các bản đặc tả yêu cầu không chỉ mô tả “hệ thống phải làm gì”. Nó là kết tinh của rất nhiều câu chuyện không được viết ra: tại sao khách hàng từng bị thiệt vì một lỗi tương tự, ai là người thật sự dùng tính năng này mỗi ngày, trường hợp ngoại lệ nào hay xảy ra ngoài đời mà không ai buồn ghi vào tài liệu chính thức. AI không có mặt ở những cuộc trò chuyện đó. Nó chỉ thấy được phần chữ chứ không thấy được phần ngầm hiểu.
Khi để AI viết đặc tả mà thiếu sự can thiệp của người làm nghiệp vụ, hệ thống nhận một bản đặc tả nghe rất giống một bản đặc tả thật, nhưng lại rỗng phần cốt lõi. Cái nguy hiểm không phải vì nó sai rõ ràng. Sai rõ ràng thì dễ phát hiện. Nguy hiểm vì nó gần đúng. Đủ đúng để không ai nghi ngờ, đủ thiếu để hai tháng sau mới lộ ra một nghiệp vụ quan trọng chưa từng được nhắc tới. Điều này dẫn tôi tới một nguyên tắc đơn giản khi đặt AI vào quy trình.
Thứ nhất, ở những bước có “đề bài rõ ràng”, tức là có chuẩn để đối chiếu đúng sai, như code phải chạy được, test case phải bao quát được luồng nghiệp vụ đã biết. Ở bước này, AI làm rất tốt vai trò tăng tốc.
Thứ hai, ở những bước cần “ngữ cảnh ngầm”, tức câu trả lời đúng phụ thuộc vào những điều chưa từng được viết ra ở đâu cả. Lúc này, AI chỉ nên là người ghi chép và gợi mở câu hỏi, không phải người ra quyết định nội dung.
Thứ ba, khi ranh giới giữa hai nhóm công việc này không cố định. Nó phụ thuộc vào việc tổ chức đã từng viết ra đủ ngữ cảnh hay chưa. Càng nhiều tri thức nghiệp vụ được ghi lại rõ ràng từ trước, AI càng có cơ sở để dựa vào để đưa ra kết quả chính xác, giảm đáng kể cho phần “gần đúng mà rỗng ruột” len vào.
Tôi không nghĩ bài học ở đây là “né” bước viết đặc tả yêu cầu ra khỏi AI mãi mãi. Tôi nghĩ bài học là: trước khi hỏi “có nên đưa AI vào bước này không”, câu hỏi đúng hơn là: ở bước này chúng ta cần một câu trả lời đúng ngữ pháp hay cần một người hiểu được điều chưa ai nói ra?
Dù công cụ mạnh đến đâu, AI cũng chỉ phát huy tốt nhất khi câu hỏi được đặt ra rõ ràng. Trong khi đó phần khó nhất của nghề lại nằm ở việc xác định đâu mới là vấn đề thực sự cần giải quyết. Bài toán nào cũng đi kèm với những "ngữ cảnh ngầm" - điều này luôn cần con người đánh giá và xử lý.
Trần Đức Duy | FPT IS
Ý kiến
()