Bộ câu hỏi phỏng vấn Vibe Coding / Agentic Flow

Ghi chú: Bộ câu hỏi này không có một đáp án chuẩn duy nhất. Những “câu trả lời tham khảo” chỉ nhằm kích hoạt suy nghĩ và giúp người đọc xây dựng khung phán đoán riêng.

Đối tượng phù hợp: các nhà phát triển sử dụng hàng ngày các công cụ CLI agentic như Claude Code, Codex, đặc biệt là những người muốn nâng cấp quá trình lập trình với AI từ “trao đổi người-máy” lên “quy trình làm việc kỹ thuật hóa”.

Mục lục

1. Phần kiến thức nền 2. Phần tổng hợp chi tiết 3. Phần quy trình công việc 4. Phần thiết kế hệ thống: suy luận mở 5. Phần triết học khái niệm: suy luận mở 6. Phụ lục: lộ trình học tập khuyến nghị 7. Tài liệu tham khảo

Một, phần kiến thức nền

Q1. /command là gì? Khác gì với skill? Khi nào dùng command, khi nào dùng skill?

Câu trả lời tham khảo

/command, hay Slash Command, là cơ chế mở rộng giai đoạn đầu của Claude Code. Người dùng có thể đặt file .md dưới .claude/commands/, rồi kích hoạt bằng cách nhập /command-name trong cuộc hội thoại. Bản chất, đây là “một đoạn prompt do người dùng chủ động gọi”.

Skill là cơ chế mở rộng thế hệ mới, thường nằm trong .claude/skills/<name>/SKILL.md, ~/.claude/skills/ hoặc plugin. Sự khác biệt chính giữa nó với command là:

Trong thực tế, gần như mọi tình huống mới nên ưu tiên dùng skill. Đặc biệt khi bạn muốn mô hình tự động kích hoạt quy trình phù hợp ở thời điểm cần thiết, hoặc cần kèm script, file ví dụ, template, thì skill phù hợp hơn.

command vẫn có thể dùng trong vài tình huống đơn giản, ví dụ tài sản legacy của team, hoặc một số prompt wrapper bắt buộc phải do người dùng kích hoạt trực tiếp. Nhưng trong dự án mới không nên tiếp tục phụ thuộc nhiều vào command.

Q2. Agent là gì? Khi nào nên dùng agent, khi nào nên dùng skill?

Câu trả lời tham khảo

Agent, đặc biệt là Sub-agent, có thể hiểu là một “phiên Claude nhỏ” có system prompt riêng, cửa sổ ngữ cảnh riêng, danh sách tool riêng. Trong Claude Code, sub-agent thường được định nghĩa qua .claude/agents/<name>.md và được cuộc hội thoại chính phân phối nhiệm vụ. Sau khi sub-agent hoàn thành, nó chỉ trả về bản tóm tắt cho hội thoại chính; phần lớn đầu ra đọc file, logs, output công cụ không làm bẩn ngữ cảnh chính.

Skill thì là một tập quy tắc hoặc thủ tục. Nó không mở ngữ cảnh mới, mà hướng dẫn Claude trong cùng cuộc hội thoại về cách làm tiếp theo.

Một nguyên tắc đơn giản để phân biệt:

• Nếu nhiệm vụ là dạy Claude một quy trình, ví dụ “trước khi commit hãy chạy lint và test”, dùng skill.
• Nếu nhiệm vụ sinh ra nhiều output của tool, ví dụ đọc hàng chục file, chạy nhiều lệnh grep, phân tích log, dùng agent.
• Nếu nhiệm vụ chỉ đọc một file đã biết, đọc trực tiếp ở hội thoại chính là đủ, không cần mở agent.
• Nếu bạn cần giữ toàn bộ quá trình suy luận trong hội thoại chính, đừng giao cho sub-agent.

Q3. Sub-agent là gì? Các sub-agent có thể giao tiếp với nhau không?

Câu trả lời tham khảo

Đặc điểm cốt lõi của sub-agent là ngữ cảnh độc lập, bộ tool độc lập, và chỉ trả về summary cho hội thoại chính.

Theo mặc định, các sub-agent không thể giao tiếp trực tiếp với nhau. Mô hình giao tiếp của chúng giống kiến trúc sao: hội thoại chính là nút trung tâm, mọi sub-agent chỉ nói chuyện với hội thoại chính. Nếu phát hiện của agent A cần chuyển cho agent B, thường cần hội thoại chính chuyển tải.

Thiết kế này có ưu điểm:

• Thông tin được tập trung về hội thoại chính, dễ kiểm toán cho người dùng.
• Tránh việc các agent tự nói chuyện vòng tròn ngoài kiểm soát.
• Ngăn bùng nổ chi phí ngữ cảnh và chi phí công cụ.

