Tòa tháp đầy lỗi, cơn say vibe, và xe trượt băng vibe

• Khi cách phát triển giao phó việc giải thích lại cho LLM ngay cả khi con người không hiểu đoạn mã do LLM tạo ra ngày càng lan rộng, ranh giới từng được phân biệt giữa agent engineering và vibe coding đang nhanh chóng mờ đi
• Xe trượt băng vibe chỉ con đường cố định từ tự động hoàn thành sang sinh mã, từ bỏ việc rà soát, rồi từ bỏ cả prompt; càng tận dụng tốc độ sinh ra, lập trình viên càng xa rời việc xây dựng lý thuyết và rà soát, vốn là vai trò cốt lõi của mình
• Trong thí nghiệm Pvote, các chuyên gia bảo mật dù đã biết trước vị trí vẫn rà soát khoảng 100 dòng mã trong gần 20 giờ mà không tìm ra lỗi khó trong ba lỗi, cho thấy giả định rằng con người có thể rà soát trọn vẹn lượng lớn đầu ra từ LLM là phi thực tế
• Cơn say vibe đang lan rộng khi mã và sản phẩm không được hiểu thâm nhập vào poster nhà hàng, chatbot hỗ trợ khách hàng, mã xác minh độ tuổi, cho tới issue·PR mã nguồn mở; ngay cả người không dùng công cụ cũng bị ảnh hưởng vì phải rà soát sản phẩm do người khác tạo ra
• AI tạo sinh có thể hữu ích trong việc phát hiện vấn đề nhưng đặc biệt yếu ở khâu tạo ra; ngay cả giữa xu hướng các hệ thống không thể hiểu được đang thay thế thế giới, con người cũng không nên từ bỏ khả năng tự tay tạo ra một môi trường tốt hơn

---

Tòa tháp của đoạn mã không thể hiểu nổi

• The Tower Keeps Rising quan sát thấy rằng ngay cả trong những tình huống trước đây phải nói chuyện với đồng đội mới giải quyết được, giờ đây vẫn có thể tiếp tục tiến triển bằng cách dùng agent
  • Armin không đánh giá đây là điều tốt hay xấu, cũng không bênh vực nó như một trạng thái bền vững
  • Tuy vậy, ông đang ở vị trí thúc đẩy xu hướng này khi điều hành một công ty vibe coding
• Hệ thống vibe coding tiếp tục chất thêm mã và các lớp trừu tượng, cuối cùng có thể đạt tới trạng thái không một con người nào hiểu được codebase
  • Ngay cả những phần con người không hiểu, LLM lại có thể diễn giải tiếp, từ đó xuất hiện một cách vận hành mới là vẫn tiếp tục phát triển được
• Ngay cả phía ủng hộ điều này cũng thừa nhận đích đến nơi con người không còn hiểu hệ thống, và xuất hiện sự thay đổi khi chấp nhận trạng thái đó như phương thức phát triển trong tương lai

Ranh giới giữa agent engineering và vibe coding sụp đổ

• Simon Willison ban đầu phân biệt rõ agentic engineering với vibe coding
  • Trong bài viết tháng 3/2025, ông đặt ra nguyên tắc rằng nếu là lập trình có AI hỗ trợ ở chất lượng production thì phải đọc mọi đoạn mã được commit vào repository và có thể giải thích chính xác cho người khác
  • Ngay cả khi mã do LLM viết, nếu con người rà soát, kiểm thử kỹ lưỡng và có thể giải thích cách nó hoạt động thì đó không phải vibe coding mà là phát triển phần mềm
• Hơn một năm sau, trong Vibe coding and agentic engineering are getting closer than I’d like, ông cho biết khi độ tin cậy của coding agent tăng lên, ngay cả mã production cũng không còn được rà soát từng dòng
  • Ông tin rằng Claude Code sẽ tạo đúng API endpoint chạy truy vấn SQL và trả về JSON, đồng thời thêm cả test và tài liệu
  • Đồng thời, ông cũng cảm thấy day dứt và nghi ngờ liệu dùng mã chưa được rà soát trong production có còn là hành động có trách nhiệm hay không
