Kỹ thuật khai thác: tận dụng Codex ở thế giới ưu tiên tác nhân

Trong năm tháng qua, nhóm của chúng tôi đã thực hiện một thử nghiệm: phát triển và phát hành một bản beta nội bộ của một sản phẩm phần mềm với 0 dòng mã được viết thủ công.

Sản phẩm có người dùng hằng ngày nội bộ và người thử nghiệm alpha bên ngoài. Nó vận chuyển, triển khai, phá vỡ và được sửa chữa. Điều khác biệt là mọi dòng mã — logic ứng dụng, kiểm tra, cấu hình CI, tài liệu, khả năng quan sát và công cụ nội bộ — đã được viết bởi Codex. Chúng tôi ước tính rằng chúng tôi đã xây dựng nó trong khoảng 1/10 thời gian cần thiết để viết mã bằng tay.

Con người điều khiển. Các tác nhân thực thi.

Chúng tôi cố ý chọn ràng buộc này để chỉ xây dựng những gì cần thiết nhằm tăng tốc độ phát triển của đội ngũ kỹ thuật lên nhiều bậc. Chúng tôi đã có nhiều tuần để gửi những gì cuối cùng trở thành một triệu dòng mã. Để làm được điều đó, chúng tôi cần hiểu những gì thay đổi khi công việc chính của nhóm kỹ sư phần mềm không còn là viết mã nữa, mà là thiết kế môi trường, xác định ý định và xây dựng các vòng phản hồi cho phép các đại lý Codex thực hiện công việc đáng tin cậy.

Bài đăng này nói về những gì chúng tôi đã học được bằng cách xây dựng một sản phẩm hoàn toàn mới với một nhóm các đại lý - những gì đã phá vỡ, những gì phức tạp và làm thế nào để tối đa hóa một nguồn lực thực sự khan hiếm của chúng tôi: thời gian và sự chú ý của con người.

Cam kết đầu tiên đối với một kho lưu trữ trống đã hạ cánh vào cuối tháng 8 năm 2025.

Giàn giáo ban đầu — cấu trúc kho lưu trữ, cấu hình CI, quy tắc định dạng, thiết lập trình quản lý gói và khung ứng dụng — được tạo bởi Codex CLI sử dụng GPT‑5, được hướng dẫn bởi một tập hợp nhỏ các mẫu hiện có. Ngay cả tệp Agents.md ban đầu chỉ đạo các tác nhân cách làm việc trong kho lưu trữ cũng được viết bởi Codex.

Không có mã do con người viết sẵn để neo hệ thống. Ngay từ đầu, kho lưu trữ đã được định hình bởi đại lý.

Năm tháng sau, kho lưu trữ chứa khoảng một triệu dòng mã trên các mảng logic ứng dụng, cơ sở hạ tầng, công cụ, tài liệu, và các tiện ích nội bộ dành cho lập trình viên. Trong giai đoạn đó, khoảng 1,500 pull request đã được mở và hợp nhất, với một đội ngũ nhỏ chỉ gồm ba kỹ sư dẫn dắt Codex. Điều này tương đương với thông lượng trung bình 3,5 PRs mỗi kỹ sư mỗi ngày, và đáng ngạc nhiên là thông lượng này đã tăng lên khi nhóm phát triển lên đến bảy kỹ sư như hiện nay. Điều quan trọng là, đây không phải là đầu ra vì mục đích tạo đầu ra: sản phẩm đã được hàng trăm người dùng sử dụng nội bộ, bao gồm cả những người dùng nội bộ thành thạo sử dụng hằng ngày.

Trong suốt quá trình phát triển, con người không bao giờ trực tiếp đóng góp bất kỳ mã nào. Điều này đã trở thành một triết lý cốt lõi cho nhóm: không có mã viết thủ công.

Việc thiếu lập trình thực hành trực tiếp của con người đã giới thiệu một loại công việc kỹ thuật khác, tập trung vào hệ thống, giàn giáo, và đòn bẩy.

