Trợ lý AI cần những gì trước khi bắt tay sửa một website?

Yêu cầu sửa bộ lọc trong thanh tìm kiếm của một website nghe có vẻ là việc nhỏ. Nhưng với một coding agent, tức trợ lý AI có thể đọc và sửa code, câu chuyện lại không đơn giản như vẻ bề ngoài, vì trước khi hiểu rõ yêu cầu và biết bắt đầu từ đâu, agent phải trả lời không ít câu hỏi, ví dụ như:

• Code của trang tìm kiếm nằm ở đâu?
• Bộ lọc cần làm theo bản thiết kế nào?
• Tài khoản nào vào được trang này?
• Thanh tìm kiếm có dùng chung một nút bấm với ứng dụng khác không, và nếu có thì công việc phải kéo thêm những file nào, còn sửa ở đây sẽ ảnh hưởng tới ứng dụng kia ra sao?

Chỉ giao yêu cầu thôi thì những câu hỏi ấy vẫn còn nguyên, nên agent cần một cách để tìm đúng tài liệu, code và công cụ, rồi giữ chúng bên nhau suốt lúc làm việc. Chuyện này giống như khi có đồng nghiệp mới: người mới cần được giới thiệu đôi chút trước khi hiểu tên một trang có ý nghĩa gì, và agent cũng vậy. Vì thế mình hình dung công việc này giống như chuẩn bị bàn làm việc cho một nhiệm vụ cụ thể, và trên chiếc bàn ấy, chọn đúng tập hồ sơ quan trọng hơn kích thước của cả tủ tài liệu phía sau.

Trước khi yêu cầu đến tay agent

Ở công ty, chiếc bàn mà mình đang định hình và điều chỉnh dần là một development harness dùng chung cho Navigos Talent One và VietnamWorks, hai sản phẩm tuyển dụng. Hiểu đơn giản, harness là mọi thứ được chuẩn bị sẵn quanh agent, gồm hướng dẫn dự án, không gian làm việc và cách truy cập, sử dụng những công cụ agent cần, và phần nào cũng có thứ tương ứng trên chiếc bàn. Hướng dẫn dự án giống tờ ghi chú để lại cho người mới, cho biết có những dự án nào, code của từng dự án nằm trong những repo nào (repo là nơi lưu code của dự án) và cần theo quy tắc gì. Không gian làm việc giống một khay giấy riêng, giữ tài liệu của một việc ở cạnh nhau và tách khỏi những việc khác. Còn cách truy cập và dùng các công cụ thì giống như giao sẵn chìa khoá cho người mới: với yêu cầu sửa bộ lọc, đó là những gì agent cần để mở bản thiết kế, chạy ứng dụng trên trình duyệt, chạy build hay cập nhật ticket của nhóm.

Khi agent đi tìm code và thiết kế của trang tìm kiếm

Nhận yêu cầu sửa bộ lọc xong, việc đầu tiên agent làm là tìm code. Mỗi dự án trong harness ghi rõ những repo liên quan và hướng dẫn áp dụng cho các repo đó, giúp agent biết đoạn code nào thuộc tính năng tìm kiếm cần sửa và đoạn code ấy nằm ở đâu. Tìm được code của bộ lọc rồi, agent vẫn cần biết bộ lọc phải trông như thế nào, và câu trả lời nằm trong bản thiết kế mà nhóm đã chọn. Để xem kỹ bản thiết kế ấy, agent dùng Figma Lens, công cụ mình tạo ra để tìm đúng màn hình trong một file Figma và soi từng chi tiết. Mình muốn agent chỉ lấy những thông tin có thể thay đổi quyết định tiếp theo, vì lấy mọi thứ cùng lúc sẽ khiến agent khó thấy bản thiết kế nào và đoạn code nào mới thật sự thuộc về bộ lọc này.

Khi developer chuyển sang dự án khác giữa chừng

Giờ giả sử việc sửa bộ lọc cần đụng tới nút bấm dùng chung ở trên, và đang làm dở thì người developer làm cùng agent chuyển harness sang một dự án khác, nên những repo và hướng dẫn đang mở trước mắt agent giờ thuộc về dự án kia. Khi người đó quay lại mở việc sửa trang tìm kiếm, việc này phải khôi phục đúng những gì đã lưu từ đầu: repo và hướng dẫn của trang tìm kiếm, nút bấm dùng chung và bản thiết kế đã chọn. Nếu không, việc trên màn hình trông vẫn y như cũ trong khi agent đang đọc code của dự án kia, và chẳng có dấu hiệu nào cho agent biết điều đó.

Trang giới thiệu không gian làm việc minh hoạ mối quan hệ giữa một việc và không gian làm việc của việc đó. Các bản sao code riêng cho phép nhiều agent sửa code song song, nhưng nếu hai agent cùng cần sửa nút bấm dùng chung, chúng vẫn phải thống nhất ai chịu trách nhiệm cho thay đổi đó và ai đưa thay đổi ấy vào ứng dụng.

Khi agent mở trang để thử bộ lọc

