- Gần đây, một danh mục dịch vụ mới mang tên "dọn dẹp vibe coding" đã xuất hiện trong ngành CNTT:
Vibe Coding Cleanup as a Service
- Khi thực tế rằng phần lớn mã do AI tạo ra không phù hợp để đưa vào production ngày càng lộ rõ, một thị trường dịch vụ mới chuyên sắp xếp và sửa lại phần mã này đã hình thành
- Kể từ khi Andrej Karpathy định nghĩa "Vibe Coding" vào đầu năm 2025, 92% lập trình viên đã sử dụng công cụ AI, nhưng vấn đề suy giảm chất lượng mã và lỗ hổng bảo mật cũng bộc lộ nghiêm trọng
- Trên thực tế, các lập trình viên đang chuyên xử lý sự thiếu nhất quán, trùng lặp và logic phi lý do AI tạo ra, trong khi các marketplace chuyên biệt và dịch vụ tư vấn cũng đang lan rộng
- AI rất giỏi với các tác vụ nhỏ, nhưng vì không thể xét đến ngữ cảnh toàn hệ thống nên đã tạo ra hàng loạt nợ cấu trúc và vấn đề bảo mật, từ đó mở ra một cơ hội ngành mới gọi là "nền kinh tế dọn dẹp"
- Để doanh nghiệp tận dụng AI coding thành công, có thể giao phần prototype cho AI, nhưng cần đầu tư nhân lực chuyên môn vào quá trình dọn dẹp kiến trúc, bảo mật và kiểm thử
Sự xuất hiện và lan rộng của vibe coding
- Đầu năm 2025, Andrej Karpathy sử dụng thuật ngữ "vibe coding", giúp khái niệm này được định hình
- Cách làm tạo ra toàn bộ hàm thông qua hội thoại ngôn ngữ tự nhiên
- Nhanh chóng lan rộng cùng kỳ vọng có thể tăng năng suất gấp 10 lần
- Theo GitHub, 92% lập trình viên đang dùng công cụ AI coding
- Copilot tạo ra hàng tỷ dòng mã mỗi tháng
- Tuy nhiên, theo phân tích của GitClear, khi dùng mã AI thì tỷ lệ biến động mã cao hơn 41%
- Lượng mã bị hoàn tác hoặc viết lại trong vòng 2 tuần tăng mạnh
- Nghiên cứu của Stanford cho thấy các lập trình viên dùng hỗ trợ AI viết ra nhiều mã kém an toàn hơn, nhưng lại có xu hướng tin rằng mã đó an toàn hơn
- Các công cụ AI gây ra vấn đề khuếch đại nhiều anti-pattern do thiếu kiểm tra dữ liệu đầu vào, dùng dependency lỗi thời và các quyết định thiết kế mơ hồ
Thực tế của nền kinh tế dọn dẹp
- Gần đây, trong ngành CNTT đã âm thầm xuất hiện một lĩnh vực dịch vụ mới mang tên dọn dẹp vibe coding
- Ban đầu nó chỉ giống như một câu đùa kiểu "sửa mớ mã hỗn độn do AI tạo ra", nhưng giờ đang dần trở thành một cơ hội kinh doanh thực sự
- Theo điều tra của 404 Media, một số lập trình viên đang xây dựng sự nghiệp chỉ bằng việc dọn dẹp mã AI
- Công việc là tháo gỡ những thứ được gọi là "AI spaghetti" gồm thiếu nhất quán, trùng lặp và logic kỳ quặc
- Ulam Labs quảng bá Vibe Coding Cleanup là dịch vụ cốt lõi
- Một marketplace chuyên biệt mang tên VibeCodeFixers.com cũng đã xuất hiện
- Chỉ trong vài tuần đã có hơn 300 chuyên gia đăng ký và ghép nối hàng chục dự án
- Khách hàng điển hình: "startup tiêu tốn hàng nghìn đô la OpenAI credit và sở hữu một prototype chỉ hoạt động được một nửa"
Vì sao mã AI thất bại
- Vấn đề không phải AI tự thân viết mã tệ, mà là nó không hiểu ngữ cảnh hệ thống và viết mã được tối ưu cục bộ
- Kết quả là các mẫu thiếu nhất quán, logic trùng lặp và lỗ hổng bảo mật tích tụ, tạo ra nợ kỹ thuật
- Theo nghiên cứu của Georgetown University, ít nhất 48% mã do AI tạo ra chứa lỗ hổng bảo mật
- Rò rỉ thông tin bí mật, dùng thư viện cũ và điều kiện tranh chấp phát sinh khi có tải
- Nghiêm trọng hơn là chính lập trình viên cũng không hiểu đầy đủ mã do AI sinh ra nên không thể phát hiện vấn đề đúng cách
- Thoughtworks gọi đây là "nợ năng lực"
- Hiện tượng đội ngũ mất đi khả năng bảo trì mã và rơi vào phụ thuộc AI
Cơ hội thị trường
- Thị trường dọn dẹp đang tăng trưởng nhanh, nhưng khó nắm được các con số cụ thể
- Gartner dự báo đến năm 2028, 75% lập trình viên doanh nghiệp sẽ dùng công cụ hỗ trợ mã AI
- Nhu cầu dọn dẹp được dự đoán sẽ xuất hiện ở phần lớn dự án
- Ngay cả khi chỉ một phần trong số đó cần dọn dẹp, xét về quy mô đây vẫn là một thị trường mới rất lớn
- Xét về kinh tế, lĩnh vực này cũng hấp dẫn
- Startup dùng AI để tạo MVP nhanh chóng, nhưng sau đó lại phải bỏ ra lượng thời gian và chi phí tương đương để dọn dẹp
- Dù vậy vẫn nhanh hơn phát triển truyền thống
- Các chuyên gia dọn dẹp thu phí 200~400 USD mỗi giờ
- Các dịch vụ được đóng gói như gói giá cố định, audit mã AI và pipeline "Vibe-to-Production" cũng đang lan rộng
- Theo Thoughtworks, trong các dự án sử dụng AI, tỷ lệ refactoring giảm, biến động mã tăng, và một quá trình dọn dẹp quy mô lớn là bắt buộc trước khi thật sự đưa vào production
- Nhiều công ty tư vấn đã bắt đầu tuyển nhân sự chuyên trách vai trò dọn dẹp hoặc remediation cho mã AI
- Kết luận là thị trường dọn dẹp là có thật, đang tăng trưởng nhanh và vẫn còn nhiều vùng chưa được khai phá
Tác động đến kỹ thuật phần mềm
- Một sự thay đổi mang tính nền tảng trong phương pháp phát triển phần mềm đang diễn ra
- Quy trình phát triển đang được tái cấu trúc thành AI triển khai → con người phụ trách kiến trúc, kiểm thử và dọn dẹp, tức một mô hình phân công lao động
- Gergely Orosz ví công cụ AI như "một lập trình viên junior cực kỳ nhiệt huyết", nhấn mạnh rằng nó có thể viết mã rất nhanh nhưng luôn cần được giám sát
- Nhưng AI luôn chỉ dừng ở mức junior và không phát triển thành senior, nên vai trò của chuyên gia dọn dẹp sẽ luôn cần thiết
- Các con đường sự nghiệp mới cũng đang mở ra
- Lập trình viên junior nếu học được kỹ năng dọn dẹp thì có thể đạt mức lương senior chỉ sau 2 năm
- Senior hiểu rõ điểm mạnh và giới hạn của AI có thể tạo ra giá trị rất cao
- Doanh nghiệp thành công không phải là nơi dùng AI nhiều nhất, mà là nơi xây dựng quy trình dọn dẹp có hệ thống
- Tổ chức nào xây dựng được quy trình dọn dẹp vững chắc có thể giành lợi thế cạnh tranh trên thị trường
Quan điểm của Donado Labs
- Dựa trên nhiều kinh nghiệm dọn dẹp vibe code, Donado Labs nhấn mạnh rằng AI hữu ích để tăng tốc, nhưng nhất định cần có quá trình dọn dẹp bởi chuyên gia
- Hãy dùng AI cho prototyping và các công việc lặp lại, còn kiến trúc cốt lõi, bảo mật và kiểm thử nên do con người đảm trách
- Với dịch vụ “Vibe to Production”, công ty chuẩn hóa prototype AI lên cấp độ doanh nghiệp
- Bao gồm kiểm thử, tăng cường bảo mật và tài liệu hóa
- Doanh nghiệp tận dụng AI coding thành công không phải là tổ chức dùng AI nhiều nhất, mà là tổ chức dùng AI một cách thông minh và đầu tư vào dọn dẹp
- Điều cốt lõi là tiến hành dọn dẹp song song trước khi nợ kỹ thuật tích tụ
- Trước tuyên bố rằng AI sẽ thay thế lập trình viên, câu hỏi "ai sẽ dọn dẹp đống mã đó?" mới chính là cơ hội kinh doanh thực sự
4 bình luận
Hồi đầu thời GPT, có những người đi thuê ngoài lập trình bị ép giá kiểu bảo rằng đã làm prototype bằng AI rồi, chỉ cần hoàn thiện thêm một chút thôi.
> Các chuyên gia dọn dẹp tính phí 200~400 USD mỗi giờ
Nhưng thật lòng mà nói, liệu có ai làm kiểu này không?
Ngay cả trước khi vibe coding xuất hiện, tôi cũng từng nghĩ sẽ thật tốt nếu có một dịch vụ dọn dẹp những đoạn mã rối như tơ vò, và rồi đúng là đã có người làm ra nó. Nhưng có lẽ công ty chúng tôi sẽ không áp dụng đâu T_T
Trước đây dịch vụ sửa ngón tay trong tranh AI từng thịnh hành... nhưng giờ đến cả việc đó cũng không còn làm nữa.
Có vẻ dọn dẹp bằng AI rồi cũng sẽ đi theo vết xe đổ đó.
Ý kiến trên Hacker News
Tôi đã nhận các dự án “dọn cấu trúc” cho doanh nghiệp suốt khá lâu rồi
Trước đây, tôi thường nhận mã gần như không chạy nổi từ các agency gia công, nhưng dạo này có vẻ nguồn gốc của vấn đề đã chuyển sang LLM
Rốt cuộc vẫn là những vấn đề cũ lặp đi lặp lại
Chỉ là cách cắt giảm chi phí đã thay đổi mà thôi
Rõ ràng luôn có lý do để chọn đường tắt, nhưng vấn đề thực sự xảy ra khi người ta không nhận thức sâu sắc rằng cách đó có thể phải trả giá
Dù đến từ quản lý, nhân viên hay nhân lực thuê ngoài thì kết quả cũng tương tự nhau
Tôi chưa từng quảng bá riêng dịch vụ cải tổ cấu trúc cho các nền tảng vibe coding, nhưng có lẽ giờ là lúc nên thử
Thị trường phần mềm ở Úc khá nhỏ nên khó nghe được kết quả của những thử nghiệm như vậy
Tôi nghĩ khác biệt giữa vibe coding và thuê ngoài nằm ở lượng mã được tạo ra
Tôi từng dùng vibe coding để làm một script helper đơn giản; nếu tự viết thì chắc chỉ dài khoảng 1/3 hiện tại, và phần lớn edge case có lẽ tôi đã chẳng xử lý đến làm gì (có cả xử lý ngoại lệ thừa thãi lẫn những chỗ thực sự hữu ích)
Việc tôi làm chỉ là quét qua mã và xóa một dòng xóa file tạm vì có thể vô tình xóa luôn thư mục home
Nhưng sau đó khi làm sâu hơn với dữ liệu, tôi nhận ra một số file tạm đã biến mất và vẫn còn thêm hai chỗ khác có mã xóa
Thực ra mã quá nhiều nên con người đọc hết là điều không thực tế
Dù vậy, về tốc độ thì đúng là hiệu quả cực lớn
Từ giờ tôi định chạy test bằng AI trong sandbox thay vì đọc mã quá kỹ
Có một khác biệt lớn, đặc biệt với những công cụ có “chế độ lập kế hoạch” như Claude Code
Dạo này tôi dùng Claude Code khá nhiều ở công ty, và luôn bắt đầu ở chế độ lập kế hoạch, hỏi theo kiểu hội thoại rằng “nên triển khai thế nào”, rồi qua vài lượt trao đổi để gọt chi tiết thành một kế hoạch tốt
Sau đó AI nói chính xác nó sẽ tạo mã gì ra (kèm cả code diff), và chỉ sau khi tôi phê duyệt cuối cùng thì nó mới sinh mã thật
Ngược lại, khi tôi từng review mã do đội outsource làm trước đây thì đúng là một mớ spaghetti code hỗn loạn đến mức không thể hiểu nổi
Tôi nghĩ cũng hay nếu viết vài thuật ngữ liên quan đến vibe-coding trên website, dù chỉ để làm SEO
Tôi cũng từng nghĩ tương tự
Nhưng khi một dự án được vibe-coded và thành ra đầy bug, rồi tôi vào sửa bug và dọn lại cấu trúc, thế là xong thật sao?
Tôi thắc mắc một công ty vốn ngay từ đầu đã không có chuyên môn để thiết lập mọi thứ thì sẽ duy trì nó tiếp bằng cách nào
Tôi cho rằng cả outsource lẫn phát triển dựa trên LLM cuối cùng đều đòi hỏi bộ năng lực tương tự
Tức là vẫn luôn cần nền tảng kỹ thuật vững như làm rõ yêu cầu, giao tiếp, quản lý stakeholder, định nghĩa đặc tả, kiểm thử và tài liệu hóa
Tôi thấy hơi lạ khi khái niệm "vibe coding" của Karpathy lại nổi lên theo cách này
Có lẽ chuyện đó chỉ xảy ra trong nhóm những người không có nhiều kinh nghiệm phát triển thực tế
Nếu tôi nhớ không nhầm, vibe coding là trạng thái kiểu ‘chỉ việc nói chuyện với AI, tin vào dòng chảy và tiến lên mà không thèm kiểm tra kết quả sinh mã’, tức một kiểu flow state mà gần như chẳng ngoái lại nhìn mã
Nếu chất lượng của phần mềm được làm ra nghiêm túc có quan trọng dù chỉ một chút thì đó là một cách làm thực sự khủng khiếp
Có thể dùng cho meme trên Twitter, thử nghiệm tự thỏa mãn, hay mấy script nhỏ dùng ở nhà, nhưng để phát triển sản phẩm tử tế thì quá vô lý
Việc nó thành chủ đề nóng là vì một người nổi tiếng như Karpathy đã đặt cho nó một cái tên hấp dẫn; nếu người khác nói ra thì có lẽ đã chìm nghỉm rồi
Ngay cả trước thời AI, các lập trình viên junior hoặc thiếu kinh nghiệm cũng đã code kiểu này rồi
Họ copy-paste từ đâu đó, chỉ cần thấy chạy là được, đến khi gặp bug kỳ quặc hay core dump thì đổi thứ tự source code để nó biến mất
Kiểu làm việc này ở công ty ít nhất cũng có thể bị cảnh cáo, vào diện cải thiện hiệu suất, hoặc tệ hơn là bị loại ra
Những người không chuyên thường không nhận được kết quả đúng ý khi làm việc với kỹ sư phần mềm
Tôi xem sự xuất hiện của vibe coding là một lời tự phản tỉnh về loại phần mềm mà chúng ta đã giao suốt bấy lâu
Thực tế, chất lượng phần mềm của các startup vibe-coded mà tôi biết đều rất tệ, nhưng nếu nó làm đúng thứ họ muốn thì ở giai đoạn này chất lượng chưa quan trọng
Cho đến khi chất lượng phần mềm gây ra “đòn đánh thực sự” với doanh nghiệp, họ sẽ không muốn mạo hiểm thuê dev để rồi ý tưởng của mình bị biến dạng
Cuối cùng, một thứ tệ hại nhưng dùng được ngay cho đúng mục đích của họ vẫn tốt hơn phần mềm hoàn hảo mà họ lại không muốn
Thích hay không thì vibe coding cũng sẽ không biến mất
Cá nhân tôi cũng không quá đồng tình với khái niệm này, nhưng trong tổ chức tôi vẫn hay nói với đồng nghiệp rằng “cái này tôi làm kiểu vibe coded”
Với chúng tôi, nó chỉ có nghĩa là ‘phần lớn mã được AI tự động tạo ra’
Nhưng tôi tuyệt đối không có ý định đẩy loại mã này lên production mà không qua review
Chỉ kiểu ‘tôi vừa dựng nhanh một app hay ho bằng vibe coding’ thôi, dùng nhẹ nhàng cho mục đích thử nghiệm
Tôi nghĩ ý Karpathy là vibe coding là một “thí nghiệm khả thi” đáng thử để xem nó đi được đến đâu và vui đến mức nào
Ông ấy không có ý khuyến khích công ty thật sự làm sản phẩm chỉ bằng vibe coding
Mọi người đã tự diễn giải ngữ cảnh của cụm từ này quá mức theo ý mình
Thực tế Karpathy cũng đã giải thích ý ông ấy trong một video YouTube
Bài liên quan
YouTube của Karpathy: Software Is Changing (Again)
Tôi nghĩ hiểu lầm càng lớn hơn vì mọi người muốn tin rằng việc khó giờ đã trở nên dễ dàng
Tôi vẫn nghĩ bản thân tweet ban đầu cũng chỉ là một trò đùa hay cách diễn đạt sự tự do của “YOLO coding”, chứ không phải đề xuất nó như một quy trình làm việc thật sự
Chỉ là một cách vui vẻ để viết lại cảm giác giải phóng mà ông ấy có lúc đó thôi
Giờ vibe coding gần như đang bị dùng như một từ để hạ thấp hoặc mỉa mai mọi hình thức hỗ trợ code bằng AI
Bất kỳ công cụ nào cũng có thể dùng tốt hoặc dùng dở, nhưng gần đây meme kiểu “vibe coding ngu đến mức nào” lại rất dễ kiếm phiếu trên mạng
Đến mức thấy mệt mỏi rồi
Cốt lõi bài viết là luận điểm rằng "nếu startup nhờ vibe coding mà rút ngắn vài tuần để làm MVP, rồi sau này dù có phải tốn thời gian và chi phí tương tự để dọn dẹp lại thì vẫn nhanh hơn phát triển truyền thống"
Tôi thật sự muốn biết có đúng vậy không
Theo những gì tôi thấy, nếu dev tự làm mà có dùng AI hỗ trợ thì chênh lệch tốc độ có thể không lớn
Đặc biệt nếu biết rằng MVP hay prototype rồi sẽ đi thẳng vào production, thì thiết kế kiến trúc cho đúng ngay từ đầu có vẻ tốt hơn về dài hạn
Nhưng đa số phía sản phẩm và ban điều hành lại xem thời gian đó là lãng phí
Lợi thế thực sự của vibe coding là đội sản phẩm có thể tự làm ra thứ họ muốn ngay, không cần phải giải thích cho dev
Có lẽ thị trường sẽ có chỗ cho các công cụ sản phẩm dựa trên vibe coding, tập trung vào việc làm rõ đặc tả và prototype hơn là tạo ra mã
Những công cụ như vậy có thể mang lại đặc tả tốt hơn cho dev, đồng thời cho phía kinh doanh thêm đóng góp và quyền chủ động
Ở startup, time-to-market quan trọng đến mức dù tổng thời gian và chi phí có cao hơn thì việc chấp nhận nợ kỹ thuật để ra mắt nhanh hơn vẫn là một quyết định hoàn toàn hợp lý
Đó cũng là lý do người ta tích nợ kỹ thuật
Twitter ban đầu cũng khởi đầu như một web app Ruby on Rails, rồi cứ mỗi lần Justin Bieber tweet là server lại sập và hiện fail-whale
Nhưng khi phát triển, họ rốt cuộc đã thuê chuyên gia để làm lại bài bản trên một cấu trúc vững vàng và dễ mở rộng hơn
Có lẽ dùng cho prototype thì được hơn là gọi là MVP,
nhưng nếu tổ chức hay cá nhân không có kỷ luật là không đẩy prototype lên prod, thì tôi nghĩ nên tránh vibe coding
Ai cũng biết việc thuyết phục lãnh đạo rằng “đoạn mã trông ngầu mà mọi người đang dùng thực ra bên trong là thảm họa và phải viết lại toàn bộ” khó đến mức nào
Trong những trường hợp như vậy, công cụ no-code còn an toàn hơn nhiều
Thực tế là phần lớn MVP hay prototype sớm muộn cũng bị đưa lên production
Tôi nhớ có người từng nói rằng nếu "mã MVP không bẩn đến mức phát ốm thì có lẽ bạn đã tốn quá nhiều thời gian cho chất lượng mã"
Rốt cuộc những đoạn mã tạm bợ lại trở thành xương sống của công ty
Một dịch vụ chỉ chuyên dọn loại cấu trúc này có lẽ có thể gọi là "C-Suite cleanup as a Service", nhưng quảng cáo vậy chắc chẳng ai thuê
Ngay khi đọc bài, tôi đã cảm nhận rất rõ đây là văn phong của Claude dù không cần em-dash
Chắc chắn OP đã đưa suy nghĩ và tư liệu của mình vào prompt, nhưng những cụm từ và sắc thái câu chữ rất đặc trưng, giống hệt thứ LLM thường tạo ra, nên đọc có cảm giác khá gượng
Tôi tự hỏi liệu kiểu viết này rồi sẽ trở nên lỗi thời như một thứ “văn phong LLM” hay không
Có vẻ giờ sẽ đến thời của dịch vụ vibe-writing cleanup as a service
Tôi đã dùng em-dash rất nhiều từ lâu rồi, mà giờ có vẻ sắp đến lúc phải cố tình giảm bớt nó đi
Microsoft Word tự động đổi dấu gạch nối thành em-dash
Tôi thấy vibe coding giống như tự sửa ống nước ở nhà
Bạn tự làm, rồi khi nước phụt tung trong phòng tắm thì cuối cùng vẫn phải gọi thợ cấp cứu với giá đắt
Qua quá trình đó, lần sau bạn sẽ học được thêm chút gì đó
Có thể so sánh như vậy, nhưng thợ ống nước chuyên nghiệp cũng dùng rất tốt các công cụ hỗ trợ DIY
Khác biệt là người chuyên nghiệp biết rõ nên dùng đến đâu và vào lúc nào
Tôi còn thấy nghiêm trọng hơn
Thợ ống nước còn nhìn thấy mình đang làm gì, còn vibe code thì có ngày tự nhiên thứ gì đó ngừng hoạt động mà bạn chẳng biết tại sao
Trên YouTube có rất nhiều người tự sửa ống nước ở nhà mà làm còn kỹ hơn cả thợ chuyên nghiệp
Có lẽ còn tùy việc người làm vibe coding có thực sự học được gì từ trải nghiệm đó hay không
Chắc phải chờ thời gian trả lời
Tôi thấy phép so sánh này thật sự phù hợp
Giống như một môi giới bất động sản đang bị áp lực phải bán nhà nên hấp tấp tự làm việc của thợ ống nước, nhà sáng lập startup cũng vội vàng demo thứ gì đó để kéo sự chú ý của nhà đầu tư và khách hàng, rồi sau đó mới gọi chuyên gia thật sự đến dọn dẹp
Nếu may mắn, họ còn có thể tránh được tai nạn lớn trước khi chuyện đó xảy ra
Tôi khá bất ngờ khi biết cụm Janitor Engineer đã có sẵn trong ngành rồi
Ngoài ra, các liên kết trong bài sau "Why AI code fails at scale" đều bị hỏng, nên càng thấy lạ vì bài đó cũng mới đăng không lâu
Chỉ nói thêm vậy thôi, mong không ai thấy khó chịu
Từ khi vibe coding thành mốt, tôi cũng nửa đùa nửa thật nuôi một kế hoạch nghỉ hưu là làm tư vấn “all-organic-code”, đi gỡ tung rồi dọn dẹp đống mã do AI sinh ra
Thứ thực sự hiếm lại là dự án mới tinh (greenfield)
vibe coding đang nhanh chóng làm suy yếu tài liệu hóa và sự rõ ràng trong kiến trúc
Các công ty chỉ xem lượng token mã được tạo ra và tốc độ làm prototype là chỉ số quan trọng, còn phớt lờ chi phí ẩn của bảo trì và dọn dẹp
Giờ kỹ năng thật sự không còn là tạo ra mà là dọn dẹp
Năng lực thật sự là biết hướng dẫn tốt ngay từ đầu để cho ra phần mềm đúng đắn
Có người nghĩ Claude code kiểu này là “công nghệ mới nhất”, nhưng để làm cho ra hồn thì phải tham gia sâu hơn nhiều
Thực ra cũng không khác kỹ nghệ phần mềm truyền thống là mấy
Mấu chốt là tối thiểu hóa chi phí và đáp ứng yêu cầu
Nếu bạn không yêu cầu rõ khả năng bảo trì, thì kết quả đúng như “ý định ban đầu” sẽ xuất hiện
Tôi không hiểu vì sao lại là cái chết của tài liệu hóa
Bạn hoàn toàn có thể viết tài liệu trước, rồi phát triển bằng cách kiểm tra xem mã có khớp với tài liệu đó hay không
Hoặc để mã tự sinh tài liệu, rồi tự mình xem xét liệu nó có phù hợp không
Công ty chúng tôi đã làm dịch vụ khôi phục khẩn cấp cho các hệ thống quan trọng của khách hàng suốt hàng chục năm nay (kiểu sự cố gây thiệt hại tài chính nghiêm trọng mà họ không thể tự xử lý)
Trong vài năm gần đây, số trường hợp như vậy đang tăng khá nhanh
vibe code giống legacy code ở nhiều khía cạnh
Người ta thiếu tự tin với nó nên ngại sửa, và cả chất lượng bên trong lẫn bên ngoài đều thấp
Nhưng cũng có khác biệt
Lượng mã ít hơn so với tuổi đời của nó, áp lực lịch trình cao hơn, và kỳ vọng bị thổi phồng
Cách tiết kiệm chi phí nhất là đẩy lỗi về càng sớm càng tốt, không phải lúc runtime mà là ở giai đoạn thiết kế hay trước thời điểm compile
Vấn đề là AI khiến mọi người chạy đến runtime quá nhanh
Nhân tiện, bài “Vibe code is legacy code (val.town)” đáng để xem
Bài đăng HN liên quan
Legacy code không phải lúc nào cũng xấu
Thường nó phức tạp hoặc thiếu tài liệu, và tích lũy vô số bản vá vận hành lớn nhỏ theo thời gian
Nhiều vấn đề vận hành thực tế (như yêu cầu mới) đã được phản ánh nên nó vẫn chạy ổn trong dịch vụ thật
Vấn đề là khi những người quen codebase đó biến mất, thậm chí không còn ai biết ngôn ngữ hay công cụ đã dùng lúc ấy nữa
Tôi tò mò liệu vibe coding có áp dụng được với ngôn ngữ strongly typed hay không
Tôi đồng ý rằng có thể xem mã tạo kiểu vibe như legacy code
Nhưng tôi thắc mắc liệu mọi người có thực sự ngại sửa vibe code đến mức như vậy không
Tôi bắt đầu nghĩ có lẽ việc sinh mã bằng LLM rồi cũng có thể biến mất
Bài viết luôn giả định rằng LLM sẽ tạo mã và luôn cần cleanup sau đó, nhưng nếu chi phí LLM cộng chi phí cleanup lúc nào cũng đắt hơn lương dev, thì rốt cuộc chẳng phải ta sẽ quay lại để con người tự viết hay sao?
Việc để LLM tạo mã rồi kiểm tra trước khi dùng không giống vibe coding
vibe coding là dùng luôn mã hoàn chỉnh mà không kiểm tra
Tôi nghĩ cả hai cách đều sẽ không biến mất
Ngày nay, AI vibe coding đang dần bớt là trào lưu
Vì sắp tới sẽ có AI còn giỏi hơn nữa xuất hiện
Nếu chỉ vibe coding cả ngày thì cuối cùng có thể thành một mô hình chi phí không kham nổi
Có thể tất cả sự phấn khích trước mức độ hỗ trợ đó chỉ là ảo giác, rồi sau này người ta sẽ tỉnh ra và chịu cú sốc thực tế
Xu hướng biến mọi ví dụ lập trình thành công cụ hỗ trợ dự đoán hoàn tất và tự động sinh ra sẽ tuyệt đối không biến mất
Giống như ngày xưa người ta còn code mà không có syntax highlighting, nhưng giờ chẳng ai cố tình làm thế nữa
Việc gõ lại DFS lần thứ 80 không khiến lòng tự trọng của tôi với tư cách lập trình viên tăng thêm chút nào