Vibe Coding Là Gì Vậy?

Tôi sẽ thừa nhận: lần đầu tiên nghe “vibe coding,” tôi nghĩ đó chỉ là một từ khoá khác. Một trend LinkedIn nữa, bên cạnh “developer 10x” và những chuyên gia vẽ vời.

Rồi tôi dành ba tháng xây dựng portfolio site của mình với Claude Opus 4 làm pair programmer, và tôi hiểu ra: vibe coding không phải trend. Nó là một cách hoàn toàn khác nhau để xây dựng phần mềm. Và nó vừa lộn xộn, vừa bực bội, vừa tuyệt vời, vừa đẩy cao năng suất — đôi khi tất cả những thứ đó xảy ra trong cùng một giờ.

Tôi là Thuan Luong, một Tech Lead ở Việt Nam. Đây là câu chuyện thực tế của tôi về những gì xảy ra khi bạn dừng viết code từng dòng và bắt đầu miêu tả những gì bạn muốn cho một AI có thể nghiên cứu, viết code, debug, và deploy cùng bạn.

Không hype. Không demo được cherry-pick. Chỉ có sự thực — bao gồm cả những phần nơi mọi thứ bị hỏng.

Quy Trình Làm Việc Vibe Coding

Trước khi đi vào những câu chuyện thực tế, hãy tôi giải thích một phiên vibe coding điển hình như thế nào với Claude Code (CLI tool) và Claude Opus 4.

Quy trình rất đơn giản:

1. Bạn mô tả những gì bạn muốn — bằng lời nói thường ngày, dù chi tiết hay mơ hồ
2. Claude nghiên cứu — đọc codebase của bạn, hiểu các pattern hiện có, kiểm tra dependencies
3. Claude viết code — xuyên suốt nhiều files nếu cần, tuân theo quy ước của project bạn
4. Bạn review và lặp lại — chấp nhận, từ chối, hoặc điều hướng lại
5. Claude debug — khi có vấn đề, bạn mô tả, Claude điều tra
6. Bạn deploy — đôi khi debug deployment cùng nhau

Đây là nó trông như thế nào trong thực tế:

flowchart TD
    A[Ban co y tuong] --> B[Mo ta cho Claude]
    B --> C[Claude doc codebase]
    C --> D[Claude de xuat cach lam]
    D --> E{Ban dong y?}
    E -->|Co| F[Claude viet code]
    E -->|Khong| G[Ban tao huong moi]
    G --> D
    F --> H[Ban review]
    H --> I{Tham lay?}
    I -->|Co| J[Commit va deploy]
    I -->|Can sua| K[Mo ta viec can sua]
    K --> F
    J --> L{Lam viec trong production?}
    L -->|Co| M[Ship no]
    L -->|Khong| N[Debug cung nhau]
    N --> F

Nghe có vẻ gọn gàng, nhưng thực tế, bạn sẽ dành nhiều thời gian trong vòng feedback giữa “Claude viết code” và “Mô tả vấn đề cần sửa.” Và đó là nơi điều kỳ diệu xảy ra — hoặc nơi bạn bị mất một giờ để tìm kiếm một con ma.

Ví Dụ Thực Tế 1: Xây Dựng Một Bài Blog 1200 Dòng Đa Ngôn Ngữ Từ Đầu

Nhiệm Vụ

Tôi muốn viết một bài blog kỹ thuật sâu sắc về khả năng AI giọng nói của Qwen — mô hình speech-to-text, text-to-speech, và tương tác giọng nói thời gian thực của họ. Bài viết cần:

• Được nghiên cứu kỹ lưỡng với chi tiết kỹ thuật chính xác
• Đa ngôn ngữ (phiên bản tiếng Anh và tiếng Việt)
• Phong phú về hình ảnh với sơ đồ Mermaid và hình ảnh hero SVG
• Được định dạng đúng cho blog dựa trên Astro của tôi trên Cloudflare Pages
• Khoảng 1200 dòng cho mỗi phiên bản ngôn ngữ

Đây là loại công việc mà bình thường sẽ mất tôi hai ngày đầy đủ: một ngày nghiên cứu và lập dàn ý, một ngày viết, định dạng, tạo sơ đồ, và deploy.

Với Claude, nó mất một phiên. Khoảng ba giờ.

Cách Nó Diễn Ra

Bước 1: Prompt nghiên cứu

Tôi bắt đầu đơn giản:

Nghiên cứu các mô hình AI giọng nói của Qwen — Qwen2-Audio,
Qwen-TTS, và khả năng tương tác giọng nói thời gian thực của họ.
Tôi cần các chi tiết kỹ thuật chính xác: kiến trúc mô hình,
ngôn ngữ được hỗ trợ, kết quả benchmark, khả dụng API.
Tập trung vào những gì làm cho chúng thú vị cho developers
xây dựng ứng dụng giọng nói.

Claude trả lại với một tổng quan có cấu trúc bao gồm kiến trúc mô hình, phương pháp huấn luyện, so sánh benchmark, và các endpoint API. Một số tôi đã biết, một số là mới. Quan trọng là, Claude chỉ ra những khu vực mà thông tin không chắc chắn hoặc nơi tài liệu chính thức thiếu hụt — điều tôi đánh giá cao hơn là tự tin ảo tưởng.

