“Let AI handle the boring; let humans handle the clever.”

Về tác giả:

Addy Osmani là một lãnh đạo kỹ thuật cấp cao tại Google Chrome, nơi ông phụ trách trải nghiệm nhà phát triển, hiệu năng, và các công cụ phát triển phần mềm sử dụng trí tuệ nhân tạo. Ông có hơn 20 năm kinh nghiệm trong ngành phát triển công nghệ web, và là tác giả của nhiều cuốn sách về các phương pháp hay nhất trong kỹ thuật phần mềm.

Tổng quan về Vibe Coding

Phần 1: Khái niệm Vibe Coding và sự chuyển đổi vai trò lập trình viên

🧭 1. Lập trình đang thay đổi: Từ câu lệnh sang ý định

• Truyền thống: lập trình = viết từng dòng lệnh chi tiết cho máy.
• Thời đại mới: bạn mô tả ý định (“intent”) → AI viết code thay bạn.
• 🧠 Vibe Coding = bạn mô tả bằng ngôn ngữ tự nhiên, AI “cảm” rồi hiện thực hóa.
  • Lập trình giống như nói chuyện với một đồng đội hơn là gõ lệnh thủ công.

💡 2. Khái niệm “Vibe Coding” là gì?

• ✅ Một cách tiếp cận “prompt-first” do Andrej Karpathy đề xuất.
• 🌀 Bạn thả lỏng kiểm soát chi tiết, dùng AI để khám phá nhanh, code nhanh.
• Ví dụ điển hình: “Tôi chỉ cần nói đại khái ‘tạo một app đếm từ và export PDF’ → AI tạo xong trong 10 phút.”

🎨 3. Định nghĩa lại vai trò lập trình viên

• Từ người viết từng dòng code → trở thành người cộng tác cùng AI:
  • Đưa ra yêu cầu → AI gợi ý code → bạn chỉnh sửa và phản hồi lại → lặp lại.
• Quá trình giống như pair-programming với một AI thông minh.
• Trích lời Karpathy: “Tôi cứ ‘Accept all’, không cần đọc diff… Gặp bug thì copy-paste error cho AI sửa.”

⚙️ 4. Các công cụ làm nên Vibe Coding

• IDE: Cursor, Windsurf, Replit, các môi trường tích hợp AI.
• Model phía sau: Claude (Sonnet, Opus), ChatGPT (GPT-4).
• Các IDE này hiểu được toàn bộ codebase và giúp:
  • Viết, sửa, refactor code
  • Tạo nhiều file cùng lúc
  • Hỏi về lỗi và sửa lỗi ngay trong giao diện IDE

⚖️ 5. Tác động đến năng suất

• ⚡ Có thể tăng năng suất gấp 10x – 100x (theo một số dev như John Hoestje).
• 🚀 Code boilerplate, CRUD, test, doc – chỉ mất vài phút.
• 🤖 Giống như có vô hạn thực tập sinh AI làm việc cùng bạn tốc độ “điện”.

🚨 6. Mặt trái của Vibe Coding

• Code chạy được không đồng nghĩa với code chất lượng.
• Rủi ro:
  • Thiếu kiểm tra bảo mật
  • Không tối ưu
  • Dễ sinh “code nhà tạm” (chạy được nhưng dễ sập)
• Có thể bị cuốn theo prompt mà không có kế hoạch hoặc thiết kế kiến trúc rõ ràng.

🧭 7. Lập trình dựa trên ý định = lập trình mô tả

• Chuyển từ: “Do A, rồi B, rồi C”
  sang
  “Tôi cần một chức năng làm A, B, C”
• 🧠 Prompt là “đơn vị tư duy” mới – giống như pseudocode chạy được.
• Viết prompt tốt = viết mô tả kỹ thuật tốt.

🔁 8. Chu trình hợp tác người + AI

✨ 9. Tác động tích cực của Vibe Coding

• 🕒 Rút ngắn thời gian build tính năng → prototyping cực nhanh.
• 😄 Giữ “flow” làm việc, không bị ngắt quãng vì chi tiết lặt vặt.
• 🧑‍🔬 Người không chuyên (PM, marketer…) cũng có thể tạo web tool bằng prompt.
• 🧠 Lập trình viên có thời gian tập trung vào design, UX, logic khó.

⚠️ 10. Thách thức cần lưu ý

• ❗ Cần test nghiêm ngặt – không tin tưởng AI tuyệt đối.
• 🤔 Vấn đề “thui kỹ năng”: dùng AI nhiều → mất khả năng viết tay, debug sâu.
• 🔐 Lo ngại về bảo mật & bản quyền mã nguồn.
• 📉 Vibe coding không phù hợp khi cần độ chính xác cao (ví dụ: phần mềm tài chính, xử lý concurrency, hệ thống embedded).

Phần 2: Vibe Coding vs AI-assisted Engineering

🧬 1. Hai thái cực trên cùng một phổ

• Tác giả phân tích: đây không phải là đúng/sai mà là sự lựa chọn theo mục tiêu:
  • Vibe Coding: tốc độ, sáng tạo, khám phá ý tưởng
  • AI-assisted Engineering: chất lượng, kiểm soát, duy trì lâu dài

“Vibe coding như jazz即興 (即 hứng khởi). AI-engineering như nhạc cổ điển có bản nhạc rõ ràng.”

🧠 2. Vibe Coding – Lập trình bằng cảm hứng và tốc độ

• Bạn đưa ra ý tưởng tổng thể, AI thực hiện phần còn lại.
• Mô hình: “code by conversation” – bạn nói gì, AI viết đó.
• Tương tự như: “Tôi muốn component dashboard hiển thị filter theo ngày và nút export”
  → AI sinh ra code React + call API + export file.

📌 Dùng khi:

• Hackathon
• Prototype nhanh
• Tự học hoặc học framework mới
• Tạo internal tool CRUD nhanh

🧱 3. AI-assisted Engineering – Có kế hoạch, có kiểm soát

• Bạn bắt đầu bằng một bản thiết kế, PRD nhỏ, hoặc cấu trúc rõ ràng.
• Sau đó nhờ AI thực hiện từng phần cụ thể: tạo component, sinh test, migration…
• 🛠️ Bạn vẫn là người:
  • Viết logic quan trọng
  • Review code AI viết
  • Quyết định integration

