"Vibe Coding" so với thực tế

• Gần đây, phát biểu của Andrej Karpathy đã gây chú ý: "Hãy để bản thân trôi theo Vibe, chấp nhận tăng trưởng theo cấp số nhân, và thậm chí quên cả việc code tồn tại."
• "Vibe Coding" chỉ xu hướng giao việc giải quyết vấn đề cho các công cụ AI mà không có kế hoạch rõ ràng hoặc không trực tiếp viết mã
• Thông qua các tác nhân LLM (mô hình ngôn ngữ lớn), giờ đây có thể ra lệnh bằng ngôn ngữ tự nhiên để tạo và chỉnh sửa mã
  • 2022: Có thể sao chép và chỉnh sửa mã trong ChatGPT
  • 2023: Có thể review và chỉnh sửa mã trong Copilot tích hợp với IDE
  • 2024~2025: Có thể chỉnh sửa nhiều tệp trong dự án, tự kiểm thử và tự sửa lỗi

Cách "Vibe Coding" hoạt động

• Cả người dùng kỹ thuật lẫn không kỹ thuật đều có thể thiết lập dự án thông qua các tác nhân dựa trên LLM
• Có thể tạo website hoặc ứng dụng bằng các lệnh đơn giản (ví dụ: "Tạo website khu nghỉ dưỡng trượt tuyết")
• Sau thiết lập ban đầu, có thể tự động chỉnh sửa và kiểm thử

• Ví dụ:

  • Cursor, GitHub Copilot Agent Mode... có thể chỉnh sửa tệp và thực thi lệnh
  • Thực hiện tự sửa và tự kiểm thử → có thể phát sinh lỗi do thiếu tính nhất quán

Vấn đề về tính tự chủ của tác nhân

• Tác nhân có thể tự động thực hiện công việc, nhưng không phải là tự chủ hoàn toàn
• Nếu chạy mà không có sự phê duyệt của người dùng, có thể phát sinh rủi ro (ví dụ: thực thi lệnh trong chế độ YOLO)
• Có thể phát sinh vấn đề về chất lượng và độ chính xác của mã

• Các vấn đề chính:

  • Không tái sử dụng được mã hiện có → lặp đi lặp lại việc tạo cùng một component
  • Cố gắng chạy logic phía máy chủ ở phía client
  • Phát sinh lỗi sau khi sửa mã sai → thất bại khi cố sửa lại
  • Không viết được unit test hoặc làm hỏng mã

Những giới hạn thực tế

• Các mô hình như Claude 3.7 Sonnet không thể vượt qua giới hạn của dữ liệu huấn luyện
• Khi mất ngữ cảnh trong codebase, không thể thực hiện các chỉnh sửa nhất quán
• Khi quy mô mã tăng lên, hiệu năng giảm và không thể duy trì ngữ cảnh
• Khi vượt quá kích thước cửa sổ ngữ cảnh của LLM, sẽ phát sinh vấn đề về tính nhất quán

• Các ví dụ vấn đề cụ thể:

  • Sao chép interface TypeScript
  • Chạy logic máy chủ ở phía client
  • Thất bại khi sửa các component trùng lặp
  • Thất bại khi viết unit test
  • Thất bại khi sửa lỗi sau khi refactor mã

Nỗ lực giải quyết vấn đề

• Claude Plays Pokémon: tác nhân tương tác theo thời gian thực và chơi game
• Thất bại trong việc duy trì bộ nhớ và sửa các lỗi lặp lại
• Thất bại trong việc xây dựng trí nhớ dài hạn → lỗi tiếp diễn liên tục

• Khả năng cải thiện:

  • Cần cải thiện MCP (Model Context Protocol) và quản lý bộ nhớ
  • Khi sửa mã, LLM phải phản ánh chính xác các lần sửa trước đó
  • Cần lưu giữ trí nhớ theo miền và lịch sử công việc

Kết luận

• "Vibe Coding" có thể đạt đến khoảng 80% trong việc hiện thực hóa các ý tưởng chức năng, nhưng để tạo ra sản phẩm đáng tin cậy và an toàn thì vẫn cần nỗ lực từ con người có kinh nghiệm
• Các tác nhân AI giúp những người có kỹ năng tạo ra nhiều thứ hơn một cách độc lập, nhưng không thể thay thế những người có thể giải quyết các vấn đề khó đòi hỏi kinh nghiệm và trực giác.
• Ở trình độ hiện tại, "Vibe Coding" khó dẫn tới những sản phẩm thực sự hữu ích trong thực tế, và sự hỗ trợ của các lập trình viên giàu kinh nghiệm là điều thiết yếu
• "Vibe Coding" chỉ là công cụ hỗ trợ viết mã, không phải phương tiện thay thế hoàn toàn

