Nhà máy phần mềm: Ánh sáng và Bóng tối

Một nhà máy phần mềm là các vòng lặp được khai thác ở quy mô lớn. Bạn có thể chạy vòng lặp với con người ở trong đó (nhà máy sáng): đánh đổi khả năng phán đoán và sự tập trung để lấy tốc độ và rủi ro hỏng hóc. Hoặc bạn có thể bỏ qua con người (nhà máy tối) và để các tác nhân đó tự phạm vi, xây dựng và triển khai mã, mà không cần ai thực sự đọc chi tiết. Nhưng nếu mọi người ngừng đọc, họ sẽ ngừng hiểu phần mềm của bạn. Công việc khó khăn nhất của bạn bây giờ là biết nên xây dựng những kiểm tra nào và ủy quyền bao nhiêu quyền tự chủ.

Ý tưởng về nhà máy phần mềm này là một thuật ngữ có từ bài báo "The economics of program production" của Bob Bemer năm 1968. Trong suốt nửa thế kỷ, nhiều người đã mơ về một thế giới nơi phần mềm là một quy trình sản xuất có thể lặp lại và đo lường được (tương tự như việc dập khuôn các bộ phận ô tô trong một nhà máy) thay vì là nghề thủ công riêng lẻ của từng cá nhân. Trong lịch sử, giấc mơ này thường (mặc dù không phải lúc nào cũng vậy) đã thất bại, một phần vì khó khăn trong việc "dập khuôn" các ý tưởng.

Nhưng trong hai năm qua, mọi thứ đã thay đổi đáng kể đến mức bây giờ đã có ý nghĩa để xem xét lại giấc mơ cũ. Và vì một số điểm tinh tế có thể dễ dàng bị bỏ qua, nên cần phải khá chính xác về những gì thực sự mới và khác biệt, và những gì có thể là những cái bẫy lặp đi lặp lại, được ngụy trang thành những cơ hội mới.

@dexhorthy, đồng sáng lập của HumanLayer gần đây đã có một bài nói chuyện tuyệt vời tại Hội chợ Thế giới Kỹ sư AI có tựa đề "Kỹ thuật Khai thác là Chưa Đủ: Tại sao Nhà máy Phần mềm Thất bại." đáng để xem về chủ đề này.

Vòng lặp là nguyên tử. Nhà máy là vòng lặp ở quy mô lớn.

Cấu trúc là tất cả, và tất cả bắt đầu với những đơn vị nhỏ. Toàn bộ kiến trúc thực sự là ba khái niệm xếp chồng lên nhau: vòng lặp, dây cương, và nhà máy.

Một vòng lặp là một tác nhân thực hiện một công việc duy nhất lặp đi lặp lại: thu thập ngữ cảnh, thực hiện hành động, kiểm tra kết quả và lặp lại cho đến khi một điều kiện nào đó được đáp ứng. Nó là đơn vị nhỏ nhất của công việc tác nhân, và mọi thứ ở trên nó chỉ là các vòng lặp xếp chồng lên các vòng lặp.

Điểm mấu chốt của kỹ thuật vòng lặp là bạn ngừng nhắc nhở tác nhân từng bước một và thay vào đó thiết kế hệ thống nhỏ nhắc nhở nó cho bạn.

Dây cương là những bức tường xung quanh một vòng lặp: hộp cát nó chạy trong đó, các công cụ nó có thể với tới, bộ nhớ tồn tại giữa các lần chạy, và các cổng quyết định "xong" có nghĩa là gì. Vòng lặp là hành vi; dây cương là môi trường nơi hành vi đó chạy bên trong.

Đưa cho một mô hình thô không có dây cương và nó sẽ vui vẻ quay vòng mãi mãi. Dây cương là mọi thứ xung quanh nó làm cho nó hữu ích và an toàn để chạy.

Một nhà máy phần mềm là nhiều vòng lặp được khai thác chạy cùng một lúc, được cung cấp bởi một hàng đợi công việc và được xả qua một cổng xem xét vào sản xuất, với con người sở hữu toàn bộ từ trên xuống. Nó không phải là một tác nhân lớn hơn; nó là một sơ đồ tổ chức được tạo thành từ các vòng lặp.

