- Một thử nghiệm xây dựng và phát hành sản phẩm phần mềm beta nội bộ với ràng buộc cố định là 0 dòng mã viết tay, trong đó Codex viết cả logic ứng dụng, bài kiểm thử, cấu hình CI, tài liệu, hệ thống quan sát và công cụ nội bộ
- Bắt đầu từ một kho git trống, codebase đã tăng lên khoảng 1 triệu dòng sau khoảng 5 tháng, với thông lượng PR khi ba kỹ sư vận hành Codex để mở và hợp nhất khoảng 1.500 PR
- Công việc chính của kỹ sư chuyển từ viết mã sang thiết kế môi trường, đặc tả ý định và xây dựng vòng phản hồi để giúp agent làm việc một cách đáng tin cậy
- Tri thức của kho mã được quản lý bằng
AGENTS.mdngắn gọn,docs/có cấu trúc, execution plan, linter và CI; còn UI, log, metric và trace được chuyển thành khả năng đọc hiểu của ứng dụng để Codex có thể trực tiếp đọc và xác minh - Khi thông lượng tăng, việc tối thiểu hóa merge gate và sửa bằng các lần chạy tiếp theo trở thành lựa chọn thực tế, nhưng tính nhất quán kiến trúc dài hạn và việc mã hóa phán đoán của con người vẫn là bài toán đang học
Bản beta nội bộ được tạo ra với 0 dòng mã viết tay
- Trong 5 tháng qua, đã tiến hành một thử nghiệm xây dựng và phát hành sản phẩm phần mềm beta nội bộ với 0 dòng mã viết tay
- Sản phẩm có người dùng nội bộ hằng ngày và các alpha tester bên ngoài, và đang thực sự trải qua các luồng phát hành, triển khai, sự cố và sửa lỗi
- Mọi dòng mã từ logic ứng dụng, bài kiểm thử, cấu hình CI, tài liệu, hệ thống quan sát đến công cụ nội bộ đều do Codex viết, và ước tính được xây dựng trong khoảng 1/10 thời gian so với khi viết mã bằng tay
- Con người điều phối, agent thực thi
- Kết quả cuối cùng, sau vài tuần, phải được phát hành ở quy mô khoảng 1 triệu dòng mã; vì vậy công việc chính của đội kỹ thuật đã chuyển từ viết mã sang thiết kế môi trường, đặc tả ý định và xây dựng vòng phản hồi
Bắt đầu từ một kho git trống
- Commit đầu tiên của kho trống được tạo vào cuối tháng 8 năm 2025
- Scaffold ban đầu gồm cấu trúc kho, cấu hình CI, quy tắc định dạng, cấu hình package manager và framework ứng dụng được Codex CLI dùng GPT-5 tạo ra với sự hướng dẫn từ một số template sẵn có
- File
AGENTS.mdban đầu để hướng dẫn cách agent làm việc trong kho cũng do Codex viết - Không có mã do con người viết từ trước để chống đỡ hệ thống, và kho được hình thành bởi agent ngay từ đầu
- Sau 5 tháng, kho đạt quy mô khoảng 1 triệu dòng trải khắp logic ứng dụng, hạ tầng, công cụ, tài liệu và tiện ích cho lập trình viên nội bộ
- Ba kỹ sư vận hành Codex để mở và hợp nhất khoảng 1.500 PR, tương đương thông lượng trung bình 3,5 PR mỗi ngày cho mỗi kỹ sư
- Thông lượng còn tăng thêm sau khi đội ngũ hiện đã mở rộng lên bảy kỹ sư
- Kết quả không phải là đầu ra chỉ để tạo đầu ra; sản phẩm đang được hàng trăm người dùng nội bộ sử dụng, 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 không trực tiếp đóng góp mã, và không có mã viết tay là triết lý cốt lõi của nhóm
Định nghĩa lại vai trò kỹ sư
- Ràng buộc không để con người trực tiếp viết mã đã đưa vào 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
- Tiến độ ban đầu chậm hơn dự kiến, nhưng không phải vì Codex thiếu năng lực mà vì môi trường chưa được đặc tả đủ rõ
- Agent thiếu công cụ, abstraction và cấu trúc nội bộ cần thiết để tiến tới các mục tiêu ở mức cao
- Công việc chính của đội kỹ thuật là làm cho agent có thể làm được việc hữu ích
- Công việc thực tế là chia các mục tiêu lớn thành những khối nhỏ hơn như thiết kế, mã, review, kiểm thử; đưa prompt để agent tạo ra các khối đó; rồi dùng chúng làm bàn đạp cho các tác vụ phức tạp hơn theo cách đi theo chiều sâu
- Khi thất bại, cách giải quyết không phải là “cố gắng hơn” mà là tìm ra năng lực nào còn thiếu để Codex hoàn thành công việc, rồi biến điều đó thành thứ mà agent có thể đọc và làm theo
- Con người chủ yếu tương tác với hệ thống qua prompt, theo luồng kỹ sư mô tả công việc, chạy agent rồi để agent mở PR
- Trong quá trình hoàn tất PR, 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 từ con người hoặc agent, rồi lặp lại cho đến khi mọi reviewer là agent đều hài lòng, theo cách gần với 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à skill tích hợp trong kho để thu thập ngữ cảnh mà không cần con người copy-paste - Con người có thể review PR nhưng không bắt buộc; theo thời gian, gần như toàn bộ công việc review đã chuyển sang xử lý giữa các agent
Tăng khả năng đọc hiểu của ứng dụng
- Khi thông lượng xử lý mã tăng lên, nút thắt chuyển sang năng lực QA của con người
- Vì ràng buộc cố định là thời gian và sự chú ý của con người, nên năng lực của agent được mở rộng bằng cách làm cho UI ứng dụng, log và metric của app có thể được Codex trực tiếp đọc hiểu
- Ứng dụng được cấu hình để có thể khởi động theo từng git worktree, cho phép Codex chạy và thao tác một instance cho mỗi thay đổi
- Chrome DevTools Protocol được kết nối vào runtime của agent, đồng thời tạo các skill cho snapshot DOM, screenshot và thao tác điều hướng
- Nhờ đó, Codex có thể tái hiện lỗi, xác minh bản sửa và trực tiếp suy luận hành vi UI
- Log, metric và trace được phơi bày cho Codex thông qua một stack observability local tồn tại tạm thời cho từng worktree cụ thể
- Codex làm việc trên một phiên bản ứng dụng hoàn toàn cô lập, bao gồm cả log và metric, và khi công việc đó kết thúc thì các log và metric liên quan cũng bị xóa
- Agent truy vấn log bằng LogQL và truy vấn metric bằng PromQL
- Các prompt như “đảm bảo khởi động service hoàn tất trong dưới 800ms” hoặc “đảm bảo không span nào trong bốn user journey cốt lõi vượt quá 2 giây” được chuyển thành tác vụ có thể thực thi
- Việc một lần chạy Codex đơn lẻ xử lý một tác vụ trong hơn 6 giờ là chuyện thường gặp, và khoảng thời gian đó thường là lúc con người đang ngủ
Biến tri thức của kho mã thành hệ thống lưu trữ chính thức
- Một trong những thách thức cốt lõi để làm cho agent hiệu quả trong các tác vụ lớn và phức tạp là quản lý ngữ cảnh
- Codex không cần một cuốn sổ tay hướng dẫn 1.000 trang mà cần một tấm bản đồ
- Ngữ cảnh là tài nguyên khan hiếm, và các file hướng dẫn khổng lồ sẽ đẩy công việc, mã và tài liệu liên quan ra ngoài, khiến agent bỏ lỡ các ràng buộc cốt lõi hoặc tối ưu nhầm ràng buộc
- Hướng dẫn quá mức thì không còn là hướng dẫn, vì khi mọi thứ đều quan trọng thì chẳng có gì còn quan trọng, dẫn đến việc agent chỉ dừng ở mức đối sánh mẫu cục bộ thay vì chủ động khám phá
- Một cẩm nang khổng lồ duy nhất sẽ nhanh chóng lỗi thời, có nguy cơ trở thành nghĩa địa của các quy tắc cũ và thành vật cản hấp dẫn mà con người không bảo trì
- Một file nguyên khối duy nhất khiến việc kiểm chứng cơ học về độ bao phủ, tính cập nhật, quyền sở hữu và liên kết chéo trở nên khó khăn, nên trôi lệch là điều không thể tránh
AGENTS.mdđược xem là mục lục chứ không phải bách khoa toàn thư- Cơ sở tri thức của kho được đặt trong thư mục
docs/có cấu trúc và được xem là hệ thống lưu trữ chính thức - Một
AGENTS.mdngắn khoảng 100 dòng được đưa vào ngữ cảnh, đóng vai trò bản đồ chỉ đến những nguồn chân lý sâu hơn - Tài liệu thiết kế được lập danh mục và lập chỉ mục cùng với tập hợp niềm tin cốt lõi xác định 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 đồ ở mức cao nhất về domain và các tầng package
- Tài liệu chất lượng chấm điểm từng domain sản phẩm và từng tầng 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; thay đổi nhỏ dùng các kế hoạch nhẹ mang tính tạm thời, còn tác vụ phức tạp thì được commit vào kho dưới dạng execution plan kèm tiến độ và log quyết định
- Kế hoạch đang hoạt động, kế hoạch đã hoàn tất và technical debt đã biết đều được quản lý phiên bản và đặt cùng nhau, giúp agent có thể làm việc mà không phụ thuộc vào ngữ cảnh bên ngoài
- Cấu trúc này cho phép công bố dần dần, để agent bắt đầu từ một điểm vào nhỏ và ổn định thay vì bị choáng ngợp ngay từ đầu, rồi học nơi cần xem tiếp theo
- Linter chuyên dụng và các job CI xác minh tính cập nhật, liên kết chéo và độ chính xác cấu trúc của cơ sở tri thức
- Một agent chăm sóc tài liệu chạy lặp lại sẽ tìm các tài liệu cũ hoặc obsolete không còn phản ánh hành vi thực tế của mã và tạo PR sửa chúng
Khả năng đọc hiểu của agent là mục tiêu
- Vì toàn bộ codebase là sản phẩm do agent tạo ra, mục tiêu tối ưu hóa cao nhất là khả năng đọc hiểu của Codex
- Cũng như việc giúp kỹ sư mới dễ khám phá mã, mục tiêu của kỹ sư con người là khiến agent có thể trực tiếp suy luận toàn bộ domain nghiệp vụ từ chính kho mã
- Từ góc nhìn của agent, thứ gì không thể truy cập trong ngữ cảnh lúc chạy thì về thực chất là không tồn tại
- Tri thức nằm trong Google Docs, thread chat hay trong đầu con người không phải đối tượng hệ thống có thể truy cập; chỉ mã, Markdown, schema và execution plan là artifact được quản lý phiên bản trong local của kho mà agent có thể nhìn thấy
- Dù cả nhóm có thống nhất một pattern kiến trúc qua thảo luận trên Slack, nếu agent không thể khám phá ra thì nó cũng giống như tri thức mà một người mới gia nhập sau 3 tháng không hề biết đến
- Cung cấp thêm ngữ cảnh cho Codex không phải là đổ vào các chỉ dẫn tùy tiện, mà là tổ chức và phơi bày đúng thông tin để agent có thể suy luận
- Cũng như onboarding thành viên mới với nguyên tắc sản phẩm, chuẩn mực kỹ thuật, văn hóa đội ngũ và cả sở thích dùng emoji, việc cung cấp các thông tin này cho agent cũng dẫn đến đầu ra đồng bộ hơn
- Phụ thuộc và abstraction được ưu tiên theo hướng có thể được nội tại hóa hoàn toàn và suy luận được bên trong kho
- Công nghệ thường bị xem là “nhàm chán” lại có xu hướng dễ để agent mô hình hóa hơn nhờ tính kết hợp, độ ổn định API và sự hiện diện trong dữ liệu huấn luyện
- Trong một số trường hợp, để agent tự triển khai lại một phần chức năng còn rẻ hơn việc vòng qua hành vi cấp cao mờ đục của thư viện công khai
- Thay vì mang vào một package kiểu
p-limitdùng chung, nhóm đã tự triển khai helper map-with-concurrency của riêng mình; nó được tích hợp chặt với OpenTelemetry, có 100% độ bao phủ kiểm thử và hành vi khớp chính xác với kỳ vọng runtime - Khi kéo được nhiều phần hơn của hệ thống vào dạng mà agent có thể trực tiếp kiểm tra, xác minh và sửa đổi, đòn bẩy không chỉ tăng cho Codex mà còn cho các agent khác như Aardvark cùng làm việc trên codebase đó
Cưỡng chế kiến trúc và gu kỹ thuật
- Chỉ tài liệu thôi là chưa đủ để duy trì tính nhất quán trong một codebase hoàn toàn do agent tạo ra
- Bằng cách cưỡng chế các điều kiện bất biến thay vì quản lý vi mô từng chi tiết triển khai, có thể tạo ra một cấu trúc cho phép agent phát hành nhanh mà không làm suy yếu nền tảng
- Với Codex, yêu cầu là phân tích hình dạng dữ liệu ở ranh giới, nhưng không quy định phải làm bằng cách nào
- Agent hoạt động hiệu quả nhất trong môi trường có ranh giới chặt chẽ và cấu trúc dễ dự đoán, nên ứng dụng được tổ chức xoay quanh một mô hình kiến trúc vững chắc
- Mỗi domain nghiệp vụ được chia thành một tập tầng cố định, còn hướng phụ thuộc và các kết nối được phép thì được kiểm chứng nghiêm ngặt
- Các ràng buộc này được cưỡng chế bằng linter tùy chỉnh và kiểm thử cấu trúc do Codex tạo ra
- Trong mỗi domain nghiệp vụ, mã chỉ được phép phụ thuộc tiến về phía trước theo các tầng cố định
Types → Config → Repo → Service → Runtime → UI - Các mối quan tâm xuyên suốt như xác thực, connector, telemetry và feature flag chỉ được phép đi vào thông qua một interface tường minh duy nhất là
Providers - Mọi phụ thuộc khác đều không được phép và bị chặn bằng cơ chế máy móc
- Đây thường là kiểu kiến trúc bị hoãn đến khi có hàng trăm kỹ sư, nhưng trong môi trường coding agent, nó là điều kiện tiên quyết ngay từ đầu để giữ tốc độ mà vẫn ngăn mục nát và trôi lệch kiến trúc
- Trong vận hành thực tế, các quy tắc được cưỡng chế bằng linter tùy chỉnh, kiểm thử cấu trúc và một tập nhỏ các “điều kiện bất biến về gu kỹ thuật”
- Logging có cấu trúc, quy ước đặt tên schema và type, giới hạn kích thước file, và yêu cầu độ tin cậy theo từng nền tảng đều được cưỡng chế tĩnh bằng custom lint
- Thông báo lỗi của custom lint được viết để chèn hướng dẫn sửa lỗi trực tiếp vào ngữ cảnh của agent
- Trong workflow ưu tiên con người, các quy tắc như vậy có thể bị thấy là quá tỉ mỉ hoặc gò bó, nhưng trong môi trường agent, một quy tắc đã được mã hóa một lần sẽ nhân lên và áp dụng đồng thời cho toàn bộ hệ thống
- Ở trung tâm, hệ thống kiểm soát chặt ranh giới, độ chính xác và khả năng tái lập; còn bên trong, đội ngũ hoặc agent có nhiều tự do trong cách biểu đạt lời giải
- Mã kết quả không phải lúc nào cũng khớp với sở thích phong cách của con người, nhưng nếu nó đúng, dễ bảo trì và có thể được các lần chạy agent sau này đọc hiểu thì đã đạt chuẩn
- Gu của con người tiếp tục được phản hồi ngược trở lại qua comment review, PR refactor và bug hướng ra người dùng để cập nhật tài liệu hoặc công cụ
- Khi tài liệu là chưa đủ, quy tắc sẽ được nâng cấp thành mã
Thông lượng đã thay đổi triết lý hợp nhất
- Khi thông lượng của Codex tăng lên, nhiều chuẩn mực kỹ thuật truyền thống bắt đầu phản tác dụng
- Kho mã được vận hành với số lượng merge gate chặn tối thiểu
- PR được giữ ngắn
- Flake trong kiểm thử thường được xử lý bằng các lần 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 sự chú ý của con người, chi phí sửa thấp còn chi phí chờ cao
- Đây là cách làm có thể bị xem là thiếu trách nhiệm trong môi trường thông lượng thấp, nhưng trong môi trường này lại thường là trade-off đúng
Phạm vi thực sự của “do agent tạo ra”
- Nói rằng codebase được tạo bởi agent Codex có nghĩa là mọi thứ bên trong codebase
- Những gì agent tạo ra bao gồm
- Mã sản phẩm và bài kiểm thử
- Cấu hình CI và công cụ phát hành
- Công cụ nội bộ cho lập trình viên
- 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 kho mã
- File định nghĩa dashboard production
- Con người luôn ở trong vòng lặp, nhưng làm việc ở tầng trừu tượng cao hơn trước
- Con người quyết định thứ tự ư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 và xác minh kết quả
- Khi agent gặp khó khăn, đó được xem là tín hiệu để tìm ra thứ còn thiếu trong công cụ, guardrail hoặc tài liệu, rồi đưa bản sửa đó trở lại kho và cũng để Codex viết
- Agent trực tiếp dùng các công cụ phát triển tiêu chuẩn, lấy feedback review, phản hồi inline, push cập nhật, và nhiều khi còn tự squash rồi merge PR của chính mình
Nâng mức tự chủ
- Khi ngày càng nhiều phần như kiểm thử, xác minh, review, xử lý phản hồi và phục hồi được mã hóa vào hệ thống, Codex gần đây đã vượt qua ngưỡng có thể tự đẩy một tính năng mới từ đầu đến cuối
- Những việc agent có thể làm chỉ với một prompt đơn lẻ
- 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 lại video thể hiện lỗi
- Triển khai bản sửa
- Trực tiếp thao tác ứng dụng để xác minh bản sửa
- Ghi lại video thứ hai cho thấy vấn đề đã được giải quyết
- Mở PR
- Phản hồi feedback từ agent và con người
- Phát hiện và sửa lỗi build thất bại
- Chỉ escalate cho con người khi cần phán đoán
- 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 đó, và không nên giả định là có thể tổng quát hóa nếu không có mức đầu tư tương tự
Entropy và garbage collection
- Tính tự chủ hoàn toàn của agent cũng đưa vào những vấn đề mới
- Codex sao chép các pattern đã tồn tại trong kho, và sẽ lặp lại chúng ngay cả khi các pattern đó không đồng đều hoặc không tối ưu
- Theo thời gian, sự lặp lại này dẫn đến trôi lệch
- Ban đầu con người xử lý việc đó thủ công, và nhóm đã dành mỗi thứ Sáu, tức 20% mỗi tuần, để dọn “AI slop”
- Cách làm này không thể mở rộng, nên nhóm đã mã hóa các “golden principle” trực tiếp vào kho và xây dựng quy trình dọn dẹp lặp lại
- Golden principle là các quy tắc cơ học có quan điểm rõ ràng nhằm giữ cho codebase dễ đọc và nhất quán cho các lần chạy agent trong tương lai
- Một ví dụ là ưu tiên shared utility package thay vì helper làm tay để tập trung hóa các điều kiện bất biến
- Một ví dụ khác là xác minh ranh giới hoặc dựa vào type SDK thay vì thăm dò dữ liệu theo kiểu “YOLO”, để agent không vô tình xây dựng trên những hình dạng mà nó chỉ đoán ra
- Các tác vụ Codex chạy nền định kỳ sẽ quét độ lệch, cập nhật điểm chất lượng và tạo các PR refactor có mục tiêu
- Phần lớn PR refactor có thể review trong dưới 1 phút và có thể auto-merge
- Quá trình này hoạt động giống như garbage collection
- Technical debt giống như khoản vay lãi cao; gần như luôn tốt hơn nếu trả dần liên tục theo từng phần nhỏ thay vì để dồn lại rồi xử lý đau đớn một lần
- Gu của con người, một khi đã được ghi lại, sẽ được cưỡng chế liên tục trên mọi dòng mã
- Các pattern xấu có thể được phát hiện và xử lý hằng ngày trước khi lan khắp codebase trong nhiều ngày hoặc nhiều tuần
Vẫn đang trong quá trình học hỏi
- Chiến lược này cho đến nay hoạt động tốt qua các giai đoạn phát hành và áp dụng nội bộ tại OpenAI
- Việc xây dựng sản phẩm thật cho người dùng thật giúp neo khoản đầu tư vào thực tế và kéo nó theo hướng khả năng bảo trì dài hạn
- Tính nhất quán kiến trúc trong một hệ thống hoàn toàn do agent tạo ra sẽ thay đổi thế nào qua nhiều năm vẫn còn là điều chưa biết
- Nhóm cũng vẫn đang học xem ở đâu phán đoán của con người tạo ra đòn bẩy lớn nhất, và làm sao mã hóa phán đoán đó để tạo hiệu ứng tích lũy
- Hệ thống này sẽ tiến hóa ra sao khi mô hình ngày càng giỏi hơn theo thời gian cũng vẫn là vùng chưa rõ
- Điều đã trở nên rõ ràng là việc xây dựng phần mềm vẫn đòi hỏi kỷ luật, nhưng kỷ luật đó thể hiện ở scaffolding nhiều hơn là ở mã
- Tầm quan trọng của công cụ, abstraction và vòng phản hồi để giữ tính nhất quán của codebase tiếp tục tăng lên
- Bài toán khó nhất hiện nay là thiết kế môi trường, vòng phản hồi và hệ thống điều khiển để giúp agent tạo và duy trì phần mềm phức tạp, đáng tin cậy ở quy mô lớn
- Khi các agent như Codex đảm nhận nhiều hơn trong vòng đời phần mềm, tầm quan trọng của những câu hỏi này sẽ còn tăng
- Những bài học ban đầu giúp phán đoán nên đầu tư nỗ lực vào đâu để có thể đơn giản là xây dựng thứ gì đó
1 bình luận
Ý kiến trên Hacker News
Thông lượng ở mức phi lý. Tôi tự hỏi nên lấy đường cơ sở nào để so sánh. Trước thời kỳ coding bằng agent, thông thường một kỹ sư được kỳ vọng sẽ mở bao nhiêu PR? Cỡ 2~10 PR mỗi ngày chăng?
Tôi cũng tự hỏi liệu trong 6 tháng qua phần mềm có thực sự tốt hơn không. Nếu số kỹ sư vẫn tương đương, thì chu kỳ lặp của các ứng dụng phần mềm lớn đáng ra phải nhanh hơn khoảng 5 lần, nhưng có vẻ không phải vậy. Ứng dụng AI thay đổi rất nhanh, nhưng đó là lĩnh vực quá mới nên mức đó cũng dễ hiểu; còn ngoài ra thì khó cảm nhận được
Ở đây là 1.500 PR cho 1 triệu dòng, tức mức tăng ròng khoảng 650 dòng mỗi PR. Không phải toàn bộ PR là 650 dòng, mà là mức tăng ròng +650 dòng sau khi lấy phần thêm vào trừ phần xóa đi
Có vài câu hỏi dành cho độc giả kỹ tính. Một dự án mà mỗi năm tăng thêm số dòng tương đương toàn bộ codebase của Firefox thì sau 10 năm sẽ trông ra sao? Số dòng nói gì về mức độ dài dòng của công cụ, và việc mục đích của dự án không được công khai rõ ràng nói gì về kết quả? Trong một thế giới con người không còn trực tiếp viết code, liệu còn lý do gì để bận tâm đến số dòng nữa không? Nếu codebase lớn hơn rất nhiều thì mức dùng token sẽ ra sao? Nếu được xác nhận rằng việc dùng LLM làm bùng nổ số dòng code, điều đó sẽ có ý nghĩa gì với các codebase đã dùng vài tháng rồi muốn quay lại lập trình thủ công vì chi phí?
Kỳ lạ là phần lớn ứng dụng của “agent” dường như lại dùng để tạo ra một sản phẩm AI khác. Kiểu như rùa chống đỡ rùa kéo dài vô tận. Có lẽ điều này nói nhiều hơn về lĩnh vực của Harness hơn là về sức mạnh của “agent”
Nhìn vào MS Office gần đây có rất nhiều thay đổi nhỏ, nhưng đa số chỉ gây khó chịu. Ví dụ như khi @tag đồng nghiệp trong bình luận Word thì mất focus, hay phải bấm hai lần mới gõ được vào ô tìm kiếm của Outlook, hoặc bộ chọn ngày trên Outlook mobile dường như đã mất tính năng hiển thị thời gian rảnh của tôi và của người tham dự
Vậy nên nhìn thì có vẻ thông lượng cao, nhưng đáng tiếc là lại đang làm hỏng những tính năng vốn hoạt động tốt. Hoặc họ đang tiêu thời gian cho những thứ không quan trọng, như thanh trạng thái tìm kiếm của OneDrive quay vòng quanh ô nhập liệu
Tức là phần lớn code được viết ra vẫn do tôi ngồi ghế lái và kiểm soát, còn AI chỉ dùng để tăng trạng thái tập trung và gỡ các chỗ bị kẹt. Tôi muốn công cụ chỉ tạo code ở mức tối thiểu
Trong 5 tháng qua tôi đã làm cùng một kiểu thử nghiệm ở tsz[1] và đi đến kết luận rất tương tự. Cần rất nhiều harness để ép buộc tách biệt kiến trúc tốt, đồng thời cũng cần rất nhiều test và CI
Mục tiêu khi xây dựng tsz là học cách làm các dự án rất lớn với AI. Cuối cùng, cùng một workflow và tư duy đó cũng có thể áp dụng để xây dựng các ứng dụng sản phẩm cho khách hàng có UI. Có vẻ OpenAI đang dùng cả kiểm thử trình duyệt tự động và video như một phần của workflow. Khi model tốt lên, hướng làm phần mềm kiểu này có lẽ rồi sẽ hợp lý, nhưng theo tôi thì vẫn chưa đến mức đó. Dù vậy, khác với các tuyên bố mơ hồ của OpenAI, ở đây họ có chia sẻ kết quả để mọi người tự xem
Những giải pháp như Lovable, vốn cung cấp mức tự động hóa rất cao, có phần hơi quá lạc quan và không gắn chặt với nhiều kiểm thử tự động
[1] https://github.com/tsz-org/tsz
Cách này trùng khớp hoàn toàn với những gì tôi đã làm. Hãy cung cấp cho Claude/Codex phương tiện để tự xác minh công việc của chúng. Ví dụ như trình duyệt, smoke test, end-to-end test, môi trường local có độ trung thực cao
Hãy đặt toàn bộ ngữ cảnh — issue tracking, tài liệu, ý tưởng, kế hoạch, nhật ký công việc — vào trong repo (https://github.com/shepherdjerred/monorepo/tree/main/package...)
Hãy cấp cho Claude/Codex quyền truy cập các công cụ quan sát như Grafana, Prometheus, Tempo, PagerDuty, và bắt chúng tuân theo các nguyên tắc kỹ thuật tốt như fail fast, type safety, parsing ở boundary
Chỉ là trong homelab tôi vẫn chưa đạt được mức tự chủ hoàn toàn vì chi phí và tải CI
Gần đây tôi xem một video về công nhân nhà máy thuốc lá điện tử. Họ nhấc từng bó thuốc lá điện tử từ băng chuyền lên, ngậm vào miệng, rít mạnh khoảng 5 giây rồi chuyển sang bó tiếp theo để kiểm tra. Việc con người review hàng trăm dòng thay đổi trong các PR do AI viết ra thực ra cũng không khác mấy
PR thì không như vậy. Một PR tệ có thể gây hậu quả chí mạng cho doanh nghiệp, trong khi một điếu thuốc lá điện tử lỗi thì thường không đến mức đó
Thêm nữa, nếu kỹ sư phần mềm lấy mẫu đầu ra của AI thì hiện tại chất lượng vẫn chưa liên tục đạt chuẩn mong muốn để đưa vào sản phẩm. Vì vậy vẫn phải review mọi PR và sửa khá nhiều cái
Nếu có thể giới hạn phạm vi ảnh hưởng của thay đổi, và đầu ra nhìn chung trở nên đủ chấp nhận được mà không cần giám sát, đến mức trong nhà máy chỉ cần kiểm tra chéo rằng không có hồi quy, thì cách tiếp cận lấy mẫu mới có thể hiệu quả
Tôi là một trong ba kỹ sư đã viết bài này. Nếu có câu hỏi thì tôi có thể trả lời
Tôi không phải người hoài nghi AI, nhưng tôi thấy đáng nghi về ý đồ của bài này. Nó đưa ra những tuyên bố lớn về kỹ thuật agent-first dựa trên một sản phẩm thật, người dùng thật, một đội ngũ thật đang tăng trưởng, và làm như thể đây là một ví dụ thực tế, nhưng lại không nói hay cho xem họ đã làm ra cái gì. Nó y hệt mọi bài cường điệu AI khác
Cái này chỉ có thể hoạt động nếu có tài nguyên tính toán vô hạn và token vô hạn
Với trải nghiệm dùng gói $20, kiểu tiếp cận agent thuần như thế này là bất khả thi. Rất nhanh sẽ đụng hạn mức và kết quả lại ít hơn
Cách đã cho hiệu quả rất tốt là cung cấp mã do con người viết làm tham chiếu rồi bảo nó mở rộng từ đó. Hãy dựng sẵn cấu trúc tổng thể, thiết kế kiến trúc, viết vài đoạn mã mẫu như controller, service, model, component, schema cơ sở dữ liệu, cách xác thực, để LLM có điểm tựa bắt đầu tập trung chú ý
Tôi thường viết các stub mô tả chi tiết cách triển khai. Nó giống pseudocode ở mức trừu tượng cao hơn. Sau đó tôi yêu cầu LLM hiện thực nó
Nếu thất bại, thường tốt hơn là hoàn tác toàn bộ thay đổi, điều chỉnh stub để nó có thể bắt được lỗi thất bại trước đó, rồi thử lại
Hoặc commit thay đổi rồi để nó xử lý riêng phần sai trong một ngữ cảnh mới
Nếu thử tiếp cận kiểu agent ngay từ đầu, tôi luôn thất vọng cả về kết quả lẫn hạn mức. Có khi chưa đến một tiếng đã chạm trần
Nâng lên $200/tháng thì dùng được nhiều hơn, nhưng ngay cả với người dùng nặng như tôi thì mức sử dụng vẫn luôn thiếu
Tôi vẫn ghen tị với những người được lượng sử dụng gấp 200 lần chỉ vì đã RSVP tham dự tiệc của OpenAI
Lại thêm một bài bán hàng thở dốc nữa. Kiểu bán cuốc cho thợ đào, nhưng vàng đâu? Những sản phẩm tuyệt vời thực sự đã được tạo ra nhờ các chatbot nói chuyện với nhau trên Git và sinh ra từng đống dòng mã ở đâu? Chẳng thấy gì cả
Tôi ước những bài blog phấn khích thế này mang tính hướng dẫn hơn một chút
Ví dụ, giá mà họ chỉ ra từng bước cách thiết lập workflow mà họ khẳng định là mạnh mẽ đến vậy và trình diễn cụ thể luôn
Tôi không phải người hoài nghi AI. Ngược lại, nếu thật sự có siêu năng lực ở đây thì tôi không muốn bỏ lỡ
Với tính năng mới thì tôi viết đặc tả tính năng bằng Gherkin, với phần cải tiến thì cập nhật nó, còn refactor thì không đụng vào. Tôi gắn nhãn PR bằng các danh từ này
Tôi chạy kiểm tra kiểu, lint, unit test và các bước xác minh khác nhanh và có thể script hóa bằng pre-push hook
Tôi tạo một site con VitePress trong repo và để agent duy trì nó. Tôi tài liệu hóa các nguyên tắc quan trọng, kiến trúc, v.v.
Tôi tạo một lệnh CLI liệt kê mọi trang và mô tả YAML frontmatter, để agent có thể chọn cái cần đọc mà không làm nổ cửa sổ ngữ cảnh
Tôi dùng thiết kế hướng miền và monorepo. Logic được viết trong các lớp headless, rồi các lớp được ghép thành ứng dụng. Agent điều hướng các lớp này rất tốt
Tôi dùng zod hoặc công cụ tương đương của ngôn ngữ đó và phát triển API theo hướng contract-first. Cá nhân tôi thích phần này nhất, và tôi dùng orpc
Tôi chỉ tạo một skill duy nhất là “code” và mô tả vòng đời của nó. Mở worktree, cấu hình
.envđể không xung đột với agent khác, chọn các cổng chưa dùng, và Docker rất phù hợp cho việc này. Viết hoặc cập nhật file tính năng, điều phối đặc tả ở đây rồi triển khai, xác minh bằng thứ như playwright mcp, chạy các kiểm tra trước khi push, chờ review sau khi push, dọn dẹp xong thì fast-forward merge vàomaintestcontainers rất tốt để bảo đảm nhiều agent có thể chạy test mà không va chạm nhau
Nghiêm túc là tôi chỉ có một skill thôi. Còn lại đều nằm trong tài liệu. Tôi thấy nó rất năng suất, không phải theo nghĩa số dòng mã, mà theo nghĩa “làm ra phần mềm tốt”
Để làm vậy, mỗi khi agent gặp vấn đề, tôi hỏi nó nên dùng công cụ hay script kiểm chứng nào để giải quyết. Trong quá trình audit, tôi cũng để nó tự viết luôn những công cụ đó. Kết quả là bây giờ đã có hơn 30 quy tắc để kiểm chứng commit[2], và chúng hoạt động khá tốt
[1] https://github.com/gildas-lormeau/rebuild-and-ruin (muốn xem chế độ “demo” thì cứ để đến khi đồng hồ đếm hết)
[2] https://github.com/gildas-lormeau/rebuild-and-ruin/blob/a4c3...
Ban đầu tôi đã thử cách này. Trước khi viết code, tôi dùng ChatGPT như một “quản lý dự án” để thiết lập toàn bộ harness. Một tuần sau, có hơn 140 tài liệu về quy tắc, kiến trúc và framework được tạo ra, còn số dòng code thì là 0
Về sau, khi cho một công cụ khác đánh giá, kết luận là “một két sắt trống hoàn hảo và an toàn tuyệt đối”
Harness rất chỉn chu, không có gì để chê, nhưng bên trong thì chẳng có gì cả
Harness rất quan trọng, nhưng nếu không đi song song với việc phát hành code thì rốt cuộc cũng chỉ là viết nên hư cấu mà thôi