Vibe coding không thể là cái cớ cho công việc chất lượng thấp
(addyo.substack.com)- Vibe coding dựa trên AI mang tính đột phá, nhưng đây cũng là lời cảnh báo rằng tốc độ không đi cùng chất lượng là điều nguy hiểm
"Di chuyển nhanh hơn và phá vỡ nhiều thứ hơn"
"vibe coding, cách để hai kỹ sư tạo ra khoản nợ kỹ thuật tương đương 50 người"
- Cách diễn đạt biến tấu từ khẩu hiệu cũ của Thung lũng Silicon này gần đây đang được nhắc đến trong cộng đồng kỹ thuật như một khái niệm mang tên “vibe coding”
- Đúng là phát triển dựa trên AI đang cách mạng hóa cách tạo ra phần mềm, nhưng điều đó không phải giấy phép để vứt bỏ tính nghiêm ngặt, quy trình review và tay nghề kỹ sư
- "vibe coding" không thể là cái cớ để biện minh cho công việc chất lượng thấp
- Công bằng mà nói về mặt ưu điểm, lập trình có AI hỗ trợ có thể là một game changer
- Nó hạ thấp rào cản gia nhập cho lập trình viên mới hoặc người không chuyên, giúp họ có thể tạo ra phần mềm hoạt động chỉ bằng cách mô tả nhu cầu
- Điều này giải phóng sức sáng tạo và cho phép nhiều người hơn tự giải quyết vấn đề của mình bằng phần mềm tùy biến
- Xu hướng này được xem là một phần của trào lưu unbundling phần mềm cá nhân (dùng các công cụ nhỏ chạy bằng AI thay vì ứng dụng đóng gói sẵn)
- Các kỹ sư giàu kinh nghiệm cũng có thể hưởng lợi
- Nhưng như bất kỳ kỹ sư dày dạn kinh nghiệm nào cũng sẽ nói, tốc độ không có ý nghĩa gì nếu đến cuối cùng bánh xe rơi ra
- Và chính tại đây các vết nứt bắt đầu lộ ra — khoảng cách giữa vibe và thực tế, tức sự khác biệt giữa cảm giác hưng phấn và hiện thực của việc xây dựng phần mềm có thể bảo trì và đủ độ vững chắc
Sự thật khó chịu: chất lượng không tự động đi kèm
- Mức độ hype rất lớn, nhưng sự hoài nghi của các lập trình viên kỳ cựu với vibe coding cũng không hề nhỏ
- Phê bình cốt lõi là thế này: AI tạo code nhanh không có nghĩa là code đó tốt
- Trên thực tế, tin tưởng và dùng nguyên xi code do AI tạo ra có thể khá nguy hiểm
- Câu đùa rằng “hai kỹ sư tạo ra khoản nợ kỹ thuật bằng 50 người” không hoàn toàn chỉ là đùa
- Code AI không được kiểm tra có thể khuếch đại nợ kỹ thuật ở quy mô lớn
→ Khoản nợ này khiến code dễ tổn thương, khó bảo trì và về lâu dài sẽ tạo ra chi phí rất lớn
- Các dự án làm bằng vibe coding thường trông bề ngoài rất ổn ("Chạy tốt đấy, deploy thôi!")
- Nhưng trên thực tế chúng thường che giấu các rủi ro như:
- Không có xử lý lỗi
- Hiệu năng kém
- Cách làm bảo mật thiếu ổn định
- Cấu trúc logic yếu và dễ vỡ
- Những dự án như vậy giống công trình xây trên cát,
- và theo cách tôi gọi thì đó là “house of cards code” —
trông như đã hoàn thiện nhưng sẽ dễ dàng sụp đổ trước áp lực thực tế - Nếu bạn từng thấy feature lớn đầu tiên của một lập trình viên junior gần như hoạt động nhưng sập ngay chỉ vì một input không lường trước, thì bạn sẽ hiểu cảm giác đó
- AI có thể tạo ra rất nhiều code rất nhanh, nhưng số lượng không đồng nghĩa với chất lượng
- "AI giống như một lập trình viên junior cực kỳ nhiệt tình vừa gia nhập đội"
- → Khái niệm này được minh họa rất rõ qua hình minh họa của Forrest Brazeal
- Rủi ro này không chỉ là giả thuyết, ở góc độ bảo trì thực tế đây là một vấn đề hoàn toàn có thật
- Nếu module do AI tạo ra quá phức tạp hoặc khó hiểu, ai sẽ là người chịu trách nhiệm bảo trì?
- Ngay cả khi chính lập trình viên viết ban đầu cũng không hiểu hoàn toàn phần code AI tạo ra,
thì đoạn code đó có thể trở thành ác mộng cho việc sửa đổi hoặc mở rộng về sau
- Bảo mật là một vấn đề lớn khác
- AI có thể tạo ra đoạn code bề ngoài hoạt động tốt, nhưng bên trong lại ẩn chứa các lỗ hổng nghiêm trọng như SQL injection
- Hoặc cũng có thể phần xử lý lỗi được làm rất sơ sài
- Nếu những vấn đề như vậy được đưa vào production mà không qua review kỹ lưỡng, chúng có thể dẫn đến sự cố thực tế
- Một vấn đề nữa là overfitting theo prompt
→ AI làm đúng chính xác điều bạn yêu cầu, nhưng điều đó có thể khác với thứ thực sự cần thiết - Lập trình viên con người trong quá trình triển khai thường phát hiện lỗi thiết kế hoặc hiểu sai yêu cầu và sẽ sửa chúng
- Ngược lại, AI hoàn toàn không nhận ra những hiểu lầm như vậy, và nếu con người không phát hiện rồi sửa, vấn đề sẽ bị bỏ mặc
- Dĩ nhiên, tất cả điều này không có nghĩa là AI tuyệt đối không thể viết code tốt —
- AI đôi khi vẫn tạo ra code rất tốt
- Nhưng để đánh giá liệu đoạn code đó có thực sự dùng được hay không, ba yếu tố sau là bắt buộc:
- ngữ cảnh (context)
- sự xem xét phản biện (scrutiny)
- kinh nghiệm và chuyên môn (expertise)
- Tính đến năm 2025, AI mà chúng ta đang dùng giống một trợ lý đầy nhiệt huyết nhưng thiếu kinh nghiệm
- Cũng như bạn không giao toàn bộ thiết kế hệ thống cho một lập trình viên mới năm đầu mà không giám sát,
code do AI tạo ra cũng không nên được chấp nhận mà không qua review - Kỳ vọng về “AI magic” giờ đây phải được điều chỉnh cho hài hòa với thực tế của kỹ nghệ phần mềm
- Vậy phải cân bằng thế nào?
- Điều quan trọng là không cần phải bác bỏ hoàn toàn vibe coding
- vibe coding đôi khi có thể rất hữu ích
- Nhưng điều quan trọng là tích hợp nó một cách bài bản — tức xem AI như một công cụ có giới hạn rõ ràng
- Điều đó cũng có nghĩa là con người phải ở trong vòng lặp, và chúng ta phải dùng AI theo cách vẫn giữ được tiêu chuẩn chất lượng và nguyên tắc kỹ thuật
AI không phải người thay thế mà là thực tập sinh (con người phải ở trong vòng lặp)
- Để dùng vibe coding hiệu quả, cần một sự thay đổi tư duy: hãy đối xử với AI như ‘một thực tập sinh lập trình trong đội, rất nhanh nhưng còn non tay’
- Tức là bạn — kỹ sư senior hoặc team lead — vẫn là người chịu trách nhiệm cuối cùng cho kết quả đầu ra
- AI có thể nhanh chóng tạo bản nháp, nhưng bạn vẫn phải review bằng con mắt phản biện, chỉnh sửa và xác nhận rằng nó đáp ứng tiêu chuẩn chất lượng
- Các lập trình viên giàu kinh nghiệm thường làm việc này một cách trực giác
- Khi AI đề xuất code, họ không bấm “Accept” rồi đi tiếp ngay mà sẽ xử lý như sau:
- Đọc và hiểu trước đoạn code AI viết — đối xử với nó như code do một lập trình viên junior viết
- Nếu code là một khối đơn hoặc lộn xộn thì mô-đun hóa và refactor — tách nó thành các đơn vị nhỏ hơn, rõ ràng hơn
- Tự thêm các xử lý ngoại lệ hoặc edge case còn thiếu — như kiểm tra
null, xác thực input, những thứ AI hay bỏ sót - Siết chặt kiểu dữ liệu lỏng lẻo hoặc các lớp trừu tượng chưa hoàn chỉnh — chuyển các giả định ngầm thành các hợp đồng tường minh
- Đánh giá xem kiến trúc hoặc cách tiếp cận mà AI chọn có kém hiệu quả không — ví dụ: xử lý brute-force, đưa vào global state
- Viết test hoặc thực hiện kiểm thử thủ công — nếu AI đã sinh unit test thì cũng phải review xem các test đó có thực sự hợp lệ hay không
-
Thông qua toàn bộ quá trình này, bạn sẽ bơm sự từng trải kỹ thuật (wisdom) vào đoạn code do AI tạo ra
-
Sự kết hợp này có thể rất mạnh — AI mang lại tốc độ, còn con người đảm bảo độ tin cậy
-
Trên thực tế, theo nghiên cứu và kinh nghiệm công việc, lập trình viên senior thường thu được nhiều giá trị từ công cụ AI coding hơn junior
-
Lý do là vì senior có kiến thức và kinh nghiệm để dẫn dắt đầu ra của AI đúng hướng, cũng như sửa lỗi của nó
-
Ngược lại, junior có nguy cơ tin AI như một thẩm quyền tuyệt đối
- Vì vậy có một quy tắc quan trọng được đặt ra:
→ Code do AI viết phải luôn được review trước khi đưa vào - Giống như review PR của một lập trình viên mới, bạn phải đọc từng dòng và chỉ merge sau khi đã hiểu hoàn toàn
- Đừng mặc định AI thông minh hơn — đa số trường hợp là không phải vậy
- Với những phần bạn không hiểu:
- Hãy chỉnh lại prompt để yêu cầu rõ ràng hơn, hoặc
- Tốt hơn là tự viết lại đoạn code đó
- Đầu ra của AI chỉ là ‘bản nháp’ và bắt buộc phải qua review
- Trong môi trường phát triển theo nhóm:
- Nếu ai đó dùng AI để tạo code,
- thì người đó phải có khả năng tự giải thích và bảo vệ đoạn code ấy trong buổi review
- “Vì nó chạy mà” là không đủ — chỉ khi con người hiểu và có thể bảo trì thì đó mới là code đúng nghĩa
- Một thực hành tốt khác: con người làm thiết kế, AI làm triển khai
- Nghĩa là, hãy dùng AI để triển khai nhanh các công việc đã được định nghĩa rõ như CRUD API
- Ngược lại, những yêu cầu như “hãy thiết kế một kiến trúc microservices có khả năng mở rộng” thì con người phải làm
- Thiết kế cấp cao và các quyết định cốt lõi phải tiếp tục thuộc về con người
- Tóm lại: giao việc đơn giản, lặp đi lặp lại (grunt work) cho AI, và giao việc cần tư duy, phán đoán (brain work) cho con người
- Giao tiếp và tài liệu hóa cũng trở nên cực kỳ quan trọng
- Nếu đã yêu cầu AI xử lý một thuật toán phức tạp hoặc một thư viện còn xa lạ,
- thì nhất định phải ghi lại tài liệu về lý do và chủ đích của lựa chọn đó
- người bảo trì trong tương lai, hoặc chính bạn trong tương lai, phải có thể hiểu vì sao đoạn mã đó được làm theo cách ấy
- Một số đội nhóm còn ghi lại chính prompt đã dùng khi tạo mã quan trọng bằng AI
→ cách này hữu ích vì khi debug có thể tham chiếu lại “lịch sử hội thoại” với AI
- Kết luận là, sự can thiệp của con người không phải tùy chọn mà là điều bắt buộc
- Dùng mã AI mà không có con người tham gia cũng giống như gieo xúc xắc với chất lượng phần mềm
- Chúng ta vẫn chưa sống trong thời đại mà AI có thể thay thế năng lực hiểu biết tổng thể của một kỹ sư senior
- vibe coding phải là một mối quan hệ hợp tác —
→ AI có thể tăng tốc, còn con người là người cài dây an toàn cho tốc độ đó
Các quy tắc thực chiến để vibe coding chất lượng cao
- Giờ hãy tóm lược các thảo luận ở trên thành những quy tắc và best practice có thể áp dụng ngay
- Có thể xem đây là cuốn sổ tay mới của thời đại “di chuyển nhanh, nhưng đừng phá hỏng mọi thứ”
- Đây là những quy tắc đóng vai trò lan can an toàn để vẫn giữ được chất lượng khi vibe coding
- Rule 1: Always Review AI-Generated Code / Luôn review mã do AI tạo ra
- Không có ngoại lệ. Mọi đoạn mã AI viết ra đều phải được review như mã do một lập trình viên junior viết
- Dù là tự review hay đồng nghiệp review, đều phải thực hiện
- Với Copilot, ChatGPT, Cursor hay bất kỳ AI nào cũng vậy
- Nếu không có thời gian review, thì cũng không có thời gian để dùng đoạn mã đó
- Merge mã AI mà không review cũng đồng nghĩa với việc ôm nguyên rủi ro vào người
- Rule 2: Establish Coding Standards and Follow Them / Thiết lập tiêu chuẩn mã hóa và tuân thủ chúng
- AI phản chiếu nguyên trạng phong cách mã mà nó đã học, nên nếu không có tiêu chuẩn thống nhất trong nhóm thì chất lượng sẽ rất chênh lệch
- Cần định nghĩa rõ style guide, pattern kiến trúc và các quy tắc coding của nhóm
- Ví dụ: “mọi hàm đều phải có JSDoc và unit test” → mã do AI tạo cũng áp dụng y như vậy
- Với các dự án dùng cấu trúc phân tầng hoặc layered architecture,
cần refactor để AI không nhét các lời gọi DB vào trong mã UI - Nên áp dụng các rule lint hoặc static analysis để bắt những lỗi AI thường gặp (ví dụ: hàm quá phức tạp, dùng API deprecated, v.v.)
- Rule 3: Use AI for Acceleration, Not Autopilot / AI là bộ tăng tốc, không phải chế độ lái tự động
- vibe coding nên được dùng để xử lý nhanh những công việc mà bạn đã hiểu rõ
- Ví dụ sử dụng tốt:
- tạo boilerplate
- scaffold component
- chuyển đổi ngôn ngữ
- viết khung cho các thuật toán đơn giản
- Ví dụ sử dụng rủi ro:
- bắt AI thiết kế cả một module chỉ từ mô tả mơ hồ
- thử tạo mã cho một domain mà bạn không rành
- Nếu đoạn mã đó sẽ tồn tại lâu dài, thì nhất định phải chuyển từ vibe mode sang engineering mode
- Rule 4: Test, Test, Test / Nhất định phải kiểm thử
- AI tạo ra mã không có nghĩa là nó tự động trở thành đáp án đúng
- Bắt buộc phải viết test cho mọi luồng chính
- Nếu AI cũng tạo luôn test, thì vẫn cần xem lại liệu test đó có thực sự hợp lệ hay không
- Đặc biệt với các tính năng UI hoặc phần có nhiều đầu vào từ người dùng, bắt buộc phải tự tay bấm thử và test các đầu vào bất thường
- Ứng dụng được vibe-code thường chạy tốt ở happy path nhưng dễ yếu trước các đầu vào ngoại lệ
- Rule 5: Iterate and Refine / Lặp lại và tinh chỉnh
- Nếu kết quả đầu tiên AI đưa ra chưa đạt, đừng bỏ qua mà hãy thử lại hoặc refactor
- vibe coding là một quy trình lặp dựa trên đối thoại
- Ví dụ:
- “hãy làm đoạn mã này gọn hơn”
- “hãy tách nó thành các hàm nhỏ hơn”, v.v. để điều chỉnh lại prompt
- Hoặc tự refactor → xác định điểm cần sửa → prompt lại → lặp tiếp
- Chiến lược làm việc theo chu kỳ với AI rất hiệu quả
- Rule 6: Know When to Say No / Biết lúc nào nên từ chối
- vibe coding không phải lúc nào cũng là lựa chọn tốt nhất
- Trong các tình huống cần thiết kế quan trọng hoặc đòi hỏi bảo mật, tự viết vẫn tốt hơn
- Ví dụ:
- module liên quan đến bảo mật nên tự thiết kế, chỉ dùng AI cho một phần
- nếu AI trả lời quá phức tạp cho một vấn đề đơn giản, tự viết còn nhanh hơn
- Khi AI không giải quyết đúng vấn đề, đừng cố chấp mà hãy chuyển sang chế độ thủ công
- “Vì AI đã làm rồi” không phải cái cớ để bạn không cần hiểu mã của chính mình
- Rule 7: Document and Share Knowledge / Tài liệu hóa và chia sẻ tri thức
- Mã do AI tạo ra cũng phải được tài liệu hóa ngang với mã tự viết (đôi khi còn nhiều hơn)
- Nếu có quyết định không trực quan hoặc cách triển khai khác thường, cần để lại chú thích
- Phải chia sẻ rõ với đồng đội phần nào là mã do AI tạo
- Một số nhóm còn lưu nguyên prompt đã dùng cho các đoạn mã AI quan trọng → rất hữu ích khi debug
- Bằng cách tuân theo các quy tắc trên, đội nhóm có thể tận dụng tối đa năng suất của vibe coding đồng thời giảm thiểu rủi ro
- Cốt lõi là AI không thay thế con người mà bổ trợ cho con người
- AI xử lý nhanh việc lặp lại, còn con người phụ trách tư duy phản biện và sáng tạo
- Chúng ta đang sống trong thời đại cùng tạo mã (co-create) với AI
Khi nào vibe coding phát huy hiệu quả vs khi nào nó sụp đổ
- Điều quan trọng là phải hiểu rõ vibe coding tỏa sáng ở đâu và không hiệu quả ở đâu
- Không phải mọi dự án hay mọi công việc đều phù hợp như nhau với workflow dựa trên AI
- Dưới đây là phần phân loại cách sử dụng được tổng hợp từ kinh nghiệm và các trường hợp thực tế trong ngành
- 👍 Trường hợp hoạt động tốt (Great Use Cases)
- Rapid prototyping (tạo prototype nhanh)
→ đây là điểm mạnh nhất của vibe coding. Khi có ý tưởng cho một ứng dụng nhỏ hoặc một tính năng
→ có thể dùng AI assistant để nhanh chóng tạo proof of concept hoặc prototype
→ code hơi lộn xộn một chút cũng không sao — điều cốt lõi là kiểm chứng ý tưởng
→ đã có nhiều trường hợp dùng riêng AI để làm app trong các dự án cuối tuần rồi kiểm thử ý tưởng - One-off scripts / Internal tools (script dùng một lần, công cụ nội bộ)
→ như phân tích file log, tự động hóa công việc cá nhân, dashboard nội bộ
→ trong môi trường mà thất bại không gây rủi ro lớn, vibe coding rất hiệu quả để tiết kiệm thời gian
→ trong những tình huống không cần chất lượng cấp production, có thể nhanh chóng tạo ra thứ “chạy được ngay” - Learning and exploration (học tập và thử nghiệm)
→ khi học một ngôn ngữ mới hoặc API mới, có thể nhờ AI tạo ví dụ
→ dù không phải code hoàn hảo, vẫn hoàn toàn đủ để làm tài liệu học tập
→ giống như có một TA (trợ giảng) ảo trình bày nhiều cách thử khác nhau, rồi con người tinh chỉnh lại - Boilerplate-heavy tasks (các tác vụ nhiều boilerplate)
→ ví dụ: tạo 10 data class tương tự nhau, triển khai CRUD
→ nếu cấu trúc đã rõ ràng, AI có thể bám rất chính xác vào các mẫu lặp đi lặp lại
→ có thể xử lý nhanh các việc máy móc để con người tập trung vào phần quan trọng
- Rapid prototyping (tạo prototype nhanh)
- 👎 Trường hợp dễ phát sinh vấn đề (Not-So-Great Use Cases)
- Enterprise software / Complex systems (phần mềm cấp doanh nghiệp, hệ thống phức tạp)
→ những hệ thống có logic nghiệp vụ phức tạp, tính đồng thời, bảo mật và yêu cầu tuân thủ
→ AI sẽ không biết các điều kiện đó nếu không được nêu rõ, mà kể cả có biết thì cũng có thể phản ánh chưa đầy đủ
→ ví dụ: hệ thống thanh toán fintech, phần mềm điều khiển hàng không vũ trụ thì tuyệt đối không nên giao riêng cho AI
→ trong môi trường như vậy, AI chỉ có thể hỗ trợ một phần; chất lượng cuối cùng vẫn bắt buộc phải có QA và chuyên môn của con người - Long-term maintainability (khả năng bảo trì dài hạn)
→ với codebase sẽ tồn tại nhiều năm, cấu trúc ngay từ đầu là rất quan trọng
→ code được vá víu bằng AI thường thiếu tính nhất quán, tạo gánh nặng lớn cho bảo trì về sau
→ thà đầu tư thời gian từ đầu để xây dựng framework và thiết kế rõ ràng còn hơn
→ nhiều người dùng đầu tiên đã chia sẻ trải nghiệm rằng thời gian tiết kiệm được nhờ vibe coding
rồi sau này lại phải trả bằng công sức refactor và dọn dẹp - Critical algorithms / Optimizations (thuật toán hiệu năng cao hoặc công việc tối ưu hóa)
→ ví dụ: quản lý bộ nhớ tùy biến, thuật toán sắp xếp siêu nhanh
→ AI có thể ổn với đầu vào nhỏ, nhưng thường thiếu cân nhắc về khả năng mở rộng
→ có thể chậm đi hoặc hoạt động sai mà không có cảnh báo
→ những phần như vậy vẫn cần sự sáng tạo và mức độ hiểu biết sâu của con người - Explainability and clarity (tính rõ ràng và khả năng giải thích)
→ trong những tình huống mà code phải được đọc một cách rõ ràng bởi các lập trình viên khác hoặc kiểm toán viên
→ nếu AI trừu tượng hóa quá mức hoặc tiếp cận theo cách phức tạp, độ dễ đọc và khả năng bảo trì sẽ suy giảm nghiêm trọng
→ AI hiện tại không phải lúc nào cũng hướng tới “code ngắn gọn, súc tích” → đôi khi quá verbose hoặc trừu tượng hóa không cần thiết
→ trong những trường hợp này, cần con người refactor và viết code rõ ràng hơn
- Enterprise software / Complex systems (phần mềm cấp doanh nghiệp, hệ thống phức tạp)
- Tóm lại, vibe coding là một công cụ tăng tốc mạnh mẽ nhưng không phải lời giải vạn năng
- Nó rất hiệu quả với những công việc cần tốc độ và chấp nhận được việc sửa đi sửa lại kết quả vài lần
- Ngược lại, giao phần mềm mission-critical cho AI làm một lần cho xong là một thử nghiệm đầy rủi ro
- Nói ví von thì: giống như giao xe buýt trường học cho tay đua xe chuyên nghiệp lái — là công cụ tốt nhưng dùng sai mục đích
- Không biết đến một ngày nào đó AI có trở thành công cụ nền tảng cho toàn bộ hoạt động phát triển hay không, nhưng hôm nay thì chưa
- Việc chúng ta cần làm hôm nay là dùng AI cho đúng bài toán, theo đúng cách, với đúng trách nhiệm
Kết luận: hãy vibe một cách thận trọng – tận hưởng tốc độ nhưng đừng đánh mất tay nghề
- vibe coding và phát triển phần mềm dựa trên AI là một bước nhảy vọt lớn trong sự tiến hóa của công cụ
- xu hướng này không phải mốt nhất thời mà là thực tế đã hình thành, và về sau sẽ còn tinh vi hơn nữa
- nếu là một đội ngũ kỹ thuật nhìn về tương lai thì không nên phớt lờ điều này
- cũng như các công cụ tự động hóa trước đây hay các framework cao cấp từng vượt lên cách phát triển truyền thống,
những đội ngũ biết tận dụng AI tốt có khả năng sẽ vượt qua những đội ngũ không làm được điều đó - thông điệp của bài viết này không phải là hãy từ chối vibe coding —
→ mà là hãy tiếp cận nó với đôi mắt mở, đồng thời vẫn giữ vững những nguyên tắc nền tảng của kỹ thuật phần mềm
- Bài học quan trọng nhất: tốc độ là vô nghĩa nếu không có chất lượng
- Triển khai thật nhanh một đống code đầy bug và không thể bảo trì chỉ là lao thật nhanh về phía vách đá
- Những lập trình viên giỏi nhất là những người tăng tốc nhờ AI nhưng không làm sụp đổ hệ thống
- AI gánh phần nặng, còn con người xác nhận rằng mọi thứ đang đứng vững đúng cách
- Cốt lõi là tìm ra điểm cân bằng (sweet spot) đó
- Các điểm thực hành dành cho tech lead và manager:
→ cần xây dựng trong đội ngũ một văn hóa coi AI là công cụ phải được sử dụng có trách nhiệm- khuyến khích vibe coding, nhưng đồng thời cũng phải đặt ra kỳ vọng và quy tắc rõ ràng để bảo vệ codebase
- code do AI sinh ra cũng phải luôn là đối tượng của code review,
- và xây dựng một văn hóa mà câu hỏi “Code này có hiểu được không?” trở nên tự nhiên
- đầu tư nâng cao năng lực để cả đội có thể hợp tác hiệu quả với AI
- đưa vào các kỹ năng mới như viết prompt tốt, đánh giá đề xuất của AI
- đây là một sự thay đổi mô hình giống như khi chuyển sang ngôn ngữ bậc cao hay áp dụng Git trước đây
→ những đội ngũ thích nghi sớm sẽ có lợi thế
- Điều chúng ta thực sự cần coi trọng trong kỹ thuật phần mềm vẫn là những điều sau:
- giải quyết vấn đề của người dùng
- xây dựng các hệ thống đáng tin cậy
- liên tục học hỏi
- vibe coding là phương tiện, không phải mục đích
- Nếu nó giúp mang lại giá trị tốt hơn và nhanh hơn cho người dùng thì đó là một công cụ tuyệt vời
- Nhưng nếu trong quá trình đó nó khiến chúng ta phải hy sinh chất lượng và bảo mật mà mình cần tin cậy, thì nên hạn chế sử dụng
- Bản chất cốt lõi vẫn không thay đổi:
→ tư duy rõ ràng, hiểu yêu cầu, thiết kế có tính đến thay đổi, và kiểm thử kỹ lưỡng
- Cuối cùng, hãy khắc ghi tinh thần này:
→ “Hãy di chuyển nhanh, nhưng đừng phá vỡ mọi thứ – hoặc nếu có phá vỡ, thì nhất định phải sửa được.” - Hãy viết code thật nhanh, nhưng nền tảng bên dưới phải là một cơ sở kỹ thuật vững chắc
- AI có thể là một chiếc đục mạnh mẽ trong tay người thợ lành nghề
→ nhưng người điều khiển chiếc đục đó vẫn là đôi tay con người
- Vì vậy hỡi các lập trình viên, hãy vibe – nhưng hãy vibe một cách thận trọng
- Hãy đón nhận tương lai, nhưng đừng đánh mất những nguyên tắc nền tảng đã đưa chúng ta đến đây
- vibe coding không phải cái cớ để biện minh cho chất lượng thấp,
→ mà là cơ hội để cho thấy chúng ta có thể tạo ra những điều lớn lao hơn đến mức nào khi kết hợp khả năng phán đoán của con người với năng lực tạo sinh của máy móc
- Những đội ngũ nội hóa được nguyên tắc này sẽ không chỉ trở nên nhanh hơn,
→ mà còn xây dựng được phần mềm xứng đáng để tồn tại lâu dài
Happy coding — và hãy giữ vibe thật cao, còn chất lượng thì cao hơn nữa.
3 bình luận
+1
Tôi đồng ý.
Cảnh báo bài dài.
Ý kiến trên Hacker News
Đã định nghĩa lại ý nghĩa của "vibe coding"
Cảm thấy sự cường điệu quanh AI coding quá lớn và không thể đáp ứng một cách thực tế
Gợi nhớ đến thời kỳ đầu những năm 2000 khi các tập đoàn lớn cố gắng outsource công việc phát triển sang các quốc gia thu nhập thấp
Đối xử với AI như một lập trình viên junior trong nhóm có thể còn tốn nhiều thời gian hơn
Điều này còn tùy vào use case
Có nhiều góc nhìn khác nhau về chất lượng phần mềm
Có câu hỏi về việc AI-assisted coding liệu có ảnh hưởng tiêu cực đến sự phát triển của lập trình viên hay không
Dùng vibe coding để đánh giá độ khó của công việc
Con người có xu hướng tiết kiệm năng lượng, và vibe coding cho phép phát triển với ít nỗ lực hơn
Toàn bộ bài viết có vẻ như chỉ đang phóng đại câu "con người cần review vibe code trước khi deploy lên production"