- Khi tận dụng các công cụ coding AI và dần giao cho chúng những công việc ngày càng lớn hơn, tác giả đã cảm thấy kinh ngạc, nhưng rồi xác nhận rằng tính nhất quán và độ hoàn thiện về mặt cấu trúc của kết quả còn thiếu
- Dù đã viết đặc tả chi tiết, AI agent vẫn không thể duy trì ngữ cảnh dài hạn hoặc phát triển thiết kế, và cuối cùng toàn bộ codebase biến thành một tập hợp các mảnh ghép không đồng nhất
- Các đoạn mã khi xét riêng lẻ có vẻ hoàn chỉnh, nhưng xét tổng thể thì xuất hiện sự lộn xộn về cấu trúc (sloppy) và sự sụp đổ ngữ cảnh
- Sau những trải nghiệm đó, tác giả đi đến kết luận rằng không thể dùng code do AI tạo ra để bảo đảm niềm tin của người dùng hay bảo vệ dữ liệu, và quay lại cách tự viết code
- AI coding vẫn hữu ích, nhưng có thể gây ra nợ kỹ thuật và sự mất quyền kiểm soát của lập trình viên, nên cần được sử dụng một cách thận trọng
Sự phấn khích ban đầu với AI coding và việc nhận ra giới hạn
- Phần lớn người dùng bắt đầu với AI coding bằng những tác vụ đơn giản, rồi dần giao cho nó các bài toán phức tạp hơn và trầm trồ trước hiệu năng
- Nhưng sau một thời điểm nhất định, lỗi và sự thiếu nhất quán của AI bắt đầu lộ rõ, tạo ra khoảng cách giữa kỳ vọng và thực tế
- Khi kết quả không như ý, người dùng thường quy nguyên nhân về prompt của chính mình và cố gắng viết đặc tả cụ thể hơn
- Họ dùng các công cụ như Obsidian để viết tài liệu spec chi tiết, nhưng AI không thể phát triển chúng về lâu dài
Thất bại của cách tiếp cận dựa trên đặc tả
- Trong phát triển thực tế, tài liệu thiết kế là “tài liệu sống” liên tục thay đổi trong quá trình khám phá và triển khai
- Nhưng AI agent lại bị cố định vào đặc tả ban đầu, nên không thể linh hoạt chỉnh sửa hoặc diễn giải lại
- Khi xử lý các cấu trúc phức tạp, agent có xu hướng đánh mất toàn bộ ngữ cảnh của vấn đề hoặc cố tiến hành một cách gượng ép
- Kết quả là code nhìn bề ngoài có vẻ hoàn chỉnh nhưng lại thiếu tính nhất quán nội tại và tính toàn vẹn cấu trúc
Sự suy giảm chất lượng code và giới hạn của ‘vibecoding’
- Code do AI viết có thể trông rất tốt ở từng phần riêng lẻ, nhưng xét tổng thể lại trở thành một tổ hợp vô nghĩa
- Sau khi rà soát toàn bộ codebase, tác giả phát hiện bên trong nó tồn tại “sự lộn xộn thuần túy (slop)”
- AI trung thành với prompt và tính tự nhất quán của chính nó, nhưng không cân nhắc sự hài hòa của toàn hệ thống hay tính nhất quán giữa các mẫu liền kề
- Điều này giống với hiện tượng “vibewriting”, nơi một vài đoạn văn của tiểu thuyết rất hay nhưng toàn bộ chương lại rời rạc, lộn xộn
Quay lại phát triển lấy con người làm trung tâm
- Tác giả cho rằng không thể đem code do AI sinh ra đi triển khai thành sản phẩm hoặc dùng để bảo vệ dữ liệu người dùng
- Với quyết tâm “không nói dối người dùng bằng đoạn code này”, tác giả quay trở lại tự mình lập trình
- Khi tự viết, tác giả cảm nhận rằng tốc độ, độ chính xác, tính sáng tạo và năng suất lại được cải thiện
- Nếu đánh giá theo hiệu quả phát triển tổng thể chứ không chỉ tốc độ sinh code đơn thuần, con người vẫn chiếm ưu thế
Tiếp tục sử dụng AI coding nhưng có ranh giới
- Tác giả vẫn dùng LLM ở mức hạn chế cho một số công việc (khoảng 40%)
- Nó hữu ích với các tác vụ lặp lại hoặc sinh code đơn giản, nhưng nợ kỹ thuật và sự suy giảm khả năng hiểu code sẽ dần tích lũy
- Về lâu dài, có nguy cơ lập trình viên đánh mất mô hình tinh thần về codebase, và không thể giải quyết vấn đề nếu thiếu AI
- Trong lúc di chuyển (tàu hỏa, máy bay...), cũng có thể xảy ra tình huống năng suất giảm về 0% do phụ thuộc vào AI
- Các lập trình viên khác chỉ ra rằng tư duy “chỉ cần viết spec cho tốt” là sự tái hiện của mô hình waterfall, trong khi phát triển thực tế đòi hỏi khám phá ngẫu hứng và tương tác liên tục
Kết luận
- AI coding vẫn là một công cụ mạnh mẽ, nhưng khả năng duy trì ngữ cảnh toàn hệ thống và tính nhất quán về cấu trúc còn thiếu
- Khả năng phán đoán trực giác và điều chỉnh ngẫu hứng của lập trình viên con người vẫn là yếu tố cốt lõi,
và AI nên được dùng như công cụ hỗ trợ dưới sự kiểm soát thận trọng
8 bình luận
Khái niệm vibe coding còn chưa được tạo ra đủ tròn 1 năm mà nói như thể làm suốt 2 năm, đúng kiểu làm màu trên SNS thôi lol
Cần đầu tư công sức vào việc gọt giũa đặc tả chứ.. Nếu thật sự làm và tinh chỉnh đặc tả đúng theo kiểu chính quy đã học trong kỹ nghệ phần mềm, rồi vừa quản lý truy vết vừa cập nhật trong quá trình làm thì sẽ rất ổn.
Khi làm dự án, tôi luôn tiếp tục nâng phiên bản template tài liệu đặc tả và prompt, nhưng giờ thì bắt đầu thấy có lẽ mình nên thật sự học kỹ hơn về kỹ nghệ phần mềm.
Tác giả vẫn đang sử dụng LLM một cách hạn chế cho một số công việc nhất định (khoảng 40%)
Nhìn vào cách mô tả như trên, có vẻ tác giả cũng không hẳn cho rằng cần phải loại bỏ hoàn toàn AI.
Có vẻ chúng ta cần tiếp tục suy nghĩ về cách tận dụng nó cho tốt. Tôi cho rằng phát triển mà bỏ qua AI thì sẽ dần bị tụt lại phía sau.
Tác giả bài viết này đã dùng những phương pháp tận dụng hiệu quả rồi, nhưng dù vậy tôi vẫn nghĩ cần cân nhắc theo hướng tận dụng AI tốt hơn nữa.
(Vẫn chỉ là còn nhiều thử và sai... )
Hãy cập nhật đặc tả.
A, già đi thật ghét.
Ý kiến trên Hacker News
Tôi cho rằng chính việc AI làm quá tốt những thứ cơ bản mới là điều nguy hiểm
Sinh viên sẽ không còn tự viết code vì nghĩ rằng “AI làm thay rồi”, và kết quả là họ không thể tự mình học được các bước trung gian hay những khái niệm khó
Với tư cách là một giáo viên CS, tôi luôn nhấn mạnh với học sinh rằng “chính em phải tự viết code, không phải cái máy”
Dùng xe nâng để nhấc vật nặng thì dễ, nhưng cơ bắp sẽ không phát triển
Chính nỗi đau trong quá trình học mới là cốt lõi của sự trưởng thành
Dĩ nhiên trong công việc thì kết quả quan trọng hơn, nhưng vẫn cần những người có thể tư duy ở tầng cao
Ứng viên có kiến thức lý thuyết hoàn hảo, nhưng hoàn toàn không thể giải thích nguyên lý hoạt động của chính đoạn code mình viết
Cuối cùng người đó thú nhận rằng “GenAI đã viết phần lớn”, và khoảng cách giữa ‘đã học’ và ‘đã tự làm’ là quá lớn
Dạy ‘code được viết như thế nào’ không còn quan trọng bằng dạy ‘code hoạt động như thế nào’
Ngày xưa từng có thời người ta phải tự viết bằng assembly, nhưng giờ nguyên lý của compiler mới là thứ đáng để hiểu hơn
Trên thực tế đa số mọi người sẽ không bao giờ tự viết compiler hay OS, nhưng hiểu nguyên lý của chúng sẽ giúp nắm được giới hạn của ngôn ngữ lập trình
Khi compiler mới xuất hiện cũng từng có tranh luận y hệt, và cuối cùng chúng ta vẫn tiến lên các tầng trừu tượng cao hơn
Chỉ triển khai đơn thuần thì không thể đào sâu suy nghĩ
Nếu giao phần triển khai cho AI, rốt cuộc sẽ thành cảnh ‘người mù dò đường cùng nhau’
Quá trình trực tiếp đụng vào code và suy nghĩ về nó là điều thiết yếu
Tôi không đồng tình với câu “AI làm tốt việc nhỏ nhưng còn làm tốt việc lớn hơn”
Trên thực tế tôi chỉ nhận được những kết quả gây thất vọng
Code hoặc không chạy đúng, hoặc cần chỉ dẫn chỉnh sửa lặp đi lặp lại
Nếu vòng phản hồi khó vận hành thì cuối cùng chính mình sẽ là nguồn phản hồi duy nhất, và lúc đó mới cảm nhận rõ giới hạn của AI
Ví dụ nếu mô tả rõ cấu trúc TaskManager hay quy tắc ownership của bộ nhớ, nó có thể tạo ra code vượt qua cả test
Có người như Ryan Dahl nói rằng “giờ tôi không còn tự viết code nữa”, nhưng đó là vì họ mài giũa như đang cộng tác thật sự thông qua phản hồi lặp lại
Phải đối xử với AI như đang dạy một đứa trẻ
Mô tả rõ input, output và lỗi dự kiến, rồi thử nghiệm lặp lại và chỉnh sửa
Claude sẽ đặt câu hỏi, nghiên cứu và thậm chí review code
Cảm giác như đang mentor một lập trình viên junior rất có năng lực
Ban đầu tôi thử “vibe coding” với tâm thế cởi mở, nhưng càng lúc càng trở nên hoài nghi
Nó phù hợp với code lặp lại và rõ ràng, nhưng không thích hợp với logic cốt lõi của doanh nghiệp
Claude thường bỏ qua đặc tả, lặp đi lặp lại cùng một logic nhiều lần, hoặc nói là đã sửa nhưng thực tế vẫn để nguyên
Thậm chí còn có cảm giác model ngày càng đần đi
Giờ tôi chỉ dùng nó cho thảo luận thiết kế hoặc debug
Nếu có quá nhiều “phần chán ngắt” để AI lấp vào, có lẽ ngay từ đầu cấu trúc code đã có vấn đề
Ở điểm này LLM vẫn còn hữu ích
Nhiều developer vốn chỉ nhận bản thiết kế đã chốt sẵn rồi đi triển khai, nên AI có thể tăng tốc cho họ
Tôi không đồng ý với nhận định rằng “AI không phản ánh được thay đổi trong thiết kế”
Ngược lại, tôi nghĩ “đó chính là vai trò của con người”
Ví dụ nếu bảo nó thay đổi cấu trúc API, AI có thể tìm mọi phần liên quan để sửa và còn chạy test nữa
Hoặc là quá bám vào chi tiết triển khai, hoặc là bỏ sót phần kiểm chứng khái niệm
Dù vậy test do con người viết cũng thường tương tự nên tôi vẫn hiểu được
Nếu không tự tay viết code thì sẽ rất khó cảm nhận những phần thô ráp và mất cân bằng của lớp trừu tượng, và điều đó cuối cùng dẫn đến suy giảm chất lượng cấu trúc
Chính khác biệt này quyết định mức độ hoàn thiện của code
Nhưng điều quan trọng là phải biết phán đoán khi nào một việc thực sự cần con người can thiệp bằng tay
Tuy nhiên phải dùng gói cao cấp (ví dụ Claude Max 200 đô) thì mới đạt hiệu quả
Tôi thấy nghi ngờ với câu “đã vibe coding từ 2 năm trước”
Karpathy chỉ mới đặt ra thuật ngữ này cách đây chưa đầy 1 năm (nguồn)
Điều thú vị là GPT đã tự thiết kế API mà chính nó sẽ dùng, rồi triển khai theo API đó
Nhưng về sau các model bắt đầu chặn những cuộc hội thoại liên quan đến tự sửa đổi và tự sao chép
Không cần công cụ dạng agent hoàn chỉnh, chỉ với ChatGPT hay Claude cũng đã làm được
và giờ đã bắt đầu cộng tác với AI từ ngay giai đoạn nghiên cứu để đạt kết quả tốt
Tôi nói với học sinh rằng “xem thể thao trên TV không có nghĩa là bạn đang tập thể dục”
Vibe coding cũng vậy, vẫn có cảm giác thành tựu chỉ có được khi tự tay viết code
nhờ ‘đoạn code nửa hoàn chỉnh’ do AI tạo ra mà tôi lại có thêm động lực
Tôi nghi ngờ rằng các kỹ sư thực thụ có thật sự mù quáng làm ‘vibe coding’ hay không
Bản thân tôi thì dùng cách gọt giũa code qua đối thoại nhiều hơn
Tôi đưa ra yêu cầu, cùng AI xem lại phương án thiết kế, rồi dần dần hoàn thiện cấu trúc
Quá trình này chậm nhưng vẫn giữ được chiều sâu của tư duy và sự cộng tác
AI đưa ra ý tưởng mới dựa trên lượng lớn code đã học, còn tôi dùng kinh nghiệm để điều tiết chúng
Cuối cùng AI giống như một phiên bản mở rộng của tôi (me++)
Tôi vẫn chưa sẵn sàng giao hết cho một agent hoàn toàn, nhưng cách này là hiệu quả nhất
Tôi cảm thấy code do AI viết giống như một cuốn tiểu thuyết có từng đoạn rất hay nhưng tổng thể thì rối tung
Nhìn theo từng chương thì hoàn hảo, nhưng xét toàn bộ ngữ cảnh thì lại hỗn loạn
Nếu vậy thì kỳ vọng một codebase 10.000 dòng được vibe-code sẽ hoạt động tử tế là điều quá sức
Nếu không phản ánh suy nghĩ và cảm xúc của con người, trải nghiệm người dùng cũng sẽ mất đi tính nhất quán và sinh ra ma sát nhận thức
và nói rằng khi thiết kế đã rõ ràng thì LLM có thể tăng tốc bùng nổ cho các phần việc boilerplate
Nhưng phần thiết kế vẫn là việc của con người
Có thể xem dự án của anh ấy ở bản phát hành công khai trên GitHub
Tôi thừa nhận rằng code do LLM tạo ra có thể rất tốt ở từng phần nhưng yếu ở cấu trúc tổng thể
Nhưng nếu hiểu codebase và tự mình review kỹ thì hoàn toàn có thể bù đắp được
Vibe coding rất phù hợp cho làm prototype
Cách hiệu quả là nhanh chóng bắt nhịp, rồi sau đó refactor và mở rộng dần
Tức là vibe coding thực sự là chỉ nhìn kết quả đầu ra rồi phán đoán mà thôi