[nicewook]

Phần "mức độ hiện tại" thu hút sự chú ý của tôi. Có phải chúng ta đang nhìn LLM bằng khái niệm thời gian của con người không?

[ng0301]

Điều tôi cảm nhận khi code cùng AI là, nếu chia nhỏ thành các đơn vị theo kiểu nguyên tắc trách nhiệm đơn nhất + TDD để AI có thể hiểu được ngữ cảnh ngay cả khi chỉ được đưa một phần mã, thì cần thiết kế sao cho không phải đọc bối cảnh lớn mà chỉ với ngữ cảnh cục bộ cũng đủ để nắm bắt được.

[ifmkl]

Tôi cũng đồng ý vì thứ tôi dùng AI nhiều nhất cho sở thích là làm web game. Khi quy mô vượt qua một mức nhất định, đến một lúc nào đó sẽ xuất hiện những phần mà có lẽ nên gọi là độ tập trung của AI giảm đi rõ rệt. Tôi tận dụng việc này theo cách sau: gộp toàn bộ cây thư mục và mã nguồn trong game thành một file duy nhất kèm TOC, rồi khi tạo thread mới thì tải file đó lên và tiếp tục làm việc. Và khi đặt câu hỏi, tôi luôn yêu cầu trả lời bằng cách nói rõ ràng, một cách tường minh tên của dự án hiện tại. Dù vậy vẫn còn những chỗ chưa thật sự hài lòng... nhưng tôi rất hài lòng với việc có thể hoàn thành dần sở thích mà trước đây vì quá bận với cuộc sống thực nên thậm chí không dám bắt đầu, trong một khoảng thời gian tương đối ngắn.

[pcj9024]

Mình rất thích kiểu làm đại khái trước rồi chỉnh nốt các chi tiết còn lại.

[psguny9]

Tôi đang thử nhiều cách khác nhau, nhưng giới hạn về trí nhớ là rất rõ ràng. Ở mức PoC thì ổn. Xét về khả năng kiểm chứng nhanh tiềm năng/tính hữu dụng thì cũng tốt.

Vấn đề là lại càng cần người có kinh nghiệm.

[colus001]

Xét việc phần lớn thời gian trong lập trình là dành cho gỡ lỗi và đọc mã, tôi nghĩ cách nói đó bị cường điệu hóa khá nhiều. Những người làm AI thì ai cũng nói theo giọng điệu này, nhưng ít nhất nhìn vào tình hình hiện tại thì có vẻ chưa phải vậy. Nếu đến mức không còn cần bàn tay con người nữa, liệu có còn cần lập trình không? Khi đó có lẽ chỉ cần đưa phần mô tả API vào và dùng LLM làm backend thì hơn.

[reagea0]

Trên thực tế, nhiều người cũng dùng theo cách đó: thiết lập schema rồi nhận về.

[nowdoit7]

Tôi đồng ý. Ban đầu nó cho thấy tốc độ phát triển gần như kỳ diệu, nhưng khi quy mô lớn dần và số lượng tệp tăng lên, nếu người chịu trách nhiệm quản lý nó (ở đây là con người) không thể quản lý hiệu quả, thì thứ nhận lại sẽ chỉ là một sản phẩm phình to và đầy lỗi. Khi đã đi đến mức không còn cách cứu vãn, bạn chỉ lãng phí credit (Windsurf) hoặc request (Cursor). Dù mọi thứ sẽ dần tốt lên, nhưng ở thời điểm hiện tại không nên tin tưởng 100% vào mã do AI tạo ra.

[GN⁺]

Ý kiến trên Hacker News