📌 Dùng khi:

• Làm việc theo team
• Feature cho sản phẩm chính
• Cần đảm bảo maintainability, review, test coverage

🧰 4. Công cụ & cách dùng khác nhau

Rubber duck debugging là một kỹ thuật lập trình nơi lập trình viên giải thích mã nguồn từng dòng một cho… một con vịt cao su (hoặc bất kỳ đối tượng vô tri nào). Mục đích là để tự mình phát hiện lỗi hoặc hiểu sâu hơn vấn đề thông qua quá trình “giảng giải”.

📘 Nguồn gốc tên gọi: Từ cuốn The Pragmatic Programmer (1999), nơi tác giả kể câu chuyện về một lập trình viên luôn mang theo một con vịt cao su và “giải thích mã” cho nó để tìm lỗi.

📐 5. Ví dụ minh họa

🌀 Vibe Coding

Bạn nói: “Tạo web đếm từ & export PDF với màu nổi bật” → AI tạo app hoàn chỉnh sau vài prompt, không cần chuẩn bị trước.

🧭 AI-assisted Engineering

Bạn viết:

• Yêu cầu component dashboard
• List API, thiết kế UI
• Prompt AI tạo file theo spec
  → Review, viết test, refactor thêm

🚥 6. Tư duy người dùng và kỳ vọng

🚨 7. Nguy cơ khi dùng Vibe Coding quá mức

• Dễ sinh code “black box” → team khác không hiểu.
• Thiếu nhất quáng về thư viện, naming, cấu trúc.
• Tốn thời gian về sau để refactor.
• Vibe coding tốt cho bắt đầu, nhưng không nên kết thúc ở đó.

🧭 8. Hành trình phát triển kỹ năng: từ vibe → engineering

• Nhiều dev mới ban đầu say mê Vibe Coding (“nói là có code”).
• Sau một thời gian, họ chuyển sang tư duy kỹ thuật hơn:
  • Biết cách chia prompt nhỏ
  • Kiểm soát đầu ra
  • Biết “gài sườn” để AI bám theo

Trở thành “người chỉ huy dàn nhạc AI”, không chỉ là “prompt artist”.

Phần 3: Lập trình bằng ý định & nghệ thuật ra lệnh cho AI

🧭 1. Từ hướng dẫn từng bước → mô tả mục tiêu

• Truyền thống: bạn phải chỉ rõ từng bước máy cần làm.
• Giờ đây: bạn chỉ cần nói “Tôi muốn kết quả A” → AI tìm cách thực hiện.
• 🔁 Lập trình trở thành quá trình “mô tả điều bạn muốn” hơn là “dạy máy làm sao để làm”.

Giống như nói “Tôi muốn đến quận 3” và để AI chọn lộ trình, thay vì bạn tự chỉ từng ngã rẽ.

✍️ 2. Prompt – đơn vị tư duy mới của lập trình viên

• Prompt: mô tả hành vi mong muốn bằng ngôn ngữ tự nhiên hoặc pseudocode.
• Quan trọng hơn cú pháp – prompt là cách bạn giao tiếp tư duy với AI.
• Ví dụ: “Đọc file CSV, lọc người trên 18 tuổi, trích email”
  → AI viết đoạn code hoàn chỉnh thực hiện điều đó.

📐 3. Viết prompt tốt = kỹ năng lập trình mới

• Prompt không rõ → AI sẽ đoán và dễ sai.
• Prompt tốt:
  • Cụ thể
  • Có bối cảnh (context)
  • Có mục tiêu rõ ràng
• Em sẽ hướng dẫn chi tiết hơn trong chương 3 (theo sách), nhưng tạm thời: Hãy nghĩ prompt là một tài liệu mô tả yêu cầu (spec) súc tích.

🔁 4. Chu trình cộng tác người + AI

🎼 Giống như bạn và AI cùng “soạn nhạc”: AI gợi đoạn nhạc, bạn chỉnh lại để ra bản final.

🎯 5. Lập trình theo ý định = thử nghiệm liên tục

• Một prompt không cần đúng hoàn hảo từ đầu.
• AI cho bạn phản hồi ngay → bạn tinh chỉnh prompt hoặc code.
• 🧪 Khuyến khích tinh thần thử – sai – sửa nhanh.
• Đây là điểm mạnh: chi phí “sai” rất thấp → bạn dám sáng tạo hơn.

📈 6. Tác động đến nghề lập trình

• Lập trình viên:
  • Viết ít code hơn
  • Thiết kế & validate nhiều hơn
• Kỹ năng mới:
  • Biết mô tả yêu cầu đúng cách
  • Biết cách kiểm tra, chỉnh sửa code AI tạo ra
  • Trở thành người định hướng, kiểm tra, và tối ưu đầu ra

🔧 AI viết nhanh, nhưng con người vẫn cần biết đúng sai và tại sao.

Phần 4: Khi nào nên dùng Vibe Coding? Khi nào nên cẩn trọng?

🌟 1. Tình huống lý tưởng để dùng Vibe Coding

✅ 1.1. Dự án từ số 0 (Zero-to-One)

• Khi bạn cần tạo prototype nhanh, chưa cần tối ưu.
• Ví dụ: app MVP cho startup, sản phẩm demo hackathon.

🧱 1.2. Tính năng CRUD và ứng dụng nội bộ

• AI cực mạnh trong việc sinh:
  • Model, API, UI form
  • Validations và logic đơn giản
• Các tác vụ như: “Thêm màn hình quản lý Inventory” → prompt → xong.

🔗 1.3. Code tích hợp và “glue code”

• Kết nối API, xử lý định dạng dữ liệu, chuyển đổi JSON, v.v.
• AI đọc được docs → sinh sẵn đoạn code dùng thư viện phù hợp.

🧑‍💻 1.4. Dùng framework phổ biến

• AI rất giỏi với: React, Next.js, Django, Express, Laravel…
• Sinh component, gọi API, route, config, test đều làm tốt.

🔁 1.5. Sinh code lặp lại