Tiến trình ban đầu chậm hơn chúng ta mong đợi, không phải vì Codex không có khả năng, mà vì môi trường không được xác định rõ ràng. Tác nhân thiếu các công cụ, các lớp trừu tượng và cấu trúc nội bộ cần thiết để tiến tới các mục tiêu cấp cao. Công việc chính của nhóm kỹ thuật chúng tôi đã trở thành việc giúp các tác nhân có thể thực hiện công việc hữu ích.

Trên thực tế, điều này có nghĩa là làm việc theo chiều sâu trước: chia nhỏ các mục tiêu lớn thành các khối nhỏ hơn (thiết kế, lập trình, xem xét, kiểm thử, v.v.), yêu cầu tác nhân xây dựng các khối đó và sử dụng chúng để mở khóa các nhiệm vụ phức tạp hơn. Khi có thứ gì đó thất bại, cách khắc phục gần như không bao giờ là “cố gắng hơn.” Bởi vì cách duy nhất để đạt được tiến bộ là để Codex làm công việc, các kỹ sư con người luôn bước vào nhiệm vụ và hỏi: “khả năng nào còn thiếu, và làm thế nào để chúng tôi khiến nó vừa dễ hiểu vừa có thể thực thi đối với tác nhân?”

Con người tương tác với hệ thống gần như hoàn toàn thông qua các câu lệnh: một kỹ sư mô tả một nhiệm vụ, chạy tác nhân và cho phép nó mở một pull request. Để đưa một PR đến khi hoàn tất, chúng tôi hướng dẫn Codex tự rà soát các thay đổi của chính nó ở môi trường cục bộ, yêu cầu thêm các lượt rà soát cụ thể từ tác nhân cả ở môi trường cục bộ lẫn trên đám mây, phản hồi mọi phản hồi do con người hoặc tác nhân đưa ra, và lặp lại theo vòng lặp cho đến khi tất cả các tác nhân rà soát đều hài lòng (về cơ bản, đây là một Vòng lặp Ralph Wiggum⁠(mở trong cửa sổ mới)). Codex sử dụng trực tiếp các công cụ phát triển tiêu chuẩn của chúng tôi (gh, kịch bản cục bộ và kỹ năng nhúng kho lưu trữ) để thu thập ngữ cảnh mà không cần con người sao chép và dán vào CLI.

Con người có thể xem xét các pull request, nhưng không bắt buộc phải làm như vậy. Theo thời gian, chúng tôi đã thúc đẩy gần như tất cả các nỗ lực đánh giá theo hướng được xử lý từ đại lý đến đại lý.

Khi thông lượng mã tăng lên, nút thắt của chúng tôi trở thành năng lực QA của con người. Bởi vì hạn chế cố định là thời gian và sự chú ý của con người, chúng tôi đã làm việc để thêm nhiều khả năng hơn cho tác nhân bằng cách làm cho những thứ như giao diện người dùng ứng dụng, nhật ký và số liệu ứng dụng có thể đọc trực tiếp với Codex.

Ví dụ: chúng tôi đã tạo ứng dụng có thể khởi động cho mỗi git worktree, vì vậy Codex có thể khởi chạy và chạy một phiên bản cho mỗi thay đổi. Chúng tôi cũng đã kết nối Giao thức Chrome DevTools vào thời gian chạy tác nhân và tạo các kỹ năng để làm việc với ảnh chụp nhanh DOM, ảnh chụp màn hình và điều hướng. Điều này cho phép Codex tái tạo lỗi, xác thực các bản sửa lỗi và lý do về hành vi giao diện người dùng trực tiếp.

Chúng tôi cũng đã làm điều tương tự cho các công cụ quan sát. Các nhật ký, số liệu và dấu vết được hiển thị cho Codex thông qua một ngăn xếp quan sát cục bộ, có tính chất tạm thời đối với bất kỳ cây công việc nào. Codex hoạt động trên một phiên bản hoàn toàn cô lập của ứng dụng đó — bao gồm nhật ký và số liệu của nó, sẽ bị phá bỏ sau khi nhiệm vụ đó hoàn thành. Các đại lý có thể truy vấn nhật ký với LogQL và số liệu với PromQL. Với bối cảnh này có sẵn, các lời nhắc như “đảm bảo khởi động dịch vụ hoàn thành trong vòng dưới 800ms” hoặc “không có khoảng thời gian trong bốn hành trình quan trọng của người dùng vượt quá hai giây” trở nên có thể theo dõi được.

