Tại sao mô hình 'Nhà máy phần mềm' thất bại: Đừng chỉ dựa vào quy trình kỹ thuật

Tại sao các nhà máy phần mềm (Software Factories) thất bại

hoặc: kỹ thuật khai thác (harness engineering) là chưa đủ

Lưu ý

Tôi đang điều hành một công ty (HumanLayer) chuyên xây dựng các công cụ trong lĩnh vực cộng tác giữa con người và tác nhân (agent), vì vậy những gì tôi sắp nói dưới đây có thể hơi thiên vị. Dẫu vậy, tôi hy vọng bạn thấy chủ đề này hữu ích hoặc ít nhất là thú vị như tôi. -Dex

tôi đoán là giờ chúng ta đang làm vòng lặp (loops) rồi

Tất cả chúng ta đang chạy đua để đưa việc lập trình bằng AI vào môi trường thực tế (production). Đã có rất nhiều bàn luận về kỹ thuật vòng lặp (loop engineering), và quan điểm phổ biến hiện nay là chúng ta có lẽ nên viết nhiều vòng lặp hơn.1

StrongDM đã viết về nhà máy phần mềm "tắt đèn" (lights-off software factory) của họ, nơi không có con người nào đọc mã và cũng không có con người nào viết mã.

Câu chuyện diễn ra đại loại như thế này:

Ryan Lopopolo của OpenAI đã viết về điều này vào tháng 2 và có một bài thuyết trình vào tháng 4 về nhà máy phần mềm của OpenAI, Symphony.

Những người này đều cực kỳ thông minh và tôi dành sự tôn trọng rất lớn cho họ. Nhưng cách nhìn hoài nghi nhất ở đây là gọi đây là một cái cớ khác để bơm thêm tiền đầu tư mạo hiểm (VC) vào "cỗ máy tạo rác" (slop cannon).

nó... ừm... nó đang diễn ra

Bạn của chúng ta, Mario, đã đứng lên tại AI Engineer Europe và cầu xin chúng ta hãy chậm lại — bởi vì các công ty vốn không đáng phải chịu sự cố do sai sót của tác nhân lập trình (coding-agent), thì nay lại đang... gặp sự cố do chính những sai sót đó.

Như Matt Pocock đã nói, các cơ sở mã (codebase) đang sụp đổ nhanh hơn bao giờ hết.

Tôi vẫn chưa thể tìm ra bất kỳ dữ liệu/kết quả xác thực nào từ StrongDM về việc nhà máy "tắt đèn" đó đã hoạt động ra sao. Các bản tin cập nhật khá thưa thớt từ tháng 2 đến tháng 6 năm nay. chỉnh sửa - có một cuộc thảo luận với nhóm trên hacker news vào ngày 23 tháng 7 - có vẻ như chúng ta sắp có một bản cập nhật chính thức hơn!

Các chuyên gia tại Faros AI đã đưa ra một báo cáo: kể từ khi tất cả chúng ta2 bắt đầu sử dụng các công cụ lập trình AI này vào tháng 1 và tháng 2, chất lượng đánh giá pull-request đã giảm sút nghiêm trọng.

Báo cáo này thiên về tín hiệu tương quan hơn là bằng chứng xác thực3, và toàn bộ mục đích của bài viết này là cảnh giác với dữ liệu rác (slop data), nhưng nó có vẻ đúng về mặt định hướng dựa trên những gì tôi đã thấy.

"Bạn đang cầm sai cách" (thực ra là không phải)

Rất nhiều người sẽ nói với bạn rằng đây là vấn đề về kỹ năng — rằng nếu bạn không đạt được kết quả tốt, đó là lỗi của bạn.

Nhưng dù bạn chọn cách... ừm... cầm nó như thế nào, tôi đảm bảo bạn vẫn sẽ được bảo rằng nếu việc "tối đa hóa token" (token-maxxing) không hiệu quả với bạn, thì đó là do kỹ năng của bạn. Bạn chỉ cần tiêu tốn nhiều token hơn. Hãy từ bỏ việc đọc mã đi. Và nếu bạn mới bắt đầu, tôi hứa đó là một phần của quá trình tiến bộ. Mùa hè năm ngoái tôi cũng từng nghĩ như vậy.

