AI Coding đang thay đổi cách chúng ta xây dựng phần mềm. Thay vì mất hàng giờ để viết boilerplate, sửa bug nhỏ, tạo component hoặc refactor code, lập trình viên giờ có thể nhờ AI hỗ trợ gần như tức thì.

Nhưng có một vấn đề lớn: AI có thể viết code rất nhanh, nhưng không có nghĩa là code đó đã sẵn sàng để release.

Nếu chỉ prompt kiểu “hãy code tính năng này”, AI thường sẽ làm được bản đầu tiên. Nhưng bản đó có thể gặp nhiều vấn đề: UI mỗi màn một kiểu, component khó bảo trì, thiếu test, chưa xử lý edge case, performance chưa tốt, hoặc thậm chí có rủi ro bảo mật.

Vì vậy, khi làm việc với AI Coding, điều quan trọng không chỉ là “prompt thế nào để AI code nhanh hơn”, mà là:

Làm sao để AI làm việc theo một quy trình đủ chặt chẽ, giống một lập trình viên có kinh nghiệm?

Bài viết này chia sẻ một workflow thực tế để dùng AI Coding hiệu quả hơn: giữ UI nhất quán, code sạch hơn và giảm rủi ro trước khi release.

1. Đừng bắt AI code ngay: hãy bắt AI hiểu trước

Sai lầm phổ biến nhất khi dùng AI Coding là đưa yêu cầu rồi bảo AI code ngay.

Ví dụ:

Hãy tạo màn hình quản lý đơn hàng.

Nghe thì rõ, nhưng thực ra yêu cầu này còn thiếu rất nhiều thông tin:

• Màn hình này dành cho ai?
• Có những trạng thái nào?
• Dữ liệu lấy từ đâu?
• Có phân quyền không?
• Có trạng thái loading, empty, error không?
• UI đang theo design system nào?
• Tính năng này ảnh hưởng đến file nào?
• Có cần test không?

Nếu AI không hiểu đủ bối cảnh, nó sẽ tự đoán. Và khi AI tự đoán quá nhiều, code sinh ra thường khó kiểm soát.

Vì vậy, bước đầu tiên nên là yêu cầu AI làm rõ:

Trước khi code, hãy đọc code hiện có và tóm tắt lại:
1. Requirement chính là gì?
2. Những assumption bạn đang đưa ra là gì?
3. Những file hoặc module nào có thể bị ảnh hưởng?
4. Có edge case nào cần chú ý?
5. Kế hoạch implement ngắn gọn là gì?

Mục tiêu không phải là làm quy trình phức tạp hơn. Mục tiêu là tránh việc AI viết code dựa trên hiểu nhầm.

Một AI coding assistant tốt không nên chỉ là “máy sinh code”. Nó nên hoạt động như một pair programmer: hiểu vấn đề, đề xuất hướng đi, rồi mới implement.

2. Muốn UI nhất quán, cần có design system hoặc rule rõ ràng

Một trong những lỗi dễ thấy nhất khi dùng AI để làm frontend là UI thiếu nhất quán.

Mỗi lần bạn nhờ AI tạo một component mới, nó có thể tự chọn spacing, font size, border radius, shadow, màu sắc hoặc layout khác nhau. Kết quả là sau vài ngày, sản phẩm trông như được ghép từ nhiều style khác nhau.

Để tránh điều này, hãy yêu cầu AI luôn tuân theo design system.

Nếu project đã có design system, hãy bắt AI đọc trước:

Trước khi tạo UI mới, hãy kiểm tra design system, component library và các màn hình tương tự trong project. Không tự tạo style mới nếu đã có pattern hiện hữu.

Nếu project chưa có design system, ít nhất nên tạo một file hướng dẫn tối giản, ví dụ:

design-system.md

## Typography
- Heading: dùng font size, weight và line-height thống nhất
- Body text: ưu tiên dễ đọc, không dùng quá nhiều kích cỡ chữ

## Spacing
- Dùng spacing scale cố định: 4, 8, 12, 16, 24, 32px
- Không dùng margin/padding tùy tiện

## Colors
- Dùng token màu có sẵn
- Không hard-code màu mới nếu không có lý do rõ ràng

