Điểm nổi bật
- Engagement: khoảng 822 points và 359 comments sau 5 giờ trên HN front page.
- Luận điểm trung tâm: AI có thể tăng tốc viết phần mềm, nhưng khi vượt ngưỡng hiểu biết của con người thì chi phí sửa lỗi và rủi ro vận hành tăng rất nhanh.
- Phe ủng hộ thận trọng: kỹ sư kỳ cựu nhấn mạnh việc bảo trì hệ thống phức tạp vẫn cần hiểu ngữ cảnh tích lũy qua nhiều năm.
- Phe phản biện: một số ý kiến cho rằng đây chỉ là vòng lặp cũ của ngành phần mềm, nơi hệ thống luôn lộn xộn vì thực tế kinh doanh lộn xộn.
- Hàm ý doanh nghiệp: có thể xuất hiện nhu cầu mới cho dịch vụ “AI rescue consulting” để cứu các hệ thống vibecoded mất kiểm soát.
Biểu đồ
Tóm tắt
Thread bắt đầu từ nhận định khá cực đoan nhưng trúng tâm lý thời điểm: có những công ty đang rơi vào “AI psychosis”, tức tin rằng có thể để AI đẩy nhanh việc xây dựng phần mềm tới mức con người không còn theo kịp cấu trúc, logic và các góc cạnh vận hành của chính hệ thống đó. HN phản ứng rất mạnh vì đây không còn là câu hỏi “AI có viết code được không”, mà là câu hỏi ai sẽ chịu trách nhiệm khi phần mềm sống trong môi trường thật, với khách hàng thật, dữ liệu thật và lỗi thật.
Điểm hay của thread là nó không chỉ chống AI theo kiểu cảm tính. Nhiều bình luận thừa nhận AI hữu ích rõ rệt với người có kinh nghiệm, nhưng cũng chỉ ra failure mode đang lặp lại: người ít nền tảng kỹ thuật dùng AI để đẻ ra một kiến trúc ngày càng phức tạp, thêm cache, thêm service, thêm lớp abstraction mà không hiểu trade-off. Khi hệ thống bắt đầu có trạng thái, edge case và áp lực vận hành, lợi thế tạo nhanh ban đầu đổi lấy chi phí đọc hiểu và sửa sai ngày càng lớn.
Chi tiết
Phần mở đầu của thread đưa ra một dự báo đáng chú ý: vài năm tới có thể xuất hiện một mảng tư vấn giá trị cao chuyên “giải cứu” các hệ thống do AI tạo ra quá nhanh, tương tự cách ngành bảo mật có incident response hay ngành hạ tầng có dịch vụ khôi phục sau sự cố. Lập luận cốt lõi là khi một hệ thống được AI viết gần như thuần túy, độ phức tạp có thể tăng đến điểm không còn con người nào thực sự nắm được bức tranh tổng thể. Khi đó, mỗi lỗi mới không chỉ tốn thời gian sửa mà còn kéo theo token burn ngày càng lớn, vì AI tiếp tục sửa trên nền một kiến trúc vốn đã mù mờ.
Rất nhiều bình luận hưởng ứng vì họ nhìn thấy hình ảnh quen thuộc của những cuộc rewrite trước đây, chỉ khác là AI đang tăng tốc chu kỳ lặp này. Một nhánh tranh luận thú vị đến từ các kỹ sư lâu năm, những người nhấn mạnh rằng hệ thống “xấu” không phải lúc nào cũng là hệ thống tồi. Nhiều codebase lộn xộn thực ra là kết quả của hàng năm tích hợp các edge case, ngoại lệ vận hành và yêu cầu mang lại doanh thu. Vấn đề của vibe coding, theo góc nhìn này, là nó tái tạo hình thức của giải pháp mà không tích lũy được sự hiểu biết sâu về những góc cạnh đã được chưng cất trong hệ thống cũ.
Phe còn lại phản biện rằng ngành phần mềm vốn luôn có những hệ thống vượt quá khả năng hiểu trọn vẹn của một cá nhân, nên AI chỉ đang tái hiện giới hạn con người trên một nhịp nhanh hơn. Đây là phản biện quan trọng vì nó kéo thảo luận ra khỏi kiểu lập luận “AI xấu, người tốt”. Một số người còn đùa rằng nếu AI tạo ra các hệ thống rối rắm như con người từng tạo hàng chục năm qua, như vậy nó đã khá gần hiệu năng của lập trình viên thực tế. Nhưng ngay cả nhánh phản biện này cũng không phủ nhận vấn đề governance: hệ thống phức tạp chỉ bền khi có review, kiểm thử, trách nhiệm kiến trúc và người hiểu miền nghiệp vụ.
Comment gây chú ý nhất là ví dụ một người không chuyên thắng thầu phần mềm quản lý tồn kho cho bệnh viện sau khi vibe code với Claude, rồi lúng túng khi phải triển khai lên hạ tầng thật và xử lý lỗi dữ liệu. Từ góc nhìn chiến lược, đây là phần đáng đọc nhất. Nó cho thấy rủi ro không nằm ở demo, mà nằm ở khoảnh khắc sản phẩm bước vào môi trường có quy định, dữ liệu nhạy cảm và yêu cầu uptime. Nếu AI tiếp tục hạ thấp rào cản tạo phần mềm, doanh nghiệp sẽ phải nâng chuẩn kiểm soát kiến trúc, review và vận hành lên tương ứng. Không làm điều đó, “AI psychosis” có thể trở thành tên gọi mới của nợ kỹ thuật được tăng tốc bằng tự động hóa.