33 điểm bởi GN⁺ 17 ngày trước | 9 bình luận | Chia sẻ qua WhatsApp
  • Nhân vụ rò rỉ mã nguồn của Claude, tác hại của việc mù quáng tin vào "vibe coding" đối với chất lượng dự án thực tế đã bị phơi bày
  • Vibe coding lấy việc hoàn toàn không nhìn vào bên trong mã nguồn làm nguyên tắc, nhưng điều này chỉ là một sự mê tín thuần túy; trên thực tế luôn phải đi kèm với sự thiết kế cấu trúc của con người như file kế hoạch, kỹ năng, quy tắc
  • AI thực sự rất giỏi ở các công việc như dọn dẹp mã trùng lặp và nợ kỹ thuật, nhưng để tận dụng được điều đó thì con người phải trực tiếp xem mã, xác định vấn đề và giải thích cho AI
  • Hiếm khi AI tự nhận ra rằng "có spaghetti code ở đây, cần phải dọn lại"; khi con người cung cấp trước định hướng và bối cảnh thì kết quả mới có chất lượng cao
  • Như câu "phần mềm tệ là lựa chọn của lập trình viên", sự suy giảm chất lượng là kết quả của các quyết định, chứ không phải do AI
  • Nói cách khác, chất lượng phần mềm đi xuống không phải lỗi của AI mà là lựa chọn do chính lập trình viên đưa ra

Vụ rò rỉ mã nguồn Claude và vấn đề của vibe coding

  • Mã nguồn của Claude đã bị rò rỉ và bị nhiều người chế giễu vì chất lượng mã thấp
  • Nguyên nhân của vấn đề này được chỉ ra là dogfooding quá mức, tức văn hóa sử dụng sản phẩm của chính mình một cách quá mù quáng
  • Bản thân việc tự dùng sản phẩm là một ý tưởng tốt, nhưng có thể bị biến chất thành một hoạt động mang tính sùng bái vượt qua mọi giới hạn hợp lý

Bản chất thực sự của vibe coding

  • Vibe coding là cách làm lấy nguyên tắc không hề đóng góp gì vào bên trong mã, thậm chí còn không nhìn vào nó
  • Tuy nhiên, vibe coding thuần túy là một huyền thoại (Myth) — trên thực tế luôn tồn tại framework do con người tạo ra như file kế hoạch (danh sách việc cần làm), kỹ năng, quy tắc; nếu không có cấu trúc này thì AI thể hiện rất kém
  • Mã được viết bằng tiếng Anh nên ai cũng có thể đọc được, vậy mà các lập trình viên lại từ chối tự kiểm tra bằng lập luận rằng "nhìn vào bên trong là gian lận"
  • Trên thực tế, khi một người xem mã thì đã phát hiện sự trùng lặp quy mô lớn giữa agent và tool, một vấn đề mà chỉ cần ai đó liếc qua một lúc là có thể dễ dàng nhận ra

AI và việc dọn dẹp nợ kỹ thuật

  • Các dự án phần mềm thường khởi đầu với nợ kỹ thuật, và trước đây có những trường hợp chỉ riêng việc dọn dẹp đã mất tới 1 năm
  • Nếu tận dụng AI, công việc dọn dẹp này có thể hoàn thành trong vài tuần, hoặc được giải quyết dần dần song song với việc phát triển tính năng mới
  • AI rất giỏi dọn dẹp mã, nhưng lại kém ở khả năng tự phát hiện vấn đề — kết quả tốt xuất hiện khi con người chỉ ra rằng "ở đây có spaghetti code" và cung cấp hướng dẫn

