Trong quá khứ, các nhà máy công nghiệp đã thay đổi hoàn toàn cách thế giới sản xuất hàng hóa vật chất: năng suất cao hơn, chi phí thấp hơn và tốc độ vượt trội. Ngày nay, một sự chuyển dịch tương tự đang diễn ra trong lĩnh vực phát triển phần mềm. 🛠️
Sự xuất hiện của các Mô hình Ngôn ngữ Lớn (LLM) đã giảm rào cản viết mã, tăng năng suất cá nhân và thôi thúc các tổ chức nhìn nhận việc phát triển phần mềm như một hệ thống sản xuất. Tuy nhiên, các quy trình phát triển phần mềm truyền thống và thực hành CI/CD đã tồn tại hàng thập kỷ có thể không còn phù hợp dưới áp lực này. Đó là lúc khái niệm 'nhà máy phần mềm' ra đời – và giống như các nhà máy vật chất, nó cần nhiều hơn là tốc độ để thực sự hoạt động hiệu quả. 💡
Ý tưởng về một 'nhà máy phần mềm' đã trở nên rõ ràng hơn trong năm qua. Theo Luca Rossi trong bài viết 'Kỷ nguyên Nhà máy Phần mềm' (Nguồn: https://refactoring.fm/p/the-era-of-the-software-factory), AI không chỉ thay đổi tốc độ viết mã của con người mà còn biến đổi toàn bộ hệ thống sản xuất phần mềm. Khái niệm này có thể mang nhiều ý nghĩa khác nhau: một bộ sưu tập các tác nhân mã hóa (coding agents), tệp kỹ năng, CI/CD nhanh hơn, hệ thống đánh giá tốt hơn hoặc tự động hóa nhiều hơn trong việc triển khai phần mềm. Tuy nhiên, cách tiếp cận tốt hơn là xem nó như một tập hợp các nguyên tắc hơn là một danh mục công cụ. Một nhà máy phần mềm không thể chỉ là một tập hợp lỏng lẻo các lời nhắc, tác nhân và plugin. Nó cần một nền tảng định nghĩa cách công việc di chuyển qua hệ thống và cách mã được tạo, xem xét, thử nghiệm, truy vết, triển khai và cải thiện khi có vấn đề xảy ra. Nếu không, tất cả những gì bạn đang làm chỉ là đặt thêm một cỗ máy riêng lẻ vào một căn phòng trống và gọi đó là một nhà máy.
Vì sao điều này lại xảy ra ngay lúc này? 🚀
Có một vài yếu tố đang hội tụ cùng lúc: * Nhu cầu không ngừng tăng: Các công ty luôn muốn có nhiều phần mềm hơn khả năng các kỹ sư có thể tạo ra. Đó là lý do tại sao các công cụ như Excel tồn tại: chúng thường lấp đầy khoảng trống cho rất nhiều phần mềm mà nhiều công ty mong muốn có thể tạo ra. * AI hạ thấp rào cản: AI đã giảm rào cản gia nhập vào việc tạo mã, và đây là phần mà mọi người đều tập trung vào. Việc tạo mã giờ đây dễ dàng hơn, mặc dù không phải lúc nào cũng rẻ hơn hoặc tốt hơn, bằng chứng là nhiều công ty lớn đang 'đau đầu' về hóa đơn AI cao ngất ngưởng của họ (Nguồn: https://fortune.com/article/why-is-the-cost-of-ai-higher-than-human-workers-nvidia-executive/). Rào cản để viết mã chức năng đã thực sự sụp đổ. * Thay đổi điểm nghẽn: Quan trọng hơn, một kỹ sư duy nhất có thể tạo ra nhiều mã hơn so với vài năm trước. Điều đó làm thay đổi điểm nghẽn: không còn là 'Một người có thể viết cái này nhanh đến mức nào?' hoặc thậm chí, trong một số trường hợp, 'Có ai hiểu cách viết mã không?'. Thay vào đó, câu hỏi trở thành: 'Liệu mã này có nên được viết ra không?' Quan trọng hơn, chúng ta có thực sự có thể tạo ra các sản phẩm cuối cùng bền vững và đáng tin cậy mà không chỉ chất chồng 'nợ kỹ thuật'? Hay chúng ta chỉ đang đẩy ra nhiều 'sản phẩm AI cẩu thả' nhanh hơn bao giờ hết? Đó chính là nơi ẩn chứa mối nguy hiểm. ⚠️
Những hiểm họa của "nhà máy phần mềm" hiện đại 😱
Tất cả những điều này nghe có vẻ tuyệt vời. Rốt cuộc, các nhà máy đã giúp sản xuất nhanh hơn và nhất quán hơn. Chúng giúp sản xuất nhiều ô tô và sản phẩm hơn, với chi phí thấp hơn, dẫn đến nhiều người hơn có khả năng mua sắm. Bỏ qua tác động môi trường, bạn có thể lập luận rằng đây là một điều tích cực.
Nhưng giống như nhiều điều trong kỹ thuật, luôn có sự đánh đổi, và trong trường hợp này, có những rủi ro mới.
Khi bạn tăng năng suất của một người bằng máy móc, dù là kỹ thuật số hay không, bạn cũng tăng số lỗi có thể mắc phải, bởi cá nhân hoặc máy móc. Tốc độ mã có thể được tạo ra hiện nay đang ở quy mô công nghiệp. Ngay cả các tổ chức nhỏ hơn cũng có thể đột nhiên có các cơ sở mã phình to bằng kích thước các cơ sở mã của các công ty công nghệ một thập kỷ trước.
Dữ liệu đã cho thấy các vấn đề. Faros AI phát hiện rằng trong khi thông lượng tác vụ trên mỗi nhà phát triển tăng 33,7% và tỷ lệ hợp nhất PR (Pull Request) tăng 16,2%, thì tỷ lệ sự cố trên PR đã tăng 242,7% và số lỗi trên mỗi nhà phát triển tăng 54% (Nguồn: https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways). Nghiên cứu DORA của Google cũng nhận thấy rằng việc áp dụng AI nhiều hơn thực sự liên quan đến sự ổn định phân phối kém hơn (Nguồn: https://dora.dev/ai/gen-ai-report/report/).
Với vai trò là trưởng phòng dữ liệu bán thời gian, tôi đã được mời đến để khắc phục chính những vấn đề này. Chỉ riêng trong năm qua, tôi đã làm việc trên hai dự án mà hạ tầng dữ liệu do AI tạo ra dần dần biến đổi theo thời gian. Giữa nhiều kỹ sư cố gắng làm việc nhanh chóng và thiếu các tiêu chuẩn, các dự án này trở nên khó kiểm soát. Các cơ sở mã thường trải qua một mức độ tiến hóa nhất định, nhưng khi các phong cách khác nhau hòa trộn, các LLM lại bắt đầu tạo ra những đột biến riêng của chúng. Các cơ sở mã phát triển năm đến sáu phong cách khác nhau chỉ trong vài tháng – một quá trình mà trước đây phải mất nhiều năm. Lớp chồng lớp (Nguồn: https://seattledataguy.substack.com/p/layer-by-layer-we-built-data-systems), các kỹ sư dần dần không còn hiểu chính xác điều gì đang diễn ra.
Mô hình này lặp lại những gì đã xảy ra một thập kỷ trước với các công cụ tự phục vụ: những lợi ích năng suất ban đầu che giấu sự phức tạp ở giai đoạn sau. Và đó là lý do tại sao 'nhà máy phần mềm' không thể chỉ đơn thuần là về tốc độ.
Vậy điều gì làm nên một "nhà máy phần mềm" hiệu quả? ✅
Có một số nguyên tắc chính cần xem xét khi xây dựng một nhà máy phần mềm: * Nền tảng thay vì công cụ: Nhiều nhóm đang dần triển khai AI vào quy trình làm việc viết mã của họ ở các rìa – thêm một tác nhân đánh giá PR hoặc một tệp kỹ năng vào kho lưu trữ của họ. Nhưng xây dựng một nhà máy phần mềm thực sự đòi hỏi một nền tảng, không phải một bộ sưu tập các công cụ rời rạc. Một nền tảng cung cấp một nền tảng thống nhất nơi các công cụ không bị phân tán ở các góc riêng biệt. Thay vào đó, chúng tích cực chia sẻ dữ liệu, giao tiếp với nhau và hoạt động như một hệ thống gắn kết duy nhất – các tiêu chuẩn, quy trình và chính công việc đều được kết nối. * Khả năng chạy lại và truy vết: Một nền tảng thực sự yêu cầu khả năng quay lại bất kỳ lần chạy nào, xác định điều gì đã sai và chạy lại nó – đó là lý do tại sao các tác nhân một lần không tạo nên một nhà máy. Hệ thống cần hỗ trợ việc lấy một ID nối tiếp, tra cứu nó và truy vết chính xác cách nó đạt được kết quả đầu ra đã tạo ra. Đây là lý do tại sao các máy trạng thái (state machines) có ý nghĩa hơn các vòng lặp (loops) cho các quy trình làm việc AI: chúng giúp việc chạy lại một quy trình và hiểu điều gì đã xảy ra ở mỗi bước dễ dàng hơn nhiều. * An toàn và rào cản bảo vệ: Các nhà máy không phải là nơi an toàn. Nhà máy phần mềm cũng vậy. Khi nhiều người phát triển trên các nền tảng này, các rào cản bảo vệ và biện pháp an toàn tốt hơn cần được xây dựng. Việc kiểm thử và kiểm soát chất lượng cần được đẩy lên phía trước của quy trình – bắt lỗi ở giai đoạn sớm nhất có thể sẽ giảm chi phí khắc phục và hạn chế phạm vi ảnh hưởng. * Tiêu chuẩn hóa: Ở cấp độ doanh nghiệp, mỗi cơ sở mã có phong cách riêng. Việc đặt một trợ lý mã lên trên mà không có tiêu chuẩn sẽ tạo ra một sự pha trộn phong cách lộn xộn. Tiêu chuẩn hóa phải được xây dựng vào quy trình ngay từ đầu. * Kiểm soát chất lượng: Trong các mô hình sản xuất cũ, kiểm soát chất lượng diễn ra ở cuối dây chuyền. Sản phẩm được xây dựng, kiểm tra, phát hiện lỗi và sửa chữa sau đó. Cách tiếp cận của Toyota khác (Nguồn: https://global.toyota/en/company/vision-and-philosophy/production-system/). Chất lượng được đưa vào chính quy trình – công nhân được yêu cầu dừng dây chuyền khi có điều gì đó sai. Mục tiêu không phải là bắt lỗi ở cuối; mà là ngăn chặn chúng chảy xuống giai đoạn sau ngay từ đầu. Điều tương tự cũng đúng với nhà máy phần mềm. QC cần được tích hợp vào toàn bộ quy trình, bắt đầu từ cách viết đặc tả. Điều đó có nghĩa là tích hợp phân tích mã tĩnh (static code analysis) để bắt các lỗi rõ ràng và cung cấp các mẫu cho LLM để chúng biết cấu trúc mã cần tuân theo. Nếu không có điều đó, điểm nghẽn sẽ trở thành khâu xem xét cuối cùng – hoặc các nhóm chỉ đơn thuần là đẩy ra nhiều 'sản phẩm AI cẩu thả' hơn.
Tốc độ không đi kèm chất lượng không phải là năng suất thực sự! 💡
Cải thiện tốc độ đầu ra mã của bạn không phải là năng suất thực sự nếu các vấn đề ở giai đoạn sau không được quản lý. Một công ty không năng suất hơn vì nó sản xuất hàng triệu ô tô, chỉ để thấy tất cả chúng hỏng hóc trong vòng 100 dặm. Nó cũng không năng suất hơn nếu tất cả những gì nó làm là sản xuất một dòng chảy vô tận các 'bằng chứng khái niệm' (proofs-of-concept) mà không bao giờ đi vào sản xuất.
Năng suất thực sự là khi nhà máy phần mềm biến các token phù du thành các sản phẩm bền vững. Thật dễ dàng nói về số dòng mã và đội của bạn đang di chuyển nhanh hơn bao nhiêu.
Nhà máy phần mềm giành chiến thắng không phải là nhà máy tạo ra nhiều mã nhất. Đó là nhà máy tạo ra ít lỗi nhất ở các giai đoạn sau. 🏆