Đầu năm nay, nhóm của chúng tôi tại 8090 đã tháo dỡ hệ thống thanh toán của một thực thể lớn. Nó bao gồm 18 triệu dòng mã COBOL và Assembly, được tích lũy từ trước khi một số kỹ sư của chúng tôi ra đời. Không ai còn hiểu trọn vẹn nó nữa, nhưng bằng cách sử dụng Software Factory, chúng tôi đã dịch ngược nó thành hơn 100.000 quy tắc tiếng Anh đơn giản trong 40 ngày. Khi hoàn thành công việc đó, tôi nhận ra tại sao cụm từ "software factory" lại đột nhiên được mọi người khác sử dụng.
Khái niệm này đang được sử dụng lại vì nó hàm ý một mức độ tin cậy công nghiệp mà các doanh nghiệp mong muốn nhưng không đạt được. Các nhà máy phần mềm có 50 năm lịch sử đằng sau, và đặc điểm nổi bật duy nhất của nó là thứ mà các doanh nghiệp cần hơn bao giờ hết - một hệ thống sản xuất đảm bảo đầu ra. Điều này trái ngược với sự thất vọng ngày càng tăng về một bộ công cụ rời rạc giúp trao quyền cho cá nhân nhưng lại khiến toàn bộ hệ thống trở nên hỗn loạn hơn.
Thuật ngữ này lâu đời hơn hầu hết mọi người nghĩ
Hitachi đã mở "Software Works" vào năm 1969 như một nhà máy theo đúng nghĩa đen: một tòa nhà nơi phần mềm được sản xuất dưới sự kiểm soát chất lượng thống kê, với tỷ lệ lỗi được đo trên mỗi nghìn dòng mã, quy trình chuẩn hóa và một đội ngũ quản lý chịu trách nhiệm về chất lượng đầu ra. Toshiba, NEC và Fujitsu đã làm theo, và trong suốt những năm 1970 và 1980, các nhà máy phần mềm Nhật Bản này đã xuất xưởng một số mã đáng tin cậy nhất từng được viết. Các hệ thống họ sản xuất đã vận hành cơ sở hạ tầng ngân hàng, đường sắt và năng lượng trong nhiều thập kỷ.
Năm 2004, hai kiến trúc sư của Microsoft đã xuất bản một cuốn sách có tên "Software Factories", lập luận rằng phần mềm nên được xây dựng giống như cách ô tô được chế tạo: từ các thành phần đã được kiểm chứng, trên dây chuyền sản xuất có thể lặp lại, với sự biến thiên được kiểm soát bởi thiết kế từ trước thay vì được sửa chữa bằng những nỗ lực anh hùng ở phía sau. Không quân Hoa Kỳ vận hành các nhà máy phần mềm ngày nay. Kessel Run xây dựng và vận hành phần mềm nhiệm vụ cho Bộ Quốc phòng, và khi phần mềm đó hỏng, họ chịu trách nhiệm.
Trong suốt 60 năm, một điều luôn nhất quán cho đến làn sóng AI này. Một nhà máy không bao giờ chỉ là một công cụ hay một mẹo tăng năng suất, dù có tốt đến đâu. Một nhà máy là một hệ thống sản xuất nhận đầu vào, tạo ra thành phẩm và đứng sau chất lượng của những thành phẩm đó. Nói cách khác, Ford không bao giờ bán cho bạn một cái cờ lê, một vài bộ phận và chúc bạn may mắn. Ford bán cho bạn một chiếc xe hơi, và nếu chiếc xe hơi bị hỏng, Ford thu hồi nó, bởi vì đó là nhà máy của họ đã sản xuất ra nó.
Đó là tiêu chuẩn, và tôi cho rằng các nhà máy phần mềm hiện đại cũng phải tuân thủ tiêu chuẩn đó.
Năm bài kiểm tra
Một nhà máy phần mềm nên vượt qua năm bài kiểm tra. Thiếu bất kỳ một bài nào, bạn có một thứ khác. Thứ khác đó rất có thể là một công cụ dành cho nhà phát triển, có thể hữu ích, nhưng là một sản phẩm khác với nghĩa vụ khác.
Bài kiểm tra một: một nhà máy bắt đầu từ mục đích kinh doanh. Đầu vào của nhà máy là những gì doanh nghiệp cần, được diễn đạt bằng ngôn ngữ kinh doanh: các yêu cầu, quy tắc, ràng buộc pháp lý, kết quả mong muốn. Nếu đầu vào, thay vào đó, là một ticket Jira do một kỹ sư viết cho một kỹ sư khác, thì bạn đang nhìn vào một công cụ mạnh được gắn vào một quy trình hiện có. Toàn bộ mục đích của một nhà máy là khách hàng mô tả sản phẩm và nhà máy tìm ra cách sản xuất.
Bài kiểm tra hai: một nhà máy duy trì sự mạch lạc dưới sự thay đổi liên tục. Đây là bài kiểm tra khó nhất và là bài kiểm tra mà hầu như không ai trên thị trường công cụ AI nói đến, bởi vì sản phẩm của họ làm cho vấn đề tồi tệ hơn.
Viết mã mới chưa bao giờ là nút thắt cổ chai trong phần mềm doanh nghiệp. Nút thắt cổ chai là một hệ thống thực tế được thay đổi hàng tuần bởi hàng tá người. Mỗi thay đổi là một cơ hội để hệ thống bị xé rời. Yêu cầu lệch khỏi tài liệu. Tài liệu lệch khỏi mã. Mã lệch khỏi bài kiểm tra. Hãy để sự lệch lạc đó tích lũy trong hai mươi năm và bạn sẽ có được hệ thống thanh toán mà tôi đã mô tả ở đầu: 18 triệu dòng mà không ai hiểu trọn vẹn, một hợp đồng bảo trì với các nhà cung cấp tăng 5 đến 8% mỗi năm và một tổ chức không còn có thể thay đổi phần mềm của chính mình mà không sợ hãi.
Thực tế là việc tạo mã làm tăng tốc độ lệch lạc. Nếu các agent của bạn tạo ra lượng mã gấp mười lần so với các đặc tả không được đồng bộ hóa, bạn đang gây ra sự lệch lạc với tốc độ chưa từng có. Vấn đề 18 triệu dòng mất bốn thập kỷ để xây dựng bằng tay, nhưng các đội agent không có sự quản trị sẽ xây dựng điều này trong vài năm.
Một nhà máy phần mềm hoạt động giúp cho mục đích, đặc tả, mã, bài kiểm tra và hành vi sản xuất được đồng bộ hóa như một đối tượng được quản trị duy nhất. Thay đổi yêu cầu và mã thay đổi. Sửa nóng mã và yêu cầu cập nhật. Hãy yêu cầu một nhà cung cấp cho bạn thấy vòng lặp này đã đóng, trực tiếp trên một hệ thống thực. Nếu họ không thể, họ đang bán tính năng tạo mã. Và mặc dù hữu ích, đó là một thứ khác.
Bài kiểm tra ba: một nhà máy hoạt động độc lập với bất kỳ cá nhân cụ thể nào. Một công cụ chỉ tốt bằng người sử dụng nó. Đưa cùng một coding agent cho hai kỹ sư, bạn sẽ nhận được kết quả hoàn toàn khác nhau tùy thuộc vào người viết prompt, người xem xét các diff và người bắt lỗi. Sự khác biệt đó có thể chấp nhận được trong một công cụ. Nó là yếu tố loại trừ trong một hệ thống sản xuất. Một nhà máy nên sản xuất với tốc độ và chất lượng có thể dự đoán được bất kể ai đang làm việc, đó chính xác là những gì các kiểm soát thống kê của Hitachi được xây dựng để đảm bảo: chất lượng như một thuộc tính của dây chuyền, không phải của người vận hành.
Cách một nhà máy đạt được điều này là kiến thức tích lũy trong hệ thống thay vì trong các cá nhân. Khi một người gia nhập, nhà máy trao cho họ mọi thứ nó đã học được. Khi một người rời đi, không có gì ra khỏi cửa. Hầu hết phần mềm doanh nghiệp đều thất bại thảm hại trong bài kiểm tra này. Lý do một hệ thống thanh toán trở nên khó đọc không phải là mã tồi. Đó là sự hiểu biết về mã nằm trong con người, và qua nhiều năm, con người thay đổi. Nếu kiến thức của họ không bao giờ được hệ thống nắm bắt, hệ thống sẽ dần dần trở thành một hộp đen.
Để nói rõ, điều này không có nghĩa là con người không quan trọng hay một nhà máy không đòi hỏi trách nhiệm giải trình. Một nhà máy luôn có một người cụ thể chịu trách nhiệm cho đầu ra. Nó chỉ không bao giờ phụ thuộc vào bất kỳ ai trong số họ là không thể thay thế. Một hệ thống cần một anh hùng để hoạt động thì không có trách nhiệm giải trình cũng không phải là một nhà máy. Nó có một anh hùng, và các anh hùng cuối cùng sẽ tìm thấy những cuộc phiêu lưu mới.
Bài kiểm tra bốn: mọi đơn vị đầu ra đều có thể truy xuất nguồn gốc. Trong một nhà máy thực sự, mọi bộ phận đều có "số lô". Khi một thứ gì đó hỏng, bạn truy vết nó trở lại qua dây chuyền sản xuất đến lô, máy móc và ca làm việc. Các ngành được quản lý yêu cầu chính xác điều này từ phần mềm, và đó là lý do tại sao họ chậm nhất trong việc áp dụng các công cụ mã hóa AI. "Mô hình đã viết nó" không phải là câu trả lời mà kiểm toán viên chấp nhận. Một nhà máy phần mềm tạo ra dấu vết kiểm toán như một sản phẩm phụ của chính quá trình sản xuất: quy tắc này tồn tại vì yêu cầu này, được phê duyệt bởi người này, được thực hiện trong thay đổi này, được xác minh bởi bài kiểm tra này, được triển khai tại thời điểm này. Nguồn gốc phải được xây dựng trong dây chuyền sản xuất, có nghĩa là tài liệu được viết sau đó không được tính.
Bài kiểm tra năm: ai đó chịu trách nhiệm cho thành phẩm. Đây là bài kiểm tra phân biệt một nhà máy phần mềm với một công cụ dành cho nhà phát triển, bởi vì đó là bài kiểm tra mà hầu hết các nhà cung cấp công cụ không sẵn sàng đáp ứng.
Một nhà máy xuất xưởng một sản phẩm mà nó đứng sau. Khi hệ thống thanh toán tính toán sai một yêu cầu bồi thường, khi hệ thống giao dịch tạo ra một con số sai, khi xác thực sản xuất phê duyệt một bộ phận xấu, một người cụ thể sẽ trả lời cho nó, sửa nó và chịu chi phí. Tôi đã đọc rất nhiều hợp đồng công cụ AI và các phần sở hữu trí tuệ dài hàng trang, nhưng phần trách nhiệm giải trình thường chỉ có một câu, và câu đó nói rằng đầu ra được cung cấp nguyên trạng và việc xác minh là vấn đề của bạn. Điều này hoàn toàn không đủ điều kiện cho một nhà máy.
Một trong những khách hàng của chúng tôi, một công ty bảo hiểm y tế đại chúng, đã biến các quy tắc yêu cầu bồi thường phải trả thành một bộ lọc trước xác định và cắt giảm các yêu cầu được chuyển đến một nhà cung cấp trả tiền theo từng lần phát hiện hơn 80%, tránh được hơn 20 triệu đô la trong bốn năm. Những con số như vậy chỉ xảy ra khi bên thực hiện công việc phải chịu trách nhiệm cho kết quả.
Những gì không phải là một nhà máy
Áp dụng các bài kiểm tra, nhiều người tự gọi mình là nhà máy, thay vào đó, lại là một thứ khác.
Các coding agent, dù có tốt đến đâu, cũng chỉ là công cụ. Chúng nhận nhiệm vụ kỹ thuật làm đầu vào, tạo ra mã làm đầu ra và chuyển giao tất cả trách nhiệm xác minh và giải trình cho các kỹ sư của khách hàng. Gọi một đội quân của chúng là nhà máy không thay đổi điều này.
Bảng điều khiển điều phối agent là các công cụ giám sát. Chúng giúp việc theo dõi agent làm việc dễ dàng hơn.
Điểm chuẩn là các công cụ đo lường cho các công cụ. Một điểm số cao cho bạn biết một công cụ giỏi trong các nhiệm vụ được chuẩn hóa. Nó không thể cho bạn biết liệu hệ thống của bạn có duy trì được sự mạch lạc sau hai năm thay đổi liên tục bởi các nhóm hỗn hợp gồm người và agent hay không.
Tại sao định nghĩa lại quan trọng ngay bây giờ
Chi phí sản xuất phần mềm đang giảm mạnh. Và khi chi phí sản xuất giảm, giá trị sẽ chuyển dịch sang những người có thể đảm bảo đầu ra. Điều này đã xảy ra trong mọi quá trình công nghiệp hóa trước đây và nó sẽ lại xảy ra trong AI.
Các công ty khởi nghiệp đang nắm bắt từ "nhà máy" hiểu điều này theo bản năng. Nhưng nhiều người đang vươn tới sự tín nhiệm của sản xuất công nghiệp mà không chấp nhận nghĩa vụ đã tạo ra sự tín nhiệm đó ngay từ đầu.
Vì vậy, hãy bỏ qua các bản demo và điểm chuẩn, và hãy hỏi mọi nhà máy phần mềm một câu hỏi: khi hệ thống hỏng trong sản xuất, ai là người nhận cuộc gọi?
Trong trường hợp của một nhà máy phần mềm, câu trả lời phải là "chúng tôi".