Cách sử dụng AI đúng đắn — phương pháp tiếp cận dựa trên đối thoại

  • Để giải quyết vấn đề trùng lặp đúng cách, tác giả đưa ra các bước sau:
    • Lập danh sách các mục tương ứng với cả agent và tool
    • Xem ví dụ rồi xác định mỗi mục là agent hay tool
    • Thảo luận tiêu chí tổng thể và xây dựng guideline chung
    • Kiểm tra toàn bộ danh mục rồi sửa các mục bị phân loại sai
    • Với các mục cùng tồn tại ở cả hai bên, xem xét hai phiên bản rồi gộp thành một
  • Chế độ Ask được tạo ra cho quy trình này; cốt lõi là cùng xem xét ví dụ và sửa ngay những điểm sai khi AI cố gắng đồng ý quá mức
  • Sau khi trao đổi đủ nhiều, bạn có thể cảm thấy AI đã tạo ra kết quả trông như one-shot, nhưng thực tế đó là thành quả dựa trên rất nhiều tương tác trước đó với con người
  • Nhóm Claude đã áp dụng dogfooding một cách cực đoan mà bỏ qua toàn bộ quy trình này, đến mức từ chối cả nỗ lực tối thiểu là nhìn lướt vào mã và mô tả vấn đề

Ví dụ sử dụng thực tế

  • Ví dụ workflow của tác giả: khi bắt đầu cuộc trò chuyện sẽ nói như "hãy kiểm tra mã không thể truy cập được trong codebase này" hoặc "hàm này nhìn đau cả mắt"
  • Tác giả tiếp tục đối thoại cho đến khi tìm ra hướng có thể thực thi, giải thích việc cần làm rồi tiếp tục thảo luận cho đến khi AI ngừng nói những điều ngớ ngẩn
  • Sau đó lập kế hoạch và chạy build là cách làm hằng ngày

Chất lượng phần mềm là vấn đề của lựa chọn

  • Dùng AI không có nghĩa là phải chấp nhận phần mềm chất lượng thấp
  • Những thư viện do các lập trình viên nhận thù lao quá cao làm ra mà không có AI hỗ trợ cũng có thể có chất lượng tệ
  • Phần mềm tệ là quyết định do chính mình đưa ra, và con người phải chịu trách nhiệm cho điều đó cũng như theo đuổi chất lượng tốt hơn

9 bình luận

 
koreacglee 17 ngày trước

Không khí tôn sùng việc vibe coding thật điên rồ. Người ta cứ rao giảng rằng chỉ cần dùng AI AGENT để FULL AUTO MATION, tự động hóa hoàn toàn từ sinh code, merge, review đến kiểm chứng, rồi để mọi thứ tự vận hành đến mức gần như chẳng cần bận tâm gì về cấu trúc code, chỉ thỉnh thoảng khi các agent tự vướng vào nhau hoặc lúc đó lập trình viên mới can thiệp là xong; ai không làm được như vậy thì bị coi là kẻ bất thường, không theo kịp xu hướng... Nhìn mấy người vốn ngày thường cứ tung ra đầy rẫy boilerplate code và những đoạn code chỉ là chuỗi lặp của các pattern đơn giản mà vẫn lĩnh lương cao ngất, rồi giờ lại mạnh miệng nói rằng với AI thì không cần viết code nữa, đúng là chán chẳng buồn nói.

 

Muốn tạo ra mã có chất lượng ra hồn thì phải micro-manage đến cả những chi tiết rất nhỏ. Tôi nghĩ chuyện tự động hóa hoàn toàn là điều vô lý, trừ khi chỉ dùng để sản xuất hàng loạt những đoạn mã boilerplate thật sự. Những người nói về tự chủ hoàn toàn thì thuộc một trong hai kiểu: либо là không hiểu rõ, либо là kẻ lừa đảo.

 
blacksocks 14 ngày trước

Các dự án nửa vời tràn lan…
những người chỉ hiểu lập trình một nửa thì lại cuồng nhiệt…

 
qwertypotter 17 ngày trước

dogfooding tốt hơn nên được hiểu là “dog pudding” chứ không phải độc chiếm.

 

dog食...

 
iolothebard 16 ngày trước

Tiêu đề và nội dung khác nhau…?

 
summerpicnic 17 ngày trước

Có vẻ giống kiểu chỉ trích mà vội kết luận rằng vibe coding đồng nghĩa với không làm code review rồi ghép lý do vào cho khớp.