Mô hình Agent Teams thử nghiệm có thể đưa vào khả năng truyền thông giữa các agent cùng cấp, nhưng đó là một mô hình hợp tác phức tạp hơn hoàn toàn.

Q4. Sự khác nhau lớn nhất giữa Agent Team và Sub-agent là gì?

Câu trả lời tham khảo

Sub-agent giống như “thuê một cộng tác viên tạm thời làm một việc rồi báo cáo lại”. Nó thường mang tính một lần: hội thoại chính giao task, sub-agent thực hiện, rồi trả về summary.

Agent Team giống như “lập một nhóm cộng tác lâu dài”. Mỗi teammate có thể có vai trò, ngữ cảnh độc lập, và có khả năng trao đổi thông tin liên tục qua cơ chế message.

Trong thực tế, hầu hết tác vụ phát triển hàng ngày đã đủ dùng sub-agent. Agent Team gần hơn với hướng nghiên cứu hợp tác đa-agent, thích hợp cho dự án phức tạp, nhưng khó debug hơn.

Q5. MCP là gì? Khác gì với giao diện API?

Câu trả lời tham khảo

MCP, hay Model Context Protocol, là giao thức tiêu chuẩn hóa việc công khai công cụ, tài nguyên và prompt cho client của mô hình theo dạng chuẩn hóa. Một MCP server có thể khai báo các tools, resources, prompts nào nó cung cấp; sau khi client kết nối có thể tự động khám phá và gọi.

Có thể hiểu sự khác biệt giữa API “thô” và MCP như sau:

So sánh nhanh: API là “dây giao tiếp cầm tay làm theo nhiều kiểu khác nhau”, MCP gần giống “cổng USB-C cho gọi tool của LLM”.

Giá trị cốt lõi của nó không chỉ là truyền dữ liệu mà là giúp công cụ có “khả năng tự mô tả”: mô hình biết tên tool là gì, tham số nào, có khả năng ghi không, cần xác nhận không, từ đó suy luận khi nào gọi và gọi như thế nào.

Q6. Sub-agent có thể tạo thêm sub-agent con của riêng nó không?

Câu trả lời tham khảo

Thông thường là không. Sub-agent không nên khởi tạo sub-agent của chính nó.

Thiết kế này chủ yếu nhằm tránh ba vấn đề:

1. Đệ quy vô hạn: Nếu agent có thể sinh vô hạn agent mới, cây gọi sẽ rất dễ mất kiểm soát. 2. Không thể kiểm toán: Khi lồng sâu quá, hội thoại chính khó biết ở mỗi tầng đã diễn ra gì. 3. Bùng nổ ngữ cảnh và chi phí: Mỗi tầng agent có thể có ngữ cảnh riêng, chi phí và độ trễ tăng nhanh.

Nếu thực sự cần “ủy quyền lồng”, cách tốt hơn là:

• Hội thoại chính phân phối nhiều sub-agent theo cấu trúc phẳng.
• Trong sub-agent dùng skill để tổ chức các bước.
• Với nhiệm vụ cực kỳ phức tạp, cân nhắc Agent Team nhưng cần đặt ranh giới và ngân sách rõ ràng.

Hai, phần tổng hợp chi tiết

Q7. CLAUDE.md / AGENTS.md là gì? Thứ tự tải và độ ưu tiên như thế nào?

Câu trả lời tham khảo

CLAUDE.md và AGENTS.md có thể hiểu là “tiêm prompt cố định” cấp dự án hoặc người dùng. Chúng dùng để khai báo các quy tắc mà agent phải biết mỗi khi khởi động, như phong cách code, lệnh test, file cấm chỉnh sửa, quy tắc commit...

Các tầng thường gặp gồm:

Nên tránh biến nó thành một bài viết giới thiệu dự án; thay vào đó hãy viết thành các quy tắc cứng mà agent phải tuân thủ, ví dụ:

• Đọc các test liên quan trước khi sửa mã.
• Không sửa .env và file khóa bí mật.
• Bắt buộc chạy npm run typecheck sau khi hoàn tất.
• Không thêm phụ thuộc không cần thiết.

Một kinh nghiệm thực tế: cố gắng giữ mỗi file dưới khoảng 200 dòng. Nội dung quá dài nên tách thành tài liệu riêng và liên kết lại qua tham chiếu.

Q8. Hooks là gì? Hãy liệt kê vài tình huống dùng hook phổ biến.

Câu trả lời tham khảo

Hook là các callback xác định được đăng ký theo sự kiện trong vòng đời của Claude Code hay công cụ agentic tương tự. Nó không phải việc “mô hình nhớ làm” mà là ép buộc ở tầng runtime của công cụ.

Các sự kiện phổ biến gồm:

• Trước khi gọi tool: ví dụ chặn lệnh nguy hiểm.
• Sau khi gọi tool: ví dụ tự động format sau khi sửa file.
• Khi bắt đầu session: ví dụ tiêm trạng thái git hiện tại.
• Khi dừng lại: ví dụ gửi thông báo desktop.

Một số kịch bản dùng thường gặp:

Giá trị của Hooks nằm ở tính “xác định”. Prompt có thể bị mô hình bỏ qua, nhưng hook là ràng buộc ở tầng công cụ.

Q9. Các Permission Mode nào có? Mỗi loại phù hợp môi trường nào?

Câu trả lời tham khảo

Permission Mode quyết định agent có cần xác nhận từ người dùng khi thực hiện đọc/ghi file, chạy lệnh, gọi tool ngoài hay không.

Nguyên tắc chung: càng gần môi trường production thì quyền nên thận trọng hơn; càng giống thử nghiệm tạm thời hoặc sandbox thì quyền có thể mở hơn.

Q10. Khi dùng /compact, phần ngữ cảnh nào được giữ, phần nào mất?

Câu trả lời tham khảo

Bản chất của /compact là nén ngữ cảnh hội thoại. Nó giữ lại một phần thông tin ưu tiên cao, chứ không giữ nguyên chi tiết đầy đủ của các lần gọi công cụ trước.

Thông thường sẽ được giữ hoặc tiêm lại:

• System prompt.
• File quy tắc cấp dự án, ví dụ CLAUDE.md.
• Bộ nhớ người dùng hoặc dự án.
• Tóm tắt hội thoại.
• Mô tả skill ưu tiên cao nào đó.

Những thứ dễ mất:

• Toàn bộ output đầy đủ của lịch sử gọi công cụ.
• Chi tiết đã từng đọc nhưng chưa ghi vào file bền vững.
• Thỏa thuận tạm thời chỉ tồn tại trong hội thoại.
• Schema đầy đủ của một số tool được nạp theo nhu cầu.

Gợi ý thực tế: đừng nhét toàn bộ ràng buộc dài hạn chỉ vào chat. Những quy tắc quan trọng nên đặt vào CLAUDE.md, AGENTS.md, memory, PROGRESS.md hoặc tài liệu dự án.

Q11. Mối quan hệ giữa Plugin và Skill là gì?

Câu trả lời tham khảo

Skill là một đơn vị năng lực; Plugin là gói mở rộng đã đóng gói để phát hành.

Một plugin có thể bao gồm:

• Nhiều skills.
• Định nghĩa sub-agent.
• Hooks.
• MCP server.
• LSP server.
• Công cụ nhị phân.
• Cài đặt mặc định.

Có thể hiểu thế này: skill là linh kiện, plugin là bộ công cụ đã lắp ráp. Nếu team có quy trình lập trình AI ổn định, có thể đóng gói thành plugin để thành viên mới cài đặt chỉ một click.

Q12. ToolSearch / Deferred Tools là gì? Tại sao thiết kế như vậy?

Câu trả lời tham khảo

Ý tưởng cốt lõi của Deferred Tools là: khi khởi động, không đưa toàn bộ schema đầy đủ của tất cả tool vào ngữ cảnh ngay; chỉ cho mô hình biết tên tool trước. Khi cần dùng một tool thực sự, thông qua ToolSearch hoặc cơ chế tương tự sẽ tải cấu trúc tham số chi tiết.

Lý do chính:

1. Tiết kiệm token: MCP server lớn có thể có hàng chục đến hàng trăm tool, schema toàn bộ rất tốn ngữ cảnh. 2. Giảm nhiễu chú ý: Tool không liên quan nhưng luôn đứng trong prompt lâu dài có thể làm lệch quyết định của mô hình. 3. Nạp theo nhu cầu: Chỉ tải mô tả chi tiết khi thật sự cần.

Chi phí là lần đầu dùng tool có thể mất thêm một lần round trip, nhưng tổng thể thường hợp lý hơn.

Ba, phần quy trình công việc

Q13. Nhận một task tính năng mới trung bình, nên dùng agentic tools để chia nhỏ như thế nào?

Câu trả lời tham khảo

Một quy trình điển hình có thể là:

1. Vào plan mode trước, chỉ đọc để khám phá code, chưa vội sửa. 2. Dùng Explore sub-agent song song tìm file liên quan, tìm entrypoint, luồng dữ liệu, vị trí test. 3. Hội thoại chính hoặc Plan sub-agent đưa ra giải pháp theo phong cách TDD: tiêu chuẩn chấp nhận, test case, hiện thực tối thiểu, chiến lược xác thực. 4. Dùng model thứ hai hoặc review agent làm cross-model review để bù khoảng trống. 5. Ở các điểm phân nhánh thiết kế quan trọng, hỏi người dùng thay vì tự quyết tác động lớn. 6. Rời plan mode, chuyển sang chế độ có thể chỉnh sửa. 7. Viết hoặc cập nhật test trước, sau đó mới triển khai tính năng. 8. Sau khi triển khai, chạy test liên quan, typecheck, lint. 9. Cuối cùng tự kiểm bằng review skill hoặc code-review agent.