Sự thay đổi mô hình cuối cùng là chuyển từ việc viết mã sang xây dựng và vận hành nhà máy viết mã. Đơn vị công việc chuyển lên một cấp độ, đến vòng lặp, dây cương và luồng giữa chúng, thay vì từng bản vá mã riêng lẻ.

Vòng lặp → dây cương → nhà máy. Một nhà máy không phải là một tác nhân thông minh hơn; nó là nhiều vòng lặp được khai thác nuôi một cổng xem xét duy nhất, với một con người sở hữu vòng lặp bên ngoài. Nhà máy, được vẽ

Slide trung tâm mà Dex dành nhiều thời gian nhất thật xuất sắc vì nó là một sơ đồ làm rõ ràng, trực quan hóa những gì nếu không thì chỉ là một vòng lặp hiển nhiên. Đây là cách tôi hiểu về nó:

Nhà máy là một vòng lặp khép kín: ý định và tín hiệu sản xuất nuôi một hàng đợi, dây cương xây dựng, các kiểm tra tự động và cổng xem xét nó, triển khai gửi nó, giám sát biến sản phẩm trở lại thành tín hiệu. Ý định chảy từ tầm nhìn của lãnh đạo kỹ thuật, và trực tiếp từ các kỹ sư, vào một hàng đợi những việc cần làm. Các tín hiệu từ sự cố và yêu cầu của người dùng cũng thúc đẩy cùng một hàng đợi.

Dây cương chỉ là thứ chọn một mục từ hàng đợi và xây dựng một thay đổi cho nó. Vượt ra ngoài dây cương, chúng ta có thể thấy tất cả các kiểm tra tự động cần thiết để làm cho các thay đổi đủ an toàn để đưa vào sản xuất. Các kiểm tra tự động này chạy cùng một lúc, một cách dễ dàng, không cần bất kỳ sự tham gia có ý thức nào của các kỹ sư, nhờ vào CI, kiểm thử, phân tích tĩnh và quét đủ loại. Điểm quyết định duy nhất ở đây là cổng xem xét. Sau khi được phê duyệt, các thay đổi được triển khai và giám sát trong sản xuất, với dữ liệu giám sát phản hồi vào các tín hiệu đã khởi động vòng lặp ngay từ đầu.

Nhìn chung, mọi ô trong sơ đồ này gần như có chi phí bằng không: tạo mã, kiểm thử, quét. Tất cả đều chạy ở quy mô lớn với chi phí không đáng kể. Chỉ có một ô đắt đỏ ngoan cố chống lại việc mở rộng quy mô, và đó là cổng xem xét. Cái hộp màu hổ phách sáng bóng đó là "sự phán đoán", và là nơi ẩn chứa mấu chốt của cuộc tranh luận về việc liệu chúng ta có thể làm cho việc phát triển nhanh hơn và thường xuyên hơn hay không.

Tại sao chúng ta gọi nó là "tối"

Một nhà máy tối chạy với đèn tắt về mặt vật lý, bởi vì những thứ duy nhất trên sàn nhà máy là máy móc và máy móc không cần ánh sáng để nhìn. Một nhà máy phần mềm tối cũng tương tự: mã được triển khai mà không có con người nào đọc, chỉ được xác minh bởi các máy móc khác.

Hình ảnh này được mượn từ ngành sản xuất. Nguồn gốc của nó là vật lý chứ không phải kỹ thuật số, bắt nguồn từ các cơ sở nơi đèn tắt và công việc được thực hiện bởi robot. FANUC ở Nhật Bản đã vận hành các nhà máy không đèn loại này từ năm 2001; Xiaomi, vào năm 2024, đã mở một nhà máy tối tự động hóa cao của riêng mình. Điểm chung của chúng là một sản phẩm được lắp ráp và vận chuyển mà không có một con người nào đọc bất kỳ phần nào của nó. "Tối" xuất hiện khi hành động đọc đó bị loại bỏ khỏi quy trình.

Tôi không mượn khái niệm này vì không khí của nó hay như một sự xúc phạm. Đối với tất cả sự ồn ào rùng rợn của nó, "tối" ở đây là một tuyên bố vật lý đơn giản: sàn nhà máy ban đầu, nhưng không có ánh sáng. Trong phần mềm, sàn nhà máy là bản vá. Bất kể ai đã viết bản vá, ai đã xem xét nó, ai đã triển khai nó, những con người đó không còn nữa, và những gì còn lại là một bản vá chỉ được xác minh bởi các máy móc đã xây dựng nó.