## Components
- Button, Card, Input, Modal, Table phải tái sử dụng component hiện có
- Luôn xử lý loading, empty, error state

## Responsive
- UI phải hoạt động tốt trên mobile, tablet và desktop

Design system không cần quá phức tạp ngay từ đầu. Nhưng phải có một nguồn sự thật để AI bám vào.

Nếu không có rule, AI sẽ “sáng tạo”. Nếu có rule, AI sẽ “tuân thủ”.

3. Dùng skill hoặc project instruction để AI làm việc theo quy trình

Các công cụ AI Coding ngày nay thường hỗ trợ custom instruction, project rule, skill, agent instruction hoặc file hướng dẫn trong repo.

Bạn có thể dùng các cơ chế này để ép AI đi theo quy trình làm việc nhất quán.

Ví dụ, thay vì mỗi lần đều phải prompt dài, bạn có thể tạo một file như:

• AGENTS.md
• CLAUDE.md
• .cursor/rules/ai-coding-workflow.mdc
• .windsurfrules
• .github/copilot-instructions.md

Trong đó ghi rõ cách AI phải làm việc với project.

Một workflow cơ bản có thể như sau:

AI Coding Workflow

1. Understand
- Đọc requirement, code liên quan và convention hiện có.
- Tóm tắt lại vấn đề, assumption và edge case.

2. Plan
- Đề xuất kế hoạch implement ngắn gọn.
- Nêu rủi ro chính nếu có.

3. Implement
- Giữ thay đổi nhỏ, dễ review.
- Tuân thủ architecture, naming convention và design system.

4. Verify
- Chạy lint, typecheck, test và build nếu project hỗ trợ.
- Nếu không chạy được, nói rõ lý do và đưa command để người dùng tự chạy.

5. Review
- Review diff cuối cùng theo correctness, security, performance, clean code, architecture, accessibility và UI/UX.

6. Release Decision
- Kết luận: Ship / Ship with caution / Do not ship.
- Nêu blocker, non-blocking issue, manual QA và rollback plan.

Điểm quan trọng ở đây là: đừng chỉ dùng AI bằng prompt rời rạc. Hãy đưa AI vào một quy trình cố định.

Prompt tốt giúp AI trả lời tốt trong một lần.
Workflow tốt giúp AI làm việc ổn định qua nhiều lần.

4. Code xong chưa đủ: phải có bước verify

AI rất dễ nói rằng code đã ổn. Nhưng “ổn” không nên chỉ là cảm giác.

Sau khi AI implement, hãy yêu cầu nó chạy các bước kiểm chứng có thể có:

Sau khi code xong, hãy chạy các command phù hợp:
- lint
- typecheck
- unit test
- integration test nếu có
- build

Nếu command nào không chạy được, hãy giải thích lý do, không được giả vờ là đã chạy.

Đây là bước cực kỳ quan trọng.

Với project JavaScript/TypeScript, có thể là:

npm run lint
npm run typecheck
npm test
npm run build

Với project Python, có thể là:

ruff check .
pytest
mypy .

Với project backend, có thể cần thêm migration check, API test hoặc contract test.

Điểm cần nhớ: AI không nên chỉ viết code. AI phải giúp bạn kiểm chứng code.

Nếu không có bước verify, bạn chỉ mới có “code được sinh ra”.
Nếu có verify, bạn mới bắt đầu có “code có thể tin cậy hơn”.

5. Review code theo checklist rõ ràng

Sau khi code chạy được, vẫn cần review.

Nhưng thay vì bảo AI “review code giúp tôi”, hãy đưa tiêu chí cụ thể.

Một checklist tốt nên gồm:

Correctness

Code có giải đúng requirement không? Có bỏ sót trường hợp nào không?

Security

Có lộ dữ liệu nhạy cảm không? Có kiểm tra permission không? Có validate input không?

Performance

Có query thừa không? Có render lại quá nhiều không? Có xử lý dữ liệu lớn kém không?

Clean code

Code có dễ đọc không? Có đặt tên rõ không? Có logic bị lặp không?

Clean architecture

