- Michele Catasta, president và head of AI tại Replit, lập luận rằng đánh giá agent phải chuyển từ một điểm số "cổng kiểm soát boolean" dùng một lần sang một cỗ máy liên tục giúp ship một agent tốt hơn mỗi ngày.
- Replit vận hành hai trụ cột: benchmark offline (
VibeBenchmã nguồn mở mới, xây cả app từPRDvà chấm điểm bằng evaluator tự động điều khiển trình duyệt) dùng trước khi ship, và đánh giá online (AB testingcộng phân cụm trace ngữ nghĩa, gọi làTelescope) dùng sau khi ship. - Bài nói nhấn mạnh AB test hiếm khi cho kết quả rõ ràng, nên gu thẩm mỹ và triết lý sản phẩm của con người vẫn thiết yếu; các model long-context biết suy luận gần đây (Opus 4.5+) cuối cùng đã giúp vòng lặp phản hồi dựa trên trace trở nên khả thi.
Evaluating and improving Replit Agent at scale
- Hiểu rằng
vibe codingở Replit là trường hợp cực đoan: người dùng đi từ prompt ngôn ngữ tự nhiên thẳng đến app chạy được, không chọn framework, không viết test — nên eval kiểu developer truyền thống buộc phải thay đổi. - Đánh giá phải liên tục thay vì một điểm số do con người tạo ra, vì model, prompt và định nghĩa tool thay đổi không ngừng (nhiều bản release agent mỗi ngày tới hàng triệu người dùng).
- Tập trung vào
functional correctness("app có làm đúng điều người dùng yêu cầu không") thay vì giao thức cố định của SweetBench/HumanEval (vốn không hợp với vibe coding vì không có test sẵn và xây từ repo trống). - Dùng
VibeBench: lấyPRDlàm đầu vào, xây app end-to-end, chấm bằng evaluator tự động đọc code, mở trình duyệt và đi qua test plan bằng ngôn ngữ tự nhiên; các kịch bản từ zero-to-one tới "slop on slop" tới phân rã task chạy song song rồi merge. - Lưu ý kết quả VibeBench: chênh ~2x giữa model frontier và open-weight, và hầu hết model làm tệ hơn khi mở rộng code của chính mình — vì vậy luôn thêm bước test giữa các feature.
- Triển khai trụ cột online (
Telescope): phân cụm hàng triệu trace production theo ngữ nghĩa mỗi đêm, embed các bản tóm tắt lỗi, phân loại bằng LLM, để bắt các lỗi long-tail hiếm (ví dụ 1%) mà dashboard DataDog không thấy. - Tự động hóa vòng lặp Telescope (~90% có agent hỗ trợ): phát hiện lỗi từ trace, tự cắt PR bằng coding agent, chạy VibeBench làm phép thử (giảm 10 điểm = thay đổi xấu), AB test các thay đổi gây tranh cãi, ship khi rõ thắng — nhưng quyết định cuối vẫn do con người dựa trên gu thẩm mỹ và triết lý sản phẩm.
vibe coding— đi từ đặc tả ngôn ngữ tự nhiên thẳng đến app chạy được, không chọn framework, không viết testVibeBench— benchmark mã nguồn mở của Replit cho vibe coding end-to-endPRD— tài liệu yêu cầu sản phẩm; ở đây là prompt dài mô tả cách xây appautomated evaluator— agent AI đọc code, mở trình duyệt và chạy test plan để chấm điểmfunctional correctness— app có làm đúng điều người dùng yêu cầu khôngTelescope— hệ thống nội bộ của Replit phân cụm trace, phát hiện lỗi và tự sinh fixtrace clustering— gom trace theo độ tương đồng ngữ nghĩa để lộ ra các kiểu lỗi lặp lạiAB testing— chạy nhiều phiên bản agent song song trong production để so metricslop on slop— xây feature mới trên code agent chưa kiểm chứng; kịch bản khó nhất
Vấn đề: vì sao eval truyền thống không đủ
Replit là nền tảng vibe coding cho knowledge worker. Trong trường hợp cực đoan của họ, người dùng bắt đầu chỉ từ một đặc tả ngôn ngữ tự nhiên và không gì khác — họ kỳ vọng đi từ prompt thẳng đến app chạy được, không nói framework muốn dùng, không viết test. Do đó cách đánh giá và xây agent kiểu cũ (dành cho lập trình viên) buộc phải thay đổi tận gốc.
Thách thức càng lớn vì model thay đổi gần như liên tục, nhanh hơn cả một năm trước. Replit phải đổi prompt, định nghĩa tool và ship nhiều bản agent mỗi ngày cho hàng triệu người dùng. Cách cũ — chạy eval ra một điểm số duy nhất do con người diễn giải (harness tốt hơn hay tệ đi, có cần post-training thêm không) — không còn phù hợp. Diễn giả đề xuất chuyển sang đánh giá liên tục, khai thác hàng triệu trace production mỗi ngày.
Hai trụ cột đánh giá
Hệ thống mới có hai trụ cột:
- Benchmark offline (cổng kiểm soát): dùng trước khi ship, như một cờ boolean. Nếu có regression lớn thì dừng release; nếu không thay đổi hoặc tốt lên thì tiếp tục.
- Đánh giá online: chạy sau khi ship, gồm
AB testingvà phân cụm trace production, buộc đội phản ứng nhanh nhất có thể.
Vòng lặp: có hai trụ cột này, bạn phản ánh kết quả, sửa code, chạy eval lại, lặp đi lặp lại mỗi ngày.
VibeBench: benchmark mới
SweetBench và HumanEval đều theo cùng giao thức — sinh code khớp prompt, áp patch lên repo, chạy test có sẵn. Điều này không phản ánh vibe coding vì người dùng không viết test và bắt đầu từ repo trống. Cái cần đo là functional correctness — app có làm đúng điều người dùng yêu cầu không.
VibeBench (mã nguồn mở tại vibebench.ai) lấy đầu vào là một PRD — prompt dài mô tả cách xây app, chọn từ 20 trace thực tế thay vì dữ liệu tổng hợp. Một harness xây app end-to-end từ repo trống, rồi các automated evaluator đọc code base, mở trình duyệt trỏ tới app, và đi qua một test plan diễn đạt bằng ngôn ngữ tự nhiên ("mở admin dashboard, đăng nhập tài khoản này, nhấp toggle kia"). Nếu bước nào fail thì gom lại và sinh điểm.
Có năm kiểu ghép (pairing), từ đơn giản đến phức tạp:
- Zero-to-one: từ PRD xây app một phát.
- VibeBench Ref: bắt đầu từ thứ đã chạy, xây feature lên trên.
- VibeBench Vibe ("slop on slop"): bắt đầu từ MVP do agent tạo chưa kiểm chứng, rồi viết thêm code agent lên trên.
- Parallel + merge: phân rã task, chạy song song rồi merge các patch — khó hơn nhiều cho coding agent.
- Thậm chí bắt đầu từ app có bug và xây feature lên trên.
Vì vibe coding không đặt guardrail (người dùng tự chọn ngôn ngữ, framework), evaluator phải hoàn toàn bất khả tri về cách triển khai. Đó là lý do mất nhiều tháng để xây — khác với SweetBench có "bề mặt" cố định.
Kết quả đáng chú ý: chênh gần 2x giữa model frontier và open-weight; hầu hết model làm tệ hơn khi mở rộng code của chính mình (slop on slop là khó nhất). Bài học: luôn thêm bước test giữa mỗi feature, nếu không bạn xây trên nền móng lung lay.
Telescope: trụ cột online
Khác với offline (~20 app), Replit Engine thu hàng triệu session mỗi ngày, không kịch bản, phản ánh điều người dùng thực sự làm. Replit chạy nhiều AB test để giữ mình trung thực, theo dõi các metric như thời lượng chạy bất thường và sentiment người dùng (phân tích cảm xúc mỗi prompt). Một tín hiệu tích cực mạnh đặc thù của Replit: người dùng publish app của họ ra công khai.
Vấn đề: AB test hiếm khi rõ ràng — ví dụ thời lượng chạy +7% nhưng rẻ hơn 8%, sentiment dao động. Đây là lúc gu thẩm mỹ và triết lý sản phẩm của con người vào cuộc.
Để sinh ứng viên AB test, Replit phân cụm tất cả trace mỗi đêm, xác định cụm nào là hành vi bình thường (phần lớn app thành công) và cụm nào có vấn đề. Với cụm có vấn đề: embed các bản tóm tắt lỗi, gom theo loại, đưa qua một LLM để phân loại. Vì làm theo ngữ nghĩa (không phải regex trên log), có thể gom các lỗi gần nhau về nghĩa dù output không giống nhau. Cụm được retrain mỗi đêm (vì nhiều phiên bản engine chạy song song), và còn cho biết một cụm có biến mất sau khi fix hay không — bắt được cả lỗi chỉ xảy ra 1% mà DataDog không thấy.
Telescope là vòng lặp: (1) phát hiện lỗi từ phân cụm trace; (2) tự cắt PR bằng coding agent dựa trên thông tin từ trace, log, dashboard; (3) đánh giá xem có phải breaking change — chạy VibeBench như phép thử (giảm 10 điểm = xấu); (4) AB test các thay đổi gây tranh cãi; (5) ship khi rõ thắng, lặp lại nếu giả thuyết đúng nhưng PR chưa hoàn hảo. Khoảng 90% có agent hỗ trợ.
Ví dụ thực tế: setup môi trường đôi khi lâu hơn dự kiến, agent (vốn rất hăng sửa lỗi) đi lạc cố sửa môi trường. Vì agent không xác định, mỗi phiên debug khác nhau, nên grep log không lộ ra — chỉ khi phân cụm trace mới thấy lỗi xảy ra khá thường xuyên và fix ngay (không cần AB test vì là regression thuần).
Vai trò của con người và gu thẩm mỹ
Dù tối ưu hết mức cho AI engineer, vẫn còn nhiều việc trí tuệ cho con người: với mỗi cụm, đội đặt giả thuyết về điều có thể sai, ưu tiên nguồn lực, đưa hiểu biết của mình vào để hướng dẫn agent thay vì để nó viết PR không giám sát. Mỗi lựa chọn PR/AB test là "tạo hình ngọn đồi" cần tối ưu, định nghĩa triết lý sản phẩm. Quyết định launch cuối cùng vẫn do con người.
Thông điệp đóng: đừng coi đánh giá chỉ là bước kiểm tra cuối trước khi ship, một cờ boolean — hãy coi nó như cỗ máy giúp ship một agent tốt hơn mỗi ngày.
Hỏi đáp với Anthropic (Hannah)
Về việc mở mã nguồn VibeBench: Catasta tin nên đóng góp tối đa cho cộng đồng — eval công khai giúp model tốt hơn, agent tốt hơn, sản phẩm tốt hơn; ông không tin vào việc cạnh tranh trên eval.
Về Telescope: nếu 6 tháng trước thử mà nản thì hãy thử lại — các model long-context biết suy luận (Opus 4.5+) giờ cho phép tiêm cả trace vào Opus và nhận phản hồi tinh vi. Telescope không chỉ dùng trace mà còn form phản hồi trong sản phẩm, góc nhìn người dùng và mọi instrument trong DataDog.
Về gu thẩm mỹ: hơn một năm rưỡi trước agent còn yếu, mọi thứ là "trò sinh tồn"; nay khi agent mạnh và nhiều lựa chọn, gu phải khớp với user base thực tế — đội Replit rất kỹ thuật nhưng phục vụ knowledge worker chưa từng viết dòng code nào.
TL;DR
- Michele Catasta, president và head of AI tại Replit, lập luận rằng đánh giá agent phải chuyển từ một điểm số "cổng kiểm soát boolean" dùng một lần sang một cỗ máy liên tục giúp ship một agent tốt hơn mỗi ngày.
- Replit vận hành hai trụ cột: benchmark offline (
VibeBenchmã nguồn mở mới, xây cả app từPRDvà chấm điểm bằng evaluator tự động điều khiển trình duyệt) dùng trước khi ship, và đánh giá online (AB testingcộng phân cụm trace ngữ nghĩa, gọi làTelescope) dùng sau khi ship. - Bài nói nhấn mạnh AB test hiếm khi cho kết quả rõ ràng, nên gu thẩm mỹ và triết lý sản phẩm của con người vẫn thiết yếu; các model long-context biết suy luận gần đây (Opus 4.5+) cuối cùng đã giúp vòng lặp phản hồi dựa trên trace trở nên khả thi.
Điểm chính
- Hiểu rằng
vibe codingở Replit là trường hợp cực đoan: người dùng đi từ prompt ngôn ngữ tự nhiên thẳng đến app chạy được, không chọn framework, không viết test — nên eval kiểu developer truyền thống buộc phải thay đổi. - Đánh giá phải liên tục thay vì một điểm số do con người tạo ra, vì model, prompt và định nghĩa tool thay đổi không ngừng (nhiều bản release agent mỗi ngày tới hàng triệu người dùng).
- Tập trung vào
functional correctness("app có làm đúng điều người dùng yêu cầu không") thay vì giao thức cố định của SweetBench/HumanEval (vốn không hợp với vibe coding vì không có test sẵn và xây từ repo trống). - Dùng
VibeBench: lấyPRDlàm đầu vào, xây app end-to-end, chấm bằng evaluator tự động đọc code, mở trình duyệt và đi qua test plan bằng ngôn ngữ tự nhiên; các kịch bản từ zero-to-one tới "slop on slop" tới phân rã task chạy song song rồi merge. - Lưu ý kết quả VibeBench: chênh ~2x giữa model frontier và open-weight, và hầu hết model làm tệ hơn khi mở rộng code của chính mình — vì vậy luôn thêm bước test giữa các feature.
- Triển khai trụ cột online (
Telescope): phân cụm hàng triệu trace production theo ngữ nghĩa mỗi đêm, embed các bản tóm tắt lỗi, phân loại bằng LLM, để bắt các lỗi long-tail hiếm (ví dụ 1%) mà dashboard DataDog không thấy. - Tự động hóa vòng lặp Telescope (~90% có agent hỗ trợ): phát hiện lỗi từ trace, tự cắt PR bằng coding agent, chạy VibeBench làm phép thử (giảm 10 điểm = thay đổi xấu), AB test các thay đổi gây tranh cãi, ship khi rõ thắng — nhưng quyết định cuối vẫn do con người dựa trên gu thẩm mỹ và triết lý sản phẩm.
Từ vựng
vibe coding— đi từ đặc tả ngôn ngữ tự nhiên thẳng đến app chạy được, không chọn framework, không viết testVibeBench— benchmark mã nguồn mở của Replit cho vibe coding end-to-endPRD— tài liệu yêu cầu sản phẩm; ở đây là prompt dài mô tả cách xây appautomated evaluator— agent AI đọc code, mở trình duyệt và chạy test plan để chấm điểmfunctional correctness— app có làm đúng điều người dùng yêu cầu khôngTelescope— hệ thống nội bộ của Replit phân cụm trace, phát hiện lỗi và tự sinh fixtrace clustering— gom trace theo độ tương đồng ngữ nghĩa để lộ ra các kiểu lỗi lặp lạiAB testing— chạy nhiều phiên bản agent song song trong production để so metricslop on slop— xây feature mới trên code agent chưa kiểm chứng; kịch bản khó nhất
Nội dung chi tiết
Vấn đề: vì sao eval truyền thống không đủ
Replit là nền tảng vibe coding cho knowledge worker. Trong trường hợp cực đoan của họ, người dùng bắt đầu chỉ từ một đặc tả ngôn ngữ tự nhiên và không gì khác — họ kỳ vọng đi từ prompt thẳng đến app chạy được, không nói framework muốn dùng, không viết test. Do đó cách đánh giá và xây agent kiểu cũ (dành cho lập trình viên) buộc phải thay đổi tận gốc.
Thách thức càng lớn vì model thay đổi gần như liên tục, nhanh hơn cả một năm trước. Replit phải đổi prompt, định nghĩa tool và ship nhiều bản agent mỗi ngày cho hàng triệu người dùng. Cách cũ — chạy eval ra một điểm số duy nhất do con người diễn giải (harness tốt hơn hay tệ đi, có cần post-training thêm không) — không còn phù hợp. Diễn giả đề xuất chuyển sang đánh giá liên tục, khai thác hàng triệu trace production mỗi ngày.
Hai trụ cột đánh giá
Hệ thống mới có hai trụ cột:
- Benchmark offline (cổng kiểm soát): dùng trước khi ship, như một cờ boolean. Nếu có regression lớn thì dừng release; nếu không thay đổi hoặc tốt lên thì tiếp tục.
- Đánh giá online: chạy sau khi ship, gồm
AB testingvà phân cụm trace production, buộc đội phản ứng nhanh nhất có thể.
Vòng lặp: có hai trụ cột này, bạn phản ánh kết quả, sửa code, chạy eval lại, lặp đi lặp lại mỗi ngày.
VibeBench: benchmark mới
SweetBench và HumanEval đều theo cùng giao thức — sinh code khớp prompt, áp patch lên repo, chạy test có sẵn. Điều này không phản ánh vibe coding vì người dùng không viết test và bắt đầu từ repo trống. Cái cần đo là functional correctness — app có làm đúng điều người dùng yêu cầu không.
VibeBench (mã nguồn mở tại vibebench.ai) lấy đầu vào là một PRD — prompt dài mô tả cách xây app, chọn từ 20 trace thực tế thay vì dữ liệu tổng hợp. Một harness xây app end-to-end từ repo trống, rồi các automated evaluator đọc code base, mở trình duyệt trỏ tới app, và đi qua một test plan diễn đạt bằng ngôn ngữ tự nhiên ("mở admin dashboard, đăng nhập tài khoản này, nhấp toggle kia"). Nếu bước nào fail thì gom lại và sinh điểm.
Có năm kiểu ghép (pairing), từ đơn giản đến phức tạp:
- Zero-to-one: từ PRD xây app một phát.
- VibeBench Ref: bắt đầu từ thứ đã chạy, xây feature lên trên.
- VibeBench Vibe ("slop on slop"): bắt đầu từ MVP do agent tạo chưa kiểm chứng, rồi viết thêm code agent lên trên.
- Parallel + merge: phân rã task, chạy song song rồi merge các patch — khó hơn nhiều cho coding agent.
- Thậm chí bắt đầu từ app có bug và xây feature lên trên.
Vì vibe coding không đặt guardrail (người dùng tự chọn ngôn ngữ, framework), evaluator phải hoàn toàn bất khả tri về cách triển khai. Đó là lý do mất nhiều tháng để xây — khác với SweetBench có "bề mặt" cố định.
Kết quả đáng chú ý: chênh gần 2x giữa model frontier và open-weight; hầu hết model làm tệ hơn khi mở rộng code của chính mình (slop on slop là khó nhất). Bài học: luôn thêm bước test giữa mỗi feature, nếu không bạn xây trên nền móng lung lay.
Telescope: trụ cột online
Khác với offline (~20 app), Replit Engine thu hàng triệu session mỗi ngày, không kịch bản, phản ánh điều người dùng thực sự làm. Replit chạy nhiều AB test để giữ mình trung thực, theo dõi các metric như thời lượng chạy bất thường và sentiment người dùng (phân tích cảm xúc mỗi prompt). Một tín hiệu tích cực mạnh đặc thù của Replit: người dùng publish app của họ ra công khai.
Vấn đề: AB test hiếm khi rõ ràng — ví dụ thời lượng chạy +7% nhưng rẻ hơn 8%, sentiment dao động. Đây là lúc gu thẩm mỹ và triết lý sản phẩm của con người vào cuộc.
Để sinh ứng viên AB test, Replit phân cụm tất cả trace mỗi đêm, xác định cụm nào là hành vi bình thường (phần lớn app thành công) và cụm nào có vấn đề. Với cụm có vấn đề: embed các bản tóm tắt lỗi, gom theo loại, đưa qua một LLM để phân loại. Vì làm theo ngữ nghĩa (không phải regex trên log), có thể gom các lỗi gần nhau về nghĩa dù output không giống nhau. Cụm được retrain mỗi đêm (vì nhiều phiên bản engine chạy song song), và còn cho biết một cụm có biến mất sau khi fix hay không — bắt được cả lỗi chỉ xảy ra 1% mà DataDog không thấy.
Telescope là vòng lặp: (1) phát hiện lỗi từ phân cụm trace; (2) tự cắt PR bằng coding agent dựa trên thông tin từ trace, log, dashboard; (3) đánh giá xem có phải breaking change — chạy VibeBench như phép thử (giảm 10 điểm = xấu); (4) AB test các thay đổi gây tranh cãi; (5) ship khi rõ thắng, lặp lại nếu giả thuyết đúng nhưng PR chưa hoàn hảo. Khoảng 90% có agent hỗ trợ.
Ví dụ thực tế: setup môi trường đôi khi lâu hơn dự kiến, agent (vốn rất hăng sửa lỗi) đi lạc cố sửa môi trường. Vì agent không xác định, mỗi phiên debug khác nhau, nên grep log không lộ ra — chỉ khi phân cụm trace mới thấy lỗi xảy ra khá thường xuyên và fix ngay (không cần AB test vì là regression thuần).
Vai trò của con người và gu thẩm mỹ
Dù tối ưu hết mức cho AI engineer, vẫn còn nhiều việc trí tuệ cho con người: với mỗi cụm, đội đặt giả thuyết về điều có thể sai, ưu tiên nguồn lực, đưa hiểu biết của mình vào để hướng dẫn agent thay vì để nó viết PR không giám sát. Mỗi lựa chọn PR/AB test là "tạo hình ngọn đồi" cần tối ưu, định nghĩa triết lý sản phẩm. Quyết định launch cuối cùng vẫn do con người.
Thông điệp đóng: đừng coi đánh giá chỉ là bước kiểm tra cuối trước khi ship, một cờ boolean — hãy coi nó như cỗ máy giúp ship một agent tốt hơn mỗi ngày.
Hỏi đáp với Anthropic (Hannah)
Về việc mở mã nguồn VibeBench: Catasta tin nên đóng góp tối đa cho cộng đồng — eval công khai giúp model tốt hơn, agent tốt hơn, sản phẩm tốt hơn; ông không tin vào việc cạnh tranh trên eval.
Về Telescope: nếu 6 tháng trước thử mà nản thì hãy thử lại — các model long-context biết suy luận (Opus 4.5+) giờ cho phép tiêm cả trace vào Opus và nhận phản hồi tinh vi. Telescope không chỉ dùng trace mà còn form phản hồi trong sản phẩm, góc nhìn người dùng và mọi instrument trong DataDog.
Về gu thẩm mỹ: hơn một năm rưỡi trước agent còn yếu, mọi thứ là "trò sinh tồn"; nay khi agent mạnh và nhiều lựa chọn, gu phải khớp với user base thực tế — đội Replit rất kỹ thuật nhưng phục vụ knowledge worker chưa từng viết dòng code nào.