Đây là một việc đáng ngạc nhiên là dễ làm, ít nhất là lúc đầu. Nó dễ dàng vì bước xem xét còn thiếu đó cản trở mọi thứ. Sự vắng mặt của nó làm cho nhận thức của bạn về thông lượng dọc của nhóm bạn dường như tăng lên đột ngột và triệt để. Cảm giác như bạn đã phá vỡ rào cản âm thanh. Đối với tất cả vẻ dễ dàng rõ ràng của nó, việc tồn tại với các quy trình làm việc tối đó khó hơn vẻ bề ngoài, với tất cả các chi phí tiềm ẩn của chúng.

Kỹ thuật Khai thác là Chưa Đủ

Dây cương của việc điều phối, tạo mẫu trong hộp cát và gọi công cụ khi các mô hình tương tác với thế giới và với nhau sẽ ngày càng trở nên mạnh mẽ và hiệu quả. Tuy nhiên, có một sự thất bại cố hữu trong mô hình khi cố gắng theo kịp chất lượng cơ sở mã trong dài hạn và thông qua các thay đổi tích lũy, và tôi nghĩ có lý do chính đáng để tin rằng chỉ riêng các mô hình cuối cùng sẽ thua trong cuộc chiến đó chống lại nợ hiểu biết.

Nợ hiểu biết là khoảng cách ngày càng rộng giữa lượng mã tồn tại và lượng mã mà bất kỳ con người nào vẫn còn hiểu. Một nhà máy tối không trả bớt khoản nợ đó; nó nhận nó càng nhanh càng tốt, với các bài kiểm tra luôn xanh trong suốt quá trình.

Đây là một điểm khác biệt quan trọng vì các mô hình làm tốt một số nhiệm vụ. Nhưng đối với bất cứ điều gì không phải là một thay đổi tức thời đối với một phần nhỏ của cơ sở mã, đặc biệt là trong một hệ thống brownfield phức tạp, việc viết mã tự động chỉ dựa trên mô hình phải đối mặt với một trở ngại không thể vượt qua. Các ứng dụng Greenfield, đồ chơi cuối tuần và các dự án phụ đều giống nhau ở chỗ một vài tháng phát triển thường là đủ để đưa mọi thứ vào trạng thái hoạt động, hoặc ít nhất là đủ gần.

Nhưng một hệ thống doanh nghiệp đã được phát triển trong một thập kỷ hoặc hơn là một con quái vật khác; nó phải được bảo trì, trong một môi trường chuyên nghiệp với tốc độ chuyên nghiệp. Ba đến sáu tháng sau khi bắt đầu một dự án, bạn đã chìm ngập trong mã chưa đọc. Loại môi trường đó, và đặc biệt là các ràng buộc được thực thi bởi mã sản xuất, sẽ khiến ngay cả một tác nhân mạnh mẽ cũng hoạt động kém, tất cả đều trái ngược với việc "vibe-coding" mà các nhà phát triển làm việc trên các đồ chơi cuối tuần yêu thích.

Dex báo cáo từ kinh nghiệm rằng đây là một thất bại lớn, đến nỗi nó đòi hỏi phải gỡ lỗi thủ công tỉ mỉ để xác định. Điều này đến từ việc vận hành một nhà máy mã tự động hoàn toàn trong khoảng bốn tháng, trong thời gian đó không có con người nào nhìn vào mã được viết. Ẩn dưới trải nghiệm này là một sự đánh đổi giữa hai chỉ số xung đột. Một là tối đa hóa việc sử dụng token, con số mà chúng ta hiện đang coi là tiến bộ. Cái còn lại, mà nó âm thầm giảm thiểu, là lượng hệ thống mà bất kỳ người tham gia nào vẫn hiểu tại bất kỳ thời điểm nào.

Nơi mà nhà máy tối thực sự tỏa sáng là khả năng đốt cháy qua mã nguyên sơ trong khi các bài kiểm tra vẫn xanh. Sự phán xét cuối cùng, khi nó đến, sẽ không phải là một khoảnh khắc kịch tính "mọi thứ đều đi sai hướng". Nó sẽ là yên lặng và muộn màng.