Điểm mấu chốt của quy trình này không phải “mở nhiều agent cho oai oăm”, mà là tách rõ giai đoạn khám phá, thiết kế, triển khai, xác thực, và hồi quy.

Q14. Khi nào nên mở sub-agent, khi nào không nên?

Câu trả lời tham khảo

Nên mở sub-agent khi:

• Cần đọc hơn 10 file để nghiên cứu.
• Cần chạy nhiều lệnh grep, find, phân tích log.
• Làm review độc lập hoặc review an toàn.
• Xử lý song song nhiều task con không phụ thuộc.
• Output công cụ có thể rất dài, không muốn bẩn ngữ cảnh chính.

Không nên mở sub-agent khi:

• Nhiệm vụ chỉ cần 1–3 lần gọi tool.
• Chỉ đọc một đường dẫn đã biết.
• Nhiệm vụ cần xác nhận với người dùng nhiều lần.
• Bạn muốn toàn bộ quá trình suy luận giữ nguyên trong hội thoại chính.

Nói ngắn gọn: sub-agent phù hợp với công việc “nhiều tìm kiếm, nhiều đọc, nhiều log”, không phù hợp việc “nhanh gọn, tức thì”.

Q15. Làm sao tránh làm bẩn ngữ cảnh hội thoại chính?

Câu trả lời tham khảo

Có thể kiểm soát từ nhiều phía:

• Giao phần đọc và nghiên cứu lớn cho Explore sub-agent, chỉ cho nó trả summary.
• Dùng head, tail, grep để gom output dài, đừng đưa cả nghìn dòng log vào hội thoại.
• Đóng gói quy trình lặp đi lặp lại thành skill thay vì dán lại một khối quy tắc dài mỗi lần.
• Sau các mốc giai đoạn, chạy /compact đúng lúc.
• Viết thông tin quan trọng lâu dài vào CLAUDE.md, AGENTS.md, memory hoặc PROGRESS.md.
• Không để agent đọc đi đọc lại cùng một file; trạng thái file nên xác nhận qua diff, test, và version control.

Nguyên tắc cốt lõi là: ngữ cảnh càng nhiều không phải càng tốt, điều quan trọng là tỷ lệ tín hiệu trên nhiễu càng cao.

Q16. Code bị bug, nên dùng agentic tools debug thế nào?

Câu trả lời tham khảo

Quy trình tương đối an toàn là:

1. Đừng vội sửa code, trước hết tái hiện bug. 2. Viết một test hoặc case nhỏ ổn định bị lỗi. 3. Xác nhận test thực sự fail để chứng minh bạn hiểu vấn đề. 4. Dùng Explore tìm các file liên quan trên đường đi phát sinh bug. 5. Đưa ra giả thuyết rồi xác minh từng cái, thay vì vá bừa. 6. Sau sửa xong, chạy test liên quan. 7. Cuối cùng chạy toàn bộ hoặc các lệnh kiểm tra quan trọng. 8. Nếu agent liên tục sửa không ra, dừng ngữ cảnh hiện tại, đổi hướng hoặc cho model khác chẩn đoán độc lập.

Nỗi sợ lớn nhất khi debug bằng agent là “đoán rồi sửa dần”. Không có test tái hiện ổn định, mô hình rất dễ làm code rối hơn khi sửa.

Q17. Trong repo hợp tác nhóm, làm sao làm cho workflow agentic hóa theo đội?

Câu trả lời tham khảo

Trọng tâm của đội hóa là biến kinh nghiệm cá nhân thành tài sản của repo.

Tầng chia sẻ có thể gồm:

• CLAUDE.md / AGENTS.md ở gốc repo: quy tắc cứng của đội.
• .claude/skills/: workflow dùng chung.
• .claude/agents/: các sub-agent dùng chung cho research, review, debug...
• .claude/settings.json: permissions, hooks, whitelist tool dùng chung.
• Template PR: yêu cầu mô tả quyết định AI đã tham gia và các lệnh xác thực.

Tầng cá nhân có thể gồm:

• CLAUDE.local.md: ưu tiên cá nhân, thường không commit.
• .claude/settings.local.json: override quyền của cá nhân.

Tiến thêm một bước là đóng gói năng lực chung của đội thành plugin để cài, nâng cấp, bảo trì thống nhất.