Code có đặt đúng layer không? Component có ôm quá nhiều trách nhiệm không? Business logic có bị nhét vào UI không?

UI/UX

Giao diện có nhất quán không? Có loading, empty, error state không? Có responsive không?

Accessibility

Có dùng label, keyboard navigation, focus state, contrast phù hợp không?

Testability

Logic có dễ test không? Có test cho case quan trọng không?

Maintainability

Người khác đọc code sau 3 tháng có hiểu không? Tính năng này có dễ mở rộng không?

Khi review, nên yêu cầu AI review chính diff vừa thay đổi, không review chung chung.

Prompt có thể dùng:

Hãy review final diff theo các tiêu chí:
1. Correctness
2. Security
3. Performance
4. Clean code
5. Clean architecture
6. UI/UX consistency
7. Accessibility
8. Testability
9. Maintainability

Với mỗi vấn đề, hãy ghi:
- Mức độ: blocker / major / minor
- Vị trí code liên quan
- Vì sao đây là vấn đề
- Cách sửa đề xuất

Review tốt không chỉ nói “code ổn”. Review tốt phải chỉ ra rủi ro, mức độ nghiêm trọng và hướng xử lý.

6. Trước khi release, hãy bắt AI đưa ra release decision

Một câu hỏi rất hữu ích ở cuối session là:

Code này release được chưa?

Nhưng để tránh câu trả lời cảm tính, hãy yêu cầu AI trả lời theo format cố định:

Đưa ra release decision:

- Recommendation: Ship / Ship with caution / Do not ship
- Blockers:
- Non-blocking issues:
- Required manual QA:
- Rollback plan:
- Confidence: High / Medium / Low
- Lý do:

Ví dụ:

Recommendation: Ship with caution

Blockers:
- Không có blocker nghiêm trọng.

Non-blocking issues:
- Chưa có test cho empty state.
- Cần QA thêm trên mobile viewport.

Required manual QA:
- Kiểm tra flow tạo đơn hàng.
- Kiểm tra trạng thái loading/error.
- Kiểm tra responsive trên mobile.

Rollback plan:
- Revert pull request này nếu phát hiện lỗi trong production.
- Feature có thể tắt qua flag order-management-v2.

Confidence: Medium
Lý do: Build pass, logic chính ổn, nhưng coverage cho edge case còn thiếu.

Cách này giúp bạn biến AI thành một reviewer có trách nhiệm hơn.

Nó cũng giúp team ra quyết định rõ ràng: ship ngay, ship có điều kiện, hay chưa nên ship.

7. Dùng AI để học lại những gì vừa làm

Một điểm rất mạnh nhưng ít người tận dụng: sau khi AI code xong, hãy yêu cầu nó dạy lại.

Không chỉ hỏi “bạn đã làm gì?”, mà hãy bắt AI giải thích theo nhiều tầng:

• Vấn đề ban đầu là gì?
• Vì sao vấn đề đó tồn tại?
• Có những hướng giải quyết nào?
• Vì sao chọn hướng này?
• Code mới hoạt động ra sao?
• Có edge case nào?
• Thay đổi này ảnh hưởng đến phần nào của hệ thống?
• Nếu sau này cần mở rộng thì nên chú ý gì?

Bạn có thể dùng prompt:

Hãy giải thích lại bằng tiếng Việt như một mentor giàu kinh nghiệm.

Mục tiêu là giúp tôi hiểu sâu:
1. Vấn đề ban đầu là gì và vì sao nó xảy ra?
2. Giải pháp là gì và vì sao chọn cách này?
3. Có edge case nào?
4. Có tradeoff nào?
5. Thay đổi này ảnh hưởng đến hệ thống ra sao?

Sau đó tạo checklist những gì tôi cần hiểu và hỏi tôi 3-5 câu để kiểm tra.

Việc này đặc biệt hữu ích nếu bạn đang học code, onboarding vào project mới, hoặc muốn hiểu sâu hơn về business logic.

AI Coding không chỉ giúp bạn làm nhanh hơn. Nếu dùng đúng, nó còn giúp bạn học nhanh hơn.

8. Custom Instruction nên dùng thế nào?