Tối và sáng là cùng một đường ống với đèn ở những vị trí khác nhau. Phiên bản sáng không chỉ thêm lại việc xem xét ở cuối - nó còn di chuyển sự phán đoán của con người lên thượng nguồn, đến thiết kế và kiến trúc, nữa. Nút thắt cổ chai chưa bao giờ là việc tạo mã

Ràng buộc cơ bản trong một nhà máy phần mềm không phải là chúng ta có thể sản xuất ra bao nhiêu mã: mà là chúng ta có thể xác minh nó nhanh như thế nào.

Áp lực ngược là quy tắc rằng bạn chỉ có thể trao cho một vòng lặp nhiều quyền tự chủ như bạn có thể xác minh một cách rẻ và đáng tin cậy, và không hơn một inch. Xác minh, chứ không phải tạo mã, mới là ràng buộc thực sự đối với một nhà máy.

Bởi vì khả năng tạo mã không giới hạn luôn căng thẳng với nguồn lực hữu hạn, không thể mở rộng của sự chú ý của con người, vấn đề cốt lõi là khoảng cách giữa việc tạo mã rẻ và việc xem xét có giới hạn. Hãy nhìn vào cái phễu: miễn là phần cổ đại diện cho việc xác minh không mở rộng, nó sẽ bị tắc nghẽn. Như Dex chỉ ra, chỉ riêng khối lượng không phải là vấn đề: những gì chúng ta thực sự đang phải chịu đựng là sự dư thừa của các PR tồi. Khi bạn có khối lượng lớn mà không có cổng đáng tin cậy, các lỗi được sản xuất là không thể tránh khỏi. Đây chỉ là áp lực ngược một lần nữa: quyền tự chủ không thể mở rộng vượt quá những gì có thể được xác minh một cách rẻ và đáng tin cậy.

Vấn đề bậc hai là tại sao việc cải thiện mô hình sẽ không tự động thu hẹp khoảng cách giữa những gì nó có thể tạo ra và những gì có thể được xác minh. Việc đào tạo trên các hệ thống có kiến trúc tốt là một đề xuất khó khăn hơn so với việc vượt qua các bài kiểm tra đơn giản: hãy nhớ, các hàm chi phí đo lường sự xuất sắc của kiến trúc không được đo bằng giây hoặc thậm chí vài phút, mà bằng tháng và năm. Các gradient gọn gàng về mặt chức năng là không thể tính toán được, vì vậy một hệ thống mong đợi sự đánh giá nhanh chóng, tức thì về các quyết định thiết kế phức tạp sẽ không được đào tạo trên các ví dụ tốt.

Tạo mã là một cái miệng rộng; xác minh là cái cổ hẹp. Tăng tốc cái miệng chỉ làm sâu thêm đống ở cái cổ.

Bật đèn trở lại

Một nhà máy sáng là cùng một đường ống với đèn được bật ở nơi sự phán đoán tồn tại. Các tác nhân vẫn thực hiện hầu hết việc xây dựng, nhưng một con người đọc những gì được tạo ra trước khi nó được triển khai, và đèn vẫn sáng ở bất cứ nơi nào một quyết định sai lầm là đắt đỏ.

Phiên bản sáng không gắn việc xem xét vào cuối mà di chuyển điểm phán đoán của con người lên thượng nguồn, đến sản phẩm, thiết kế và kiến trúc trước khi một tác nhân bắt đầu một vòng lặp.

Một điều tuyệt vời về giờ làm việc ban đầu đó là nó dẫn đến ít giờ thực hiện hơn. Nó biến một buổi xem xét mã dài và bực bội thành một bài đọc nhanh về một kế hoạch dài hai trăm dòng. Bạn có thể xem xét một quyết định trước khi nó được xây dựng, vì vậy sau này bạn không phải lần theo hai nghìn dòng mã được tạo ra để tìm ra quyết định đó thậm chí là gì. Một số quyết định đủ đắt đỏ và tồn tại lâu dài đến nỗi bạn muốn có một người tham gia vào sớm, trước khi chi phí cộng dồn. Tất nhiên, vẫn có những lúc bạn xem xét các bản vá, ngay cả khi bạn đã dành thời gian lúc đầu.