Bốn, phần thiết kế hệ thống: suy luận mở

Các câu hỏi sau không có đáp án chuẩn, trọng tâm là luyện khung đánh giá trade-off và nhận diện rủi ro.

Q18. Thiết kế một nền tảng agentic low-code, nên ưu tiên nguyên tắc nào?

Hướng thảo luận

Điểm đầu tiên là xác định source of truth. Quyền ưu tiên là mã do agent sinh ra hay DSL low-code? Đồng bộ hai chiều nghe có vẻ đẹp nhưng thực tế rất dễ rơi vào hell kỹ thuật.

Cũng cần cân nhắc:

• Khả năng đảo ngược và version control: sau khi agent sửa 50 component một lần, phải có thể diff, revert, review.
• Sandbox và phân tầng quyền: user agent của nền tảng không thể truy cập trực tiếp DB, phải đi qua gateway phân quyền.
• Cung cấp ngữ cảnh: kiến thức nghiệp vụ đưa vào agent bằng cách nào? Người dùng phải viết rule hay tự động chiết xuất từ tài liệu sẵn có?
• Khả năng quan sát lỗi: khi agent gọi API bên thứ ba hoặc MCP fail, phải có thể replay lại.
• Xác nhận quyết định quan trọng: đừng thay thế suy nghĩ người dùng; quyết định ảnh hưởng lớn bắt buộc xác nhận rõ.
• Hiện thị chi phí: token, gọi API, độ trễ của từng thao tác phải thấy được.

Một nền tảng agentic low-code tốt không phải “nút thần kì”, mà là một hệ thống kỹ thuật có thể kiểm toán, rollback và compose được.

Q19. Thiết kế MCP gateway nội bộ doanh nghiệp, xử lý quyền, audit, rate limit thế nào?

Hướng thảo luận

Một MCP gateway cấp doanh nghiệp ít nhất cần xử lý các vấn đề sau:

• Quyền: vai trò khác nhau nhìn thấy tool khác nhau. Vai trò chỉ đọc không nên thấy schema của tool delete_*.
• Audit: mỗi lần gọi tool ghi lại user, agent_id, tham số, kích thước trả về, thời gian và trạng thái kết quả.
• Rate limit: giới hạn QPS, đồng thời, và số lượt gọi/ngày theo user hoặc agent.
• Ẩn dữ liệu nhạy cảm: xử lý trước khi trả cho agent, kể cả PII, khóa bí mật, trường nội bộ nhạy cảm.
• Chiến lược fallback: khi service backend lỗi thì trả structured error, không để đợi vô hạn.
• Quản lý phiên bản: thay đổi schema tool phải có version, tránh client cũ đột ngột hỏng.
• Cô lập tenant: công cụ và dữ liệu của team, dự án khác nhau phải tách biệt.

Trọng tâm của MCP gateway không phải “kết nối thêm nhiều tool”, mà là “để mô hình dùng tool một cách an toàn”.

Q20. Mô hình hợp tác nhiều agent nên chọn sao dạng sao (star) hay dạng lưới (mesh)? Vì sao?

Hướng thảo luận

Kiến trúc sao có ưu điểm rõ: rõ ràng, kiểm soát được, dễ audit. Hội thoại chính là trung tâm, mọi sub-agent đều báo cáo về đó. Nhược điểm là nút trung tâm có thể thành điểm nghẽn và mức song song hạn chế.

Cấu trúc lưới gần hơn thực tế đội làm việc, nhiều agent có thể trao đổi nhau nên lý thuyết song song tốt hơn. Nhưng nhược điểm cũng rõ:

• Có thể phát sinh vòng lặp hội thoại giữa agent.
• Ngữ cảnh dễ bùng nổ.
• Ranh giới trách nhiệm mờ.
• Độ khó debug tăng mạnh.

Trong thực tế, hầu hết tác vụ sao đã đủ dùng. Chỉ trong các nhiệm vụ phức tạp, nhiều vai trò mới đáng thử phối hợp dạng lưới, và khi đó phải đi kèm quản lý ngân sách message, giới hạn thread, trực quan hóa đồ thị hội thoại và cơ chế audit mạnh.

Một câu hỏi sâu hơn: ROI của hợp tác đa-agent có thực sự cao hơn “một agent đơn mạnh hơn”? Khi năng lực mô hình tiếp tục tăng, việc điều phối nhiều agent có thể chỉ thực sự có giá trị ổn định trong một số kịch bản phức tạp.

Q21. Thiết kế một agent review an toàn, cần tránh bẫy nào?

Hướng thảo luận

Agent review an toàn không thể chỉ nhìn diff. Nhiều lỗ hổng nằm trong chuỗi gọi và ngữ cảnh, không phải vài dòng vừa đổi.