• Tạo 10 function gần giống nhau?
• Viết 50 model theo schema?
  → Prompt 1 lần → AI sinh hàng loạt.

⚠️ 2. Những điểm yếu cần cảnh giác

🧩 2.1. Hệ thống phức tạp, logic mới lạ

• AI dễ sai khi chưa từng “thấy” bài toán kiểu đó trước.
• Ví dụ: viết trình biên dịch, tính toán đồng thời, giải thuật tối ưu hóa…

🧠 2.2. Tối ưu hệ thống cấp thấp

• AI không đủ hiểu về:
  • Quản lý bộ nhớ
  • SIMD, Assembly, hệ thống nhúng
• Có thể sinh code sai hoặc không tối ưu.

🔒 2.3. Bảo mật và chất lượng mã nguồn

• AI có thể dùng thư viện lỗi thời hoặc thiếu kiểm tra lỗi nghiêm ngặt.
• Ví dụ: sinh hệ thống login dùng thuật toán mã hóa yếu.

📚 2.4. Framework mới hoặc quá đặc thù

• Nếu thư viện hoặc framework quá mới (hoặc ít người dùng), AI không biết rõ.
• Kết quả: code có thể sai hàm, sai cấu trúc.

🎨 2.5. Thiết kế UI sáng tạo

• AI giỏi tạo layout quen thuộc (form, table…), nhưng không giỏi sáng tạo UX độc đáo.

🧭 3. Cách tận dụng AI một cách thông minh

🔁 4. Quy tắc vàng khi dùng Vibe Coding

“Let AI handle the boring; let humans handle the clever.”
→ AI làm nhanh, nhưng con người quyết định chất lượng.

• Kiểm tra code AI như bạn kiểm tra code của thực tập sinh.
• Đừng deploy nếu bạn không hiểu code đó.
• Đừng sợ sửa lại hoặc bỏ đi – AI có thể tạo lại dễ dàng.

✨ 5. Tóm tắt lợi ích chính của Vibe Coding

✅ Tăng tốc phát triển (10x–100x)
✅ Giúp lập trình viên giữ “flow” tốt hơn
✅ Giảm rào cản kỹ thuật cho người mới
✅ Mở rộng khả năng lập trình cho PM, marketer, nhà thiết kế sản phẩm

🚨 6. Tóm tắt rủi ro – cần tỉnh táo

❌ Không hiểu rõ code AI tạo → dễ gây lỗi ngầm
❌ Kỹ năng nền giảm nếu lệ thuộc
❌ Code AI có thể thiếu security, best practices
❌ Prompt kém → AI sinh kết quả lệch mục tiêu
❌ Rủi ro về bản quyền & bảo mật (nếu dùng AI online)

Phần 5: Hệ sinh thái công cụ Vibe Coding

🧑‍💻 1. Cursor – IDE AI thân thiện cho vibe coder

• Fork từ VS Code, tích hợp AI ngay trong editor.
• Bạn có thể:
  • Bôi đoạn code → yêu cầu AI optimize / sửa lỗi
  • Nhập prompt → AI sinh code mới hoặc refactor
• Composer mode: tạo nhiều bước liên tục theo luồng logic.
• Dùng Claude hoặc GPT tùy cấu hình.
• Miễn phí: đưa diff → bạn tự accept
  Pro: có thể auto-apply thay bạn.

🌊 2. Windsurf – IDE AI thông minh và dũng cảm

• Được xây bởi team Codeium.
• Index toàn bộ codebase → hiểu toàn dự án.
• Chế độ Cascade + Write:
  • Gợi ý nhiều file cùng lúc
  • Tự tạo + sửa file → như dev junior thực thụ
• Phù hợp dự án lớn, refactor hệ thống, multi-layered fix.

🤖 3. Claude (Sonnet) – “động cơ AI” phổ biến nhất hiện nay

• Dùng nhiều trong Cursor & Windsurf.
• Ưu điểm:
  • Nhanh, gọn, ít lỗi
  • Hiểu context dài
  • Xử lý code đa bước rất tốt
• Lý tưởng cho dev chuyên nghiệp vibe coding tốc độ cao.

🧠 4. Claude (Opus) – phiên bản “suy luận sâu”

• Chậm hơn, nhưng mạnh hơn khi:
  • Debug sâu
  • Làm bài toán logic nhiều bước
• Dùng khi Claude Sonnet thất bại hoặc cần giải thích dài dòng.

📚 5. Claude 0.x – phiên bản “tâm sự nhiều”

• Thích hợp brainstorming, mô tả logic, đọc hiểu.
• Không giỏi viết code chính xác, nhưng có “tư duy từng bước” hữu ích.
• Dùng như… một vịt cao cấp 🦆

🗨️ 6. ChatGPT (GPT-4) – cố vấn AI toàn năng

• Không tích hợp trực tiếp codebase, nhưng:
  • Giải thích code
  • Phân tích lỗi
  • Tư vấn cấu trúc / kiến trúc / quyết định
• Rất mạnh trong:
  • Rubber duck debugging
  • So sánh giải pháp
  • Học framework / kiến thức nền

Nghệ thuật ra lệnh cho AI (Prompting an AI)

Phần 1: Tại sao prompt lại quan trọng?

🧠 1. Lập trình viên trong thời đại mới = người biết prompt

• Trong môi trường AI hỗ trợ lập trình, cách bạn nói chuyện với AI = kỹ năng quyết định chất lượng sản phẩm.
• Prompt tốt → AI viết đúng thứ bạn cần
• Prompt dở → AI tưởng bạn cần A, nhưng lại tạo ra B

❝ A bad prompt wastes 5 minutes. A great prompt saves 5 hours. ❞

🎯 2. Prompt tốt giống như một đặc tả kỹ thuật súc tích

• Prompt càng rõ, càng cụ thể → AI càng dễ hiểu
• Cấu trúc 1 prompt hiệu quả gần giống như:
  • Nhiệm vụ: Tôi muốn bạn làm gì
  • Bối cảnh: Dự án hoặc khung làm việc là gì
  • Định dạng đầu ra: Tôi muốn kết quả ra sao (code, markdown, bảng…)
  • Ràng buộc: Phải dùng lib gì, tránh điều gì…

