Việc Meta tham gia thị trường AI hỗ trợ lập trình trong tuần này đi kèm một tuyên bố cụ thể đáng để suy ngẫm. Muse Code, tác nhân lập trình mới của công ty hoạt động trên terminal, không chỉ viết mã từng tệp một — theo bài đăng ra mắt của Mark Zuckerberg, khi một công việc đủ lớn, nó sẽ “phân nhánh thành các tác nhân phụ riêng biệt làm việc song song trong những worktree biệt lập”, và trong quá trình thử nghiệm nội bộ của Meta, công cụ này được cho là đã đồng thời xây dựng sáu tính năng cho một trò chơi mà không xảy ra xung đột. Đó là tuyên bố của một nhà cung cấp về chính sản phẩm của mình trong ngày ra mắt, không phải kết quả đã được kiểm chứng độc lập, vì vậy hãy nhìn con số cụ thể này với thái độ hoài nghi. Nhưng hình thức quy trình làm việc mà nó mô tả không phải ý tưởng chỉ có ở Meta — việc cho các tác nhân thực thi song song và biệt lập đang trở thành một mô hình mặc định trong lĩnh vực tác nhân lập trình, và nó làm thay đổi ý nghĩa thực sự của việc “giỏi việc này”.

Trong hai năm qua, lời quảng bá dành cho các công cụ AI hỗ trợ lập trình phần lớn xoay quanh tốc độ trên một luồng duy nhất: một tác nhân, một nhiệm vụ, một diff để xem xét. Đây là kỹ năng mà hầu hết kỹ sư đã phần nào nắm được — đọc diff, chạy các bài kiểm thử, đưa vào vận hành. Việc phân tách công việc cho nhiều tác nhân làm việc trong các worktree biệt lập phá vỡ mô hình đó. Bạn không còn xem xét một thay đổi mạch lạc duy nhất từ một mạch suy nghĩ duy nhất. Bạn đang xem xét nhiều thay đổi đồng thời, được suy luận độc lập, tất cả đều phải hội tụ thành một hệ thống hoạt động được mà không mâu thuẫn với nhau, không lặp lại logic, cũng không âm thầm bất đồng về cách một phần dùng chung của codebase nên hoạt động.

Vì sao đây thực sự là một kỹ năng khác, chứ không phải phiên bản nhanh hơn của kỹ năng cũ

Xem xét một diff do AI viết phần lớn là kiểm tra tính đúng đắn: nó có làm đúng điều được mô tả không, có làm hỏng những phần lân cận không. Xem xét đầu ra của nhiều tác nhân chạy song song bổ sung thêm một lớp mà trước đây hầu hết mọi người chưa từng phải rèn luyện, bởi cho đến gần đây, công việc của không một cá nhân nào đòi hỏi điều đó: tính nhất quán giữa các diff. Hai tác nhân có cùng tự nghĩ ra phiên bản riêng của cùng một hàm trợ giúp không? Thay đổi được “cô lập” của một tác nhân có âm thầm phụ thuộc vào một tệp mà tác nhân khác đang viết lại dở dang không? Bước hợp nhất có thực sự phát hiện ra một xung đột hay đã âm thầm chọn giả định của một nhánh thay cho nhánh kia? Đây không phải lỗi theo nghĩa truyền thống — từng diff riêng lẻ có thể vượt qua các bài kiểm thử của chính nó nhưng vẫn tạo ra một hệ thống thiếu nhất quán sau khi kết hợp.

Đây cũng là vấn đề mà các đội ngũ kỹ thuật phân tán từ trước đến nay vẫn xử lý với những người đóng góp là con người, chỉ khác là được nén lại thành vài phút thay vì vài ngày. Điểm khác biệt là một nhóm kỹ sư cấp thấp thường tự nhiên xin hướng dẫn khi một nhiệm vụ có vẻ mơ hồ; còn một tác nhân được tối ưu để hoàn thành phần việc được giao thường sẽ tạo ra một câu trả lời đầy tự tin, sạch sẽ về cú pháp, nhưng lại cho nhầm câu hỏi. Để phát hiện điều đó, cần có người hiểu nhiệm vụ đủ rõ để ngay từ đầu phân rã nó — nghĩa là kỹ năng thực sự trở thành nút thắt không phải là “xem xét mã thật nhanh”, mà là “chia một phần việc thành những phần có thể chạy song song một cách an toàn, và biết phần nào không thể”.

