Mistral Large 4 dựng khối Rubik bằng code, ráp xong màu lại biến mất

Mistral Large 4 dựng khối Rubik bằng code, ráp xong màu lại biến mất

Bạn nhờ AI viết một ứng dụng nhỏ, AI báo xong, bạn mở lên dùng thử thì phát hiện ra nó vỡ ngay ở bước tưởng chừng đơn giản nhất. Đó chính xác là chuyện vừa xảy ra khi nhà sáng tạo nội dung công nghệ Matthew Berman thử thách mô hình Mistral Large 4 của hãng Mistral AI (Pháp) tự viết một khối Rubik có thể chơi được ngay trên trình duyệt.

Thử thách: dựng khối Rubik chơi được ngay trên trình duyệt

Yêu cầu Berman đưa ra không phải một câu đố toán học hay bài kiểm tra trí nhớ, mà là một bài kiểm tra vibe coding thực sự: nhờ AI viết code cho một khối Rubik 3D hiển thị ngay trên trình duyệt, người chơi bấm được để xoay từng mặt, có nút xáo trộn (scramble) để làm rối khối trước khi chơi. Đây là dạng việc rất quen thuộc với người dùng AI để vibe code một ứng dụng nhỏ mà không cần biết viết code: mô tả bằng lời, để AI tự ra code, rồi bấm thử xem có chạy đúng không.

Hai lần sửa, hai kiểu lỗi khác nhau

Lần đầu, Mistral Large 4 trả về một khối Rubik nhìn đẹp, dựng hình 3D đầy đủ, nhưng nút "scramble" không hoạt động. Bấm vào không có gì xảy ra, khối lập phương cứ đứng yên ở trạng thái đã giải xong, vô dụng với một trò chơi lẽ ra phải bắt đầu từ trạng thái bị xáo trộn.

Berman yêu cầu sửa lại. Lần thứ hai, mô hình fix được đúng lỗi đó: nút xáo trộn chạy, các mặt xoay được như mong đợi. Nhưng việc sửa lỗi cũ lại kéo theo một lỗi mới nghiêm trọng hơn: mỗi lần xoay một mặt, toàn bộ màu sắc trên các ô vuông của khối lập phương biến mất. Nói cách khác, AI vá được phần chuyển động nhưng lại làm hỏng phần trạng thái màu, hai thứ lẽ ra phải luôn khớp với nhau trong một khối Rubik thật.

Lỗi tại mô hình, hay tại cách nó được lắp ráp để làm việc

Điều đáng chú ý trong câu chuyện này không chỉ là việc AI mắc lỗi, mà là cách Berman nhìn nhận nguyên nhân. Thay vì kết luận thẳng "Mistral Large 4 kém", ông cho rằng vấn đề nằm nhiều hơn ở sự phối hợp giữa mô hình và "harness", tức là lớp công cụ và quy trình tự động bao quanh mô hình khi nó viết code (đọc file, chạy thử, tự sửa theo lỗi báo về). Một khối Rubik hoạt động đúng cần giữ đồng bộ hai thứ cùng lúc: trạng thái dữ liệu bên trong (mặt nào đang ở đâu, màu gì) và hình ảnh hiển thị ra ngoài. AI có thể viết đúng từng đoạn code riêng lẻ, nhưng khi sửa một phần mà không kiểm tra lại toàn bộ chuỗi liên kết giữa dữ liệu và giao diện, lỗi mới rất dễ sinh ra ngay tại chỗ tưởng đã ổn.

Đây cũng là lý do vì sao ngay cả khi một mô hình AI viết code giỏi, kết quả cuối cùng vẫn phụ thuộc nhiều vào cách người dùng kiểm tra lại từng bước, giống như bài học rút ra từ việc một lập trình viên từng vibe code lại cả bộ ứng dụng Adobe bằng AI: AI làm được việc lớn, nhưng người đứng sau vẫn phải là người bấm thử và phát hiện chỗ vỡ trước khi coi là xong.

Điều này có ý nghĩa gì với bạn

Nếu bạn đang hoặc sắp dùng AI để tự làm một ứng dụng nhỏ, dù là trò chơi, công cụ nội bộ hay trang web cá nhân, câu chuyện khối Rubik là lời nhắc rất thực tế: đừng coi "AI báo đã sửa xong" là dấu hiệu để dừng kiểm tra. Mỗi lần AI sửa một lỗi, hãy thử lại đúng tính năng vừa sửa và cả những tính năng liên quan gần đó, vì lỗi mới thường xuất hiện ngay cạnh chỗ vừa được vá. Với các ứng dụng có trạng thái thay đổi liên tục như trò chơi, biểu mẫu nhiều bước hay giỏ hàng, nên yêu cầu AI giải thích ngắn gọn nó vừa đổi những gì trước khi bạn chấp nhận bản sửa, thay vì chỉ nhìn giao diện có chạy được hay không. Nếu bạn mới tìm hiểu chi phí và công sức để tự làm một ứng dụng theo cách này, bài làm app bằng vibe coding tốn bao nhiêu tiền một tháng sẽ giúp bạn hình dung rõ hơn trước khi bắt tay vào làm, và thói quen kiểm chứng lại câu trả lời của AI cũng nên áp dụng cả với code, không chỉ với văn bản.

Câu hỏi thường gặp

Mistral Large 4 là gì? Là mô hình ngôn ngữ lớn mới nhất của hãng Mistral AI (Pháp), dùng để trả lời câu hỏi và viết code, tương tự nhóm mô hình của OpenAI, Anthropic hay Google.

Lỗi khối Rubik có nghĩa là Mistral Large 4 viết code kém hơn các AI khác không? Bài kiểm tra của Berman không so sánh trực tiếp với các mô hình khác, nên chưa đủ căn cứ để kết luận mô hình nào viết code giỏi hơn. Điều rõ ràng hơn là: ngay cả AI mạnh cũng có thể làm vỡ một phần đã chạy đúng khi sửa phần khác, nếu không kiểm tra lại toàn bộ.

"Harness" trong bài này nghĩa là gì? Là lớp công cụ và quy trình tự động bao quanh mô hình AI khi nó viết code, ví dụ cách đọc file, chạy thử và đưa lỗi quay lại cho mô hình sửa tiếp. Harness vận hành không tốt có thể khiến một mô hình giỏi vẫn cho ra kết quả lỗi.

Người mới học vibe coding nên rút ra điều gì từ câu chuyện này? Luôn bấm thử lại chính tính năng AI vừa sửa, và cả những phần liên quan gần đó, trước khi coi là xong. Đừng chỉ tin vào lời AI báo "đã sửa xong".

#MistralAI #VibeCoding #AI #LapTrinhVoiAI #TinTucAI