• Khoảng cách giữa hai lập trường này chỉ là hơn 1 năm một chút
• Dù nhận thức rằng agent engineering là cách dùng mong muốn đã lan rộng, người dùng thực tế, bao gồm cả chính Simon, vẫn có xu hướng bị kéo về phía vibe coding

Xe trượt băng vibe

• Xe trượt băng là môn thể thao lao nhanh xuống đường băng, nhưng thực tế gần như chỉ có một hướng để đi
  • Các vận động viên có thể so trình độ với nhau và cảm nhận sự phấn khích, nhưng người ngồi trên xe hầu như không có nhiều khoảng trống để chọn chính hành trình của mình
• Trong xe trượt băng vibe, LLM là phương tiện còn người dùng là hành khách
  • Quyền chủ động thực tế ít hơn nhiều so với cảm nhận của người dùng, và nó gần với một hành trình được dựng sẵn hơn là chỉ một con dốc trơn trượt
• Lập trình viên đi qua các bước sau và dần loại bỏ chính mình khỏi quá trình sản xuất mã
  • Ban đầu nghĩ rằng mình chỉ dùng nó như tự động hoàn thành nâng cao
  • Sau đó chạy agent để khám phá ý tưởng nhưng nói rằng sẽ tự viết mã
  • Tiếp theo để agent sinh mã nhưng tự nhủ sẽ rà soát mọi kết quả
  • Chẳng bao lâu sau, gần như không còn rà soát mã mà lại tin rằng agent có thể là lập trình viên giỏi hơn mình
  • Cuối cùng, vượt qua mức “không còn tự code nữa” để tiến tới giai đoạn “không còn tự viết prompt nữa”
• Mỗi bước là một quá trình chuyển sang sản xuất mã dựa trên niềm tin rằng LLM hiểu công việc của nó và xử lý tốt

Xung đột giữa tốc độ sinh ra và việc rà soát

• Phần chậm trong lập trình không phải là tạo ra mà là xây dựng lý thuyết và rà soát; những kết quả có vẻ hợp lý nhưng sai lại cực kỳ khó debug và khó hiểu
• Thuộc tính mạnh nhất của LLM là tốc độ sinh ra, nên nếu con người phải rà soát mọi kết quả thì rất khó tận dụng trọn vẹn tốc độ đó
• Ngược lại, xây dựng lý thuyết và rà soát lại là vai trò quan trọng nhất của lập trình viên, vì vậy càng tối đa hóa lợi thế của LLM thì càng phát sinh xung đột khi rời xa vai trò cốt lõi
• Luận án của Ka-Ping Yee, Building Reliable Voting Machine Software, chỉ ra bốn yếu tố khiến việc kiểm chứng phần mềm trở nên khó khăn
  • số lượng thành phần
  • tương tác phức tạp
  • phạm vi ảnh hưởng rộng
  • tính phi tuyến
• Bốn vấn đề này có thể còn trầm trọng hơn bởi cách LLM sinh mã

Thí nghiệm rà soát lỗi của Pvote

• Ka-Ping Yee và David Wagner đã cài vào máy bỏ phiếu mô hình Pvote ba lỗi ở mức dễ, trung bình và khó, mỗi mức một lỗi, có thể bị lợi dụng để thay đổi kết quả bầu cử
• Cả ba lỗi đều được đặt trong vùng 100 dòng tương ứng các dòng 11~109 của Navigator.py
  • Đây là phần thú vị về mặt logic chương trình, đồng thời là lựa chọn có tính đến thời gian hạn chế của người rà soát
  • Họ cho người rà soát biết khu vực cần xem, nhưng không cho biết có bao nhiêu lỗi
• Kết quả rà soát trong ngày thứ ba như sau
  • Dan Sandler, người rất thành thạo Python, đã tìm thấy lỗi dễ và lỗi trung bình trong khoảng 70 phút
  • Yoshi Kohno và Mark Miller tìm ra lỗi dễ sau khoảng 4 giờ
  • Không ai tìm ra lỗi khó