Đọc code và thiết kế mới chỉ là bước đầu, vì sau đó agent còn phải chạy ứng dụng trong môi trường khớp với công việc. Trang tìm kiếm có thể chỉ mở được với một số tài khoản, nên một ghi chú lưu sẵn sẽ cho agent biết việc này cần dùng tài khoản nào, còn thông tin riêng tư của tài khoản thì không xuất hiện trong ghi chép công khai. Biết tài khoản cần dùng có thể giúp agent chọn môi trường phù hợp, còn mở được trang tìm kiếm bằng tài khoản ấy thì xác nhận agent vào được đúng trang cần kiểm tra. Trang mở rồi thì các công cụ trình duyệt và API giúp agent thử bộ lọc lẫn những request phía sau bộ lọc.

Nhìn thấy bộ lọc trên trang chỉ trả lời được một câu hỏi: bộ lọc hiển thị đã đúng chưa. Nếu yêu cầu còn nói rằng bộ lọc đã chọn phải được giữ lại, agent cần đổi lựa chọn rồi tải lại trang, vì chỉ bước đó mới cho biết lựa chọn có còn sau khi tải lại hay không. Yêu cầu đặt ra hành vi nào thì hồ sơ công việc cần ghi rõ agent đã thử hành vi đó ra sao và kết quả thế nào.

Khi build xong và đến tay QA

Bộ lọc đã chạy đúng thì bước tiếp theo là chạy build, tức tạo từ code ra một phiên bản ứng dụng để QA kiểm thử. Build thành công chỉ có ích khi ta biết bản build đó được tạo từ phiên bản code nào, và nếu nút bấm đến từ một gói dùng chung thì phần bàn giao cũng cần ghi phiên bản của gói đó. Khi build thất bại, cũng nhờ những thông tin ấy mà agent lần lại được phiên bản code đã dùng và log của lần build. Ngay cả khi build xong, điều đó cũng chưa có nghĩa là môi trường đang chạy đã nhận bản build mới, nên khi bàn giao cần tách bạch hai chuyện này.

Bước cuối là bàn giao cho QA, và đây là lúc cần tới Jira CLI, một công cụ khác mình tạo ra. Jira CLI giúp agent ghi những gì đã quan sát vào ticket Jira, để QA thấy cần mở bản build nào, lựa chọn bộ lọc có được giữ lại sau khi tải lại trang hay không (nếu yêu cầu có nêu hành vi này), và đã có ai xác nhận môi trường đang chạy bản build đó chưa. Khi những khác biệt ấy được ghi rõ, QA có một điểm bắt đầu đáng tin cậy hơn.

Giữa yêu cầu này và yêu cầu tiếp theo

Mình phụ trách chính việc phát triển harness này, từ thiết lập quy trình, ranh giới tích hợp cho tới các hướng dẫn giúp agent dùng đúng code, thiết kế và công cụ của từng việc. Agent hỗ trợ phần triển khai, còn mình kiểm soát và review các thay đổi trong code, rồi kiểm tra xem môi trường có giữ đúng bối cảnh của công việc trong lúc agent làm hay không, mà bối cảnh này chính là thứ dễ bị xáo trộn khi có người chuyển dự án như ở trên. Khi việc chuẩn bị không gian làm việc và quản trị harness bắt đầu chiếm thời gian và sự chú ý dành cho sản phẩm, mình cũng đã thúc đẩy chuyển sang một phiên bản đơn giản hơn.

Phiên bản hiện tại cho phép agent chuyển sang một công cụ khác sẵn có khi một công cụ hỗ trợ không bắt buộc gặp lỗi, mà vẫn giữ nguyên phạm vi công việc và các bước kiểm tra bắt buộc. Harness đang được dùng nội bộ cho hai sản phẩm và vẫn trong quá trình ổn định.

Nếu bạn định làm một môi trường tương tự, mình nghĩ nên theo một thay đổi bình thường, như yêu cầu sửa bộ lọc ở trên, từ lúc có yêu cầu cho tới khi đến tay QA. Chỗ nào phải giải thích đi giải thích lại, hay chỗ nào không ai chắc nguồn thông tin nào đúng, đều là chỗ đáng xem kỹ. Hãy bắt đầu từ đó, rồi để môi trường hỗ trợ lớn dần quanh những việc thật sự cần làm.

Chi tiết về không gian làm việc và bàn giao bản phát hành

Harness hỗ trợ Git worktrees, tức các bản sao làm việc riêng dùng chung lịch sử của cùng một repo, còn agent vẫn làm việc trong những ứng dụng lập trình quen thuộc. Các thao tác Jira CLI và Jenkins đã được cho phép sẽ hỗ trợ việc bàn giao và chạy build. Khi kiểm tra bàn giao, cần xác định phiên bản ứng dụng và phiên bản của các gói dùng chung có thay đổi, còn muốn xác nhận bản phát hành đang chạy thì phải có kết quả kiểm tra từ chính môi trường đó. Phần triển khai tại công ty vẫn được giữ riêng tư; Figma Lens và Jira CLI cung cấp một số giao diện công khai có liên quan.