Cũng cần tránh:

• Tin vào test pass: phần chưa được cover test thường là nơi tập trung lỗ hổng.
• Agent tự chạy lệnh tấn công: giai đoạn review nên thiên về read-only để tránh biến agent review thành bề mặt tấn công.
• Theo đuổi zero false positive: review an toàn nên chấp nhận false positive có kiểm soát hơn là bỏ sót vấn đề nguy hiểm cao.
• Thiếu phân cấp: phải tách P0, P1, P2 để giúp người quyết định ưu tiên.
• Không giải thích được: không thể chỉ nói “unsafe”, mà phải nêu vì sao nguy hiểm, phạm vi ảnh hưởng gì, cách xử lý.

Cách ổn hơn: một model review, một model khác cross-check, rồi con người ra quyết định cuối.

Q22. Thiết kế cơ chế nhớ dài hạn, quyết định ghi gì và không ghi gì ra sao?

Hướng thảo luận

Nên ghi những thứ sau:

• Mức coding style người dùng sửa đi sửa lại nhiều lần.
• Ràng buộc cứng cấp dự án.
• Lệnh dùng thường xuyên.
• Thông tin kỹ thuật dễ quên nhưng có giá trị dài hạn, như port, test entry, vị trí tài liệu.

Không nên ghi:

• Cuộc đối thoại tạm thời một lần.
• Nội dung chứa dữ liệu nhạy cảm.
• Trạng thái bug đã lỗi thời.
• Các giả định chưa chắc chắn về tính ổn định dài hạn.

Ký ức dài hạn cũng cần cơ chế cập nhật: khi ghi vào thì gộp trùng lặp; định kỳ dọn bớt mục cũ; cho phép người dùng review, chỉnh sửa, xóa. Chia sẻ qua nhiều dự án cũng cần thận trọng: sở thích có thể dùng chung, nhưng kiến thức dự án không nên bơm sang dự án khác bừa bãi.

Năm, phần triết học khái niệm: suy luận mở

Q23. Vì sao nên giữ context đơn giản? Một prompt đẩy đầy thông tin có phải tốt hơn không?

Hướng thảo luận

Giá trị của context không nằm ở độ dài, mà ở tỷ lệ tín hiệu trên nhiễu.

Đẩy đầy thông tin gây ra vài vấn đề:

• Pha loãng attention: quy tắc quan trọng bị ngập trong thông tin vô thưởng vô phạt.
• Tăng chi phí: mỗi lần suy luận phải xử lý nhiều token hơn.
• Tăng độ trễ: ngữ cảnh dài thường làm phản hồi chậm hơn.
• Khó debug: khi lỗi, khó xác định rule nào xung đột.
• Khó tiến hóa: prompt phức tạp giống một cục spaghetti, sửa càng nhiều càng lộn.

Context tốt không phải là “ít thông tin”, mà là “chỉ giữ đúng thông tin cần cho nhiệm vụ hiện tại”.

Q24. Agent nên chủ động hay thụ động? Khi nào nên hỏi user, khi nào tự quyết?

Hướng thảo luận

Tiêu chí đánh giá có thể nhìn qua ba chiều:

1. Khả năng đảo ngược của hành động: thay đổi local có thể đảo ngược thì tự quyết; các hành động không đảo ngược như push, delete, gửi email thì phải hỏi. 2. Phạm vi tác động: ảnh hưởng chỉ máy local có thể chủ động hơn; ảnh hưởng đội, production, khách hàng thì phải cẩn trọng. 3. Độ bất định: nếu agent chưa chắc về quyết định, nên hỏi, không được đặt cược.

Agent tốt không phải “luôn hỏi”, cũng không phải “luôn tự quyết”, mà biết hỏi đúng câu hỏi: hỏi ở ngã rẽ quan trọng, tránh làm phiền ở thứ vụn vặt.

Q25. Vibe Coding là hype hay là cuộc cách mạng phương pháp?

Hướng thảo luận

Nhóm cho rằng hype sẽ nói: đây chỉ là autocomplete thông minh hơn. Trong dự án phức tạp, agent vẫn mắc lỗi cơ bản, và chi phí bảo trì bị đánh giá thấp.

Nhóm cho rằng đây là thay đổi mô hình sẽ nói: đơn vị lập trình đang chuyển từ “dòng / hàm” lên “ý định / ràng buộc”. Vai trò kỹ sư chuyển từ người gõ code sang kiến trúc sư, người biên tập, người thiết kế hệ thống.

Quan điểm trung dung an toàn là: đây đúng là thay đổi mô hình, nhưng không phải thay thế 1:1. Nó khuếch đại năng lực của kỹ sư giỏi vì họ tạo spec tốt hơn và review tốt hơn; đồng thời cũng khuếch đại sức phá hủy của người kém, vì họ có thể tạo mã xấu nhanh hơn.