Thật không may cho cái tôi của tôi, một vài điều ngớ ngẩn mà tôi quyết định nói về "cách cầm nó tốt hơn" đã được ghi lại và hiện có khoảng một triệu lượt xem trên YouTube. Tôi không cố khoe khoang ở đây, tôi chia sẻ điều này chỉ để khẳng định rằng tôi đã nghiên cứu sâu về những cách tốt nhất để sử dụng các tác nhân lập trình trong một thời gian dài, và đã khám phá ra một số điều mà nhiều người khác thấy thực sự hữu ích.

Dù sao đi nữa, lời hứa hẹn từ tất cả những lời tán gẫu "chỉ cần dùng nhiều token hơn" trên mạng mà chúng ta buộc phải chịu đựng, tóm lại là: với đủ kỹ thuật khai thác (harness engineering), chúng ta có thể đạt được lợi ích từ cả hai thế giới:

Tất cả những gì chúng ta phải làm là cấu hình thêm nhiều linter và rắc thêm vài từ ma thuật như "đánh giá đối kháng" (adversarial review) vào đủ các bot đánh giá PR, và phần mềm của chúng ta sẽ tự xây dựng một cách vui vẻ mà không gặp sự cố.

Đây không phải là vấn đề về kỹ năng

Điều tôi sẽ cố gắng thuyết phục bạn là không lượng kỹ thuật khai thác hay "tối đa hóa vòng lặp" (loopsmaxxing) nào có thể giải quyết được vấn đề về cơ bản là nằm ở khâu huấn luyện mô hình.

Để giải quyết vấn đề này, tôi đã phải đào sâu vào cách các mô hình lập trình thực sự được huấn luyện và đánh giá - xét trên cả khía cạnh RLVR và các tiêu chuẩn đánh giá (benchmark).

Trong bài viết này, tôi sẽ đi qua:

Tôi sẽ cố gắng cắt bỏ sự cường điệu của mọi plugin kỹ năng xuất hiện hàng ngày và đại dịch lời khuyên "tối đa hóa token do ảo tưởng AI", và nói về các loại hình hiệu quả theo thuật ngữ chung mà không cần tham chiếu đến bất kỳ kỹ năng hay khuôn khổ cụ thể nào.

Phiên bản video: bài viết này dựa trên (và mở rộng từ) bài phát biểu chính của tôi tại AI Engineer World's Fair 2026.

Cảm ơn @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, và @jeffreyhuber vì những phản hồi cho bài viết này.

Một lưu ý bên lề: điều này không liên quan gì đến "vibe coding"

Addy Osmani đã làm rõ một điều đáng chú ý:

Một lập trình viên đang "vibe coding" cho một dự án phụ mà chỉ vài người chạy, và một đội ngũ đang duy trì một hệ thống doanh nghiệp mười năm tuổi thêm một quý nữa, hầu như không chia sẻ bất kỳ ràng buộc nào đáng kể, và hầu hết các lời khuyên đang lưu hành thực chất là một trong hai người đó đang dạy người kia cách sống.

Nếu bạn yêu thích vibe coding, làm ơn, hãy cứ tiếp tục tận hưởng nó. Tôi vẫn vibe coding rất nhiều thứ, tôi chỉ là cũng duy trì rất nhiều phần mềm thực tế (và thông qua HumanLayer, giúp hàng ngàn kỹ sư khác làm điều tương tự), vì vậy phần còn lại của bài viết này nhắm vào những người đang giải quyết các vấn đề khó trong các cơ sở mã phức tạp.

Tôi nghe từ "brownfield" rất nhiều khi nói về sự phân chia này. Trong lịch sử, nó có nghĩa là một thứ gì đó bằng Java mười năm tuổi, nhưng với tốc độ chúng ta có thể phát hành hiện nay, có vẻ như một cơ sở mã do tác nhân (agent) xây dựng bắt đầu gặp khó khăn sau khoảng ba đến sáu tháng — bạn bắt đầu chậm lại, và cách bạn tiếp cận việc thêm các tính năng mới phải thay đổi.

Lịch sử tóm tắt về nhà máy phần mềm

Tôi đã xây dựng và nghiên cứu các nhà máy phần mềm trong suốt sự nghiệp của mình, nhưng tôi chỉ mới biết điều này gần đây: thuật ngữ này bắt nguồn từ một hội nghị của NATO vào năm 1968 — chính là hội nghị đã mang đến cho chúng ta khái niệm "kỹ thuật phần mềm" (software engineering).