- Mitchell Hashimoto: "Hiện nay nhiều công ty đang rơi vào một cơn cuồng loạn tập thể nghiêm trọng vì AI, và gần như không thể có một cuộc trò chuyện lý trí với họ"
- Cuộc tranh luận MTBF vs MTTR trong thời đại tự động hóa hạ tầng đám mây nay đã lan sang toàn bộ ngành phát triển phần mềm, và sự mê tín vào AI agent đang tạo ra một dạng cuồng loạn tập thể mới
- Chủ nghĩa tuyệt đối hóa MTTR với kiểu suy nghĩ "agent sẽ sửa bug rất nhanh nên phát hành kèm bug cũng không sao" đang lan tràn, dù đây là lối tư duy đã được chứng minh là thất bại từ thời hạ tầng
- Hệ thống có thể trông khỏe mạnh ở các chỉ số cục bộ nhưng trên tổng thể lại biến chất thành trạng thái không thể hiểu nổi; việc giảm bug report và tăng test coverage không đảm bảo an toàn thực sự
- Khi trực tiếp nêu vấn đề này, cuộc đối thoại thường bị chặn lại bằng những phản bác tức thì như "test coverage đã 100%" hay "bug report đang giảm", cho thấy người ta không nhìn được bức tranh toàn cảnh
- Tốc độ thay đổi quá nhanh khiến không ai nhận ra sự mục ruỗng của kiến trúc nền tảng, trong khi mọi người đang xây nên một "cỗ máy thảm họa có khả năng phục hồi" được tự động hóa
Luận điểm cốt lõi: cơn cuồng loạn tập thể vì AI (AI Psychosis)
- Hiện nay nhiều công ty đang ở trong trạng thái cuồng loạn tập thể vì AI nghiêm trọng, đến mức bản thân việc trò chuyện lý trí với họ cũng là điều bất khả
- Không thể nêu đích danh cá nhân cụ thể vì trong đó có cả những người bạn mà tác giả vô cùng kính trọng
- Tác giả bày tỏ sự lo ngại sâu sắc về cách tình hình này có thể diễn biến tiếp theo
Bài học từ thời hạ tầng: MTBF vs MTTR
- Cuộc tranh luận MTBF (thời gian trung bình giữa các lần hỏng) vs MTTR (thời gian trung bình để khôi phục) từng trải qua trong giai đoạn chuyển đổi lên cloud và tự động hóa cloud nay đang quay trở lại
- Khi đó nó chỉ giới hạn trong lĩnh vực hạ tầng, còn hiện nay đã mở rộng ra toàn bộ ngành phát triển phần mềm (và xa hơn là toàn thế giới)
- Những người sùng bái AI đang vận hành gần như theo tư duy tuyệt đối rằng "chỉ cần MTTR là đủ"
- Logic của họ là: "agent sẽ sửa bug ở tốc độ và quy mô vượt quá khả năng con người, nên phát hành kèm bug cũng không sao"
- Bài học rút ra từ thời hạ tầng: MTTR rất tuyệt, nhưng không thể vứt bỏ hoàn toàn bản thân các hệ thống có khả năng phục hồi
Kiểu phản bác và sự chặn đứng đối thoại
- Khi nêu vấn đề này với những người quen biết ngoài đời, phản ứng nhận được thường là sự gạt đi ngay lập tức
- Những câu như "không đâu, test coverage hoàn hảo mà" hoặc "bug report đang giảm"
- Các phản bác như vậy không cho thấy được bức tranh toàn cảnh
- Tác giả đã trực tiếp chia sẻ mối lo ngại này với họ nhưng không được lắng nghe, nên cho rằng cần phải nói rộng hơn
Cỗ máy thảm họa được tự động hóa
- Một bài học đã từng trả giá trong hạ tầng: thông qua tự động hóa, ta có thể tạo ra một "cỗ máy thảm họa cực kỳ có khả năng phục hồi"
- Hệ thống có thể trông lành mạnh ở các chỉ số cục bộ nhưng trên tổng thể lại trở nên không thể hiểu nổi
- Bug report giảm xuống nhưng rủi ro tiềm ẩn lại tăng vọt
- Test coverage tăng lên nhưng mức độ hiểu nghĩa của hệ thống lại suy giảm
- Thay đổi diễn ra quá nhanh khiến không ai nhận ra sự bào mòn của kiến trúc nền tảng
Các luận điểm trong những phản hồi nổi bật
- @adamhjk: "Thứ mà vibe coding thuần túy phá hủy đầu tiên chính là bản thân kiến trúc", và ngay từ đầu phải có kiến trúc thì mới nhận ra được sự bào mòn
- Mitchell Hashimoto giải thích thêm: với hạ tầng, có thể cập nhật hệ thống online để áp dụng MTTR cho mọi người dùng trong một khoảng thời gian hợp lý; nhưng với thư viện, phần mềm desktop, ứng dụng di động và các phần mềm do người khác tích hợp hoặc tự chạy, cách này không hiệu quả
- @tinygrad: chúng ta đã bước vào thời đại mà việc xác định AI đang nói hoàn toàn sai không còn mất 10 giây mà là 20 phút, và tổ chức cần giữ được điểm tiếp xúc với thực tại
- @beyang: UX của agent hiện tại đang biến "LGTM (Looks Good To Me)" thành con đường ít lực cản nhất, và tốc độ tạo ra đoạn mã trông có vẻ hợp lý của agent đã nâng vấn đề xác minh trong code review thành một mối đe dọa tức thời
- @beh_zod: hàm thưởng của việc phát hành thì ngắn hạn, còn thời gian để mọi người nhận ra khoản nợ đang tích tụ thường vượt quá khoảng chú ý của đa số
- @shipwithjay: khi lãnh đạo kỹ thuật không thể trả lời các câu hỏi phản thực tế (điều gì phải đúng thì ta mới dừng việc này lại?) và chỉ im lặng, đó là một triệu chứng
- @chadfowler: đang viết một cuốn sách về vấn đề này; cốt lõi là tái bố trí tính nghiêm ngặt (rigor) vào kiến trúc và hệ thống đánh giá, và đây là cơ hội để thực hành những best practice trước giờ chưa làm được vì thiếu thời gian và chi phí
Câu trả lời của Mitchell Hashimoto trước các câu hỏi và ý kiến
- Q: "Vậy nên làm gì thay thế?"
- A: "Hãy suy nghĩ (dùng AI, nhưng hãy suy nghĩ)"
- Q: Ông cho rằng ý nghĩ "AI bị thổi phồng quá mức" còn có khả năng là một triệu chứng mang tính hoang tưởng hơn
- A: Mọi xu hướng thế tục đều bị thổi phồng quá mức, nhưng đó không phải là lý do để gạt bỏ tất cả
- Q: "Nếu phải chọn giữa bảo vệ những gì mình đang có và lao vào rủi ro, tôi sẽ chọn phương án thứ hai"
- A: Đây không phải một công tắc nhị phân
1 bình luận
Ý kiến trên Hacker News
Có vẻ tư vấn kiến trúc AI sẽ trở thành một mảng tư vấn giá trị cao lớn, giống như ứng phó sự cố bảo mật hay chuyên gia khôi phục dữ liệu
Các hệ thống do AI viết thuần túy có thể phình lên tới mức độ phức tạp mà con người không thể hiểu nổi, tỷ lệ sửa lỗi thì giảm trong khi số token tiêu tốn cho mỗi lỗi lại tăng, và cuối cùng các thay đổi do AI tạo ra có thể sinh ra nhiều lỗi hơn số lỗi mà chúng sửa, khiến toàn bộ hệ thống trở nên bất ổn
Sẽ cần một quy trình đặc biệt để dọn dẹp mớ hỗn độn đó như trong clean room, rút ra các nguyên tắc thiết kế cốt lõi, rồi có lẽ vẫn dùng AI để xây lại từ đầu
Kỹ nghệ phần mềm trong tương lai có lẽ sẽ xoay quanh các nguyên tắc để tránh chuyện này ngay từ đầu, nhưng cũng như kỹ nghệ phần mềm truyền thống đã mất lâu hơn dự kiến để đi tới các nguyên tắc thiết kế ổn định, có lẽ cũng sẽ mất 20 năm để học được điều đó
Phía bệnh viện còn cấp quyền truy cập máy chủ của bộ phận IT, nhưng vì không thể nối Claude vào nên anh ấy không biết cách triển khai, loay hoay rất lâu rồi liên lạc nhờ giúp, và ứng dụng có vẻ cũng có vài vấn đề thú vị liên quan tới dữ liệu/trạng thái
Nó gợi hình ảnh như một người được giao hàng Amazon miễn phí không giới hạn tới tận nhà; về lý thuyết thì là cuộc sống dư dả, nhưng trên thực tế lại bị chôn vùi dưới một thứ gì đó chứ không phải thịnh vượng
Và ai cũng biết kết cục ra sao
Họ đã hiện thực nửa vời Kubernetes bên trong một Github Actions dài hàng nghìn dòng, hoàn toàn không thể hiểu nổi
Tôi ghét phần marketing AI, nhưng vẫn thấy nó hữu ích như một công cụ giúp người có kinh nghiệm di chuyển nhanh hơn
Chỉ là nếu không phải chuyên gia thì AI dường như sẽ tạo ra các lời giải quá phức tạp cho bất kỳ việc gì người ta muốn làm
Có vẻ điều anh ấy nói không hẳn là việc dùng AI tự nó, mà là hiện tượng công ty và con người thuê ngoài việc ra quyết định và suy nghĩ cho AI
Dùng AI để viết code không phải là AI psychosis hay điều xấu, nhưng nếu chỉ quăng prompt vào rồi tin ngay những gì AI nói thì khá gần với AI psychosis
Tôi thường thấy dân tài chính trên Twitter và các VC thay thế tư duy và suy luận bằng ảnh chụp màn hình ChatGPT cho những chủ đề mà chỉ cần tự nghĩ một chút là được
Những công cụ này dở tệ trong chuyện ý tưởng, tư duy và lời khuyên; chúng chỉ đưa ra những thứ trông như mẫu hình bằng cách pattern matching, nên nếu đem một ý tưởng ra bàn thì đa phần nó sẽ nhả ra những lời nhảm nhí chung chung nhất
Ngược lại, với các việc như viết code, nơi pattern matching thực sự hữu ích, nó khá có ích, nhưng không nên giao cả tư duy lẫn quyết định cho nó
Nhìn chung trần cao hơn và đáy cũng thấp hơn, và mô tả ở trên là rất chính xác
Tôi có vài bài viết liên quan: https://mitchellh.com/writing/my-ai-adoption-journey, https://mitchellh.com/writing/building-block-economy, https://mitchellh.com/writing/simdutf-no-libcxx
Bài cuối là một thay đổi phức tạp tôi thực hiện nhờ AI, và cũng cho thấy tôi tiếp cận nó một cách hợp lý thế nào
Nó gần như luôn tạo ra văn bản trông có vẻ hợp logic, nhưng bên trong lại có thể chứa các giả định ngầm và các quyết định sai, không phù hợp với trường hợp sử dụng cụ thể
Muốn tạo ra lời giải thật sự đúng thì định nghĩa vấn đề phải chuẩn, mà chuyện đó có khi còn khó hơn cả việc làm ra lời giải
Hoặc cũng tương tự việc giao cho một tư vấn viên bất kỳ
Liệu câu “AI nói đó là ý tưởng hay” có thực sự tệ hơn “chúng tôi làm theo xu hướng ngành” không
Khi một người làm vậy một mình, bạn bè và gia đình vẫn có thể chỉ ra những hành vi hay lời nói kỳ quặc để phần nào kéo họ lại
Nhưng khi người sử dụng lao động bắt đầu làm thế ở cấp lãnh đạo, rất khó tưởng tượng mọi chuyện có thể tệ đến mức nào
Bạn sẽ bị ép phải hòa theo hoặc sợ bị sa thải, và những người duy nhất còn có thể điều chỉnh suy nghĩ của bạn là các đồng nghiệp phản đối, nhưng chính những người đó lại dễ rời đi hoặc bị cho nghỉ nhất
Muốn giữ việc thì bạn phải cư xử cho phù hợp
Vì agent thay bạn ra quyết định nên công việc chạy theo tốc độ của agent, và nhiều khi nó còn âm thầm tự quyết rồi chỉ đưa ra đầu ra cuối cùng kiểu “đây là kế hoạch”
Muốn review cho đàng hoàng thì bạn lại phải hiểu sâu vấn đề, tức quay về tốc độ của con người, nên rốt cuộc thường chỉ lướt qua rồi phê duyệt
Cốt lõi là phải xác định một cách có ý thức và cẩn trọng xem quyết định nào được phép thuê ngoài
Làm vậy sẽ phải chậm lại, lợi ích vibe coding phóng đại kiểu 10x sẽ giảm đi, nhưng đổi lại bạn can dự nhiều hơn và tích lũy ít nợ nhận thức hơn
Các quyết định chán ngắt như duyệt mảng thế nào, hay nối đầu ra của một lời gọi vào đầu vào của lời gọi khác ra sao, có thể giao cho agent
Còn các quyết định thật sự thì phải chốt trước và đưa vào spec: xác định ranh giới, API, cấu trúc dữ liệu cốt lõi, hệ thống và trách nhiệm, xử lý lỗi, cũng như các ràng buộc mạnh về bảo mật và quyền riêng tư
Nếu còn mơ hồ thì phải dặn agent dừng lại, và một kỹ sư giỏi có thể đạt được mức tăng tốc 2~3 lần mà không có tác dụng phụ
Có khi chuyện này sẽ biến kỹ nghệ phần mềm thành một ngành kỹ thuật đúng nghĩa
Hiện tại những người chỉ biết prompt đang dựng cả hạ tầng cho công ty
Cá nhân tôi biết một người đã migrate database công ty sang phiên bản Postgres mới hơn, và cuối cùng đúng là thành công, nhưng chỉ cần nghe anh ấy kể lại quá trình thôi là tôi đã nghiến răng
Nó có cảm giác như: “Tôi đổ xăng lên máy chủ rồi châm thuốc, nhưng đừng lo, tôi tìm được bình chữa cháy dưới tầng hầm. Đồng hồ báo trống, nhưng lắc lên vẫn nghe còn chất lỏng bên trong”
Khi anh ta rời công ty, họ sẽ cần một prompter còn tự tin hơn nữa để duy trì hạ tầng DB đó
Bài này chỉ ra rằng không thể tranh luận với những người nói kiểu “cứ deploy bug cũng không sao, agent có thể sửa ở tốc độ và quy mô con người không làm nổi”
Nhưng câu trả lời được upvote cao nhất lại chính là ví dụ cho kiểu “nhưng agent cực kỳ nhanh” đó
Có thể họ đang giả định lợi ích của việc codebase và tính năng tăng gấp đôi lớn hơn thiệt hại do bug tăng gấp đôi
Ít nhất thì trông cũng đẹp trong bản tin gửi nhà đầu tư quý này
Có khi bạn chỉ đang tiếp tục đẩy thêm rác ra ngoài, còn vòng phản hồi thì là khách hàng chăng?
Câu trả lời tôi nhận được là: “Đó là game theory. Sẽ có người làm, và rồi cậu cũng buộc phải làm. Không thể nào tệ đến thế được.”
Logic đó có thể hữu ích, nhưng bỏ qua rủi ro lại là chuyện khác
Giả định rằng chỉ cần chạy cực nhanh và đập nát mọi thứ thì cuối cùng sẽ ra kết quả tốt là rất nguy hiểm
Làn sóng AI này đang không diễn ra tốt đẹp và tôi không thích nó
Tôi không nghĩ bên mắc psychosis nhất định phải là “phe chúng tôi”
Tôi làm ở một công ty rất lớn, và công ty tôi từ trước đến nay lúc nào cũng hiện đại hóa và áp dụng công nghệ mới chậm như băng trôi
Nhưng kỳ lạ là giờ đây điều đó lại có thể trở thành lợi thế cạnh tranh
Cuộc sống bắt chước nghệ thuật
Trước đây tôi vẫn hay đùa kiểu ở đây còn dùng fax, nhưng tôi không ngờ làm việc trong một nền văn hóa không có cơn sốt như thế này lại đáng mừng đến vậy
Đọc HN cứ như bước vào Alice's Wonderland của những kẻ cực đại hóa token và người mắc AI psychosis
Ở đây tôi thật sự không biết một ai bị ép phải làm việc theo kiểu đó cả
Nếu bạn có cảm giác như vậy, có thể bạn sẽ thích công cụ CLI mới Burn, Baby, Burn (those tokens) này: https://github.com/dtnewman/burn-baby-burn/tree/main
Show HN ở đây: https://news.ycombinator.com/item?id=48151287
Điều này làm tôi nhớ tới Simple Made Easy của Rich Hickey và cách ông ấy xây dựng Clojure
Ngay cả trước khi LLM có thể sinh cả chương trình, các framework phức tạp đã cho phép lập trình viên tạo ra phiên bản ban đầu của chương trình rất nhanh, nhưng phải đánh đổi bằng việc chương trình khó hiểu hơn và vì thế cũng khó debug, khó sửa hơn
Có những người đang đặt cược rằng dù AI có viết ra chương trình rối rắm và phức tạp đến đâu, AI lúc nào cũng sẽ đủ thông minh để debug, bảo trì và sửa đổi nó
Tôi thì không chắc như vậy
AI psychosis không phải là lập trường phản đối việc dùng AI
Tôi dùng công cụ code bằng AI hằng ngày, nhưng công cụ AI không có khái niệm về tương lai
Việc chúng ta xây được các hệ thống ổn định từ trước tới nay phần nào dựa vào lối suy nghĩ ích kỷ của kỹ sư kiểu “nếu cái này vỡ trong production thì mình sẽ không sửa nổi, và lúc 3 giờ sáng người ta sẽ gọi mình dậy”
Cũng còn có kiểu lười biếng thông thường là muốn tìm một thư viện hoàn hảo trên CPAN để khỏi phải tự làm, và đôi khi việc tìm không ra thư viện còn tốn thời gian hơn tự viết
Tôi đã dùng công cụ AI để viết hàng nghìn dòng code đưa vào production, và nhìn chung thấy khá tự nhiên, vì từ năm 2017 tôi đã nói với mọi người rằng đừng tự tay gõ toàn bộ code mà hãy viết code bằng cách khác và đặt bẫy trong test để bắt code tệ
Nhưng có một điều AI không làm là viết ít code hơn: https://xcancel.com/t3rmin4t0r/status/2019277780517781522/
Báo cáo bug cũng giảm khi mọi người mất niềm tin rằng bug sẽ được sửa
Vì việc report bug thường đòi hỏi đầu tư thời gian khá lớn
Kiểu chuyện này xảy ra khá thường khi niềm tin vào một nhóm hay một công ty sụp đổ
Vì thế khả năng bị báo sai cao hơn, và một số nội dung có thể không đúng
Thành ra bạn đang bị tấn công từ nhiều hướng
Thậm chí còn chưa tính tới các chiến thuật đối kháng
Nếu không có đạo đức, còn cách nào tốt hơn việc dùng agent để dội hàng loạt báo cáo bug giả vào đối thủ cạnh tranh?
Xong vấn đề
Phần lớn, có lẽ thậm chí toàn bộ những gì Mitchell quan sát được, hoàn toàn có thể xảy ra kể cả khi không có AI
Tôi cảm thấy mình đang ở vào một vị trí rất lạ
Tôi ghét những thay đổi mà AI mang lại cho trải nghiệm và thực hành viết code tới mức muốn làm bất cứ thứ gì khác ngoài việc dùng máy tính, nhưng đồng thời tôi cũng thấy những công cụ này rất mạnh và vẫn đang tiếp tục tiến bộ
Luận điểm của Mitchell là hợp lý. Những công cụ này có thể đưa nền móng mục ruỗng vào hệ thống, và chỉ phát hiện ra khi toàn bộ cấu trúc sụp xuống
Tôi không muốn ở vào vị trí phải chịu trách nhiệm vào lúc đó mà lại không hiểu codebase sâu như trước đây
Nhưng con người từ lâu cũng đã luôn đưa những bug tinh vi nhưng chí mạng vào code
Vì vậy phần lớn chuyện này với tôi vẫn giống như một câu hỏi thực nghiệm còn bỏ ngỏ
Liệu chúng ta sẽ thấy nhiều hệ thống sụp đổ theo những cách kinh khủng mà trước đây chưa từng có không? Có thể một phần là vậy
Đồng thời liệu chúng ta có học được rằng phải dịch chuyển nhiều hơn sang đặc tả và kiểm chứng không? Tôi không biết
Dù sao thì cách xây dựng hệ thống này có vẻ là không thể tránh được, kể cả nếu trên đường sẽ có va chạm
Tôi nghĩ phe phản AI cũng có một dạng psychosis phản ứng ngược của riêng mình
Tôi không muốn dính líu tới AI, nhưng cũng không thể phủ nhận trải nghiệm thực tế khi dùng các công cụ này
Tôi ước có nhiều không gian hơn cho những cuộc thảo luận về AI vừa thực tế vừa tiêu cực như thế này
Đó cũng là một phần lý do Mitchell là một lập trình viên giỏi