Bạn có thể nghĩ rằng tất cả nghe có vẻ không hào nhoáng. Bạn nói đúng. Lưới an toàn được tạo thành từ các thực hành kiến trúc hoàn toàn bình thường mà chúng ta đã luôn biết và hầu hết đã bỏ qua: các kiểu và chữ ký phương thức tốt để các lỗi bị trình biên dịch bắt thay vì trong sản xuất; các đường nối kiểm thử nơi chúng ta có thể ghim hành vi và làm cho thay đổi có thể quan sát được; bố trí mã để người đọc tiếp theo, dù là con người hay mô hình, biết nơi tìm thứ họ quan tâm; giữ các ngăn xếp cuộc gọi ngắn và dễ đọc; giữ các ranh giới thành phần được xác định rõ ràng để một thay đổi không có bán kính ảnh hưởng lớn; và tiêm phụ thuộc để chúng ta có thể hoán đổi một phần này cho một phần khác. Không có gì là mới. Chúng ta đã luôn nói rằng chúng ta quan tâm đến kiến trúc tốt. Nhưng bây giờ khi chúng ta đang sử dụng các tác nhân viết mã tự động, kiến trúc đó cuối cùng đã làm một công việc thứ hai như một lưới an toàn rẻ và khó làm giả chống lại những sai lầm mà tác nhân sẽ mắc phải.

Lưới an toàn đó phải tồn tại bên ngoài mô hình, bởi vì mô hình sẽ không cung cấp nó. Các tác nhân viết mã có cảm giác có năng lực nhất, bao gồm Claude Code và Codex, được huấn luyện tăng cường dựa trên dây cương và công cụ của chính chúng: thông thạo tất cả các công cụ và thành ngữ của nghề, nhưng không phải với những thứ như khả năng bảo trì lâu dài. Kiến trúc có chủ đích mà chúng ta đã luôn nói đến là công cụ bắt lấy khoản nợ đó, và khoản đầu tư chúng ta thực hiện vào nó là chúng ta mua lại quyền tự chủ của mình.

Kết hợp điều đó với cơ sở hạ tầng an toàn, và có một số vòng lặp chặt chẽ, ít rủi ro mà bạn có thể chạy không cần giám sát. Horthy đã mô tả một trong một bài đăng gần đây: một cron GitHub Actions hàng đêm chỉ sửa một anti-pattern, một vi phạm lint hoặc một prop không cần thiết, commit, và tự động mở một pull request nhỏ, để nhóm thức dậy với một cơ sở mã tốt hơn một chút và một bản vá đủ ngắn để đọc. Nhưng đối với các vòng lặp có rủi ro đủ cao, bạn không muốn mạo hiểm thức dậy với một hệ thống xác thực bị hỏng, công cụ thanh toán, hoặc hợp đồng API công khai. Hãy giữ đèn sáng ở đó, và tin tưởng rằng một người có phán đoán và kiến thức làm việc thực sự về hệ thống sẽ bắt được lỗi.

Điều gì làm cho một vòng lặp xứng đáng được chạy tối

Quy tắc này áp dụng cho dù bạn gọi nó là áp lực ngược, xác minh, hay công tắc đèn.

Một vòng lặp chỉ có thể tự động hóa hoàn toàn nếu việc kiểm tra rẻ, chạy với tần suất cao và dựa vào thứ gì đó không thể dễ dàng bị giả mạo. Các nhà tiên tri xanh-đỏ, cổng kiểu, kiểm thử thuộc tính và một tác nhân xem xét kết hợp với một tiêu chí thực sự đều phù hợp. Bạn cũng cần nhà tiên tri trả lời ngay lập tức và không thay đổi theo thời gian. Khi "xong" có thể được chứng minh không chỉ bởi bạn mà còn bởi một máy móc, bạn đã đạt được tự động hóa.

Các vòng lặp ngắn dễ xác minh hơn các vòng lặp dài. Quy tắc ngón tay cái của Dex: một tác nhân duy trì được ba đến mười bước, sau đó bắt đầu mất mạch sau hai mươi. Lý do là sự tích lũy ngữ cảnh, tác nhân càng kéo theo nhiều, nó càng có khả năng đi lạc. Khi một vòng lặp ngắn, việc xác minh nó là rẻ. Các vòng lặp lan rộng che giấu sai lầm trong các góc, đó là một cách khác để nói rằng chúng chưa bao giờ xứng đáng với trạng thái không đèn.

