Vibe code là legacy code
(blog.val.town)- Vibe coding là cách viết mã nhanh theo trực giác với sự hỗ trợ của AI, và rốt cuộc sẽ để lại phần mã mà người viết không hiểu, tức là legacy code
- Legacy code là đoạn mã mà không ai thực sự hiểu, gây ra nợ kỹ thuật và các vấn đề bảo trì, đồng thời làm tăng khả năng phát sinh lỗi khi thêm tính năng mới
- Vibe coding có thể là một cách phát triển nhanh cho prototype hoặc dự án ngắn hạn, nhưng không phù hợp với các dự án cần được duy trì lâu dài
- Khi người không chuyên dùng vibe coding cho một dự án lớn, rủi ro cũng giống như đưa thẻ tín dụng cho một đứa trẻ
- Ngay cả trong năm 2025, khi phát triển cùng AI, việc giữ sự thận trọng và duy trì mức độ hiểu biết vẫn rất quan trọng
Vibe coding là gì
- Andrej Karpathy định nghĩa thuật ngữ "vibe coding" là một kiểu lập trình trong đó AI viết mã, còn người dùng gần như không bận tâm đến nó đến mức quên cả sự tồn tại của chính đoạn mã
- Cách tiếp cận này khác với phát triển phần mềm truyền thống ở chỗ nhà phát triển vẫn có thể tạo ra sản phẩm mà không cần hiểu gì về bên trong đoạn mã đã được tạo ra
Vấn đề của legacy code và nợ kỹ thuật
- Mã mà không ai hiểu được thì đã là legacy code
- Loại mã này tốn rất nhiều thời gian để duy trì và bảo trì, đồng thời làm gia tăng đáng kể vấn đề khi xuất hiện bug hoặc khi thêm tính năng mới
- Bài viết nhấn mạnh rằng bản chất của lập trình không phải là tạo ra thật nhiều mã, mà là xây dựng lý thuyết khái niệm
Vibe coding và prototyping
- Vibe coding mang lại khả năng bắt đầu và phát triển nhanh cho việc làm prototype hoặc dự án dùng một lần
- Nếu không cần bảo trì về sau, thì việc không biết bên trong mã hoạt động thế nào cũng không phải gánh nặng lớn
- Vì vậy, nó có thể tăng tốc độ phát triển lên đáng kể và rất phù hợp để thử nghiệm các ý tưởng mới
Phổ mức độ hiểu biết trong vibe coding
- Vibe coding là cách làm mà nhà phát triển càng hiểu ít về mã thì lại càng nhiều vibe hơn
- Về cơ bản, kỹ sư càng hiểu rõ yêu cầu thì mức độ vibe coding càng giảm
- Khi một người không biết lập trình yêu cầu tạo mã mà không phân biệt được web với ứng dụng native, hay không biết dữ liệu được lưu như thế nào, thì thông thường sẽ phát sinh nhiều vibe coding hơn
Vibe coding quy mô lớn bởi người không chuyên: giống như thẻ tín dụng
- Việc một người không chuyên cố tạo và duy trì một dự án lớn bằng vibe coding giống như đưa thẻ tín dụng cho một đứa trẻ mà không giải thích khái niệm gì cả
- Ban đầu mọi thứ có thể trông rất dễ dàng, nhưng sau đó sẽ kéo theo chi phí bảo trì khổng lồ và hàng loạt vấn đề
- Cuối cùng, khi 'hóa đơn' đến, nếu không có khả năng xử lý vấn đề thì tình hình còn có thể trở nên tệ hơn
Phát triển nghiêm túc trong kỷ nguyên AI năm 2025
- Andrej Karpathy nhấn mạnh rằng khi phát triển cùng AI, sự thận trọng, sự cẩn thận và thái độ liên tục học hỏi về mã hiện có là điều bắt buộc
- Cần có khả năng phán đoán của con người để chống lại sự tự tin quá mức của AI, cũng như để phân biệt mã tốt và mã xấu
- Không nên chỉ giao hết cho AI, mà nhất định phải tự đọc và hiểu mã
Cách Val Town sử dụng công cụ AI
- Val Town tự động hóa quá trình viết mã, chạy mã, kiểm tra và cải tiến lặp đi lặp lại thông qua trợ lý AI có tên Townie
- Townie là công cụ phù hợp cho vibe coding, và có thể được dùng linh hoạt hoặc bị kiểm soát chặt chẽ tùy mục đích sử dụng
- Cách phát triển cùng AI đang tiến hóa rất nhanh, nhưng tầm quan trọng của nền tảng lý thuyết trong phát triển phần mềm phức hợp vẫn sẽ tiếp tục được duy trì
Cảnh báo về vibe coding thiếu kiểm soát của người không chuyên
- Việc người không biết lập trình chi hàng nghìn đô la để vibe coding một ý tưởng ứng dụng khổng lồ không phải là cách làm tốt
- Xét cho cùng, luôn cần đến con mắt con người để trực tiếp đọc và phân tích bên trong mã; và thay vì cố sửa legacy code khó hiểu, thường sẽ hiệu quả hơn nếu thiết kế lại cho đúng ngay từ đầu
Kết luận và lời khuyên
- Khi xây dựng phần mềm phức tạp, nền tảng lý thuyết là yếu tố cốt lõi
- Dù AI đang nhanh chóng làm thay đổi cách lập trình, chuyên môn của nhà phát triển con người vẫn rất quan trọng
- Nếu người không chuyên cố tạo một ứng dụng quy mô lớn bằng AI, thì rốt cuộc việc đọc toàn bộ mã và làm lại từ đầu có thể vẫn là lựa chọn tốt hơn
12 bình luận
Phép so sánh này giống như đưa thẻ tín dụng cho một đứa trẻ
quả là một phép so sánh phù hợp
hay cũng có thể ví như đưa dao cho một đứa trẻ
Nếu xuất hiện AI tạo mã có thể tự thêm cả chú thích cho mã do AI sinh ra và vẽ sơ đồ luồng code, thì cũng sẽ hữu ích ở một mức độ nào đó.
Đây là một câu chuyện khá đáng đồng cảm. Thực tế tôi cũng đang trực tiếp trải qua một phần trong đó…
Đồng thời cũng tò mò không biết phần này sẽ thay đổi ra sao theo sự biến chuyển về hiệu năng của mô hình.
Đúng là một câu nói quá chuẩn, nghe xong chỉ biết đập đùi cái đét. Những người không hiểu code thì khi làm vibe coding sẽ thốt lên "wow", còn những người biết code thì sẽ nói "tại sao lại như thế này?"
Tình trạng bình luận thật thảm hại.
Vậy thì ô tô có phải là thứ mà cho đến khi hiểu hết toàn bộ cấu trúc bên trong của nó thì vĩnh viễn không thể lái được sao?
Làm ô tô mà không hiểu cấu trúc bên trong = vibe coding
Có thể dùng được. Nhưng chắc là không thể tạo ra nó.
Tôi nghĩ đây là vấn đề về phương pháp và kỹ thuật; những người nói đừng dùng AI mà phải code tay kiểu hữu cơ thì cũng giống như những người bảo chân lý là đừng dùng máy tính kỹ thuật hay hàm Excel mà hãy gảy bàn tính hoặc viết tay vậy.
Đó là một phép so sánh sai. Máy tính kỹ thuật, cũng như máy tính cầm tay hay Excel, cho ra kết quả chính xác theo giá trị đầu vào. Nếu AI xuất ra đúng nguyên vẹn kết quả mà người dùng dự đoán, thì nó hẳn đã không phải là một công nghệ khác biệt đến vậy so với vô số công nghệ mới từng xuất hiện cho đến nay. Đó cũng là lý do vì sao theo thời gian, những lo ngại về bảo mật và hallucination ngày càng lớn hơn. Nói cách khác, Gen AI là thứ không thể kiểm soát hoàn toàn. Cần hiểu rõ giới hạn hiện tại của LLM và chỉ nên dùng chúng ở những nơi phù hợp.
Hiện tại, vibe coding vẫn mới chỉ ở giai đoạn sơ khai, và tôi nghĩ sang năm hoặc năm sau nữa nó sẽ trở thành một phương pháp phát triển đã trưởng thành. Cũng như devops trở thành aidevops, tôi cho rằng rồi sẽ xuất hiện aiagile hoặc vibeagile.
Ý kiến trên Hacker News
Đây là câu chuyện về một người bạn không phải lập trình viên. Năm ngoái, anh ấy tự code và ra mắt một SaaS, rồi bắt đầu có doanh thu hầu như chỉ nhờ truyền miệng và inbound, gần như không làm marketing. Anh ấy dùng Replit và Supabase để phát triển, và nghĩ đến việc ứng dụng ngày càng phức tạp hơn khi nhận phản hồi khách hàng thì thật sự rất ấn tượng. Theo tôi, trên thị trường này đã có sẵn hai bên hiện hữu, và vì bạn tôi đưa ra một sản phẩm hiện đại hơn với mức phí hàng tháng rẻ hơn nhiều nên có vẻ họ không hài lòng lắm (các sản phẩm cũ đều là phần mềm desktop cho Windows). Vì vậy, họ thuê hacker tấn công SaaS của bạn tôi, và những hacker này tấn công mà không đòi tiền chuộc. Đáng tiếc là vì anh ấy code quá nhanh khi chưa có kinh nghiệm nên có rất nhiều lỗ hổng. Đầu tiên, danh sách người dùng bị lộ trong mã frontend nên hacker đã gửi email cho toàn bộ khách hàng. Thứ hai, hacker lấy được khóa Stripe rồi hoàn tiền cho toàn bộ khách hàng. Thứ ba, đến giờ hacker vẫn thử tấn công XSS, thỉnh thoảng vẫn xuất hiện các thẻ như
<script>alert()</script>trong các trường nhập liệu. Kết luận của tôi là, khi người thiếu kinh nghiệm làm vibe-coding thì technical debt sẽ tích tụ gần như ngay lập tức. Nhưng đồng thời, việc người bạn này chứng minh được tính khả thi thương mại của một sản phẩm chỉ trong vài tháng mà không có kinh nghiệm kỹ thuật cũng rất đáng kinh ngạc. Hiện tại anh ấy đang tuyển lập trình viên để khắc phục. Với chỉ vài trăm đô đầu tư mà đã chứng minh được tiềm năng kinh doanh khá tốt bằng thứ mã lỏng lẻo và kém bảo mật như vậy, nên rốt cuộc tôi nghĩ quá trình đó vẫn có giá trịTôi thấy giả định rằng đây là do đối thủ cạnh tranh làm có vẻ giống trốn tránh trách nhiệm hơn. Thực tế có lẽ chỉ là các trình quét lỗ hổng tự động phát hiện ra trang web, rồi vì nó quá sơ hở nên hacker chui vào phá phách thôi. Những ai thường xuyên thấy kiểu lưu lượng khai thác này trên các dịch vụ kết nối Internet đều sẽ hiểu
Về mặt đạo đức, chuyện này chẳng khác nào xây một căn nhà mà không có kinh nghiệm kỹ thuật, rồi có người chỉ việc đá một cái là nó sập. Vấn đề không nằm ở vibe coding tự thân, mà ở chỗ thiếu kiến thức cần thiết để đưa ra các quyết định quan trọng. Những chuyện như vậy thậm chí có thể dẫn đến trách nhiệm pháp lý
Nếu thị trường đã có sẵn các bên cung cấp từ trước, thì có thật là cần một MVP kiểu này để chứng minh nhu cầu không? Về bản chất, nếu cung cấp rẻ hơn thì người ta sẽ chuyển từ nhà cung cấp cũ sang, nên chẳng cần kiểm chứng điều đó. Bài học mà bạn anh nhận được là: một số khách hàng có thể sẵn sàng trả tiền ở giai đoạn đầu (chưa có dữ liệu về tỷ lệ quay lại), nhưng cuối cùng vẫn phải tuyển người để làm ra một sản phẩm thực thụ, và khi đó lợi thế cạnh tranh về giá cũng sẽ giảm đi. Khi đến lúc phải đầu tư nghiêm túc cho marketing thì sẽ có rất nhiều điều phải cân nhắc. Cuối cùng lại quay về sự thật quen thuộc là ý tưởng tự nó không có giá trị gì, năng lực thực thi mới là mấu chốt
Vấn đề căn bản của ngành này là bạn anh có thể tiếp tục kinh doanh mà gần như không phải chịu trách nhiệm gì. Nếu phần mềm bị quản lý chặt chẽ như các ngành kỹ thuật khác, thì lập trình viên hay doanh nghiệp hẳn đã phải chịu trách nhiệm pháp lý vì làm lộ thông tin khách hàng
Dù xét ở góc độ chứng minh tính khả thi kinh doanh thì có thể đã thành công, nhưng từ phía khách hàng thì đây có thể là thiệt hại chứ không phải lợi ích. Họ vừa trả tiền để dùng, vừa đặt dữ liệu quan trọng vào một nơi yếu kém về bảo mật, trong khi cũng chưa rõ sản phẩm có thực sự hoạt động tử tế hay không. Giờ nói sẽ tuyển lập trình viên để vá lại thì có lẽ không dễ như tưởng tượng. Tôi ủng hộ AI khi nó được dùng làm tài liệu học, công cụ tăng năng suất, hay công cụ học tập, nhưng nếu không có con người ở giữa thì kết quả có thể rất tệ
Trước đây cũng đã nhiều lần người không phải lập trình viên hoặc lập trình viên junior dễ dàng tạo và triển khai ứng dụng bằng Microsoft Access, Excel, v.v. Khi đó cũng đầy rẫy giới hạn, vấn đề mở rộng và ác mộng vận hành, nhưng đồng thời làn sóng đó cũng thúc đẩy các lập trình viên chuyên nghiệp tăng tốc làm ra giải pháp tốt hơn. Thời PC phổ cập cũng vậy, các lập trình viên mainframe từng kinh hãi khi nhìn đống mã “hỗn loạn” của thế giới PC
Tôi đã làm kỹ sư phần mềm gần ba mươi năm và đã đọc hết các bình luận trong bài này. Nhưng tôi nghĩ gần như mọi lập luận chỉ trích vibe coding đều áp dụng y hệt cho mọi codebase “do con người viết” mà tôi từng thấy trong suốt thời gian đó (dĩ nhiên vẫn có ngoại lệ)
Tôi không hiểu vì sao một prototype làm ra để vứt đi lại bị coi là xấu. Đó là bước quan trọng nhất khi bắt đầu kinh doanh. Legacy code cũng vậy. Trên thực tế, phần lớn mã đang tạo ra doanh thu rất có thể đã bị chính các lập trình viên trong tổ chức đó coi là legacy rồi
Có câu đùa rằng, mọi thứ trở thành legacy ngay từ khoảnh khắc được merge vào trunk
Tôi hơi đồng ý, nhưng vấn đề của vibe coding là nó cho phép người ta lao vào làm mà không nghiên cứu tử tế, không tìm hiểu cấu trúc codebase hiện có hay giải pháp thật sự cần là gì. Mới hôm qua thôi, một đồng nghiệp không quen Rust đã dùng vibe coding để làm tính năng mới; bề ngoài thì “chạy được”, nhưng thực tế cực kỳ tệ (I/O đồng bộ trong ngữ cảnh tokio async, lock, tự triển khai channel, v.v.). Dù đã có sẵn các abstraction bất đồng bộ an toàn, người đó vẫn tạo ra abstraction mới sai bét. Nếu tự tìm hiểu hoặc hỏi giúp đỡ trước thì có thể đã tham khảo được ví dụ trong code hiện có
Mọi đoạn mã rồi cũng sẽ trở thành legacy code. Từ hồi tôi còn là junior, rồi qua kinh nghiệm review vô số script production hay mã dịch vụ do các đồng nghiệp junior viết, tôi thấy kiểu nhìn tuyệt đối hóa này là quá đà. Vấn đề này lặp lại ở hầu hết các tổ chức. Tôi cũng hiểu việc viết bài phê phán chất lượng mã do LLM tạo ra, nhưng ai đã dành cả sự nghiệp để sửa, mở rộng hoặc refactor hệ thống do người khác làm ra thì sẽ hiểu thực tế này rõ hơn. Trừ khi thế giới kỹ nghệ phần mềm áp dụng các tiêu chuẩn nghiêm ngặt về tính nhất quán, chứng nhận, trách nhiệm và kết quả thực tế như cơ khí, nếu không thì tranh luận kiểu này cũng không có nhiều ý nghĩa. Bản thân ngành IT hiện đại được xây trên một triết lý hoàn toàn ngược lại: ‘agile’, ‘làm nhanh rồi hỏng cũng không sao’. Phát hành nhanh, thiết kế ít, deploy thường xuyên, nếu lên nhầm thì rollback, nếu sập thì “đành chịu thôi”. Phần mềm đang bị đối xử như đồ chơi. Có lẽ 1% tự tin rằng họ làm đúng bài bản, nhưng phần lớn thì không
Hiện tại đang có một chuyện thú vị xảy ra. Những người không hiểu rõ về engineering, và cả một số người hiểu ở mức nào đó nhưng lại không giải thích cho đúng, đang lan truyền một narrative sai lệch trên mạng. Họ nói rằng giờ junior developer năng suất gấp 10 lần, thậm chí PM cũng tự deploy code. Nhưng chỉ cần nhắm mắt lại và hình dung đoạn mã được tạo ra trong hoàn cảnh đó, thì 100% đó là legacy code và code để vứt đi. Bản chất vấn đề không nằm ở AI, hay việc PM có thể kéo code trực tiếp từ Figma, hay junior spam prompt. Lý do thật sự của khoảng cách giữa kỳ vọng và thực tế là vì người ta không còn phân biệt được đúng các thuật ngữ và khái niệm vốn được định nghĩa qua nhiều năm tranh luận.
lean prototype và disposable prototype (thậm chí còn chưa phải MVP) là hai thứ khác nhau. MVP cũng lại khác và chỉ có thể làm sau khi lean prototype đã được kiểm chứng thành công. Product lại là một thứ khác nữa so với MVP.
Các công cụ vibe coding rất tuyệt để tạo disposable prototype thật nhanh, còn IDE tích hợp LLM thì phù hợp hơn để làm product thực sự. Ở giai đoạn hiện tại, chỉ kỹ sư thực thụ mới đạt tới mức code lean prototype bằng prompt LLM, còn phần còn lại chỉ tạo ra phần mềm đơn giản chạy bằng disposable code
Anh nói “product khác với MVP”, và tôi muốn nói câu đó với gần như mọi công ty tôi từng làm. Dạo này hội đồng quản trị và giới C-level đều có thái độ kiểu “quý này cứ tung ra thứ gì đó đi”, nên lập trình viên làm xong MVP là lập tức bị đẩy sang dự án tiếp theo. Bất kể có phải vibe coding hay không, thực tế là chỉ cần nhìn có vẻ nhiều tính năng thì các chỉ số kinh doanh vẫn tăng, dù chất lượng thật ra thế nào. Môi trường mà kỹ sư thực thụ (giờ có vẻ người ta gọi như vậy thay cho “developer”) chủ động dẫn dắt việc prototyping thật ra rất hiếm. Có lẽ chỉ thấy trong game hoặc một vài công ty tech. Còn đa số thì chỉ chăm chăm làm MVP. Vibe coding đơn giản là tăng tốc độ sản xuất MVP, và chất lượng bị hy sinh tương ứng
Xu hướng dùng lẫn lộn “định nghĩa thuật ngữ” mà không có thực chất đã tăng lên rõ rệt trong ngành suốt 10 năm qua. Những thuật ngữ này vốn là các từ đã tích lũy ngữ cảnh qua vô số sách vở, tranh luận và thời gian rất dài. Khi một lập trình viên dày dạn dùng một từ, trong đó đã gói sẵn toàn bộ kinh nghiệm và bối cảnh tranh luận. Nhưng người mới vào lại “copy” bề mặt của từ đó mà không có ngữ cảnh, không định nghĩa ý nghĩa rồi cứ thế dùng. Kết quả là chẳng ai còn nắm được gốc rễ từng từ thật ra nghĩa là gì, hay vì sao nó phù hợp với bối cảnh đó. Ví dụ như "'agile', 'technical debt', 'DevOps', và gần đây nhất là ‘vibe coding'", v.v. Trên HN cũng có một bài về semantic drift. Đây là hiện tượng rất phổ biến trong ngành phần mềm.
Ví dụ kỹ thuật là trong JavaScript, người ta trộn lẫn 'object', 'JSON', 'dictionary', 'hashmap' như thể là một. Ban đầu mỗi từ có nghĩa khác nhau, nhưng với các lập trình viên JS thì tất cả chỉ còn là ‘object’. Nó giống như độ phân giải ngôn ngữ và khái niệm bị nghiền nát thành chỉ còn một “pixel”
Trước đây các lập trình viên hay nói rằng mỗi người có “tâm thế” khác nhau với code. Nhưng giờ thì sự mệt mỏi của lập trình viên vì không ai hiểu nổi code đã tăng khủng khiếp. Trước kia khi rơi vào tình huống như vậy, kỹ sư sẽ đứng ra sửa phần hỏng cho hữu ích, còn kiến trúc sư sẽ giảm bớt độ phức tạp. Giờ trong thời đại LLM, lượng code đổ ra nhiều gấp 100 lần, nhưng bản thân kỹ sư và kiến trúc sư lại bị loại khỏi dòng chảy đó. Đó chính là thực trạng mà chúng ta đang trực tiếp cảm nhận.
Nếu ai đó nghĩ ra được phương pháp kiểm thử để giải quyết chuyện này (TDD MCP server, DDD MCP server hay bất kỳ workflow/architecture nào), thì hoàn toàn có thể thành startup trị giá nghìn tỷ. Chúng ta đang rất cần công cụ có thể tăng mạnh và mở rộng hiệu quả code review
Tôi nghĩ phải định nghĩa rõ hơn cả “phần mềm hoạt động được” là gì. Ví dụ, UI do LLM tạo ra trông cái nào cũng giống nhau, và thường sai sai ở mức tinh vi hoặc ẩn lỗi bên trong. Chỉ cần test với người dùng một lần là lộ vấn đề ngay. Ngoài ra, UI sinh bởi AI thường chỉ bám xu hướng chứ không tạo ra được thứ gì mới
Anh đã từng nhìn cách các tập đoàn lớn viết code nội bộ chưa? Nó cũng chẳng khác vibe coding là mấy. Thậm chí nếu tune LLM để vượt qua pentest thì ít ra nó còn cố làm gì đó. Còn các tập đoàn lớn thì đơn giản là chẳng thèm quan tâm
Thực ra mọi code đều là legacy. Vì thế việc vibe coding tạo ra nhiều code nhanh không có gì đặc biệt. Cuối cùng thì cả “đoạn mã do chính tay tôi viết mà cũng chẳng ai hiểu nổi” cũng tệ như nhau. Xét về bảo trì, mọi code đều chỉ là gánh nặng. Library cũng chỉ giúp giảm bớt vấn đề; những thứ thay đổi thường xuyên hoặc giao diện đã lạc hậu thì còn là legacy tệ hơn nữa.
Người càng viết code lâu năm thì càng đi đến kết luận rằng đáp án là tạo ra ít hơn, tức là giảm tổng nhu cầu ngay từ đầu. Mọi độ phức tạp cuối cùng đều trở thành “vấn đề mà bản thân trong tương lai sẽ không còn nhớ nữa”. Thực tế là yêu cầu cũng thay đổi liên tục, và ngay cả yêu cầu do chuyên gia đưa ra cũng có thể sai (mà “chuyên gia” đó có khi chính là mình)
Tôi không đồng ý với lập luận “mọi code đều là legacy”. Có những đoạn mã nhỏ mà người viết vẫn nắm trọn trong đầu, nên nó hoàn toàn ở trạng thái ‘thời gian thực’. Định nghĩa thực chất của legacy là mã có quy mô lớn và hiện không còn ai trong tổ chức thực sự sở hữu nó. Vibe code thỏa mãn sẵn cả hai điều kiện đó ngay từ khi nó được tạo ra
Legacy là khi không còn stakeholder nào gắn với nó nữa, nên việc bảo trì lẫn nắm lại ngữ cảnh đều trở nên khó khăn
Tôi muốn giải quyết vấn đề với ít code nhất có thể. Mấu chốt là khiến code không phải là vấn đề của tôi. Vấn đề nằm ở abstraction rò rỉ đến mức nào, mà các abstraction do LLM tạo ra hiện rất tệ. Nó sẽ cải thiện đến đâu trong tương lai thì chưa rõ.
Tôi muốn đầu tư vào các công cụ giúp việc hiểu code trở nên thú vị hơn, dễ hơn và rẻ hơn. Bạn tôi Glen đang làm một dự án có thể đáng tham khảo: https://glench.github.io/fuzzyset.js/ui/
Như Geoffrey Litt từng nói, LLM có thể hữu ích hơn nhiều trong việc tạo ra các công cụ trực quan hóa tạm thời, debugger, v.v. để giúp chúng ta hiểu code của chính mình
Mọi code đều có rủi ro, nhưng không phải tất cả đều là legacy. Mã do vibe coding tạo ra có cảm giác trở thành legacy ngay lập tức vì ngay từ đầu nó đã không có ngữ cảnh hay chủ sở hữu
Để phản bác quan điểm “mọi code đều là legacy”, tôi cho rằng nếu đó là dự án mà tôi hiểu rất sâu, có thể chỉ ra nguyên nhân bug ngay lập tức và hình dung cách triển khai tính năng mới trong đầu, thì đó không phải legacy
Theo tôi, “thời đại nhìn code như toán học” đã kết thúc. Phần mềm đủ lớn và gắn với thế giới thực thì không thể được bảo đảm là đúng tuyệt đối như một chứng minh toán học. Các hệ thống trong đời thực là sản phẩm kỹ nghệ dựa vào bảo đảm hình thức, thiết kế dựa trên kinh nghiệm, kiểm thử thực nghiệm, bí quyết nghề nghiệp, tiêu chí hiệu năng, v.v.
Xu hướng này sẽ lan cả xuống những script nhỏ nhất. Phần lớn phần mềm thậm chí không cần được chứng minh về mặt toán học. Chỉ cần đạt mục đích là đủ. Tôi hoàn toàn trân trọng tay nghề lập trình, nhưng có lẽ đã đến lúc phải buông bỏ phần đó.
Kết cục là tương lai có thể là một trong hai lựa chọn sau
chương trình 100.000 dòng, 50.000 bài test, bảo đảm toàn bộ yêu cầu nhưng không ai dễ đọc nổi, tổng chi phí 50.000 USD (chi phí token API)
con người trực tiếp thiết kế ra 30.000 dòng, 3.000 bài test, abstraction tinh tế, đáp ứng cùng yêu cầu, tổng chi phí 300.000 USD (chi phí nhân sự lập trình viên)
Nếu tôi là người tiêu dùng phần mềm, không quan tâm nội tình chi tiết mà chỉ nhìn giá, thì tôi sẽ chọn ngay phương án rẻ hơn 6 lần
Phải nghĩ đến lúc cần thay đổi vì yêu cầu mới từ bên ngoài. Khi đó, nếu phần mềm này là cốt lõi của doanh nghiệp thì gần như sẽ phải đổi nhà cung cấp ngay lập tức. Vì vậy dù là B2B hay B2C, bảo trì và hỗ trợ luôn rất quan trọng. Phần mềm lúc nào cũng phải thích nghi được với thay đổi
Vì vậy mới có câu đùa kiểu “đoạn code này do tôi và Copilot hiểu; giờ thì chỉ còn Copilot hiểu nữa thôi”
Với nhận định “hệ thống đủ lớn gắn với thế giới thực không thể được chứng minh đúng về mặt toán học”, những người làm formal verification có thể sẽ phản đối rất dữ dội, hoặc cũng có thể trong lòng lại đồng ý
Trong hai kịch bản đó, phải hỏi xem khi cần nâng cấp phiên bản thì bên nào rẻ hơn và nhanh hơn. Hiện tại tôi vẫn nghĩ mô hình có con người lập trình rẻ hơn, nhưng tương lai thì không chắc
Thực ra ngoài đời tôi hầu như chưa từng thấy cả hai lựa chọn đó
Có lẽ giai đoạn tiến hóa cuối cùng sẽ là một ngôn ngữ lập trình hoàn toàn hướng máy, đến mức con người không cần đọc nổi nữa. Tại sao LLM phải chuyển thành ngôn ngữ dễ hiểu cho người như Python hay Swift làm gì? Chỉ cần có đầu ra chạy được ngay là xong, khi đó khái niệm bảo trì cũng trở nên vô nghĩa. Chúng ta chưa ở giai đoạn đó, nhưng có lẽ một ngày nào đó sẽ đi về hướng này
Phần mềm tốt luôn phải ở trong trạng thái được bảo trì. Vì yêu cầu mới luôn xuất hiện không ngừng, nên niềm tin rằng chỉ cần ship tính năng một lần là xong mãi mãi vốn đã là chuyện để đùa rồi. Đó là lý do code, test và tài liệu được viết với ý thức về thay đổi trong tương lai lại quan trọng. Nếu LLM hàng loạt tạo ra black-box code vô nghĩa thì chẳng có gì đáng sợ hơn. Ý tưởng LLM đạt tới trình độ code ngang người và khiến chẳng ai cần bận tâm nữa vẫn thuộc về khoa học viễn tưởng. Coding trên thực tế chỉ là một phần của toàn bộ quá trình tạo ra phần mềm hữu ích thực sự
Thực ra machine code chẳng phải đã ở mức đó rồi sao? LLM được tối ưu cho giao diện con người có thể đọc được, vì thế nó tạo JSON chứ gần như không dùng BSON
Tôi nghi ngờ không biết thứ này rốt cuộc giải quyết được vấn đề gì. Còn những vấn đề nó tạo ra thì quá rõ
Cảm giác như LLM học code dành cho con người, sinh ra code đó, rồi lại chạy code để lấy hành vi mong muốn — giống một kiểu “trò chơi truyền tin”. Cũng khiến tôi nghĩ liệu có cách nào tạo ra hành vi trực tiếp không cần qua code hay không
Nếu nói về ngôn ngữ khó đọc với con người thì Malbolge là ví dụ tiêu biểu. Ngay cả chương trình "Hello World" đầu tiên của nó cũng được tạo ra bằng genetic algorithm
Tôi là tác giả bài gốc. Rất hào hứng được trao đổi với mọi người
Thuật ngữ ‘vibe coding’ đúng là một cách gọi quá hoàn hảo. Giống như cách ‘cloud computing’ bị mở rộng nghĩa khủng khiếp vậy. Ban đầu nó chỉ việc bật các instance EC2 theo nhu cầu rồi xong việc thì bỏ đi, nhưng vì ẩn dụ quá trực quan nên đến cả Gmail giờ cũng bị gọi là ‘cloud’.