Không nên nhét toàn bộ workflow dài vào custom instruction.

Custom instruction nên ngắn, chỉ chứa nguyên tắc cố định. Ví dụ:

When helping me with coding, follow a structured workflow:

1. Understand the requirement and restate assumptions.
2. Inspect existing code conventions before changing anything.
3. Plan briefly before implementation.
4. Implement small, reviewable changes.
5. Verify with available lint, typecheck, tests, and build commands.
6. Review the final diff for correctness, security, performance, clean code, architecture, accessibility, UI/UX, and maintainability.
7. End with a release recommendation: Ship / Ship with caution / Do not ship.
8. When I ask to learn, explain the problem, solution, edge cases, tradeoffs, and quiz me in Vietnamese.

Còn bản đầy đủ nên đặt trong project instruction hoặc repo file.

Lý do là mỗi project có context khác nhau: tech stack khác, command khác, architecture khác, design system khác. Workflow chi tiết nên đi cùng repo, không nên chỉ nằm trong custom instruction chung.

9. Một mẫu workflow hoàn chỉnh để áp dụng ngay

Bạn có thể copy mẫu này vào AGENTS.md, CLAUDE.md, Cursor Rules hoặc công cụ AI Coding bạn đang dùng:

# AI Coding Workflow Guideline

## 1. Understand
Before coding:
- Read the relevant files.
- Identify existing conventions, architecture, and design system.
- Restate the requirement.
- List assumptions.
- Identify affected files/modules.
- Identify edge cases and risks.

## 2. Plan
Before implementation:
- Propose a short implementation plan.
- Keep the plan practical and minimal.
- Mention security, performance, UX, or migration risks if relevant.

## 3. Implement
While coding:
- Follow existing architecture and naming conventions.
- Reuse existing components and utilities.
- Follow the design system.
- Keep changes small and reviewable.
- Avoid unnecessary abstractions.
- Do not introduce new dependencies unless justified.

## 4. Verify
After implementation:
- Run available checks: lint, typecheck, test, build.
- Add or update tests for changed logic.
- If a check cannot be run, explain why and provide the exact command for the human to run.

## 5. Review
Review the final diff against:
- Correctness
- Security
- Performance
- Clean code
- Clean architecture
- Accessibility
- UI/UX consistency
- Testability
- Maintainability
- Release risk

For each issue, include:
- Severity: blocker / major / minor
- Location
- Explanation
- Suggested fix

## 6. Release Decision
End with:
- Recommendation: Ship / Ship with caution / Do not ship
- Blockers
- Non-blocking issues
- Required manual QA
- Rollback plan
- Confidence: High / Medium / Low

## 7. Teach Back
When requested, explain in Vietnamese:
- The original problem and why it existed
- The solution and why it was chosen
- Edge cases and tradeoffs
- Broader system impact

End with:
- A checklist of what the human should understand
- 3-5 questions to verify understanding

Kết luận

AI Coding không còn là chuyện tương lai. Nó đã trở thành một phần trong workflow phát triển phần mềm hằng ngày.

Nhưng để dùng AI hiệu quả, chúng ta cần thay đổi cách nghĩ.

Đừng chỉ hỏi:

Prompt thế nào để AI code nhanh hơn?

Hãy hỏi:

Quy trình nào giúp AI code đáng tin hơn?

Một AI coding assistant tốt cần được đặt vào một workflow rõ ràng:

• Hiểu vấn đề trước khi code
• Tuân thủ design system
• Implement theo convention của project
• Chạy lint, test, build
• Review theo checklist cụ thể
• Đưa ra release decision
• Dạy lại để con người hiểu sâu hơn

Khi đó, AI không chỉ là công cụ sinh code. Nó trở thành một pair programmer, reviewer và mentor.

Và đó mới là cách dùng AI Coding bền vững: không chỉ nhanh hơn, mà còn sạch hơn, nhất quán hơn và an toàn hơn khi release.

Các skills dùng cho AI Agentic Coding:
– https://github.com/kientv/agent-coding-skill
– https://github.com/obra/superpowers
– https://github.com/gsd-build/get-shit-done
– https://github.com/leonxlnx/taste-skill