🪞 3. Prompt là bản sao của tư duy bạn

• Prompt chưa rõ → nghĩa là bạn chưa rõ mình muốn gì
• Quá trình viết prompt = quá trình:
  • Suy nghĩ lại yêu cầu
  • Diễn đạt lại mục tiêu
  • Kiểm tra xem logic có mạch lạc không

Prompt giỏi → logic rõ → kết quả chuẩn
Prompt loạn → AI hoang mang → output tào lao

🧗 4. Không có prompt “tuyệt đối”, chỉ có prompt “phù hợp”

• Tuỳ công cụ, context và mục tiêu → cần điều chỉnh cách prompt:
  • Claude thích prompt “tự nhiên, đối thoại”
  • GPT-4 thích prompt rõ ràng, cấu trúc chặt
  • Cursor thích prompt ngắn gọn và kèm đoạn code bôi đen

⚒️ 5. Cách luyện kỹ năng prompt

Phần 2: Phân loại prompt theo mục tiêu sử dụng

🔧 1. Prompt kỹ thuật (Mechanical prompts)

📌 Dùng khi bạn đã biết rõ mình muốn AI làm gì.

Đặc điểm:

• Rõ ràng, cụ thể
• Tập trung vào đầu ra đúng định dạng
• Gần giống “mệnh lệnh” hơn là đối thoại

Ví dụ:

Viết một hàm sumArray trong JavaScript nhận một mảng và trả về tổng các phần tử. Không dùng .reduce.

👉 Dễ đánh giá đúng/sai, phù hợp khi:

• Sinh boilerplate
• Viết test case
• Sinh migration hoặc config

🧠 2. Prompt khai phá (Exploratory prompts)

📌 Dùng khi bạn chưa biết rõ giải pháp, cần AI gợi ý.

Đặc điểm:

• Mở, gợi ý hướng đi
• Có thể lặp nhiều lần
• Thường dùng để brainstorming

Ví dụ:

Tôi muốn xây một hệ thống đặt lịch học cho sinh viên. Có những cách nào để lưu thông tin này trong MongoDB?

👉 Dễ mở rộng, phù hợp cho:

• Thiết kế hệ thống
• So sánh giải pháp
• Tìm hướng tiếp cận mới

👤 3. Prompt đóng vai (Role-based prompts)

📌 Dùng để bắt AI nhập vai cụ thể → dẫn đến phong cách trả lời khác.

Đặc điểm:

• Có phần mở đầu như “Bạn là một…”
• Thay đổi cách AI diễn giải vấn đề

Ví dụ:

Bạn là một kỹ sư bảo mật giàu kinh nghiệm. Hãy xem đoạn code dưới đây có vấn đề gì không về bảo mật.

👉 Giúp AI:

• Có quan điểm rõ ràng hơn
• Giao tiếp theo phong cách phù hợp

🧩 4. Prompt “thử rồi sửa” (Scaffold-and-Refine prompts)

📌 Dùng để yêu cầu AI viết 1 phần, sau đó tiếp tục bổ sung.

Ví dụ quy trình:

1. Prompt 1: Viết form tạo user bằng Angular.
2. Prompt 2: Giờ thêm validation email.
3. Prompt 3: Thêm nút lưu + gọi API /create-user.

👉 Phù hợp khi:

• Xây dựng UI nhiều bước
• Viết pipeline xử lý
• Refactor từng phần

📝 5. Prompt phản hồi (Feedback prompts)

📌 Dùng để hỏi AI đánh giá lại code, logic, UI…

Ví dụ:

Có cách nào viết lại đoạn mã sau ngắn gọn và dễ test hơn?

👉 Tạo vòng lặp kiểm tra chất lượng:

• Giúp bạn học từ chính AI
• Phát hiện vấn đề mà bạn không thấy

Phần 3: Kỹ thuật viết prompt hiệu quả theo từng loại

🔧 1. Mechanical Prompt – viết prompt kỹ thuật “gãy gọn”

📌 Mục tiêu: Output rõ ràng, dễ kiểm chứng đúng/sai

✅ Mẫu cấu trúc:

Viết một hàm [tên] bằng [ngôn ngữ] nhận đầu vào [cụ thể] và trả về [kết quả mong muốn]. Không dùng [giới hạn nếu có].

🎯 Bí quyết:

• Luôn mô tả rõ input/output (kiểu dữ liệu, điều kiện)
• Nếu cần giới hạn: hãy nói rõ (“không dùng sort”, “không dùng thư viện ngoài”)
• Gợi ý format: JSON, markdown, plain text…

🧠 2. Exploratory Prompt – prompt để khám phá ý tưởng

📌 Mục tiêu: Khám phá không gian giải pháp, tạo brainstorming

✅ Mẫu cấu trúc:

Tôi đang [nhiệm vụ/chức năng]. Có những cách nào để [đạt mục tiêu]? Ưu/nhược điểm của từng cách?

🎯 Bí quyết:

• Nêu rõ context: sản phẩm, mục tiêu, công nghệ đang dùng
• Yêu cầu AI so sánh, phân tích → tránh trả lời chung chung
• Dùng follow-up để đào sâu từng hướng

👤 3. Role-based Prompt – prompt cho AI nhập vai

📌 Mục tiêu: Thay đổi cách AI suy nghĩ & trả lời

✅ Mẫu cấu trúc:

Bạn là một [vai trò]. Với kinh nghiệm của mình, bạn sẽ đánh giá đoạn code sau như thế nào?

🎯 Bí quyết:

• Chọn vai trò phù hợp: senior engineer, frontend architect, DevOps expert…
• Có thể kết hợp với exploratory hoặc feedback prompt để tạo chiều sâu

🧩 4. Scaffold-and-Refine Prompt – prompt từng bước

📌 Mục tiêu: Xây kết quả phức tạp theo từng bước

✅ Chiến thuật:

1. Giao nhiệm vụ đơn giản đầu tiên (scaffold)
2. Gửi lại kết quả, yêu cầu chỉnh (refine)
3. Lặp lại cho đến khi đạt yêu cầu