Chúng ta thường thấy Codex duy nhất chạy công việc trên một nhiệm vụ duy nhất trong tối đa sáu giờ (thường là trong khi con người đang ngủ).

Quản lý bối cảnh là một trong những thách thức lớn nhất trong việc làm cho các đại lý có hiệu quả trong các nhiệm vụ lớn và phức tạp. Một trong những bài học đầu tiên chúng tôi học được rất đơn giản: cung cấp cho Codex một bản đồ, không phải một cuốn sách hướng dẫn 1.000 trang.

Chúng tôi đã thử “một phương pháp Agents.md⁠(mở trong cửa sổ mới) lớn” . Nó đã thất bại theo những cách có thể dự đoán được:

• Bối cảnh là một nguồn tài nguyên khan hiếm. Một tệp lệnh khổng lồ loại bỏ nhiệm vụ, mã và các tài liệu liên quan — vì vậy tác nhân bỏ lỡ các ràng buộc chính hoặc bắt đầu tối ưu hóa cho những điều sai.
• Quá nhiều hướng dẫn trở thành không còn hướng dẫn. Khi mọi thứ đều "quan trọng", không có gì là quan trọng. Tác nhân cuối cùng lại đối sánh theo mẫu một cách cục bộ thay vì điều hướng một cách có chủ đích.
• Nó bị thối rữa ngay lập tức. Một tài liệu hướng dẫn nguyên khối sẽ biến thành một nghĩa địa của những quy tắc lỗi thời. Các tác nhân không thể biết điều gì vẫn còn đúng, con người ngừng duy trì nó, và tệp tin lặng lẽ trở thành một mối phiền toái hấp dẫn.
• Thật khó để xác minh. Một đốm đốm không thể kiểm tra cơ học (độ bao phủ, độ tươi, quyền sở hữu, liên kết chéo), vì vậy sự trôi dạt là không thể tránh khỏi.

Vì vậy, thay vì coi AGENTS.md là bách khoa toàn thư, chúng tôi coi nó như mục lục.

Cơ sở tri thức của kho lưu trữ nằm trong thư mục có cấu trúc docs/ và được coi là hệ thống lưu trữ chính thức. Một Agents.md ngắn (khoảng 100 dòng) được đưa vào ngữ cảnh và chủ yếu đóng vai trò như một bản đồ, với các chỉ dẫn đến các nguồn chân lý sâu sắc hơn ở nơi khác.

Tài liệu thiết kế được lập danh mục và chỉ mục, bao gồm trạng thái xác minh và một tập hợp các niềm tin cốt lõi xác định các nguyên tắc hoạt động ưu tiên tác nhân. Tài liệu kiến trúc⁠(mở trong cửa sổ mới) cung cấp bản đồ cấp cao nhất của các tên miền và phân lớp gói. Một tài liệu chất lượng phân loại từng miền sản phẩm và lớp kiến trúc, theo dõi các khoảng trống theo thời gian.

Các kế hoạch được coi là các tài liệu hạng nhất. Các kế hoạch tạm thời, gọn nhẹ được sử dụng cho những thay đổi nhỏ, trong khi các công việc phức tạp hơn được ghi lại trong các kế hoạch thực thi⁠(mở trong cửa sổ mới) kèm theo nhật ký tiến độ và quyết định được lưu trữ vào kho lưu trữ. Các kế hoạch đang hoạt động, các kế hoạch đã hoàn thành và các khoản nợ kỹ thuật đã biết đều được quản lý theo phiên bản và đặt cùng một chỗ, cho phép các tác nhân vận hành mà không cần dựa vào ngữ cảnh bên ngoài.

Điều này cho phép tiết lộ dần dần: các tác nhân bắt đầu với một điểm vào nhỏ, ổn định và được hướng dẫn nơi cần xem tiếp theo, thay vì bị choáng ngợp ngay từ đầu.

