Bend 2 và cái bẫy "vibe-coding": Xây cả một ngôn ngữ mà không biết lĩnh vực của mình đã tồn tại

Bend 2 đang được giới thiệu như một ngôn ngữ dành cho kỷ nguyên lập trình bằng AI: con người viết ra các "luật" (laws), AI viết phần triển khai cùng các chứng minh, và trình biên dịch kiểm tra xem các chứng minh đó có hợp lệ hay không. Nghe thì rất ấn tượng, và dễ hiểu vì sao ai đó lại muốn có một ngôn ngữ như vậy. Tuy nhiên, theo một bài phân tích trên blog của Liam Powell, dự án này đã sập vào một cái bẫy phổ biến của trào lưu vibe-coding – một vấn đề ít khi được nhắc đến.

Vibe-coding là gì và vì sao nó nguy hiểm?

Vibe-coding là cách lập trình mà ở đó lập trình viên để cho AI viết phần lớn mã nguồn dựa trên mô tả bằng ngôn ngữ tự nhiên, thay vì tự tay viết từng dòng hoặc tham khảo kỹ lưỡng tài liệu chuyên ngành.

Vấn đề nằm ở chỗ: vibe-coding cho phép bạn xây dựng một giải pháp đồ sộ trước khi học đủ về bài toán để nhận ra rằng một giải pháp tốt hơn nhiều đã tồn tại từ lâu. Một lập trình viên có thể tạo ra cả một ngôn ngữ lập trình lẫn trình biên dịch, mà bỏ lỡ một hướng tiếp cận mà chỉ cần một khảo sát nhập môn trong lĩnh vực đó cũng đủ chỉ ra.

Lĩnh vực được nhắc đến ở đây là xác minh hình thức (formal verification). Điều đáng chú ý là cụm từ này không xuất hiện ở bất kỳ đâu trên trang chủ của Bend hay trong mã nguồn của nó. Tác giả dự án dường như đã xây cả một ngôn ngữ xoay quanh một lĩnh vực mà không hề biết rằng lĩnh vực ấy thực sự tồn tại.

Con số biết nói: 58 dòng luật, 442 dòng chứng minh

Để thấy rõ vấn đề, hãy nhìn vào chính bản demo trên trang chủ của Bend.

• Chỉ để phát biểu rằng người chơi không bao giờ có thể chạm vào lá cờ hoặc thắng game, dự án cần tới 58 dòng mã trong tệp LAWS.bend.
• Để chứng minh các tính chất đơn giản đó, LLM viết mã phải tạo ra tới 442 dòng trong tệp PROOF.bend.

Nói cách khác, một bài toán nhỏ xíu lại kéo theo một khối lượng đặc tả và chứng minh khổng lồ, được xây dựng từ những nguyên lý cơ bản.

Cùng bài toán đó, nhưng với SPARK

Để chứng minh cái bẫy này rõ ràng hơn, tác giả bài viết đã nhờ chính một LLM tái tạo lại demo của Bend bằng SPARK – một ngôn ngữ và trình biên dịch mã nguồn mở dành cho xác minh hình thức. Đáng chú ý: tác giả hoàn toàn "vibe-code" phần này, chỉ đưa ra yêu cầu chung chung mà không có hướng dẫn chi tiết nào thêm.

Kết quả chạy GNATprove (công cụ kiểm chứng của SPARK) đưa ra thông báo:

Success: all checks proved (12 checks).

Điểm khác biệt then chốt so với Bend: những gì được viết trong SPARK đã bao gồm mọi thứ cần thiết để chứng minh tính đúng đắn của chương trình, mà không cần để LLM lãng phí thời gian và token để dựng lên một chứng minh dài 442 dòng từ con số không. Không cần một khối "luật" khổng lồ, không cần một tệp chứng minh cồng kềnh – chính ngôn ngữ và trình biên dịch đã đảm nhận phần lớn công việc.

Bài học vượt ra ngoài phạm vi Bend

Câu chuyện này không chỉ đúng với Bend. Nó phản ánh rủi ro chung của vibe-coding trong kỷ nguyên AI:

• Vibe-coding khiến việc triển khai một thiết kế sai lầm, hoặc lạc hậu hàng chục năm trở nên quá dễ dàng, vì bạn có thể nhận được kết quả ngay lập tức mà chẳng cần nghiên cứu gì.
• Nếu bạn hỏi một LLM rằng liệu có thể chứng minh một hàm là đúng đắn về mặt hình thức bằng cách dựng chứng minh từ các nguyên lý cơ bản hay không, nó sẽ sẵn sàng làm theo. Nó sẽ không chủ động gợi ý rằng máy tính đã có thể tự xây những chứng minh phức tạp mà không cần LLM, giúp loại bỏ 99% công việc.
• Nó cũng sẽ không nói với bạn rằng thứ bạn đang xây dựng thực ra đã tồn tại phần lớn dưới dạng công trình có sẵn để kế thừa.

Nói cách khác, công cụ AI rất giỏi làm theo yêu cầu, nhưng lại kém trong việc phản biện tiền đề. Nó không tự hỏi liệu bài toán bạn đang giải có thực sự cần giải theo cách đó hay không.

Điều này có ý nghĩa gì với cộng đồng công nghệ Việt Nam?

Với các nhóm phát triển phần mềm trong nước đang ngày càng dựa vào AI để tăng tốc, bài học ở đây rất đáng lưu tâm: tốc độ không thay thế được hiểu biết nền tảng.

• Trước khi để AI sinh ra một hệ thống lớn, hãy dành thời gian khảo sát xem lĩnh vực đó đã có chuẩn mực, công cụ hoặc nghiên cứu nào sẵn có chưa.
• Đặt câu hỏi ngược cho AI: "Cách tiếp cận này có phải là hiện đại nhất không? Có giải pháp nào đã được kiểm chứng trong lĩnh vực này chưa?" – thay vì chỉ yêu cầu nó hiện thực hóa ý tưởng của bạn.
• Coi AI như một người cộng sự triển khai, không phải người thầy dẫn đường về kiến thức chuyên ngành.

Câu chuyện về Bend 2 là một lời cảnh tỉnh: sức mạnh của AI có thể khiến chúng ta xây những tòa nhà đồ sộ trên nền móng mà ta chưa từng kiểm tra xem có tồn tại hay không. Và đôi khi, một chút nghiên cứu trước khi gõ phím có thể tiết kiệm hàng trăm dòng mã – cùng rất nhiều thời gian và công sức về sau.