🎯 Bí quyết:

• Coi AI như junior: đừng giao 1 lần xong, hãy giao dần từng bước
• Gắn nhãn từng đoạn: “Đây là phần service”, “Đây là controller” → giúp AI chia file

📝 5. Feedback Prompt – prompt để xin nhận xét

📌 Mục tiêu: Kiểm tra code, logic, viết lại cho tốt hơn

✅ Mẫu cấu trúc:

Hãy xem đoạn mã dưới đây. Có cách nào làm ngắn gọn hơn, dễ test hơn không?

🎯 Bí quyết:

• Nếu muốn rewrite: hãy nói rõ “viết lại với [tiêu chí]”
• Nếu muốn chỉ lỗi: yêu cầu “tìm bug hoặc vấn đề security/UX”

Phần 4: Những lỗi phổ biến khi viết prompt khiến AI “bối rối” hoặc “phá game”

❌ 1. Prompt quá mơ hồ

Viết cho tôi một hàm xử lý người dùng.

🔻 Lỗi: Không rõ xử lý là gì? Validate? Lưu DB? Tạo user mới?
✅ Cách sửa:

Viết hàm tạo user mới với các field: name, email, password. Lưu vào MongoDB. Trả về object đã lưu.

❌ 2. Giao việc quá nhiều trong một prompt

Viết một component Angular hiển thị danh sách sản phẩm, có filter, sort, phân trang, và gọi API.

🔻 Lỗi: AI dễ “bỏ sót” phần hoặc viết lộn xộn.
✅ Cách sửa:

Viết component Angular hiển thị danh sách sản phẩm từ API /products. Gồm: tiêu đề, giá, mô tả. Chưa cần filter hay sort.

→ Sau đó tiếp tục: “Thêm filter theo giá dưới 500k” → “Thêm sort theo tên”…

❌ 3. Không nói rõ ràng định dạng đầu ra

Tạo cho tôi một schema

🔻 Lỗi: Schema gì? JSON? SQL? Mongoose?
✅ Cách sửa:

Tạo Mongoose schema cho bảng User gồm: name (string), email (unique), createdAt (Date, default Now)

❌ 4. Quên nói rõ bối cảnh / hệ sinh thái

Viết middleware kiểm tra token

🔻 Lỗi: Express hay NestJS?
✅ Cách sửa:

Viết middleware kiểm tra JWT token trong NestJS. Nếu không hợp lệ, trả về 401.

❌ 5. Không dùng ví dụ minh hoạ

Hãy giúp tôi tối ưu prompt này

🔻 Lỗi: AI không biết prompt đó là gì
✅ Cách sửa:

Đây là prompt gốc của tôi: “Viết hàm tính điểm học sinh”. Hãy gợi ý cách viết lại để AI hiểu tốt hơn.

Hai vòng phản hồi trong kỹ năng prompt

🎯 Mục tiêu của chương:

Giúp bạn hiểu rằng việc viết prompt hiệu quả không chỉ là chuyện viết hay, mà còn liên quan đến việc quan sát phản hồi và điều chỉnh liên tục.

Phần 1: Hai vòng phản hồi – bên ngoài & bên trong

🔄 1. Vòng phản hồi bên ngoài (External Feedback Loop)

📌 Đây là phản hồi từ chính AI sau khi bạn gửi prompt:

• AI trả lời tốt? → Tiếp tục
• AI trả lời sai? → Cần sửa prompt

💡 Đây là cách bạn luyện tập kỹ năng:

• Thử prompt A → Nhận phản hồi → Sửa thành A′ → Tiếp tục
• Mỗi vòng như vậy làm bạn hiểu hơn:
  • AI hiểu sai ở đâu?
  • Có chi tiết nào chưa rõ?
  • Có cần chia nhỏ nhiệm vụ không?

🧠 2. Vòng phản hồi bên trong (Internal Feedback Loop)

📌 Đây là suy nghĩ bên trong của bạn khi đọc output của AI:

• Mình có hiểu rõ vấn đề chưa?
• Liệu đây có phải thứ mình thật sự muốn không?
• Có cách nào khác tốt hơn không?

💬 Prompt không chỉ là “ra lệnh”, mà còn là gương phản chiếu tư duy của bạn.

Việc bạn không biết prompt gì → thường là dấu hiệu bạn chưa hiểu rõ bài toán của chính mình.

🔍 So sánh 2 vòng phản hồi:

Phần 2: Cách áp dụng 2 vòng phản hồi trong thực tế

⚙️ 1. Khi thiết kế hệ thống hoặc giải bài toán phức tạp

Quy trình:

1. Viết prompt mở đầu (Exploratory prompt): Tôi cần xây hệ thống đặt lịch khám bệnh. Có những kiến trúc nào phù hợp?
2. Quan sát vòng phản hồi bên ngoài:
   • AI liệt kê 3 kiến trúc: monolith, microservice, event-driven.
   • Nhưng giải thích không rõ, hoặc quá chung chung.
3. Kích hoạt vòng phản hồi bên trong:
   • “Mình chưa nói rõ số lượng người dùng, loại lịch, quy mô hệ thống…”
   • “Chắc mình cần nói rõ là dùng MongoDB và hoạt động theo mô hình B2C.”
4. Viết lại prompt tốt hơn: Tôi cần kiến trúc cho hệ thống đặt lịch khám bệnh online B2C. Dùng MongoDB, cần khả năng scale đến 100k user. Gợi ý kiến trúc phù hợp.

✅ Kết quả: Prompt rõ hơn, AI trả lời sâu hơn, bạn hiểu chính mình rõ hơn.

🧑‍💻 2. Khi viết code cùng AI

Vòng phản hồi bên ngoài:

Viết middleware NestJS kiểm tra JWT

• AI viết sai: dùng sai thư viện hoặc logic kiểm tra token không đúng

→ Bạn phải quay lại kiểm tra prompt:

• Có nói rõ là “NestJS”? Có nói “dùng thư viện nào”? Có yêu cầu xử lý lỗi cụ thể không?

Vòng phản hồi bên trong:

• Bạn đọc code → không hiểu logic → tự hỏi: “Tại sao mình không tự viết thử logic trước khi nhờ AI?”

