Một Tháng Vibe Coding Với Claude Code: Vai Trò Mới, Triết Lý Mới
Điểm nổi bật
Nhấn để đến mục tương ứng
- 1 Nếu không đúng hướng, clarify và re-run Trade-off mà Morten thẳng thắn thừa nhận: Giải thích rõ ràng what/where/how — yêu cầu gì, ở file nào, theo pattern nào Let Claude implement: Bây giờ anh describe, approve, và review .
- 2 Từ 1 tháng kinh nghiệm thực tế của Morten: Start với một task nhỏ, quen với review workflow, và học khi nào Claude excellent vs khi nào cần guidance nhiều hơn. cách describe task, cách review output, khi nào dùng 2-phase planning.
- 3 Sau 1 tháng commit toàn bộ vào "vibe coding" với Claude Code, anh ghi lại những gì thực sự thay đổi và những gì không. Anh không phải người dễ bị impressed bởi hype. vai trò của anh đã thay đổi fundamentally.
- 4 Sau 1 tháng iterate, Morten thống nhất với workflow 2 phase: Flag bất kỳ assumption nào bạn đang make 5. Highlight risks Save plan vào TASK.md và đợi approval." Morten review TASK.md. "Trước khi implement, hãy tạo detailed plan cho feature này:.
- 5 Khi sub-task lớn hơn, review quality giảm — bạn bắt đầu skim thay vì đọc. Insight quan trọng từ 1 tháng kinh nghiệm: break features thành sub-tasks nhỏ hơn 500 lines . Database schema changes (migrations) — 50 lines 2.
Từ Programmer Sang Code Reviewer — Một Tháng Thay Đổi
Morten Vistisen là senior software engineer. Anh không phải người dễ bị impressed bởi hype. Sau 1 tháng commit toàn bộ vào "vibe coding" với Claude Code, anh ghi lại những gì thực sự thay đổi và những gì không.
Phát hiện lớn nhất: vai trò của anh đã thay đổi fundamentally.
"The code is no longer yours, BUT it's still your responsibility to ensure that whatever goes into master is of high enough quality."
Đây không phải là bad news — nhưng là sự thay đổi cần được thừa nhận và chuẩn bị.
Vai Trò Mới: Part Code Reviewer, Part Product Manager
Trước Claude Code, Morten code. Bây giờ anh describe, approve, và review. Công việc mỗi ngày:
- Describe: Giải thích rõ ràng what/where/how — yêu cầu gì, ở file nào, theo pattern nào
- Let Claude implement: Không micromanage từng dòng code
- Review: Đọc kỹ mọi thay đổi trước khi merge
- Approve hoặc redirect: Nếu không đúng hướng, clarify và re-run
Trade-off mà Morten thẳng thắn thừa nhận: nhiều code reviews hơn (và anh không thích code review). Nhưng đổi lại: products ship nhanh hơn đáng kể.
PM angle xuất hiện vì Morten không chỉ review code — anh cần suy nghĩ về product: sequence of features đúng không? Architecture có hold up không khi scale? User experience có coherent không?
Framework 2 Phase: Plan Trước, Code Sau
Sau 1 tháng iterate, Morten thống nhất với workflow 2 phase:
Phase 1: Planning
Prompt: "Trước khi implement, hãy tạo detailed plan cho feature này:
1. List tất cả files cần modify
2. Describe approach cho mỗi thay đổi
3. Identify dependencies và potential conflicts
4. Flag bất kỳ assumption nào bạn đang make
5. Highlight risks
Save plan vào TASK.md và đợi approval."
Morten review TASK.md. Nếu plan tốt, approve. Nếu có vấn đề, clarify ngay — trước khi mất thời gian implement wrong thing.
Phase 2: Implementation
Sau approval, Claude implement với fresh context (đọc TASK.md để hiểu scope). Tại sao fresh context? Tránh "drift" từ planning conversation. Implementation agent nên focused vào execution, không bị distracted bởi exploration history.
Kết quả: cleaner implementation, ít "we discussed this earlier" confusion, và dễ reset nếu implementation đi sai hướng.
Sub-Task Decomposition: 500 Lines Rule
Insight quan trọng từ 1 tháng kinh nghiệm: break features thành sub-tasks nhỏ hơn 500 lines.
Tại sao 500 lines? Đủ để có meaningful progress, nhỏ đủ để review kỹ. Khi sub-task lớn hơn, review quality giảm — bạn bắt đầu skim thay vì đọc.
Pattern thực tế:
Large feature: "Add OAuth authentication"
Sub-tasks:
1. Database schema changes (migrations) — ~50 lines
2. OAuth provider configuration — ~100 lines
3. Token validation middleware — ~150 lines
4. API endpoints cho auth flow — ~200 lines
5. Frontend OAuth buttons — ~100 lines
6. Tests cho mỗi component — ~300 lines total
Mỗi sub-task có context từ previous sub-tasks (provided as summary), tránh context window overflow.
Quality Trực Tiếp Phụ Thuộc Vào Planning Quality
Morten nhấn mạnh điều này nhiều lần, với nhiều ví dụ. Không phải một observation ngẫu nhiên — đây là pattern consistent nhất sau 1 tháng:
"Claude code is great at following instructions. The quality of what you get out is directly correlated to the quality of what you put in."
Vague instruction → vague code. Specific, well-thought-out instruction → specific, well-implemented code.
Điều này không khác gì khi làm việc với junior developer — nhưng với Claude, gap giữa good instruction và vague instruction thể hiện rõ hơn và faster.
Triết Lý Không Đổi: Make It Work, Make It Fast, Make It Pretty
Đây là quote mà nhiều developer resonates với:
"Remember mbv, make it work, make it fast, make it pretty. And always in that order. With claude, I feel like I make it through the loop faster."
Triết lý này — được dùng trong software engineering từ lâu — vẫn hoàn toàn valid với vibe coding. Thực ra Claude Code làm cho nó dễ apply hơn:
- Make it work: Claude implement nhanh. Bạn có prototype nhanh để test hypothesis về architecture.
- Make it fast: Sau khi working, bạn có thể ask Claude identify bottlenecks và optimize.
- Make it pretty: Refactoring với Claude — clean up code, better naming, better structure.
Loop chạy nhanh hơn, nhưng order không thay đổi. Cố optimize too early hay polish too early vẫn là premature optimization.
Multi-Project Productivity Boost
Một benefit ít ai nhắc đến: khả năng làm việc trên nhiều projects đồng thời tốt hơn.
Trước đây: context switch giữa projects tốn cognitive cost lớn — cần "load" codebase vào đầu.
Bây giờ: Morten describe task, Claude code. Trong khi Claude implement project A, Morten review project B. Context switch ít tốn kém hơn vì Claude giữ technical context, Morten chỉ cần giữ product context.
Ai Thắng: Expert Hay Novice?
Morten address trực tiếp câu hỏi nhiều người sợ hỏi: liệu developer không có kinh nghiệm có thể vibe code ra sản phẩm tốt như senior developer không?
Câu trả lời của anh, được minh họa bằng hai historical parallels:
WordPress parallel: WordPress democratize web development. Thay vì ít web developer, có nhiều hơn vì accessibility tăng demand. Chất lượng vẫn distributed theo expertise.
Expertise amplification: Expert wielding Claude Code vẫn outperforms novice wielding Claude Code. Vì:
- Expert biết cách break down problems
- Expert biết khi nào code là wrong
- Expert biết trade-offs của architecture decisions
- Expert biết khi nào Claude đang hallucinate về technical details
AI là force multiplier — nó amplifies existing capability, không substitute for it. Xem thêm: Autonomous Coding Agent — AI tự viết code từ spec.
Recommendations Cho Developer Muốn Bắt Đầu
Từ 1 tháng kinh nghiệm thực tế của Morten:
Tuần 1: Learn Các Giới Hạn
Đừng cố dùng Claude Code cho mọi thứ ngay. Start với một task nhỏ, quen với review workflow, và học khi nào Claude excellent vs khi nào cần guidance nhiều hơn.
Tuần 2-3: Build Workflow
Develop personal patterns: cách describe task, cách review output, khi nào dùng 2-phase planning. Không có workflow universal — mỗi developer cần find what works for them.
Tuần 4: Optimize
Sau khi có workflow, tìm bottlenecks. Thường là: planning quality, review thoroughness, hay context management.
Setup đề xuất ban đầu: CLAUDE.md Masterclass để cấu hình workspace đúng từ đầu.
Kết Luận: Faster Loop, Same Principles
Sau 1 tháng, Morten không sợ bị replaced. Anh cũng không phải người với output giảm — ngược lại. Nhưng anh đã thay đổi cách làm việc.
Người thắng trong kỷ nguyên vibe coding không phải người biết nhiều syntax nhất — mà là người biết rõ ràng nhất điều họ muốn build và tại sao. Những kỹ năng đó không bị obsolete bởi AI.
Make it work, make it fast, make it pretty. Luôn theo thứ tự đó. Với Claude Code, bạn đi qua loop nhanh hơn. Nhưng bạn vẫn là người quyết định loop đó có đáng chạy không.
Nguồn tham khảo
Bài viết dựa trên: Learnings From Vibe Coding With Claude Code For 1 Month — Morten Vistisen.
Bai viet co huu ich khong?
Bản quyền thuộc về tác giả. Vui lòng dẫn nguồn khi chia sẻ.







