Việc chấp nhận mã code do AI viết mà không hiểu cách thức hoạt động đang ngày càng phổ biến.
Nhiều người coi lập trình là việc ra lệnh cho máy tính thực hiện các hành động chính xác và lặp đi lặp lại. Với sự xuất hiện của các công cụ AI như ChatGPT, giờ đây ai cũng có thể mô tả một chương trình bằng tiếng Anh và để mô hình AI dịch nó thành mã code hoạt động mà không cần hiểu cách thức code đó hoạt động. Andrej Karpathy, cựu nhà nghiên cứu của OpenAI, gần đây đã đặt tên cho phương pháp này là “vibe coding” (lập trình theo cảm hứng), và nó đang được đón nhận rộng rãi trong giới công nghệ. Kỹ thuật này, được hỗ trợ bởi các mô hình ngôn ngữ lớn (LLM) từ các công ty như OpenAI và Anthropic, đã thu hút sự chú ý vì tiềm năng giúp giảm rào cản gia nhập lĩnh vực tạo phần mềm. Tuy nhiên, vẫn còn nhiều câu hỏi về việc liệu phương pháp này có thể tạo ra mã code đáng tin cậy cho các ứng dụng thực tế hay không, ngay cả khi các công cụ như Cursor Composer, GitHub Copilot và Replit Agent ngày càng dễ tiếp cận hơn với những người không phải lập trình viên.
Việc “vibe coding” không chú trọng vào sự kiểm soát và chính xác, mà tập trung vào việc để bản thân “chìm đắm” trong dòng chảy công việc. Ngày 2 tháng 2, Karpathy đã giới thiệu thuật ngữ này trên X (trước đây là Twitter), viết: “Có một kiểu lập trình mới mà tôi gọi là ‘vibe coding’, nơi bạn hoàn toàn để mặc cho cảm hứng dẫn dắt, chấp nhận những điều bất ngờ và quên đi rằng code thậm chí còn tồn tại.” Ông mô tả quá trình này một cách rất đời thường: “Tôi chỉ nhìn thấy thứ gì đó, nói về thứ đó, chạy nó và sao chép dán, và phần lớn nó hoạt động.” Nếu có lỗi xảy ra, bạn chỉ cần đưa nó trở lại mô hình AI, chấp nhận các thay đổi, hy vọng nó sẽ hoạt động và lặp lại quá trình.
Phương pháp của Karpathy hoàn toàn trái ngược với các thực tiễn phát triển phần mềm truyền thống, thường nhấn mạnh vào việc lập kế hoạch cẩn thận, kiểm thử và hiểu rõ chi tiết triển khai. Như Karpathy đã hài hước thừa nhận trong bài đăng gốc của mình, phương pháp này dành cho những lập trình viên lười biếng nhất: “Tôi yêu cầu những điều ngớ ngẩn nhất, chẳng hạn như ‘giảm độ rộng của thanh bên xuống một nửa’, vì tôi quá lười để tự tìm ra nó. Tôi luôn chọn ‘Chấp nhận tất cả’; tôi không còn đọc các khác biệt nữa.”
Về cơ bản, kỹ thuật này biến bất kỳ ai có kỹ năng giao tiếp cơ bản thành một lập trình viên ngôn ngữ tự nhiên mới – ít nhất là đối với các dự án đơn giản. Với việc các mô hình AI hiện nay bị hạn chế bởi lượng code mà chúng có thể xử lý cùng một lúc (kích thước ngữ cảnh), thường có một giới hạn trên về độ phức tạp của một dự án phần mềm được tạo bằng “vibe coding” trước khi con người phải trở thành người quản lý dự án cấp cao, tự tay lắp ráp các mảnh code do AI tạo ra thành một kiến trúc lớn hơn. Nhưng khi giới hạn kỹ thuật mở rộng với mỗi thế hệ mô hình AI, những giới hạn đó có thể sẽ biến mất trong tương lai.
Hiện nay không có cách nào để biết chính xác có bao nhiêu người đang sử dụng “vibe coding” cho các dự án sở thích hoặc công việc phát triển, nhưng Cursor đã báo cáo 40.000 người dùng trả phí vào tháng 8 năm 2024, và GitHub đã báo cáo 1,3 triệu người dùng Copilot chỉ hơn một năm trước đó (tháng 2 năm 2024). Mặc dù chúng ta không thể tìm thấy số lượng người dùng cho Replit Agent, nhưng trang web này tuyên bố có 30 triệu người dùng, với tỷ lệ phần trăm không xác định sử dụng công cụ lập trình AI của trang web. Một điều chúng ta biết: phương pháp này đã đặc biệt thu hút sự chú ý trực tuyến như một cách thú vị để tạo mẫu game nhanh chóng. Peter Yang của Microsoft gần đây đã chứng minh “vibe coding” trong một chủ đề trên X bằng cách xây dựng một trò chơi bắn súng góc nhìn thứ nhất đơn giản với zombie thông qua các câu hỏi được đưa vào Cursor và Claude 3.7 Sonnet. Yang thậm chí còn sử dụng một ứng dụng chuyển giọng nói thành văn bản để anh ta có thể mô tả bằng lời những gì anh ta muốn thấy và tinh chỉnh nguyên mẫu theo thời gian.
Nhiều người đã tự mình trải nghiệm “vibe coding”. Việc có một “thần đèn” tạo code dựa trên cảm hứng có thể rất hữu ích trong những trường hợp bất ngờ. Năm ngoái, một người đã yêu cầu Claude của Anthropic viết một chương trình Microsoft Q-BASIC trên MS-DOS có thể giải nén 200 tệp ZIP vào các thư mục tùy chỉnh, giúp tiết kiệm nhiều giờ làm việc thủ công.
Với tất cả những điều này, cần có ý kiến chuyên gia. Simon Willison, một nhà phát triển phần mềm độc lập và nhà nghiên cứu AI, đã đưa ra một quan điểm sắc sảo về lập trình hỗ trợ AI trong một cuộc phỏng vấn với Ars Technica. “Tôi thực sự thích ‘vibe coding'”, ông nói. “Đó là một cách thú vị để thử một ý tưởng và chứng minh xem nó có hoạt động được hay không.” Nhưng có những giới hạn về việc Willison sẽ đi xa đến đâu. “Sử dụng ‘vibe coding’ cho một cơ sở mã sản xuất rõ ràng là rủi ro. Phần lớn công việc chúng ta làm với tư cách là kỹ sư phần mềm liên quan đến việc phát triển các hệ thống hiện có, nơi chất lượng và tính dễ hiểu của mã cơ bản là rất quan trọng.”
Ở một mức độ nào đó, việc hiểu ít nhất một số code là rất quan trọng bởi vì code do AI tạo ra có thể bao gồm lỗi, hiểu lầm và “ảo giác” – ví dụ, các trường hợp mà mô hình AI tạo ra các tham chiếu đến các hàm hoặc thư viện không tồn tại. “Việc ‘vibe coding’ rất thú vị cho đến khi bạn phải ‘vibe debug’ (gỡ lỗi theo cảm hứng)”, nhà phát triển Ben South đã ghi chú một cách dí dỏm trên X, nhấn mạnh vấn đề cơ bản này.
Willison gần đây đã lập luận trên blog của mình rằng việc gặp phải “ảo giác” với các công cụ lập trình AI không gây hại bằng việc nhúng thông tin sai do AI tạo ra vào một báo cáo đã viết, bởi vì các công cụ lập trình có chức năng kiểm tra thực tế tích hợp sẵn: Nếu có “ảo giác”, code sẽ không hoạt động. Điều này tạo ra một ranh giới tự nhiên cho độ tin cậy của “vibe coding” – code chạy hoặc không chạy. Tuy nhiên, việc tính toán rủi ro – lợi ích đối với “vibe coding” trở nên phức tạp hơn nhiều trong các môi trường chuyên nghiệp. Trong khi một nhà phát triển độc lập có thể chấp nhận sự đánh đổi của “vibe coding” cho các dự án cá nhân, thì các môi trường doanh nghiệp thường yêu cầu các tiêu chuẩn về khả năng bảo trì và độ tin cậy của code mà các giải pháp “vibe coding” có thể khó đáp ứng. Khi code không hoạt động như mong đợi, việc gỡ lỗi đòi hỏi phải hiểu code thực sự đang làm gì – chính xác là kiến thức mà “vibe coding” thường bỏ qua.
Khi nói đến việc xác định chính xác “vibe coding” là gì, Willison đã đưa ra một sự phân biệt quan trọng: “Nếu một LLM viết mọi dòng code của bạn, nhưng bạn đã xem xét, kiểm tra và hiểu tất cả, thì đó không phải là ‘vibe coding’ trong sách của tôi – đó là việc sử dụng LLM như một trợ lý đánh máy.” Ngược lại, “vibe coding” liên quan đến việc chấp nhận code mà không hoàn toàn hiểu cách thức hoạt động của nó.
Mặc dù “vibe coding” bắt nguồn từ Karpathy như một thuật ngữ hài hước, nhưng nó có thể phản ánh một sự thay đổi thực sự trong cách một số nhà phát triển tiếp cận các nhiệm vụ lập trình – ưu tiên tốc độ và thử nghiệm hơn là sự hiểu biết kỹ thuật sâu sắc. Và đối với một số người, điều đó có thể đáng sợ. Willison nhấn mạnh rằng các nhà phát triển cần chịu trách nhiệm về code của họ: “Tôi tin tưởng rằng với tư cách là một nhà phát triển, bạn phải chịu trách nhiệm về code mà bạn tạo ra – nếu bạn định đặt tên mình vào đó, bạn cần tự tin rằng bạn hiểu cách thức và lý do tại sao nó hoạt động – lý tưởng nhất là đến mức bạn có thể giải thích nó cho người khác.” Ông cũng cảnh báo về một con đường phổ biến dẫn đến nợ kỹ thuật: “Đối với các thử nghiệm và dự án có rủi ro thấp mà bạn muốn khám phá những gì có thể và xây dựng các nguyên mẫu thú vị? Hãy cứ làm đi! Nhưng hãy nhận thức được rủi ro rất thực tế rằng một nguyên mẫu đủ tốt thường phải đối mặt với áp lực đưa vào sản xuất.”
Vậy, liệu “vibe coding” có khiến các lập trình viên mất việc không? Về bản chất, lập trình luôn là việc ra lệnh cho máy tính hoạt động như thế nào. Phương pháp thực hiện điều đó đã thay đổi theo thời gian, nhưng có thể sẽ luôn có những người giỏi hơn trong việc ra lệnh chính xác cho máy tính những việc cần làm hơn những người khác – ngay cả bằng ngôn ngữ tự nhiên. Theo một cách nào đó, những người đó có thể trở thành những “lập trình viên” mới.
Có một thời điểm vào cuối những năm 1970 đến đầu những năm 1980, nhiều người cho rằng mọi người cần có kỹ năng lập trình để sử dụng máy tính hiệu quả vì có rất ít ứng dụng được xây dựng sẵn cho tất cả các nền tảng máy tính khác nhau. Các hệ thống trường học trên toàn thế giới đã nỗ lực tạo ra khả năng đọc hiểu máy tính giáo dục để dạy mọi người lập trình. Không lâu sau đó, mọi người đã tạo ra các ứng dụng phần mềm hữu ích cho phép những người không phải lập trình viên sử dụng máy tính dễ dàng – không cần lập trình. Tuy nhiên, các lập trình viên không biến mất – thay vào đó, họ sử dụng các ứng dụng để tạo ra các chương trình tốt hơn và phức tạp hơn. Có lẽ điều đó cũng sẽ xảy ra với các công cụ lập trình AI.
Tóm lại, các công nghệ điều khiển bằng máy tính như hệ thống lái tự động đã giúp cho việc bay siêu thanh đáng tin cậy trở nên khả thi vì chúng có thể xử lý các khía cạnh của chuyến bay mà chỉ những người được đào tạo và có năng lực cao nhất mới có thể kiểm soát an toàn. AI có thể làm điều tương tự đối với lập trình, cho phép con người bỏ qua các vấn đề phức tạp mà nếu không sẽ mất quá nhiều thời gian để mã hóa thủ công, và điều đó có thể cho phép tạo ra các trải nghiệm phần mềm phức tạp và hữu ích hơn trong tương lai. Nhưng vào thời điểm đó, liệu con người vẫn có thể hiểu hoặc gỡ lỗi chúng không? Có thể là không. Chúng ta có thể hoàn toàn phụ thuộc vào các công cụ AI, và chắc chắn một số người thấy điều đó hơi đáng sợ hoặc không khôn ngoan.
Việc “vibe coding” tồn tại trong bối cảnh lập trình hay chỉ là một kỹ thuật tạo mẫu có thể sẽ phụ thuộc ít hơn vào khả năng của các mô hình AI và nhiều hơn vào sự sẵn sàng của các tổ chức trong việc chấp nhận sự đánh đổi rủi ro về chất lượng code, khả năng bảo trì và nợ kỹ thuật. Hiện nay, “vibe coding” vẫn là một thuật ngữ phù hợp để mô tả mối quan hệ hỗn độn, mang tính thử nghiệm giữa AI và các nhà phát triển – mang tính cộng tác hơn là tự động, nhưng ngày càng làm mờ ranh giới giữa ai (hoặc cái gì) thực sự đang lập trình.
Nguồn: https://arstechnica.com/ai/2025/03/is-vibe-coding-with-ai-gnarly-or-reckless-maybe-some-of-both/