💬 Lúc này, vòng phản hồi bên trong giúp bạn tránh phụ thuộc AI mù quáng.

🧪 3. Khi thử nghiệm UI hoặc thiết kế

“Tôi muốn thiết kế một màn hình đăng ký học online đơn giản. Gồm 3 bước: chọn khóa, điền thông tin, thanh toán.”

• Phản hồi bên ngoài:
  AI tạo UI 3 bước, nhưng layout thiếu responsive → bạn yêu cầu thêm detail về mobile view
• Phản hồi bên trong:
  Bạn nhận ra mình chưa định nghĩa rõ UX cho từng bước → prompt chưa đủ tốt

✅ Cải thiện:

Thiết kế 3 bước đăng ký khóa học. Ở mỗi bước, cần nêu rõ feedback user, cách xử lý lỗi, và UX cho mobile.

🧠 Kết luận:

“Viết prompt = viết spec + luyện tư duy + trò chuyện với chính mình.”

Nếu bạn luyện cả 2 vòng phản hồi thường xuyên, bạn không chỉ dùng AI tốt hơn, mà còn hiểu công việc của mình rõ hơn, đặc biệt trong các giai đoạn:

• Lập kế hoạch
• Brainstorm
• Coding
• Refactoring
• Đánh giá chất lượng sản phẩm

Phần 3: Hướng dẫn tự luyện tập 2 vòng phản hồi – như một kỹ năng nghề nghiệp

📌 Mục tiêu:

Biến việc viết prompt và phản hồi từ AI thành một chu trình học chủ động – giúp bạn:

• Giỏi hơn qua từng lần dùng AI
• Tránh lệ thuộc mù quáng
• Rèn tư duy rõ ràng, sắc bén hơn

🧪 Bài tập 1: Viết và sửa một prompt ít nhất 3 lần

1. Bắt đầu với một vấn đề mơ hồ Viết cho tôi một API gửi email
2. Gửi prompt – ghi nhận output
3. Phản hồi bên ngoài:
   • AI viết đúng không?
   • Output có đầy đủ không?
4. Phản hồi bên trong:
   • Mình thật sự muốn API có log lại không?
   • Có cần dùng thư viện cụ thể không?
5. Sửa prompt → gửi lại Viết API NestJS gửi email bằng Nodemailer. Input gồm: to, subject, content. Có log gửi vào file email.log.

🔁 Làm lại 2–3 vòng → bạn sẽ luyện được “prompt engineering muscle”.

✅ Checklist sau mỗi lần viết prompt:

📈 Thói quen đề xuất để nâng cao kỹ năng:

• 🧘‍♂️ Sau mỗi prompt, dành 30 giây để ghi lại:
  • Điều gì AI hiểu sai?
  • Điều gì bạn học được từ phản hồi?
• 📔 Tạo “Prompt Logbook” – ghi chép:
  • Prompt gốc
  • Output nhận được
  • Prompt sau khi sửa
  • Bài học rút ra
• 🎯 Tập trung vào các kỹ năng sau:
  • Mô tả đầu vào / đầu ra rõ ràng
  • Chia nhỏ yêu cầu
  • Diễn đạt logic bằng từ ngữ đơn giản

Khi nào nên dùng Vibe Coding (và khi nào KHÔNG nên dùng)

💡 Tóm tắt:

Vibe Coding là một cách tiếp cận khám phá và tự do, rất mạnh khi làm việc sáng tạo. Nhưng nó không phù hợp mọi lúc.
Chương này giúp bạn biết lúc nào nên thả lỏng với AI, lúc nào cần kiểm soát chặt.

Phần 1: Các tình huống nên dùng Vibe Coding

🎨 1. Khi bạn chưa rõ cần gì – và muốn khám phá

• Ví dụ: Bạn đang thử nghiệm UI mới cho một hệ thống nội bộ.
• ✅ Vibe Coding giúp bạn:
  • Viết ra nhiều phiên bản cùng lúc
  • Nhanh chóng đánh giá cái nào “ổn vibe” → chọn rồi refine

💬 “Hãy thử tạo 3 giao diện hiển thị danh sách tài khoản, mỗi cái theo một phong cách khác nhau.”

💭 2. Khi bạn cần ý tưởng, không cần sự hoàn hảo

• Ví dụ: Viết nội dung onboarding, brainstorm tên hàm, đặt biến gợi cảm hứng
• Không cần chính xác tuyệt đối → AI có thể “phiêu” cùng bạn

🧠 “Gợi ý 5 tên hàm cho chức năng lọc dữ liệu người dùng, mang phong cách hài hước.”

🔧 3. Khi bạn muốn tạo prototype nhanh (chấp nhận “xài tạm”)

• Viết nhanh một giao diện, endpoint mẫu, hàm tính sơ bộ
• Sau đó mới quay lại refactor sau

⏱ “Viết tạm code Node.js lấy dữ liệu từ URL, parse JSON và log ra console – không cần try-catch.”

🎯 4. Khi bạn đang viết những thứ “không nguy hiểm”

• Ví dụ:
  • Mẫu email
  • Slide thuyết trình
  • Tài liệu nội bộ
• Lúc này, sự sáng tạo và tốc độ quan trọng hơn độ chính xác tuyệt đối

Phần 2: Khi nào KHÔNG nên dùng Vibe Coding

⚠️ 1. Khi làm việc với hệ thống phức tạp và rủi ro cao

Ví dụ: Viết hàm xử lý thanh toán, bảo mật, xác thực, quyền truy cập…

💣 Nếu AI “phiêu” sai → lỗi nghiêm trọng → mất dữ liệu, mất tiền, vi phạm bảo mật.

✅ Giải pháp:

• Dùng AI-assisted engineering thay vì Vibe Coding
• Bạn phải biết mình đang làm gì, hiểu logic, dùng test, validation rõ ràng

🛑 2. Khi bạn đang làm việc trong nhóm

Vibe Coding có thể tạo ra code hoặc logic “vô vibe” với người khác

• Code khó đọc
• Thiếu naming rõ ràng
• Không tuân thủ standard của team

✅ Giải pháp:

