- Anthropic đang sử dụng các
agentAI nhưRoboBunvàClaude code reviewđể tự động hóa đáng kể quy trình phát triểnBun, từ việc tái hiệnissuevà tạoPRđến việcreviewmã. - Hệ thống này giúp tiết kiệm lượng lớn
thời gian phát triểnbằng cách giải quyết các tác vụ lặp đi lặp lại và phát hiện cácbugtinh vi, cho phép kỹ sư tập trung vào các vấn đề phức tạp hơn. - Hiệu quả của các
agentđược nâng cao nhờClaude MD(tài liệu hướng dẫn cụ thể), vòng lặpCI/CDchặt chẽ, và chiến lược "hill climbing" nơiagenttự xác minh và lặp lại để đạt được mục tiêu, đặc biệt với cácLLMmạnh mẽ nhưClaude 4.7/Opus.
Live coding session with Claude Code and Boris
- Tự động tái hiện lỗi & tạo PR:
RoboBuntự động tái hiệnissuevà tạoPRkèmtest, đảm bảo cáctestnày thất bại trên phiên bản cũ và pass trên phiên bản mới để xác minh bản sửa lỗi. - Tối ưu hóa Code Review đa tác nhân: Sử dụng kết hợp
agent(ví dụ:Code Rabbitchostyle,Claude code reviewcho logic sâu vàedge case) giúp phát hiệnbugcần nhiềucontextvà giải quyết các vấn đề nhỏ, giảmchi phí chuyển đổithủ công. - Tài liệu hóa (
Claude MD) là chìa khóa: Cung cấp tài liệu chi tiết về cáchbuild, chạytest, viếttest, cấu trúccodevà xử lý cácissuephổ biến choagentlà điều kiện tiên quyết để chúng hoạt động hiệu quả. - Vòng lặp CI/CD tự động:
Agentcần có khả năng đọclỗi CIvàbuild log, thực hiện toàn bộ vòng lặp từ viết mã, kiểm thử,giám sát CIđến sửa lỗi để mọi thứ sẵn sàngmergekhi đến tay con người. - Chiến lược "Hill Climbing": Để
agenthoạt động tự động hiệu quả, hãy cung cấp cho chúng một mục tiêu (metric), cách để cải thiện (improve performance), và cách để đo lường (measure), cho phép chúng lặp lại liên tục cho đến khi hoàn thành. - Tăng cường khả năng của LLM: Các mô hình
LLMtiên tiến (nhưClaude 4.7/Opus) đã đạt đến mức có thể thực hiện các quy trình tự động hóa phức tạp này một cáchhiệu quảhàng ngày, thay vì chỉ vớiscaffoldinglớn. - Khả năng mở rộng cho sản phẩm thương mại: Mô hình này không chỉ giới hạn ở
mã nguồn mởmà có thể áp dụng cho các sản phẩm thương mại, ví dụ, tự động xử lýcustomer support ticketbằng cách chobottái hiệnissuevà tạoPR.
agent— tác nhânClaude Code— Claude Code (tên sản phẩm/tính năng)Bun— Bun (tên sản phẩm)PR— Pull Request (Yêu cầu hợp nhất mã)issue— vấn đề (lỗi, yêu cầu tính năng)repo— kho chứa (repository)bot— bot (rô-bốt tự động)test— kiểm thửmerge— hợp nhấtdebug— gỡ lỗicode review— đánh giá mãLLM— Large Language Model (Mô hình ngôn ngữ lớn)context— ngữ cảnhlinter— công cụ kiểm tra cú pháp/phong cách mãCLI tool— công cụ dòng lệnhcustomer support ticket— phiếu hỗ trợ khách hàngbuild— xây dựng (dự án, mã nguồn)CI/CD— Continuous Integration/Continuous Deployment (Tích hợp liên tục/Triển khai liên tục)Claude MD— Claude MD (tài liệu/hướng dẫn cụ thể cho Claude)hill climbing— leo đồi (thuật toán tối ưu hóa)scaffolding— khung sườn (cấu trúc hỗ trợ)benchmark— điểm chuẩnedge case— trường hợp ngoại lệ/biênbottleneck— nút thắt cổ chai
Giới thiệu và thiết lập agent
Chào mừng lên sân khấu, Boris Cherny, Trưởng phòng Claude Code tại Anthropic, và Jared Sumner, người sáng tạo Bun tại Anthropic. Được rồi, đây là một hội nghị dành cho nhà phát triển. Chúng ta sẽ nói chuyện một chút, nhưng chủ yếu tôi sẽ tập trung vào coding. Vì vậy, phần này dành cho các nhà phát triển có mặt tại đây. Tôi sẽ bắt đầu bằng cách nói một chút về cách Bun sử dụng Claude Code để xây dựng và duy trì Bun, cũng như cách thiết lập của chúng tôi hoạt động. Bởi vì đây là một thiết lập hơi nâng cao hơn so với những gì phổ biến hiện nay. Nhưng trước tiên, tôi sẽ cho một vài tác nhân chạy để khắc phục và giải quyết các vấn đề. Đây là một cảnh kinh điển của Jared khi làm việc trong lúc đang thuyết trình.
Tự động tái hiện lỗi và tạo PR với RoboBun
Trong repo của Bun, mỗi khi ai đó gửi một issue, chúng tôi có một block của Claude tự động chạy và cố gắng tái hiện issue đó. Bạn có thể thấy người này có side effect này, và đây là một trong những issue gần đây nhất. Và chúng ta có thể thấy rằng RoboBun, bot của chúng tôi, đã quản lý để tái hiện issue và tự động gửi một PR. Tất cả các PR này luôn có test. Đây là một trong những yêu cầu bắt buộc trước khi bạn có thể gửi một PR. Vậy thách thức ở đây là, liệu code này có vẻ đúng không? Và một trong những điều chúng tôi làm để kiểm tra là, liệu test có thất bại ở phiên bản Bun trước đó trong debug branch này không? Và bot thực sự không thể gửi PR nếu không thỏa mãn điều kiện đó. Điều này có nghĩa là, với mọi issue xuất hiện trong issue tracker của Bun, bạn đều có RoboBun tự động cố gắng tái hiện nó trước khi bất kỳ ai chấp nhận. Điều này tiết kiệm rất nhiều thời gian vì chúng tôi có rất nhiều issue get-out đang mở. Nó thực sự chuyển thách thức từ việc chỉ sửa lỗi và debug issue sang việc, đây có phải là thứ đúng để merge không? Liệu đây có phải là bản sửa lỗi đúng không? Nó tốt đến mức nào? Nó vẫn còn 100% của bạn hay chỉ 10%? Chúng ta có thể vào phần insights và contributors. Và nếu chúng ta xem trong ba tháng gần nhất, và đây là dành riêng cho main, chúng ta có thể thấy rằng RoboBun hiện là một contributor lớn hơn cho Bun so với tôi. Và đó là với việc không phải tất cả các PR của nó đều được merge. Bạn có thể thấy chúng tôi có rất nhiều PR đang mở hiện nay. Thách thức thực sự là làm thế nào để chúng ta biết liệu có thể merge PR đó hay không? Và đó chính là test.
Tối ưu hóa code review với agent và LLM
Và một điều thú vị khác về việc này là chúng tôi có các bot code review tự động chạy và chúng phản hồi qua lại. Chẳng hạn, Code Rabbit để lại một comment, sau đó RoboBun để lại một comment, và chúng cứ thế phản hồi qua lại. Code Rabbit đã làm điều này... "Còn cách này thì sao?" Và nó cũng đánh dấu các comment là đã được giải quyết khi hoàn thành. Và bạn có thể thấy chúng đã làm rất nhiều. Có rất nhiều phản hồi qua lại ở đây, khoảng 30 comment gì đó. Vậy là bạn đang sử dụng sự kết hợp của nhiều tác nhân. Đây là code review, đây là Claude code review, và cả Code Rabbit nữa. Và bạn đang sử dụng chúng cùng nhau. Vâng, và tôi nghĩ về cơ bản thì Code Rabbit tốt cho các vấn đề về style và những thứ như đảm bảo nó tuân thủ Claude MD. Còn Claude code review thực sự rất tốt. "Đây là một edge case rất tinh vi mà tôi sẽ mất khoảng 30 phút để đọc toàn bộ code và có tất cả context để tìm ra." Vì vậy, nó thực sự giỏi trong việc phát hiện các bug mà bạn cần có đầy đủ context để thực sự hiểu. Và tôi nghĩ về cơ bản là rất khó để có được tất cả sự tự động hóa này mà không có code review trong loop với Claude - việc chúng trả lời hoặc phản hồi mang tính "thực hiện" cao hơn là sửa lỗi. Và đó cũng là một phần lớn của những gì từng tốn rất nhiều thời gian khi các PR mất quá nhiều thời gian để merge, bởi vì bạn sẽ phải check out branch cục bộ, sửa lỗi lint error, sau đó chạy linter cục bộ, rồi đẩy nó lên lại. Và có tất cả chi phí chuyển đổi này liên tục tồn tại. Và vì vậy, tôi nghĩ đây là một use case đặc biệt tốt cho các LLM bởi vì nếu không, nó sẽ tốn rất nhiều thời gian để ship. Và tôi đoán là đặc biệt đối với code base của Bun bởi vì nó là systems code, rất dễ để repro một issue và sau đó xem liệu issue đó đã được sửa hay chưa, bởi vì điều này quay trở lại những gì chúng ta đã nói trước đây về verification loop kiểu này. Nó đều là systems code nên nó thực sự giống như một test case trên một kiến trúc cụ thể và bạn có thể về cơ bản repro hoặc verify bất cứ điều gì.
Khả năng mở rộng cho các sản phẩm thương mại
Vâng, đó là một trong những điều làm cho việc này dễ dàng hơn trong các code base của Bun vì nó là một CLI tool, chúng ta không cần chạy browser để test mọi thứ, nhưng bạn cũng có thể thiết lập để chụp screenshot hoặc quay video hoặc những thứ tương tự. Trong trường hợp của Bun, chúng ta chưa cần điều đó, ít nhất là chưa. Có một vài điều chúng ta có thể làm như vậy, chẳng hạn chúng tôi có một số thứ front end sẽ rất hay. Nhưng vâng, tôi nghĩ đây là hướng đi thực sự thú vị vì nó tiết kiệm rất nhiều thời gian. Và điều này không phải chỉ dành riêng cho Bun, mà là một điều có thể khái quát hóa hơn, bởi vì hầu hết các sản phẩm không phải là mã nguồn mở thì thay vì một issue, điểm khởi đầu có thể là một customer support ticket. Vì vậy, bạn có thể hình dung việc tự động chuyển các customer support ticket cho một Claude bot để sau đó bot đó cố gắng tái hiện issue và gửi một PR, rồi thực hiện code review qua lại. Và đó là lúc tôi nghĩ đối với nhiều công ty, điều này trở nên có tác động lớn hơn rất nhiều vì nó tiết kiệm rất nhiều thời gian phát triển. Bạn có tư duy ra một cái tên nào đó cho pattern này không? Nó giống như adversarial code review hay gì đó?
Điều kiện tiên quyết để agent hoạt động hiệu quả
Vâng, tôi không biết. Nhưng tôi nghĩ rằng cũng có một vài điều khác về việc này, đó là nếu bạn chỉ làm theo cách này thì nó không hoạt động hoàn toàn. Bước đầu tiên bạn cần là đảm bảo môi trường phát triển đã được thiết lập. Tôi nghĩ điều này đã được nói đến trước đây nhưng Claude MD rất quan trọng vì nếu không, nó sẽ chỉ gửi các PR không thực sự hợp lý để bạn merge. Vì vậy, chúng tôi rất nhấn mạnh trong code base của Bun rằng nó chạy lệnh đặc biệt này để thực hiện build. Và quá trình build này chạy lệnh để nó chuyển tiếp các argument bởi vì đó cũng là một điều gây nhầm lẫn là vì Bun phải được compile, bạn muốn đảm bảo rằng nó đang chạy các thay đổi thực tế chứ không phải một debug build đã cũ. Chúng tôi cũng đi sâu vào chi tiết về cách chạy test, cách viết test, nơi đặt test. Và rất nhiều kiểu như "đây là cách làm", "đây là tất cả các issue mà chúng tôi đã gặp phải trước đây". Về cơ bản, pattern ở đây là mỗi khi bạn thấy mình lặp lại một điều gì đó, nó có lẽ nên được đưa vào Claude MD. Bởi vì câu hỏi bây giờ là làm thế nào để bạn làm cho nó maintainable khi có nhiều tác nhân Claude chạy mọi lúc. Và để làm được điều đó, nó cần phải được viết ra, nó cần phải được documented. Vì vậy, một chi tiết rất nhỏ là chúng tôi kiểm tra rằng chúng tôi có nó để đảm bảo rằng Claude nhìn thấy thông báo lỗi, chúng tôi làm cho nó in thông báo lỗi trước các điều kiện ít cung cấp thông tin hơn. Vì vậy, điều này giống như bạn có Claude viết một test và sau đó test đó tệ hoặc có điều gì đó không hoạt động. Và sau đó bạn thấy điều này lặp lại một hoặc hai lần và sau đó bạn chỉ cần nói về việc thêm nó vào Claude MD để mỗi lần trong tương lai khi bạn viết một test, bạn sẽ làm đúng ngay từ đầu. Vâng. Vì vậy, đây giống như một loại compound engineering. Và sau đó, cũng rất hữu ích khi cung cấp cho nó một cái nhìn tổng quan về tất cả các folder, cách code được bố trí, chẳng hạn như về các dependencies.
Vòng lặp CI/CD tự động và khả năng mở rộng agent
Một điều khác mà tôi nghĩ là thú vị là đảm bảo nó có thể đọc các lỗi CI và build log của bạn. Bạn muốn thiết lập tác nhân để nó có thể đọc code, để thực hiện toàn bộ loop của việc viết code, test xem code có hoạt động không, kiểm tra CI, giám sát CI và đọc tất cả các lỗi. Để đến khi nó đến tay một người, mọi thứ đều đã được thiết lập sẵn. Lý tưởng là bạn đọc code và bạn có các dấu hiệu rất rõ ràng cho thấy bạn có thể tự tin cao để merge nó. Và cách duy nhất để điều đó đúng là nếu nó được thiết lập để thành công. Thật thú vị. Tôi nhớ khi chúng ta lần đầu gặp nhau, bạn đã nói về tầm nhìn của mình về việc mọi người có thể chạy hàng trăm tác nhân song song và điều đó sẽ hoạt động như thế nào. Và tôi cảm thấy lúc đó tôi thực sự chưa hiểu, mặc dù bây giờ mỗi đêm tôi đang chạy hàng trăm tác nhân mỗi đêm. Và tôi cảm thấy bây giờ tôi cuối cùng cũng hiểu được, nhưng đây là điều bạn đã tư duy về rất lâu rồi. Vì vậy, có vẻ như đây là một kiểu thiết lập để có thể mở rộng tác nhân lên rất nhiều. Bạn cần tự xác minh để các tác nhân có thể chạy tự động.
Tiến hóa của hệ thống agent và khả năng của mô hình 4.7
Vâng. Giống như điều này đã được thực hiện qua nhiều lần lặp trong code base của Bun. Trước đây, chúng tôi chỉ có một Discord bot mà tôi có thể mention bot đó và nó sẽ khởi động một container. Nó không có các tính năng CI, không có tính năng code review. Và bây giờ nó tốt hơn rất nhiều, đặc biệt là với Opus 4.7. Tất cả những thứ này đang ngày càng tốt hơn. Ồ vâng, chúng ta cũng có thể kiểm tra xem nó đang diễn ra thế nào. Có vẻ như nó đã tạo ra một PR. Cái đầu tiên. Nó đã viết test. Vậy có lẽ trong khi chúng ta xem xét nó, tôi tò mò muốn hỏi những người trong phòng. Khi mọi người tư duy về quá trình phát triển của mình, hãy giơ tay nếu nó trông giống như thế này, nơi bạn có một loạt các cửa sổ terminal hoặc các tab desktop và bạn đang dán các issue vào. Được rồi. Vậy là khoảng một nửa số người. Và sau đó thì sao nếu nó trông giống như RoboBun hoặc một cái gì đó tương tự hơn, nơi nó đóng vòng lặp nhiều hơn một chút. Nó giống như lớp trừu tượng tiếp theo. Sắp xếp lại với nhau. Vâng. Tôi nghĩ nó không đáng ngạc nhiên vì tôi nghĩ khả năng mô hình đang đạt đến mức đó. Tôi nghĩ 4.7 là mô hình đầu tiên mà thực sự cảm thấy nó có thể làm được điều này. Và trước đây, có lẽ bạn có thể làm được với một đống scaffolding. Giống như bạn chỉ cần ném một đống token vào nó và nó có thể hoạt động phần nào. Nhưng bây giờ nó đủ hiệu quả. Bạn thực sự có thể làm điều này hàng ngày.
Đánh giá PR tự động và vai trò của Claude code review
Vâng. Để tôi xem. Vậy là PR đầu tiên đã có đó. Để xem nó có làm thêm cái nào khác không. Được rồi. Đã tạo hai PR. Điều này trông rất khả thi. Hay đấy. Và cái trước sau này có phải là do bạn yêu cầu nó làm không hay là nó tự làm? Đôi khi nó tự làm. Nó khá giỏi trong việc biết khi nào nên làm điều đó. Giống như khi đó là một thứ định dạng chuỗi. Nó cũng giữ một style của label, điều này tốt vì không có style nào khác biệt nhiều. Để tôi xem. Thay đổi này có vẻ tốt không? Vâng. Chủ yếu điều tôi đang tư duy lúc này là nó đã làm điều này. Điều này tốt vì bạn không muốn viết từng byte một. Bạn muốn viết theo khối. Và sau đó nó sử dụng saturation cho nó. Nhưng tôi không thích điều đó. Hoặc là nó không nên phải làm điều đó. Có ai ở đây thực sự biết Zig không? Có. Bạn đang tìm kiếm, tốt đấy. Và bạn có thể thấy nó tuân theo các pattern từ Claude MD await bằng cách sử dụng. Và sau đó pattern giải quyết tất cả các front cùng một lúc. Vậy workflow của bạn là gì? Khi bạn thấy một cái gì đó như thế này, bạn thường vào và comment hay bạn sẽ đợi code review đến và drop một comment? Thông thường nó phụ thuộc vào mức độ phức tạp. Trong trường hợp này, thông thường tôi sẽ đợi vì cái này thực ra khá đơn giản. Tôi cảm thấy khá tự tin cao rằng nếu test pass, thì tôi có lẽ sẽ merge cái này. Nhưng tôi vẫn sẽ đợi code review chạy, ít nhất là Claude code review, đề phòng trường hợp. Bởi vì điều tôi thực sự thích ở nó là nó sẽ tìm thấy những thứ không có trong diff mà xuất phát từ việc truy vết luồng điều khiển, đó là điều bạn muốn khi một người review nó, giống như một người có nhiều context có thể tư duy về tất cả các edge case mà điều này có thể gặp phải.
Hiệu quả Code Review và Tự động hóa
Tỷ lệ tín hiệu trên nhiễu (signal-to-noise ratio) khá tốt; có lẽ khoảng 10% thời gian là sai. Điều này khác hẳn so với các sản phẩm code review khác mà chúng tôi đã thử trước đây, khi về cơ bản bạn phải bỏ qua hầu hết những gì chúng nói. Thật sự rất tuyệt. Một hệ thống như thế này đã hoạt động được bao lâu rồi? Đây có phải là một tính năng của mô hình mới nhất, hay bạn đã có Robobun hoặc loại repo tự động, sửa lỗi tự động, toàn bộ pipeline này trong bao lâu rồi? Chúng ta có thể thấy điều này trong một biểu đồ nào đó. Có khá nhiều commit, nhưng tôi nghĩ đó có thể không phải trên nhánh main, mà là về Rust. Vâng, tôi nghe nói bun sẽ sớm được viết bằng Rust. Tôi không biết nữa. Hoặc có một Claude đang chạy và chúng ta sẽ xem điều gì xảy ra.
Bạn có thể thấy rằng khối lượng commit ban đầu khá thấp, sau đó đã tăng lên rất nhiều và rồi lại tăng rất nhiều nữa. Hiện tại, bottleneck thực sự là liệu tôi có cảm thấy hài lòng khi merge thay đổi này và sự tự tin của tôi rằng các thay đổi đó là chính xác hay không. Và đó là một điều mới mẻ, bởi vì trước đây, code không đủ tốt.
Thách thức về Xác minh và CI
Bạn nghĩ điều gì còn lại? Sẽ cần gì để Robobun có thể giải quyết hoàn toàn một vấn đề khi nó xuất hiện và tự động đưa ra một bản sửa lỗi? Có phải là một tool bị thiếu, một khả năng của mô hình bị thiếu, hoặc một phiên bản mô hình nào đó? Tôi nghĩ nó cần thêm một chút nữa. Mất rất nhiều thời gian để xác minh các thay đổi là chính xác. Điều này đã đúng ngay cả khi một người thực hiện push một PR.
Nhưng tôi nghĩ thách thức là làm thế nào để chúng ta truyền đạt đủ bằng chứng rằng các thay đổi là chính xác, hoặc làm cho việc roll back dễ dàng hơn. Tôi nghĩ đó là hai hướng chính. Tuy nhiên, đối với phần lớn các vấn đề đơn giản, chúng ta nên merge thường xuyên hơn, và bottleneck hiện tại thực sự là CI và đảm bảo rằng code chạy hoàn chỉnh, tất cả các test đều hoạt động. Về cơ bản, nó đã sẵn sàng, và các dự án lớn vẫn không hề đơn giản, nhưng tôi cũng đã thực hiện một số PR khá lớn gần đây với Claude, chủ yếu là với code do Claude tạo ra chứ không phải với Robobun nhiều như vậy.
Nâng cao Khả năng của Claude và Hill Climbing
Chẳng hạn, gần đây chúng tôi đã thêm hỗ trợ cho một thư viện xử lý mới vào bun. Tôi có thể pull up PR đó, và nó được thực hiện bởi Claude, và chúng tôi cũng đã thực hiện một loạt các PR theo sau. Điều thú vị là khi tôi nhìn vào những người khác nhau sử dụng code của Claude, mọi người đều ở một mức độ tinh vi hoặc áp dụng khác nhau. Đối với tôi, điều khó khăn nhất là mô hình thay đổi rất thường xuyên, vì vậy tôi phải liên tục điều chỉnh và hiệu chỉnh lại những gì nó có thể làm. Với tư cách là một kỹ sư, điều đó thật khó vì nó là một công nghệ rất kỳ lạ. Đây là công nghệ đầu tiên tôi sử dụng mà lại như vậy. Và tôi cảm thấy rằng cách bạn làm điều này thực sự vượt xa cách nhóm Claude code làm cho Claude code của chính họ. Đối với tôi, cách nhóm Claude code làm điều đó thực sự rất tự động, nhưng điều này còn tiến xa hơn nữa. Đây gần như là một hệ thống full lift off, một fully closed loop hoàn chỉnh.
Trong hai tuần qua, chúng tôi đã thêm một máy chủ HTTP/3 vào bun. Có một PR cho máy chủ HTTP/2. Có hỗ trợ fetch cho HTTP/3 và HTTP/2. Có API xử lý hình ảnh này. Có bản Rust rewrite đang diễn ra, có thể sẽ không được ship. Đó là bản tôi đã làm cho đến nay kiên nhẫn nhất, và "đã làm" là một từ quá mạnh vì nó còn rất nhiều việc phải làm. Ngay cả một thứ như thế này, đây là một benchmark. Claude đã chạy benchmark cho bạn. Vâng, Claude đã chạy benchmark này. Tôi đã cho nó chạy trên một máy Linux riêng biệt. Và tôi nói: "Hãy làm cho nó nhanh hơn sharp." Đó là những gì tôi đã làm. Tôi đưa ra một vài ý tưởng như: "Ồ, bạn có thể thử đọc code này trong JavaScript Core để tìm ra cách tránh cloning typed array khi không thực sự cần thiết." Nhưng sau đó nó đã tự thực hiện và tìm ra giải pháp. Thành thật mà nói, điều đó khá điên rồ vì tất cả những điều này sẽ không thể thực hiện được vài tháng trước.
Tôi cảm thấy rằng trong Anthropic, trong cộng đồng AI, loại điều này được gọi là hill climbing. Đây là ý tưởng rằng nếu bạn cung cấp cho mô hình một loại số liệu nào đó và sau đó bạn cung cấp cho nó một cách để xác minh kết quả của nó, bạn có thể khiến nó lặp lại và tiếp tục, cho đến khi nó đạt được số liệu đó. Và đây là điều mà Claude 7 tôi nghĩ là đặc biệt giỏi. Tôi nghĩ đó là một điều thực sự bị đánh giá thấp vì tôi nghĩ nó là mô hình đầu tiên thực sự rất giỏi ở điểm đó. Nếu bạn chỉ cho nó một mục tiêu, bạn cho nó một cách để cải thiện hiệu suất và bạn cho nó một cách để đo lường, nó sẽ tiếp tục cho đến khi hoàn thành, nếu bạn để nó ở auto mode.
Bạn cũng có thể thấy rằng đây là một trường hợp khác mà các nhận xét code review thực sự rất hữu ích, bởi vì trong PR này có khoảng một trăm nhận xét hoặc gì đó, và nó cứ đi và sửa mọi thứ. Nó cứ tiếp tục trong một thời gian, và trong lúc đó, bạn chỉ làm việc khác. Đây không phải là điều tôi tập trung 100%. Tôi có thể chỉ tập trung 10% vào việc này; tôi đang làm năm việc cùng một lúc. Điều này chắc chắn không thể thực hiện được sáu tháng trước, ba tháng trước; điều này là rất gần đây mới thực hiện được.
Trải nghiệm CLI và Chế độ No Flicker
Được rồi. Các session đang hoạt động như thế nào? Vâng, chúng tôi có một PR ở đó, và có vẻ như sắp có một PR khác. PR này có lẽ sẽ là cái khó nhất. Mặc dù vậy, nó trông khá tốt. Dựa trên những thay đổi này, nó có vẻ hợp lý. Tôi sẽ không làm theo cách này, nhưng tôi nghĩ chúng ta cần một cách tốt hơn hoặc tối ưu hóa hơn để làm điều này vì có rất nhiều kiểm tra.
Và nhìn vào thiết lập của bạn ở đây, bạn chủ yếu sử dụng CLI. Vâng. Và bạn luôn sử dụng auto mode cho quyền hạn chứ? Vâng. Và trước đó tôi đã sử dụng dangerously skip permissions. Không, các bạn có thể xóa mọi thứ nếu làm vậy. Tôi không biết nữa. Tôi nghĩ tôi không nên khuyến nghị điều đó. Nhưng tôi nghĩ chờ Claude duyệt rất mất thời gian vì bạn chỉ cần đi làm việc khác và nó cứ ngồi đó. Đó là lý do tại sao auto mode thực sự tốt vì đó là một cách thực sự để khắc phục điều đó thay vì chỉ tin tưởng.
Tôi cũng nhận thấy input, trình soạn thảo nhỏ, được đặt ở cuối màn hình, vì vậy bạn đang sử dụng no flicker mode. Vâng, tôi đang sử dụng no flicker. Thành thật mà nói, tôi nghĩ chúng ta nên đặt nó làm mặc định vì nó tốt hơn rất nhiều. Bạn có thể thấy tôi có thể cuộn rất nhanh. Và bạn có thể cuộn nhanh trước đây, nhưng đôi khi có hiện tượng nhấp nháy, và bây giờ thì không. Mọi người đã thử no flicker mode cho CLI chưa? Vâng, một vài người. Vâng. Chúng tôi đã ra mắt nó vào ngày Cá tháng Tư, vì vậy nhìn lại thì nó giống như một trò đùa một chút. Nếu bạn thực sự đặt biến môi trường Claude Code no flicker equals one Claude, chúng tôi đã viết lại hoàn toàn renderer đang chạy trong CLI. Vì vậy, nó đang sử dụng virtualized scrolling, virtualized selection. Và điều này có nghĩa là mức sử dụng bộ nhớ và CPU liên tục. Và cũng có một số điều hay ho khác như nếu bạn là người type, bạn thực sự có thể nhấp xung quanh trình soạn thảo, và các sự kiện chuột hoạt động, điều này khá điên rồ đối với terminal.
Tôi cũng đang để nó theo dõi PR. Bạn có thể thấy nó ở đây và một số lệnh, sau đó nó sẽ đi ngủ trong 20 phút và thức dậy trở lại. 20 phút có lẽ hơi lâu một chút nhưng không sao. Và đó có phải là việc sử dụng một loop hoặc thứ gì đó không? Tôi nghĩ vậy. Vâng. Và sau đó, hãy xem nó đang làm gì khác. Và những cái khác vẫn đang được sửa lỗi bổ sung. Được rồi. Vậy là khoảng 20 hoặc 25 phút đã trôi qua và chúng ta đã có ba PR. Không, không tệ. Vâng. Và tôi nghĩ chúng ta sẽ có cái thứ tư khi nó hoàn tất việc chạy này. Và trong thời gian chờ đợi, Robobun vẫn đang chạy và tiếp tục tạo ra nhiều PR hơn nữa. Mỗi khi ai đó gửi một vấn đề, nó sẽ cố gắng tái tạo nó.
Bottleneck Luôn Thay Đổi và Tương lai của Robobun
Vâng. Tôi cảm thấy rằng cách Claude code khiến bạn tư duy là mỗi khi có một bottleneck mới, bạn phải tự động hóa bottleneck đó, và sau đó luôn có một bottleneck khác và bạn sẽ chuyển sang giải quyết nó. Giống như việc viết code từng là bottleneck và giờ thì không còn nữa. Sau đó, việc xác minh và chạy test từng là bottleneck và giờ cũng không còn nữa. Và bây giờ có một lớp xác minh sâu hơn. Có lẽ là vậy.
Bạn nghĩ những bottleneck nào còn lại? Chắc chắn đó là lớp xác minh sâu hơn này. Tôi cảm thấy bottleneck tiếp theo sẽ là lập kế hoạch: chúng ta nên làm gì và không nên làm gì, và cách đúng đắn để sửa lỗi này là gì. Lý tưởng nhất là Claude đủ thông minh hoặc chúng ta có thể đủ tin tưởng Claude để nó tự merge các PR. Tôi nghĩ rằng trong một số dự án nhất định, bạn có thể làm điều đó và để nó tự động hoàn toàn. Tôi nghĩ bun chưa đạt đến mức đó đối với Claude hay đúng hơn là cho bun. Nhưng tôi nghĩ sẽ rất tuyệt nếu chúng ta có các tooling để cảm thấy đủ tự tin để làm điều đó.
Hiện tại Robobun không xây dựng tính năng. Nó chưa thực hiện các feature request. Đúng vậy. Vâng, nó không thực hiện các feature request nhưng đôi khi chúng tôi cũng sử dụng nó. Vì vậy, chúng tôi cũng có thể mention nó trong Discord hoặc Slack và nó sẽ cố gắng triển khai tính năng đó. Đôi khi khi mọi người nói: "Này, bun đang thiếu cái này," và tôi chỉ mention con bot và có lẽ một giờ sau sẽ có một PR. Rất nhiều lần ai đó đã tweet cho tôi một cái gì đó như: "Bạn có thể sửa lỗi này không?" hoặc đại loại vậy, và đó là những gì tôi làm, sau đó tôi trả lời bằng một liên kết đến PR. Chúng ta có nên thêm một tài khoản Robobun trên Twitter không?
Tôi nghĩ rằng nó có thể thực hiện các feature request, nhưng tôi ngần ngại cho phép nó triển khai mọi thứ mà bất kỳ ai yêu cầu trong một vấn đề GitHub vì đó là một khối lượng lớn. Bởi vì theo một cách nào đó, việc đưa một thứ như thư viện xử lý hình ảnh vào bun là khá điên rồ. Nhưng chúng ta đã nói về engineering taste (gu kỹ thuật), và có một yếu tố của gu cá nhân ở đó. Giống như bạn cảm thấy đó là một ý tưởng hay. Và chúng tôi vẫn chưa chắc liệu Claude đã đạt đến điểm mà nó cũng sẽ nghĩ đây là một ý tưởng hay hay không. Nhưng bạn biết đấy, một lúc nào đó trong tương lai nó sẽ đạt được.
Tôi nghĩ rằng các PR trở thành các đề xuất. Việc không merge các PR trước đây giống như bạn cảm thấy tồi tệ nếu bạn không merge PR của một đồng nghiệp vì họ đã bỏ công sức vào đó. Nhưng bạn không cần phải cảm thấy tồi tệ khi đó là Claude. Vì vậy, nếu PR sai hoặc vì bất kỳ lý do gì, bạn có thể không merge nó. Nhưng điều đó có nghĩa là tiêu chuẩn cho những gì bạn merge là: nó có nên ở đó không? Bởi vì tôi nghĩ cũng có sự khác biệt khi đó là con người, vì với con người bạn không muốn họ cảm thấy tồi tệ về công việc bị mất của họ. Vì vậy, theo một cách nào đó, điều đó thực sự làm tăng tiêu chuẩn cho những gì bạn quyết định merge.
Thật thú vị. Khi các bottleneck thay đổi, động lực cũng thay đổi một chút. Nó giống như việc phải tin tưởng lẫn nhau, phải tin tưởng những người trong nhóm. Điều này thay đổi một chút. Bây giờ, nó thiên về việc chúng ta có sự tự động hóa phù hợp không và chúng ta có tin tưởng sự tự động hóa không, như một nhóm. Vâng. Vậy tôi nghĩ chúng ta sắp kết thúc rồi.
Tiến độ Xử lý PR Cuối cùng
Có lẽ có một điều cuối cùng nào đó chúng ta muốn cho mọi người thấy để kiểm tra tiến độ đã đạt được không? Tôi không nghĩ vậy. Vâng, nó vẫn đang tiếp tục với cái PR thứ tư. Nó đang qua lại, ví dụ như tìm thấy một lỗi và sau đó sửa lỗi đó. Có vẻ như nó sắp gửi PR rồi.
Hiệu quả của Chế độ Tự động (Auto Mode)
Được rồi, hãy đợi cái này. Nó sắp có thêm một cái nữa. Đây là điểm thú vị của chế độ tự động (auto mode). Ở chế độ tự động, tôi có thể chạy các quads hàng giờ liền. Tôi chạy nó hầu như mỗi đêm. Tôi sẽ có một loạt các quads chạy ở chế độ tự động. Trước đây, nó không hoạt động vì luôn bị kẹt ở một loại yêu cầu cấp quyền nào đó. Và rồi, nghe có vẻ điên rồ, toàn bộ quá trình này chỉ là một prompt, và nó đã chạy trong 30 phút. Vâng, đây là tất cả những gì tôi đã nói. Được rồi, nó đang đẩy lên. Nó sắp gửi PR. Nghe có vẻ đây là giải pháp đúng cho một vấn đề đã tồn đọng từ lâu. Và chúng ta đã có một PR. Vâng, chúng ta có thể vào vấn đề này và xem nó có bao nhiêu đầu ra. 20. Vâng, khá nhiều.
Tầm nhìn về Tương lai Ngành Kỹ thuật
Tuyệt vời. Có lẽ chúng ta có thể tạm dừng ở đây. Nhưng đối với tôi, đây là một tầm nhìn thật sự thú vị về nơi mà ngành kỹ thuật đang hướng tới. Tôi nghĩ là cho tất cả mọi người trong căn phòng này. Và chúng ta sẽ thấy điều này trước tiên. Chúng ta sẽ phải tìm hiểu nó trước, và sau đó mọi người khác sẽ phải tìm hiểu điều này. Vì vậy, như chúng ta đã nói sáng nay, chúng tôi rất hào hứng được cùng nhau trên hành trình này. Và như bạn có thể thấy, chúng ta chưa tìm ra mọi thứ. Nhưng tôi nghĩ chế độ chúng ta đang ở là liên tục thử nghiệm, liên tục cố gắng xem bottleneck tiếp theo là gì để chúng ta có thể giải quyết nó. Điều này rất thú vị vì nó rất tuyệt. Tôi thích những thứ này. Tuyệt vời. Tôi có nên, vâng, chúng ta có thể để nó như vậy.
TL;DR
- Anthropic đang sử dụng các
agentAI nhưRoboBunvàClaude code reviewđể tự động hóa đáng kể quy trình phát triểnBun, từ việc tái hiệnissuevà tạoPRđến việcreviewmã. - Hệ thống này giúp tiết kiệm lượng lớn
thời gian phát triểnbằng cách giải quyết các tác vụ lặp đi lặp lại và phát hiện cácbugtinh vi, cho phép kỹ sư tập trung vào các vấn đề phức tạp hơn. - Hiệu quả của các
agentđược nâng cao nhờClaude MD(tài liệu hướng dẫn cụ thể), vòng lặpCI/CDchặt chẽ, và chiến lược "hill climbing" nơiagenttự xác minh và lặp lại để đạt được mục tiêu, đặc biệt với cácLLMmạnh mẽ nhưClaude 4.7/Opus.
Điểm chính
- Tự động tái hiện lỗi & tạo PR:
RoboBuntự động tái hiệnissuevà tạoPRkèmtest, đảm bảo cáctestnày thất bại trên phiên bản cũ và pass trên phiên bản mới để xác minh bản sửa lỗi. - Tối ưu hóa Code Review đa tác nhân: Sử dụng kết hợp
agent(ví dụ:Code Rabbitchostyle,Claude code reviewcho logic sâu vàedge case) giúp phát hiệnbugcần nhiềucontextvà giải quyết các vấn đề nhỏ, giảmchi phí chuyển đổithủ công. - Tài liệu hóa (
Claude MD) là chìa khóa: Cung cấp tài liệu chi tiết về cáchbuild, chạytest, viếttest, cấu trúccodevà xử lý cácissuephổ biến choagentlà điều kiện tiên quyết để chúng hoạt động hiệu quả. - Vòng lặp CI/CD tự động:
Agentcần có khả năng đọclỗi CIvàbuild log, thực hiện toàn bộ vòng lặp từ viết mã, kiểm thử,giám sát CIđến sửa lỗi để mọi thứ sẵn sàngmergekhi đến tay con người. - Chiến lược "Hill Climbing": Để
agenthoạt động tự động hiệu quả, hãy cung cấp cho chúng một mục tiêu (metric), cách để cải thiện (improve performance), và cách để đo lường (measure), cho phép chúng lặp lại liên tục cho đến khi hoàn thành. - Tăng cường khả năng của LLM: Các mô hình
LLMtiên tiến (nhưClaude 4.7/Opus) đã đạt đến mức có thể thực hiện các quy trình tự động hóa phức tạp này một cáchhiệu quảhàng ngày, thay vì chỉ vớiscaffoldinglớn. - Khả năng mở rộng cho sản phẩm thương mại: Mô hình này không chỉ giới hạn ở
mã nguồn mởmà có thể áp dụng cho các sản phẩm thương mại, ví dụ, tự động xử lýcustomer support ticketbằng cách chobottái hiệnissuevà tạoPR.
Từ vựng
agent— tác nhânClaude Code— Claude Code (tên sản phẩm/tính năng)Bun— Bun (tên sản phẩm)PR— Pull Request (Yêu cầu hợp nhất mã)issue— vấn đề (lỗi, yêu cầu tính năng)repo— kho chứa (repository)bot— bot (rô-bốt tự động)test— kiểm thửmerge— hợp nhấtdebug— gỡ lỗicode review— đánh giá mãLLM— Large Language Model (Mô hình ngôn ngữ lớn)context— ngữ cảnhlinter— công cụ kiểm tra cú pháp/phong cách mãCLI tool— công cụ dòng lệnhcustomer support ticket— phiếu hỗ trợ khách hàngbuild— xây dựng (dự án, mã nguồn)CI/CD— Continuous Integration/Continuous Deployment (Tích hợp liên tục/Triển khai liên tục)Claude MD— Claude MD (tài liệu/hướng dẫn cụ thể cho Claude)hill climbing— leo đồi (thuật toán tối ưu hóa)scaffolding— khung sườn (cấu trúc hỗ trợ)benchmark— điểm chuẩnedge case— trường hợp ngoại lệ/biênbottleneck— nút thắt cổ chai
Nội dung chi tiết
Giới thiệu và thiết lập agent
Chào mừng lên sân khấu, Boris Cherny, Trưởng phòng Claude Code tại Anthropic, và Jared Sumner, người sáng tạo Bun tại Anthropic. Được rồi, đây là một hội nghị dành cho nhà phát triển. Chúng ta sẽ nói chuyện một chút, nhưng chủ yếu tôi sẽ tập trung vào coding. Vì vậy, phần này dành cho các nhà phát triển có mặt tại đây. Tôi sẽ bắt đầu bằng cách nói một chút về cách Bun sử dụng Claude Code để xây dựng và duy trì Bun, cũng như cách thiết lập của chúng tôi hoạt động. Bởi vì đây là một thiết lập hơi nâng cao hơn so với những gì phổ biến hiện nay. Nhưng trước tiên, tôi sẽ cho một vài tác nhân chạy để khắc phục và giải quyết các vấn đề. Đây là một cảnh kinh điển của Jared khi làm việc trong lúc đang thuyết trình.
Tự động tái hiện lỗi và tạo PR với RoboBun
Trong repo của Bun, mỗi khi ai đó gửi một issue, chúng tôi có một block của Claude tự động chạy và cố gắng tái hiện issue đó. Bạn có thể thấy người này có side effect này, và đây là một trong những issue gần đây nhất. Và chúng ta có thể thấy rằng RoboBun, bot của chúng tôi, đã quản lý để tái hiện issue và tự động gửi một PR. Tất cả các PR này luôn có test. Đây là một trong những yêu cầu bắt buộc trước khi bạn có thể gửi một PR. Vậy thách thức ở đây là, liệu code này có vẻ đúng không? Và một trong những điều chúng tôi làm để kiểm tra là, liệu test có thất bại ở phiên bản Bun trước đó trong debug branch này không? Và bot thực sự không thể gửi PR nếu không thỏa mãn điều kiện đó. Điều này có nghĩa là, với mọi issue xuất hiện trong issue tracker của Bun, bạn đều có RoboBun tự động cố gắng tái hiện nó trước khi bất kỳ ai chấp nhận. Điều này tiết kiệm rất nhiều thời gian vì chúng tôi có rất nhiều issue get-out đang mở. Nó thực sự chuyển thách thức từ việc chỉ sửa lỗi và debug issue sang việc, đây có phải là thứ đúng để merge không? Liệu đây có phải là bản sửa lỗi đúng không? Nó tốt đến mức nào? Nó vẫn còn 100% của bạn hay chỉ 10%? Chúng ta có thể vào phần insights và contributors. Và nếu chúng ta xem trong ba tháng gần nhất, và đây là dành riêng cho main, chúng ta có thể thấy rằng RoboBun hiện là một contributor lớn hơn cho Bun so với tôi. Và đó là với việc không phải tất cả các PR của nó đều được merge. Bạn có thể thấy chúng tôi có rất nhiều PR đang mở hiện nay. Thách thức thực sự là làm thế nào để chúng ta biết liệu có thể merge PR đó hay không? Và đó chính là test.
Tối ưu hóa code review với agent và LLM
Và một điều thú vị khác về việc này là chúng tôi có các bot code review tự động chạy và chúng phản hồi qua lại. Chẳng hạn, Code Rabbit để lại một comment, sau đó RoboBun để lại một comment, và chúng cứ thế phản hồi qua lại. Code Rabbit đã làm điều này... "Còn cách này thì sao?" Và nó cũng đánh dấu các comment là đã được giải quyết khi hoàn thành. Và bạn có thể thấy chúng đã làm rất nhiều. Có rất nhiều phản hồi qua lại ở đây, khoảng 30 comment gì đó. Vậy là bạn đang sử dụng sự kết hợp của nhiều tác nhân. Đây là code review, đây là Claude code review, và cả Code Rabbit nữa. Và bạn đang sử dụng chúng cùng nhau. Vâng, và tôi nghĩ về cơ bản thì Code Rabbit tốt cho các vấn đề về style và những thứ như đảm bảo nó tuân thủ Claude MD. Còn Claude code review thực sự rất tốt. "Đây là một edge case rất tinh vi mà tôi sẽ mất khoảng 30 phút để đọc toàn bộ code và có tất cả context để tìm ra." Vì vậy, nó thực sự giỏi trong việc phát hiện các bug mà bạn cần có đầy đủ context để thực sự hiểu. Và tôi nghĩ về cơ bản là rất khó để có được tất cả sự tự động hóa này mà không có code review trong loop với Claude - việc chúng trả lời hoặc phản hồi mang tính "thực hiện" cao hơn là sửa lỗi. Và đó cũng là một phần lớn của những gì từng tốn rất nhiều thời gian khi các PR mất quá nhiều thời gian để merge, bởi vì bạn sẽ phải check out branch cục bộ, sửa lỗi lint error, sau đó chạy linter cục bộ, rồi đẩy nó lên lại. Và có tất cả chi phí chuyển đổi này liên tục tồn tại. Và vì vậy, tôi nghĩ đây là một use case đặc biệt tốt cho các LLM bởi vì nếu không, nó sẽ tốn rất nhiều thời gian để ship. Và tôi đoán là đặc biệt đối với code base của Bun bởi vì nó là systems code, rất dễ để repro một issue và sau đó xem liệu issue đó đã được sửa hay chưa, bởi vì điều này quay trở lại những gì chúng ta đã nói trước đây về verification loop kiểu này. Nó đều là systems code nên nó thực sự giống như một test case trên một kiến trúc cụ thể và bạn có thể về cơ bản repro hoặc verify bất cứ điều gì.
Khả năng mở rộng cho các sản phẩm thương mại
Vâng, đó là một trong những điều làm cho việc này dễ dàng hơn trong các code base của Bun vì nó là một CLI tool, chúng ta không cần chạy browser để test mọi thứ, nhưng bạn cũng có thể thiết lập để chụp screenshot hoặc quay video hoặc những thứ tương tự. Trong trường hợp của Bun, chúng ta chưa cần điều đó, ít nhất là chưa. Có một vài điều chúng ta có thể làm như vậy, chẳng hạn chúng tôi có một số thứ front end sẽ rất hay. Nhưng vâng, tôi nghĩ đây là hướng đi thực sự thú vị vì nó tiết kiệm rất nhiều thời gian. Và điều này không phải chỉ dành riêng cho Bun, mà là một điều có thể khái quát hóa hơn, bởi vì hầu hết các sản phẩm không phải là mã nguồn mở thì thay vì một issue, điểm khởi đầu có thể là một customer support ticket. Vì vậy, bạn có thể hình dung việc tự động chuyển các customer support ticket cho một Claude bot để sau đó bot đó cố gắng tái hiện issue và gửi một PR, rồi thực hiện code review qua lại. Và đó là lúc tôi nghĩ đối với nhiều công ty, điều này trở nên có tác động lớn hơn rất nhiều vì nó tiết kiệm rất nhiều thời gian phát triển. Bạn có tư duy ra một cái tên nào đó cho pattern này không? Nó giống như adversarial code review hay gì đó?
Điều kiện tiên quyết để agent hoạt động hiệu quả
Vâng, tôi không biết. Nhưng tôi nghĩ rằng cũng có một vài điều khác về việc này, đó là nếu bạn chỉ làm theo cách này thì nó không hoạt động hoàn toàn. Bước đầu tiên bạn cần là đảm bảo môi trường phát triển đã được thiết lập. Tôi nghĩ điều này đã được nói đến trước đây nhưng Claude MD rất quan trọng vì nếu không, nó sẽ chỉ gửi các PR không thực sự hợp lý để bạn merge. Vì vậy, chúng tôi rất nhấn mạnh trong code base của Bun rằng nó chạy lệnh đặc biệt này để thực hiện build. Và quá trình build này chạy lệnh để nó chuyển tiếp các argument bởi vì đó cũng là một điều gây nhầm lẫn là vì Bun phải được compile, bạn muốn đảm bảo rằng nó đang chạy các thay đổi thực tế chứ không phải một debug build đã cũ. Chúng tôi cũng đi sâu vào chi tiết về cách chạy test, cách viết test, nơi đặt test. Và rất nhiều kiểu như "đây là cách làm", "đây là tất cả các issue mà chúng tôi đã gặp phải trước đây". Về cơ bản, pattern ở đây là mỗi khi bạn thấy mình lặp lại một điều gì đó, nó có lẽ nên được đưa vào Claude MD. Bởi vì câu hỏi bây giờ là làm thế nào để bạn làm cho nó maintainable khi có nhiều tác nhân Claude chạy mọi lúc. Và để làm được điều đó, nó cần phải được viết ra, nó cần phải được documented. Vì vậy, một chi tiết rất nhỏ là chúng tôi kiểm tra rằng chúng tôi có nó để đảm bảo rằng Claude nhìn thấy thông báo lỗi, chúng tôi làm cho nó in thông báo lỗi trước các điều kiện ít cung cấp thông tin hơn. Vì vậy, điều này giống như bạn có Claude viết một test và sau đó test đó tệ hoặc có điều gì đó không hoạt động. Và sau đó bạn thấy điều này lặp lại một hoặc hai lần và sau đó bạn chỉ cần nói về việc thêm nó vào Claude MD để mỗi lần trong tương lai khi bạn viết một test, bạn sẽ làm đúng ngay từ đầu. Vâng. Vì vậy, đây giống như một loại compound engineering. Và sau đó, cũng rất hữu ích khi cung cấp cho nó một cái nhìn tổng quan về tất cả các folder, cách code được bố trí, chẳng hạn như về các dependencies.
Vòng lặp CI/CD tự động và khả năng mở rộng agent
Một điều khác mà tôi nghĩ là thú vị là đảm bảo nó có thể đọc các lỗi CI và build log của bạn. Bạn muốn thiết lập tác nhân để nó có thể đọc code, để thực hiện toàn bộ loop của việc viết code, test xem code có hoạt động không, kiểm tra CI, giám sát CI và đọc tất cả các lỗi. Để đến khi nó đến tay một người, mọi thứ đều đã được thiết lập sẵn. Lý tưởng là bạn đọc code và bạn có các dấu hiệu rất rõ ràng cho thấy bạn có thể tự tin cao để merge nó. Và cách duy nhất để điều đó đúng là nếu nó được thiết lập để thành công. Thật thú vị. Tôi nhớ khi chúng ta lần đầu gặp nhau, bạn đã nói về tầm nhìn của mình về việc mọi người có thể chạy hàng trăm tác nhân song song và điều đó sẽ hoạt động như thế nào. Và tôi cảm thấy lúc đó tôi thực sự chưa hiểu, mặc dù bây giờ mỗi đêm tôi đang chạy hàng trăm tác nhân mỗi đêm. Và tôi cảm thấy bây giờ tôi cuối cùng cũng hiểu được, nhưng đây là điều bạn đã tư duy về rất lâu rồi. Vì vậy, có vẻ như đây là một kiểu thiết lập để có thể mở rộng tác nhân lên rất nhiều. Bạn cần tự xác minh để các tác nhân có thể chạy tự động.
Tiến hóa của hệ thống agent và khả năng của mô hình 4.7
Vâng. Giống như điều này đã được thực hiện qua nhiều lần lặp trong code base của Bun. Trước đây, chúng tôi chỉ có một Discord bot mà tôi có thể mention bot đó và nó sẽ khởi động một container. Nó không có các tính năng CI, không có tính năng code review. Và bây giờ nó tốt hơn rất nhiều, đặc biệt là với Opus 4.7. Tất cả những thứ này đang ngày càng tốt hơn. Ồ vâng, chúng ta cũng có thể kiểm tra xem nó đang diễn ra thế nào. Có vẻ như nó đã tạo ra một PR. Cái đầu tiên. Nó đã viết test. Vậy có lẽ trong khi chúng ta xem xét nó, tôi tò mò muốn hỏi những người trong phòng. Khi mọi người tư duy về quá trình phát triển của mình, hãy giơ tay nếu nó trông giống như thế này, nơi bạn có một loạt các cửa sổ terminal hoặc các tab desktop và bạn đang dán các issue vào. Được rồi. Vậy là khoảng một nửa số người. Và sau đó thì sao nếu nó trông giống như RoboBun hoặc một cái gì đó tương tự hơn, nơi nó đóng vòng lặp nhiều hơn một chút. Nó giống như lớp trừu tượng tiếp theo. Sắp xếp lại với nhau. Vâng. Tôi nghĩ nó không đáng ngạc nhiên vì tôi nghĩ khả năng mô hình đang đạt đến mức đó. Tôi nghĩ 4.7 là mô hình đầu tiên mà thực sự cảm thấy nó có thể làm được điều này. Và trước đây, có lẽ bạn có thể làm được với một đống scaffolding. Giống như bạn chỉ cần ném một đống token vào nó và nó có thể hoạt động phần nào. Nhưng bây giờ nó đủ hiệu quả. Bạn thực sự có thể làm điều này hàng ngày.
Đánh giá PR tự động và vai trò của Claude code review
Vâng. Để tôi xem. Vậy là PR đầu tiên đã có đó. Để xem nó có làm thêm cái nào khác không. Được rồi. Đã tạo hai PR. Điều này trông rất khả thi. Hay đấy. Và cái trước sau này có phải là do bạn yêu cầu nó làm không hay là nó tự làm? Đôi khi nó tự làm. Nó khá giỏi trong việc biết khi nào nên làm điều đó. Giống như khi đó là một thứ định dạng chuỗi. Nó cũng giữ một style của label, điều này tốt vì không có style nào khác biệt nhiều. Để tôi xem. Thay đổi này có vẻ tốt không? Vâng. Chủ yếu điều tôi đang tư duy lúc này là nó đã làm điều này. Điều này tốt vì bạn không muốn viết từng byte một. Bạn muốn viết theo khối. Và sau đó nó sử dụng saturation cho nó. Nhưng tôi không thích điều đó. Hoặc là nó không nên phải làm điều đó. Có ai ở đây thực sự biết Zig không? Có. Bạn đang tìm kiếm, tốt đấy. Và bạn có thể thấy nó tuân theo các pattern từ Claude MD await bằng cách sử dụng. Và sau đó pattern giải quyết tất cả các front cùng một lúc. Vậy workflow của bạn là gì? Khi bạn thấy một cái gì đó như thế này, bạn thường vào và comment hay bạn sẽ đợi code review đến và drop một comment? Thông thường nó phụ thuộc vào mức độ phức tạp. Trong trường hợp này, thông thường tôi sẽ đợi vì cái này thực ra khá đơn giản. Tôi cảm thấy khá tự tin cao rằng nếu test pass, thì tôi có lẽ sẽ merge cái này. Nhưng tôi vẫn sẽ đợi code review chạy, ít nhất là Claude code review, đề phòng trường hợp. Bởi vì điều tôi thực sự thích ở nó là nó sẽ tìm thấy những thứ không có trong diff mà xuất phát từ việc truy vết luồng điều khiển, đó là điều bạn muốn khi một người review nó, giống như một người có nhiều context có thể tư duy về tất cả các edge case mà điều này có thể gặp phải.
Hiệu quả Code Review và Tự động hóa
Tỷ lệ tín hiệu trên nhiễu (signal-to-noise ratio) khá tốt; có lẽ khoảng 10% thời gian là sai. Điều này khác hẳn so với các sản phẩm code review khác mà chúng tôi đã thử trước đây, khi về cơ bản bạn phải bỏ qua hầu hết những gì chúng nói. Thật sự rất tuyệt. Một hệ thống như thế này đã hoạt động được bao lâu rồi? Đây có phải là một tính năng của mô hình mới nhất, hay bạn đã có Robobun hoặc loại repo tự động, sửa lỗi tự động, toàn bộ pipeline này trong bao lâu rồi? Chúng ta có thể thấy điều này trong một biểu đồ nào đó. Có khá nhiều commit, nhưng tôi nghĩ đó có thể không phải trên nhánh main, mà là về Rust. Vâng, tôi nghe nói bun sẽ sớm được viết bằng Rust. Tôi không biết nữa. Hoặc có một Claude đang chạy và chúng ta sẽ xem điều gì xảy ra.
Bạn có thể thấy rằng khối lượng commit ban đầu khá thấp, sau đó đã tăng lên rất nhiều và rồi lại tăng rất nhiều nữa. Hiện tại, bottleneck thực sự là liệu tôi có cảm thấy hài lòng khi merge thay đổi này và sự tự tin của tôi rằng các thay đổi đó là chính xác hay không. Và đó là một điều mới mẻ, bởi vì trước đây, code không đủ tốt.
Thách thức về Xác minh và CI
Bạn nghĩ điều gì còn lại? Sẽ cần gì để Robobun có thể giải quyết hoàn toàn một vấn đề khi nó xuất hiện và tự động đưa ra một bản sửa lỗi? Có phải là một tool bị thiếu, một khả năng của mô hình bị thiếu, hoặc một phiên bản mô hình nào đó? Tôi nghĩ nó cần thêm một chút nữa. Mất rất nhiều thời gian để xác minh các thay đổi là chính xác. Điều này đã đúng ngay cả khi một người thực hiện push một PR.
Nhưng tôi nghĩ thách thức là làm thế nào để chúng ta truyền đạt đủ bằng chứng rằng các thay đổi là chính xác, hoặc làm cho việc roll back dễ dàng hơn. Tôi nghĩ đó là hai hướng chính. Tuy nhiên, đối với phần lớn các vấn đề đơn giản, chúng ta nên merge thường xuyên hơn, và bottleneck hiện tại thực sự là CI và đảm bảo rằng code chạy hoàn chỉnh, tất cả các test đều hoạt động. Về cơ bản, nó đã sẵn sàng, và các dự án lớn vẫn không hề đơn giản, nhưng tôi cũng đã thực hiện một số PR khá lớn gần đây với Claude, chủ yếu là với code do Claude tạo ra chứ không phải với Robobun nhiều như vậy.
Nâng cao Khả năng của Claude và Hill Climbing
Chẳng hạn, gần đây chúng tôi đã thêm hỗ trợ cho một thư viện xử lý mới vào bun. Tôi có thể pull up PR đó, và nó được thực hiện bởi Claude, và chúng tôi cũng đã thực hiện một loạt các PR theo sau. Điều thú vị là khi tôi nhìn vào những người khác nhau sử dụng code của Claude, mọi người đều ở một mức độ tinh vi hoặc áp dụng khác nhau. Đối với tôi, điều khó khăn nhất là mô hình thay đổi rất thường xuyên, vì vậy tôi phải liên tục điều chỉnh và hiệu chỉnh lại những gì nó có thể làm. Với tư cách là một kỹ sư, điều đó thật khó vì nó là một công nghệ rất kỳ lạ. Đây là công nghệ đầu tiên tôi sử dụng mà lại như vậy. Và tôi cảm thấy rằng cách bạn làm điều này thực sự vượt xa cách nhóm Claude code làm cho Claude code của chính họ. Đối với tôi, cách nhóm Claude code làm điều đó thực sự rất tự động, nhưng điều này còn tiến xa hơn nữa. Đây gần như là một hệ thống full lift off, một fully closed loop hoàn chỉnh.
Trong hai tuần qua, chúng tôi đã thêm một máy chủ HTTP/3 vào bun. Có một PR cho máy chủ HTTP/2. Có hỗ trợ fetch cho HTTP/3 và HTTP/2. Có API xử lý hình ảnh này. Có bản Rust rewrite đang diễn ra, có thể sẽ không được ship. Đó là bản tôi đã làm cho đến nay kiên nhẫn nhất, và "đã làm" là một từ quá mạnh vì nó còn rất nhiều việc phải làm. Ngay cả một thứ như thế này, đây là một benchmark. Claude đã chạy benchmark cho bạn. Vâng, Claude đã chạy benchmark này. Tôi đã cho nó chạy trên một máy Linux riêng biệt. Và tôi nói: "Hãy làm cho nó nhanh hơn sharp." Đó là những gì tôi đã làm. Tôi đưa ra một vài ý tưởng như: "Ồ, bạn có thể thử đọc code này trong JavaScript Core để tìm ra cách tránh cloning typed array khi không thực sự cần thiết." Nhưng sau đó nó đã tự thực hiện và tìm ra giải pháp. Thành thật mà nói, điều đó khá điên rồ vì tất cả những điều này sẽ không thể thực hiện được vài tháng trước.
Tôi cảm thấy rằng trong Anthropic, trong cộng đồng AI, loại điều này được gọi là hill climbing. Đây là ý tưởng rằng nếu bạn cung cấp cho mô hình một loại số liệu nào đó và sau đó bạn cung cấp cho nó một cách để xác minh kết quả của nó, bạn có thể khiến nó lặp lại và tiếp tục, cho đến khi nó đạt được số liệu đó. Và đây là điều mà Claude 7 tôi nghĩ là đặc biệt giỏi. Tôi nghĩ đó là một điều thực sự bị đánh giá thấp vì tôi nghĩ nó là mô hình đầu tiên thực sự rất giỏi ở điểm đó. Nếu bạn chỉ cho nó một mục tiêu, bạn cho nó một cách để cải thiện hiệu suất và bạn cho nó một cách để đo lường, nó sẽ tiếp tục cho đến khi hoàn thành, nếu bạn để nó ở auto mode.
Bạn cũng có thể thấy rằng đây là một trường hợp khác mà các nhận xét code review thực sự rất hữu ích, bởi vì trong PR này có khoảng một trăm nhận xét hoặc gì đó, và nó cứ đi và sửa mọi thứ. Nó cứ tiếp tục trong một thời gian, và trong lúc đó, bạn chỉ làm việc khác. Đây không phải là điều tôi tập trung 100%. Tôi có thể chỉ tập trung 10% vào việc này; tôi đang làm năm việc cùng một lúc. Điều này chắc chắn không thể thực hiện được sáu tháng trước, ba tháng trước; điều này là rất gần đây mới thực hiện được.
Trải nghiệm CLI và Chế độ No Flicker
Được rồi. Các session đang hoạt động như thế nào? Vâng, chúng tôi có một PR ở đó, và có vẻ như sắp có một PR khác. PR này có lẽ sẽ là cái khó nhất. Mặc dù vậy, nó trông khá tốt. Dựa trên những thay đổi này, nó có vẻ hợp lý. Tôi sẽ không làm theo cách này, nhưng tôi nghĩ chúng ta cần một cách tốt hơn hoặc tối ưu hóa hơn để làm điều này vì có rất nhiều kiểm tra.
Và nhìn vào thiết lập của bạn ở đây, bạn chủ yếu sử dụng CLI. Vâng. Và bạn luôn sử dụng auto mode cho quyền hạn chứ? Vâng. Và trước đó tôi đã sử dụng dangerously skip permissions. Không, các bạn có thể xóa mọi thứ nếu làm vậy. Tôi không biết nữa. Tôi nghĩ tôi không nên khuyến nghị điều đó. Nhưng tôi nghĩ chờ Claude duyệt rất mất thời gian vì bạn chỉ cần đi làm việc khác và nó cứ ngồi đó. Đó là lý do tại sao auto mode thực sự tốt vì đó là một cách thực sự để khắc phục điều đó thay vì chỉ tin tưởng.
Tôi cũng nhận thấy input, trình soạn thảo nhỏ, được đặt ở cuối màn hình, vì vậy bạn đang sử dụng no flicker mode. Vâng, tôi đang sử dụng no flicker. Thành thật mà nói, tôi nghĩ chúng ta nên đặt nó làm mặc định vì nó tốt hơn rất nhiều. Bạn có thể thấy tôi có thể cuộn rất nhanh. Và bạn có thể cuộn nhanh trước đây, nhưng đôi khi có hiện tượng nhấp nháy, và bây giờ thì không. Mọi người đã thử no flicker mode cho CLI chưa? Vâng, một vài người. Vâng. Chúng tôi đã ra mắt nó vào ngày Cá tháng Tư, vì vậy nhìn lại thì nó giống như một trò đùa một chút. Nếu bạn thực sự đặt biến môi trường Claude Code no flicker equals one Claude, chúng tôi đã viết lại hoàn toàn renderer đang chạy trong CLI. Vì vậy, nó đang sử dụng virtualized scrolling, virtualized selection. Và điều này có nghĩa là mức sử dụng bộ nhớ và CPU liên tục. Và cũng có một số điều hay ho khác như nếu bạn là người type, bạn thực sự có thể nhấp xung quanh trình soạn thảo, và các sự kiện chuột hoạt động, điều này khá điên rồ đối với terminal.
Tôi cũng đang để nó theo dõi PR. Bạn có thể thấy nó ở đây và một số lệnh, sau đó nó sẽ đi ngủ trong 20 phút và thức dậy trở lại. 20 phút có lẽ hơi lâu một chút nhưng không sao. Và đó có phải là việc sử dụng một loop hoặc thứ gì đó không? Tôi nghĩ vậy. Vâng. Và sau đó, hãy xem nó đang làm gì khác. Và những cái khác vẫn đang được sửa lỗi bổ sung. Được rồi. Vậy là khoảng 20 hoặc 25 phút đã trôi qua và chúng ta đã có ba PR. Không, không tệ. Vâng. Và tôi nghĩ chúng ta sẽ có cái thứ tư khi nó hoàn tất việc chạy này. Và trong thời gian chờ đợi, Robobun vẫn đang chạy và tiếp tục tạo ra nhiều PR hơn nữa. Mỗi khi ai đó gửi một vấn đề, nó sẽ cố gắng tái tạo nó.
Bottleneck Luôn Thay Đổi và Tương lai của Robobun
Vâng. Tôi cảm thấy rằng cách Claude code khiến bạn tư duy là mỗi khi có một bottleneck mới, bạn phải tự động hóa bottleneck đó, và sau đó luôn có một bottleneck khác và bạn sẽ chuyển sang giải quyết nó. Giống như việc viết code từng là bottleneck và giờ thì không còn nữa. Sau đó, việc xác minh và chạy test từng là bottleneck và giờ cũng không còn nữa. Và bây giờ có một lớp xác minh sâu hơn. Có lẽ là vậy.
Bạn nghĩ những bottleneck nào còn lại? Chắc chắn đó là lớp xác minh sâu hơn này. Tôi cảm thấy bottleneck tiếp theo sẽ là lập kế hoạch: chúng ta nên làm gì và không nên làm gì, và cách đúng đắn để sửa lỗi này là gì. Lý tưởng nhất là Claude đủ thông minh hoặc chúng ta có thể đủ tin tưởng Claude để nó tự merge các PR. Tôi nghĩ rằng trong một số dự án nhất định, bạn có thể làm điều đó và để nó tự động hoàn toàn. Tôi nghĩ bun chưa đạt đến mức đó đối với Claude hay đúng hơn là cho bun. Nhưng tôi nghĩ sẽ rất tuyệt nếu chúng ta có các tooling để cảm thấy đủ tự tin để làm điều đó.
Hiện tại Robobun không xây dựng tính năng. Nó chưa thực hiện các feature request. Đúng vậy. Vâng, nó không thực hiện các feature request nhưng đôi khi chúng tôi cũng sử dụng nó. Vì vậy, chúng tôi cũng có thể mention nó trong Discord hoặc Slack và nó sẽ cố gắng triển khai tính năng đó. Đôi khi khi mọi người nói: "Này, bun đang thiếu cái này," và tôi chỉ mention con bot và có lẽ một giờ sau sẽ có một PR. Rất nhiều lần ai đó đã tweet cho tôi một cái gì đó như: "Bạn có thể sửa lỗi này không?" hoặc đại loại vậy, và đó là những gì tôi làm, sau đó tôi trả lời bằng một liên kết đến PR. Chúng ta có nên thêm một tài khoản Robobun trên Twitter không?
Tôi nghĩ rằng nó có thể thực hiện các feature request, nhưng tôi ngần ngại cho phép nó triển khai mọi thứ mà bất kỳ ai yêu cầu trong một vấn đề GitHub vì đó là một khối lượng lớn. Bởi vì theo một cách nào đó, việc đưa một thứ như thư viện xử lý hình ảnh vào bun là khá điên rồ. Nhưng chúng ta đã nói về engineering taste (gu kỹ thuật), và có một yếu tố của gu cá nhân ở đó. Giống như bạn cảm thấy đó là một ý tưởng hay. Và chúng tôi vẫn chưa chắc liệu Claude đã đạt đến điểm mà nó cũng sẽ nghĩ đây là một ý tưởng hay hay không. Nhưng bạn biết đấy, một lúc nào đó trong tương lai nó sẽ đạt được.
Tôi nghĩ rằng các PR trở thành các đề xuất. Việc không merge các PR trước đây giống như bạn cảm thấy tồi tệ nếu bạn không merge PR của một đồng nghiệp vì họ đã bỏ công sức vào đó. Nhưng bạn không cần phải cảm thấy tồi tệ khi đó là Claude. Vì vậy, nếu PR sai hoặc vì bất kỳ lý do gì, bạn có thể không merge nó. Nhưng điều đó có nghĩa là tiêu chuẩn cho những gì bạn merge là: nó có nên ở đó không? Bởi vì tôi nghĩ cũng có sự khác biệt khi đó là con người, vì với con người bạn không muốn họ cảm thấy tồi tệ về công việc bị mất của họ. Vì vậy, theo một cách nào đó, điều đó thực sự làm tăng tiêu chuẩn cho những gì bạn quyết định merge.
Thật thú vị. Khi các bottleneck thay đổi, động lực cũng thay đổi một chút. Nó giống như việc phải tin tưởng lẫn nhau, phải tin tưởng những người trong nhóm. Điều này thay đổi một chút. Bây giờ, nó thiên về việc chúng ta có sự tự động hóa phù hợp không và chúng ta có tin tưởng sự tự động hóa không, như một nhóm. Vâng. Vậy tôi nghĩ chúng ta sắp kết thúc rồi.
Tiến độ Xử lý PR Cuối cùng
Có lẽ có một điều cuối cùng nào đó chúng ta muốn cho mọi người thấy để kiểm tra tiến độ đã đạt được không? Tôi không nghĩ vậy. Vâng, nó vẫn đang tiếp tục với cái PR thứ tư. Nó đang qua lại, ví dụ như tìm thấy một lỗi và sau đó sửa lỗi đó. Có vẻ như nó sắp gửi PR rồi.
Hiệu quả của Chế độ Tự động (Auto Mode)
Được rồi, hãy đợi cái này. Nó sắp có thêm một cái nữa. Đây là điểm thú vị của chế độ tự động (auto mode). Ở chế độ tự động, tôi có thể chạy các quads hàng giờ liền. Tôi chạy nó hầu như mỗi đêm. Tôi sẽ có một loạt các quads chạy ở chế độ tự động. Trước đây, nó không hoạt động vì luôn bị kẹt ở một loại yêu cầu cấp quyền nào đó. Và rồi, nghe có vẻ điên rồ, toàn bộ quá trình này chỉ là một prompt, và nó đã chạy trong 30 phút. Vâng, đây là tất cả những gì tôi đã nói. Được rồi, nó đang đẩy lên. Nó sắp gửi PR. Nghe có vẻ đây là giải pháp đúng cho một vấn đề đã tồn đọng từ lâu. Và chúng ta đã có một PR. Vâng, chúng ta có thể vào vấn đề này và xem nó có bao nhiêu đầu ra. 20. Vâng, khá nhiều.
Tầm nhìn về Tương lai Ngành Kỹ thuật
Tuyệt vời. Có lẽ chúng ta có thể tạm dừng ở đây. Nhưng đối với tôi, đây là một tầm nhìn thật sự thú vị về nơi mà ngành kỹ thuật đang hướng tới. Tôi nghĩ là cho tất cả mọi người trong căn phòng này. Và chúng ta sẽ thấy điều này trước tiên. Chúng ta sẽ phải tìm hiểu nó trước, và sau đó mọi người khác sẽ phải tìm hiểu điều này. Vì vậy, như chúng ta đã nói sáng nay, chúng tôi rất hào hứng được cùng nhau trên hành trình này. Và như bạn có thể thấy, chúng ta chưa tìm ra mọi thứ. Nhưng tôi nghĩ chế độ chúng ta đang ở là liên tục thử nghiệm, liên tục cố gắng xem bottleneck tiếp theo là gì để chúng ta có thể giải quyết nó. Điều này rất thú vị vì nó rất tuyệt. Tôi thích những thứ này. Tuyệt vời. Tôi có nên, vâng, chúng ta có thể để nó như vậy.