OpenAI đã công bố vào ngày 18 tháng 8 năm 2026 một báo cáo trải nghiệm về việc loại bỏ Enzyme trong cơ sở mã của Asana bằng Codex. Nghiên cứu điển hình công bố khoảng hai tuần dương lịch, một tuần rưỡi nỗ lực kỹ thuật và 12.000 đô la chi phí cho mô hình và cơ sở hạ tầng. Những con số này ấn tượng, nhưng chúng cần được đọc như trường hợp của nhà cung cấp, không phải là lời hứa áp dụng cho mọi lần di cư.
1. Những gì vụ việc Asana khẳng định
Theo phản hồi được OpenAI công bố về Asana, nhóm đã gỡ bỏ Enzyme, một hệ thống kiểm thử đã trở thành một khoản nợ quan trọng, trong khoảng hai tuần lịch. Công việc trực tiếp của con người dự kiến chiếm khoảng một tuần rưỡi, trong khi chi phí cho các mô hình và hạ tầng là khoảng 12.000 đô la.
Bài viết so sánh kết quả này với một kế hoạch cũ mà Asana ước tính ít nhất là năm năm và khoảng 6 triệu đô la chi phí nhân sự. Sự so sánh này xuất phát từ chính tổ chức và phụ thuộc vào phương pháp ước tính được sử dụng. Nó không nên được biến thành tỷ lệ năng suất chung hay so sánh chi phí đầy đủ một cách độc lập.
Thông tin hữu ích nhất là mang tính hoạt động: từ một lời nhắc ban đầu gồm năm câu, tối đa bốn đại lý làm việc song song trên các bản sao riêng biệt của cơ sở mã. Một kỹ sư kiểm tra tiến độ hai lần mỗi ngày và mỗi thay đổi được đề xuất đều được xem xét.
2. Tại sao việc di cư này thích hợp cho các đại lý
Thay thế một hệ thống kiểm thử là một vấn đề rộng lớn nhưng thường lặp đi lặp lại. Các biến đổi có thể theo các mẫu: sửa đổi các import, điều chỉnh các helper, thay thế các selector, viết lại các assertion và sửa các bài kiểm thử.
Kết quả mong đợi có thể kiểm chứng một cách mạnh mẽ. Một bài test phải biên dịch, thực thi và duy trì một hành vi nhất định. Vòng lặp này cung cấp cho tác nhân một phản hồi khách quan, trái ngược với việc tái thiết kế nghiệp vụ mà chất lượng phụ thuộc vào các ý định ít được tài liệu hóa.
Việc di cư cũng có thể được chia theo tệp, thư mục hoặc thành phần. Các lô độc lập hạn chế xung đột và cho phép thực thi nhiều tác nhân song song.
Những đặc điểm này tạo thành một lưới hữu ích: tính lặp lại, khả năng kiểm chứng, khả năng phân chia và mức độ mơ hồ nghề nghiệp thấp. Một dự án càng hội tụ những đặc điểm này, nó càng phù hợp cho một thí nghiệm tác nhân. Lưới này là một cách đọc phương pháp học của Partitech; nghiên cứu điển hình của OpenAI không trình bày chi tiết từng chuyển đổi này một cách riêng lẻ.
3. Vai trò quyết định của việc chia nhỏ
Giao cho một tác nhân “xóa toàn bộ nợ kỹ thuật” hiếm khi đưa ra kết quả có thể sử dụng được. Cần xây dựng một danh mục: cách sử dụng phụ thuộc, biến thể, ngoại lệ, phạm vi kiểm tra và thứ tự di chuyển.
Kho lưu trữ sau đó có thể được chia thành các đơn vị có thể so sánh. Mỗi lô nhận được một hướng dẫn ngắn gọn, các ràng buộc, một yêu cầu kiểm tra và một định nghĩa về việc hoàn thành. Các trường hợp không điển hình được tách riêng thay vì làm ô nhiễm tất cả các lời nhắc.
Phản hồi từ Asana cho thấy rằng các hướng dẫn đơn giản hơn hoạt động tốt hơn. Nhận xét này phù hợp với thực tiễn kỹ thuật: chuyển các quy tắc ổn định sang các script, bài kiểm tra và trình phân tích mã, thay vì giải thích toàn bộ dự án trong một prompt khổng lồ.
4. Song song có kiểm soát
Nhiều tác nhân có thể tăng tốc xử lý nếu phạm vi của họ là độc lập. Các bản sao riêng biệt của kho lưu trữ giúp họ không sửa đổi cùng lúc cùng một không gian làm việc.
Tuy nhiên, cần phải quản lý các phụ thuộc. Một tác nhân có thể tạo ra một trợ lý chung mà những người khác sẽ cần. Một đội phải quyết định những thay đổi cấu trúc nào được tích hợp trước và những phần nào có thể vẫn độc lập.
Sự song song cũng làm tăng khối lượng kiểm tra. Bốn nhân viên tạo ra các sửa đổi nhanh hơn so với đội kiểm tra chúng sẽ tạo ra một hàng đợi mới. Vì vậy, số lượng tối ưu phụ thuộc vào khả năng của CI và kiểm soát con người, không chỉ dựa vào số lượng giấy phép có sẵn.
5. Tại sao các bài kiểm tra vẫn là chất xúc tác thực sự
Trang OpenAI không tài liệu hóa các lệnh kiểm tra, cũng như CI, hay phạm vi chức năng của việc di chuyển. Do đó, các thực hành được mô tả trong phần này cấu thành phương pháp bảo đảm của chúng tôi cho một dự án đại lý, chứ không phải là kết quả đo lường trong trường hợp Asana.
Một tác nhân có thể thay đổi nhiều mã; các bài kiểm tra cho phép biết nhanh chóng liệu sự thay đổi có chấp nhận được hay không. Nếu không có một loạt thử nghiệm đáng tin cậy, đội ngũ phải đọc từng dòng và tái tạo hành vi mong đợi, điều này phá hủy phần lớn lợi ích thu được.
Trước khi di cư, hãy ổn định các lệnh kiểm tra, giảm các trường hợp không xác định và thêm các kiểm soát nhắm mục tiêu. Một bài kiểm tra thất bại một lần trên mười gây phiền nhiễu cho cả một đại lý lẫn con người.
CI phải tạo ra các thông điệp có thể sử dụng và cho phép thực hiện một phần. Đại lý có thể sửa chữa hiệu quả hơn khi nhận được phản hồi chính xác về tệp, khẳng định hoặc loại liên quan.
6. Việc xem xét của con người không biến mất
Vụ việc được công bố nêu rõ rằng mỗi đề xuất đều được xem xét và phê duyệt bởi con người. Kỹ sư kiểm tra công việc hai lần mỗi ngày và hướng dẫn các nhân viên khi chiến lược cần thay đổi.
Bài đánh giá phải tập trung vào hành vi, không chỉ về phong cách. Kiểm tra các loại bỏ trong bao phủ, các khẳng định bị suy yếu, các lối đi vòng kiểu, các snapshot được chấp nhận quá dễ dàng và các thay đổi cấu hình toàn cục.
Một đại lý giỏi có thể đưa ra giải pháp giúp CI vượt qua bằng cách loại bỏ bài kiểm tra gây vấn đề. Tiêu chí chấp nhận nên cấm rõ ràng loại đường tắt này.
7. Những gì con số chi phí không nói
Số 12.000 đô la được thông báo bao gồm các mô hình và cơ sở hạ tầng, nhưng trang không cung cấp bảng phân tích để biết cách tính chi phí cho việc chuẩn bị kho lưu trữ, phát triển các công cụ nội bộ, thời gian xem xét, cơ sở hạ tầng hiện có, các sửa chữa sau này hoặc việc vốn hóa đội ngũ.
Ngược lại, việc so sánh với một kế hoạch ít nhất năm năm và khoảng 6 triệu đô la chi phí nhân sự dựa trên ước tính của Asana, mà có thể chưa bao giờ được thực hiện dưới dạng này. Hai con số này không thể so sánh trực tiếp nếu không có phương pháp chi tiết.
Đối với dự án của bạn, hãy tính toán chi phí toàn phần: mô hình, CI, lưu trữ, kỹ thuật, đánh giá, sự cố và bảo trì script. So sánh nó với một kịch bản con người thực tế trên cùng phạm vi và cùng mức chất lượng.
8. Một phương pháp có thể tái tạo cho dự án của bạn
Bắt đầu bằng một phân tích tĩnh và một kiểm kê có thể kiểm chứng. Sau đó chọn một lô thử nghiệm gồm 20 đến 50 biến đổi tiêu biểu. Viết một hướng dẫn ngắn, một lệnh kiểm tra và một danh sách các cấm đoán.
Hãy để một nhân viên thực hiện lô hàng tại một chi nhánh tách biệt. Đo tỉ lệ chấp nhận không cần sửa lại, thời gian xem xét, các lỗi chức năng và chi phí. Sửa các công cụ trước khi tăng khối lượng.
Khi người lái đã ổn định, phân chia phần còn lại của công trường, giới hạn số lượng nhân viên theo khả năng đánh giá và tích hợp dần dần. Giữ một bảng điều khiển: các tệp đã xử lý, các bài kiểm tra đã thêm, các thất bại, xung đột và nợ kỹ thuật còn lại.
Phương pháp này hoàn thiện cách tiếp cận của chúng tôi về đo lường và ưu tiên nợ kỹ thuật và các biện pháp bảo vệ được trình bày trong Đại lý phát triển vào năm 2026.
9. Những di cư cần tránh đầu tiên
Đừng sử dụng như trình điều khiển đầu tiên một việc đại tu chưa được kiểm tra, một logic nghiệp vụ không được tài liệu hóa hoặc một việc di chuyển dữ liệu không thể đảo ngược. Các đại lý không bù đắp được việc thiếu định nghĩa kết quả mong đợi.
Cũng tránh một công trường nơi mỗi tệp phụ thuộc vào một kiến trúc đang thay đổi. Xung đột giữa các tác nhân, nhánh và quyết định của con người có thể vượt quá lợi ích của việc tạo ra.
Trường hợp Asana không chứng minh rằng một tác nhân có thể thay thế một đội ngũ. Nó cho thấy, theo phản hồi được OpenAI công bố, rằng một đội ngũ được trang bị tốt có thể biến một công việc lặp đi lặp lại thành một quy trình di chuyển song song. Kỹ năng then chốt vẫn là kỹ thuật hệ thống công việc.
Partitech đồng hành cùng các cuộc di cư kỹ thuật được hỗ trợ bởi AI: kiểm kê, thiết kế các lô, gợi ý và kịch bản, tăng cường kiểm thử, điều phối Codex và kiểm soát chất lượng.