Chúng tôi thực thi điều này một cách máy móc. Các linter chuyên dụng và các tác vụ CI xác thực rằng cơ sở kiến thức luôn được cập nhật, được liên kết chéo và được cấu trúc đúng cách. Một tác nhân "doc-gardening" định kỳ sẽ quét các tài liệu cũ hoặc lỗi thời không phản ánh hành vi thực tế của mã và mở các pull request để sửa lỗi.

Khi cơ sở mã phát triển, khuôn khổ của Codex cho các quyết định thiết kế cũng cần phải phát triển.

Vì kho lưu trữ được tạo hoàn toàn bởi tác nhân, nó được tối ưu hóa trước hết cho độ dễ đọc của Codex. Tương tự như cách các nhóm hướng tới việc cải thiện khả năng điều hướng mã của họ cho các kỹ sư mới được tuyển dụng, mục tiêu của các kỹ sư của chúng tôi là làm cho một tác nhân có thể suy luận về toàn bộ miền nghiệp vụ trực tiếp từ kho lưu trữ.

Theo quan điểm của tác nhân, bất cứ thứ gì mà nó không thể truy cập trong ngữ cảnh trong khi chạy hiệu quả đều không tồn tại. Hệ thống không thể truy cập được kiến thức tồn tại trong Google Docs, chuỗi trò chuyện hoặc đầu của mọi người. Các hiện vật có phiên bản, cục bộ kho lưu trữ (ví dụ: mã, markdown, lược đồ, kế hoạch thực thi) là tất cả những gì nó có thể nhìn thấy.

Chúng tôi nhận ra rằng theo thời gian, chúng tôi cần phải đưa ngày càng nhiều ngữ cảnh vào kho lưu trữ. Cuộc thảo luận trên Slack đã giúp cả nhóm thống nhất về một mẫu hình kiến trúc đó? Nếu tác nhân không thể tìm ra thông tin đó, thì nó cũng không thể đọc được, giống như việc một nhân viên mới gia nhập công ty ba tháng sau đó sẽ không biết đến nó.

Cung cấp thêm ngữ cảnh cho Codex có nghĩa là tổ chức và làm rõ thông tin phù hợp để tác nhân có thể suy luận dựa trên đó, thay vì làm quá tải nó với các hướng dẫn tùy tiện. Tương tự như cách bạn sẽ tích hợp đồng đội mới về các nguyên tắc sản phẩm, tiêu chuẩn kỹ thuật và văn hóa nhóm (bao gồm các tùy chọn biểu tượng cảm xúc), cung cấp cho đại lý thông tin này dẫn đến kết quả phù hợp hơn.

Cách diễn đạt này đã làm rõ nhiều đánh đổi. Chúng tôi ưu tiên các phần phụ thuộc và các lớp trừu tượng có thể được hoàn toàn nội bộ hóa và suy luận trong kho lưu trữ. Các công nghệ thường được mô tả là "nhàm chán" lại có xu hướng dễ dàng hơn để các tác nhân xây dựng mô hình nhờ khả năng kết hợp, tính ổn định của API và khả năng thể hiện trong tập dữ liệu huấn luyện. Trong một số trường hợp, việc để tác nhân triển khai lại các tập con của chức năng rẻ hơn so với việc tìm cách khắc phục hành vi thượng nguồn khó hiểu từ các thư viện công khai. Ví dụ, thay vì dùng một gói kiểu p-limitchung chung, chúng tôi đã tự triển khai một helper map-with-concurrency: nó được tích hợp chặt chẽ với hệ thống đo lường OpenTelemetry của chúng tôi, có độ bao phủ kiểm thử 100%, và hoạt động đúng chính xác theo cách mà runtime của chúng tôi mong đợi.

Việc kéo nhiều hệ thống hơn vào một biểu mẫu mà đại lý có thể kiểm tra, xác thực và sửa đổi trực tiếp sẽ làm tăng đòn bẩy - không chỉ cho Codex, mà còn cho các đại lý khác (ví dụ: Aardvark) cũng đang làm việc trên cơ sở mã.