Giữ đèn sáng là trường hợp ngược lại. Một vòng lặp cần được xem xét nếu một câu trả lời sai là đắt đỏ và chỉ có một người mới có thể bắt được nó. Các lỗi sản xuất tinh vi mà các bài kiểm tra không thể bắt được, bán kính ảnh hưởng lớn, và một quyết định sẽ định hình công việc của một năm hoặc hơn đều đủ điều kiện. Trong những trường hợp đó, sự chú ý của bạn là sản phẩm thực sự, là thứ đắt đỏ, thiết yếu.

Mối nguy hiểm là quên lật từng công tắc và chỉ đặt tất cả chúng vào cùng một chế độ. Tất cả tối, và bạn sẽ bị mắc kẹt trong việc phá bỏ mọi thứ bốn tháng sau. Tất cả sáng, và không ai có thể hoàn thành việc xem xét kịp thời và bạn sẽ bị mắc kẹt trong một nút thắt cổ chai khổng lồ. Công việc khó khăn, đòi hỏi kỹ năng là quyết định nên đặt mỗi công tắc ở đâu.

Vòng lặp, đồ thị hay máy trạng thái?

Bạn nên đọc "Máy trạng thái trong 2 phút" của @DavidKPiano

Khi bạn giao một nhiệm vụ cho một tác nhân, có lẽ bạn sẽ xây dựng một đồ thị xung quanh nó, cho dù bạn gọi đồ thị đó là một máy trạng thái hữu hạn hay một tập hợp các lệnh gọi dịch vụ được liên kết có điều kiện. Đó là một khuôn khổ nơi phần mềm không chỉ tuân theo một số quy tắc trừu tượng mà là một quy trình làm việc có cấu trúc: mỗi nút là một bước rõ ràng, và mỗi cạnh giữa các nút là một điều kiện rõ ràng.

Điều đó nghe có vẻ là rất nhiều cấu trúc, nhưng hầu hết nó đã có sẵn trong bất kỳ phần mềm nào, vì bất kỳ mã nào cũng có thể được biểu diễn dưới dạng đồ thị luồng điều khiển. Vì vậy, điểm mới lạ thực sự duy nhất là một tác nhân khăng khăng đòi quyền tự chủ thực sự chỉ đang đi dạo xung quanh một đồ thị cụ thể, và sự tự do của nó bị giới hạn trong phạm vi bên trong một nút. Và đây là phần mà mọi người quên, điều mà Dex đã viết ra một năm trước: phần mềm luôn luôn có cấu trúc đó. Có một lý do tại sao chúng ta từng vẽ các chương trình dưới dạng lưu đồ.

Động thái thực sự mới là cố gắng vứt bỏ sơ đồ, dựa vào một vòng lặp nơi mô hình chọn đường dẫn công cụ theo từng lệnh gọi, cho đến khi nó tự tuyên bố hoàn thành. Điều đó cảm thấy như sự giải phóng, cho đến khi nó gặp một cơ sở mã mười năm tuổi, và kỷ luật mà mọi người bây giờ đang khám phá lại, làm chủ luồng điều khiển của bạn, thực sự chỉ là đi dạo đồ thị trở lại quanh vòng lặp. Vì vậy, câu hỏi liệu chúng ta có nên chuyển từ vòng lặp trở lại đồ thị hay không gần như là một sự thừa nhận rằng chúng ta cần lưu đồ ngay từ đầu.

Đây là những gì nó trông như thế nào trong thực tế. Hãy lấy một lỗi cần sửa. Như một vòng lặp thuần túy, bạn ngồi xuống và nghĩ: tìm ra vấn đề, thay đổi một số mã, chạy các bài kiểm tra, xem điều gì xảy ra, và nếu vòng đó không kết thúc lần chạy, hãy lặp lại và bắt đầu lại. Toàn bộ hành trình được quyết định khi bạn tiến hành, vấn đề nào bạn theo đuổi, mã chính xác bạn thay đổi, bài kiểm tra nào bạn chạy và theo thứ tự nào, liệu bạn có chạy kiểm tra gì không, và liệu bạn có thử lại hay tuyên bố chiến thắng.

