AI Developer Mindset — Think in Prompts, Rules & Skills
A bilingual guide on the developer mindset for working effectively with AI. From crafting prompts to defining rules and skills — the thinking framework that separates power users from casual prompters.
Why Mindset Matters More Than Syntax {Tại sao tư duy quan trọng hơn cú pháp}
Most developers approach AI like a search engine {Hầu hết dev tiếp cận AI như công cụ tìm kiếm} — type a question, get an answer {gõ câu hỏi, nhận câu trả lời}. This works for trivial tasks {Cách này hoạt động cho task nhỏ}. But for serious engineering work {Nhưng với công việc nghiêm túc}, the difference between a good AI user and a great one isn’t prompt syntax {sự khác biệt giữa người dùng AI tốt và xuất sắc không phải cú pháp prompt} — it’s how they think about the collaboration {mà là cách họ nghĩ về sự hợp tác}.
This post covers three levels of AI-developer integration {Bài viết này bao gồm ba cấp độ tích hợp AI-developer}:
- Prompts — the conversation layer {tầng hội thoại}
- Rules — the guardrails layer {tầng rào chắn}
- Skills — the workflow layer {tầng quy trình}
Each level solves a specific problem {Mỗi cấp độ giải quyết một vấn đề cụ thể}. Together, they form a progressive system {Kết hợp lại, chúng tạo thành hệ thống tiến triển} that makes AI genuinely useful instead of merely convenient {khiến AI thực sự hữu ích thay vì chỉ tiện lợi}.
The Mental Model {Mô hình tư duy}
Think of your AI agent as a new team member {Hãy nghĩ AI agent như thành viên mới trong team}:
┌─────────────────────────────────────────────────────────────┐
│ Your AI Integration Stack │
├─────────────────────────────────────────────────────────────┤
│ │
│ SKILLS ──── "Here's the full playbook for X workflow" │
│ "Đây là cẩm nang đầy đủ cho quy trình X" │
│ (complex, multi-step, reusable) │
│ │
│ RULES ───── "Always follow these conventions" │
│ "Luôn tuân theo các quy ước này" │
│ (persistent, automatic, lightweight) │
│ │
│ PROMPTS ─── "Do this specific thing right now" │
│ "Làm việc cụ thể này ngay bây giờ" │
│ (ephemeral, contextual, one-shot) │
│ │
└─────────────────────────────────────────────────────────────┘The key insight {Nhận thức then chốt}: you should promote patterns upward {bạn nên nâng cấp pattern lên trên}. If you keep writing the same prompt → make it a rule {Nếu bạn cứ viết cùng một prompt → biến nó thành rule}. If a rule grows complex → make it a skill {Nếu rule trở nên phức tạp → biến nó thành skill}.
Level 1: Effective Prompting {Cấp 1: Prompt hiệu quả}
The CIDER Framework {Khung CIDER}
Every effective prompt has five elements {Mọi prompt hiệu quả đều có năm yếu tố}:
| Element | Meaning {Nghĩa} | Example {Ví dụ} |
|---|---|---|
| Context | Background info the AI needs {Thông tin nền AI cần} | “This is a Next.js 16 app using App Router” |
| Intent | What you want to achieve {Bạn muốn đạt được gì} | “Add error handling to the checkout flow” |
| Details | Specifics and constraints {Chi tiết và ràng buộc} | “Use toast notifications, not alert()“ |
| Examples | Show, don’t just tell {Cho xem, không chỉ nói} | “Like how /login handles auth errors” |
| Restrictions | What NOT to do {Những gì KHÔNG được làm} | “Don’t modify the payment service” |
Bad vs Good Prompts {Prompt tệ và tốt}
Bad {Tệ} — vague, no context, ambiguous {mơ hồ, không ngữ cảnh, không rõ ràng}:
Fix the bug in the login pageBetter {Tốt hơn} — has intent and some context {có ý định và một ít ngữ cảnh}:
The login form submits but doesn't redirect to /dashboard after success.
Fix the redirect logic in app/login/actions.ts.Best {Tốt nhất} — full CIDER, the AI barely needs to guess {đầy đủ CIDER, AI hầu như không cần đoán}:
Context: Next.js 16 app with App Router. Auth uses server actions in
app/login/actions.ts. After successful login, user should go to /dashboard.
Problem: Login succeeds (I can see the session cookie set) but the page stays
on /login. No errors in console.
Constraint: Don't change the auth logic — only fix the redirect. We use
redirect() from next/navigation, not router.push().
Reference: The /register flow works correctly — check app/register/actions.ts
for how it handles post-auth redirect.The 80/20 Rule of Prompting {Quy tắc 80/20 của Prompting}
80% of prompt quality comes from {80% chất lượng prompt đến từ}:
- Being specific about what you want {Cụ thể về điều bạn muốn} — not “make it better”, but “reduce bundle size by lazy-loading the chart library” {không phải “làm tốt hơn”, mà “giảm bundle size bằng cách lazy-load thư viện chart”}
- Showing the current state {Cho thấy trạng thái hiện tại} — paste the error, attach the file, describe what happens NOW {dán lỗi, đính kèm file, mô tả những gì đang xảy ra BÂY GIỜ}
- Defining boundaries {Xác định ranh giới} — “only modify these files”, “don’t add new dependencies” {“chỉ sửa các file này”, “không thêm dependency mới”}
The other 20% is tone, formatting, and persona instructions {20% còn lại là giọng điệu, định dạng, và hướng dẫn persona} — nice to have, not essential {tốt để có, không thiết yếu}.
Prompt Patterns for Developers {Các pattern prompt cho Developer}
The Scope-Lock Pattern {Pattern Khoá phạm vi}
Prevents the AI from making unnecessary changes {Ngăn AI làm thay đổi không cần thiết}:
Scope: ONLY modify src/components/Modal.tsx
Do NOT touch: global styles, other components, package.json
Task: Add keyboard trap (focus stays inside modal when open, ESC closes it)The Before/After Pattern {Pattern Trước/Sau}
When you want a specific transformation {Khi bạn muốn một biến đổi cụ thể}:
Current behavior: clicking "Save" shows a loading spinner that never disappears
Expected behavior: spinner shows for max 3s, then either success toast or error toast
File: src/components/SaveButton.tsxThe Teach-Me Pattern {Pattern Dạy-Tôi}
When you want to understand, not just get code {Khi bạn muốn hiểu, không chỉ nhận code}:
Explain how React Server Components decide what to include in the client bundle.
Use a concrete example from this codebase. Show me which imports would end up
in the browser and why.The Incremental Pattern {Pattern Từng-bước}
Break complex tasks into checkpoints {Chia task phức tạp thành các điểm kiểm tra}:
We're adding dark mode. Let's do this step by step:
1. First, add CSS variables for both themes in global.css
2. Wait for my review before proceeding to step 2Level 2: Rules — Persistent Guardrails {Cấp 2: Rules — Rào chắn vĩnh viễn}
When to Create a Rule {Khi nào tạo Rule}
Create a rule when you find yourself correcting the AI about the same thing repeatedly {Tạo rule khi bạn thấy mình sửa AI về cùng một điều lặp đi lặp lại}:
Pattern recognition:
{Nhận diện pattern:}
"Don't use any" → 3rd time → Rule: "No `any` in TypeScript"
"Use kebab-case" → 3rd time → Rule: "File naming: kebab-case.ts"
"We use pnpm not npm" → 2nd time → Rule: "Package manager: pnpm only"
"Don't add comments" → 5th time → Rule: "Comments: only explain WHY"The 3-strike rule {Quy tắc 3-lần}: if you correct the AI about the same thing three times {nếu bạn sửa AI cùng một điều ba lần}, it’s time to write a rule {đã đến lúc viết rule}.
Anatomy of a Good Rule {Cấu trúc Rule tốt}
A rule should be {Một rule nên}: short, specific, and actionable {ngắn, cụ thể, và có thể hành động}.
# TypeScript Conventions
- No `any` — use `unknown` then narrow with type guards
- No `@ts-ignore` — fix the actual type error
- No `as` assertions unless after runtime validation (e.g. after zod.parse())
- Prefer `type` for unions, `interface` for object shapes
- Import types with `import type` for tree-shakingBad rule {Rule tệ} — too vague to enforce {quá mơ hồ để thực thi}:
# Code Quality
Write good code. Follow best practices. Make it clean.Good rule {Rule tốt} — specific, checkable {cụ thể, kiểm tra được}:
# Naming
- Files: kebab-case.ts (utils), PascalCase.tsx (components)
- Variables: camelCase
- Types/Interfaces: PascalCase, no "I" prefix
- Constants: UPPER_SNAKE_CASE only for true compile-time constantsRule Categories {Phân loại Rule}
Organize rules by scope {Tổ chức rule theo phạm vi}:
| Category {Loại} | Purpose {Mục đích} | Examples {Ví dụ} |
|---|---|---|
| Prohibitions | Things to NEVER do {Những thứ KHÔNG BAO GIỜ làm} | No any, no !important, no hard-coded secrets |
| Conventions | How things should be done {Cách mọi thứ nên được làm} | Naming, file structure, import order |
| Architecture | System boundaries {Ranh giới hệ thống} | “No React — pure Astro”, “SSG only” |
| Content | Writing standards {Tiêu chuẩn viết} | “Start from h2”, “max 5 tags”, “description required” |
The Minimal Viable Ruleset {Bộ rule tối thiểu khả dụng}
Start with these 4 rules for any project {Bắt đầu với 4 rule này cho mọi project}:
- Project context — what this project IS {project này LÀ gì} (stack, purpose, deployment)
- Coding standards — naming, style, type safety {đặt tên, style, type safety}
- Prohibitions — things that must NEVER happen {những thứ KHÔNG BAO GIỜ được xảy ra}
- File patterns — where things go, how they’re structured {mọi thứ ở đâu, cấu trúc thế nào}
That’s it {Vậy đủ}. Four rules cover 90% of what you’d otherwise repeat in prompts {Bốn rule bao phủ 90% những gì bạn sẽ lặp lại trong prompt}.
Level 3: Skills — Workflow Automation {Cấp 3: Skills — Tự động hoá quy trình}
When to Create a Skill {Khi nào tạo Skill}
Create a skill when {Tạo skill khi}:
- A workflow has 5+ steps that must happen in order {Một quy trình có 5+ bước phải xảy ra theo thứ tự}
- The workflow is repeatable — you do it weekly or more {Quy trình lặp lại — bạn làm hàng tuần hoặc nhiều hơn}
- The workflow requires specific domain knowledge {Quy trình cần kiến thức chuyên môn cụ thể}
Examples of skill-worthy workflows:
{Ví dụ các quy trình đáng tạo skill:}
- "Implement a Jira ticket" (read ticket → plan → code → test → PR)
- "Self-review before push" (diff → lint → type-check → review → fix)
- "Write a blog post" (research → outline → draft → edit → publish)
- "Split work into PRs" (analyze changes → group → create branches → push)Skill vs Rule vs Prompt — Decision Tree {Skill vs Rule vs Prompt — Cây quyết định}
Is this instruction...
One-time? ─────────────────────── → PROMPT
{Một lần?} {just say it in chat}
Repeated & simple? ───────────── → RULE
{Lặp lại & đơn giản?} {write a .mdc file}
Repeated & complex (5+ steps)? ─ → SKILL
{Lặp lại & phức tạp (5+ bước)?} {write a SKILL.md}Anatomy of a Good Skill {Cấu trúc Skill tốt}
A skill is a step-by-step playbook {Skill là cẩm nang từng bước} that the AI follows autonomously {mà AI tuân theo tự động}:
# Deploy to Production
## Steps
1. Run `npm run build` — verify no errors
2. Run `npm run test` — all tests must pass
3. Check `git status` — no uncommitted changes
4. Create git tag with format `v{version}`
5. Push tag: `git push origin v{version}`
6. Wait for CI to pass (check GitHub Actions)
7. If CI fails, report the error and stop
## Constraints
- Never deploy on Friday after 4pm
- Never skip tests even if "just a typo"
- If build fails, fix it before retryingThe Progressive Promotion Pattern {Pattern Nâng cấp tiến triển}
Watch how a piece of knowledge naturally evolves {Xem cách một kiến thức tự nhiên phát triển}:
Day 1 (Prompt):
"Use pnpm, not npm. And use kebab-case for filenames."
{Dùng pnpm, không phải npm. Và dùng kebab-case cho tên file.}
Day 3 (Still prompting the same thing):
"Remember — pnpm! And kebab-case files!"
{Nhớ nhé — pnpm! Và kebab-case cho file!}
Day 5 (Create a Rule):
# coding-standards.mdc
- Package manager: pnpm (never npm or yarn)
- File naming: kebab-case.ts for utilities
Day 30 (Rule grows into a Skill):
# create-component/SKILL.md
1. Create file: src/components/{category}/{name}.astro
2. Use kebab-case for filename
3. Add Props interface with JSDoc
4. Register in barrel export if exists
5. Add to Storybook if component is reusableThe Developer’s AI Workflow {Quy trình AI của Developer}
Daily Loop {Vòng lặp hàng ngày}
Morning:
{Buổi sáng:}
1. Review what AI did yesterday (if async tasks ran)
{Xem lại AI đã làm gì hôm qua (nếu có task chạy nền)}
2. Plan today's tasks — which ones benefit from AI?
{Lên kế hoạch ngày — task nào được lợi từ AI?}
3. Start with hardest task (your brain is fresh, AI benefits from clear thinking)
{Bắt đầu với task khó nhất (não bạn còn tươi, AI hưởng lợi từ tư duy rõ)}
During coding:
{Trong lúc code:}
4. Use AI for implementation after YOU design the approach
{Dùng AI để implement sau khi BẠN thiết kế cách tiếp cận}
5. Review every change — AI is fast but makes subtle mistakes
{Review mọi thay đổi — AI nhanh nhưng mắc lỗi tinh vi}
6. When you correct AI → ask "Should this be a rule?"
{Khi bạn sửa AI → hỏi "Cái này có nên là rule không?"}
End of day:
{Cuối ngày:}
7. Reflect: what repeated? What was slow? What was wrong?
{Suy ngẫm: cái gì lặp? Cái gì chậm? Cái gì sai?}
8. Promote patterns: prompt → rule → skill
{Nâng cấp pattern: prompt → rule → skill}The 70/30 Split {Phân chia 70/30}
The ideal AI-human split for serious engineering {Phân chia AI-người lý tưởng cho engineering nghiêm túc}:
| You do (30%) {Bạn làm (30%)} | AI does (70%) {AI làm (70%)} |
|---|---|
| Architecture decisions {Quyết định kiến trúc} | Implementation of decided patterns {Implement các pattern đã quyết} |
| Edge case identification {Nhận diện edge case} | Writing the actual code {Viết code thực tế} |
| Code review {Review code} | Refactoring, renaming, restructuring |
| User experience design {Thiết kế trải nghiệm} | Boilerplate, tests, documentation |
| ”What should we build?” {“Nên xây gì?”} | ”How to implement what you decided” {“Cách implement cái bạn đã quyết”} |
Never delegate to AI {KHÔNG BAO GIỜ giao cho AI}:
- Security-critical decisions {Quyết định bảo mật quan trọng}
- Data model design {Thiết kế data model}
- “Should we use library X or Y?” {“Nên dùng thư viện X hay Y?”}
- Performance trade-offs {Đánh đổi hiệu năng}
Always delegate to AI {LUÔN giao cho AI}:
- Writing tests for already-designed logic {Viết test cho logic đã thiết kế}
- File scaffolding and boilerplate {Tạo khung file và boilerplate}
- Searching codebase for patterns {Tìm pattern trong codebase}
- Formatting, linting, import sorting {Định dạng, lint, sắp xếp import}
Common Anti-Patterns {Các Anti-Pattern phổ biến}
1. The “Do Everything” Prompt {Prompt “Làm hết đi”}
❌ "Build me a complete e-commerce site with auth, payments, and admin panel"This fails because {Cái này thất bại vì}: context window overflow, no clear stopping point, AI makes dozens of architectural decisions you didn’t approve {tràn context window, không có điểm dừng rõ ràng, AI đưa ra hàng chục quyết định kiến trúc bạn không duyệt}.
Fix {Sửa}: break into phases, design first, implement piece by piece {chia thành các giai đoạn, thiết kế trước, implement từng phần}.
2. The “Trust Everything” Mindset {Tư duy “Tin hết”}
❌ AI writes code → You commit without reading → Bug in productionFix {Sửa}: always review {luôn review}. Read the diff {Đọc diff}. Run the tests {Chạy test}. AI is a drafter, you are the editor {AI là người nháp, bạn là biên tập}.
3. The “Never Customize” Trap {Bẫy “Không bao giờ tuỳ chỉnh”}
❌ Using AI for 6 months with zero rules, zero skills
Correcting the same mistakes 500 timesFix {Sửa}: spend 30 minutes writing your first 4 rules {dành 30 phút viết 4 rule đầu tiên}. The ROI is immediate {ROI ngay lập tức}.
4. The “Over-Engineer” Trap {Bẫy “Thiết kế quá mức”}
❌ 50 rules, 20 skills, configuration more complex than the codebaseFix {Sửa}: start minimal {bắt đầu tối thiểu}. Add rules only when you feel pain {Thêm rule chỉ khi bạn thấy khó chịu}. If a rule isn’t triggered weekly, delete it {Nếu rule không được kích hoạt hàng tuần, xoá nó}.
Practical Templates {Mẫu thực tế}
Starter Rule Template {Mẫu Rule khởi đầu}
# Project Context
## What this is
[1-2 sentences: what the project does, who uses it]
## Stack
[List: framework, language, key libraries]
## Key directories
[Table: path → purpose]
## Conventions
- [Naming rules]
- [File organization rules]
- [Import rules]
## Prohibitions
- [Things that must never happen]
- [Security boundaries]Prompt Template for Complex Tasks {Mẫu Prompt cho task phức tạp}
## Context
- Project: [name, stack, current state]
- File(s): [which files are relevant]
## Task
[What needs to happen — be specific]
## Constraints
- Only modify: [list files]
- Don't change: [list things to preserve]
- Must maintain: [backwards compatibility? types? tests?]
## Reference
- Similar implementation: [point to existing code]
- Docs: [relevant documentation URL]
## Acceptance Criteria
- [ ] [Specific checkable outcome 1]
- [ ] [Specific checkable outcome 2]The Mindset Shift {Sự chuyển đổi tư duy}
The ultimate realization {Nhận thức cuối cùng}: working with AI isn’t about knowing the right prompt syntax {làm việc với AI không phải về biết cú pháp prompt đúng}. It’s about thinking clearly enough that another entity can execute your intent {Mà là về suy nghĩ đủ rõ ràng để một thực thể khác có thể thực thi ý định của bạn}.
This is the same skill as {Đây là cùng kỹ năng với}:
- Writing clear Jira tickets {Viết Jira ticket rõ ràng}
- Onboarding a new team member {Onboard thành viên mới}
- Writing documentation {Viết documentation}
- Designing an API {Thiết kế API}
If you can explain your intent clearly to a human {Nếu bạn có thể giải thích ý định rõ ràng cho người}, you can prompt an AI effectively {bạn có thể prompt AI hiệu quả}. The AI just has less patience for ambiguity {AI chỉ ít kiên nhẫn hơn với sự mơ hồ}.
Start today {Bắt đầu hôm nay}:
- Write 4 rules for your current project {Viết 4 rule cho project hiện tại} (10 minutes)
- Next time you correct the AI, ask: “Should this be a rule?” {Lần tới bạn sửa AI, hỏi: “Cái này có nên là rule không?”}
- After 2 weeks, check which prompts you keep repeating → promote them {Sau 2 tuần, kiểm tra prompt nào bạn cứ lặp lại → nâng cấp chúng}
The compound effect is real {Hiệu ứng kép là thật}. In a month, your AI will feel like a different tool {Trong một tháng, AI của bạn sẽ cảm thấy như một công cụ khác} — because you’ll have taught it how YOUR team works {vì bạn đã dạy nó cách TEAM BẠN làm việc}.