Bước 2: Dàn ý và cấu trúc

Dựa trên nghiên cứu này, tạo dàn ý chi tiết cho một bài
blog kỹ thuật. Đối tượng mục tiêu: developers và tech leads
đánh giá các giải pháp AI giọng nói. Bao gồm các phần
tìm hiểu kiến trúc sâu, ví dụ code thực tế, so sánh với
các giải pháp thay thế (OpenAI Whisper, ElevenLabs),
và một framework quyết định "khi nào dùng cái gì."

Bước 3: Bản nháp đầy đủ

Đây là nơi mọi thứ thú vị. Tôi yêu cầu Claude viết bài viết hoàn chỉnh, và đây là nơi phần “vibe” của vibe coding phát huy. Tôi không quản lý từng đoạn. Thay vào đó, tôi mô tả tone tôi muốn:

Viết như một senior engineer giải thích cho đồng nghiệp
qua cà phê, không phải như một trang tài liệu. Bao gồm
những đánh giá thực tế — nơi Qwen xuất sắc và nơi nó
kém. Sử dụng ví dụ code có thể chạy, không phải pseudocode.
Thêm sơ đồ Mermaid cho các phần kiến trúc.

Claude tạo ra bài viết đầy đủ. Nó… tầm 80% ở đó. Cấu trúc vững chắc, chi tiết kỹ thuật chính xác, ví dụ code chức năng. Nhưng tone quá hình thức ở một số chỗ, một số sơ đồ cần cấu trúc lại, và một vài phần cần sâu sắc hơn.

Bước 4: Vòng lặp lặp lại

Đây là nơi vibe coding xứng đáng với cái tên của nó. Thay vì viết lại các phần, tôi cung cấp feedback hướng đi:

Phần về kiến trúc Qwen2-Audio quá bề mặt. Sâu hơn vào
cách tiếp cận dual-encoder và giải thích tại sao nó
quan trọng cho các tình huống đa ngôn ngữ. Ngoài ra,
bảng so sánh với Whisper cần thêm một dòng về độ trễ
thời gian thực.

Và:

Sơ đồ Mermaid cho đường ống TTS quá phức tạp. Đơn giản hóa
nó — hiển thị luồng cấp cao, không phải từng thành phần
bên trong.

Sau ba vòng lặp lại, phiên bản tiếng Anh xong. Rồi đến phiên bản tiếng Việt.

Bước 5: Tạo phiên bản đa ngôn ngữ

Bây giờ tạo phiên bản tiếng Việt. Không chỉ dịch — hãy
địa phương hóa. Các developers Việt Nam có bối cảnh và
ưu tiên khác. Điều chỉnh ví dụ nếu cần thiết, và đảm bảo
tất cả các sơ đồ Mermaid chỉ sử dụng ASCII (không có dấu
tiếng Việt trong nhãn sơ đồ).

Đây là một điểm tinh tế nhưng quan trọng. Dịch máy của nội dung kỹ thuật hầu như luôn là tồi tệ. Những gì tôi cần là địa phương hóa — và Claude xử lý nó tốt một cách bất ngờ. Phiên bản tiếng Việt đọc một cách tự nhiên, sử dụng các thuật ngữ kỹ thuật thích hợp (chúng tôi sử dụng một hỗn hợp các thuật ngữ tiếng Việt và tiếng Anh ở Việt Nam), và điều chỉnh các tham chiếu văn hóa.

Ràng buộc sơ đồ Mermaid là thứ tôi học theo cách khó. Các công cụ rendering Mermaid bị nghẹn trên các dấu diacritical trong nhãn nút. Vì vậy mỗi sơ đồ cần chỉ text ASCII, thậm chí trong phiên bản tiếng Việt. Claude ghi nhớ ràng buộc này xuyên suốt toàn bộ phiên mà không cần tôi lặp lại.

Kết Quả

Hai bài blog hoàn chỉnh, mỗi bài khoảng 1200 dòng. Frontmatter Astro được định dạng đúng. Sơ đồ Mermaid hoạt động. Một prompt hình ảnh hero SVG tôi có thể sử dụng với một trình tạo hình ảnh. Cả hai được deploy lên Cloudflare Pages trong cùng một phiên.

Tổng thời gian: khoảng 3 giờ.

Tôi sẽ viết prose tốt hơn ở một số chỗ không? Ở một số chỗ, vâng. Nhưng chất lượng chung có đủ tốt để xuất bản không? Hoàn toàn. Và chỉ riêng việc biên soạn nghiên cứu đã tiết kiệm cho tôi một ngày đầy đủ.

Code Thực Tế Đã Ship

Dưới đây là một ví dụ về cấu trúc frontmatter Astro và component mà Claude tạo ra:

---
import BlogLayout from '../../layouts/BlogLayout.astro';
import { getCollection } from 'astro:content';

const post = await getCollection('blog').then(posts =>
  posts.find(p => p.slug === 'qwen-voice-ai-complete-guide')
);

const { Content } = await post.render();
---

<BlogLayout
  title={post.data.title}
  description={post.data.description}
  pubDate={post.data.pubDate}
  heroImage={post.data.heroImage}
  tags={post.data.tags}
  lang={post.data.lang}
>
  <Content />
</BlogLayout>

