DoorDash dọn feature flag bằng AI: 45/50 pull request dùng được
Theo báo cáo kỹ thuật của DoorDash, hệ thống nhiều agent tạo pull request dùng được cho 45/50 feature flag cũ, với thời gian trung bình 13.8 phút và chi phí mô hình 4.79 USD cho mỗi lần dọn.
Đây không phải quy trình AI tự chọn hành vi sản phẩm rồi tự merge mã. Kỹ sư xác nhận giá trị cần giữ trước khi agent sửa code và vẫn quyết định có đưa pull request vào nhánh chính hay không; những chuỗi phụ thuộc quá sâu được trả lại cho con người thay vì cố hoàn tất bằng mọi giá.
Benchmark 50 ca thực sự đo điều gì
Mẫu đánh giá gồm các dynamic value — tên DoorDash dùng cho feature flag — đã được hệ thống xử lý trong nhiều repository Kotlin. Một pull request chỉ được xem là đạt khi CI vượt qua, phần mã thay đổi đúng và kỹ sư chấp nhận kết quả; vì vậy “dùng được” không đồng nghĩa với “agent tạo ra một diff trông hợp lý”.
Bản tổng thuật của InfoQ phân rã 50 ca thành 31 PR được merge ngay lần đầu, 14 PR cần sửa và năm ca cần kỹ sư can thiệp; cùng nguồn này ghi nhận không có lỗi hoặc hồi quy trong mẫu, đồng thời cho biết mỗi agent có timeout một giờ.
Trong nhóm cần sửa, vấn đề là thiếu test để đạt patch coverage hoặc còn sót biến và tham chiếu mã chết. Các ca phải chuyển cho kỹ sư đều liên quan đến chuỗi gọi hàm sâu, trong đó tham số đi qua nhiều interface; agent đã xóa được phần lớn mã nhưng bỏ sót một số mắt xích. Ranh giới tin cậy vì thế nằm ở mức độ hoàn tất: hệ thống có thể không dọn xong, nhưng kết quả chưa vượt cổng kiểm tra sẽ không trở thành PR để merge.
Tóm tắt chính thức tại ICSME 2026 mô tả đây là đánh giá công nghiệp dựa trên PR được kỹ sư phê duyệt, với ba thước đo chính là tỷ lệ thành công, chi phí cho mỗi lần dọn và thời gian xử lý. Điều đó giới hạn cách diễn giải: đây là kết quả triển khai nội bộ của một cấu hình cụ thể, không phải benchmark độc lập giữa các mô hình hay cam kết cho codebase khác.
Flag cũ được chọn trước khi AI tham gia
DoorDash không đưa mọi flag vào hàng đợi. Một dynamic value chỉ được coi là cũ khi đã không thay đổi trong khoảng thời gian nội bộ quy định, vẫn còn tham chiếu trong code, chưa ở trạng thái archived hoặc retired và không thuộc danh sách loại trừ. Tác vụ sau đó được tạo trong Jira và chuyển vào pha phân tích.
Bộ lọc này quan trọng vì nó tách hai câu hỏi khác nhau: flag có vẻ không còn hoạt động và flag đã an toàn để xóa không phải một. Hệ thống còn phải biết giá trị production cần giữ; chỉ đọc mã nguồn không thể cho biết một thử nghiệm triển khai một phần nên được hoàn tất, quay lui hay để nguyên.
Hai giai đoạn giữ quyết định sản phẩm cho con người
Ở pha phân tích, agent điều phối đọc ticket Jira, tìm repository và các tham chiếu mã, rồi truy vấn nền tảng thử nghiệm qua Model Context Protocol để lấy UUID, trạng thái rollout và giá trị đích. Nó tạo báo cáo có cấu trúc về nhánh cần giữ cùng các tệp có khả năng bị ảnh hưởng. Kỹ sư phải duyệt báo cáo này trước khi bất kỳ tệp nào được sửa.
Sau khi giá trị đích được xác nhận, agent chuyên dọn dẹp thay lời gọi flag bằng giá trị đó, rút gọn điều kiện, xóa nhánh chết và cập nhật test. DoorDash dùng Claude Sonnet cho điều phối và thu thập ngữ cảnh, còn Claude Opus thực hiện phần sửa mã cần lần theo ngữ nghĩa và chuỗi phụ thuộc.
Hệ thống được xây trên Agent Development Kit. Giới thiệu ADK của Google nêu rõ framework hỗ trợ phân cấp agent chuyên biệt, điều phối tuần tự hoặc song song và kết nối công cụ MCP; tuy nhiên, các cổng kiểm soát cụ thể trong benchmark là thiết kế của DoorDash chứ không phải tính năng tự động có sẵn của framework.
Worktree cô lập và kiểm thử chặn PR không đạt
Mỗi agent sửa mã trong một Git worktree riêng. Khi nhiều tác vụ chạy song song, thay đổi của chúng không ghi đè lên nhau; một lần chạy thất bại có thể bị loại bỏ cùng worktree mà không làm bẩn nhánh làm việc chính. Gradle được chạy không dùng daemon để tránh chia sẻ trạng thái giữa các môi trường cô lập.
Trước khi được phép mở PR, thay đổi phải build thành công, vượt test, đạt ngưỡng patch coverage trên các dòng đã sửa và qua Detekt. Agent có thể chẩn đoán rồi thử sửa lại khi một cổng thất bại, nhưng timeout đặt giới hạn cho vòng lặp đó. Thiết kế này không chứng minh mọi thay đổi do LLM tạo ra đều đúng; nó giảm khả năng một thay đổi chưa được kiểm chứng đi tiếp trong quy trình.
4.79 USD là chi phí mô hình, không phải tổng chi phí
Con số trung bình chỉ phản ánh chi phí gọi mô hình trong lần dọn được đo. Nó không bao gồm công sức xây hệ thống điều phối, tích hợp Jira và nền tảng thử nghiệm, tài nguyên build và CI, bảo trì quy tắc kiểm tra hay thời gian kỹ sư phê duyệt báo cáo và review PR.
Vì vậy, phép so sánh hợp lý không phải “vài USD thay cho toàn bộ chi phí kỹ thuật”, mà là chi phí biên của một tác vụ lặp lại sau khi hạ tầng đã tồn tại. Lợi ích kinh tế còn phụ thuộc vào số flag đủ điều kiện, độ ổn định của test, mức độ phân tán của dependency injection và tỷ lệ ca phải trả lại cho kỹ sư. Giá mô hình, prompt và lượng ngữ cảnh thay đổi cũng có thể làm kết quả khác đi.
Khi nào kết quả 45/50 có thể tái tạo
Codebase cần một nguồn sự thật đáng tin cậy về rollout và giá trị phải giữ; nếu thiếu dữ liệu này, cả công cụ dựa trên quy tắc lẫn LLM đều có thể giữ nhầm nhánh. Repository cũng phải có build, test, patch coverage và static analysis đủ ổn định để đóng vai trò cổng quyết định, thay vì chỉ cung cấp tín hiệu tham khảo.
Kiến trúc mã là biến số lớn. Kho mã PolyglotPiranha của Uber mô tả cách dọn feature flag bằng các quy tắc biến đổi code khi người dùng cung cấp tên flag, hành vi đích và mẫu API. Cách này phù hợp khi quan hệ có thể biểu diễn bằng cấu trúc cú pháp; DoorDash chọn agent vì hằng số, client đọc giá trị, wrapper dùng dependency injection và logic nghiệp vụ có thể nằm ở nhiều tệp, nối với nhau qua lời gọi hàm.
Do đó, tỷ lệ thành công thuộc về toàn bộ cấu hình: tiêu chí chọn flag, dữ liệu rollout trực tiếp, phân vai mô hình, worktree cô lập, timeout, kiểm thử tự động và phê duyệt của con người. Năm ca cần kỹ sư không phải mã lỗi đã lọt qua để merge, mà là các thay đổi không hoàn tất bị chặn đúng tại ranh giới đã thiết kế.
Đọc thêm:
Đăng ký bản tin
Nhận tin Web3, AI và tiền mã hóa mới nhất ngay trong hộp thư.