Như một đồ thị, điều đầu tiên bạn làm là vạch ra những gì nên xảy ra. Tái tạo lỗi hoặc đi hỏi thêm thông tin, tìm nguyên nhân, thử một bản sửa, chạy các bài kiểm tra, và để một lần chạy thất bại quay trở lại bản sửa trong khi một lần chạy thành công tiếp tục đến bước xem xét, nơi chỉ có sự phê duyệt mới đến được "xong". Tác nhân vẫn thông minh bên trong mỗi hộp; nó chỉ không thể đi lang thang ra khỏi những con đường bạn đã cho phép. Santi đã trình bày điều này với một sơ đồ làm cho sự khác biệt trở nên rõ ràng.

Sự hấp dẫn thực sự của đồ thị đó, tất nhiên, là nó là áp lực ngược được vẽ dưới dạng sơ đồ. Bạn từ bỏ một số quyền tự do của tác nhân và đổi lại nhận được các kiểm tra bắt buộc và các điểm thất bại dễ đọc, vì vậy khi một lần chạy chết, bạn có thể chỉ vào nút đã giết nó. Đó là cùng một bản năng đằng sau dòng thẳng thừng của Dex rằng hầu hết cái gọi là tác nhân không thực sự có tính chủ động cao, "chủ yếu là mã xác định, với các bước LLM được rải vào đúng những điểm." Và điều này không chỉ là một hiện tượng của cách mọi người tình cờ xây dựng mọi thứ ngay bây giờ: bạn có thể thấy mô hình trong LangGraph và LlamaIndex Workflows, trong quy trình làm việc đồ thị-trên-tác nhân kết hợp của Jerry Liu với một vòng lặp bên ngoài phát triển các phần của đồ thị khi nó chạy, và trong lời nhắc nhở của David Khourshid rằng điều này thực sự chỉ là máy trạng thái và mô hình tác nhân xuất hiện trong lớp vỏ mới.

Một sự làm rõ, vì thuật ngữ này bị quá tải nặng nề: khi tôi tiếp tục gọi đây là một đồ thị, tôi không có ý nói đồ thị tri thức. Tôi có nghĩa là một đồ thị có hướng được xác định trước về cách công việc sẽ chảy, bao gồm các cạnh có điều kiện, tạo cho vòng lặp một hình dạng mà bạn thực sự có thể tin tưởng.

Nơi con người thực sự đi

Lưu ý rằng người đó không bao giờ rời khỏi nhà máy. Họ đã di chuyển.

Tôi nghĩ các kỹ sư ngày càng cần phải sở hữu vòng lặp bên ngoài. Các tác nhân có thể điều tra một lỗi, viết chẩn đoán, thực hiện một bản sửa, chạy các bài kiểm tra và viết một báo cáo. Đó là việc thực hiện vòng lặp bên trong, và chúng có thể làm điều đó hiệu quả như bất kỳ ai. Nhưng đó không bao giờ là công việc. Những phần bạn sở hữu là những gì tôi gọi là vòng lặp bên ngoài: quyết định xem đó có phải là cách đúng đắn để giải quyết vấn đề không, xác minh chẩn đoán và việc thực hiện là hợp lý, phê duyệt thay đổi, và chịu hậu quả của việc sai. Ranh giới giữa hai vòng lặp là bằng chứng, các bản vá, các bài kiểm tra, các bản ghi và một lời giải thích ngắn kết nối chúng. Các kiểu, đường nối và tiêu chí làm cho nó có thể giám sát tất cả điều này mà không cần làm nhiều việc cho mỗi thay đổi.

Sẽ hữu ích khi nói theo cách này: bạn không còn ở dưới dây chuyền sản xuất viết các thay đổi nữa; bạn ở cuối dây chuyền sản xuất thiết kế nó và canh gác cổng. Có rất nhiều điều bạn có thể làm để cải thiện mô hình và làm cho dây cương có năng lực hơn, nhưng tôi đã quan sát thấy rằng việc xác định các vấn đề đắt đỏ trong dài hạn thường không phải là điều bạn có thể tự động hóa. Điều cốt lõi vẫn là công việc là thực hiện phán đoán của con người tốt hơn bất kỳ luồng giấy tờ và sức mạnh tính toán nào.

Robot hoạt động tốt trong bóng tối, nhưng con người cần nhìn thấy những gì chúng đang làm. Nếu mọi thứ trên sàn nhà máy đều tối, và bạn không thể thấy gì, và bạn thậm chí không thể tìm thấy công tắc đèn, đó là nơi nguy hiểm nằm.

Pangram đã ghi điểm bài viết này là 100% do con người viết.