Chỉ riêng tài liệu thôi thì không đủ để duy trì tính nhất quán của một codebase được tạo hoàn toàn bởi tác nhân. Bằng cách thực thi các bất biến, thay vì vi mô hóa cách triển khai, chúng tôi cho phép các tác nhân phát hành nhanh mà không làm suy yếu nền tảng. Ví dụ, chúng tôi yêu cầu Codex phân tích các hình dạng dữ liệu tại ranh giới⁠(mở trong cửa sổ mới), nhưng không quy định cụ thể cách thức thực hiện điều đó (mô hình dường như thích Zod, nhưng chúng tôi không chỉ định thư viện cụ thể đó).

Các tác nhân hoạt động hiệu quả nhất trong môi trường có ranh giới rõ ràng và cấu trúc dễ dự đoán⁠(mở trong cửa sổ mới), vì vậy chúng tôi đã xây dựng ứng dụng dựa trên một mô hình kiến trúc cứng nhắc. Mỗi miền nghiệp vụ được chia thành một tập lớp cố định, với các hướng phụ thuộc được xác thực nghiêm ngặt và một tập cạnh được phép giới hạn. Các ràng buộc này được thực thi một cách cơ học thông qua các linter tùy chỉnh (tất nhiên là do Codex tạo ra!) và các bài kiểm thử cấu trúc.

Sơ đồ dưới đây cho thấy quy tắc: trong mỗi miền kinh doanh (ví dụ: Cài đặt ứng dụng), mã chỉ có thể phụ thuộc “hướng về phía trước” thông qua một tập lớp cố định (Types → Config → Repo → Service → Runtime → UI). Các mối quan tâm xuyên suốt (auth, connectors, telemetry, feature flags) đi vào thông qua một giao diện rõ ràng duy nhất: Providers. Bất cứ điều gì khác đều bị cấm và thực thi một cách máy móc.

Đây là kiểu kiến trúc mà bạn thường hoãn lại cho đến khi bạn có hàng trăm kỹ sư. Với các tác nhân mã hóa, đó là điều kiện tiên quyết ban đầu: những ràng buộc là những gì cho phép tốc độ mà không bị phân rã hoặc trôi dạt kiến trúc.

Trong thực tế, chúng tôi thực thi các quy tắc này bằng các trình kiểm tra mã tùy chỉnh và các kiểm thử cấu trúc, cùng với một tập nhỏ các “bất biến về sở thích.” Ví dụ: chúng tôi thực thi tĩnh việc ghi nhật ký có cấu trúc, các quy ước đặt tên cho lược đồ và kiểu, giới hạn kích thước tệp và các yêu cầu về độ tin cậy dành riêng cho nền tảng bằng các lint tùy chỉnh. Vì các lint được tùy chỉnh, chúng tôi viết các thông báo lỗi để đưa hướng dẫn khắc phục vào ngữ cảnh tác nhân.

Trong quy trình làm việc đầu tiên của con người, các quy tắc này có thể mang lại cảm giác khó hiểu hoặc hạn chế. Với các tác nhân, chúng trở thành hệ số nhân: một khi được mã hóa, chúng áp dụng ở mọi nơi cùng một lúc.

Đồng thời, chúng tôi nêu rõ những trường hợp các ràng buộc là quan trọng và những trường hợp thì không. Điều này tương tự như việc lãnh đạo một tổ chức nền tảng kỹ thuật quy mô lớn: thiết lập ranh giới từ trung ương, cho phép tự chủ ở cấp địa phương. Bạn đặc biệt chú trọng đến ranh giới, tính chính xác và khả năng tái lập. Trong phạm vi những ranh giới đó, bạn cho phép các nhóm—hoặc các tác nhân—có mức độ tự do đáng kể trong cách các giải pháp được thể hiện.

Mã kết quả không phải lúc nào cũng phù hợp với sở thích phong cách của con người và điều đó không sao cả. Miễn là đầu ra là chính xác, có thể bảo trì và dễ đọc đối với các đại lý trong tương lai, nó sẽ đáp ứng được tiêu chuẩn.