Và một đoạn từ sơ đồ Mermaid thực tế trong bài:

flowchart LR
    A[Audio Input] --> B[Audio Encoder]
    A --> C[Whisper Encoder]
    B --> D[Fusion Layer]
    C --> D
    D --> E[LLM Backbone]
    E --> F[Text Response]
    E --> G[Audio Understanding]

Đơn giản, gọn gàng, chính xác. Loại sơ đồ mất 5 phút để viết bạn nhưng Claude tạo chính xác lần đầu tiên khoảng 70% thời gian.

Ví Dụ Thực Tế 2: Cuộc Phiêu Lưu Debug Cache Cloudflare

Đây là câu chuyện yêu thích của tôi vì nó nắm bắt toàn bộ phổ của AI pair programming — cái đẹp và cái bực bội.

Vấn Đề

Sau khi deploy một cập nhật lên blog của tôi, trang web live vẫn hiển thị nội dung cũ. Cụ thể, một phiên bản cũ hơn của một bài blog được phục vụ mặc dù phiên bản mới được xây dựng đúng và upload lên Cloudflare Pages.

Tôi đã gặp điều này trước đây với browser caching, vì vậy tôi đã làm những điều rõ ràng trước tiên:

• Hard refresh (Ctrl+Shift+R)
• Xóa cache trình duyệt
• Kiểm tra trong một cửa sổ ẩn danh
• Thử một trình duyệt khác

Nội dung cũ tương tự ở khắp nơi. Đây không phải một vấn đề browser cache.

Đưa Claude Vào Phiên Debug

Trang Cloudflare Pages của tôi đang phục vụ nội dung cũ
sau khi deploy. Tôi đã xác minh rằng đó không phải cache
trình duyệt. Giúp tôi debug.

Claude ngay lập tức đề nghị kiểm tra response headers:

curl -I https://thuanluong.com/blog/qwen-voice-ai/

Output rất tiết lộ:

HTTP/2 200
content-type: text/html; charset=utf-8
cf-cache-status: HIT
age: 14523
cache-control: public, max-age=604800

Hai điều nổi bật: cf-cache-status: HIT có nghĩa là Cloudflare’s edge CDN đã cache trang, và age: 14523 có nghĩa là cached version khoảng 4 giờ tuổi. max-age=604800 có nghĩa Cloudflare sẽ tiếp tục phục vụ cached version này tối đa 7 ngày.

Hành Trình Debug

Đây là nơi nó trở nên thú vị. Claude và tôi đã đi qua nhiều cách tiếp cận:

Nỗ Lực 1: Purge Cloudflare cache qua dashboard

Claude hướng dẫn tôi qua Cloudflare dashboard cache purge. Tôi purged mọi thứ. Kiểm tra lại.

cf-cache-status: HIT
age: 2

Chờ cái gì? Cache được purged và ngay lập tức được re-populated với nội dung cũ? Điều đó không có ý nghĩa.

Nỗ Lực 2: Cách tiếp cận file _headers

Claude đề nghị thêm file _headers để kiểm soát hành vi cache:

