- Đây là một trường hợp thử nghiệm trong đó một nhóm nội bộ của OpenAI đã xây dựng và phát hành bản beta nội bộ của một sản phẩm phần mềm trong 5 tháng mà không viết mã thủ công, toàn bộ mã đều do agent Codex tạo ra
- Bắt đầu với 3 kỹ sư, nhóm đã xử lý khoảng 1 triệu dòng mã và 1.500 pull request, tương đương trung bình 3,5 PR được hợp nhất mỗi ngày trên mỗi kỹ sư
- Vai trò của kỹ sư đã chuyển từ trực tiếp lập trình sang thiết kế môi trường, nêu rõ ý định và xây dựng vòng lặp phản hồi, trong đó việc dựng scaffolding để agent có thể làm việc ổn định là yếu tố cốt lõi
- AGENTS.md được dùng như mục lục chứ không phải bách khoa toàn thư, đồng thời tính nhất quán kiến trúc được áp đặt một cách cơ học thông qua tài liệu có cấu trúc, linter và kiểm thử cấu trúc
- Khi mức độ tự chủ của agent tăng lên, việc quản lý entropy và dọn dẹp liên tục theo kiểu garbage collection trở nên thiết yếu, và kỷ luật trong xây dựng phần mềm đang chuyển từ mã nguồn sang scaffolding
Thử nghiệm bắt đầu từ một kho git trống
- Cuối tháng 8 năm 2025, nhóm thực hiện commit đầu tiên vào một repository trống; scaffold ban đầu (cấu trúc repository, cấu hình CI, quy tắc định dạng, thiết lập package manager, framework ứng dụng) được tạo trong Codex CLI bằng GPT-5 dựa trên template sẵn có
- Tệp AGENTS.md ban đầu dùng để hướng dẫn agent cách làm việc với repository cũng do chính Codex viết
- Ngay từ đầu, repository được hình thành bởi agent mà không có mã nguồn có sẵn nào do con người viết
- Sau 5 tháng, repository chứa khoảng 1 triệu dòng mã trải rộng trên logic ứng dụng, hạ tầng, tooling, tài liệu và các tiện ích phát triển nội bộ
- Một nhóm nhỏ gồm 3 người đã mở và hợp nhất khoảng 1.500 pull request, tương đương thông lượng trung bình 3,5 PR mỗi ngày trên mỗi kỹ sư
- Khi nhóm tăng lên 7 người, thông lượng còn tiếp tục tăng
- Hệ thống đã được hàng trăm người dùng nội bộ sử dụng hằng ngày, bao gồm cả các power user nội bộ
- Trong toàn bộ quá trình phát triển, con người chưa từng trực tiếp đóng góp mã vào mã nguồn
- "Không có dòng mã nào được viết thủ công" đã trở thành triết lý cốt lõi của nhóm
Định nghĩa lại vai trò của kỹ sư
- Vì con người không còn trực tiếp viết mã, nên cần một kiểu công việc kỹ thuật khác tập trung vào hệ thống, scaffolding và đòn bẩy
- Lý do tiến độ ban đầu chậm hơn kỳ vọng không phải do Codex thiếu năng lực, mà do môi trường còn thiếu sót
- Agent thiếu công cụ, lớp trừu tượng và cấu trúc nội bộ để đạt được các mục tiêu cấp cao
- Công việc chính của đội ngũ kỹ thuật đã chuyển sang hỗ trợ agent thực hiện được những nhiệm vụ hữu ích
- Nhóm chia nhỏ các mục tiêu lớn thành những khối xây dựng nhỏ hơn (thiết kế, mã nguồn, review, kiểm thử, v.v.), rồi để agent ghép các khối này lại và giải quyết các nhiệm vụ phức tạp hơn theo kiểu làm việc theo chiều sâu
- Khi thất bại, câu hỏi cốt lõi không phải là "cố hơn nữa", mà là "đang thiếu khả năng nào, và làm sao để khiến nó dễ đọc và có thể thực thi được đối với agent"
- Con người gần như tương tác với hệ thống hoàn toàn thông qua prompt
- Chỉ dẫn mô tả công việc, chạy agent, mở pull request, v.v.
- Để hoàn tất PR, nhóm yêu cầu Codex tự review thay đổi của mình ở local, yêu cầu thêm review từ agent ở local và trên cloud, phản hồi feedback, rồi lặp lại cho đến khi mọi reviewer là agent đều hài lòng
- Về bản chất là cách làm Ralph Wiggum Loop
- Codex trực tiếp dùng các công cụ phát triển tiêu chuẩn như gh, script local và các kỹ năng tích hợp trong repository để thu thập ngữ cảnh
- Con người vẫn có thể review pull request, nhưng không còn là bắt buộc; theo thời gian, gần như toàn bộ công việc review đã được chuyển sang xử lý giữa các agent
Tăng khả năng đọc được của ứng dụng
- Khi thông lượng mã tăng lên, năng lực QA của con người trở thành điểm nghẽn
- Vì thời gian và sự chú ý của con người là tài nguyên cố định, nhóm đã bổ sung khả năng cho agent bằng cách làm cho UI ứng dụng, log và metric có thể được Codex trực tiếp đọc và hiểu
- Tính năng khởi động ứng dụng theo từng git worktree cho phép Codex chạy và điều khiển một instance riêng cho từng thay đổi
- Nhóm kết nối Chrome DevTools Protocol vào runtime của agent và tạo kỹ năng cho snapshot DOM, screenshot và thao tác điều hướng
- Nhờ đó Codex có thể trực tiếp tái hiện bug, xác minh bản sửa lỗi và suy luận về hành vi UI
- Tooling quan sát hệ thống cũng được áp dụng theo cách tương tự
- Log, metric và trace được đưa tới Codex thông qua một stack observability cục bộ tồn tại tạm thời cho từng worktree
- Sau khi công việc hoàn tất, log và metric sẽ bị xóa
- Agent có thể truy vấn log bằng LogQL và metric bằng PromQL
- Khi có ngữ cảnh như vậy, việc xử lý các prompt như "khởi động dịch vụ trong vòng 800ms" hoặc "không để span nào vượt quá 2 giây trên bốn hành trình người dùng cốt lõi" trở nên dễ dàng
- Một lần chạy Codex có thể thực hiện một tác vụ duy nhất trong hơn 6 giờ (thường là khi con người đang ngủ)
Dùng tri thức của repository như một hệ thống hồ sơ
- Quản lý ngữ cảnh là một trong những thách thức lớn nhất để agent thực hiện hiệu quả các tác vụ lớn và phức tạp
- Bài học ban đầu là: cần đưa cho Codex một tấm bản đồ, chứ không phải cuốn cẩm nang 1.000 trang
- Nhóm từng thử cách làm "một AGENTS.md thật lớn" và thất bại đúng như dự đoán
- Ngữ cảnh là tài nguyên khan hiếm: tệp chỉ dẫn khổng lồ khiến tác vụ, mã và tài liệu liên quan trở nên rối rắm, làm agent bỏ sót các ràng buộc quan trọng hoặc tối ưu sai ràng buộc
- Quá nhiều chỉ dẫn thì không còn là chỉ dẫn: nếu mọi thứ đều "quan trọng" thì sẽ chẳng còn gì thực sự quan trọng; agent sẽ chỉ còn đối sánh mẫu cục bộ thay vì khám phá có chủ đích
- Rất nhanh bị hỏng: cẩm nang khổng lồ đồng nhất nhanh chóng biến thành nghĩa địa của các quy tắc lỗi thời, còn agent thì không thể xác định điều gì vẫn còn hiệu lực
- Khó xác minh: một khối blob duy nhất không phù hợp cho việc kiểm tra cơ học (độ bao phủ, độ mới, quyền sở hữu, liên kết chéo), nên sự lệch pha là không thể tránh khỏi
- Giải pháp là xem AGENTS.md như mục lục chứ không phải bách khoa toàn thư
- Cơ sở tri thức của repository được quản lý như một hệ thống hồ sơ trong thư mục
docs/ có cấu trúc
- Một AGENTS.md ngắn (khoảng 100 dòng) được chèn vào ngữ cảnh và chủ yếu đóng vai trò bản đồ, dẫn tới những nguồn thông tin sâu hơn và đáng tin cậy hơn
- Tài liệu thiết kế được phân loại và lập chỉ mục, bao gồm các niềm tin cốt lõi định nghĩa trạng thái xác minh và nguyên tắc vận hành ưu tiên agent
- Tài liệu kiến trúc cung cấp bản đồ cấp cao nhất về domain và cách phân lớp package
- Tài liệu chất lượng chấm điểm từng domain sản phẩm và từng lớp kiến trúc, đồng thời theo dõi khoảng cách theo thời gian
- Kế hoạch được xem là artifact hạng nhất
- Các kế hoạch tạm thời, đơn giản được dùng cho những thay đổi nhỏ
- Các tác vụ phức tạp được đưa vào kế hoạch thực thi cùng với tiến độ và nhật ký quyết định, rồi lưu trong repository
- Kế hoạch đang thực hiện, kế hoạch đã hoàn thành và cả các khoản nợ kỹ thuật đã biết đều được quản lý phiên bản và đặt cùng một chỗ
- Nhờ vậy có thể công bố dần dần: agent bắt đầu từ những điểm vào nhỏ, ổn định mà không bị quá tải ngay từ đầu, rồi tiến tiếp sang bước kế tiếp
- Việc cưỡng chế bằng cơ học: linter chuyên dụng và các job CI xác minh rằng cơ sở tri thức luôn cập nhật, có liên kết chéo và được cấu trúc đúng
- Một agent "doc-gardening" chạy lặp lại sẽ kiểm tra các tài liệu cũ hoặc không còn hiệu lực và mở pull request để sửa
Mục tiêu là khả năng đọc được đối với agent
- Vì repository được tạo hoàn toàn bởi agent, nó được tối ưu trước hết cho khả năng đọc của Codex
- Mục tiêu của kỹ sư con người là để agent có thể suy luận về toàn bộ domain kinh doanh ngay từ chính repository
- Từ góc nhìn của agent, bất cứ thứ gì không truy cập được trong ngữ cảnh lúc chạy thì về thực chất là không tồn tại
- Google Docs, các luồng chat và kiến thức nằm trong đầu con người đều không thể được hệ thống truy cập
- Chỉ các artifact được quản lý phiên bản trong repository (mã nguồn, Markdown, schema, kế hoạch thực thi) mới truy cập được
- Ngay cả một mẫu kiến trúc đã được thống nhất trong thảo luận Slack cũng là không thể đọc được nếu agent không thể tìm thấy nó
- Cung cấp thêm ngữ cảnh cho Codex không có nghĩa là nhồi thêm chỉ dẫn tạm thời, mà là tổ chức và phơi bày đúng thông tin để agent có thể suy luận
- Kết quả sẽ tốt hơn khi cung cấp cho agent thông tin về nguyên tắc sản phẩm, chuẩn mực kỹ thuật và văn hóa nhóm (kể cả sở thích dùng emoji) theo cách giống như onboarding một thành viên mới
- Nhóm ưu tiên những phụ thuộc và lớp trừu tượng mà agent có thể nội hóa hoàn toàn và suy luận được ngay trong repository
- Các công nghệ "nhàm chán" thường dễ để agent mô hình hóa hơn nhờ độ kết dính, tính ổn định của API và mức độ hiện diện trong dữ liệu huấn luyện
- Trong một số trường hợp, để agent tự tái triển khai một tập con tính năng còn rẻ hơn việc phụ thuộc vào hành vi upstream mờ đục của thư viện công khai
- Ví dụ: tự triển khai helper map-with-concurrency thay vì dùng package kiểu
p-limit đa dụng, nhờ đó tích hợp chặt chẽ với OpenTelemetry instrumentation, đạt 100% test coverage và hoạt động đúng như kỳ vọng ở runtime
- Càng kéo hệ thống lên dạng mà agent có thể kiểm tra, xác minh và trực tiếp sửa đổi, đòn bẩy không chỉ tăng với Codex mà còn với các agent khác (ví dụ Aardvark)
Áp đặt kiến trúc và gu kỹ thuật
- Chỉ riêng tài liệu là không đủ để giữ cho một codebase do agent tạo ra luôn hoàn toàn nhất quán
- Nhóm giữ nền tảng vững chắc đồng thời cho phép agent phát hành nhanh bằng cách cưỡng chế các bất biến mà không vi mô hóa cách triển khai
- Ví dụ: nhóm muốn Codex parse hình dạng dữ liệu ở ranh giới, nhưng không chỉ định chi tiết phải làm bằng cách nào (dù model có xu hướng thích Zod)
- Agent hoạt động hiệu quả nhất trong môi trường có ranh giới nghiêm ngặt và cấu trúc dễ dự đoán
- Ứng dụng được xây dựng xoay quanh một mô hình kiến trúc chặt chẽ
- Mỗi domain nghiệp vụ được tách thành một tập lớp cố định với hướng phụ thuộc được xác minh nghiêm ngặt và một tập cạnh cho phép bị giới hạn
- Mã đi theo thứ tự Types → Config → Repo → Service → Runtime → UI
- Các mối quan tâm xuyên suốt (xác thực, connector, telemetry, feature flag) đi vào thông qua một giao diện tường minh duy nhất tên là Providers
- Mọi thứ khác đều không được phép và bị cưỡng chế bằng cơ học
- Những ràng buộc này được áp dụng thông qua linter tùy biến và kiểm thử cấu trúc do Codex tạo ra
- Mức kiến trúc như vậy thường bị trì hoãn cho đến khi tổ chức có hàng trăm kỹ sư, nhưng với agent lập trình thì đó là điều kiện tiên quyết ngay từ đầu
- Lint tùy chỉnh còn dùng để áp dụng tĩnh logging có cấu trúc, quy ước đặt tên cho schema và type, giới hạn kích thước tệp và các yêu cầu ổn định theo từng nền tảng
- Vì lint là tùy biến, nhóm có thể viết thông điệp lỗi để tiêm chỉ dẫn sửa lỗi trực tiếp vào ngữ cảnh của agent
- Trong workflow lấy con người làm trung tâm, những quy tắc này có thể bị xem là quá chi li hoặc quá gò bó, nhưng khi dùng agent thì hiệu quả của chúng được khuếch đại nhiều lần
- Các ràng buộc giúp phân định rõ điều gì là quan trọng và điều gì không
- Điều này tương tự việc vận hành một tổ chức nền tảng kỹ thuật quy mô lớn: trung tâm đặt ranh giới, địa phương được tự chủ
- Mã sinh ra có thể không phải lúc nào cũng khớp với sở thích văn phong của con người, nhưng nếu đầu ra đúng, dễ bảo trì và dễ đọc khi agent chạy thì coi như đạt chuẩn
- Gu của con người được phản hồi liên tục vào hệ thống
- Comment review, PR refactor và bug phía người dùng sẽ được ghi lại dưới dạng cập nhật tài liệu hoặc mã hóa trực tiếp vào tooling
- Nếu tài liệu là chưa đủ, thì nâng quy tắc thành mã
Sự thay đổi trong triết lý hợp nhất
- Khi thông lượng của Codex tăng lên, các chuẩn mực kỹ thuật truyền thống lại trở nên phản tác dụng
- Repository được vận hành với các cổng chặn merge tối thiểu
- Pull request có vòng đời ngắn, còn tình trạng test không ổn định sẽ được xử lý ở lượt chạy tiếp theo thay vì chặn tiến trình vô thời hạn
- Trong hệ thống mà thông lượng của agent vượt xa mức chú ý của con người, chi phí sửa lỗi rẻ còn độ trễ thì đắt
- Cách này có thể không phù hợp trong môi trường có thông lượng thấp hơn, nên cần đánh đổi thích hợp
Phạm vi thực sự của "được agent tạo ra"
- Khi nói codebase được tạo bởi agent Codex, điều đó có nghĩa là mọi thứ trong codebase
- Mã sản phẩm và kiểm thử
- Cấu hình CI và tooling 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ế
- Evaluation harness
- Comment review và phản hồi
- Script quản lý chính repository
- Tệp định nghĩa dashboard production
- Con người vẫn luôn ở trong vòng lặp, nhưng làm việc ở một tầng trừu tượng khác so với trước đây
- Ưu tiên công việc, chuyển phản hồi người dùng thành tiêu chí chấp nhận, xác minh kết quả
- Khi agent gặp khó khăn, nhóm xem đó là tín hiệu để xác định phần còn thiếu trong công cụ, guardrail và tài liệu, rồi luôn để chính Codex viết bản sửa và đưa trở lại repository
- Agent còn có thể lấy feedback review, trả lời inline, push bản cập nhật, thậm chí tự squash và merge pull request của chính mình
Mức độ tự chủ ngày càng tăng
- Khi nhiều vòng lặp phát triển hơn như kiểm thử, xác minh, review, xử lý phản hồi và khôi phục được mã hóa trực tiếp vào hệ thống, nhóm đã chạm tới một ngưỡng quan trọng
- Những việc agent có thể làm chỉ với một prompt bao gồm:
- Xác minh trạng thái hiện tại của codebase
- Tái hiện bug đã được báo cáo
- Ghi video cho thấy tình huống lỗi
- Triển khai bản sửa
- Chạy ứng dụng để xác minh bản sửa
- Ghi video thứ hai cho thấy giải pháp
- Mở pull request
- Phản hồi feedback từ agent và con người
- Phát hiện và sửa lỗi build
- Escalate lên con người chỉ khi cần đến phán đoán
- Hợp nhất thay đổi
- Những hành vi này phụ thuộc rất lớn vào cấu trúc và tooling cụ thể của repository này, nên không thể mặc định rằng chúng sẽ tổng quát hóa được nếu không có đầu tư tương tự
Entropy và garbage collection
- Sự tự chủ hoàn toàn của agent tạo ra vấn đề mới: Codex sao chép các mẫu đã tồn tại trong repository, kể cả các mẫu không đồng nhất hoặc chưa tối ưu, nên theo thời gian sự lệch pha là không thể tránh khỏi
- Ban đầu con người xử lý thủ công, dành thời gian vào mỗi thứ Sáu (20% tuần làm việc) để dọn dẹp "AI slop"
- Đúng như dự đoán, cách này không thể mở rộng
- Giải pháp thay thế là mã hóa "các nguyên tắc vàng" trực tiếp vào repository và xây dựng quy trình dọn dẹp định kỳ
- (1) Ưu tiên gói utility dùng chung hơn là các helper tự viết để quản lý bất biến theo cách tập trung
- (2) Không khám phá dữ liệu theo kiểu "YOLO-style"; thay vào đó, xác minh ở ranh giới hoặc dựa vào SDK có kiểu để ngăn agent vô tình xây dựng dựa trên những hình dạng mà nó chỉ đoán ra
- Nhóm vận hành các tác vụ nền của Codex để thường xuyên kiểm tra độ lệch, cập nhật điểm chất lượng và tạo PR refactor có mục tiêu
- Phần lớn có thể review trong vòng 1 phút và được tự động merge
- Cách làm này hoạt động như garbage collection: nợ kỹ thuật giống như khoản vay lãi cao, nên trả dần từng chút một trước khi lãi tích tụ sẽ hiệu quả hơn
- Một khi gu của con người đã được nắm bắt, nó sẽ liên tục phản ánh trên mọi dòng mã; các mẫu xấu được phát hiện và xử lý hằng ngày thay vì để lan rộng trong nhiều ngày hoặc nhiều tuần
Bài học đang tiếp diễn và thách thức phía trước
- Chiến lược này đã được áp dụng hiệu quả tại OpenAI cho đến giai đoạn phát hành và triển khai nội bộ
- Việc xây dựng sản phẩm thực cho người dùng thực giúp đưa các khoản đầu tư này bám vào thực tế và đảm bảo khả năng bảo trì dài hạn
- Điều vẫn chưa rõ là: trong một hệ thống được tạo hoàn toàn bởi agent, tính nhất quán kiến trúc sẽ tiến hóa ra sao trong nhiều năm
- Nhóm vẫn đang học xem phần nào là nơi phán đoán của con người tạo ra ảnh hưởng lớn nhất, và làm sao mã hóa phán đoán đó để tái sử dụng theo hiệu ứng cộng dồn
- Khi năng lực của mô hình tiếp tục tăng, hướng phát triển tiếp theo của hệ thống này vẫn còn là điều chưa biết
- Việc xây dựng phần mềm vẫn cần kỷ luật, nhưng kỷ luật ấy ngày càng thể hiện nhiều hơn trong scaffolding chứ không phải trong mã nguồn
- Tooling, lớp trừu tượng và vòng lặp phản hồi để giữ codebase nhất quán đang ngày càng trở nên quan trọng hơn
- Thách thức lớn nhất hiện tại là thiết kế môi trường, vòng lặp phản hồi và hệ thống điều khiển giúp agent xây dựng và bảo trì phần mềm phức tạp, ổn định ở quy mô lớn
1 bình luận
40 ngày, 1 triệu dòng, 13 tỷ token — CEO Lablup Shin Jeong-gyu khám phá bản chất của quy trình làm việc tác tử - Silicon Valley của Park Jae-hong - https://wikidocs.net/blog/@jaehong/8206/