Vibe coding khiến bus factor về 0
(mindflash.org)- Trong phát triển phần mềm, Bus Factor là khái niệm thể hiện cần có bao nhiêu người nắm giữ tri thức thì mới có thể duy trì dự án; trước đây trong trường hợp xấu nhất giá trị là 1
- Tuy nhiên, sau khi ChatGPT được công bố (30/11/2022), cùng với việc AI tạo sinh được phổ cập rộng rãi, nhiều người không còn trực tiếp lưu giữ tri thức mà phụ thuộc vào AI, dẫn đến trên thực tế xuất hiện tình trạng bus factor bằng 0
- Trong thực tế lập trình, ngày càng nhiều lập trình viên dùng nguyên xi mã và tính năng do LLM tạo ra, từ bỏ nỗ lực hiểu codebase và chuyển sang “vibe coding”
- Vì vậy, khi sửa lỗi, vá bảo mật hoặc mở rộng tính năng, có thể phải đối mặt với tình huống không ai biết vì sao đoạn mã lại được viết như vậy
- Điều này gây ra rủi ro nghiêm trọng đối với độ tin cậy và bảo mật phần mềm, và cho đến khi AI có thể tạo ra mã hoàn hảo một cách hoàn hảo, vẫn sẽ tồn tại giới hạn mang tính nền tảng
Khái niệm và lịch sử của bus factor
- Bus factor là khái niệm biểu diễn bằng con số việc một tri thức cụ thể được chia sẻ cho bao nhiêu người
- Ví dụ: nếu có 3 người biết cách khôi phục bản sao lưu cơ sở dữ liệu thì bus factor của chức năng đó là 3
- Theo truyền thống, giá trị tệ nhất là 1; nếu một người đánh mất tri thức đó thì không thể tiếp tục duy trì dự án
- Để vượt qua điều này, nhân loại đã lan truyền tri thức bằng vô số cách như tài liệu hóa, đào tạo, chuyển giao tri thức, hội thảo, trường học
- Điều đó đã dẫn tới những nỗ lực có hệ thống nhằm truyền thừa và bảo tồn tri thức, với rất nhiều nhân lực và thời gian được đầu tư
AI được đưa vào và bus factor 0
- Tháng 11/2022, việc ra mắt ChatGPT đã mở ra kỷ nguyên “AI First”
- Trong quá trình AI tạo ra mã và tính năng, nhiều người bị loại khỏi vai trò chủ thể lưu giữ tri thức và bắt đầu phụ thuộc vào sản phẩm do AI tạo ra, khiến mức độ hiểu dự án sụt giảm mạnh
- Kết quả là xuất hiện trạng thái hoàn toàn không có người nắm giữ tri thức, tức tình huống bus factor 0
- Các lập trình viên cho thấy xu hướng không tự viết hay tự hiểu mã và tính năng, mà ủy quyền hoàn toàn cho AI
- Trong quá trình này, các nhà phát triển né tránh việc hiểu codebase và tài liệu hóa, thay vào đó chỉ đơn giản yêu cầu AI giải thích lại
Vấn đề của việc lập trình dựa trên LLM
- Bỏ qua vấn đề chất lượng mã, điểm cốt lõi là việc đọc và bảo trì vốn dĩ khó hơn viết
- Trước đây, ít nhất mentor hoặc tài liệu còn cung cấp được một mức hỗ trợ tối thiểu, nhưng trong môi trường phụ thuộc AI thì ngay cả lưới an toàn đó cũng biến mất
- Trong phát triển dựa trên LLM, quá trình sinh mã không được ghi lại, và ngay cả AI cũng không nhớ được ngữ cảnh của đoạn mã mà chính nó đã tạo ra
- Cuối cùng, các lập trình viên rơi vào tình huống phải phân tích và chỉnh sửa đoạn mã do AI viết nhưng ngữ cảnh lại không rõ ràng
- Điều này dẫn đến trạng thái không ai có thể biết được ý đồ và cấu trúc của mã trong các việc như xử lý bug, vá lỗ hổng bảo mật hay nâng cấp dependency
Rủi ro từ góc nhìn người dùng
- Không chỉ nhà phát triển mà người dùng cũng bị đặt vào vòng rủi ro
- Phần mềm mà họ tải lên tài liệu cá nhân, thông tin thẻ tín dụng, ảnh riêng tư hay suy nghĩ cá nhân có thể đã được tạo bằng đoạn mã mà không ai biết cấu trúc nội bộ và mục đích của nó
- Điều này hàm chứa rủi ro nghiêm trọng về bảo vệ dữ liệu và độ tin cậy, đồng thời làm dấy lên nghi vấn về tính ổn định của dịch vụ
Kết luận
- Vibe coding dẫn đến bus factor 0 về bản chất là một cách tiếp cận có khiếm khuyết
- Đây là giới hạn không thể tránh khỏi cho tới khi AI có thể tạo ra mã chính xác 100% từ prompt chính xác 100%
- Vì vậy, trong tình hình hiện tại, bên cạnh việc tận dụng AI, không thể xem nhẹ tầm quan trọng của việc lưu giữ tri thức và hiểu mã, và việc duy trì hệ thống quản lý tri thức cùng quy trình tài liệu hóa là điều bắt buộc
3 bình luận
Chẳng phải hệ số bus đã trở thành vô hạn sao?
Nếu nhà phát triển thuộc công ty không có kiến thức thì bus factor sẽ tiệm cận về 0.
Ý kiến Hacker News
Việc dùng LLM để cứ thế tạo ra một lượng lớn mã chưa được review là cách sử dụng sai; điều đó đồng nghĩa dự án sẽ đi chệch hướng về mặt cấu trúc hoặc sẽ sớm không thể bảo trì khi phát sinh các bug phức tạp Điểm mạnh thực sự của LLM là trong những tình huống như: cần áp dụng một thuật toán nổi tiếng lên cấu trúc dữ liệu phức tạp sẵn có, dựng bộ khung cho test data hay unit test có nhiều dependency, tạo visual web editor cùng backend API rồi gắn thêm chức năng lưu vào sqlite, hoặc áp dụng các thay đổi lặp đi lặp lại trên codebase lớn mà ngay cả regex phức tạp cũng khó xử lý, v.v. Trên thực tế, nhờ LLM mà những việc mất nửa ngày hay 3 ngày có thể được khởi động chỉ trong 2 phút Điều quan trọng là dù LLM không giải được các bài toán cực khó thì năng suất vẫn có thể tăng mạnh Có thể thoát khỏi những việc lặp lại nhàm chán để tập trung vào các vấn đề thú vị hơn
Tôi từng nghĩ LLM sẽ xử lý xong các thay đổi lặp lại trên codebase lớn trong 2 phút, nhưng khi tự thử với nhiều model lớn thì thấy bối cảnh càng phức tạp, lỗi càng tích tụ, đôi khi còn phát sinh cả những thay đổi không liên quan, nên rốt cuộc không thể tin cậy được Với ví dụ nhỏ thì hoàn hảo, nhưng càng mở rộng quy mô càng yếu Có thể cải thiện bằng agentic loop, nhưng phải chạy/review lặp đi lặp lại nên cuối cùng còn tốn thời gian hơn nhiều Bảo LLM viết một chương trình để tự động hóa việc thay đổi thì đáng tin hơn hẳn
Các ví dụ được nêu ra đều có vẻ tốt, nhưng trên thực tế số trường hợp dùng được còn nhiều hơn thế Bạn đang nói từ góc nhìn của một lập trình viên dày dạn, nhưng những người ít kỹ năng kỹ thuật hoặc mới học cũng đã có thể làm được nhiều việc hơn nhờ LLM Những việc trước đây phải trả 100 đô cho người khác giờ có thể tự thử làm trong 3 phút Việc kết quả có hoàn hảo và bảo trì được hay không thậm chí trở nên kém quan trọng hơn; việc cho thấy khả năng làm được mới có giá trị lớn hơn
Tôi đồng ý với ý kiến của bạn, nhưng muốn chia sẻ một trải nghiệm khá buồn cười gần đây Tôi nhờ Claude viết unit test, và khi review thì hóa ra code của tôi thật sự có bug, test đã tìm ra nó Nhưng thay vì sửa bug, Claude lại cho pass bằng cách không chạy luôn cái test bị fail đó; đúng là một giai thoại hài hước ngoài đời thực LLM yếu ở việc định nghĩa yêu cầu, thiết kế kiến trúc, viết đặc tả phù hợp với yêu cầu; còn lại mạnh ở những việc có phạm vi rõ ràng và tác động giới hạn như viết code
Tôi đã thử áp dụng một bước trung gian kiểu để AI tự động review PR trước rồi mới review thủ công Việc sinh code mất 5~10 phút, còn review và commit bổ sung thường mất 1~3 giờ, nhưng tôi đã áp dụng thành công cách này trên nhiều dự án (10~20k LOC, khoảng 100 file) Nếu đưa đặc tả tốt thì nhiều tính năng được triển khai gần như chính xác mà không cần sửa lớn, chủ yếu là refactor dựa trên feedback Tất nhiên khi nó không hoạt động đúng thì cũng có lúc mất gần cả ngày để xử lý, nhưng nhìn chung năng suất tăng 3~5 lần Với dự án lớn thì có vẻ tốt hơn nếu chia nhỏ và mô-đun hóa
Cách nói kiểu "LLM hoàn thành khối lượng công việc x ngày chỉ trong 2 phút" hơi phóng đại vì không tính thời gian review Nếu cộng cả quá trình review và kiểm chứng thực tế thì sẽ mất nhiều thời gian hơn rất nhiều Ngược lại còn dễ rơi vào đúng cái “cách làm sai” được nói lúc đầu
Bài này nêu ra khá nhiều vấn đề của việc AI sinh code, nhưng có vẻ không xem xét những cách giải quyết đã có hoặc có thể xuất hiện trong tương lai Trước đây cũng vậy, chỉ cần đội ngũ bỏ ra mức công sức tối thiểu với codebase thì người mới vào đã có thể được hỗ trợ để hiểu code Tôi tự hỏi không biết tác giả có thiếu kinh nghiệm với legacy code không, hay thật sự nghĩ rằng chuyện AI "quên toàn bộ ngữ cảnh của quá trình viết ban đầu" là điều không thể sửa được Vấn đề Bus Factor 0 cũng đang bị hiểu sai như thể chỉ có thể giải quyết nếu chính xác hoàn toàn 100%, trong khi con người cũng đâu phải lúc nào cũng đúng 100%, nhưng ta vẫn tin họ
Tôi cảm thấy bài viết nhìn vấn đề quá rút gọn Thực tế là ngay từ đầu đã luôn tồn tại chuyện ta không thể làm mọi việc cùng chính tác giả Chỉ riêng việc có pair hoặc AI giải thích cho mình thôi cũng đã là một bước tiến khổng lồ Cứ như đang tưởng tượng một thế giới không có con người, nhưng thật ra chúng ta đã thường xuyên gặp tình huống đó rồi
Tôi là tác giả, và tôi đồng ý với nhận xét đầu tiên, cũng như nghĩ rằng AI rồi sẽ thu hẹp khoảng cách này Nhưng đến lúc đó thì một số vấn đề có thể đã xảy ra rồi Cũng có vấn đề là để lại code mà không có ngữ cảnh logic hay lịch sử thao tác Người ta hay nói AI "luôn học hỏi", nhưng thực tế là nó không học gì thêm cho tới khi model mới ra mắt Con người cũng không chính xác 100%, nhưng không phải Bus Factor 0; việc nhận diện và xử lý vấn đề dễ hơn Nếu các vấn đề còn lại cũng được giải quyết thì vấn đề bus factor cũng sẽ giảm đi
Tôi từng nghĩ giá như hồi phân tích legacy code đã có tool AI Kiểu những tình huống dở khóc dở cười như: "Người cuối cùng sửa file Perl này giờ là giám đốc chi nhánh, vậy mình phải tự đặt lịch họp với ông ấy à?" thực sự đã từng xảy ra
Với câu hỏi "Tại sao phải chính xác 100%?", tôi nghĩ những người chỉ trích AI lại thường có xu hướng kỳ vọng AI phải là một lời giải hoàn hảo như phép màu Nó hơi giống sắc thái của việc ai đó phản đối static typing rồi phàn nàn rằng "nó còn không bắt được cả lỗi logic"
Dạo này blog nào cũng có quá nhiều hình ảnh do AI tạo ra, đến mức còn gây xao nhãng và nhiều khi chẳng giúp gì cho nội dung
Gần đây tôi gia nhập một team có codebase rất tệ, phần lớn lập trình viên cũ đã rời đi, mà cả những người còn lại cũng không hiểu code lắm Gần như đúng nghĩa bus factor 0 Điều đáng ngạc nhiên là AI đã cải thiện đáng kể tốc độ hiểu code, nắm ý đồ và debug Tôi bắt đầu trích xuất tài liệu trực tiếp từ chính code bằng AI Tài liệu hóa hay truyền miệng đều có thể bị méo mó, còn code mới là sự thật Với sự trợ giúp của AI, tôi có thể tạo ra một môi trường nơi code tự giải thích được, và cảm nhận được mức tăng năng suất rất lớn
Trước cả khi LLM xuất hiện, Bus Factor đã luôn là một vấn đề Phần lớn công ty không cấu trúc công việc sao cho nhiều người cùng hiểu được từng phần Dù nhiều người được phân vào các mảng khác nhau, khối lượng công việc vẫn cứ tăng lên, và cuối cùng lại lặp lại tình trạng không ai hiểu hết mọi thứ Để tránh hoàn toàn điều này thì cần quản lý kỹ thuật rất mạnh, như luân chuyển con người trong codebase, nhưng thường không làm trọn vẹn được vì áp lực tốc độ Tôi đã tổng kết lại hồi tưởng kinh nghiệm CTO liên quan đến chuyện này thành một cuốn sách ở đây và công khai không đặt nặng giá bán Tôi nghĩ về nguyên lý thì môi trường xây hệ thống bằng LLM cũng không khác mấy môi trường dùng 10 lập trình viên outsource
Bus Factor đã là vấn đề từ trước thời LLM, và là một thuật ngữ chuyên môn có từ lâu TFA nói rằng trước đây Bus Factor là 1, còn bây giờ xu hướng là đang tiến hẳn về 0, và đó mới là điều bị phê phán
Khối lượng công việc chỉ ngày càng phình to, chứ thực tế công việc không tiến theo hướng đáng khuyến khích hơn mà chỉ lặp lại kiểu làm cho xong để kịp deadline Chỉ dựng vài chướng ngại trong quy trình thì không giải quyết được
Não bộ của chúng ta có xu hướng tiết kiệm năng lượng với những thông tin không dùng thường xuyên, nên càng xa rời thứ gì đó thì ta càng khó hiểu hoặc quên nó đi Kể cả có tự review toàn bộ code thì kỹ năng cuối cùng vẫn có thể mai một Nó cũng giống như kỹ sư làm công việc quản lý quá lâu thì gần như không còn giải được vấn đề kỹ thuật nữa Trong tự động hóa ô tô cũng vậy, việc duy trì giai đoạn trung gian (level2→5) với con người liên tục can dự là rất khó, và nếu máy móc không đáng tin 100% thì sớm muộn cũng thành vấn đề
Có một điểm thật sự quan trọng trong cuộc thảo luận này: thực ra những tool và workflow kiểu này mới chỉ ở giai đoạn khởi đầu Tôi tin rằng về sau AI có thể giải những vấn đề này tốt hơn cả con người Tôi cũng đã thử nghiệm với việc tận dụng LLM, có phần thành công, có phần thất bại, nhưng trong một số lĩnh vực nhất định nó cho thấy năng lực thực sự vượt trội LLM không biết ngại, nên có thể cập nhật tài liệu, comment, README, ADR rất kỹ lưỡng Nếu có đủ hướng dẫn và cấu trúc, thì về lâu dài codebase do LLM tham gia có khi còn dễ onboard hơn, vì tài liệu hóa có xu hướng tốt hơn nhiều
Tôi nghĩ bài viết đang bỏ qua chuyện chỉ từ bản thân code thôi cũng đã có thể đọc ra ý đồ ở mức đáng kể Con người, và có lẽ cả LLM nữa, là những thực thể khá dễ đoán Phần lớn đều giải những vấn đề tương tự bằng những cách tương tự Nhìn vào cách code được viết, ta có thể lần ra manh mối về việc ai đã giải quyết vấn đề gì, khi nào và vì sao Tất nhiên vẫn có nhiều thông tin bị che khuất, nhưng điều tương tự cũng xảy ra ở những tổ chức có thành viên thay đổi thường xuyên
Tôi nghĩ quá trình tư duy của con người cuối cùng cũng được phản ánh vào trong code, nhưng dù vậy nó vẫn kém xa việc có một người thật để hỏi trực tiếp Reverse engineering thường chỉ làm khi thật sự cần, nhưng với legacy code thì cuối cùng ai cũng phải làm Tuy nhiên xét về năng suất thì đó không phải điều tốt Và codebase do LLM tạo ra không mang một ý đồ thống nhất, mà là sự pha trộn ý đồ của nhiều người khác nhau, nên chỉ nhìn vài mảnh code riêng lẻ lại càng dễ mơ hồ về dụng ý ban đầu Có khi còn khiến người ta lầm tưởng rằng code do AI sinh ra cũng có ý nghĩa chặt chẽ và nhất quán như code do con người viết, nên việc diễn giải lại càng khó hơn
Khả năng hiểu ý đồ chỉ qua code còn phụ thuộc vào phạm vi và quy mô Nếu bị giới hạn 32kB như Arduino thì tương đối dễ hiểu Nhưng trong một platform phức tạp với hàng chục microservice rối vào nhau, nhất là nếu lại được làm theo kiểu 'vibe coding', thì nếu thành trách nhiệm của tôi chắc tôi chỉ muốn bỏ cuộc
Tôi đồng ý với luận điểm và kết luận của bài viết, nhưng trong 20 năm qua tôi đã nhiều lần gặp những tình huống tương tự (không có ai để hỏi, người phụ trách thực tế đều đã rời đi) Nhờ LLM thì chuyện này có thể diễn ra nhanh hơn đôi chút, nhưng tôi nghĩ đây không hẳn là vấn đề hoàn toàn mới mà giống như sự tăng tốc của một vấn đề cũ hơn Tôi hoan nghênh việc nêu ra mối lo này
Ngược lại cũng có thể xảy ra tình huống đối lập Nếu chuẩn bị tốt tài liệu, test, cấu hình để AI có thể tận dụng codebase hiệu quả, thì có thể kỳ vọng 1 năm sau AI agent sẽ làm cùng công việc đó nhanh hơn nữa
Tôi tò mò không biết AI Coding Tool rồi sẽ học được thái độ kiểu như lập trình viên cũ: "Toàn bộ code trước đây đều dở, phải viết lại sạch từ đầu" như thế nào Cũng thú vị nếu sau này chính hệ thống CI/CD sẽ trở thành kiểu AI viết lại toàn bộ dự án từ đầu
Tôi là tác giả, nếu đúng như bạn nói thì lúc đó Bus Factor đã tăng lên rồi Tức là bản chất nằm ở việc thông tin không còn chỉ nằm trong đầu người, mà được lưu trữ và duy trì dưới nhiều dạng khác nhau