# public/_headers
/blog/*
  Cache-Control: public, max-age=0, must-revalidate
  CDN-Cache-Control: max-age=60

Điều này sẽ cho Cloudflare biết chỉ cache 60 giây và cho trình duyệt không cache gì cả. Chúng tôi deploy thay đổi này.

Kết quả: File _headers được deploy, nhưng Cloudflare Pages không áp dụng nó cho các URLs bị ảnh hưởng. Các cache headers cũ vẫn tồn tại.

Nỗ Lực 3: Đi sâu hơn vào cấu hình Cloudflare Pages

Claude đề nghị kiểm tra xem có file _redirects hoặc bất kỳ Page Rules nào ghi đè headers. Chúng tôi kiểm tra — không có gì. Claude sau đó đề nghị vấn đề có thể là tiered caching của Cloudflare (nơi edge caches kéo từ một shared regional cache cũng có nội dung cũ).

Đây là một lý thuyết thú vị, nhưng nó dẫn chúng tôi vào một rabbit hole về cơ sở hạ tầng caching của Cloudflare mà, mặc dù có tính giáo dục, không giải quyết vấn đề.

Nỗ Lực 4: Giải pháp đơn giản

Sau khoảng 45 phút debug, tôi bước lùi và hỏi Claude một câu hỏi khác:

Quên cache đi. Nếu chúng ta chỉ thay đổi URL của trang thì
sao? Nó sẽ bỏ qua tất cả các vấn đề caching không?

Phản hồi của Claude về cơ bản là: “Vâng, điều đó sẽ hoạt động. Một URL mới có nghĩa là không có cached version nào tồn tại ở bất kỳ nơi nào trong CDN của Cloudflare.”

Vì vậy chúng tôi đã đổi tên URL từ /blog/qwen-voice-ai/ thành /blog/qwen-voice-ai-complete-guide/, cập nhật tất cả các liên kết nội bộ, thêm một redirect từ URL cũ, và deploy.

Nó hoạt động ngay lập tức. Nội dung tươi, không có vấn đề cache.

Bài Học

Câu chuyện này minh họa một điều quan trọng về vibe coding với AI: Claude đúng kỹ thuật ở mỗi bước nhưng không đề nghị giải pháp đơn giản nhất trước tiên. Nó đi cho “proper” fix (cache headers, cache purging, CDN configuration) thay vì “pragmatic” fix (chỉ đơn giản thay đổi URL).

Đây là một pattern tôi đã thấy lặp đi lặp lại. AI pair programmers có xu hướng phức tạp hóa các giải pháp. Chúng reach cho cách tiếp cận kiến trúc đúng khi một quick hack sẽ giải quyết vấn đề trong 30 giây.

Là người ở vòng lặp, đó là công việc của bạn: biết khi nào để nói “quên proper fix, chúng ta chỉ work around nó.”

flowchart TD
    A[Van de: noi dung cu sau deploy] --> B[Kiem tra browser cache]
    B --> C[Khong phai browser cache]
    C --> D[Kiem tra CF response headers]
    D --> E[cf-cache-status: HIT]
    E --> F[Purge CF cache]
    F --> G[Van con cu -- cache repopulated]
    G --> H[Thu tuc headers file]
    H --> I[Headers khong picked up]
    I --> J[Nghien cuu CF tiered caching]
    J --> K[Rabbit hole -- 30 min tron]
    K --> L[Tro lai va suy nghi]
    L --> M[Chi thay doi URL]
    M --> N[Van de giai quyet trong 2 phut]

    style K fill:#ff9999
    style N fill:#99ff99

Hộp hồng là nơi chúng tôi lãng phí thời gian. Hộp xanh là nơi chúng tôi nên bắt đầu. Nhìn lại 20/20, nhưng đây chính xác là loại quyết định tư duy sơ bộ phân biệt vibe coding hiệu quả khỏi chỉ để AI lái.

Ví Dụ Thực Tế 3: Mở Rộng Nội Dung Hiện Tại Xuyên Suốt Nhiều Files

Nhiệm Vụ

Tôi có một loạt bài blog hiện tại về Agentic AI — bao gồm các khái niệm như autonomous agents, tool use, planning loops, và multi-agent systems. Các bài viết rắn chắc nhưng cần mở rộng:

• Thêm ví dụ ứng dụng thực tế
• Bao gồm các đánh giá usability cho các mức độ kỹ năng developer khác nhau
• Thêm các phần về các tính năng nâng cao như memory management và error recovery
• Cập nhật các ví dụ code để phản ánh các pattern API mới hơn

Phần tricky: điều này liên quan đến việc sửa đổi 4 files cùng lúc, và những thay đổi cần phải nhất quán xuyên suốt tất cả chúng.

Tại Sao Đây Là Một Nhiệm Vụ Vibe Coding Hoàn Hảo

Sửa đổi nhiều files liên quan trong khi duy trì tính nhất quán là một trong những thứ mà AI pair programming làm thực sự tốt. Một con người làm điều này thủ công sẽ cần:

1. Mở tất cả 4 files
2. Đọc qua mỗi files để hiểu cấu trúc hiện tại
3. Lập kế hoạch cho các additions để đảm bảo tính nhất quán
4. Thực hiện thay đổi từng files một, cross-referencing những thứ khác
5. Review mọi thứ để tính nhất quán

Với Claude, quy trình là:

Tôi có 4 bài blog về Agentic AI trong /src/content/blog/.
Chúng là:
- agentic-ai-part1-fundamentals.md
- agentic-ai-part2-tool-use.md
- agentic-ai-part3-planning.md
- agentic-ai-part4-multi-agent.md

Tôi muốn thêm cái sau vào mỗi bài:
1. Phần "Real-World Applications" với 3-4 ví dụ cụ thể
   liên quan đến chủ đề của bài đó
2. Phần "Usability Assessment" đánh giá độ phức tạp
   trên một thang đo (beginner/intermediate/advanced)
3. Phần "Advanced Features" bao gồm edge cases
   và production considerations

Đảm bảo cross-references giữa các bài nhất quán
và sử dụng cùng một thuật ngữ xuyên suốt.

Claude đọc cả bốn files, hiểu cấu trúc và voice hiện tại, và tạo ra additions phù hợp với tone và độ sâu kỹ thuật của nội dung hiện tại. Nó thậm chí còn phát hiện một inconsistency trong cách tôi sử dụng các thuật ngữ “agent” vs “assistant” xuyên suốt các bài và đề nghị chuẩn hóa.

Multi-File Edit Trong Hành Động

Đây là điều mà một multi-file change trông như thế nào trong Claude Code. Claude đề xuất edits cho mỗi files, hiển thị chính xác những gì sẽ được thêm và ở đâu:

<!-- Trong agentic-ai-part2-tool-use.md -->

## Real-World Applications

### 1. Automated Code Review Pipelines

Tool-using agents xuất sắc trong các workflow review code nơi
agent cần:
- Đọc files từ một repository (file system tools)
- Chạy linters và test suites (shell execution tools)
- Query documentation APIs (HTTP tools)
- Post review comments (GitHub API tools)

Đây không phải lý thuyết. Các teams tại các công ty như
Stripe và Shopify đang chạy các biến thể của pattern này
trong production ngày hôm nay, xử lý hàng trăm pull
requests mỗi ngày với agent-assisted review.

### 2. Customer Support Triage

Khi một support ticket đến, một tool-using agent có thể:
- Query customer database cho account context
- Tìm kiếm knowledge base cho articles liên quan
- Kiểm tra system status dashboards cho ongoing incidents
- Draft một response với tất cả relevant context đính kèm

Key insight là mỗi actions này map tới một specific tool
agent có thể invoke, và agent quyết định tools nào sử dụng
dựa trên ticket content.

### 3. Data Pipeline Monitoring

Agents với access tới monitoring tools có thể:
- Query metrics databases (Prometheus, Datadog)
- Đọc log files từ distributed systems
- Thực thi diagnostic scripts
- Tạo incident tickets khi thresholds bị vượt
- Page on-call engineers cho critical issues

Use case này minh họa tại sao tool permissions quan trọng —
bạn muốn agent đọc metrics và tạo tickets, nhưng có lẽ
không để nó restart production services tự động.

Claude tạo ra các phần tương tự cho cả bốn files, duy trì chất lượng nhất quán và cross-referencing đúng. Khi Part 3 (Planning) reference các concepts từ Part 2 (Tool Use), các references phù hợp với nội dung thực tế.

Review Process

Tôi reviewed mỗi file’s changes, yêu cầu điều chỉnh ở hai chỗ:

Usability assessment trong Part 3 đánh giá planning loops
là "intermediate" nhưng tôi nghĩ implementation complexity
thực sự là "advanced" — đặc biệt là re-planning và
error recovery parts. Điều chỉnh rating và explanation.

Và:

Real-world applications trong Part 4 (multi-agent) quá
giống Part 3. Thay thế ví dụ thứ hai bằng cái về
multi-agent testing — nơi các agents khác nhau chơi
các roles khác nhau trong một test scenario.

Claude đã make cả hai changes, và kết quả là nhất quán xuyên suốt cả bốn files. Tổng thời gian: khoảng 90 phút cho những gì sẽ là một ngày đầy đủ careful editing.

Good, Bad, và Ugly

Sau ba tháng phiên làm việc vibe coding hàng ngày, đây là đánh giá thực tế của tôi.

Good

Research compilation xuất sắc. Khi tôi cần hiểu một technology, library, hoặc API mới, Claude có thể synthesize thông tin từ training data của nó nhanh hơn tôi đọc documentation. Nó không luôn đúng, nhưng nó cung cấp cho tôi một starting point 80% ở đó.

Multi-file changes với tính nhất quán. Như được thể hiện trong Ví Dụ 3, editing nhiều related files trong khi duy trì tính nhất quán là nơi AI pair programming thực sự tỏa sáng. AI giữ tất cả files trong context cùng lúc, điều mà con người đấu tranh.

Boilerplate và patterns. Setup một component mới, viết test scaffolding, tạo config files — bất kỳ cái gì theo established patterns được đáng kể nhanh hơn với Claude. Tôi ước tính nó tiết kiệm tôi 60-70% thời gian trên các tasks này.

Giải thích code của bạn lại cho bạn. Điều này nghe ngu xuẩn, nhưng nó genuinely hữu ích. Khi tôi quay lại code tôi viết vài tháng trước, tôi hỏi Claude để giải thích cái nó làm. Nó đọc code, hiểu context, và cung cấp cho tôi một summary nhanh hơn re-reading nó.

Error messages và debugging. Dán một error message và hỏi “điều này có nghĩa là gì và tôi làm thế nào để fix nó” hoạt động tốt một cách bất ngờ. Claude correctly diagnose vấn đề khoảng 75% thời gian trên lần đầu tiên.

Đây là một ví dụ thực tế từ một debug session:

Error: [astro] Cannot read properties of undefined
(reading 'slug')
  at getStaticPaths (/src/pages/blog/[...slug].astro:8:34)

Prompt của tôi: “Error này bắt đầu xuất hiện sau khi tôi thêm một bài blog mới. Cái gì đang xảy ra?”

Claude’s response identified rằng bài blog mới bị thiếu slug field trong frontmatter, cái gì gây ra dynamic route break. Correct diagnosis, 10-second fix.

Bad

Network và deployment infrastructure. Claude hiểu code rất tốt. Nó hiểu deployment infrastructure… ít hơn. Cloudflare cache debugging saga là một ví dụ hoàn hảo. Claude biết về CDN caching theo concept nhưng không có practical experience debugging production caching issues mà một seasoned DevOps engineer sẽ có.

Context window limitations. Mặc dù có một large context window, Claude có thể mất track của details trong very long sessions. Sau khoảng 2 giờ continuous work, tôi đã notice nó đôi khi quên constraints tôi đã mention earlier. Fix đơn giản — restate important constraints periodically — nhưng nó là cái gì để aware.

Overconfident suggestions. Đôi khi Claude đề xuất một fix với complete confidence và nó sai. Điều này đặc biệt phổ biến với version-specific behavior. Claude có thể đề xuất một giải pháp hoạt động trong version X của một library nhưng không hoạt động trong version Y. Luôn verify.

“Hãy để tôi restructure mọi thứ” tendency. Khi bạn hỏi Claude fix một small bug, nó đôi khi muốn refactor toàn bộ file. Bạn hỏi bandage, nó đề xuất surgery. Học để nói “chỉ fix cái một này, đừng thay đổi bất kỳ cái gì khác” là một essential vibe coding skill.

Ugly

Hallucinated APIs. Điều này đã cải thiện rất nhiều với Opus 4 so với các mô hình trước đó, nhưng nó vẫn xảy ra. Claude đôi khi reference API endpoints, function signatures, hoặc config options không tồn tại. Trong một session, nó confidently nói với tôi về một Cloudflare Pages configuration option mà tôi spend 20 phút searching trước khi realize nó hallucinated.

“Works in theory” problem. Claude có thể generate code logically correct nhưng không hoạt động trong environment cụ thể của bạn. Ví dụ, nó một lần generated một Node.js script sử dụng top-level await trong một context nơi project không được configured cho ES modules. Code là correct ES2022 JavaScript. Nó chỉ không chạy trong setup của tôi.

Infinite debugging loops. Đôi khi Claude và tôi bị stuck trong một vòng lặp nơi mỗi attempted fix tạo một vấn đề mới. Điều này thường có nghĩa chúng ta đang approach vấn đề từ một completely wrong angle. Fix là stop, bước lùi, giải thích vấn đề từ scratch, và bắt đầu lại. Nhưng recognizing khi bạn ở trong vòng lặp này mất experience.

Hiểu Kinh Tế Vibe Coding

Một cái gì mà nobody nói về là economics của vibe coding. Nó không free, và hiểu cost structure quan trọng.

Mỗi Claude Code session consume tokens. Một typical 2-hour session building một feature có thể use:

Nó có worth không? Với tôi, absolutely. Một feature mất 8 giờ build manually mất 2-3 giờ với Claude. Thậm chí accounting cho API costs, time savings là significant. Nhưng điều này giả định bạn đã là một competent developer có thể review và guide AI effectively.

Nếu bạn một junior developer, toán là khác. Bạn có thể spend hơn time understanding và verifying Claude’s suggestions so với những gì bạn sẽ tiết kiệm. Vibe coding hoạt động best khi bạn có đủ experience để biết nếu AI’s output là correct.

Practical Tips cho Effective Vibe Coding Sessions

Sau hàng trăm hours pair programming với Claude, đây là những patterns consistently hoạt động:

1. Start Với Context, Không Instructions

Bad:

Create một React component cho user authentication.

Good:

Tôi đang build một Next.js 14 app với App Router.
Authentication được handled bởi NextAuth.js v5 với GitHub
và Google providers. Existing components sử dụng
Tailwind CSS và follow một pattern nơi mỗi component
có một corresponding .test.tsx file. Tạo một sign-in
component phù hợp existing pattern này.

Càng nhiều context bạn cung cấp upfront, bạn càng cần ít iterations sau.

2. Review Trong Chunks, Không All at Once

Khi Claude generates một large amount code, không cố review nó tất cả cùng lúc. Hỏi Claude để giải thích mỗi section:

Hướng dẫn tôi qua các changes bạn made tới auth
middleware. Mỗi section làm gì và tại sao bạn
implement nó theo cách đó?

Điều này catches issues một quick skim sẽ miss.

3. Sử Dụng Checkpoints

Sau mỗi significant milestone, commit changes của bạn. Điều này cung cấp cho bạn một rollback point nếu next round changes goes sideways.

git add -A
git commit -m "feat: add user auth flow - working state"

Tôi đã được saved bởi practice này hơn là tôi có thể count.

4. Biết Khi Nào Để Take Over

Có những times khi nó faster viết code bạn thay vì giải thích gì bạn muốn Claude. Small, surgical changes — rename một variable, adjust một CSS value, fix một typo — thường faster làm manually.

Rule of thumb của tôi: nếu tôi có thể describe change trong ít hơn words so với change itself, tôi chỉ làm nó manually.

5. Restate Constraints Periodically

Trong long sessions, nhắc Claude của important constraints:

Remember: tất cả Mermaid diagrams phải sử dụng
ASCII-only text, không special characters. Và tất cả
new components cần corresponding test files.

Điều này prevent drift trong long sessions nơi Claude có thể quên earlier instructions.

6. Sử Dụng Error-First Approach Cho Debugging

Thay vì describing những gì bạn expected xảy ra, show Claude những gì actually happened:

Bad:

Login không hoạt động.

Good:

Khi tôi click sign-in button, tôi get error này
trong console:

TypeError: Cannot read property 'session' of undefined
  at AuthProvider (auth-provider.tsx:23:15)

Đây là relevant code từ auth-provider.tsx:
[paste code]

Session object nên được provided bởi NextAuth
nhưng nó appear undefined trong context này.

7. Tách Research Từ Implementation

Không hỏi Claude research và implement trong same prompt. Tách nó:

1. Đầu tiên, research: “Cái gì là best practices cho X?”
2. Review research, quyết định approach
3. Sau đó, implement: “Dựa trên những gì chúng ta discuss, implement approach B”

Điều này cung cấp cho bạn một decision point giữa research và implementation, cái gì produce kết quả tốt hơn.

8. Keep một Session Log

Tôi keep brief notes trong mỗi vibe coding session:

Session: 2026-04-15
- Goal: Add dark mode tới blog
- What worked: Component generation, CSS variables
- What failed: Theme persistence (localStorage issue)
- Time spent: 2.5 hours
- Outcome: Dark mode shipped, persistence fixed

Những logs này giúp tôi improve prompting của tôi over time và track type của tasks nào benefit most từ AI pair programming.

Workflow Trong Practice: Full Session Timeline

Hãy tôi cung cấp bạn một concrete timeline của một actual session để show cái gì vibe coding trông như thế nào trong practice:

Tổng: khoảng 2.5 giờ từ idea đến production. Và đây là cho một real feature, không phải toy example.

Điều important để notice là distribution của time:

• Research và planning: ~35 phút (23%)
• Implementation: ~60 phút (40%)
• Testing: ~30 phút (20%)
• Deployment và fixes: ~30 phút (20%)

So sánh điều này với pre-AI workflow của tôi nơi implementation alone sẽ take 3-4 giờ. Time savings là real, nhưng chúng come từ faster iteration, không từ skipping steps. Bạn vẫn cần plan, test, và debug. Bạn chỉ làm nó faster vì code generation step gần như instant.

Common Patterns và Anti-Patterns

Sau dozens sessions, tôi identified patterns consistently lead tới good outcomes và anti-patterns thất lãng phí time. Đây là chúng trong một format bạn có thể quickly reference:

Patterns That Work

Scaffold-Then-Refine pattern. Hỏi Claude generate structure đầy đủ trước, thậm chí nếu nó rough. Sau đó iterate trên individual sections. Điều này faster hơn trying để get perfection trên first pass.

Step 1: "Tạo full component với tất cả sections
        tôi described. Đừng worry về edge cases yet."

Step 2: "Bây giờ chúng ta improve error handling
        trong form submission section."

Step 3: "Thêm loading states vào submit button
        và results display."

Show-Me-Your-Thinking pattern. Trước khi Claude viết code, hỏi nó explain approach. Điều này catches architectural mistakes trước chúng trở thành code:

Trước khi bạn viết bất kỳ code, giải thích:
1. Approach bạn sẽ take
2. Files bạn sẽ modify
3. Edge cases bạn đang xem xét
4. Assumptions bạn đang make

Tôi caught vài bad assumptions cách này — như Claude assuming API của tôi returned paginated results khi nó thực tế returned mọi thứ trong một response.

Rubber Duck Upgrade pattern. Traditional rubber duck debugging có nghĩa explaining problem của bạn tới một inanimate object. Với Claude, duck nói lại. Và đôi khi nó asks right question:

Me: "Function này returns undefined khi user
     không có permissions."

Claude: "Cái gì nên xảy ra khi user không có
        permissions? Nó nên return empty array,
        throw error, hoặc redirect tới page khác?"

Câu hỏi đó forced tôi think về một flow tôi không designed yet. Bug không ở trong code — nó ở trong requirements.

Anti-Patterns To Avoid

“Fix it” loop. Bạn nói “fix it.” Claude makes change. Nó breaks cái khác. Bạn nói “fix that too.” Claude makes change khác. Nó breaks cái original lại. Điều này happens vì bạn treating symptoms thay vì causes. Break loop bằng stepping back và describing root problem.

Kitchen sink prompt. Hỏi Claude làm quá nhiều thứ cùng lúc:

Tạo user dashboard với charts, thêm authentication,
setup database, viết tests, thêm dark mode, và deploy
lên production.

Điều này produce mediocre results xuyên suốc board. Break nó thành focused sessions.

“Make it better” trap. Vague improvement requests lead tới unpredictable changes:

Bad: "Làm code này tốt hơn."
Good: "Reduce cyclomatic complexity function này
      bằng extracting validation logic vào một
      separate helper function."

Ignoring diff. Claude Code shows bạn exactly cái gì nó changed. Read diff. Mỗi time. Tôi once accepted change mà không reading nó carefully, và Claude helpful “improved” database query của tôi bằng removing WHERE clause filtered deleted records. Tất cả deleted users suddenly reappeared trong admin dashboard.

Khi Nào Không Nên Vibe Code

Vibe coding không luôn là câu trả lời. Đây là situations nơi tôi quay trở lại traditional coding:

Security-critical code. Authentication flows, encryption, permission checks — tôi viết những cái này chính tôi và có chúng reviewed bởi humans. AI-generated security code là một liability cho đến khi bạn verified mỗi line.

Performance-critical hot paths. Khi tôi cần code chạy trong tight loop millions times, tôi muốn hiểu mỗi allocation, mỗi branch, mỗi cache line. AI-generated code optimize cho readability, không performance.

Simple mechanical changes. Nếu tôi cần rename một variable xuyên suốc 3 files, tôi sử dụng IDE’s refactoring tools. Firing up một AI session cho cái này là overkill.

Khi tôi cần để learn. Nếu tôi working với một new technology và muốn deeply hiểu nó, tôi viết code chính tôi. Sử dụng AI generate code cho một technology tôi không hiểu creates knowledge gap sẽ bite tôi later.

Tương Lai Của Vibe Coding

Ba tháng trước, tôi là skeptical. Bây giờ tôi không thể imagine quay lại viết mỗi line code chính tôi.

Nhưng hãy tôi clear về cái gì tôi mean: vibe coding không replace programming skill. Nó amplify nó. Một skilled developer với Claude là dramatically more productive so với hoặc một alone. Nhưng Claude mà không một skilled developer là một code generation machine không judgment — và judgment là cái gì turn code thành software.

Những developers sẽ thrive là không những nào viết most code. Chúng là những nào có thể most effectively direct một AI để viết code đúng, catch mistakes, và biết khi nào để take over keyboard.

Đó là vibe coding. Nó không about vibe. Nó về partnership.

So Sánh AI Pair Programming Với Traditional Pair Programming

Vì tôi đã làm cả hai, hãy tôi draw một fair comparison:

Honest conclusion: AI pair programming không replace human pair programming. Chúng serve different purposes. Tôi vẫn làm human pair programming cho architectural decisions, code reviews, knowledge sharing. Tôi sử dụng AI pair programming cho implementation velocity, research compilation, tedious multi-file changes.

Ideal setup, nếu bạn có luxury, là both: pair với một human decide cái gì build, sau đó pair với Claude build nó.

Quick Reference: Vibe Coding Setup Của Tôi

Cho những ai muốn thử workflow này, đây là setup tôi:

Tools:

• Claude Code (CLI) — primary interface cho pair programming
• Claude Opus 4 — model, selected cho code quality và reasoning
• VS Code — cho manual edits và reviewing diffs
• Astro — static site framework cho blog tôi
• Cloudflare Pages — hosting và CDN
• Git — version control với frequent commits (seriously, commit often)

Project structure:

my-blog/
  src/
    content/
      blog/
        en/       # Bài tiếng Anh
        vi/       # Bài tiếng Việt
    components/   # Astro components
    layouts/      # Page layouts
    pages/        # Route pages
    styles/       # Global styles
  public/
    blog-images/  # SVGs và optimized images
  astro.config.mjs
  package.json

Claude Code configuration:

Tôi sử dụng một .claude/config.json để set project-specific context:

{
  "projectContext": "Astro blog với Cloudflare Pages. Bilingual EN/VI. Sử dụng Tailwind CSS, MDX cho blog posts. Mermaid diagrams phải ASCII-only. Tất cả blog posts cần frontmatter với title, description, pubDate, tags, heroImage, lang, translationRef fields."
}

Project context này được loaded automatically tại start của mỗi session, vì vậy Claude đã biết key constraints trước khi tôi type bất kỳ cái gì.

Metrics Từ Ba Tháng Vibe Coding

Tôi tracked productivity của tôi loosely qua ba tháng vừa qua. Đây là numbers, warts và tất cả:

Sessions tracked: 47 vibe coding sessions

Average session length: 2.1 giờ

Task completion rate trong single session: 78% (22% khác require follow-up session, thường do deployment issues hoặc discovering new requirements mid-build)

Estimated time savings vs manual coding:

• Content creation (blog posts, docs): 60-70% faster
• Feature implementation: 40-50% faster
• Bug debugging: 30-40% faster (nhưng với higher variance — đôi khi AI debugging là slower)
• Configuration và setup: 50-60% faster

Times Claude led tôi down wrong path: 8 out of 47 sessions (17%)

Times tôi learned something mới từ Claude: 31 out of 47 sessions (66%)

Metric cuối cùng surprises people. Hai-phần ba của sessions, Claude showed tôi một pattern, API, hoặc approach tôi không aware. Đôi khi nó small thing — một CSS property tôi chưa bao giờ sử dụng, hoặc một more elegant cách structure async function. Đôi khi nó significant — như introducing tôi tới Cloudflare’s HTMLRewriter API cho edge-side content transformation.

Vibe coding không chỉ về speed. Nó về learning surface area. Khi bạn pair với một AI trained trên vast amount code, bạn encounter patterns và solutions bạn sẽ không bao giờ find chính tôi, đơn giản vì bạn sẽ không bao giờ think để search cho chúng.

Final Thoughts

Nếu bạn nói tôi một năm trước rằng tôi sẽ viết một blog post về pair programming với một AI, tôi sẽ cười. AI tools back then impressive cho demos nhưng frustrating cho real work.

Claude Opus 4 là different. Không vì nó perfect — nó không. Nhưng vì nó tốt đủ để genuinely useful, và nó getting better tại một pace makes tôi think về development sẽ trông như thế nào trong hai năm.

Cho bây giờ, vibe coding là một skill. Giống như skill bất kỳ, nó takes practice. Bạn cần học làm thế nào prompt effectively, khi nào trust AI’s judgment và khi nào override nó, how để structure sessions cho maximum productivity.

Nhưng payoff là real. Tôi shipping features faster, writing comprehensive documentation, maintaining higher consistency xuyên suốc codebase, spending less time trên parts của programming tôi find tedious.

Code vẫn cần correct. Architecture vẫn cần sound. User experience vẫn cần thoughtful. AI không change bất kỳ cái đó.

Nó chỉ có nghĩa tôi spend more thời gian trên parts quan trọng — và less time typing.

Thuan Luong là một Tech Lead ở Việt Nam, xây dựng web applications và writing về intersection của AI và practical software development. Bạn có thể tìm thấy bilingual blog của anh tại thuanluong.com.

Bài viết này, vâng, được viết với help của Claude. Nhưng mỗi technical claim đã được verified, mỗi ví dụ là real, observations hoàn toàn là của tôi. Irony của viết về vibe coding sử dụng vibe coding không được tôi mất.