Nếu bạn không phải developer, Claude Artifacts là chỗ bắt đầu đúng. Bạn mô tả một workflow, Claude dựng ra UI, bạn bấm thử, sửa copy, đổi layout, thêm màn hình. Không cần terminal. Không cần biết repo là gì. Không cần hiểu npm install.
Vấn đề bắt đầu khi prototype nhìn giống app thật quá. Bạn thấy form chạy được, bảng dữ liệu có vẻ ổn, nút save cũng phản hồi. Rất dễ nghĩ: “Vậy đưa vào sản phẩm luôn được chưa?”
Thường là chưa.
Artifacts phù hợp để chứng minh ý tưởng. Claude Code phù hợp khi ý tưởng đó phải chạm codebase thật. Hai việc này nhìn gần nhau nhưng rủi ro khác hẳn.
Artifacts giải quyết phần nhìn thấy
Artifacts mạnh ở vòng đầu của vibe coding: biến mô tả mơ hồ thành thứ nhìn và bấm được.
Bạn có thể dùng nó để trả lời các câu hỏi như:
- Người dùng đi từ màn hình A sang B có hợp lý không?
- Form có cần ba bước hay một bước là đủ?
- Dashboard nên ưu tiên số liệu nào?
- Text trên nút có dễ hiểu không?
- Flow có bị thiếu trạng thái empty, loading, error không?
Đây là tầng product thinking. Người non-tech làm rất tốt tầng này vì họ hiểu khách hàng, quy trình vận hành, logic nghiệp vụ. Developer giỏi code nhưng không tự nhiên biết khách hàng của bạn muốn gì.
Artifacts cũng rất hợp để đi họp. Thay vì gửi một file requirement dài 6 trang, bạn mở prototype, bấm qua flow, hỏi team: “Chỗ này đúng chưa?” Feedback sẽ cụ thể hơn nhiều.
Nhưng artifact vẫn là prototype. Nó có thể dùng sample data. Nó có thể giả lập API. Nó có thể bỏ qua auth, role, permission, database, logging, deployment. Những thứ đó không hiện rõ trên màn hình nhưng quyết định app có sống được không.
Claude Code giải quyết phần nằm trong repo
Claude Code khác Artifacts ở chỗ nó làm việc trong project thật. Nó đọc file thật, sửa file thật, chạy command thật, xem test thật, tạo diff thật. Nếu repo dùng React, Astro, Rails, Laravel, Next.js hay bất kỳ framework nào, Claude Code phải đi theo cấu trúc repo đó.
Bạn nên nghĩ Claude Code như một developer assistant trong terminal, không phải canvas demo. Nó hữu ích khi task cần:
- Sửa component đang tồn tại trong repo.
- Nối UI vào API thật.
- Chạy test hoặc build hiện có.
- Tìm route, hook, helper, schema trong codebase.
- Tạo branch, chuẩn bị diff, mở PR nếu workflow team cần.
- Đọc lỗi build và sửa theo convention của project.
Điểm quan trọng: Claude Code có quyền gây thay đổi thật. Một artifact sai thì bạn đóng tab. Một edit sai trong repo có thể làm build fail, thay đổi behavior cũ, hoặc lộ secret nếu bạn review kém.
Vì vậy non-tech không nên nhảy vào Claude Code chỉ vì prototype đã đẹp. Hãy chuyển khi có tín hiệu rõ.
Tín hiệu nên chuyển
Tín hiệu đầu tiên: prototype cần backend. Nếu app chỉ là calculator, checklist, mock dashboard nhỏ, Artifacts có thể đủ cho vòng demo. Nếu app cần lưu dữ liệu, đọc database, phân quyền, gửi email, gọi webhook, hoặc xử lý file upload, đã đến lúc repo thật phải tham gia.
Tín hiệu thứ hai: cần auth. Login, role admin/user, invite team, reset password, session timeout, permission theo tổ chức. Đây là vùng không nên “vibe” bằng cảm giác. Auth sai là lỗi bảo mật, không chỉ lỗi UI.
Tín hiệu thứ ba: cần API thật. Sample data làm prototype trông mượt, nhưng sản phẩm thật phải chịu dữ liệu xấu: field rỗng, list dài, số âm, trạng thái bị hủy, timezone lệch, API chậm, API fail. Claude Code có thể đọc existing hook hoặc endpoint trong repo để nối đúng thay vì invent endpoint mới.
Tín hiệu thứ tư: có deployment. Nếu app phải lên staging, production, domain thật, Cloudflare, Vercel, S3, Docker, database migration, đừng xử lý như prototype. Cần review kỹ command nào được chạy, command nào phải hỏi dev.
Tín hiệu thứ năm: có payment hoặc dữ liệu khách hàng. Stripe, invoice, subscription, PII, health data, financial data, customer database. Ở đây non-tech có thể chuẩn bị requirement và test checklist, nhưng nên có developer supervise trước khi merge.
Tín hiệu thứ sáu: app phải sống trong codebase đang tồn tại. Nếu công ty đã có repo, design system, API contract, naming convention, i18n, logging, analytics, thì artifact code không phải source of truth. Source of truth là repo.
Chuẩn bị gì trước khi mở Claude Code
Đừng mở Claude Code rồi gõ: “build cái này vào app”. Prompt đó bắt model đoán quá nhiều.
Trước khi chuyển, gom một handoff pack ngắn:
- Screenshot của artifact, gồm happy path và các trạng thái phụ.
- Mô tả flow bằng ngôn ngữ nghiệp vụ, không cần framework.
- Acceptance checklist: làm xong thì bạn sẽ test những gì.
- Sample data thật hoặc gần thật, đã xóa thông tin nhạy cảm.
- Danh sách thứ không được chạm: payment, production deploy, customer data, config secret.
- Open questions: những điểm bạn chưa chắc cần dev quyết.
Ví dụ acceptance checklist tốt:
1. User mở trang booking detail từ dashboard.
2. User thấy status, customer name, service, date, price.
3. Nếu booking bị cancel, nút "Confirm" không hiện.
4. Nếu API loading, trang không nhảy layout.
5. Mobile 390px vẫn đọc được thông tin chính.Checklist này giúp Claude Code làm việc như đang implement requirement, không phải đoán từ hình.
Câu đầu tiên nên nói với Claude Code
Với non-tech, câu đầu tiên không nên là “edit file”. Câu đầu tiên nên là đọc repo.
Bạn đang ở project root. Hãy đọc cấu trúc repo và giải thích bằng tiếng Việt:
feature booking detail hiện nằm ở đâu, UI component liên quan là file nào,
API/hook nào đang được dùng, và nếu implement prototype trong folder này
thì bạn sẽ chạm những file nào. Chưa sửa file.Sau đó mới yêu cầu plan:
Viết plan ngắn trước khi sửa. Plan cần liệt kê file sẽ sửa,
lý do sửa từng file, command test/build hiện có sẽ chạy,
và rủi ro cần tôi approve. Chưa edit file cho đến khi tôi đồng ý.Đây là cách dùng Claude Code có kiểm soát. Bạn không cần hiểu từng dòng code, nhưng bạn cần biết nó định chạm vùng nào.
Khi nào cần developer supervise
Nếu task chỉ đổi text, layout nhỏ, thêm empty state trong một component rõ ràng, non-tech có thể dùng Claude Code với plan mode và review diff cẩn thận.
Nhưng hãy kéo developer vào khi thấy một trong các dấu hiệu này:
- Claude Code muốn sửa auth, payment, database migration, hoặc permission.
- Nó muốn thêm dependency mới.
- Nó muốn tạo endpoint mới thay vì dùng endpoint có sẵn.
- Nó muốn chạy deploy command.
- Diff chạm nhiều file bạn không hiểu.
- Nó nói “test pass” nhưng bạn không thấy command và output rõ.
- Nó sửa unrelated file.
Developer không cần viết lại từ đầu. Họ có thể review plan, review diff, chỉ ra file đúng, rồi để Claude Code tiếp tục trong phạm vi an toàn hơn.
Đừng paste artifact code vào production như default
Một lỗi phổ biến: thấy artifact chạy được, copy code vào repo. Có lúc làm được, nhưng không nên coi đó là đường mặc định.
Artifact code được tạo cho demo context. Repo thật có routing, state management, API layer, design tokens, validation, error handling, lint rule, test rule. Cùng một UI nhưng implementation có thể phải viết lại để fit project.
Cách đúng hơn: dùng artifact làm behavior reference. Nói với Claude Code:
Đừng paste nguyên artifact code. Hãy map behavior này vào component,
route, API hook, style convention hiện có trong repo.
Nếu có đoạn nào không fit, giải thích trước khi sửa.Vibe coding có kiểm soát không có nghĩa là chậm. Nó có nghĩa là biết lúc nào đang demo, lúc nào đang chạm sản phẩm thật.