Mô hình rộng hơn, vượt ra ngoài riêng các công cụ hỗ trợ lập trình

Đáng chú ý là điều này không chỉ giới hạn ở các công cụ dành cho nhà phát triển. Việc Google thiết kế lại ô tìm kiếm — được công bố cũng trong tuần đó — gộp AI Overviews và AI Mode vào một luồng duy nhất có thể tiếp nhận văn bản, hình ảnh, PDF, video và các tab Chrome đang mở làm đầu vào, rồi giao việc cho một tác nhân thay vì một trình phân tích truy vấn. Điểm chung giữa cả hai đợt ra mắt là như nhau: giao diện đang chuyển từ “đưa cho AI một chỉ dẫn rõ ràng và kiểm tra một đầu ra rõ ràng” sang “giao cho AI một mục tiêu được xác định khá lỏng và một đống đầu vào, rồi để nó tự tìm ra các bước.” Mô hình đó xuất hiện ở bất cứ đâu các công cụ dạng tác nhân được triển khai, không chỉ trong trình soạn thảo mã — và điều đó có nghĩa là kỹ năng xem xét và điều phối sẽ trở nên hữu ích vượt xa các vai trò kỹ thuật, đối với bất kỳ ai có công việc liên quan đến việc dẫn dắt một hệ thống AI thực hiện một nhiệm vụ nhiều bước thay vì một lời nhắc duy nhất.

Cụ thể thì nên rèn luyện điều gì

Nếu bạn viết hoặc quản lý mã, một vài thói quen cụ thể, có thể kiểm tra được sẽ xây dựng kỹ năng này nhanh hơn việc chỉ đọc về nó:

  • Hãy tìm hiểu worktree biệt lập thực sự là gì (tính năng của git cho phép đồng thời checkout nhiều nhánh vào các thư mục riêng biệtworktree) trước khi tin vào tuyên bố của một công cụ rằng các thay đổi song song “không thể xung đột”. Việc cô lập trong quá trình thực thi không đảm bảo tính nhất quán tại thời điểm hợp nhất — đó là một bước riêng biệt đáng được theo dõi kỹ.
  • Cố ý giao cho một tác nhân lập trình một nhiệm vụ đủ lớn để nó buộc phải phân rã nhiệm vụ đó, và đọc cách nó chia công việc trước khi đọc các diff tạo ra. Cách phân rã cho bạn biết nhiều hơn về việc liệu có thể tin đầu ra hay không so với bản thân phần mã.
  • Hãy luyện xem xét các diff theo từng nhóm, không phải từng cái một. Kỹ năng đồng thời ghi nhớ ba hoặc bốn thay đổi có liên quan và phát hiện điểm chúng bất đồng khác với việc xem xét từng thay đổi một cách tách biệt rồi phê duyệt nó dựa trên ưu điểm riêng.
  • Hãy hỏi điều gì xảy ra khi có xung đột, không chỉ khi mọi việc thành công. Bất kỳ công cụ nào tuyên bố có thể tự động hợp nhất song song đều phải cho bạn thấy nó làm gì khi hai tác nhân thực sự cùng chạm vào một logic — đường đi khi thất bại đó, hơn cả đường đi thuận lợi, cho biết liệu công cụ có an toàn để giao việc thực tế hay không.

Không điều nào trong số này đòi hỏi phải chờ công ty của bạn áp dụng một sản phẩm cụ thể. Mô hình này — phân rã, phân công, hội tụ lại, kiểm chứng — hiện đang xuất hiện ở các tác nhân lập trình của nhiều nhà cung cấp cũng như trong các giao diện AI dành cho người dùng phổ thông. Những người trở nên thành thạo trong việc quản lý chu trình đó, thay vì chỉ xem xét đầu ra của một luồng duy nhất, đang xây dựng một kỹ năng vẫn phù hợp bất kể tác nhân của công ty nào cuối cùng chiếm ưu thế.