Gu thẩm mỹ của con người được đưa trở lại vào hệ thống một cách liên tục. Các nhận xét đánh giá, các pull request tái cấu trúc và lỗi người dùng gặp phải được ghi lại dưới dạng cập nhật tài liệu hoặc được mã hóa trực tiếp vào công cụ. Khi tài liệu không đáp ứng được, chúng tôi đưa quy tắc vào mã

Khi thông lượng của Codex tăng lên, nhiều tiêu chuẩn kỹ thuật thông thường trở nên phản tác dụng.

Kho lưu trữ hoạt động với số lượng cổng hợp nhất chặn tối thiểu. Pull request có vòng đời ngắn. Các lỗi kiểm thử không ổn định thường được xử lý bằng các lần chạy lại theo dõi thay vì chặn tiến độ vô thời hạn. Trong một hệ thống nơi thông lượng của tác nhân vượt xa sự chú ý của con người, việc sửa lỗi thì rẻ, còn chờ đợi thì đắt.

Điều này sẽ là vô trách nhiệm trong một môi trường thông lượng thấp. Ở đây, nó thường là sự đánh đổi đúng đắn.

Khi chúng ta nói rằng cơ sở mã được tạo bởi các tác nhân Codex, chúng ta muốn nói tất cả mọi thứ trong cơ sở mã.

Các tác nhân tạo ra:

• Mã sản phẩm và thử nghiệm
• Cấu hình CI và công cụ phát hành
• Công cụ phát triển nội bộ
• Tài liệu và lịch sử thiết kế
• Bộ công cụ đánh giá
• Xem xét ý kiến và phản hồi
• Các tập lệnh quản lý kho lưu trữ
• Tệp định nghĩa bảng điều khiển sản xuất

Con người luôn vẫn tham gia quy trình, nhưng làm việc ở một tầng trừu tượng khác so với trước đây. Chúng tôi ưu tiên công việc, chuyển phản hồi của người dùng thành các tiêu chí chấp nhận, và xác thực kết quả. Khi tác nhân gặp khó khăn, chúng ta coi đó là một tín hiệu: xác định những gì còn thiếu—công cụ, rào cản bảo vệ, tài liệu—và đưa chúng trở lại kho lưu trữ, luôn luôn bằng cách để chính Codex tự viết bản sửa lỗi.

Các tác nhân sử dụng trực tiếp các công cụ phát triển tiêu chuẩn của chúng tôi. Họ lấy phản hồi đánh giá, phản hồi trực tiếp trong luồng, đẩy các bản cập nhật, và thường gộp và hợp nhất các pull request của chính họ.

Khi nhiều vòng lặp phát triển được mã hóa trực tiếp vào hệ thống — thử nghiệm, xác thực, xem xét, xử lý phản hồi và phục hồi — kho lưu trữ gần đây đã vượt qua ngưỡng có ý nghĩa nơi Codex có thể thúc đẩy một tính năng mới từ đầu đến cuối.

Với một câu lệnh duy nhất, tác nhân giờ đây có thể:

• Xác thực trạng thái hiện tại của cơ sở mã
• Tái tạo lỗi được báo cáo
• Quay một video trình bày sự cố
• Thực hiện một bản sửa lỗi
• Xác nhận bản sửa lỗi bằng cách vận hành ứng dụng
• Quay một video thứ hai minh họa việc giải quyết vấn đề
• Mở pull request
• Trả lời phản hồi của tác nhân và con người
• Phát hiện và khắc phục lỗi xây dựng
• Chỉ leo thang thành con người khi cần phán xét
• Hợp nhất thay đổi.

Hành vi này phụ thuộc rất nhiều vào cấu trúc và công cụ cụ thể của kho lưu trữ này và không nên được giả định là khái quát hóa mà không có đầu tư tương tự — ít nhất là chưa.

Quyền tự chủ hoàn toàn của tác nhân cũng đưa ra các vấn đề mới. Codex sao chép các mẫu đã tồn tại trong kho lưu trữ—kể cả những mẫu không đồng đều hoặc chưa tối ưu. Theo thời gian, điều này chắc chắn sẽ dẫn đến sự lệch hướng.