• Sang ngày thứ tư, Ian Goldberg tìm ra lỗi dễ trong khoảng 2 giờ nhưng không phát hiện lỗi nào khác
• Các chuyên gia bảo mật lành nghề, dù đã biết cả vị trí, vẫn bỏ ra tổng cộng khoảng 20 giờ-người rà soát mà không tìm ra đủ cả ba lỗi
• Mark S. Miller sau này, khi xác nhận các lỗi, đã ngạc nhiên vì mọi người đều đồng ý đó là những lỗi hiển nhiên và lẽ ra họ phải tìm thấy
• Nếu ngay cả những lập trình viên hàng đầu cũng có thể bỏ sót các lỗi chắc chắn tồn tại trong 100 dòng mã, thì cách con người rà soát khối lượng đầu ra khổng lồ của LLM là điều khó có thể gánh nổi
  • Rốt cuộc, người dùng sẽ từ bỏ việc rà soát và từng bước loại bỏ chính mình khỏi quy trình sản xuất mã

AI psychosis và cơn say vibe

• “AI psychosis” thường được dùng rộng để chỉ các hành vi hoặc kết quả xấu phát sinh từ AI tạo sinh, nhưng nghĩa gốc của nó gần hơn với trạng thái tương tác với chatbot quá mức khẳng định người dùng rồi dẫn tới loạn thần thực sự và sự lệch khỏi thực tại mang tính hoang tưởng
• Với cảm giác khó chịu lan rộng do AI tạo sinh gây ra nhưng không phải loạn thần lâm sàng, cơn say vibe (vibe sickness) là cách gọi phù hợp hơn
• Trong bài cảm nhận PyCon US 2026 của Glyph, các tình huống sau xuất hiện đồng thời
  • cơn say vibe lan rộng
  • khủng hoảng bền vững quy mô lớn của mã nguồn mở
  • làn sóng PR bảo mật chất lượng thấp
  • hy vọng, năng lượng, nỗ lực vì sự thấu hiểu lẫn nhau và lòng cảm kích đối với công việc

Sản phẩm tạo sinh lan vào đời sống thường nhật và mã nguồn mở

• Mọi người phàn nàn về slop, tức sản phẩm tạo sinh chất lượng thấp, nhưng người dùng AI tạo sinh lại không gọi chính kết quả của mình là slop
• Những sản phẩm tạo sinh có vẻ hợp lý nhưng không thể hiểu nổi xuất hiện ở khắp nơi trong đời sống
  • poster quán ăn địa phương với thiết kế khó hiểu
  • chatbot hỗ trợ khách hàng gây bực bội cho người dùng
  • mã xác minh độ tuổi
  • issue và PR chất lượng thấp được gửi vào các dự án mã nguồn mở
• Những công cụ này hữu ích cho một số công việc và có thể được đánh giá khác đi trong phát hiện vấn đề
• Tuy nhiên, chính phần tạo ra mà cái tên “genAI” nhấn mạnh lại là phần công cụ làm kém nhất
  • Không chỉ chất lượng sản phẩm tạo ra, mà còn phát sinh vấn đề là không ai hiểu được cách hệ thống được xây dựng, cấu trúc và bảo trì

Môi trường không thể thoát khỏi AI tạo sinh

• Dù không trực tiếp dùng AI tạo sinh, đồng nghiệp hay người đóng góp mã nguồn mở vẫn có thể gửi tới những sản phẩm tạo sinh mà chính họ cũng không hiểu như một “đóng góp”
  • Người rà soát phải băn khoăn liệu hỏi xem đó có phải nội dung do LLM tạo ra hay không có bị xem là bất lịch sự
  • Trong lúc trả lời issue hoặc PR, họ gián tiếp tương tác với agent và vô tình tham gia vào quy trình làm việc kiểu vibe coding
• Glyph ví việc từ chối mọi phần mềm có chứa LLM giống như nín thở cho tới khi mọi người ngừng dùng xăng pha chì để phản đối việc đưa nó vào ô tô
  • Trên thực tế, khó tránh khỏi phải chấp nhận ở một mức độ nào đó; ngay cả khi đặt ra lằn ranh đạo đức cá nhân, điều đó cũng không có nghĩa là kỳ vọng hay hào hứng với môi trường AI tạo sinh