• Viết prompt rõ: “Tuân theo chuẩn của team X”
• Hoặc chỉ dùng Vibe Coding ở bước cá nhân → sau đó refactor và commit

📉 3. Khi bạn chưa hiểu bài toán – nhưng lại phó mặc cho AI

Ví dụ: Giao cho AI viết microservice mà bạn chưa hiểu cách giao tiếp giữa các phần

❌ Hậu quả:

• Bạn tưởng đã xong, nhưng thực ra không hiểu gì
• Rủi ro “ảo tưởng tiến độ” – có code nhưng không usable

✅ Giải pháp:

• Tạm dừng → phân tích rõ luồng nghiệp vụ → viết sơ đồ
• Sau đó mới dùng AI để hỗ trợ triển khai chi tiết

👨‍⚖️ 4. Khi output của bạn sẽ được review, kiểm toán hoặc dùng để đào tạo

Ví dụ:

• Tài liệu kỹ thuật nội bộ
• Coding guideline
• Dữ liệu huấn luyện cho mô hình AI khác

❗ Vibe Coding thường có lỗi nhỏ, không nhất quán, hoặc diễn đạt “quá freestyle”

✅ Giải pháp:

• Dùng role-based prompting: “Bạn là tech writer”, “Bạn là senior engineer…”
• Yêu cầu rõ format, tiêu chuẩn đầu ra

🧠 Tổng kết phần này:

Phần 3: Cách kết hợp Vibe Coding và AI-assisted Engineering hiệu quả

🔀 Ý tưởng chính:

Bạn không cần chọn 1 trong 2. Thay vào đó, hãy kết hợp theo tình huống:

• Vibe Coding: dùng khi khám phá, cần tốc độ và sự linh hoạt
• AI-assisted Engineering: dùng khi cần tính đúng đắn, kiểm soát, cộng tác nhóm

🧪 Ví dụ quy trình kết hợp:

🎨 Bước 1: Dùng Vibe Coding để khởi động

“Gợi ý 3 cách hiển thị dữ liệu biểu đồ cho dashboard tài chính.”

• Ghi chú lại các cách có tiềm năng
• Lựa chọn hướng phù hợp

🔍 Bước 2: Chuyển sang kỹ thuật kiểm soát

“Viết lại component Angular hiển thị biểu đồ tài chính theo hướng X, dùng chart.js, có responsive.”

• Bắt đầu yêu cầu rõ hơn
• Bắt đầu validate từng phần code
• Test logic, refactor, naming theo tiêu chuẩn

🧠 Bước 3: Feedback lại quy trình

• Bạn học được gì?
• Có phần nào quá “vibe” gây lỗi không?
• Có phần nào AI giúp bạn khám phá tốt không?

💡 Gợi ý chia tỉ lệ:

Tại sao AI-Enhanced Engineering lại khác biệt?

🎯 Mục tiêu:

Hiểu sự khác biệt sâu sắc giữa cách làm phần mềm truyền thống và kỹ thuật phần mềm tăng cường bởi AI (AI-enhanced engineering).
Chương này giúp bạn:

• Nhận ra những kỹ năng mới cần có
• Thay đổi cách tư duy về việc viết code
• Tạo nền tảng để áp dụng hiệu quả các công cụ AI

Phần 1: Lập trình truyền thống vs. Lập trình tăng cường bởi AI

🧱 Trường phái cũ: Lập trình truyền thống

• Bạn biết rõ mình cần làm gì
• Viết code bằng tay, kiểm soát 100%
• Làm theo:
  🧠 Ý tưởng → ✍️ Code → ✅ Kiểm thử → 📦 Deploy

🤝 Lập trình cùng AI: Một kiểu hợp tác mới

• Bạn không làm một mình nữa
• AI là bạn đồng hành trong tư duy & triển khai
• Mọi thứ đều có thể thương lượng, không còn đúng/sai tuyệt đối

💬 So sánh:

Phần 2: Những kỹ năng mới khi làm kỹ sư thời AI

🧩 1. Tư duy hệ thống (Systems Thinking)

Bạn không chỉ viết từng hàm → mà xây nên một quy trình hợp tác giữa người và AI

• Biết phân chia công việc: “phần này AI lo, phần kia mình kiểm”
• Biết dùng AI không chỉ để viết code, mà còn:
  • Tạo schema
  • Sinh test
  • Viết tài liệu
  • Đánh giá hiệu năng

💬 “Tôi sẽ để AI đề xuất các trường dữ liệu trước, sau đó tôi tinh chỉnh lại logic.”

🔍 2. Kỹ năng đánh giá và kiểm chứng (Validation over Generation)

Trong AI-enhanced engineering, viết prompt giỏi chưa đủ – bạn phải biết kiểm tra kỹ output của AI.

• Gỡ lỗi prompt, debug code AI sinh ra
• So sánh với spec, tiêu chuẩn của dự án
• Luôn có tâm thế: “AI không sai, nhưng chưa đúng với mình”

🔧 3. Phân tách trách nhiệm rõ ràng (Human-in-the-loop Design)

Không phải cái gì cũng đưa cho AI

Bạn cần:

• Xác định cái gì nên tự làm
• Cái gì nên để AI hỗ trợ
• Cái gì nên kiểm thử kỹ

✅ Ví dụ:

🧠 4. Tư duy điều phối Prompt (Prompt Orchestration)

Giống như bạn “quản lý nhiều AI nhỏ” cùng lúc

• Dùng prompt để chia task
• Tái sử dụng prompt như module
• Xây prompt có cấu trúc:
  • Input rõ
  • Format output cố định
  • Có ví dụ minh họa

💬 “Tôi có 3 prompt: 1 cái viết code, 1 cái sinh test, 1 cái review logic. Tôi dùng lần lượt theo pipeline.”

Phần 3: Từ “người dùng AI” → thành “kỹ sư chủ động”

🎯 Mục tiêu chuyển đổi:

Không chỉ hỏi AI làm gì, mà xây cả một hệ thống phối hợp giữa bạn và AI.

🧠 Vai trò mới của kỹ sư phần mềm thời AI:

🔄 Thay đổi mindset cần có:

🧭 Trở thành kỹ sư điều phối (Prompt-Orchestrating Engineer)

Một kỹ sư AI-enhanced giỏi sẽ:

1. Thiết kế luồng prompt cho từng loại task
2. Tối ưu hóa output từ AI như tối ưu hóa code
3. Ghi lại pattern tốt để tái sử dụng cho nhóm

💬 “Thay vì chỉ ‘viết code bằng AI’, tôi đang ‘xây hệ thống sinh code đáng tin cậy’.”

Làm sao để giỏi viết prompt hơn?

🎯 Mục tiêu của chương:

Giúp bạn phát triển kỹ năng viết prompt như một kỹ sư chuyên nghiệp, không chỉ “ra lệnh cho AI” mà thiết kế cả quá trình tương tác hiệu quả.

Viết prompt không phải là “nghệ thuật nói chuyện với AI”, mà là kỹ năng giao tiếp có chiến lược với một hệ thống logic.

Phần 1: Prompt = Specification (Yêu cầu kỹ thuật hóa)

🧠 Prompt không phải là “câu hỏi”, mà là “định nghĩa nhiệm vụ”

✍️ Cấu trúc prompt hiệu quả

Một prompt tốt thường có:

1. Bối cảnh (Context) – Vai trò, ngữ cảnh người dùng
   “Bạn là kỹ sư front-end viết Angular cho hệ thống ngân hàng…”
2. Nhiệm vụ rõ ràng (Task)
   “Viết một component hiển thị danh sách tài khoản…”
3. Định dạng mong muốn (Format)
   “…và xuất ra dưới dạng một file TypeScript đầy đủ có comments.”
4. Ràng buộc cụ thể (Constraints)
   “Dùng RxJS, không dùng external library nào.”
5. Ví dụ minh họa (Example)
   “Ví dụ: đầu vào là array các account có tên, số dư…”

🧠 Ghi nhớ:

Prompt = Spec + Style Guide + Example

Prompt càng giống một tài liệu kỹ thuật – AI càng output chính xác, dễ kiểm soát, dễ debug.

Phần 2: Cách luyện tập để giỏi viết prompt hơn

🪜 Mô hình 3 cấp độ luyện tập kỹ năng prompt

🎯 Level 1: Prompt Tốt = Prompt Rõ

“Mỗi từ bạn viết đều là chỉ dẫn cho AI. Đừng để AI phải đoán.”

✅ Cách luyện:

• Viết lại prompt đã dùng → xem có thể:
  • Thêm bối cảnh?
  • Tách nhiệm vụ thành bước nhỏ hơn?
  • Nói rõ đầu vào / đầu ra?
• Tập viết prompt như viết spec kỹ thuật

🎯 Level 2: So sánh – Chỉnh sửa prompt

Không chỉ “viết”, mà còn so sánh hiệu quả giữa các phiên bản prompt

✅ Cách luyện:

• Cho cùng một nhiệm vụ → viết 2–3 prompt khác nhau
• So sánh:
  • Output nào chính xác hơn?
  • Output nào dễ kiểm tra hơn?
  • Cái nào dễ tái sử dụng hơn?

💬 “Mỗi lần viết prompt là một lần thiết kế UX cho AI.”

🎯 Level 3: Xây thư viện prompt

Không ai nhớ hết – hãy bắt đầu lưu trữ prompt tốt để tái sử dụng

✅ Cách luyện:

• Ghi lại prompt đã dùng hiệu quả:
  • Mô tả bài toán
  • Prompt đã dùng
  • Output mẫu
  • Ghi chú cải tiến (nếu có)
• Dùng Notion, Obsidian, GitHub hoặc Markdown

📘 Gợi ý: tổ chức theo dạng
[task]_[framework]_[output].md
ví dụ: generate_form_angular_markdown.md

Phần 3: Bài tập thực chiến để luyện prompt

“Không có kỹ năng nào thành thục nếu bạn không luyện trong ngữ cảnh thật.”

🔧 Bài tập 1: Viết prompt cho AI viết code

Tình huống:

“Tôi cần viết một hàm lọc danh sách người dùng theo độ tuổi.”

✅ Prompt chưa tốt:

“Viết hàm lọc người dùng theo tuổi.”

✅ Prompt tốt hơn:

“Bạn là kỹ sư backend. Viết một hàm TypeScript nhận vào mảng người dùng có tên và tuổi, trả về danh sách người trên 18 tuổi. Đừng dùng thư viện ngoài. Output gồm code và ví dụ minh họa.”

🎯 Mục tiêu:

• Viết đủ bối cảnh
• Ràng buộc cụ thể
• Có đầu vào / đầu ra rõ ràng

📚 Bài tập 2: Prompt cho AI viết tài liệu kỹ thuật

Tình huống:

“Tôi cần AI giúp viết document cho một component Angular.”

✅ Prompt tốt:

“Bạn là tech writer chuyên về Angular. Viết tài liệu hướng dẫn sử dụng cho component <user-list>, bao gồm input, output, ví dụ minh họa và các lưu ý khi dùng. Format bằng Markdown.”

🎯 Mục tiêu:

• Giao tiếp rõ ràng cho output dạng tài liệu
• Giao vai phù hợp với tone chuyên nghiệp

🛠️ Bài tập 3: Debug prompt

Tình huống:

“AI viết sai định dạng trong câu trả lời.”

✅ Cách luyện:

• Thử thêm "always respond in valid JSON"
• Hoặc "wrap your response in triple backticks"
• So sánh output và rút kinh nghiệm

🎯 Mục tiêu:

• Học cách sửa prompt thay vì sửa output

🌍 Bài tập 4: Tổng hợp thông tin / chuyển ngữ

Tình huống:

“Tôi cần tóm tắt nội dung dài hoặc chuyển thành blog dễ đọc.”

✅ Prompt tốt:

“Bạn là content editor. Tóm tắt đoạn sau thành bài blog thân thiện, giữ lại ví dụ cụ thể và thuật ngữ kỹ thuật. Độ dài dưới 500 từ. Viết như đang nói chuyện với developer junior.”

🎯 Mục tiêu:

• Tập trung tone
• Điều hướng cách AI trình bày