AI Coding, Mobile & Web Development – Cách làm việc hiệu quả với AI trong phát triển phần mềm
AI đang thay đổi cách phần mềm được tạo ra.Trước đây, developer thường phải tự:
- đọc tài liệu;
- thiết kế kiến trúc;
- viết từng file;
- debug;
- viết test;
- tối ưu;
- triển khai;
- rồi tiếp tục sửa lỗi.
AI có thể:
Phân tích yêu cầu
↓
Đề xuất kiến trúc
↓
Tạo project
↓
Viết frontend
↓
Viết backend
↓
Thiết kế database
↓
Viết API
↓
Viết test
↓
Debug
↓
Refactor
↓
Review
↓
Deploy
Nhưng có một điều rất quan trọng:
Cách hiệu quả hơn là:
Người sử dụng AI tốt không nhất thiết phải viết nhiều code hơn.
Nhưng họ phải biết:
Giao việc gì
Giao như thế nào
Chia project ra sao
Kiểm tra ở đâu
Khi nào nên dừng AI
Khi nào phải tự quyết định
Đó mới là kỹ năng cốt lõi của AI Coding.
1. AI Coding thực chất là gì?
AI Coding không chỉ là:Prompt
↓
Code
Mà đúng hơn là:
Human
↓
Requirement
↓
AI
↓
Code
↓
Human Review
↓
Test
↓
AI Fix
↓
Review
↓
Production
AI có thể là:
Pair Programmer
Code Generator
Debugger
Reviewer
Architect Assistant
Test Writer
Documentation Writer
DevOps Assistant
Tuy nhiên, AI không nên mặc định được xem là:
Technical Lead
Security Authority
Product Owner
Final Decision Maker
2. Nguyên tắc quan trọng nhất: Đừng bắt AI xây cả thế giới trong một prompt
Một lỗi rất phổ biến:AI có thể tạo rất nhiều code.
Nhưng kết quả thường:
- kiến trúc không đồng nhất;
- component lặp;
- database thiếu logic;
- API chắp vá;
- security yếu;
- nhiều phần không thực sự hoạt động.
Project
│
├── Authentication
├── User Profile
├── Feed
├── Comment
├── Notification
├── Search
├── Admin
└── Deployment
Sau đó làm từng module.
Đây là nguyên tắc:
3. Quy trình AI Coding tốt nên bắt đầu từ Specification
Đừng bắt đầu bằng:Hãy bắt đầu bằng:
Ví dụ trước khi code một tính năng:
Feature: User Registration
cần xác định:
Input:
- username
- password
Rules:
- email unique
- username unique
- password >= 8 characters
Output:
- user created
- verification email sent
Errors:
- duplicate email
- invalid email
- weak password
AI sẽ viết code tốt hơn rất nhiều nếu yêu cầu rõ.
4. PRD rất hữu ích khi làm việc với AI
PRD:Product Requirements Document
Không cần quá dài.
Một PRD nhỏ có thể gồm:
Goal
Users
Features
User Flow
Business Rules
Technical Constraints
Out of Scope
Ví dụ:
Goal:
Xây ứng dụng quản lý task cho nhóm nhỏ.
Users:
Admin
Member
Features:
Create task
Assign task
Comment
Deadline
Notification
Out of scope:
Video call
File storage
Payment
AI biết rõ:
Cái gì phải làm
và quan trọng không kém:
Cái gì không được làm
5. Luôn xác định Tech Stack trước
Một trong những nguyên nhân khiến project AI Coding trở nên hỗn loạn là AI tự chọn công nghệ khác nhau ở mỗi lần chat.Ví dụ ban đầu:
Next.js
sau đó AI lại thêm:
Express
rồi:
Firebase
rồi:
MongoDB
trong khi project đang dùng PostgreSQL.
Tốt hơn nên xác định từ đầu:
Frontend: Next.js
Backend: NestJS
Database: PostgreSQL
ORM: Prisma
Cache: Redis
Realtime: Socket.IO
CSS: Tailwind
Và yêu cầu:
6. AI rất thích thêm dependency
Đây là một vấn đề đáng chú ý.Bạn yêu cầu:
AI có thể đề xuất thêm một package.
Bạn yêu cầu:
Lại thêm một package.
Kết quả:
Simple Project
↓
150 Dependencies
Mỗi dependency tạo thêm:
Maintenance
Security Risk
Compatibility Risk
Bundle Size
Trước khi thêm package hãy hỏi:
7. Hãy cho AI đọc codebase trước khi sửa
Đừng yêu cầu:khi AI chưa hiểu project.
Một workflow tốt:
Read relevant files
↓
Understand architecture
↓
Explain current flow
↓
Propose change
↓
Modify code
Điều này đặc biệt quan trọng với project lớn.
8. Context là nhiên liệu của AI Coding
AI viết code tốt hay không phụ thuộc rất nhiều vào:Context
Context có thể gồm:
Architecture
Folder Structure
Database Schema
API Contract
Coding Rules
Existing Components
Business Logic
Known Bugs
Nếu thiếu context, AI buộc phải:
Guess
Và càng đoán nhiều:
Bug càng nhiều
9. Tạo file hướng dẫn cho AI trong project
Một cách rất hữu ích là tạo tài liệu dạng:AGENTS.md
CLAUDE.md
CONTRIBUTING.md
PROJECT.md
Trong đó ghi:
Tech stack
Folder structure
Naming conventions
Coding rules
Database rules
Commands
Testing rules
Things AI must not do
Ví dụ:
Do not modify database schema without approval.
Do not add dependencies unless necessary.
Do not change existing APIs without checking consumers.
Always run tests after modifying backend code.
Điều này giúp các phiên AI khác nhau làm việc nhất quán hơn.
10. Một task tốt cho AI phải có phạm vi rõ
Task kém:Task tốt:
On /profile page:
1. Fix avatar upload.
2. Maximum image size 5 MB.
3. Accept JPG, PNG, WebP.
4. Keep existing UI.
5. Do not modify authentication.
6. Add error handling.
7. Run existing tests after change.
Càng rõ:
AI càng ít tự suy diễn
11. Một lần chỉ nên thay đổi một nhóm logic liên quan
Không nên yêu cầu:Fix login
Refactor database
Change UI
Upgrade dependencies
Add notification
trong cùng một lần.
Nếu lỗi xuất hiện sau đó:
Không biết lỗi đến từ đâu
Tốt hơn:
Small change
↓
Test
↓
Commit
↓
Next change
12. Git là bắt buộc khi dùng AI Coding nghiêm túc
AI có thể thay đổi hàng chục file rất nhanh.Do đó Git trở nên cực kỳ quan trọng.
Workflow:
Working version
↓
Git commit
↓
AI change
↓
Review
↓
Test
Nếu AI làm hỏng:
Rollback
Không nên để AI sửa một project quan trọng mà không có version control.
13. Commit nhỏ tốt hơn commit khổng lồ
Ví dụ tốt:feat: add avatar upload
sau đó:
fix: validate avatar file size
sau đó:
test: add avatar upload tests
Tốt hơn:
update project
với 83 file thay đổi.
14. Đừng để AI sửa code ngoài phạm vi
Một coding agent đôi khi có xu hướng:Sau đó sửa thêm hàng chục file.
Nếu task là sửa bug:
Fix bug only
hãy nói rõ:
Điều này giúp giảm:
Regression
15. AI rất mạnh trong code mới, nhưng phải cẩn thận với code cũ
Trong greenfield project:AI
có thể làm rất nhanh.
Nhưng trong legacy project:
AI + thiếu context
có thể rất nguy hiểm.
Vì code cũ thường có:
Hidden Dependencies
Historical Decisions
Workarounds
Backward Compatibility
Một đoạn code nhìn "xấu" chưa chắc nên sửa.
Có thể nó tồn tại vì một lý do AI không biết.
16. Đừng để AI refactor chỉ vì code "trông chưa đẹp"
Một nguyên tắc tốt:Ví dụ:
Reduce duplication
Improve performance
Improve maintainability
Fix security issue
Không nên refactor chỉ vì:
AI nghĩ cách khác đẹp hơn
17. AI có thể hallucinate cả API và framework
AI đôi khi tạo:Function không tồn tại
Package không tồn tại
Option không tồn tại
API endpoint không tồn tại
Vì vậy với library mới:
Check Official Documentation
đặc biệt khi liên quan:
Authentication
Cloud
Payment
Framework Update
AI API
18. Compiler và Test đáng tin hơn lời giải thích của AI
AI có thể nói:Nhưng điều đó không có nghĩa:
It works.
Hãy tin:
Compiler
Tests
Runtime
Logs
hơn:
AI confidence
19. Build phải chạy
Trước khi coi task là hoàn thành:Build
phải chạy được.
Ví dụ:
npm run build
Nếu project TypeScript:
Type checking
cũng cần pass.
20. Linting cũng quan trọng
AI có thể tạo:Unused imports
Wrong types
Dead code
Formatting problems
Do đó:
Lint
nên nằm trong workflow.
21. Test là hàng rào bảo vệ tốt nhất khi để AI sửa code
Một project có test tốt giúp AI Coding an toàn hơn rất nhiều.Ví dụ:
AI changes code
↓
Run tests
↓
30 pass
1 fail
Ta biết ngay:
Something broke
Không có test:
AI changes code
↓
Looks okay
↓
Deploy
rủi ro cao hơn nhiều.
22. Test AI-generated code, đừng chỉ test happy path
Ví dụ login.Happy path:
Correct email
Correct password
Nhưng còn:
Wrong password
Invalid email
Locked account
Deleted account
Expired token
Missing field
AI thường tập trung vào:
Happy Path
Con người cần nghĩ về:
Edge Cases
23. AI rất phù hợp để viết test
Đây là một trong những use case tốt nhất.Có thể yêu cầu:
Analyze this function and create tests for:
- normal input
- empty input
- invalid input
- boundary values
- failure cases
Sau đó developer review lại test.
24. Đừng để AI viết code và test theo cùng một giả định sai
Có một vấn đề:AI viết function sai.
Sau đó AI tự viết test phù hợp với function sai.
Kết quả:
Tests pass
nhưng business logic vẫn sai.
Do đó test nên xuất phát từ:
Requirements
không phải chỉ từ implementation.
25. Mobile Development với AI rất hiệu quả, nhưng có những vấn đề riêng
AI có thể hỗ trợ:Flutter
React Native
Swift
Kotlin
và tạo:
Screens
Navigation
State Management
API Integration
Forms
Local Storage
Push Notifications
rất nhanh.
Tuy nhiên Mobile khác Web ở nhiều điểm.
26. Mobile có nhiều môi trường hơn bạn tưởng
Một app có thể chạy khác nhau trên:Android
iOS
Different OS versions
Different screen sizes
Different devices
Code compile không có nghĩa app hoạt động đúng trên mọi máy.
27. Permission trên Mobile cần kiểm tra kỹ
Ví dụ:Camera
Microphone
Location
Storage
Bluetooth
Notifications
AI có thể thêm permission quá rộng.
Chỉ nên xin:
Permission thực sự cần
và đúng thời điểm.
28. iOS và Android không hoàn toàn giống nhau
Một feature có thể cần:Android implementation
và:
iOS implementation
khác nhau.
Ví dụ:
Push Notifications
Deep Links
Background Tasks
File Access
Payments
Không nên giả định:
Works on Android
=
Works on iOS
29. Mobile App phải test trên thiết bị thật
Emulator rất hữu ích.Nhưng trước release cần test:
Real Android
Real iPhone
đặc biệt:
Camera
Network
Notifications
Keyboard
Battery
Background Mode
30. Store Review cũng là một phần của Mobile Development
Ứng dụng chạy được chưa đủ.App còn phải đáp ứng:
Google Play Policies
Apple App Store Review Guidelines
Privacy
Permissions
Content Rating
Data Safety
AI có thể hỗ trợ chuẩn bị nội dung.
Nhưng developer vẫn phải kiểm tra policy hiện hành.
31. Web Development với AI có lợi thế lớn
Web là môi trường AI Coding phát huy sức mạnh rất tốt.AI có thể xây:
Landing Page
Dashboard
Admin Panel
SaaS
Forum
E-commerce
Realtime App
rất nhanh.
Các framework hiện đại như:
Next.js
React
Vue
Nuxt
Svelte
cũng có lượng tài liệu lớn.
32. Nhưng frontend AI rất dễ tạo "code spaghetti"
AI thường có xu hướng:Component grows
↓
More conditions
↓
More state
↓
More props
Một file ban đầu:
200 lines
có thể nhanh chóng thành:
1,500 lines
Nếu không kiểm soát.
33. Component nên có trách nhiệm rõ
Ví dụ thay vì:UserPage.tsx
chứa tất cả:
Profile
Friends
Posts
Settings
Notifications
nên chia:
ProfileHeader
ProfileInfo
PostList
FriendList
SettingsPanel
Nhưng cũng không nên chia quá mức thành hàng trăm component vô nghĩa.
34. Đừng để AI tạo UI mới nếu Design System đã tồn tại
Nếu project đã có:Button
Modal
Input
Card
Table
AI nên reuse.
Nếu không, project sẽ có:
ButtonA
ButtonB
CustomButton
NewButton
ActionButton
với style khác nhau.
35. Design System rất quan trọng khi AI làm frontend
Hãy định nghĩa:Colors
Spacing
Typography
Buttons
Forms
Cards
Modals
Tables
Breakpoints
Sau đó yêu cầu AI tuân thủ.
Điều này giúp UI nhất quán hơn rất nhiều.
36. Responsive Design phải được yêu cầu rõ
AI thường tạo giao diện:Desktop looks great
nhưng:
Mobile breaks
Hãy yêu cầu test:
Desktop
Tablet
Mobile
37. Accessibility không nên bị bỏ qua
AI-generated frontend cần kiểm tra:Keyboard navigation
Labels
Alt text
Contrast
Semantic HTML
Focus state
ARIA
Đây không chỉ là vấn đề UX.
Nó còn giúp phần mềm phục vụ nhiều người dùng hơn.
38. Performance cũng là trách nhiệm của AI Coding workflow
AI có thể tạo ứng dụng chạy được nhưng rất chậm.Ví dụ:
100 database queries
cho một page.
Hoặc:
Huge frontend bundle
Hoặc tải:
10 MB image
cho thumbnail nhỏ.
39. N+1 Query
Một lỗi backend phổ biến:Get 100 users
↓
For each user
↓
Query database again
Kết quả:
101 queries
AI-generated code cần review vấn đề này.
40. Pagination là thứ AI thường quên
API:GET /users
không nên lúc nào cũng trả:
500,000 users
Nên có:
Pagination
Cursor
Limit
tùy hệ thống.
41. Cache không phải lúc nào cũng cần
AI đôi khi đề xuất:Redis
cho mọi thứ.
Nhưng cache tạo thêm:
Invalidation
Complexity
Consistency Problems
Chỉ dùng khi thực sự có lợi.
42. Đừng tối ưu quá sớm
AI có thể đề xuất:Microservices
Kubernetes
Event Bus
Kafka
cho app mới có 10 người dùng.
Thường:
Simple Architecture
tốt hơn.
43. Monolith không phải điều xấu
Một modular monolith tốt có thể phục vụ rất nhiều sản phẩm.Ví dụ:
One Backend
├── Users
├── Payment
├── Posts
├── Notifications
└── Admin
dễ quản lý hơn nhiều so với:
20 Microservices
ở giai đoạn đầu.
44. Database Design không nên giao hoàn toàn cho AI
AI có thể đề xuất schema tốt.Nhưng bạn vẫn cần kiểm tra:
Relationships
Indexes
Constraints
Unique Keys
Nullability
Cascade Delete
Database sai từ đầu rất khó sửa khi đã có dữ liệu thật.
45. Migration phải được xem như thao tác nguy hiểm
Một migration kiểu:DROP COLUMN
có thể mất dữ liệu.
Do đó:
AI generates migration
↓
Human reviews
↓
Backup
↓
Staging
↓
Production
46. Không để AI tự ý xóa dữ liệu Production
Đây nên là rule rõ ràng:Never run destructive database operations
without explicit approval.
Bao gồm:
DROP
TRUNCATE
DELETE massive rows
Destructive migration
47. Authentication nên dùng giải pháp đã được kiểm chứng
Một sai lầm của Vibe Coding là:Authentication rất dễ làm sai.
Nếu có thể, nên tận dụng framework hoặc provider đã trưởng thành.
Đặc biệt với:
Password Reset
OAuth
MFA
Session
Refresh Token
48. Authorization phải nằm ở backend
Không được chỉ:Hide Admin Button
ở frontend.
Backend vẫn phải kiểm tra:
Is user admin?
Frontend:
UX
Backend:
Security
49. Client không bao giờ đáng tin hoàn toàn
Mọi dữ liệu từ:Browser
Mobile App
API Client
đều có thể bị sửa.
Do đó backend phải validate:
Price
User ID
Role
Permissions
Input
50. AI có thể rất hữu ích trong debugging
Một workflow tốt:Error
↓
Collect logs
↓
Reproduce
↓
Give AI logs + relevant code
↓
Ask for root cause
↓
Apply minimal fix
↓
Test
Không nên chỉ nói:
51. Cho AI lỗi thật, không mô tả mơ hồ
Tốt:TypeError: Cannot read properties of undefined
at user.service.ts:87
Kèm:
Expected behavior
Actual behavior
Relevant code
Recent changes
AI sẽ debug chính xác hơn.
52. Đừng fix symptom, hãy tìm root cause
Ví dụ server crash vì:undefined
AI có thể thêm:
if (!x) return;
và hết crash.
Nhưng câu hỏi thật là:
Một fix tốt phải xử lý:
Root Cause
không chỉ:
Symptom
53. Logs tốt giúp AI debug cực nhanh
Nên có structured logging.Ví dụ:
{
"level": "error",
"userId": 123,
"requestId": "abc",
"route": "/api/orders",
"error": "..."
}
AI có thể phân tích rất tốt loại dữ liệu này.
54. Screenshot rất hữu ích với frontend bug
Nếu UI bị:Overflow
Alignment issue
Responsive bug
hãy cho AI:
Screenshot
+
DOM / component
+
CSS
thay vì chỉ mô tả.
55. AI có thể review pull request
Có thể yêu cầu:Review this diff for:
- bugs
- security
- regression
- performance
- unnecessary changes
Đây là một use case rất hữu ích.
56. Nhưng đừng bảo AI review 200 file cùng lúc nếu không cần
Large context giúp AI đọc nhiều code.Nhưng:
More context
không luôn đồng nghĩa:
Better reasoning
Hãy giới hạn phần liên quan.
57. Một kỹ thuật tốt: Plan trước, Code sau
Thay vì:hãy yêu cầu:
1. Analyze current implementation.
2. Explain the problem.
3. Propose a plan.
4. List files that need changes.
5. Wait / then implement.
Trong workflow tự động hơn, ít nhất vẫn nên có:
Plan
↓
Implementation
58. Một kỹ thuật khác: Ask AI to challenge the plan
Sau khi có kiến trúc:Điều này giúp tránh:
Confirmation Bias
59. Dùng AI thứ hai làm reviewer
Một workflow mạnh:AI A
↓
Implementation
AI B
↓
Review
Model thứ hai không bị ràng buộc bởi những giả định mà model đầu đã sử dụng.
60. Không nên để mọi model có toàn quyền Production
Có thể phân cấp:Coding Agent
→ Local
Review Agent
→ Read only
Deployment
→ Controlled CI/CD
Production
→ Restricted
Đây là cách an toàn hơn.
61. AI Coding Agent càng mạnh càng cần guardrails
Một agent có thể:Read
Write
Delete
Run commands
Install packages
Access Git
Access cloud
thì càng cần:
Permissions
Scope
Review
Logs
Rollback
62. Shell access là quyền rất mạnh
Khi AI có shell:AI
↓
Terminal
↓
Computer
Nó có thể làm gần như mọi thứ trong phạm vi user hiện tại.
Đừng xem:
Terminal access
như một quyền nhỏ.
63. Hãy đọc những command nguy hiểm trước khi chạy
Đặc biệt:sudo
rm
chmod
chown
docker
iptables
curl | bash
database commands
Nếu không hiểu command:
64. Production không phải playground của agent
Local:Experiment freely
Staging:
Test realistically
Production:
Change carefully
Đây là tư duy rất quan trọng.
65. Web, Mobile và Backend cần Contract rõ
Ví dụ API response:{
"id": 123,
"name": "Alice"
}
Nếu backend đột nhiên đổi thành:
{
"user_id": 123,
"full_name": "Alice"
}
frontend/mobile có thể hỏng.
Do đó API contract cần được quản lý rõ.
66. OpenAPI rất hữu ích trong AI Coding
Một OpenAPI specification có thể giúp:Backend
Frontend
Mobile
AI
cùng hiểu một API.
Có thể tự động tạo:
Types
Clients
Docs
Tests
67. Shared Types cũng giúp giảm bug
Trong full-stack TypeScript:Shared Types
giúp tránh frontend và backend hiểu dữ liệu khác nhau.
Nhưng cần tránh coupling quá mức.
68. Error Handling phải được thiết kế, không nên thêm sau
Không nên mọi lỗi đều trả:500 Internal Server Error
Nên phân biệt:
400 Invalid Input
401 Unauthorized
403 Forbidden
404 Not Found
409 Conflict
429 Too Many Requests
500 Internal Error
AI có thể giúp chuẩn hóa error handling rất tốt.
69. UX khi lỗi cũng quan trọng
Frontend không nên chỉ:Something went wrong
trong mọi trường hợp.
Có thể có:
Retry
Reconnect
Validation Message
Offline State
Empty State
70. Realtime Development cần đặc biệt cẩn thận
Với:WebSocket
Socket.IO
Realtime Games
Chat
Presence
AI có thể tạo demo hoạt động nhanh.
Nhưng Production phải xử lý:
Reconnect
Duplicate events
Ordering
Timeout
Race condition
Server authority
71. Client không nên là nguồn sự thật trong hệ thống cạnh tranh
Ví dụ game:Client:
"I won."
server không nên tin.
Server cần:
Validate state
và giữ:
Server authoritative
72. Race Condition rất dễ bị bỏ sót
Ví dụ hai request cùng lúc:Buy item
Buy item
có thể khiến stock âm.
AI Coding cần nghĩ đến:
Concurrency
Transaction
Locking
Idempotency
73. Idempotency đặc biệt quan trọng với Payment
Ví dụ webhook được gửi hai lần.Nếu backend xử lý:
Activate subscription
hai lần gây side effect sai.
Nên có:
Idempotency
74. Third-party API luôn có thể thất bại
Không nên code như:Stripe always works
hoặc:
OpenAI always responds
Cần xử lý:
Timeout
Rate Limit
Downtime
Invalid Response
Retry
75. Timeout phải được cấu hình
Request không nên chờ vô hạn.Ví dụ:
External API
treo.
Nếu không có timeout:
Server resources
có thể bị giữ lâu.
76. AI API cần kiểm soát chi phí
Nếu app dùng AI:User
↓
Your API
↓
LLM
cần nghĩ đến:
Token Limit
Rate Limit
Quota
Caching
Usage Tracking
Nếu không, một user có thể tạo bill rất lớn.
77. Không cho frontend gọi AI API bằng secret key
Kiến trúc:Frontend
↓
AI Provider
với secret key trong frontend là nguy hiểm.
Nên:
Frontend
↓
Backend
↓
AI Provider
78. Output của AI không nên được render mù quáng
Nếu AI trả HTML:Render directly
có thể tạo security risk.
AI output phải được xem là:
Untrusted Data
79. Documentation nên được cập nhật cùng code
AI rất hữu ích để cập nhật:README
API Docs
Architecture
Deployment Instructions
Changelog
Nhưng tài liệu cần khớp với code thật.
80. Một project AI Coding tốt nên có “source of truth”
Ví dụ:README
Architecture Doc
Database Schema
OpenAPI
Task Tracker
Không nên để thông tin quan trọng chỉ tồn tại trong:
Một cuộc chat AI cũ
81. Đừng phụ thuộc hoàn toàn vào memory của AI
Mỗi session có thể:Forget context
Misunderstand old decision
Do đó quyết định quan trọng phải nằm trong:
Repository
82. Hãy lưu Architectural Decisions
Có thể tạo:ADR
Architecture Decision Record.
Ví dụ:
Why PostgreSQL instead of MongoDB?
Why monolith instead of microservices?
Why server-authoritative game logic?
Sau này AI đọc lại sẽ hiểu lý do.
83. Đừng để AI “sáng tạo” business rules
Nếu business rule không rõ:AI will invent one.
Ví dụ:
Nếu không quy định, AI có thể tự chọn.
Do đó business logic cần do con người quyết định.
84. Product Decision và Technical Decision không giống nhau
AI có thể gợi ý:Technical options
Nhưng những câu hỏi như:
User có phải trả tiền không?
Có cho guest dùng không?
Xóa account có xóa dữ liệu không?
là product/business decision.
85. AI tốt nhất khi yêu cầu có tiêu chí thành công
Ví dụ:Task is complete when:
- user can upload avatar
- image is resized
- max 5MB
- invalid files rejected
- tests pass
- existing API unchanged
AI biết khi nào:
Done
86. Definition of Done rất quan trọng
Một task không nên kết thúc khi:Code generated
mà khi:
Code works
Tests pass
Build passes
Requirements met
No obvious regression
87. Một workflow AI Coding thực tế
Có thể sử dụng:1. Describe feature
↓
2. AI analyzes project
↓
3. AI proposes plan
↓
4. Human checks plan
↓
5. AI implements
↓
6. Build
↓
7. Test
↓
8. AI reviews diff
↓
9. Human checks
↓
10. Commit
Đây là workflow khá an toàn.
88. Với task nhỏ có thể nhanh hơn
Ví dụ:Fix typo
Change padding
Rename label
không cần quy trình quá nặng.
AI Coding tốt cũng có nghĩa:
89. Phân loại task theo rủi ro
Low Risk
CSSText
Simple UI
Documentation
Medium Risk
APIState Management
Business Logic
High Risk
AuthenticationPayment
Database Migration
Permissions
Production Infrastructure
Task càng nguy hiểm:
Review càng kỹ
90. Authentication, Payment và Database nên luôn được coi là High Risk
AI có thể hỗ trợ rất mạnh.Nhưng đây là ba vùng không nên:
Generate
↓
Deploy immediately
91. Khi nào AI Coding hoạt động tốt nhất?
AI đặc biệt mạnh với:CRUD
Forms
API Integration
UI Components
Tests
Refactoring
Documentation
Debugging
Data Transformation
Scripts
92. Khi nào AI cần con người nhiều hơn?
AI thường cần giám sát kỹ với:Complex Architecture
Security
Concurrency
Performance
Legacy Systems
Business Rules
Payments
Distributed Systems
93. AI Coding không loại bỏ kiến thức lập trình
Ngược lại.Một người hiểu code có thể nhận ra:
AI đang làm đúng hay sai
nhanh hơn rất nhiều.
AI giảm:
Amount of typing
nhưng không loại bỏ:
Need for understanding
94. Kỹ năng quan trọng nhất chuyển từ “viết code” sang “điều phối”
Developer tương lai sẽ dành nhiều thời gian hơn cho:Design
Specification
Review
Testing
Architecture
Decision Making
và ít thời gian hơn cho:
Boilerplate typing
95. Prompting cho Coding không cần hoa mỹ
Prompt tốt không phải prompt dài nhất.Prompt tốt là:
Clear
Specific
Context-rich
Testable
Bounded
96. Một prompt coding tốt có thể có cấu trúc
ContextTask
Constraints
Expected behavior
Files involved
Do not change
Validation
Ví dụ:
Context:
Next.js + NestJS application.
Task:
Add account deletion.
Constraints:
Do not hard-delete immediately.
Set deletedAt.
Logout all sessions.
Do not change:
Existing login API.
Validation:
Add tests and run existing auth tests.
97. Câu “hãy làm tốt nhất” ít giá trị hơn constraint cụ thể
Ví dụ:Make this production ready.
rất mơ hồ.
Tốt hơn:
Add:
- input validation
- error handling
- rate limiting
- logging
- tests
98. Hãy yêu cầu AI nói ra assumptions
Một prompt hữu ích:Điều này giúp phát hiện:
Missing Requirements
99. Nếu AI bắt đầu sửa quá nhiều, hãy dừng
Một dấu hiệu nguy hiểm:Task nhỏ
↓
AI sửa 40 files
Hãy kiểm tra ngay:
100. Diff là thứ phải đọc
Không nên chỉ nhìn:AI says success.
Hãy nhìn:
git diff
Ít nhất với những phần quan trọng.
101. Một trong những kỹ năng lớn nhất: biết khi nào reset cách tiếp cận
Nếu AI sửa lỗi:Fix
↓
New error
↓
Fix
↓
New error
↓
Fix
qua nhiều vòng, có thể nó đang patch symptom.
Lúc đó tốt hơn:
Stop
↓
Re-analyze root cause
102. Không nên để một cuộc chat kéo dài mãi
Sau nhiều vòng, context có thể chứa:Old assumptions
Failed approaches
Contradictory decisions
Đôi khi một session mới với:
Clean context
+
Current project state
cho kết quả tốt hơn.
103. AI Coding tốt là vòng lặp ngắn
Một vòng lý tưởng:Understand
↓
Change
↓
Verify
không phải:
Generate 50 files
↓
Hope
104. Web + Mobile + Backend nên phát triển theo vertical slice
Thay vì:Build all frontend
↓
Build all backend
có thể làm:
Login
Frontend + API + DB
↓
Test
sau đó:
Profile
Frontend + API + DB
↓
Test
Đây gọi là phát triển theo:
Vertical Slice
Rất phù hợp với AI Coding.
105. MVP nên thực sự là Minimum
AI khiến việc thêm feature quá dễ.Điều này tạo ra:
Feature Creep
Một MVP nên tập trung:
Core Value
trước.
106. Đừng thêm tính năng chỉ vì AI có thể làm nhanh
Câu hỏi đúng:Không phải:
107. AI có thể tạo Technical Debt nhanh hơn con người
Vì AI viết rất nhanh.Trong vài giờ, AI có thể tạo:
Thousands of lines
Nếu kiến trúc sai:
Technical debt
cũng tăng theo tốc độ đó.
108. Chất lượng không đến từ số lượng code
Một project tốt đôi khi:Less Code
tốt hơn:
More Generated Code
109. Xóa code cũng là một kỹ năng AI Coding
Hãy yêu cầu AI:Find:
- dead code
- duplicate logic
- unused dependencies
- obsolete files
Nhưng phải review trước khi xóa.
110. AI Coding trong tương lai sẽ ngày càng Agentic
Workflow sẽ chuyển từ:AI writes snippet
sang:
AI reads project
↓
plans
↓
codes
↓
runs tests
↓
debugs
↓
reviews
↓
creates PR
Con người chuyển dần sang:
Supervisor
Architect
Reviewer
Product Decision Maker
111. Nhưng càng tự động hóa càng cần kiểm soát
Một agent tự chủ hơn có thể làm nhiều hơn.Nhưng:
Capability ↑
=
Potential Damage ↑
nếu cấu hình sai.
Do đó cần:
Permissions
Sandbox
Git
Tests
Approval
Audit
112. Công thức đơn giản cho AI Coding hiệu quả
Có thể tóm tắt:Good Context
+
Small Tasks
+
Clear Constraints
+
Version Control
+
Tests
+
Review
=
Reliable AI Coding
113. Những điều nên làm
✓ Có specification trước khi code✓ Chia task nhỏ
✓ Cho AI đọc code liên quan
✓ Dùng Git
✓ Commit thường xuyên
✓ Test sau thay đổi
✓ Review diff
✓ Dùng staging
✓ Giới hạn quyền agent
✓ Kiểm tra dependency
✓ Kiểm tra security
✓ Giữ tài liệu kiến trúc
114. Những điều không nên làm
✗ Một prompt xây toàn bộ sản phẩm✗ Cho AI tự chọn mọi công nghệ
✗ Tin rằng code compile là đủ
✗ Deploy thẳng Production
✗ Cho AI full quyền database
✗ Cho agent root access không cần thiết
✗ Chạy command không hiểu
✗ Commit API key
✗ Bỏ qua test
✗ Để AI refactor ngoài phạm vi
✗ Tin tuyệt đối lời AI nói rằng đã fix
115. Quy trình đề xuất cho một dự án Vibe Coding
IDEA↓
PRODUCT REQUIREMENTS
↓
TECH STACK
↓
ARCHITECTURE
↓
DATABASE DESIGN
↓
AI IMPLEMENTATION
↓
TEST
↓
CODE REVIEW
↓
STAGING
↓
SECURITY REVIEW
↓
PRODUCTION
↓
MONITORING
↓
ITERATION
AI có thể tham gia ở mọi bước.
Nhưng không bước nào nên hoàn toàn thiếu kiểm soát.
116. AI Coding không phải “No Code”
Đây là điểm quan trọng.Vibe Coding không đồng nghĩa:
Không cần biết gì về code.
Đúng hơn:
Không cần tự viết mọi dòng code.
Hai điều này rất khác nhau.
117. Người không phải developer vẫn có thể tạo sản phẩm
AI đã hạ thấp rào cản rất nhiều.Một người có:
Ý tưởng
Logic
Kiến thức ngành
Khả năng mô tả vấn đề
có thể tạo sản phẩm mà trước đây phải cần cả team.
Đây là sức mạnh lớn nhất của Vibe Coding.
118. Nhưng khi sản phẩm lớn lên, kiến thức kỹ thuật càng quan trọng
Một prototype có thể:Just work
Nhưng khi có:
1,000 users
10,000 users
Payments
Sensitive Data
Realtime
yêu cầu về:
Architecture
Security
Performance
DevOps
tăng rất nhanh.
119. AI giúp một người làm được công việc của một team nhỏ
Một developer với AI hiện nay có thể đảm nhiệm:Product
Frontend
Backend
Database
Testing
DevOps
Documentation
ở mức độ mà trước đây cần nhiều người.
Nhưng đây không có nghĩa:
Mọi chuyên môn đều biến mất.
Nó có nghĩa:
Một người có thể leverage nhiều chuyên môn hơn.
120. Kết luận
AI Coding, Mobile Development và Web Development trong thời đại Vibe Coding không nên được hiểu đơn giản là:Đó là cả một quy trình:
Understand
↓
Specify
↓
Plan
↓
Delegate to AI
↓
Review
↓
Test
↓
Correct
↓
Deploy
↓
Monitor
AI đang thay đổi vai trò của developer.
Trước đây:
Developer
=
Person who writes code
Ngày càng nhiều hơn:
Developer
=
Person who designs,
directs,
reviews,
tests
and controls AI-generated systems
Một Vibe Coder giỏi không phải là người có thể tạo nhiều code nhất.
Mà là người có khả năng:
biến ý tưởng thành specification,
biến specification thành task,
giao task đúng cho AI,
kiểm tra kết quả,
phát hiện sai sót,
và đưa sản phẩm lên Production an toàn.
Có thể tóm gọn bằng một nguyên tắc:
Đây cũng là tinh thần của chuyên mục AI Coding, Mobile & Web Development: chia sẻ cách làm việc thực tế với AI trong toàn bộ vòng đời phát triển phần mềm — từ ý tưởng, kiến trúc, prompt, code, frontend, backend, mobile, database, testing, debugging, review cho tới khi sản phẩm thực sự hoạt động ngoài Production.
Trong thời đại Vibe Coding, lợi thế không còn chỉ nằm ở việc ai code nhanh hơn.
Lợi thế nằm ở việc:
ai biết tổ chức AI tốt hơn, kiểm soát chất lượng tốt hơn và biến tốc độ của AI thành sản phẩm thực sự tốt hơn.