"Vibe Coding": Sự sùng bái mù quáng và nguy cơ tạo ra phần mềm tồi

Gần đây, cộng đồng công nghệ đã có dịp "mỉa mai" vụ rò rỉ mã nguồn của Claude khi phát hiện ra chất lượng mã bên trong khá kém. Nhiều người tự hỏi làm sao một sản phẩm AI hàng đầu lại có thể sở hữu cấu trúc mã lộn xộn đến vậy. Câu trả lời nằm ở việc áp dụng triệt để khái niệm "dogfooding" (sử dụng chính sản phẩm của mình làm) đến mức trở nên cực đoan.

Dogfooding về bản chất là một ý tưởng tốt, nhưng khi nó vượt qua giới hạn hợp lý, nó biến thành một hoạt động sùng bái mù quáng. Trong trường hợp này, đó là khái niệm "vibe coding" (lập trình theo cảm hứng), nơi các nhà phát triển cố tình không đóng góp bất kỳ điều gì vào những gì diễn ra "bên dưới nắp capo", thậm chí không thèm nhìn vào mã nguồn một lần nào.

Huyền thoại về Vibe Coding thuần túy

Điều này nghe thật vô lý. Không phải là không có sự đóng góp của con người trong quá trình này. Bạn đang sử dụng ngôn ngữ tự nhiên, và máy móc cũng sử dụng chính ngôn ngữ đó cho các quy trình tư duy nội bộ của nó. Bạn có thể lập luận rằng những con người khác (không thuộc nhóm phát triển trực tiếp) đã làm hết các công việc nền tảng, nhưng thực tế không phải vậy.

Bạn vẫn đang xây dựng cơ sở hạ tầng như các tệp kế hoạch (hay còn gọi là danh sách việc cần làm), kỹ năng và quy tắc. Máy móc hoạt động rất kém nếu không được cung cấp một khung framework rõ ràng. Do đó, vibe coding thuần túy chỉ là một huyền thoại. Tuy nhiên, mọi người vẫn cố gắng thực hiện nó, dẫn đến những kết quả khá buồn cười.

Ví dụ, một con người thực sự đã nhìn vào mã và thấy rất nhiều sự trùng lặp. Bạn có thể hỏi: tại sao không có nhà phát triển nào tự mình đi kiểm tra? Câu trả lời vẫn là vibe coding. Nhìn vào mã nguồn bị coi là gian lận. Bạn chỉ nên có những cuộc trò chuyện mơ hồ với máy móc về những gì nó đang làm.

Mã nguồn không phải là "hộp đen"

Điều này trở nên đặc biệt ngớ ngẩn vì không có yếu tố kỹ thuật siêu phàm nào bên dưới mà công chúng không thể hiểu được. Mã này được viết bằng tiếng Anh. Bất kỳ ai cũng có thể đọc nó. Rất dễ để lướt qua và nhận ra: "Ồ, có rất nhiều thứ vừa là tác nhân (agents) vừa là công cụ (tools). Điều này hơi dư thừa, chúng ta nên dọn dẹp nó."

Trong phần mềm, các dự án thường sinh ra từ những sai lầm. Về mặt lịch sử, một dự án phần mềm thường gánh nặng nợ kỹ thuật (tech debt) lớn đến mức nếu bạn làm đúng theo lý trí phát triển, bạn sẽ dành cả năm sau chỉ để dọn dẹp mớ hỗn độn. Giờ đây, khi bạn có thể sử dụng AI để lập trình, bạn có thể hoàn thành việc dọn dẹp đó trong vài tuần, hoặc trả nợ chậm hơn trong khi vẫn viết tính năng mới. Và bạn nên làm như vậy. Bạn nên phấn đấu cho chất lượng cao hơn nhiều. Giúp bạn dọn dẹp mớ hỗn độn là điều AI thực sự rất giỏi.

Cách sử dụng AI đúng cách

