Cuộc Chiến Mà Không Ai Muốn Thừa Nhận

Có hai trường phái đang đối đầu nhau trong cộng đồng developer năm 2026, và cả hai đều nghĩ mình đúng.

Trường phái thứ nhất — Team Vibe Coding nói: “Ship fast, iterate faster. Code chỉ là phương tiện, sản phẩm mới là mục đích. AI viết code nhanh gấp 5 lần, tại sao phải tốn thời gian cho clean code khi ngày mai có thể phải rewrite hết?”

Trường phái thứ hai — Team Clean Code nói: “Fast code is dirty code. Technical debt sẽ giết bạn trong 6 tháng. AI-generated code là ‘code mì ăn liền’ — chạy ngay nhưng không ai maintain được. Tốc độ mà không có kỷ luật chỉ là chaos có tổ chức.”

Cả hai đều có điểm đúng. Cả hai đều có điểm mù. Bài viết này không đứng về bên nào — nó phân tích thẳng thắn cả hai và tìm ra con đường giữa.

Vấn Đề Thật Sự Với AI-Generated Code

Vấn đề 1: Inconsistency giữa các sessions

Đây là vấn đề fundamental mà ít ai thảo luận. Khi bạn viết code tay, style nhất quán vì nó đến từ một bộ não với một set of habits. Khi AI generate code, mỗi session có thể tạo ra patterns khác nhau.

Ví dụ thực tế: trong cùng một project, Claude Code có thể tạo error handling bằng try-catch ở file A, bằng Result type ở file B, và bằng error callback ở file C. Tất cả đều “đúng” — nhưng inconsistency này làm codebase khó đọc và khó maintain.

Nguyên nhân: AI models không có “memory” giữa các sessions. Mỗi session là trang giấy trắng. Dù bạn có file CLAUDE.md với conventions, AI vẫn có thể deviate vì nó generate based on probability, không phải rules.

Vấn đề 2: Over-engineering hoặc Under-engineering

AI có xu hướng “chơi an toàn” — tạo code verbose hơn cần thiết. Một function đơn giản có thể bị AI wrap trong 3 lớp abstraction, thêm error handling cho edge cases không bao giờ xảy ra, và implement design patterns không phù hợp với scale hiện tại.

Ngược lại, khi được prompt ngắn gọn, AI có thể under-engineer: bỏ qua validation, skip error handling, hardcode values thay vì config.

Sweet spot giữa hai cực này đòi hỏi human judgment — và đó chính là kỹ năng mà clean code practices training.

Vấn đề 3: “It works” trap

AI-generated code gần như luôn “chạy được” — pass tests, không có syntax errors, produce correct output. Nhưng “chạy được” và “tốt” là hai thứ rất khác nhau.

Code có thể chạy đúng nhưng có O(n²) complexity khi O(n) là đủ. Có thể chạy đúng nhưng query database N+1 lần thay vì 1 lần. Có thể chạy đúng nhưng có SQL injection vulnerability. Có thể chạy đúng nhưng memory leak khi chạy liên tục 24/7.

“It works” là bar quá thấp cho production code. Clean code practices nâng bar lên “it works correctly, efficiently, securely, and maintainably.”

Vấn Đề Thật Sự Với Clean Code Dogma

Dogma 1: Over-abstraction vì nguyên tắc

Uncle Bob’s SOLID principles là tuyệt vời — cho đúng context. Nhưng clean code dogma đôi khi dẫn đến over-abstraction: tạo interface cho class chỉ có một implementation, tách function 10 dòng thành 5 functions 2 dòng, tạo abstract factory pattern cho object chỉ được tạo ở 1 nơi.

Kết quả: code “clean” theo checklist nhưng khó đọc hơn vì phải jump qua 15 files để hiểu một flow đơn giản. Trong kỷ nguyên AI, khi AI có thể generate và refactor code nhanh chóng, mức abstraction cần phải pragmatic — không phải dogmatic.

Dogma 2: “Premature optimization is the root of all evil” — nhưng ngược lại cũng đúng

Clean code community thường quote Donald Knuth để justify không optimize sớm. Đúng — nhưng “premature non-optimization” cũng là vấn đề. Khi AI generate code mà developer không review performance characteristics, “chạy được” có thể trở thành “chạy nhưng chậm gấp 100 lần.”

Pragmatic approach: optimize hot paths sớm, để cold paths cho sau. AI có thể giúp identify hot paths nếu bạn hỏi đúng câu hỏi.

Dogma 3: Test coverage target cứng nhắc

“100% test coverage” hoặc “minimum 80% coverage” là targets phổ biến trong clean code playbook. Nhưng trong thực tế vibe coding, AI có thể generate tests cực nhanh — vấn đề không phải coverage number mà là test quality.

1000 dòng test mà chỉ test happy path thì vô nghĩa. 50 dòng test mà cover critical edge cases thì vô giá. Focus vào test quality, không phải quantity.

Con Đường Giữa — Pragmatic Clean Vibe Coding

Sau khi phân tích cả hai phía, đây là framework thực tế cho developer muốn vibe code nhanh mà vẫn maintain code quality.

Nguyên tắc 1: Convention File là bắt buộc, không phải optional

Trước khi bắt đầu vibe coding bất kỳ project nào, tạo file conventions (CLAUDE.md, .cursorrules, hoặc tương đương) với nội dung cụ thể:

Error handling strategy (một cách duy nhất, nhất quán toàn project). Naming conventions (file names, variable names, function names). Project structure rules (file nào nằm ở đâu). State management approach (một library, một pattern). API response format (standardized, không để AI tự chọn).

Đây là đầu tư 30 phút ban đầu mà tiết kiệm hàng chục giờ refactoring sau này.

Nguyên tắc 2: Review trước Accept — không ngoại lệ