Thêm nữa, việc lôi cả Claude Code vào cũng không hợp lý. Nếu thực sự xét đến các nguyên tắc kỹ thuật ở mức đòi hỏi chất lượng kiểu như bảo trì Linux, thì người ta sẽ không tiếp cận vấn đề chất lượng mã một cách phiến diện như thế này. Phần lớn gần như là cách tiếp cận mang tính tuyên truyền, kiểu nghe nói vậy thôi chứ không phải đã tự kiểm thử trực tiếp.

Nó hơi giống như chê thiết kế tòa nhà của Samsung không hay rồi bảo rằng vẫn còn lâu mới bắt kịp Sony.

 

Lúc mới thử Claude Code lần đầu, tôi đã nói với mấy người bạn nước ngoài rằng: “Tôi vừa thử vibe coding lần đầu!” Nhưng sau khi nghe tôi kể, họ lại trả lời kiểu: “Không, cái đó không phải vibe coding đâu, vibe coding đúng nghĩa là làm mà thậm chí không nhìn vào code cơ.” Có vẻ như ‘vibe coding’ thường được nói đến ở Hàn Quốc được định nghĩa rộng hơn rất nhiều so với cách phương Tây định nghĩa. Vibe coding theo cách nói trên Hacker News đúng là nên được hiểu là ‘không review code’.

 
Ý kiến trên Hacker News
  • Thật kỳ lạ khi mọi người lấy chất lượng mã nguồn bị rò rỉ của Claude Code làm ví dụ để nói rằng ‘vibe coding’ đã thất bại
    Ngược lại mới đúng. Tôi nghĩ đó là bằng chứng cho thấy vẫn có thể tạo ra sản phẩm phổ biến và thành công dù vi phạm các quy tắc “code tốt” truyền thống

    • Phần lớn mã sản phẩm tôi từng thấy lúc mới nhìn vào đều gây sốc. Ở BigCo cũng vậy mà ở startup cũng vậy
      Nhiều đoạn code chắp vá làm tạm vì deadline cứ thế ở lại production
      Với dự án cá nhân cũng thế, những commit đầu thường rất lộn xộn, rồi sau này mới tạo branch dọn dẹp để chỉnh lại
      Nhưng ở công ty thì gần như không có thời gian làm bản nháp thứ hai, thứ ba, nên cuối cùng bản nháp đầu tiên được đem đi deploy
      Thành thật mà nói, tôi cũng lo code mang tên mình có ngày bị lộ. Nhưng thực tế là vậy
    • Code tệ có thể chạy ổn trong ngắn hạn, nhưng về lâu dài chắc chắn sẽ gây vấn đề
      Khi sửa code mà bắt đầu có cảm giác “cái này hơi gượng ép”, thì sửa ngay lúc đó rốt cuộc lại là cách tiết kiệm thời gian
      Với LLM thì tôi chưa có nhiều kinh nghiệm nên không dám chắc
    • Việc “có thể thành công dù phá vỡ các quy tắc code tốt” thực ra từ xưa đến nay vẫn luôn như vậy
    • “Vibe coding” là một phổ tùy theo mức độ con người can thiệp
      Claude Code về bản chất là một sản phẩm đơn giản, và giá trị thực sự nằm ở chính mô hình
      Tức là đây là sản phẩm rủi ro thấp, nơi chất lượng code thấp cũng không thành vấn đề quá lớn, nên mới có thể xảy ra trường hợp như vậy
  • Cũng không phải là vi phạm khái niệm “vibe coding”. Cấu trúc của nó là đưa ra ý tưởng trừu tượng ở mức cao, còn code thực tế do AI viết
    Claude Code ở mức AI Level 7 (con người viết spec, bot viết code), và tác giả cho rằng Level 6 tốt hơn
    Mức lý tưởng của mỗi người là khác nhau. Có người xem Level 5 trở xuống là giới hạn, có người lại thấy từ Level 2 trở lên đã là nguy hiểm

    • Trong lĩnh vực computer vision mà tôi làm, phần UI hay app thì ở khoảng Level 6~7, nhưng pipeline rendering hay thuật toán thì AI can thiệp lại thành cản trở
      Mức phù hợp thay đổi tùy theo độ phức tạp và độ mới của lĩnh vực
    • Cốt lõi để dùng AI tốt là áp dụng mức độ khác nhau cho từng phần
      Ví dụ, app tôi làm có phần thuật toán ở Level 0, UI ở Level 7, middleware ở đâu đó ở giữa
      Tìm đúng mức cho từng vùng code mới là kỹ năng thật sự
    • Tôi đang làm việc ở khoảng Level 5. Có nhiều hàng rào an toàn như TDD, type safety, viết spec, v.v.
      Với ngôn ngữ động thì cao hơn mức này là thấy bất an. Nếu tiến tới Level 7 trở lên, tôi nghĩ tốt hơn là chuyển hẳn sang ngôn ngữ kiểu tĩnh
    • Những người phát triển nhanh nhất sau này sẽ là các lập trình viên đẩy đến mức cao nhất của thang này
      Việc coding rồi sẽ chỉ còn lại một phần nhỏ như nghề rèn thủ công, còn phần lớn sẽ được tự động hóa
      Nhưng nhờ vậy một người sẽ có thể làm công việc mà trước đây cả một team mới làm nổi
    • Ở công ty tôi ở Level 4, nhưng dự án cá nhân thì lén lút lên tới Level 6
      Sự cám dỗ chấp nhận tính năng dù chưa hiểu hoàn toàn cách nó hoạt động là rất lớn
  • Tác giả bài viết này là người sáng lập BitTorrent. Không phải blogger bình thường

    • Thấy Bram quay lại tham gia những cuộc thảo luận như thế này thật đáng mừng
    • Phần lớn thậm chí còn không biết BitTorrent là gì, nhưng có vẻ vẫn “cảm” được cái vibe
    • Xét theo sự nghiệp của ông ấy, tôi nghĩ lẽ ra nên có thêm cơ sở lập luận cho các khẳng định
  • Cách tôi thích dùng Claude Code nhất là để cải thiện chất lượng code
    Những việc nếu người làm thì trông như phí thời gian, AI làm gần như miễn phí nên lại hợp lý
    Như dọn các mẫu test lặp lại, giữ tính nhất quán khi JSON serialization, loại bỏ code trùng lặp
    Kết quả là codebase nhỏ hơn và dễ bảo trì hơn. Nó giống một kiểu linting quy mô lớn

    • Tôi cũng làm tương tự, chạy nhiều model (Opus, GPT5.4, Gemini) song song để phát hiện bug và cải thiện code
      Tôi đối chiếu chéo kết quả mà từng model tạo ra, rồi cuối cùng Opus lập danh sách cuối cùng để sửa
      Có nhiều thay đổi không cần thiết, nhưng những vấn đề bị bắt ra thực sự hữu ích
  • Góc nhìn “Dogfooding” khá thú vị
    Điểm chính không phải là chất lượng code, mà là người dùng có đánh giá được kết quả AI một cách phản biện hay không
    Một kỹ sư giàu kinh nghiệm dùng AI nhưng vẫn giữ năng lực phán đoán là chuyện hoàn toàn khác với việc giao luôn phán đoán cho AI
    Vấn đề là công cụ không phân biệt được hai kiểu này, còn marketing thì lại nhắm vào kiểu thứ hai

  • Những người ủng hộ ‘vibe coding’ cho rằng chất lượng code không quan trọng vì LLM có thể lặp (iteration) nhanh hơn con người rất nhiều
    Con người tốn kém ở từng bước (viết–kiểm chứng–sửa), còn LLM có thể lặp nhanh chỉ với chi phí token
    Nhưng tôi hoài nghi cách tiếp cận này. Tôi đã thấy quá nhiều trường hợp thực tế bị hỏng
    Dù vậy, nếu LLM tiếp tục tiến bộ thì có thể họ sẽ đúng

  • Trong phổ “vibe coding” có hai nhóm
    Một là những người không có nền tảng kỹ thuật nhưng thấy hay nên thích, nhóm kia là những người ghét AI
    Ở giữa là một tầng lớp trung gian im lặng nhưng năng suất cao. Họ vừa lạc quan vừa nhiều kinh nghiệm
    Sáu tháng qua tôi đã dùng khoảng $2500 credit Claude Code, phần lớn dù không thực sự được deploy nhưng vẫn mang lại giá trị cực lớn

    • Có câu hỏi là đo “tăng năng suất” thế nào. Khó định lượng, nhưng cảm nhận thì rất rõ
  • Tôi không đồng ý với nhận định “Claude Code là vô dụng”
    Phần lớn web app chỉ ở mức CRUD đơn giản. 99% công ty thậm chí còn không có 50.000 người dùng

    • Ứng dụng doanh nghiệp có ít người dùng hơn, nhưng tải CPU hay DB lại lớn hơn nhiều
      Công ty tôi từng làm phải chạy chương trình 22 giờ mỗi ngày vì code kém hiệu quả
    • Cần phân biệt “người dùng” với “người dùng trả tiền”. Ý nghĩa khác nhau
    • Thật ra deploy cho 100 người thôi cũng đã là địa ngục rồi. Có lẽ thời đại ‘citizen developer’ sẽ không đến đâu
  • Hiện tượng này khiến tôi nhớ đến lý thuyết đổi mới của Clayton Christensen
    Các công ty hiện tại thường tự mãn với sản phẩm sinh lời cao trước mắt và phớt lờ công nghệ mới chất lượng thấp, nhưng rốt cuộc công nghệ đó sẽ tiến bộ đủ để đảo lộn thị trường
    Claude Code cũng đã ở mức “đủ tốt”, và nếu AI tiếp tục phát triển thì cuối cùng nó sẽ vượt qua code viết thủ công

    • Ngay cả khi tiến bộ của AI dừng lại, chúng ta vẫn sẽ tạo ra tooling và pattern mới xoay quanh các model hiện tại
    • Nhưng bầu không khí hiện giờ quá lạc quan. Còn có cả chuyện lãnh đạo muốn bỏ test và code review. Có vẻ họ đang đánh giá thấp rủi ro
  • Những người xoay quanh ‘vibe coding’ có thể chia thành vài nhóm
    ① người có lợi ích tài chính, ② lập trình viên đã chán coding, ③ người mới lần đầu tạo ra thứ gì đó
    ② không muốn học cái mới, còn ③ đang thật sự cảm nhận niềm vui sáng tạo
    AI coding có thể trở thành con đường nhập môn tốt cho họ

    • Còn một nhóm nữa. Đó là những người hiệu suất cao yêu coding nhưng muốn làm được nhiều hơn
      Tôi cũng thuộc kiểu đó. Suốt 30 năm tôi yêu việc coding, nhưng thời gian biến điều mình tưởng tượng thành hiện thực luôn quá dài
      Giờ khoảng cách đó đã biến mất nên tôi thấy như được giải phóng. Mục tiêu là học cách tăng tốc mà vẫn giữ chất lượng
    • Tôi cũng đã thấy các kỹ sư xuất sắc tích cực tận dụng AI mà vẫn không hạ thấp tiêu chuẩn, đồng thời tạo ra nhiều kết quả hơn
    • Thực ra 10 năm qua của ngành phần mềm là thời kỳ của sự phức tạp không cần thiết
      Cứ bê nguyên vấn đề của tập đoàn lớn về làm theo nên năng suất giảm, còn mệt mỏi thì tăng
      Giờ nhờ AI, có thể bỏ qua đống phức tạp đó và đi thẳng tới kết quả
      Dù có framework hay cách deploy mới xuất hiện cũng không cần bận tâm. AI sẽ xử lý hết
    • Nhưng biết đâu người mà bạn nói là “không muốn học” thực ra lại là người đang học cái mới
      Mỗi lần có thay đổi thế hệ công nghệ, kiểu xung đột này lại lặp lại
    • Cá nhân tôi thì gần đây sự cẩu thả (sloppiness) lại khiến mình mất hứng