• Thung lũng kỳ lạ (uncanny valley) đang chiếm lấy thế giới thực, và các hệ thống không ai hiểu nổi đang thay thế thế giới cũ
• Cái giá phải trả khi phục hồi khỏi trạng thái này vẫn chưa được xác định, và những dự án chọn không tham gia vào AI tạo sinh hiện tại đáng được tôn trọng

Lựa chọn tạo ra một địa hình tốt hơn

• Vì công việc hay môi trường, có thể bạn không thể hoàn toàn từ chối góp phần vào các vấn đề do AI tạo sinh gây ra
• Cũng như người lái ô tô có thể bực bội với người đi xe đạp trên đường, nhưng nếu hạ tầng xe đạp thiếu thốn thì người đi xe đạp sẽ gặp nguy hiểm vì cửa xe đỗ bên đường hoặc những tài xế nóng vội
• Nếu đang lái xe mà phía trước có xe đạp, ta có thể biết ơn sự hiện diện của họ và nghĩ tới cách thay đổi địa hình và hạ tầng để xe đạp có thể tham gia an toàn hơn
  • Những thay đổi như vậy giúp việc lái ô tô dễ dàng hơn và, tùy tình huống, cũng giúp việc chọn đi xe đạp trở nên dễ hơn
• Không nên từ bỏ niềm tin rằng con người có thể trực tiếp tham gia để tạo ra một thế giới tốt đẹp hơn, thay vì phó mặc bản thân cho con đường do công nghệ định sẵn

[GN⁺]

Các ý kiến trên Lobste.rs

• Đây chắc chắn là một trong những bài viết hay về những thay đổi trong ngành kỹ nghệ phần mềm mà gần đây tôi vẫn bất an theo dõi.

• Chỉ một năm trước, kỹ nghệ theo kiểu tác tử dường như là hướng đi đáng mong muốn, nhưng đa số người dùng công cụ thực tế có vẻ đang nghiêng về vibe coding, chỉ là ngần ngại thừa nhận. Nỗi sợ rằng LLM có thể khiến kỹ năng và niềm yêu thích của tôi trở nên vô dụng đã giảm đi nhiều sau khi tôi đặt ra hai nguyên tắc.
  Thứ nhất, trong thời gian rảnh tôi không dùng LLM hay tác tử lập trình, và cũng từ chối các tính năng AI của công cụ tìm kiếm. Tôi chỉ chấp nhận rủi ro ảo giác và dùng chúng khi thật sự bế tắc đến mức không thể tự giải quyết. Làm ngơ công nghệ không khiến thế giới tự giải quyết vấn đề, nhưng trong hoàn cảnh không thể tấn công từng lập trình viên cá nhân hay thay đổi các tập đoàn lớn, thì không để nó can dự vào cả thời gian rảnh là lựa chọn thực tế mà tôi có thể làm.
  Thứ hai, ngay cả ở nơi làm việc khuyến khích mạnh việc dùng AI, tôi cũng chỉ dùng cho review code và việc vặt. Tức là hỏi những thứ có thể tự tìm trực tiếp trong codebase nhưng khá phiền, còn code thì tôi tự viết toàn bộ. Như vậy tôi mới hiểu trực giác được nguyên lý hoạt động và có thể làm việc ở mức mà bản thân và đồng nghiệp kỳ vọng.
  LLM khá ổn như một công cụ hỗ trợ phát hiện các lỗi dựa trên mẫu mà linter tất định không tìm ra. Nó cũng đưa ra câu trả lời vớ vẩn, nhưng vì tôi tự viết và hiểu code nên không tin mù quáng. Nếu lọc được các lỗi logic rõ ràng và giả định sai trước khi con người review, đồng nghiệp có thể tập trung vào những phần phức tạp hơn, đồng thời tránh sự bất lịch sự khi biến các kênh công khai thành nơi máy móc nói chuyện với nhau thay con người.
  Gần đây công ty đã siết chặt giới hạn sử dụng token, nhưng quy trình làm việc của tôi chỉ tốn 1–2 euro mỗi ngày nên tôi không lo. Những người từng dựa hoàn toàn vào trực giác có thể bất an khi phải quay lại dùng suy luận của con người, nhưng phần còn lại thì chỉ cần tự làm cùng đồng nghiệp.

  • Lời phê bình kiểu “vùi đầu vào cát thì có giải quyết được gì không” không phải đến từ một bên thứ ba thật sự, mà là lời mình tự nói thay cho nhà phê bình tưởng tượng. Càng để ý đến kiểu phê bình đó khi lựa chọn, cuộc sống càng tệ đi, nên tôi cũng cố cảnh giác với nó.
    Bên dưới còn có một kiểu nhận thức luận tự hành hạ, cho rằng càng đau đớn thì càng phải nhìn thẳng vào sự thật. Tránh né thông tin gây khổ sở có thể khiến ta cảm thấy như mình thiếu đức hạnh, nhưng sự chú ý là hữu hạn, nên tốt hơn là dùng nó cho những việc khiến ta hạnh phúc và trọn vẹn hơn, để ngày mai vẫn còn sức tiếp tục.
  • Điều này giống “vì ghét làm việc ở văn phòng nên trong thời gian rảnh tránh văn phòng” hơn là vùi đầu vào cát. Nếu có thể tránh việc không đem lại niềm vui thì tránh là hợp lý.
    Những người đối xử với mọi thứ trong đời như một công việc phải tối ưu hóa và phải trở thành giỏi nhất lại là người chịu thiệt. Nếu thích lập trình thì cứ làm cả lúc rảnh; nếu không thích, cứ để nó chỉ là nghề nghiệp. Trong thời gian rảnh, đôi khi kém hiệu quả cũng không sao; nếu không, thời gian tự do sẽ biến thành công việc thứ hai và chẳng hề được nghỉ ngơi.