Mỗi đoạn code AI generate phải được đọc trước khi accept. Không phải đọc lướt — đọc kỹ, với mindset: code này có side effects gì? Performance characteristics ra sao? Security implications? Error handling đủ chưa?

Nếu bạn không hiểu một dòng code, hỏi AI giải thích. Nếu giải thích không thuyết phục, rewrite. Đừng deploy code bạn không hiểu.

Nguyên tắc 3: Refactor sessions định kỳ

Mỗi tuần, dành 2-3 giờ cho “refactoring session” — dùng chính vibe coding. Prompt AI: “Review codebase và identify inconsistencies in patterns, naming conventions, error handling approaches. Suggest unified approach và implement refactoring.”

AI cực kỳ giỏi pattern detection — nó sẽ tìm ra inconsistencies mà bạn miss khi code từng file riêng lẻ. Refactor session giống như “dọn nhà” — không glamorous nhưng essential cho long-term maintainability.

Nguyên tắc 4: Critical paths viết kỹ, non-critical paths vibe nhanh

Không phải mọi code đều cần level clean code giống nhau. Hãy phân loại code theo criticality.

High criticality — authentication, authorization, payment processing, data validation. Đây là code cần viết kỹ: review multiple times, comprehensive tests, security audit. Vibe coding hỗ trợ nhưng human oversight tối đa.

Medium criticality — core business logic, API endpoints, database queries. Vibe coding với careful review. Test coverage cho main flows và edge cases.

Low criticality — UI components, admin pages, internal tools, utility functions. Vibe code nhanh, review nhẹ. Refactor sau nếu cần.

Phân loại này giúp allocate effort hợp lý — không over-engineer mọi thứ, không under-engineer thứ quan trọng.

Nguyên tắc 5: Tests là safety net, không phải bureaucracy

Viết tests bằng vibe coding cực nhanh — tận dụng. Nhưng focus vào test quality:

Luôn test: edge cases, error paths, security boundaries, data validation, integration points. Optional test: UI rendering (thay đổi liên tục), utility functions đơn giản (logic obvious), configuration (ít khi thay đổi).

Prompt pattern cho high-quality tests: “Viết tests cho [function/component] focus vào edge cases và failure modes. Tôi KHÔNG cần test happy path — tôi cần test: input rỗng, input quá dài, characters đặc biệt, concurrent access, timeout, và authorization bypass attempts.”

Nguyên tắc 6: Documentation sinh ra từ code, không phải ngược lại

Clean code philosophy nói “code should be self-documenting.” Trong vibe coding era, điều này càng đúng hơn — nhưng cần bổ sung:

Dùng AI generate JSDoc/docstring cho mọi public function. Dùng AI generate README cho mỗi module. Dùng AI generate architecture decision records (ADR) cho major decisions. Documentation này sinh ra nhanh bằng vibe coding và giúp AI hiểu codebase tốt hơn trong tương lai — tạo positive feedback loop.

Metrics: Đo Code Quality Trong Vibe Coding Era

Thay vì chỉ đo tốc độ, hãy track cả quality metrics:

Deployment frequency — bạn deploy thường xuyên hơn? (Tốt — nghĩa là changes nhỏ, risk thấp.) Change failure rate — bao nhiêu % deployments gây incident? (Target dưới 5%.) Time to recover — khi có incident, fix mất bao lâu? (Target dưới 1 giờ.) Code churn — bao nhiêu % code vừa viết phải rewrite trong 2 tuần? (Nếu trên 30%, code quality có vấn đề.) Dependency health — bao nhiêu dependencies outdated hoặc có vulnerabilities? (Check weekly.)

Đây là metrics từ DORA research — chúng đo outcome (delivery performance) thay vì proxy (lines of code, test coverage) — và chúng hoạt động tốt cho cả vibe coding và traditional coding.

Case Study: Project Thật — Trước Và Sau

Trước: Vibe coding không có discipline

Developer A vibe code MVP e-commerce trong 2 tuần. Kết quả: app chạy được, 47 features. Nhưng 3 error handling patterns khác nhau trong cùng project. Không có test nào. 5 API endpoints có SQL injection vulnerability. Performance: trang product list load 4.2 seconds (N+1 queries). Sau 2 tháng: 3 production incidents, 2 data corruption issues, developer A mất 3 tuần refactor.

Sau: Vibe coding với Pragmatic Clean Code

Developer B vibe code MVP tương tự, cũng 2 tuần, nhưng áp dụng framework trên. Kết quả: app chạy được, 42 features (ít hơn 5 features, nhưng solid hơn). Conventions file từ ngày 1, code consistent. Test coverage 65% focus vào critical paths. 0 security vulnerabilities (AI audit trước launch). Performance: trang product list load 0.8 seconds (optimized queries). Sau 2 tháng: 0 production incidents, dễ dàng thêm features mới.

Developer B ship ít features hơn 12%, nhưng total cost of ownership thấp hơn 60% sau 2 tháng. Đó là ROI của clean code trong vibe coding.

Kết Luận — Không Phải Chọn Một, Mà Chọn Cả Hai

Vibe coding và clean code không phải cuộc chiến zero-sum. Chúng là hai dimensions của cùng một mục tiêu: deliver phần mềm có giá trị một cách bền vững.

Vibe coding cho bạn tốc độ. Clean code cho bạn durability. Kết hợp pragmatic cả hai cho bạn sustainable velocity — nhanh mà không tích lũy debt, clean mà không chậm đến mức miss market window.

Công thức cuối cùng rất đơn giản: Convention file + careful review + periodic refactoring + critical path discipline + strategic testing = Clean Vibe Coding.

Không cần chọn bên. Hãy chọn cả hai — một cách pragmatic, không dogmatic.