Trong trường hợp cụ thể này, một con người có thể đã nói với máy móc: "Có nhiều thứ vừa là tác nhân vừa là công cụ. Hãy liệt kê tất cả chúng, xem một số ví dụ, và tôi sẽ nói cho bạn biết cái nào nên là tác nhân, cái nào nên là công cụ. Chúng ta sẽ thảo luận để tìm ra các nguyên tắc chung. Sau đó, chúng ta sẽ kiểm tra toàn bộ tập hợp, xác định danh mục của từng cái, chuyển đổi những cái sai loại, và对于那些既是两者又是两者的， đọc qua cả hai phiên bản và hợp nhất chúng thành một tài liệu với những điểm tốt nhất của cả hai."

AI thực sự rất giỏi việc này, đặc biệt nếu bạn thảo luận với nó trước đó. Đó là mục đích của chế độ "Ask". Bạn đi qua một số ví dụ, chia sẻ lý luận của mình và sửa những sai sót khi nó cố gắng đồng thuận một cách xu nịnh. Sau đủ nhiều lần qua lại, nó thường có thể thực hiện nhiệm vụ trông như thể thực hiện một lần (one-shot). Nhưng thực tế không phải vậy. Đã có rất nhiều thảo luận trước đó với bạn, con người. Nhưng khi nó thực sự bắt đầu làm việc, nó tiến nhanh vì bạn đã làm rõ các trường hợp ngoại lệ kỳ lạ và các vấn đề có thể phát sinh.

Phần mềm tồi là một sự lựa chọn

Nhưng nhóm Claude lại không làm như vậy. Họ đang quá đà với dogfooding và hoàn toàn từ chối dành vài phút để nhìn dưới nắp capo, nhận thấy những gì bị hỏng và giải thích mớ hỗn độn đó cho máy móc. Điều đó thậm chí không vi phạm khái niệm vibe coding quá nhiều. Bạn đọc nội dung một chút nhưng chỉ đưa ra các ý tưởng cấp cao, khái niệm và trừu tượng về cách giải quyết vấn đề. Máy móc vẫn làm phần lớn, nếu không phải là tất cả, công việc viết mã thực tế.

Tôi đã làm điều này trong nhiều tháng. Tôi sẽ bắt đầu một cuộc trò chuyện bằng cách nói: "Hãy kiểm tra mã nguồn này để tìm mã không thể tiếp cận", hoặc "Hàm này làm chảy máu mắt tôi", và chúng ta sẽ thảo luận về nó cho đến khi có một hành động cụ thể. Sau đó, tôi giải thích những gì tôi nghĩ nên được làm và chúng ta tiếp tục thảo luận cho đến khi tôi hết ý tưởng và máy móc ngừng nói những điều ngớ ngẩn cần sửa chữa. Sau đó, tôi bảo nó lập kế hoạch và bắt đầu xây dựng. Đó là cuộc sống của tôi. AI rất tệ trong việc tự nhận ra: "Tôi có rất nhiều mã spaghetti ở đây, tôi nên dọn dẹp nó". Nhưng nếu bạn nói với nó rằng mã này spaghetti và đưa ra một số hướng dẫn (hoặc đôi khi thậm chí không cần hướng dẫn), nó có thể làm tốt việc dọn dẹp mớ hỗn độn.

Bạn không cần phải có phần mềm chất lượng kém chỉ vì bạn đang sử dụng AI để lập trình. Đó là quan điểm nóng bỏng của tôi hôm nay. Mọi người có phần mềm chất lượng kém vì họ quyết định có phần mềm chất lượng kém. Tôi đã hét vào máy tính cả tuần này khi xử lý một thư viện được viết bởi những con người được trả lương cao mà không có sự trợ giúp của AI. Phần mềm tồi là một quyết định của bạn. Bạn cần chịu trách nhiệm về nó. Bạn nên làm tốt hơn.