• Việc viết sai chính tả Fawlty ở đây làm tôi khó chịu quá mức.

  • Có vẻ họ cố ý viết vậy như một trò chơi chữ về tháp Babel “gây trục trặc”.

• Bài viết vẫn xuất sắc như mọi khi, nhưng có lẽ không cần băn khoăn liệu hỏi một thứ có phải do LLM tạo ra có bất lịch sự không. Bất kể trong quá trình tạo ra nó có dùng LLM hay không, nếu bạn nhận được một kết quả tệ hại thì có thể nói rằng chất lượng kém và tôi không thích.

  • Nếu đó là một người đóng góp mới mà mình không biết, thì việc chỉ ra vấn đề chất lượng của PR và trả trách nhiệm sửa lại cho họ là hợp lý. Tuy nhiên, tôi nhớ dự án Zig đã áp dụng chính sách phản đối AI vì muốn trực tiếp hướng dẫn con người, chứ không phải LLM, để biến người đóng góp mới thành người đóng góp lâu dài.
    Ngược lại, với đồng nghiệp hoặc người đã tương tác lâu trên mạng, có thể ta muốn tránh bất lịch sự hết mức để duy trì quan hệ. Cần biết đóng góp đó được tạo ra như thế nào thì mới có thể thảo luận, và kết quả của việc đó cũng có thể cố ý ảnh hưởng lớn đến mối quan hệ. Việc chấp nhận rủi ro bất lịch sự, hay mặc định tránh xung đột để giữ quan hệ, là lựa chọn tùy tính cách.
    Bản thân tôi vốn hay tránh xung đột nên hiểu bối cảnh vì sao câu đó xuất hiện, và cũng không phản đối nhiều luận điểm chính.

• Tôi thích ẩn dụ xe trượt băng bobsled. Tôi không đồng ý với lập luận rằng người dùng LLM chắc chắn sẽ trượt đến tận cuối đường, nhưng nó mô tả hành vi đang quan sát được trong ngành tốt hơn bất kỳ ẩn dụ nào tôi từng thấy.

• “Ẩn dụ bobsled” thường được biết đến nhiều hơn như ngụy biện logic dốc trơn trượt. Một năm trước, tỷ lệ vibe coding là 0%, và Simon Willison đã công khai trong nhiều bài viết quá trình thận trọng đưa tác tử lập trình vào sử dụng rồi dần tăng mức độ tin cậy.
  Thế mà lại dựa vào đó để kết luận rằng “chỉ có một đích đến duy nhất”. Sẽ hợp lý hơn nếu cho rằng Willison và những người dùng khác cũng có thị hiếu và năng lực phán đoán riêng.