Những câu hỏi then chốt tiếp theo là:

• Nếu agent viết code, tri thức được tích lũy ở đâu? Repo, tài liệu, test hay bộ não cá nhân?
• Vai trò của code review có còn quan trọng hơn việc viết code?
• Việc làm việc cho vị trí mới và đào tạo lập trình sẽ thay đổi ra sao?

Q26. Một agent lặp đi lặp lại sửa không xong bug thì nên cho nó tiếp tục thử, hay tự dừng?

Hướng thảo luận

Nếu agent đã thử đi thử lại cùng một hướng sai, rất có thể ngữ cảnh đã bị ô nhiễm. Để nó tiếp tục đốt token thường chỉ đào sâu thêm đường chết.

Cách tiếp cận tốt hơn:

• Đặt giới hạn thử như: dừng sau 3 lần thất bại liên tiếp.
• Dừng vòng sửa hiện tại, làm gọn lại minimal reproduction, log, test fail.
• Đổi model để chẩn đoán độc lập.
• Khi cần, nhân sự trực tiếp tiếp quản đường đi quan trọng.

Agent bị kẹt thường không phải vì “không đủ nỗ lực suy luận”, mà vì thiếu thông tin, test không rõ, ngữ cảnh nhiễu, hoặc hướng đi sai.

Q27. Tại sao TDD trong workflow agentic lại quan trọng hơn workflow truyền thống?

Hướng thảo luận

Agent dễ tự tin viết sai. Nó có thể tự viết API, field, giá trị return. Testing là trong số ít cơ chế khách quan để phán đoán liệu nhiệm vụ đã thực sự hoàn thành hay chưa.

TDD đặc biệt quan trọng trong workflow agentic vì:

• Test là hợp đồng giao tiếp với agent.
• Test fail cho agent vòng phản hồi rõ ràng.
• Test biến nhu cầu mơ hồ thành quy chuẩn có thể thực thi.
• Acceptance test ngăn tình trạng “trông như xong nhưng thực ra chưa xong”.

Nhưng cần chú ý: đừng để agent tự viết test, tự viết implementation rồi tự báo pass. Các test chấp nhận quan trọng và test an toàn nên do con người viết, hoặc ít nhất do model khác độc lập review.

Q28. “Mã agent viết khó đọc” phải làm sao? Là lỗi công cụ hay lỗi cách dùng?

Hướng thảo luận

Cả hai đều.

Về phía công cụ, mô hình dễ rơi vào việc trừu tượng quá mức, phòng thủ quá mức, comment quá mức. Về phía cách dùng, nếu user không đặt ràng buộc, không review, mà chấp nhận ngay lần đầu thì mã rác sẽ đọng dần.

Có cách chỉnh như sau:

• Trong CLAUDE.md hoặc AGENTS.md ghi rõ quy tắc đọc được về tính dễ đọc.
• Giới hạn độ dài hàm, quy tắc đặt tên, quy tắc comment.
• Tách bước “refactor/simplify/remove redundancy” thành bước riêng.
• Dùng skill review code để bắt buộc agent tự kiểm.
• Với module quan trọng yêu cầu con người đọc kỹ diff.

Nếu không đọc mã do agent viết thì về bản chất là bạn đã giao sản xuất cho một thực tập sinh không chịu trách nhiệm.

Q29. “Mình để agent chạy cả đêm, về sáng không hiểu nó đã làm gì” — lỗi của agent hay lỗi của user?

Hướng thảo luận

Trách nhiệm nằm cả hai phía.

Phía công cụ cần cung cấp khả năng quan sát: diff file, log lệnh, điểm quyết định quan trọng, lịch sử lỗi, tóm tắt theo giai đoạn.

Phía user cũng phải đặt ranh giới: đừng để agent chạy đêm không ràng buộc. Tác vụ dài nên chia giai đoạn, mỗi giai đoạn có mục tiêu rõ, phạm vi quyền, và checkpoint.

Nhiệm vụ tự chủ càng dài, càng cần ràng buộc chặt. Một agent chạy một mình không giám sát giống như “thực tập sinh không giám sát có quyền sudo”, rủi ro rất cao trong production.

Q30. Công cụ agentic có làm cho nghề lập trình biến mất không?

Hướng thảo luận

Khả năng cao hơn không phải “lập trình viên biến mất”, mà “mức trừu tượng của lập trình viên nâng lên”.

Những vai trò bị suy yếu là loại chỉ dịch spec rõ ràng thành code. Vai trò vẫn quan trọng là hiểu yêu cầu, tách hệ thống, phán định đúng sai, chịu trách nhiệm, và duy trì kiến trúc dài hạn.