Ban đầu, con người giải quyết vấn đề này bằng tay. Trước đây, đội ngũ của chúng tôi phải dành mỗi thứ Sáu (20% của tuần) để dọn dẹp “rác AI.” Không có gì ngạc nhiên, cách đó không thể mở rộng quy mô.

Thay vào đó, chúng tôi bắt đầu mã hóa trực tiếp những gì chúng tôi gọi là "nguyên tắc vàng" vào kho lưu trữ và xây dựng một quy trình dọn dẹp định kỳ. Các nguyên tắc này là những quy tắc mang tính quan điểm, mang tính cơ học, giúp cơ sở mã dễ đọc và nhất quán cho các lần chạy tác nhân trong tương lai. Ví dụ: (1) chúng tôi ưu tiên các gói tiện ích dùng chung hơn là các helper tự viết để giữ các bất biến được tập trung, và (2) chúng tôi không thăm dò dữ liệu theo kiểu “YOLO”—chúng tôi xác thực các ranh giới hoặc dựa vào các SDK có kiểu để tác nhân không thể vô tình xây dựng dựa trên các cấu trúc được đoán mò. Theo nhịp độ đều đặn, chúng tôi có một bộ tác vụ Codex chạy nền để quét các sai lệch, cập nhật xếp hạng chất lượng và mở các pull request tái cấu trúc có mục tiêu. Hầu hết các mục này có thể được xem xét trong chưa đầy một phút và được tự động hợp nhất.

Chức năng này hoạt động giống như việc thu gom rác thải. Nợ kỹ thuật giống như một khoản vay lãi suất cao: hầu như lúc nào cũng tốt hơn nếu bạn liên tục trả dần theo từng phần nhỏ hơn là để nó tích lũy và rồi giải quyết trong những đợt bùng phát đau đớn. Gu thẩm mỹ của con người được ghi nhận một lần, rồi được thực thi liên tục trên từng dòng code. Điều này cũng cho phép chúng tôi phát hiện và xử lý các mẫu hình xấu hằng ngày, thay vì để chúng lan rộng trong cơ sở mã trong nhiều ngày hoặc nhiều tuần.

Chiến lược này cho đến nay đã hoạt động tốt thông qua việc ra mắt và áp dụng nội bộ tại OpenAI. Xây dựng một sản phẩm thực sự cho người dùng thực sự đã giúp cố định các khoản đầu tư của chúng tôi vào thực tế và hướng dẫn chúng tôi hướng tới khả năng bảo trì lâu dài.

Những gì chúng ta chưa biết là sự gắn kết kiến trúc phát triển như thế nào qua nhiều năm trong một hệ thống được tạo ra hoàn toàn bởi tác nhân. Chúng ta vẫn đang tìm hiểu nơi mà phán đoán của con người tạo ra đòn bẩy nhiều nhất và làm thế nào để mã hóa phán đoán đó để nó kết hợp. Chúng tôi cũng không biết hệ thống này sẽ phát triển như thế nào khi các mô hình tiếp tục trở nên có khả năng hơn theo thời gian.

Điều đã trở nên rõ ràng: xây dựng phần mềm vẫn đòi hỏi kỷ luật, nhưng kỷ luật xuất hiện nhiều hơn trong giàn giáo hơn là mã. Các vòng lặp công cụ, trừu tượng và phản hồi giữ cho cơ sở mã mạch kết ngày càng quan trọng.

Những thách thức khó khăn nhất của chúng tôi hiện nay tập trung vào việc thiết kế các môi trường, vòng lặp phản hồi và hệ thống điều khiển giúp các tác nhân đạt được mục tiêu của chúng tôi: xây dựng và duy trì phần mềm phức tạp, đáng tin cậy ở quy mô lớn.

Khi các tác nhân như Codex đảm nhận những phần lớn hơn của vòng đời phần mềm, những câu hỏi này sẽ càng trở nên quan trọng hơn. Chúng tôi hy vọng rằng chia sẻ một số bài học ban đầu sẽ giúp bạn suy luận về việc đầu tư nỗ lực của mình vào đâu để bạn có thể xây dựng mọi thứ.