- Sự phát triển của các mô hình ngôn ngữ lớn (LLMs) như Claude Code đã dịch chuyển đáng kể tốc độ phát triển phần mềm, cho phép các kỹ sư đơn lẻ xây dựng các hệ thống phân tán phức tạp như Kafka (
Helix) chỉ trong vài ngày. - Việc phát triển nhanh chóng bằng tác nhân AI đã chuyển các nút thắt cổ chai từ viết mã thủ công sang các thách thức về vận hành, phối hợp con người, và xác minh sự phù hợp của sản phẩm được tạo ra bởi tác nhân để triển khai vào môi trường sản phẩm.
- Để giải quyết vấn đề này, bài nói đề xuất khái niệm "công cụ máy móc" (
Tamper) cho tác nhân và "nhà máy tối" (Dark Factory), nhằm cung cấp cấu trúc, khả năng lặp lại và kiểm soát cho quá trình phát triển phần mềm do tác nhân điều khiển, giúp chuyển đổi từ cơ giới hóa sang công nghiệp hóa phần mềm.
How Datadog built a universal machine tool for Claude Code
- LLMs cho phép phát triển nhanh chóng các hệ thống phân tán phức tạp; ví dụ, xây dựng một dịch vụ streaming tương đương Kafka (
Helix) chỉ trong vài ngày với một kỹ sư duy nhất. - Chiến lược tối ưu hóa tiến hóa (ví dụ:
BITS Evolve) hiệu quả hơn khi được áp dụng cho các khối mã hoặc hàm mục tiêu hẹp, thay vì toàn bộ hệ thống lớn do bề mặt phức tạp và mơ hồ quá rộng. - Sự gia tăng năng lực của tác nhân AI đã dịch chuyển nút thắt cổ chai trong phát triển phần mềm từ quá trình xây dựng mã sang giai đoạn điều phối của con người để đưa sản phẩm vào môi trường thực tế và tích lũy kinh nghiệm vận hành.
- Các tác nhân AI thường tự tạo ra các công cụ, mã kết nối và quy ước riêng lẻ trong mỗi phiên, dẫn đến kiến thức vận hành bị phân mảnh và khó chia sẻ, khiến việc duy trì hệ thống trở nên phức tạp.
- Khái niệm "công cụ máy móc" (
machine tools) cho tác nhân (ví dụ:Tamper) là cần thiết để chuẩn hóa và cấu trúc hóa quá trình tác nhân tạo công cụ, chuyển các cơ chế ứng biến thành các đặc tả ý định chính xác, có thể lặp lại và kiểm thử được. - "Nhà máy tối" (
Dark Factory) đại diện cho một quy trình phần mềm nơi tác nhân hoạt động tự động và liên tục mà không cần sự can thiệp trực tiếp của con người, đòi hỏi con người phải tập trung vào thiết kế nhà máy, các ràng buộc và vòng lặp xác minh. - Việc triển khai
Tampertrong "nhà máy tối" cho phép quản lý chính xác hơn các phiên tác nhân (mặt phẳng điều khiển tác nhân), cấu trúc hóa quá trình tự tạo công cụ của tác nhân, và quản lý chuỗi xác minh cho các thành phần phần mềm. - Hệ thống được xây dựng bằng AI có tiềm năng tiết kiệm chi phí đáng kể (ví dụ:
Helixcó thể rẻ hơn 2-5 lần so với giải pháp hiện có), nhưng cần nỗ lực để chứng minh sự ổn định vận hành trước khi triển khai sản phẩm.
machine tools— công cụ máy mócbuild— xây dựng / phát triểntest— kiểm thửglue code— mã kết nốitác nhân— agentmôi trường sản phẩm— production environmentnút thắt cổ chai— bottleneckscalable— có thể mở rộngDark Factory— nhà máy tốiđặc tả— specification
Lời Giới Thiệu và Nguồn Cảm Hứng
Xin chào Sesh Malah, Phó chủ tịch (VP) tại DataDog. Tôi để ý bây giờ là 4 giờ chiều. Năng lượng của mọi người thế nào rồi? Từ đầu đến giờ, các bạn thấy hội nghị ra sao? Tuyệt vời. Được rồi. Hãy cùng nhau khơi dậy chút khí thế nào.
Vậy xin cho tôi thấy cánh tay của những ai đã từng nghe về machine tools trước đây. Những gì trên slide này, các bạn đã dùng cái nào chưa? Dù sao thì tôi cũng dự đoán là không có ai giơ tay cả. Dù sao thì đây vẫn sẽ là chủ đề của bài nói.
Machine tools là các công cụ như Jigs, fixtures, gauges và mills mà các bạn thấy trong ngành sản xuất để tạo ra các bộ phận máy móc chính xác và có thể lặp lại. Những bộ phận này được lắp ráp thành các cỗ máy lớn hơn như động cơ, máy bay, lò phản ứng hạt nhân, các mô-đun hạ cánh lên mặt trăng mà chúng ta đã thấy sáng nay. Machine tools là một bước đột phá trong thời kỳ công nghiệp hóa, cho phép mở rộng quy mô nhờ khả năng hoán đổi cho nhau thông qua tiêu chuẩn hóa và độ chính xác.
Đó chính là nguồn cảm hứng cho bài nói của tôi và cho những gì chúng tôi đã build tại DataDog. Tôi sẽ chia sẻ với các bạn cách tất cả những điều này phù hợp với việc build phần mềm bằng Claude Code.
Hành Trình với Mô Hình Ngôn Ngữ Lớn: Từ Giới Hạn đến Tham Vọng
Vậy những gì các bạn đang thấy trên slide là cái nhìn của tôi về 18 tháng qua. Tôi nghĩ rằng có nhiều góc nhìn khác nhau về biểu đồ này trong nhiều phiên hôm nay. Những nhận định phi khoa học này, xin đừng coi đây là đánh giá chính thức của tôi. Đây hoàn toàn là quan điểm cá nhân. Nhưng đó là câu chuyện về tham vọng với các mô hình. Trong phần lớn năm 2025, các mô hình hữu ích đối với tôi, nhưng trong giới hạn rất hẹp, như các thay đổi cục bộ, các hàm nhỏ, test, glue code, các prototype dùng một lần để tôi học hỏi rất nhiều từ chúng.
Sau đó, vào khoảng cuối năm 2025, tôi nghĩ tất cả các bạn đều đã thấy điều này khi độ dốc bắt đầu thay đổi, giống như một tăng trưởng theo cấp số nhân. Tôi bắt đầu tin tưởng Claude với các công việc code hệ thống lớn hơn và mơ hồ hơn.
Những Ý Tưởng Dẫn Lối: Từ Hệ Thống Phân Tán Cổ Điển đến Tối Ưu Hóa Tiến Hóa
Trước khi nói về machine tools, tôi muốn điểm qua một số ý tưởng đã dẫn tôi đến đây. Đây là năm 2024. Đây là một bài viết. Chúng tôi đã build một hệ thống hàng đợi phân tán tên là Courier từ đầu. Tất cả những việc này đều diễn ra trước thời đại của tác nhân, mọi thứ đều được thực hiện thủ công. Chúng ta có thể tin được không? Phần mềm vẫn được build bằng tay vào thời điểm đó. Phần khó khăn là, đối với bất kỳ hệ thống phân tán nào được con người hoặc tác nhân build, không chỉ là build các phần mà còn là build các mảnh ghép và làm cho sự tương tác giữa chúng có thể quan sát được, có thể test được và có thể xác minh được.
Vì vậy, chúng tôi rất nghiêm ngặt với việc mô hình hóa chính thức và mô phỏng. Các bạn sẽ thấy nhiều kỹ thuật khác nhau trong bài đăng này. Tất cả những điều này là công việc hệ thống cổ điển, nơi bạn xác định các phần mà lỗi có thể tốn kém hoặc khó đảo ngược, và bạn nâng cao sự nghiêm ngặt cho những phần đó mà bạn không muốn chúng trượt vào môi trường sản phẩm.
Ý tưởng tiếp theo xuất hiện vào khoảng tháng 9 năm 2025, chúng tôi gọi nó là BITS Evolve. Đây là một hệ thống tối ưu hóa tiến hóa vòng kín, lấy cảm hứng từ AlphaEvolve của DeepMind. Ý tưởng là bạn để các phần code tự cải thiện trong một môi trường được kiểm soát chặt chẽ. Tôi nghĩ chúng ta đã thấy một số thông báo hôm nay tại bài phát biểu chính về dreaming và các vòng lặp khác nhau. Vì vậy, đây là những gì chúng tôi đã thử vào tháng 9 năm 2025. Đó là một tập hợp hoặc một hội đồng các mô hình, lớn và nhỏ, và chúng tạo ra các biến thể code, bất kể bạn chỉ định cái gì bạn muốn chúng cải thiện. Trong trường hợp của chúng tôi, đó là các hàm khó, các khối code. Và sau đó bạn có một chuỗi kiểm tra mà bạn thấy ở phía bên phải màn hình với các benchmark, test và khả năng quan sát môi trường sản phẩm để quyết định cái gì sẽ tồn tại. Nó giống như chọn lọc tự nhiên.
Vì vậy, đây là cái nhìn đầu tiên đối với tôi rằng các phần mềm có thể được nuôi dưỡng, giống như các sinh vật sống, như thực vật, hoặc như vi sinh vật, và phát triển thông qua sự biến đổi với phản hồi và thích nghi.
Tuy nhiên, điều tôi nhận ra là kiểu tiến hóa này chỉ tốt khi môi trường nó thích nghi tốt. Nếu bạn có benchmark kém, chúng sẽ tạo ra những sự tiến hóa kém. Khả năng quan sát yếu, các tối ưu hóa của bạn sẽ nông cạn.
Xây Dựng Hệ Thống Lớn với Claude Code và Thách Thức
Sau đó, trong giai đoạn đột phá hoặc tăng trưởng theo cấp số nhân bắt đầu, chúng tôi đã build toàn bộ hệ thống phân tán bằng Claude Code. Tôi đã đề cập đến điểm uốn Opus 45, nơi tôi nâng cao tham vọng của mình. Nó không phải là đột ngột. Tôi không thức dậy một ngày và sau đó bắt đầu tin tưởng Claude với toàn bộ hệ thống, hoặc thậm chí là cơ sở dữ liệu của mình. Chúng tôi có rất nhiều trong số đó. Nó diễn ra dần dần. Tôi đã thử các nhiệm vụ khó hơn và các hệ thống con lớn hơn, thất bại rất nhiều, học hỏi rất nhiều qua nhiều thử nghiệm, và sau đó bắt đầu thấy thành công vào khoảng thời gian này.
Vì vậy, chúng tôi quyết định tham vọng hơn, liệu chúng ta có thể build một thứ gì đó lớn như Kafka không? Xin cho tôi thấy cánh tay của những ai đã nghe về Kafka. OK, bây giờ thì nhiều cánh tay hơn. Kafka là một dịch vụ streaming. Vì vậy, chúng tôi đã thử, liệu chúng ta có thể build nó từ đầu không? Nó giống như lặp lại cùng một chiến lược mà chúng tôi đã có cho Courier. Đó là một hệ thống hàng đợi, khá gần. Với sự nghiêm ngặt tương tự. Vì vậy, các bạn sẽ thấy chuỗi kiểm tra ở phía bên phải của slide này. Nhưng Claude Code thực hiện hầu hết việc xây dựng với một người duy nhất build nó. Trong vài ngày, với niềm tin của anh ấy, chúng tôi đã có một hệ thống hoạt động đầy đủ chức năng, có thể so sánh với Kafka. Và chúng tôi gọi nó là Helix. Vì vậy, phương pháp mã nguồn và chi tiết đều được liên kết trong bài đăng này. Mọi người có thể xem sau. Nhưng để đưa Helix vào môi trường sản phẩm bây giờ đòi hỏi phải tích lũy kinh nghiệm vận hành, và điều đó đã trở thành thách thức đối với chúng tôi.
Vì vậy, bước đi tự nhiên tiếp theo của chúng tôi là, tôi đã nói về BITS Evolve trước đó. Liệu BITS Evolve có thể phát triển các phần của Helix, theo cách nó đã phát triển các hàm quan trọng không? Tham vọng giống như hai viên gạch lớn, từ các hàm nhỏ đến việc liệu toàn bộ thành phần có thể phát triển không? Liệu nó có thể cung cấp kinh nghiệm vận hành mà chúng tôi cần để đưa vào môi trường sản phẩm không? Câu trả lời là không hoàn toàn. Bề mặt quá lớn. Ngay cả với chuỗi xác minh mà tôi đã chỉ cho các bạn trong slide trước, khá nghiêm ngặt, vẫn có quá nhiều nơi con người phải diễn giải và sửa chữa. Nó quá nhiều lượt tương tác.
Vì vậy, bạn nghĩ, OK, liệu chúng ta có thể tìm kiếm một bề mặt hẹp hơn không? Liệu chúng ta có thể giảm bớt tham vọng một chút không? Bài đăng này nói về điều đó. Vì vậy, chúng tôi đã chọn máy chủ tổng hợp số liệu của mình. Chúng tôi là DataDog, vì vậy chúng tôi có rất nhiều số liệu. Liệu chúng ta có thể cải thiện logic vật chất hóa trực tiếp, không ngoại tuyến, như những gì chúng ta đã làm với BITS Evolve trước đây không? Liệu chúng ta có thể tối ưu hóa chúng cho khách hàng với một proof carrying path xung quanh sự thay đổi không? Để con người không phải code review mọi ứng viên được tạo ra.
Sự Dịch Chuyển của Nút Thắt Cổ Chai và Định Luật Amdahl
Nếu bạn nhìn vào luồng công việc qua bốn dự án này, nếu bạn quan sát mẫu hình, mỗi dự án đều phơi bày nút thắt cổ chai cho dự án tiếp theo. Hôm nay có nhiều bài nói và bình luận về việc nút thắt cổ chai đang được di chuyển.
Với Courier, nút thắt cổ chai là quá trình xây dựng với con người build hệ thống thông qua thiết kế, mô hình hóa và xác minh cẩn thận. Chúng tôi mất một năm để build Courier. Và sau đó nếu so sánh, chỉ mất ba ngày để build một hệ thống tương tự Kafka. Trong khoảng thời gian nào? Chỉ trong vài tháng.
Với BITS Evolve, nút thắt cổ chai chuyển sang vòng lặp phản hồi. Tức là mô hình tạo ra sự biến đổi, nhưng hệ thống kiểm thử quyết định cái gì sẽ tồn tại.
Và với Helix, hệ thống Kafka mà chúng tôi đã build, nút thắt cổ chai lại dịch chuyển, nơi tác nhân có thể build phần lớn các hệ thống, như chúng ta đã thấy. Nhưng sau đó con người phải điều phối để đưa công việc vào môi trường sản phẩm thông qua các công cụ và cơ chế được build cho con người.
Đó chính là Định luật Amdahl mà Dario đã nói đến sáng nay.
Từ Cơ Giới Hóa đến Công Nghiệp Hóa: Nhu Cầu về Machine Tools cho Phần Mềm
Vì vậy, đó là bước nhảy vọt mà chúng ta đang thực hiện nếu bạn nhìn vào slide này ở trung tâm, từ cơ giới hóa sang công nghiệp hóa. Cơ giới hóa có nghĩa là tác nhân đang làm nhiều việc hơn bây giờ. Còn công nghiệp hóa, nếu mượn phép ẩn dụ này, và đó là lý do tại sao tôi giới thiệu machine tools, có nghĩa là công việc trở nên có thể lặp lại, có thể xác minh, có thể kiểm soát và có thể mở rộng (scalable).
Vậy ý tưởng về machine tool nghe có vẻ hay, nhưng tại sao chúng ta cần chúng bây giờ cho phần mềm được build bởi tác nhân? Hay chỉ cho các mô-đun hạ cánh lên mặt trăng? Là vì sự phức tạp và mơ hồ ngày càng tăng.
Mỗi lần chúng tôi cố gắng nâng cao mức độ tham vọng, bắt đầu từ những thay đổi có mục tiêu trên các hệ thống hiện có. Trong bốn tháng qua, khoảng 90% kỹ sư tại DataDog đã sử dụng các công cụ code AI cho code môi trường sản phẩm. Con số đó xấp xỉ 3.000 kỹ sư. Và Claude Code đã đóng góp ít nhất hai phần ba trong số đó. Và hầu hết công việc, như tôi đã mô tả về Helix, vẫn là do một người duy nhất điều khiển, giống như một kỹ sư điều khiển một hoặc nhiều phiên tác nhân.
Và công việc đang di chuyển trên bản đồ này, phức tạp hơn để tạo ra ở một trục và mơ hồ hơn để xác minh ở trục còn lại.
Dưới đây là một vài ví dụ cụ thể. Tôi sẽ không liệt kê tất cả, nhưng các bạn có thể chụp ảnh nếu thấy hữu ích. Và nếu bất kỳ điều nào trong số này gây được tiếng vang với các bạn, tôi rất vui được trò chuyện thêm sau này. Nhưng điểm chính tôi muốn nhấn mạnh ở đây là những điều này đang tạo ra các luồng công việc được cá nhân hóa trong chu trình phát triển phần mềm của chúng ta. Bởi vì một người có thể làm được nhiều hơn rất nhiều so với những gì họ từng làm trước đây.
Tác Động của Tác Nhân đến Chu Trình Phát Triển Phần Mềm
Đối với các kỹ sư trong chu trình phát triển phần mềm mà tôi đang nói đến, nếu tôi dùng từ "luồng công việc", nó từng có nghĩa là mối quan hệ trực tiếp giữa ý định và code. Bạn hiểu vấn đề. Bạn viết code. Bạn test nó. Bạn code review nó. Bạn triển khai nó. Bạn vận hành nó. Bạn lặp lại quá trình đó hết lần này đến lần khác.
Nhưng với tác nhân, mức độ trừu tượng đó đang thay đổi nhanh chóng. Tôi không biết. Tôi đã không nhìn thấy code. Ý tôi là, tôi đã không nhìn thấy code trong một thời gian rồi. Tôi đã chấp nhận điều đó vì tôi đã làm quản lý một thời gian. Nhưng nhiều người, họ vẫn đang cố gắng trải qua bảy giai đoạn đau buồn vì không nhìn thấy code hàng ngày.
Vì vậy, bạn không còn viết code nữa. Bạn đang định hình công việc. Bạn đang quyết định tác nhân nên thấy gì. Chúng ta đã thấy các bài phát biểu chính hôm nay, về các outcome. Tác nhân nên có những tool nào, thành công nghĩa là gì, làm thế nào để phát hiện thất bại. Tất cả những điều này đều mạnh mẽ. Nó giống như mọi người được thăng ba cấp lên chuỗi quản lý, điều mà các kỹ sư không hề mong muốn.
Bởi vì đây là một bước nhảy vọt lớn, và nó cũng gây mất phương hướng. Bạn đẩy chống lại trọng lực rất nhanh. Nó có thể gây chóng mặt. Chúng ta chưa thích nghi với độ cao làm việc này, đặc biệt là các kỹ sư yêu thích việc xem code.
Điểm Uốn và Vai Trò Mới của Con Người trong Kỷ Nguyên Tác Nhân
Vì vậy, trước bước nhảy vọt về khả năng của mô hình này, đội ngũ con người là nhà máy. Các tool được thiết kế xoay quanh sự chú ý, phán đoán của con người, và trí nhớ vận hành về những gì thực sự đang diễn ra trong môi trường sản phẩm nằm trong tổ chức con người này, trong bộ não tập thể, trong tâm trí của chúng ta. Quay trở lại với Courier, như tôi đã nói, chỉ 12 tháng trước, đây là thế giới mà chúng ta đang sống. Và chỉ bốn tháng trước, nó vẫn tiếp diễn, và sau đó bắt đầu thay đổi. Và đó là điểm uốn với Claude Code và Opus 45.
Chúng tôi bắt đầu thấy một người dẫn đầu điều phối nhiều phiên tương tác. Tôi đã thấy nhiều ảnh chụp màn hình về các phiên song song, tạo ra sản phẩm liên tục. Đối với cá nhân tôi, việc quan sát ba, bốn, năm tác nhân làm việc trên các phần khác nhau rất mất phương hướng. Tôi đã nghe Jarrett nói hôm nay rằng anh ấy đang làm 10 việc cùng một lúc. Giống như những gì cô ấy đang trình bày chỉ là 10% thời gian anh ấy đã dành ra.
Vì vậy, những tool này vẫn được thiết kế theo con người. Các tác nhân nhanh hơn hai bậc độ lớn, và chuỗi tool này được build để phù hợp với tốc độ của chúng.
Vì vậy, điều đã xảy ra là con người trở thành cầu nối giữa việc thực thi của tác nhân và các hệ thống được thiết kế theo con người. Và bây giờ, tất cả kiến thức vận hành này, ví dụ như bạn thức dậy giữa đêm vì có gì đó hỏng, nó chỉ nằm trong đầu của người đó. Và có lẽ trong một số tệp Markdown mà tác nhân ghi chép và chia sẻ với nhau.
Điều đó càng được khuếch đại với các tác nhân được quản lý trên Claude. Vì vậy, tác nhân đang thực hiện nhiều công việc nền hơn. Đó là tài nguyên tính toán. Và chúng bắt đầu đảm nhận các vai trò mang tính phán đoán. Có nghĩa là chúng không chỉ làm theo hướng dẫn của bạn nữa. Chúng đang tự đưa ra quyết định của mình. Và chúng chạy lâu hơn, hàng giờ, đôi khi qua đêm, đôi khi vài ngày. Tôi không biết, nhiệm vụ dài nhất, ai đó đã benchmark 20 giờ, 28 giờ.
Vì vậy, chúng tự xây dựng tool của riêng mình trong các phiên này. Chúng tự viết code của mình. Và sự không khớp vẫn còn đó, ví dụ như mỗi tác nhân tự phát minh ra tool riêng, glue code riêng, các quy ước riêng. Và hệ thống đó trở nên thực sự khó chia sẻ và vận hành. Bạn có thể thấy sự mơ hồ giữa những gì các phiên tác nhân tạo ra dưới dạng các tool trung gian và những gì sản phẩm của bạn đang làm, giống như code của bạn. Bạn nhận được rất nhiều output nhanh chóng.
Tamper - Công Cụ Máy Móc Cho Tác Nhân
Rất nhiều tiến bộ từ tác nhân là hữu ích, nhưng một số có thể chỉ là ảo ảnh của sự tiến bộ, và hầu hết việc xây dựng công cụ chỉ có ý nghĩa trong phiên cục bộ đó. Và bạn bắt đầu thấy sự mờ nhạt đó. Đây là lúc tôi cảm thấy chúng ta cần một cái gì đó có cấu trúc hơn. Nếu các tác nhân sẽ xây dựng và vận hành những phần lớn trong hệ thống của chúng ta, các cơ sở dữ liệu vốn quan trọng sống còn, chúng cần một thứ tương đương với khái niệm công cụ máy móc mà tôi đang cố gắng giới thiệu.
Vì vậy, Tamper là một công cụ máy móc. Ý tưởng là thay vì tác nhân tự tạo ra các công cụ không liên kết cho mọi nhu cầu cục bộ, nó tạo ra các đặc tả chính xác về ý định trên miền vấn đề. Nó là một công cụ máy móc theo cùng nghĩa với JIG hoặc máy CNC – bạn đã thấy một số máy gia công nóng hỗ trợ máy tính chưa, nơi bạn cung cấp cho chúng đặc tả về ren vít của bạn cần phải như thế nào, cái này cần phải ra sao – điều này cực kỳ lặp lại được. Bạn có thể vận hành chúng và bạn có thể xây dựng máy bay và những thứ tương tự bằng chúng. Trong trường hợp này, tác nhân không tự ứng biến cơ chế cuối cùng mỗi lần. Nó tạo ra một mô tả chính xác và nó lặp lại với Tamper hoặc một cơ chế tương tự Tamper để làm cho một cái gì đó hoạt động trước, và sau đó biến nó thành một cái gì đó có thể lặp lại, có thể kiểm tra và có thể tái sử dụng. Vì vậy, bạn thực sự có thể xây dựng một nhà máy phần mềm xung quanh code base của mình.
Khái Niệm Dark Factory
Đó là khái niệm Dark Factory. Simon Wilson của Simon Wilson.net, một blog khá ấn tượng. Tôi nghĩ ông ấy là một trong những tiếng nói AI có ảnh hưởng nhất hiện nay trong việc hướng dẫn cách làm việc với tác nhân và xây dựng phần mềm, đã phổ biến cụm từ này, gọi là Dark Factory. Tôi nghĩ đó là một sự gói gọn khá tốt về một quy trình phần mềm nơi các tác nhân tiếp tục làm việc mà không có con người trên sàn nhà máy ảo. Bạn có thể tắt đèn. Vì vậy, vai trò của con người bây giờ trở thành việc thiết kế nhà máy, các ràng buộc, các kết quả và vòng lặp xác minh. Vì vậy, thứ này có thể chạy hàng giờ, hàng ngày, hàng tuần, tạo ra những gì bạn muốn nó tạo ra. Vì vậy, một thứ như Tamper có thể lấp đầy vai trò của một công cụ máy móc để xây dựng những nhà máy như vậy.
Ứng Dụng Dark Factory Với Helix
Hãy xem xét một Dark Factory cụ thể với Helix làm mục tiêu. Những gì tôi đã chia sẻ về Helix: đó là một dịch vụ streaming giống như Kafka. Nó có lẽ là một trong năm dịch vụ đắt đỏ mà chúng tôi đang chạy tại DataDog. Giống như Kafka. Vì vậy, chúng tôi đã shadowing (theo dõi) tải công việc sản xuất của chúng tôi với Helix. Trong một số trường hợp, chúng tôi thực sự tin rằng nó có thể rẻ hơn đáng kể so với giải pháp sản xuất hiện tại của chúng tôi. Bạn có tin được không? Chúng tôi mất khoảng một tuần để xây dựng nó và chúng tôi bắt đầu shadowing nó, và chúng tôi thấy cơ hội tiết kiệm từ hai đến năm lần (2-5X). Nhưng để đi từ trạng thái hứa hẹn này đến môi trường sản phẩm vẫn cần nỗ lực. Hệ thống cần chứng minh rằng nó có thể chạy, và nhiều người có thể vận hành nó, không chỉ người đã xây dựng nó. Vì vậy, chúng tôi đã tạo ra một loạt tải công việc tổng hợp mô phỏng hình dạng sản xuất của chúng tôi. Và chúng tôi đã xây dựng một nhà máy.
Nhà máy phần mềm cho Helix sử dụng Tamper theo ba cách riêng biệt:
- Đầu tiên, như một
mặt phẳng điều khiển tác nhâncho cáctác nhânđược quản lý bởiClaude, nơi cácphiên,vai trò,hàng đợi công việcvàvòng đời hoạt độngđược quản lý chính xác hơn. - Thứ hai, như một cách để các
tác nhântựxây dựng công cụcủa chúng với cácứng dụng Tampernhỏ, cầu nốicông cụ STLCnhưGit,CIvàtriển khai. - Và thứ ba, như một
API điều khiển Helix,giao diệnvàdịch vụ vòng đờixung quanhmặt phẳng dữ liệu Helixđểthực thi tải công việcnày.
Đó là một bất ngờ đối với tôi. Bất ngờ là nó bắt đầu cảm thấy tổng quát hơn là chỉ cơ sở hạ tầng tác nhân. Rất nhiều phần mềm, nếu bạn nhìn kỹ, chỉ là logic điều khiển xung quanh cơ sở dữ liệu, API xung quanh trạng thái, chính sách xung quanh thay đổi trạng thái, chuyển đổi vòng đời, tích hợp với các hệ thống bên ngoài. Vì vậy, Tamper có thể là một công cụ phổ quát theo nghĩa nó có thể áp dụng cho bất kỳ phần mềm nào có hình dạng tôi mô tả.
So Sánh Tamper và Claude Code
Trước khi tôi đi sâu hơn vào cách Tamper hoạt động, bạn có thể tự hỏi tại thời điểm này, tại sao điều này lại khác với việc yêu cầu Claude Code xây dựng một ứng dụng CRUD, ví dụ bằng TypeScript hoặc Python? Claude có thể làm điều đó rất tốt. Chúng ta đã thấy rất nhiều yêu cầu kéo (PRs) và rất nhiều mã được tạo ra. Tuy nhiên, trong các ứng dụng CRUD thông thường, logic điều khiển được phân tán qua các tuyến đường (routes), ràng buộc cơ sở dữ liệu, mã dịch vụ, tác vụ nền và tài liệu. Tất cả có thể có kiểm thử tốt và phạm vi kiểm thử (coverage) tốt, nhưng mô hình hoạt động, thường có hình dạng máy trạng thái, chủ yếu là ngầm định trong code base.
Vì vậy, ý tưởng là Tamper làm cho máy trạng thái đó trở nên minh bạch. Điều này không đặc biệt mới lạ. Chúng ta đã có điều này với các runtime như Erlang, Erlang OTP trong nhiều thập kỷ, các runtime khác, và gần đây hơn với các công cụ luồng công việc và thực thi bền vững, các runtime như Temporal. Tất cả chúng đều đã phổ biến các runtime chính xác này, để bạn có thể chạy trong các ứng dụng có khả năng phục hồi cao.
Cấu Trúc Nội Bộ Của Tamper
Hãy xem xét một số chi tiết nội bộ của Tamper để hiểu rõ hơn. Trên đường dẫn xây dựng cho Tamper, nó yêu cầu miền vận hành này mà tôi đang mô tả về mô hình những gì bạn muốn dưới dạng một bản thiết kế (blueprint). Các trạng thái là gì, những chuyển đổi nào là hợp lệ, ai có thể yêu cầu chúng, những hiệu ứng nào được cho phép, những bất biến nào phải duy trì, điều gì xảy ra nếu một lời gọi công cụ (tool call) thất bại? Vì vậy, tác nhân sẽ thường lặp lại và đi đến bản thiết kế này, qua nhiều lượt. Hãy nghĩ nó như chế độ lập kế hoạch của riêng nó để đạt được, thay vì tạo ra một tệp Markdown mô tả nào đó, nó có thể tạo ra các hiện vật khai báo chính xác này. Và sau đó bạn có một trình biên dịch tương đương như Tamper, xác minh nó, và nó có thể triển khai nóng (hot deploy) vào một runtime. Có các runtime khác làm điều này, như Erlang Beam làm điều đó nếu bạn đã từng nghe nói về nó, có ai đã nghe nói về Erlang Beam chưa? Đó.
Vì vậy, đường dẫn chạy (run path) cảm thấy giống như bất kỳ API có hình dạng CRUD nào khác. Bạn sẽ nhận thấy sự khác biệt. Điều quan trọng cần lưu ý là tác nhân không tạo mã ứng dụng tùy ý trực tiếp. Chúng ta đã nâng cao mức trừu tượng. Nó đang tạo ra một mô tả có cấu trúc được biên dịch thành hình dạng runtime của chúng ta. Bước biên dịch nằm ngoài bước kia. Nó giống như bạn viết mã Rust và bạn đưa nó cho trình biên dịch Rust.
Tamper biến bản thiết kế này thành một thứ gọi là chuyển đổi trạng thái hình thức (formal state transitions). Điều này rất phổ biến trong lập trình hàm và runtime actor nếu bạn đã sử dụng chúng. Đây là chi tiết kỹ thuật quan trọng nhất. Hình thức ở đây không có nghĩa là mọi thuộc tính có thể được chứng minh. Nó không phải là lý thuyết. Nó có nghĩa là hình dạng cơ bản của ứng dụng được biểu diễn như một hệ thống chuyển đổi chính xác. Và khi bạn có điều đó, đó là một lý luận tốt hơn nhiều cho cả con người và tác nhân so với mã tùy ý.
Thứ lỗi cho thiết kế brutalist hoàn toàn của slide này không có tô màu cú pháp. Nhưng đó là một tác nhân kiểm tra cho một rollout Helix. Đặc tả đó trông như thế này: Trạng thái, hành động và kích hoạt. Tôi thực sự đã có một ý tưởng sáng nay khi tôi thấy thông báo về các kích hoạt được quản lý trên Claude. Có lẽ đây chỉ có thể là một pass through (truyền qua). Bạn có thể khai báo một kích hoạt ở đây và sau đó để Claude chạy chúng. Nhưng ý tưởng là bạn xác định hành động và kích hoạt trạng thái của mình, hoặc tác nhân làm điều đó, Claude làm điều đó. Và trong trường hợp này, ví dụ, mô tả triển khai bắt đầu rollout chỉ hợp lệ khi đã lên kế hoạch hoặc thực thể chuyển sang trạng thái rolling. Và điều đó kích hoạt một tác dụng phụ như đi và vá Kubernetes stateful set, điều đó không quan trọng. Và sau đó là một callback quay lại để đánh dấu tiến độ hoặc thất bại.
Những gì Tamper làm, hiện vật đó là khai báo. Vì vậy, những gì Tamper làm, nó lấy cái này và tạo ra đặc tả đó thành bảng chuyển đổi này, một khái niệm nơi logic điều khiển quan trọng giống như dữ liệu. Nó không chỉ là mã spaghetti được mã hóa một cách mệnh lệnh (imperatively encoded) trong code. Nó giống như dữ liệu có thể trao đổi, không thể kiểm tra. Và nó không bị ẩn trong bất kỳ chuỗi phương thức dịch vụ tự ứng biến nào. Điều này dễ dàng hơn cho các tác nhân làm việc. Và chúng có thể thay đổi điều này một cách linh hoạt với an toàn. Đó là lời hứa. Tôi đã thấy mọi người viết script Erlang và triển khai nóng (hot deploying) vào Beam. Tôi nghĩ đó là một cách sáng tạo để sử dụng các runtime đã được củng cố cực kỳ trên các hệ thống đảm bảo cao hơn để các tác nhân làm việc. Vì vậy, trong trường hợp này, nếu một rollout cần một trạng thái mới hoặc đường dẫn rollback, tác nhân có thể thực hiện một thay đổi đặc tả có mục tiêu, và nó có thể tải lại nóng (hot reload) nó. Vì vậy, tốc độ lặp lại thậm chí còn nhanh. Bạn không phải trải qua CI và triển khai và mọi thứ. Khi bạn để tác nhân chạy qua đêm, tôi nghĩ chúng có thể đạt được một số tiến bộ khá tốt qua đêm mà không ảnh hưởng đến an toàn, đánh giá yêu cầu kéo (PR review) và đánh giá mã (code review) và những thứ tương tự.
Cổng Chính Sách và Hệ Thống Hiệu Ứng
Và chúng ta có cổng chính sách (policy gates). Bởi vì bảng chuyển đổi giống như dữ liệu, Tamper đánh giá các chuyển đổi trạng thái và quyết định chính sách cùng nhau như: ai có thể thay đổi một triển khai rollout? Những hành động nào mà một tác nhân vận hành (operator agent), giống như nhóm các tác nhân đang làm việc trên Dark Factory? Bạn có thể nói các tác nhân vận hành này chỉ có thể làm được bấy nhiêu. Hoặc những hành động này bị cấm đối với một tác nhân xây dựng (builder agent). Và bạn có thể chỉ định độc lập như một con người rằng một rollout đã hoàn thành có thể được rollout lại hay không, hoặc một kết quả công cụ thất bại (fail tool result) có thể tiếp tục trên đường dẫn rollout của nó, v.v.
Và sau đó chúng ta có tác dụng phụ (side effects) và hệ thống hiệu ứng (effect system), cũng rất phổ biến và các runtime có kiểu dữ liệu (typed runtimes) như TypeScript. Hiệu ứng là các thao tác có kiểu dữ liệu nhỏ một cách có chủ đích ở đây trong Tamper. Giữ chúng nhỏ ngăn máy trạng thái trở thành một cửa hậu cho hành vi ứng dụng tùy ý. Nhưng nếu bạn cần hành vi ứng dụng tùy ý, bạn có thể đóng gói chúng dưới dạng các module Wasm, quen thuộc với Wasm? Thôi nào. Được rồi, vài người giơ tay. Vì vậy, đây là nơi báo cáo của chúng ta được tạo bởi một LLM có thể để lại. Đó là một nơi làm việc rất hạn chế. Điều đó có nghĩa là nó giúp khắc phục sự cố (troubleshooting) dễ dàng hơn.
Bộ Xác Minh (Verifier)
Khối xây dựng cuối cùng cho Tamper là bộ xác minh (verifier). Xác minh về cơ bản là nút thắt cổ chai (bottleneck) hiện tại cho gần như mọi thứ. Chúng ta đã thấy rất nhiều thông báo và thảo luận xung quanh nó. Vì vậy, trong Tamper, bộ xác minh là một cổng trước khi bảng chuyển đổi được tải vào các runtime. Đó là điều cho phép nó nói rằng điều này là an toàn. Bạn có thể đặt cái này và tải trực tiếp (load it live). Và nó có nhiều cấp độ giống như một kiểu pho mát Thụy Sĩ (Swiss cheese pattern). Không phải tất cả các cấp độ đều cần tìm mọi thứ một cách đầy đủ. Tác nhân (Claude) nói chung rất giỏi trong việc đưa ra phán đoán. Tôi có cần chạy tất cả các cấp độ hay chỉ một số cấp độ giống như cách nó sử dụng đầu ra trình biên dịch của nó? Ví dụ, cấp độ một kiểm tra đại số của tự động hóa. Mô hình cấp độ hai kiểm tra biểu đồ trạng thái có thể truy cập (reachable state graph). Có bất kỳ đường dẫn nào có thể đạt đến trạng thái xấu không? Và cấp độ ba chạy các lịch trình, tiêm lỗi, các bất biến có tồn tại qua các điều kiện lỗi thời gian và v.v.. Và cấp độ bốn sử dụng kiểm thử thuộc tính (property tests) mà tôi thực sự khuyến khích chúng ta phải bắt đầu học cơ chế này của kiểm thử ngẫu nhiên với chuỗi hành động.
Tất cả những điều này không đầy đủ ngay từ ngày đầu tiên. Mọi khoảng trống khám phá đều gia tăng bộ xác minh. Tôi cũng nghe Boris đề cập đến hiệu ứng tích lũy (compounding effect) của việc bạn tìm kiểm thử và bạn tiếp tục sửa lỗi các khoảng trống. Một điều kiện bị thiếu được tiết lộ trong môi trường sản phẩm hoặc mô phỏng có thể được thêm vào mô hình hoặc bộ kiểm thử. Và nó gia tăng.
Vì vậy, tất cả những điều này đang diễn ra. Tôi không biết. Ý tôi là tôi không thể dự đoán nhiều về nơi điều này có thể đi đến. Nhưng ý tưởng là nếu mỗi hiện vật của ứng dụng Tamper hoặc một bundle là ngắn gọn, rất ít dòng, vừa vặn trong đầu bạn. Tôi đã dành rất nhiều thời gian vận hành cơ sở hạ tầng quan trọng sống còn cho DataDog thức dậy vào ban đêm hàng ngàn lần trong ba hoặc bốn năm qua. Bạn sẽ không thể giữ logic quan trọng sống còn phức tạp trong đầu khi bạn muốn vận hành nó đúng cách cho một miền kinh doanh phức tạp như ngân hàng hoặc hệ thống tài chính. Bạn vẫn nên có thể mã hóa logic kinh doanh của mình theo cách này. Một cái gì đó mà con người có thể đọc. Nếu hiện vật được tạo là hàng ngàn dòng mã lộn xộn, chúng ta lại quay về nơi chúng ta bắt đầu. Và tôi chưa hoàn toàn biết liệu một LLM có thể hoàn toàn đánh giá và sau đó ký duyệt vào nó hay không. Nếu đó là một vài hiện vật nhỏ với vai trò rõ ràng khi cả con người và tác nhân có thể sửa đổi hệ thống mà không làm xáo trộn mọi thứ xung quanh nó. Tôi vẫn cảm thấy đây chỉ là kỹ thuật hệ thống tốt và phần mềm có độ đảm bảo cao hơn như trong hàng không và hệ thống tài chính đã được xây dựng theo cách này trong nhiều thập kỷ. Tuy nhiên, chi phí của sự nghiêm ngặt như vậy với con người là quá cao đối với phần mềm chung cho đến nay. Các tác nhân đang thay đổi phép tính đó.
Từ ẩn dụ sản xuất đến quy trình phát triển phần mềm
Quay trở lại ẩn dụ về sản xuất của tôi, chiến thắng không phải là một nghệ nhân có thể chế tạo một cỗ máy xuất sắc. Chiến thắng thực sự là một cỗ máy được build (xây dựng) bằng machine tools đã tạo ra các bộ phận có thể kết hợp, kiểm tra được và thay thế, nhờ đó chúng ta có thể build (xây dựng) những cỗ máy lớn hơn. Và lập luận của tôi là, đối với phần mềm — khi tác nhân build (xây dựng) phần mềm — chúng ta cần một mức độ chặt chẽ như vậy để có thể mở rộng quy mô từ đây, nếu chúng ta thực sự muốn build (xây dựng) cơ sở dữ liệu và đưa chúng vào môi trường sản phẩm / sản xuất.
Tầm quan trọng của kỷ luật và sự chặt chẽ với tác nhân
Tôi đã nhận ra điều này ngay từ đầu. Nếu tác nhân có thể tự động build (xây dựng) phần mềm trong các nhà máy với kỷ luật và sự chặt chẽ như vậy, có lẽ, chỉ có lẽ, chúng ta không cần phải dừng lại ở các "nhà máy tối" (dark factories). Tôi không biết liệu có điều gì "tối" ở đó không; nghe có vẻ hơi buồn.
Phát triển phần mềm như một sinh vật sống
Vì vậy, toàn bộ phần mềm được build (xây dựng) theo cách này có thể giống như một sinh vật mà chúng ta có thể phát triển, nuôi dưỡng và tiến hóa thông qua phản hồi, chọn lọc và thích nghi. Nó giống như, tôi không biết, nông nghiệp hoặc một quá trình tiến hóa có định hướng, nơi bạn chọn hướng mà phần mềm của bạn cần phát triển.
Tầm nhìn tương lai và kết luận
Bạn có thể chọn Kafka làm một hàng đợi (queue) vì có nhiều khách hàng sử dụng nó như một hàng đợi thay vì nói "không, chúng ta cần nhiều buffers hơn. Chúng ta không cần tất cả các brokers này." Hoặc có lẽ tôi chỉ đang mơ, phải không? Giờ đây, chúng ta có những giấc mơ trong đám mây. Đó là tất cả những gì tôi muốn chia sẻ. Cảm ơn rất nhiều vì đã lắng nghe.
TL;DR
- Sự phát triển của các mô hình ngôn ngữ lớn (LLMs) như Claude Code đã dịch chuyển đáng kể tốc độ phát triển phần mềm, cho phép các kỹ sư đơn lẻ xây dựng các hệ thống phân tán phức tạp như Kafka (
Helix) chỉ trong vài ngày. - Việc phát triển nhanh chóng bằng tác nhân AI đã chuyển các nút thắt cổ chai từ viết mã thủ công sang các thách thức về vận hành, phối hợp con người, và xác minh sự phù hợp của sản phẩm được tạo ra bởi tác nhân để triển khai vào môi trường sản phẩm.
- Để giải quyết vấn đề này, bài nói đề xuất khái niệm "công cụ máy móc" (
Tamper) cho tác nhân và "nhà máy tối" (Dark Factory), nhằm cung cấp cấu trúc, khả năng lặp lại và kiểm soát cho quá trình phát triển phần mềm do tác nhân điều khiển, giúp chuyển đổi từ cơ giới hóa sang công nghiệp hóa phần mềm.
Điểm chính
- LLMs cho phép phát triển nhanh chóng các hệ thống phân tán phức tạp; ví dụ, xây dựng một dịch vụ streaming tương đương Kafka (
Helix) chỉ trong vài ngày với một kỹ sư duy nhất. - Chiến lược tối ưu hóa tiến hóa (ví dụ:
BITS Evolve) hiệu quả hơn khi được áp dụng cho các khối mã hoặc hàm mục tiêu hẹp, thay vì toàn bộ hệ thống lớn do bề mặt phức tạp và mơ hồ quá rộng. - Sự gia tăng năng lực của tác nhân AI đã dịch chuyển nút thắt cổ chai trong phát triển phần mềm từ quá trình xây dựng mã sang giai đoạn điều phối của con người để đưa sản phẩm vào môi trường thực tế và tích lũy kinh nghiệm vận hành.
- Các tác nhân AI thường tự tạo ra các công cụ, mã kết nối và quy ước riêng lẻ trong mỗi phiên, dẫn đến kiến thức vận hành bị phân mảnh và khó chia sẻ, khiến việc duy trì hệ thống trở nên phức tạp.
- Khái niệm "công cụ máy móc" (
machine tools) cho tác nhân (ví dụ:Tamper) là cần thiết để chuẩn hóa và cấu trúc hóa quá trình tác nhân tạo công cụ, chuyển các cơ chế ứng biến thành các đặc tả ý định chính xác, có thể lặp lại và kiểm thử được. - "Nhà máy tối" (
Dark Factory) đại diện cho một quy trình phần mềm nơi tác nhân hoạt động tự động và liên tục mà không cần sự can thiệp trực tiếp của con người, đòi hỏi con người phải tập trung vào thiết kế nhà máy, các ràng buộc và vòng lặp xác minh. - Việc triển khai
Tampertrong "nhà máy tối" cho phép quản lý chính xác hơn các phiên tác nhân (mặt phẳng điều khiển tác nhân), cấu trúc hóa quá trình tự tạo công cụ của tác nhân, và quản lý chuỗi xác minh cho các thành phần phần mềm. - Hệ thống được xây dựng bằng AI có tiềm năng tiết kiệm chi phí đáng kể (ví dụ:
Helixcó thể rẻ hơn 2-5 lần so với giải pháp hiện có), nhưng cần nỗ lực để chứng minh sự ổn định vận hành trước khi triển khai sản phẩm.
Từ vựng
machine tools— công cụ máy mócbuild— xây dựng / phát triểntest— kiểm thửglue code— mã kết nốitác nhân— agentmôi trường sản phẩm— production environmentnút thắt cổ chai— bottleneckscalable— có thể mở rộngDark Factory— nhà máy tốiđặc tả— specification
Nội dung chi tiết
Lời Giới Thiệu và Nguồn Cảm Hứng
Xin chào Sesh Malah, Phó chủ tịch (VP) tại DataDog. Tôi để ý bây giờ là 4 giờ chiều. Năng lượng của mọi người thế nào rồi? Từ đầu đến giờ, các bạn thấy hội nghị ra sao? Tuyệt vời. Được rồi. Hãy cùng nhau khơi dậy chút khí thế nào.
Vậy xin cho tôi thấy cánh tay của những ai đã từng nghe về machine tools trước đây. Những gì trên slide này, các bạn đã dùng cái nào chưa? Dù sao thì tôi cũng dự đoán là không có ai giơ tay cả. Dù sao thì đây vẫn sẽ là chủ đề của bài nói.
Machine tools là các công cụ như Jigs, fixtures, gauges và mills mà các bạn thấy trong ngành sản xuất để tạo ra các bộ phận máy móc chính xác và có thể lặp lại. Những bộ phận này được lắp ráp thành các cỗ máy lớn hơn như động cơ, máy bay, lò phản ứng hạt nhân, các mô-đun hạ cánh lên mặt trăng mà chúng ta đã thấy sáng nay. Machine tools là một bước đột phá trong thời kỳ công nghiệp hóa, cho phép mở rộng quy mô nhờ khả năng hoán đổi cho nhau thông qua tiêu chuẩn hóa và độ chính xác.
Đó chính là nguồn cảm hứng cho bài nói của tôi và cho những gì chúng tôi đã build tại DataDog. Tôi sẽ chia sẻ với các bạn cách tất cả những điều này phù hợp với việc build phần mềm bằng Claude Code.
Hành Trình với Mô Hình Ngôn Ngữ Lớn: Từ Giới Hạn đến Tham Vọng
Vậy những gì các bạn đang thấy trên slide là cái nhìn của tôi về 18 tháng qua. Tôi nghĩ rằng có nhiều góc nhìn khác nhau về biểu đồ này trong nhiều phiên hôm nay. Những nhận định phi khoa học này, xin đừng coi đây là đánh giá chính thức của tôi. Đây hoàn toàn là quan điểm cá nhân. Nhưng đó là câu chuyện về tham vọng với các mô hình. Trong phần lớn năm 2025, các mô hình hữu ích đối với tôi, nhưng trong giới hạn rất hẹp, như các thay đổi cục bộ, các hàm nhỏ, test, glue code, các prototype dùng một lần để tôi học hỏi rất nhiều từ chúng.
Sau đó, vào khoảng cuối năm 2025, tôi nghĩ tất cả các bạn đều đã thấy điều này khi độ dốc bắt đầu thay đổi, giống như một tăng trưởng theo cấp số nhân. Tôi bắt đầu tin tưởng Claude với các công việc code hệ thống lớn hơn và mơ hồ hơn.
Những Ý Tưởng Dẫn Lối: Từ Hệ Thống Phân Tán Cổ Điển đến Tối Ưu Hóa Tiến Hóa
Trước khi nói về machine tools, tôi muốn điểm qua một số ý tưởng đã dẫn tôi đến đây. Đây là năm 2024. Đây là một bài viết. Chúng tôi đã build một hệ thống hàng đợi phân tán tên là Courier từ đầu. Tất cả những việc này đều diễn ra trước thời đại của tác nhân, mọi thứ đều được thực hiện thủ công. Chúng ta có thể tin được không? Phần mềm vẫn được build bằng tay vào thời điểm đó. Phần khó khăn là, đối với bất kỳ hệ thống phân tán nào được con người hoặc tác nhân build, không chỉ là build các phần mà còn là build các mảnh ghép và làm cho sự tương tác giữa chúng có thể quan sát được, có thể test được và có thể xác minh được.
Vì vậy, chúng tôi rất nghiêm ngặt với việc mô hình hóa chính thức và mô phỏng. Các bạn sẽ thấy nhiều kỹ thuật khác nhau trong bài đăng này. Tất cả những điều này là công việc hệ thống cổ điển, nơi bạn xác định các phần mà lỗi có thể tốn kém hoặc khó đảo ngược, và bạn nâng cao sự nghiêm ngặt cho những phần đó mà bạn không muốn chúng trượt vào môi trường sản phẩm.
Ý tưởng tiếp theo xuất hiện vào khoảng tháng 9 năm 2025, chúng tôi gọi nó là BITS Evolve. Đây là một hệ thống tối ưu hóa tiến hóa vòng kín, lấy cảm hứng từ AlphaEvolve của DeepMind. Ý tưởng là bạn để các phần code tự cải thiện trong một môi trường được kiểm soát chặt chẽ. Tôi nghĩ chúng ta đã thấy một số thông báo hôm nay tại bài phát biểu chính về dreaming và các vòng lặp khác nhau. Vì vậy, đây là những gì chúng tôi đã thử vào tháng 9 năm 2025. Đó là một tập hợp hoặc một hội đồng các mô hình, lớn và nhỏ, và chúng tạo ra các biến thể code, bất kể bạn chỉ định cái gì bạn muốn chúng cải thiện. Trong trường hợp của chúng tôi, đó là các hàm khó, các khối code. Và sau đó bạn có một chuỗi kiểm tra mà bạn thấy ở phía bên phải màn hình với các benchmark, test và khả năng quan sát môi trường sản phẩm để quyết định cái gì sẽ tồn tại. Nó giống như chọn lọc tự nhiên.
Vì vậy, đây là cái nhìn đầu tiên đối với tôi rằng các phần mềm có thể được nuôi dưỡng, giống như các sinh vật sống, như thực vật, hoặc như vi sinh vật, và phát triển thông qua sự biến đổi với phản hồi và thích nghi.
Tuy nhiên, điều tôi nhận ra là kiểu tiến hóa này chỉ tốt khi môi trường nó thích nghi tốt. Nếu bạn có benchmark kém, chúng sẽ tạo ra những sự tiến hóa kém. Khả năng quan sát yếu, các tối ưu hóa của bạn sẽ nông cạn.
Xây Dựng Hệ Thống Lớn với Claude Code và Thách Thức
Sau đó, trong giai đoạn đột phá hoặc tăng trưởng theo cấp số nhân bắt đầu, chúng tôi đã build toàn bộ hệ thống phân tán bằng Claude Code. Tôi đã đề cập đến điểm uốn Opus 45, nơi tôi nâng cao tham vọng của mình. Nó không phải là đột ngột. Tôi không thức dậy một ngày và sau đó bắt đầu tin tưởng Claude với toàn bộ hệ thống, hoặc thậm chí là cơ sở dữ liệu của mình. Chúng tôi có rất nhiều trong số đó. Nó diễn ra dần dần. Tôi đã thử các nhiệm vụ khó hơn và các hệ thống con lớn hơn, thất bại rất nhiều, học hỏi rất nhiều qua nhiều thử nghiệm, và sau đó bắt đầu thấy thành công vào khoảng thời gian này.
Vì vậy, chúng tôi quyết định tham vọng hơn, liệu chúng ta có thể build một thứ gì đó lớn như Kafka không? Xin cho tôi thấy cánh tay của những ai đã nghe về Kafka. OK, bây giờ thì nhiều cánh tay hơn. Kafka là một dịch vụ streaming. Vì vậy, chúng tôi đã thử, liệu chúng ta có thể build nó từ đầu không? Nó giống như lặp lại cùng một chiến lược mà chúng tôi đã có cho Courier. Đó là một hệ thống hàng đợi, khá gần. Với sự nghiêm ngặt tương tự. Vì vậy, các bạn sẽ thấy chuỗi kiểm tra ở phía bên phải của slide này. Nhưng Claude Code thực hiện hầu hết việc xây dựng với một người duy nhất build nó. Trong vài ngày, với niềm tin của anh ấy, chúng tôi đã có một hệ thống hoạt động đầy đủ chức năng, có thể so sánh với Kafka. Và chúng tôi gọi nó là Helix. Vì vậy, phương pháp mã nguồn và chi tiết đều được liên kết trong bài đăng này. Mọi người có thể xem sau. Nhưng để đưa Helix vào môi trường sản phẩm bây giờ đòi hỏi phải tích lũy kinh nghiệm vận hành, và điều đó đã trở thành thách thức đối với chúng tôi.
Vì vậy, bước đi tự nhiên tiếp theo của chúng tôi là, tôi đã nói về BITS Evolve trước đó. Liệu BITS Evolve có thể phát triển các phần của Helix, theo cách nó đã phát triển các hàm quan trọng không? Tham vọng giống như hai viên gạch lớn, từ các hàm nhỏ đến việc liệu toàn bộ thành phần có thể phát triển không? Liệu nó có thể cung cấp kinh nghiệm vận hành mà chúng tôi cần để đưa vào môi trường sản phẩm không? Câu trả lời là không hoàn toàn. Bề mặt quá lớn. Ngay cả với chuỗi xác minh mà tôi đã chỉ cho các bạn trong slide trước, khá nghiêm ngặt, vẫn có quá nhiều nơi con người phải diễn giải và sửa chữa. Nó quá nhiều lượt tương tác.
Vì vậy, bạn nghĩ, OK, liệu chúng ta có thể tìm kiếm một bề mặt hẹp hơn không? Liệu chúng ta có thể giảm bớt tham vọng một chút không? Bài đăng này nói về điều đó. Vì vậy, chúng tôi đã chọn máy chủ tổng hợp số liệu của mình. Chúng tôi là DataDog, vì vậy chúng tôi có rất nhiều số liệu. Liệu chúng ta có thể cải thiện logic vật chất hóa trực tiếp, không ngoại tuyến, như những gì chúng ta đã làm với BITS Evolve trước đây không? Liệu chúng ta có thể tối ưu hóa chúng cho khách hàng với một proof carrying path xung quanh sự thay đổi không? Để con người không phải code review mọi ứng viên được tạo ra.
Sự Dịch Chuyển của Nút Thắt Cổ Chai và Định Luật Amdahl
Nếu bạn nhìn vào luồng công việc qua bốn dự án này, nếu bạn quan sát mẫu hình, mỗi dự án đều phơi bày nút thắt cổ chai cho dự án tiếp theo. Hôm nay có nhiều bài nói và bình luận về việc nút thắt cổ chai đang được di chuyển.
Với Courier, nút thắt cổ chai là quá trình xây dựng với con người build hệ thống thông qua thiết kế, mô hình hóa và xác minh cẩn thận. Chúng tôi mất một năm để build Courier. Và sau đó nếu so sánh, chỉ mất ba ngày để build một hệ thống tương tự Kafka. Trong khoảng thời gian nào? Chỉ trong vài tháng.
Với BITS Evolve, nút thắt cổ chai chuyển sang vòng lặp phản hồi. Tức là mô hình tạo ra sự biến đổi, nhưng hệ thống kiểm thử quyết định cái gì sẽ tồn tại.
Và với Helix, hệ thống Kafka mà chúng tôi đã build, nút thắt cổ chai lại dịch chuyển, nơi tác nhân có thể build phần lớn các hệ thống, như chúng ta đã thấy. Nhưng sau đó con người phải điều phối để đưa công việc vào môi trường sản phẩm thông qua các công cụ và cơ chế được build cho con người.
Đó chính là Định luật Amdahl mà Dario đã nói đến sáng nay.
Từ Cơ Giới Hóa đến Công Nghiệp Hóa: Nhu Cầu về Machine Tools cho Phần Mềm
Vì vậy, đó là bước nhảy vọt mà chúng ta đang thực hiện nếu bạn nhìn vào slide này ở trung tâm, từ cơ giới hóa sang công nghiệp hóa. Cơ giới hóa có nghĩa là tác nhân đang làm nhiều việc hơn bây giờ. Còn công nghiệp hóa, nếu mượn phép ẩn dụ này, và đó là lý do tại sao tôi giới thiệu machine tools, có nghĩa là công việc trở nên có thể lặp lại, có thể xác minh, có thể kiểm soát và có thể mở rộng (scalable).
Vậy ý tưởng về machine tool nghe có vẻ hay, nhưng tại sao chúng ta cần chúng bây giờ cho phần mềm được build bởi tác nhân? Hay chỉ cho các mô-đun hạ cánh lên mặt trăng? Là vì sự phức tạp và mơ hồ ngày càng tăng.
Mỗi lần chúng tôi cố gắng nâng cao mức độ tham vọng, bắt đầu từ những thay đổi có mục tiêu trên các hệ thống hiện có. Trong bốn tháng qua, khoảng 90% kỹ sư tại DataDog đã sử dụng các công cụ code AI cho code môi trường sản phẩm. Con số đó xấp xỉ 3.000 kỹ sư. Và Claude Code đã đóng góp ít nhất hai phần ba trong số đó. Và hầu hết công việc, như tôi đã mô tả về Helix, vẫn là do một người duy nhất điều khiển, giống như một kỹ sư điều khiển một hoặc nhiều phiên tác nhân.
Và công việc đang di chuyển trên bản đồ này, phức tạp hơn để tạo ra ở một trục và mơ hồ hơn để xác minh ở trục còn lại.
Dưới đây là một vài ví dụ cụ thể. Tôi sẽ không liệt kê tất cả, nhưng các bạn có thể chụp ảnh nếu thấy hữu ích. Và nếu bất kỳ điều nào trong số này gây được tiếng vang với các bạn, tôi rất vui được trò chuyện thêm sau này. Nhưng điểm chính tôi muốn nhấn mạnh ở đây là những điều này đang tạo ra các luồng công việc được cá nhân hóa trong chu trình phát triển phần mềm của chúng ta. Bởi vì một người có thể làm được nhiều hơn rất nhiều so với những gì họ từng làm trước đây.
Tác Động của Tác Nhân đến Chu Trình Phát Triển Phần Mềm
Đối với các kỹ sư trong chu trình phát triển phần mềm mà tôi đang nói đến, nếu tôi dùng từ "luồng công việc", nó từng có nghĩa là mối quan hệ trực tiếp giữa ý định và code. Bạn hiểu vấn đề. Bạn viết code. Bạn test nó. Bạn code review nó. Bạn triển khai nó. Bạn vận hành nó. Bạn lặp lại quá trình đó hết lần này đến lần khác.
Nhưng với tác nhân, mức độ trừu tượng đó đang thay đổi nhanh chóng. Tôi không biết. Tôi đã không nhìn thấy code. Ý tôi là, tôi đã không nhìn thấy code trong một thời gian rồi. Tôi đã chấp nhận điều đó vì tôi đã làm quản lý một thời gian. Nhưng nhiều người, họ vẫn đang cố gắng trải qua bảy giai đoạn đau buồn vì không nhìn thấy code hàng ngày.
Vì vậy, bạn không còn viết code nữa. Bạn đang định hình công việc. Bạn đang quyết định tác nhân nên thấy gì. Chúng ta đã thấy các bài phát biểu chính hôm nay, về các outcome. Tác nhân nên có những tool nào, thành công nghĩa là gì, làm thế nào để phát hiện thất bại. Tất cả những điều này đều mạnh mẽ. Nó giống như mọi người được thăng ba cấp lên chuỗi quản lý, điều mà các kỹ sư không hề mong muốn.
Bởi vì đây là một bước nhảy vọt lớn, và nó cũng gây mất phương hướng. Bạn đẩy chống lại trọng lực rất nhanh. Nó có thể gây chóng mặt. Chúng ta chưa thích nghi với độ cao làm việc này, đặc biệt là các kỹ sư yêu thích việc xem code.
Điểm Uốn và Vai Trò Mới của Con Người trong Kỷ Nguyên Tác Nhân
Vì vậy, trước bước nhảy vọt về khả năng của mô hình này, đội ngũ con người là nhà máy. Các tool được thiết kế xoay quanh sự chú ý, phán đoán của con người, và trí nhớ vận hành về những gì thực sự đang diễn ra trong môi trường sản phẩm nằm trong tổ chức con người này, trong bộ não tập thể, trong tâm trí của chúng ta. Quay trở lại với Courier, như tôi đã nói, chỉ 12 tháng trước, đây là thế giới mà chúng ta đang sống. Và chỉ bốn tháng trước, nó vẫn tiếp diễn, và sau đó bắt đầu thay đổi. Và đó là điểm uốn với Claude Code và Opus 45.
Chúng tôi bắt đầu thấy một người dẫn đầu điều phối nhiều phiên tương tác. Tôi đã thấy nhiều ảnh chụp màn hình về các phiên song song, tạo ra sản phẩm liên tục. Đối với cá nhân tôi, việc quan sát ba, bốn, năm tác nhân làm việc trên các phần khác nhau rất mất phương hướng. Tôi đã nghe Jarrett nói hôm nay rằng anh ấy đang làm 10 việc cùng một lúc. Giống như những gì cô ấy đang trình bày chỉ là 10% thời gian anh ấy đã dành ra.
Vì vậy, những tool này vẫn được thiết kế theo con người. Các tác nhân nhanh hơn hai bậc độ lớn, và chuỗi tool này được build để phù hợp với tốc độ của chúng.
Vì vậy, điều đã xảy ra là con người trở thành cầu nối giữa việc thực thi của tác nhân và các hệ thống được thiết kế theo con người. Và bây giờ, tất cả kiến thức vận hành này, ví dụ như bạn thức dậy giữa đêm vì có gì đó hỏng, nó chỉ nằm trong đầu của người đó. Và có lẽ trong một số tệp Markdown mà tác nhân ghi chép và chia sẻ với nhau.
Điều đó càng được khuếch đại với các tác nhân được quản lý trên Claude. Vì vậy, tác nhân đang thực hiện nhiều công việc nền hơn. Đó là tài nguyên tính toán. Và chúng bắt đầu đảm nhận các vai trò mang tính phán đoán. Có nghĩa là chúng không chỉ làm theo hướng dẫn của bạn nữa. Chúng đang tự đưa ra quyết định của mình. Và chúng chạy lâu hơn, hàng giờ, đôi khi qua đêm, đôi khi vài ngày. Tôi không biết, nhiệm vụ dài nhất, ai đó đã benchmark 20 giờ, 28 giờ.
Vì vậy, chúng tự xây dựng tool của riêng mình trong các phiên này. Chúng tự viết code của mình. Và sự không khớp vẫn còn đó, ví dụ như mỗi tác nhân tự phát minh ra tool riêng, glue code riêng, các quy ước riêng. Và hệ thống đó trở nên thực sự khó chia sẻ và vận hành. Bạn có thể thấy sự mơ hồ giữa những gì các phiên tác nhân tạo ra dưới dạng các tool trung gian và những gì sản phẩm của bạn đang làm, giống như code của bạn. Bạn nhận được rất nhiều output nhanh chóng.
Tamper - Công Cụ Máy Móc Cho Tác Nhân
Rất nhiều tiến bộ từ tác nhân là hữu ích, nhưng một số có thể chỉ là ảo ảnh của sự tiến bộ, và hầu hết việc xây dựng công cụ chỉ có ý nghĩa trong phiên cục bộ đó. Và bạn bắt đầu thấy sự mờ nhạt đó. Đây là lúc tôi cảm thấy chúng ta cần một cái gì đó có cấu trúc hơn. Nếu các tác nhân sẽ xây dựng và vận hành những phần lớn trong hệ thống của chúng ta, các cơ sở dữ liệu vốn quan trọng sống còn, chúng cần một thứ tương đương với khái niệm công cụ máy móc mà tôi đang cố gắng giới thiệu.
Vì vậy, Tamper là một công cụ máy móc. Ý tưởng là thay vì tác nhân tự tạo ra các công cụ không liên kết cho mọi nhu cầu cục bộ, nó tạo ra các đặc tả chính xác về ý định trên miền vấn đề. Nó là một công cụ máy móc theo cùng nghĩa với JIG hoặc máy CNC – bạn đã thấy một số máy gia công nóng hỗ trợ máy tính chưa, nơi bạn cung cấp cho chúng đặc tả về ren vít của bạn cần phải như thế nào, cái này cần phải ra sao – điều này cực kỳ lặp lại được. Bạn có thể vận hành chúng và bạn có thể xây dựng máy bay và những thứ tương tự bằng chúng. Trong trường hợp này, tác nhân không tự ứng biến cơ chế cuối cùng mỗi lần. Nó tạo ra một mô tả chính xác và nó lặp lại với Tamper hoặc một cơ chế tương tự Tamper để làm cho một cái gì đó hoạt động trước, và sau đó biến nó thành một cái gì đó có thể lặp lại, có thể kiểm tra và có thể tái sử dụng. Vì vậy, bạn thực sự có thể xây dựng một nhà máy phần mềm xung quanh code base của mình.
Khái Niệm Dark Factory
Đó là khái niệm Dark Factory. Simon Wilson của Simon Wilson.net, một blog khá ấn tượng. Tôi nghĩ ông ấy là một trong những tiếng nói AI có ảnh hưởng nhất hiện nay trong việc hướng dẫn cách làm việc với tác nhân và xây dựng phần mềm, đã phổ biến cụm từ này, gọi là Dark Factory. Tôi nghĩ đó là một sự gói gọn khá tốt về một quy trình phần mềm nơi các tác nhân tiếp tục làm việc mà không có con người trên sàn nhà máy ảo. Bạn có thể tắt đèn. Vì vậy, vai trò của con người bây giờ trở thành việc thiết kế nhà máy, các ràng buộc, các kết quả và vòng lặp xác minh. Vì vậy, thứ này có thể chạy hàng giờ, hàng ngày, hàng tuần, tạo ra những gì bạn muốn nó tạo ra. Vì vậy, một thứ như Tamper có thể lấp đầy vai trò của một công cụ máy móc để xây dựng những nhà máy như vậy.
Ứng Dụng Dark Factory Với Helix
Hãy xem xét một Dark Factory cụ thể với Helix làm mục tiêu. Những gì tôi đã chia sẻ về Helix: đó là một dịch vụ streaming giống như Kafka. Nó có lẽ là một trong năm dịch vụ đắt đỏ mà chúng tôi đang chạy tại DataDog. Giống như Kafka. Vì vậy, chúng tôi đã shadowing (theo dõi) tải công việc sản xuất của chúng tôi với Helix. Trong một số trường hợp, chúng tôi thực sự tin rằng nó có thể rẻ hơn đáng kể so với giải pháp sản xuất hiện tại của chúng tôi. Bạn có tin được không? Chúng tôi mất khoảng một tuần để xây dựng nó và chúng tôi bắt đầu shadowing nó, và chúng tôi thấy cơ hội tiết kiệm từ hai đến năm lần (2-5X). Nhưng để đi từ trạng thái hứa hẹn này đến môi trường sản phẩm vẫn cần nỗ lực. Hệ thống cần chứng minh rằng nó có thể chạy, và nhiều người có thể vận hành nó, không chỉ người đã xây dựng nó. Vì vậy, chúng tôi đã tạo ra một loạt tải công việc tổng hợp mô phỏng hình dạng sản xuất của chúng tôi. Và chúng tôi đã xây dựng một nhà máy.
Nhà máy phần mềm cho Helix sử dụng Tamper theo ba cách riêng biệt:
- Đầu tiên, như một
mặt phẳng điều khiển tác nhâncho cáctác nhânđược quản lý bởiClaude, nơi cácphiên,vai trò,hàng đợi công việcvàvòng đời hoạt độngđược quản lý chính xác hơn. - Thứ hai, như một cách để các
tác nhântựxây dựng công cụcủa chúng với cácứng dụng Tampernhỏ, cầu nốicông cụ STLCnhưGit,CIvàtriển khai. - Và thứ ba, như một
API điều khiển Helix,giao diệnvàdịch vụ vòng đờixung quanhmặt phẳng dữ liệu Helixđểthực thi tải công việcnày.
Đó là một bất ngờ đối với tôi. Bất ngờ là nó bắt đầu cảm thấy tổng quát hơn là chỉ cơ sở hạ tầng tác nhân. Rất nhiều phần mềm, nếu bạn nhìn kỹ, chỉ là logic điều khiển xung quanh cơ sở dữ liệu, API xung quanh trạng thái, chính sách xung quanh thay đổi trạng thái, chuyển đổi vòng đời, tích hợp với các hệ thống bên ngoài. Vì vậy, Tamper có thể là một công cụ phổ quát theo nghĩa nó có thể áp dụng cho bất kỳ phần mềm nào có hình dạng tôi mô tả.
So Sánh Tamper và Claude Code
Trước khi tôi đi sâu hơn vào cách Tamper hoạt động, bạn có thể tự hỏi tại thời điểm này, tại sao điều này lại khác với việc yêu cầu Claude Code xây dựng một ứng dụng CRUD, ví dụ bằng TypeScript hoặc Python? Claude có thể làm điều đó rất tốt. Chúng ta đã thấy rất nhiều yêu cầu kéo (PRs) và rất nhiều mã được tạo ra. Tuy nhiên, trong các ứng dụng CRUD thông thường, logic điều khiển được phân tán qua các tuyến đường (routes), ràng buộc cơ sở dữ liệu, mã dịch vụ, tác vụ nền và tài liệu. Tất cả có thể có kiểm thử tốt và phạm vi kiểm thử (coverage) tốt, nhưng mô hình hoạt động, thường có hình dạng máy trạng thái, chủ yếu là ngầm định trong code base.
Vì vậy, ý tưởng là Tamper làm cho máy trạng thái đó trở nên minh bạch. Điều này không đặc biệt mới lạ. Chúng ta đã có điều này với các runtime như Erlang, Erlang OTP trong nhiều thập kỷ, các runtime khác, và gần đây hơn với các công cụ luồng công việc và thực thi bền vững, các runtime như Temporal. Tất cả chúng đều đã phổ biến các runtime chính xác này, để bạn có thể chạy trong các ứng dụng có khả năng phục hồi cao.
Cấu Trúc Nội Bộ Của Tamper
Hãy xem xét một số chi tiết nội bộ của Tamper để hiểu rõ hơn. Trên đường dẫn xây dựng cho Tamper, nó yêu cầu miền vận hành này mà tôi đang mô tả về mô hình những gì bạn muốn dưới dạng một bản thiết kế (blueprint). Các trạng thái là gì, những chuyển đổi nào là hợp lệ, ai có thể yêu cầu chúng, những hiệu ứng nào được cho phép, những bất biến nào phải duy trì, điều gì xảy ra nếu một lời gọi công cụ (tool call) thất bại? Vì vậy, tác nhân sẽ thường lặp lại và đi đến bản thiết kế này, qua nhiều lượt. Hãy nghĩ nó như chế độ lập kế hoạch của riêng nó để đạt được, thay vì tạo ra một tệp Markdown mô tả nào đó, nó có thể tạo ra các hiện vật khai báo chính xác này. Và sau đó bạn có một trình biên dịch tương đương như Tamper, xác minh nó, và nó có thể triển khai nóng (hot deploy) vào một runtime. Có các runtime khác làm điều này, như Erlang Beam làm điều đó nếu bạn đã từng nghe nói về nó, có ai đã nghe nói về Erlang Beam chưa? Đó.
Vì vậy, đường dẫn chạy (run path) cảm thấy giống như bất kỳ API có hình dạng CRUD nào khác. Bạn sẽ nhận thấy sự khác biệt. Điều quan trọng cần lưu ý là tác nhân không tạo mã ứng dụng tùy ý trực tiếp. Chúng ta đã nâng cao mức trừu tượng. Nó đang tạo ra một mô tả có cấu trúc được biên dịch thành hình dạng runtime của chúng ta. Bước biên dịch nằm ngoài bước kia. Nó giống như bạn viết mã Rust và bạn đưa nó cho trình biên dịch Rust.
Tamper biến bản thiết kế này thành một thứ gọi là chuyển đổi trạng thái hình thức (formal state transitions). Điều này rất phổ biến trong lập trình hàm và runtime actor nếu bạn đã sử dụng chúng. Đây là chi tiết kỹ thuật quan trọng nhất. Hình thức ở đây không có nghĩa là mọi thuộc tính có thể được chứng minh. Nó không phải là lý thuyết. Nó có nghĩa là hình dạng cơ bản của ứng dụng được biểu diễn như một hệ thống chuyển đổi chính xác. Và khi bạn có điều đó, đó là một lý luận tốt hơn nhiều cho cả con người và tác nhân so với mã tùy ý.
Thứ lỗi cho thiết kế brutalist hoàn toàn của slide này không có tô màu cú pháp. Nhưng đó là một tác nhân kiểm tra cho một rollout Helix. Đặc tả đó trông như thế này: Trạng thái, hành động và kích hoạt. Tôi thực sự đã có một ý tưởng sáng nay khi tôi thấy thông báo về các kích hoạt được quản lý trên Claude. Có lẽ đây chỉ có thể là một pass through (truyền qua). Bạn có thể khai báo một kích hoạt ở đây và sau đó để Claude chạy chúng. Nhưng ý tưởng là bạn xác định hành động và kích hoạt trạng thái của mình, hoặc tác nhân làm điều đó, Claude làm điều đó. Và trong trường hợp này, ví dụ, mô tả triển khai bắt đầu rollout chỉ hợp lệ khi đã lên kế hoạch hoặc thực thể chuyển sang trạng thái rolling. Và điều đó kích hoạt một tác dụng phụ như đi và vá Kubernetes stateful set, điều đó không quan trọng. Và sau đó là một callback quay lại để đánh dấu tiến độ hoặc thất bại.
Những gì Tamper làm, hiện vật đó là khai báo. Vì vậy, những gì Tamper làm, nó lấy cái này và tạo ra đặc tả đó thành bảng chuyển đổi này, một khái niệm nơi logic điều khiển quan trọng giống như dữ liệu. Nó không chỉ là mã spaghetti được mã hóa một cách mệnh lệnh (imperatively encoded) trong code. Nó giống như dữ liệu có thể trao đổi, không thể kiểm tra. Và nó không bị ẩn trong bất kỳ chuỗi phương thức dịch vụ tự ứng biến nào. Điều này dễ dàng hơn cho các tác nhân làm việc. Và chúng có thể thay đổi điều này một cách linh hoạt với an toàn. Đó là lời hứa. Tôi đã thấy mọi người viết script Erlang và triển khai nóng (hot deploying) vào Beam. Tôi nghĩ đó là một cách sáng tạo để sử dụng các runtime đã được củng cố cực kỳ trên các hệ thống đảm bảo cao hơn để các tác nhân làm việc. Vì vậy, trong trường hợp này, nếu một rollout cần một trạng thái mới hoặc đường dẫn rollback, tác nhân có thể thực hiện một thay đổi đặc tả có mục tiêu, và nó có thể tải lại nóng (hot reload) nó. Vì vậy, tốc độ lặp lại thậm chí còn nhanh. Bạn không phải trải qua CI và triển khai và mọi thứ. Khi bạn để tác nhân chạy qua đêm, tôi nghĩ chúng có thể đạt được một số tiến bộ khá tốt qua đêm mà không ảnh hưởng đến an toàn, đánh giá yêu cầu kéo (PR review) và đánh giá mã (code review) và những thứ tương tự.
Cổng Chính Sách và Hệ Thống Hiệu Ứng
Và chúng ta có cổng chính sách (policy gates). Bởi vì bảng chuyển đổi giống như dữ liệu, Tamper đánh giá các chuyển đổi trạng thái và quyết định chính sách cùng nhau như: ai có thể thay đổi một triển khai rollout? Những hành động nào mà một tác nhân vận hành (operator agent), giống như nhóm các tác nhân đang làm việc trên Dark Factory? Bạn có thể nói các tác nhân vận hành này chỉ có thể làm được bấy nhiêu. Hoặc những hành động này bị cấm đối với một tác nhân xây dựng (builder agent). Và bạn có thể chỉ định độc lập như một con người rằng một rollout đã hoàn thành có thể được rollout lại hay không, hoặc một kết quả công cụ thất bại (fail tool result) có thể tiếp tục trên đường dẫn rollout của nó, v.v.
Và sau đó chúng ta có tác dụng phụ (side effects) và hệ thống hiệu ứng (effect system), cũng rất phổ biến và các runtime có kiểu dữ liệu (typed runtimes) như TypeScript. Hiệu ứng là các thao tác có kiểu dữ liệu nhỏ một cách có chủ đích ở đây trong Tamper. Giữ chúng nhỏ ngăn máy trạng thái trở thành một cửa hậu cho hành vi ứng dụng tùy ý. Nhưng nếu bạn cần hành vi ứng dụng tùy ý, bạn có thể đóng gói chúng dưới dạng các module Wasm, quen thuộc với Wasm? Thôi nào. Được rồi, vài người giơ tay. Vì vậy, đây là nơi báo cáo của chúng ta được tạo bởi một LLM có thể để lại. Đó là một nơi làm việc rất hạn chế. Điều đó có nghĩa là nó giúp khắc phục sự cố (troubleshooting) dễ dàng hơn.
Bộ Xác Minh (Verifier)
Khối xây dựng cuối cùng cho Tamper là bộ xác minh (verifier). Xác minh về cơ bản là nút thắt cổ chai (bottleneck) hiện tại cho gần như mọi thứ. Chúng ta đã thấy rất nhiều thông báo và thảo luận xung quanh nó. Vì vậy, trong Tamper, bộ xác minh là một cổng trước khi bảng chuyển đổi được tải vào các runtime. Đó là điều cho phép nó nói rằng điều này là an toàn. Bạn có thể đặt cái này và tải trực tiếp (load it live). Và nó có nhiều cấp độ giống như một kiểu pho mát Thụy Sĩ (Swiss cheese pattern). Không phải tất cả các cấp độ đều cần tìm mọi thứ một cách đầy đủ. Tác nhân (Claude) nói chung rất giỏi trong việc đưa ra phán đoán. Tôi có cần chạy tất cả các cấp độ hay chỉ một số cấp độ giống như cách nó sử dụng đầu ra trình biên dịch của nó? Ví dụ, cấp độ một kiểm tra đại số của tự động hóa. Mô hình cấp độ hai kiểm tra biểu đồ trạng thái có thể truy cập (reachable state graph). Có bất kỳ đường dẫn nào có thể đạt đến trạng thái xấu không? Và cấp độ ba chạy các lịch trình, tiêm lỗi, các bất biến có tồn tại qua các điều kiện lỗi thời gian và v.v.. Và cấp độ bốn sử dụng kiểm thử thuộc tính (property tests) mà tôi thực sự khuyến khích chúng ta phải bắt đầu học cơ chế này của kiểm thử ngẫu nhiên với chuỗi hành động.
Tất cả những điều này không đầy đủ ngay từ ngày đầu tiên. Mọi khoảng trống khám phá đều gia tăng bộ xác minh. Tôi cũng nghe Boris đề cập đến hiệu ứng tích lũy (compounding effect) của việc bạn tìm kiểm thử và bạn tiếp tục sửa lỗi các khoảng trống. Một điều kiện bị thiếu được tiết lộ trong môi trường sản phẩm hoặc mô phỏng có thể được thêm vào mô hình hoặc bộ kiểm thử. Và nó gia tăng.
Vì vậy, tất cả những điều này đang diễn ra. Tôi không biết. Ý tôi là tôi không thể dự đoán nhiều về nơi điều này có thể đi đến. Nhưng ý tưởng là nếu mỗi hiện vật của ứng dụng Tamper hoặc một bundle là ngắn gọn, rất ít dòng, vừa vặn trong đầu bạn. Tôi đã dành rất nhiều thời gian vận hành cơ sở hạ tầng quan trọng sống còn cho DataDog thức dậy vào ban đêm hàng ngàn lần trong ba hoặc bốn năm qua. Bạn sẽ không thể giữ logic quan trọng sống còn phức tạp trong đầu khi bạn muốn vận hành nó đúng cách cho một miền kinh doanh phức tạp như ngân hàng hoặc hệ thống tài chính. Bạn vẫn nên có thể mã hóa logic kinh doanh của mình theo cách này. Một cái gì đó mà con người có thể đọc. Nếu hiện vật được tạo là hàng ngàn dòng mã lộn xộn, chúng ta lại quay về nơi chúng ta bắt đầu. Và tôi chưa hoàn toàn biết liệu một LLM có thể hoàn toàn đánh giá và sau đó ký duyệt vào nó hay không. Nếu đó là một vài hiện vật nhỏ với vai trò rõ ràng khi cả con người và tác nhân có thể sửa đổi hệ thống mà không làm xáo trộn mọi thứ xung quanh nó. Tôi vẫn cảm thấy đây chỉ là kỹ thuật hệ thống tốt và phần mềm có độ đảm bảo cao hơn như trong hàng không và hệ thống tài chính đã được xây dựng theo cách này trong nhiều thập kỷ. Tuy nhiên, chi phí của sự nghiêm ngặt như vậy với con người là quá cao đối với phần mềm chung cho đến nay. Các tác nhân đang thay đổi phép tính đó.
Từ ẩn dụ sản xuất đến quy trình phát triển phần mềm
Quay trở lại ẩn dụ về sản xuất của tôi, chiến thắng không phải là một nghệ nhân có thể chế tạo một cỗ máy xuất sắc. Chiến thắng thực sự là một cỗ máy được build (xây dựng) bằng machine tools đã tạo ra các bộ phận có thể kết hợp, kiểm tra được và thay thế, nhờ đó chúng ta có thể build (xây dựng) những cỗ máy lớn hơn. Và lập luận của tôi là, đối với phần mềm — khi tác nhân build (xây dựng) phần mềm — chúng ta cần một mức độ chặt chẽ như vậy để có thể mở rộng quy mô từ đây, nếu chúng ta thực sự muốn build (xây dựng) cơ sở dữ liệu và đưa chúng vào môi trường sản phẩm / sản xuất.
Tầm quan trọng của kỷ luật và sự chặt chẽ với tác nhân
Tôi đã nhận ra điều này ngay từ đầu. Nếu tác nhân có thể tự động build (xây dựng) phần mềm trong các nhà máy với kỷ luật và sự chặt chẽ như vậy, có lẽ, chỉ có lẽ, chúng ta không cần phải dừng lại ở các "nhà máy tối" (dark factories). Tôi không biết liệu có điều gì "tối" ở đó không; nghe có vẻ hơi buồn.
Phát triển phần mềm như một sinh vật sống
Vì vậy, toàn bộ phần mềm được build (xây dựng) theo cách này có thể giống như một sinh vật mà chúng ta có thể phát triển, nuôi dưỡng và tiến hóa thông qua phản hồi, chọn lọc và thích nghi. Nó giống như, tôi không biết, nông nghiệp hoặc một quá trình tiến hóa có định hướng, nơi bạn chọn hướng mà phần mềm của bạn cần phát triển.
Tầm nhìn tương lai và kết luận
Bạn có thể chọn Kafka làm một hàng đợi (queue) vì có nhiều khách hàng sử dụng nó như một hàng đợi thay vì nói "không, chúng ta cần nhiều buffers hơn. Chúng ta không cần tất cả các brokers này." Hoặc có lẽ tôi chỉ đang mơ, phải không? Giờ đây, chúng ta có những giấc mơ trong đám mây. Đó là tất cả những gì tôi muốn chia sẻ. Cảm ơn rất nhiều vì đã lắng nghe.