Những vai trò có thể quan trọng hơn trong tương lai gồm:

• Kiến trúc sư Agent: thiết kế đồ thị hợp tác của agent, thư viện skill và chiến lược context.
• AI reviewer: review output của agent với tốc độ cao.
• Kỹ sư context: cấu trúc hóa tri thức domain thành dạng mà agent có thể hấp thụ.
• Trưởng đội kỹ thuật: quyết định việc nào tự động hóa được, việc nào buộc phải giữ kiểm soát thủ công.

Lịch sử cho thấy có tính tương đồng: compiler chưa làm cho lập trình viên biến mất, nhưng làm giảm mạnh lập trình viên viết assembly thủ công. AI agent cũng có thể tương tự: không xóa kỹ sư, mà đẩy kỹ sư lên tầng trừu tượng cao hơn.

Sáu, phụ lục: lộ trình học tập khuyến nghị

Giai đoạn nhập môn

Đọc tài liệu chính thức, chạy qua các năng lực nền tảng:

• File quy tắc dự án: CLAUDE.md / AGENTS.md
• skill
• agent
• hooks
• /compact
• memory
• các chế độ quyền cơ bản của Codex / Claude Code

Mục tiêu không phải nhớ thuật ngữ, mà biết mỗi thứ giải quyết vấn đề gì.

Giai đoạn nâng cao

Đóng gói 3 việc bạn làm thường xuyên nhất, ví dụ:

1. Tạo commit message. 2. Viết tóm tắt PR. 3. Sau khi sửa mã thì tự chạy test và typecheck.

Bước này nằm ở chỗ nâng cấp từ “mỗi lần lại nhắc AI một lần nữa” sang “đóng quy trình thành tài sản của dự án”.

Giai đoạn nâng cao

Xây cho team hoặc dự án cá nhân một agentic workflow:

• CLAUDE.md / AGENTS.md: quy tắc dài hạn.
• skills/: quy trình tái sử dụng.
• agents/: các vai trò chuyên dụng cho research, review, debug...
• hooks/: ràng buộc xác định.
• PROGRESS.md: theo dõi trạng thái tác vụ dài.
• TASKS.md: phân tích nhiệm vụ.

Giai đoạn chuyên gia

Bắt đầu nghiên cứu các vấn đề phức tạp hơn:

• Quyết định quyền trong hooks ở PreToolUse.
• MCP gateway và mô hình quyền enterprise.
• Ngân sách message và audit trong hợp tác đa-agent.
• Thiết kế checkpoint cho workflow overnight kéo dài.
• Làm sao để test, tài liệu, file quy tắc cùng trở thành context đáng tin cậy cho agent.

Bảy, tài liệu tham khảo

• Claude Code Docs: llms.txt
• Claude Code Docs: Hooks Reference
• Claude Code Docs: Automate workflows with hooks
• OpenAI Codex: Get started
• OpenAI Codex GitHub Repository
• OpenAI Codex: Installation Docs
• OpenAI Cookbook: Hướng dẫn Prompting Codex

Bạn có thể tham khảo thêm các thực hành Codex trong 《Sử dụng Codex một cách sâu sắc hơn》; nếu muốn chuyển nhanh giữa các công cụ Claude, xem Giới thiệu công cụ CC Switch.

Câu hỏi thường gặp

Bài viết này phù hợp với trình độ nhà phát triển nào?

Bạn có thể xem phần 「Đối tượng phù hợp」 trong nội dung gốc; mục bài viết về lập trình trên website này bao phủ các mức từ cơ bản tới workflow lập trình AI, mỗi bài có nền tảng giả định khác nhau.

Các công cụ hay lệnh trong bài có khác nhau theo hệ điều hành không?

Có. Môi trường terminal, định dạng đường dẫn và cú pháp lệnh trên macOS, Linux, Windows khác nhau. Nếu bài không ghi rõ hệ thống, bạn nên điều chỉnh theo tài liệu chính thức theo nền tảng tương ứng.

Nên phối hợp với công cụ AI nào để học lập trình?

Claude Code và Codex hiện là hai công cụ AI lập trình mạnh. Chúng có thể dùng để giải thích mã, bổ sung logic, debug lỗi và sinh script. Có thể xem bài giới thiệu các công cụ Bài viết về CC Switch và Bộ câu hỏi phỏng vấn Vibe Coding để tham khảo.

Thói quen quan trọng nhất khi học lập trình là gì?

Làm thực hành quan trọng hơn học lý thuyết. Nên sớm chọn một dự án thực sự (dù nhỏ) để luyện tập, khi gặp vấn đề hãy tra tài liệu và đọc code thay vì chỉ học xong lý thuyết rồi thôi.