• Khác biệt lớn giữa "AI bị thổi phồng vs. thực tế" nằm ở các con số năng suất mà mọi người thường nói tới. Ví dụ, các đối tác của YC trích dẫn việc một công ty tuyên bố đạt "nhanh hơn 100 lần" về hiệu suất lập trình. Những tuyên bố như vậy lẽ ra phải hiện rõ với người quan sát bên ngoài, nên không cần dựa vào tự báo cáo.

  • Khóa hè của YC kéo dài 84 ngày và kết thúc bằng demo day. Nhanh hơn 100 lần tương đương với việc một nhóm tạo ra một ứng dụng có mức tính năng ngang demo day trong chưa đầy một ngày. Nếu 100 lần là thật, các đối tác đã phải nói rằng các khóa mới đang "ăn sáng với khách hàng, học điều gì đó mới, được truyền cảm hứng, rồi viết lại ứng dụng ngay trong ngày, và kết quả có mức tính năng ngang demo day". Nhưng không có câu chuyện nào như vậy, nên 100 lần là không chính xác.
  • Ngay cả mức cải thiện 10 lần, các đối tác cũng đã phải nói rằng "ở khóa này, mọi người đã đưa một ứng dụng mức demo day lên production ngay trong tuần đầu tiên". Các đối tác có cỡ mẫu rất lớn về việc các nhóm hoàn thành được bao nhiêu việc trong khoảng thời gian nào. Vì vậy, 10 lần cũng không đúng.

• Hiện tại chúng ta đang chạy theo cơn sốt outsourcing. Bỏ qua mọi lời thổi phồng, thực tế lại khác. Các cuộc thảo luận về tác nhân lập trình LLM cũng khó mà phân biệt được.

• Cũng giống như cộng đồng Go từng nói máy tính không thể thắng người chơi Go. Đã có ví dụ về các mô hình tìm ra cách sắp xếp tốt hơn. Nếu có đủ động lực và thời gian phù hợp, máy tính sẽ vượt qua chúng ta.

  • "Vibe coding" vẫn chưa phải là thực tế. Vẫn cần kinh nghiệm và kỹ năng để sửa lỗi và định hướng. Nhưng có thể thấy rõ quỹ đạo cải thiện.

• Chia sẻ một vấn đề mới với LLM cho lập trình. Các lập trình viên offshore đã được tích hợp hoàn toàn vào đội ngũ. Nhưng việc dùng LLM quá bừa bãi và rời rạc khiến các pull request được gửi lên trở thành ác mộng.

  • Tôi dùng LLM để hỗ trợ viết mã, nhưng dùng rất cẩn trọng. Có tiết kiệm thời gian, nhưng không cải thiện chất lượng. Thời gian tìm cách prompt cho đúng, thời gian xác minh đầu ra và thời gian sửa các lỗi nhỏ đã bù trừ hết lợi ích đó.
  • Đừng làm "vibe coding" và hãy cẩn thận để không mất việc.

• "Vibe Coding" có thể hiện thực hóa 80% ý tưởng. Nhưng để tạo ra thứ gì đó đáng tin cậy, an toàn và có giá trị thì vẫn cần con người nhiều kinh nghiệm.

  • 80% trong trường hợp tốt nhất cũng chỉ là proof of concept. 80% cũng giống như QA bước vào quán bar.

• Gần đây tôi thử dùng Claude và OpenAI o3-mini để chuyển mã Matlab sang Python, nhưng kết quả rất tệ. Gần như mọi dòng quan trọng đều có lỗi. Đây là loại công việc cần tự động hóa, nhưng đã thất bại.

• Làm "Vibe-TDDing" vẫn tốt hơn là không có test. Nếu hiểu về lập trình và kiểm thử, bạn có thể dùng LLM để giảm các tác động ngoại lai tiêu cực.

• Sau khi chia sẻ cách xây dựng một SaaS, đã xảy ra chuyện kỳ lạ. Mức sử dụng API key chạm trần, subscription bị lách qua, và những thứ ngẫu nhiên xuất hiện trong DB. Có lẽ đây chỉ là trò đùa.

• Nhìn thấy nhiều kỹ sư đánh giá thấp năng lực và năng suất của các công cụ lập trình AI khiến tôi yên tâm hơn về công việc của mình. Tôi sẽ không rời Cursor.

  • Những gì công cụ AI làm tốt: viết mã lặp đi lặp lại, các tác vụ DSA phức tạp, các việc đơn giản và nhàm chán, refactor trong phạm vi hẹp
  • Những gì công cụ AI làm không tốt: ánh xạ sản phẩm/doanh nghiệp vào mã, refactor quy mô lớn
  • Chất lượng mã không phải vấn đề. AI vẫn giúp tăng năng suất rất nhiều.