Mỗi bài blog trên site này được xây bởi agent. Hệ thống TTS đọc bài này cho bạn được nâng cấp bởi agent. Toàn bộ curriculum Cambridge YLE cho CubLearn — 22 file, 8 bài học game, 14 bài luyện phát âm — ship trong một buổi chiều, agent chạy toàn bộ.

Cuối mỗi bài viết có dòng chữ:

Xây bằng agentic engineering. Xác minh bởi agent QA. Review bởi người. Ship lên production.

Đó không phải slogan marketing. Đó là workflow thực tế. Series này ghi lại nó từ đầu — ý nghĩa là gì, hoạt động ra sao, và cần gì để agent ship code đáng tin.


Tại Sao “Vibe Coding” Không Phải Đích Đến

Vibe coding hiệu quả. Với demo. Với MVP không ai maintain. Với 3 ngày đầu của side project — trước khi bạn nhận ra codebase đang được giữ bởi những API tưởng tượng và giá trị hardcode.

Khảo sát Stack Overflow 2025 hỏi 49.000 lập trình viên về AI coding tools. Con số nói lên tất cả:

  • 84% dùng hoặc dự định dùng AI coding tools
  • 45% nói debug code AI lâu hơn tự viết
  • 29% thực sự tin vào output

Khoảng cách đó — 84% adoption, 29% trust — là vấn đề vibe coding tạo ra. Lập trình viên đang dùng AI, nhưng dành nhiều thời gian dọn dẹp sau nó hơn là tiết kiệm được.

Câu trả lời không phải dùng AI ít hơn. Mà là dùng khác đi.


Agentic Engineering Thực Ra Là Gì

Agentic engineering có nghĩa là thiết kế hệ thống mà agent hoạt động trong đó — không chỉ prompt agent rồi hi vọng.

Sự dịch chuyển là từ:

  • “AI, viết code cho tôi” (vibe coding)

Sang:

  • “AI, đây là specification. Đây là ràng buộc. Đây là bộ xác minh. Bây giờ hãy xây — và chứng minh nó hoạt động.”

Sự khác biệt không nằm ở prompt. Nó nằm ở mọi thứ xung quanh prompt: harness, plan mode, vòng lặp QA, test tự động, cổng deployment.

Agent viết code. Bạn thiết kế hệ thống làm cho code đó xứng đáng được viết.


Workflow Trong Thực Tế

Đây chính xác là cách site portfolio này được xây và cập nhật:

1. Specification Trước

Trước khi agent đụng vào code, task phải được định nghĩa rõ:

  • Đang thêm tính năng gì?
  • File nào sẽ bị sửa?
  • Thành công trông như thế nào (test, behavior, output)?
  • Cái gì KHÔNG được phá vỡ?

Điều này nằm trong CLAUDE.md — bộ nhớ dự án bền vững, load vào mỗi session. Quyết định quan trọng, lựa chọn kiến trúc, coding convention, cảnh báo “đừng đụng file này”. 400 dòng context giữ agent không phải học lại codebase mỗi session.

2. Plan Mode — Nghiên Cứu Trước Khi Code

Plan mode của Claude Code là không thể thương lượng. Trước khi viết dòng code đầu tiên, agent:

  1. Đọc tất cả file liên quan (grep, read, knowledge graph traversal)
  2. Lập bản đồ call chain (cái gì gọi cái gì, cái gì bị phá nếu X thay đổi)
  3. Sinh ra bản kế hoạch bằng văn bản với file path và tên hàm cụ thể
  4. Liệt kê mọi thứ có thể sai

Bản kế hoạch được review. Không phải lúc nào cũng do tôi — chi tiết hơn ở Phần 3.

3. Sinh Code — Bị Ràng Buộc và Theo Dõi

Với bản kế hoạch được duyệt, coding agent thực thi. Ràng buộc chính trong workflow:

  • Kiến trúc modular — mỗi module đủ nhỏ để vừa một context window. Agent sửa từng module một.
  • Coding convention — enforce qua CLAUDE.md và custom linting hook. Agent không thể ship code vi phạm style (snake_case vs camelCase, async pattern, error handling convention).
  • Hook system — pre-commit hook tự động chạy. Agent không thể bypass.

4. Agent QA Review — Bộ Lọc Khắt Khe

Sau khi sinh code, agent QA chuyên biệt review output theo checklist có cấu trúc:

  • Test coverage — code có test không? Test có thực sự kiểm tra behavior không?
  • Wiring verification — mỗi hàm mới có được gọi ở đâu đó trong application flow không?
  • Tuân thủ convention — code có theo pattern đã thiết lập chưa?
  • Edge cases — input rỗng thì sao? Null values? Network fail?
  • Fidelity với plan — implementation có khớp với kế hoạch không?

Agent QA đã reject plan 4-5 lần trước khi approve. Nó chạy chậm hơn sinh code thô 10 lần. Chênh lệch chất lượng là rất lớn.

5. Human Review — Quét 5 Phút

Sau khi QA approve, tôi review diff. Không từng dòng — tôi tin agent QA làm việc đó. Tôi đang tìm:

  • Cái này có ý nghĩa kiến trúc không?
  • Có gì bất ngờ trong diff không?
  • Có concern bảo mật hay data nào mà agent QA có thể bỏ sót không?

5 phút cho hầu hết thay đổi. Đôi khi 30 giây.

6. CI/CD — Cổng Tự Động

GitHub CI chạy mỗi khi push:

  • TypeScript compilation
  • Unit tests
  • Integration tests (khi có)
  • Build validation

Nếu bước nào fail: không có gì deploy. Code của agent phải qua cùng cổng như code con người.

7. Smoke Tests Sau Deploy — Kiểm Tra Cuối

Sau khi Cloudflare Pages deploy:

  1. Smoke tests tự động hit các endpoint chính
  2. Docker logs được kiểm tra lỗi runtime
  3. Các user journey cốt lõi được xác minh (blog post render, TTS hoạt động, newsletter subscribe hoạt động)

Smoke tests fail: tự động rollback.

Pass: traffic route tới deployment mới.


Ví Dụ Thực Tế: Nâng Cấp TTS Trong 30 Phút

Đây là workflow trong thực tế. Đêm qua, tôi yêu cầu agent nâng cấp Text-to-Speech của site từ Journey voices sang Chirp3-HD với caching 30 ngày.

Spec tôi cung cấp:

  • Nâng cấp lên Google Chirp3-HD (en-US-Chirp3-HD-Charon, vi-VN-Chirp3-HD-Charon)
  • Thêm Cloudflare Cache API với SHA-256 hash keys và TTL 30 ngày
  • Auto-detect ngôn ngữ trang (document.documentElement.lang) cho voice selection
  • Cập nhật TTSPlayer.astro với 4 patch nhắm mục tiêu

Agent đã làm:

  1. Đọc functions/api/tts.ts hiện tại (108 dòng)
  2. Đọc functions/api/tts-config.ts (37 dòng)
  3. Đọc các section liên quan của TTSPlayer.astro (2328 dòng, tìm kiếm Journey, voice =, /api/tts)
  4. Sinh 3 file mới và áp 4 patch phẫu thuật
  5. Xác minh: không có em-dash, không có smart quote, không có breaking change cho audio player interface

Tổng thời gian wall-clock: 28 phút từ spec đến pushed commit.

Cách cũ (trước workflow agentic): Đọc docs, viết code, test local, debug CORS headers, fix base64 decode, fix language code extraction, cuối cùng push. Có lẽ 3-4 giờ.


Series Này Gồm Gì

Đây là Phần 1 của series 5 phần. Sắp tới:

Phần 2 — “Plan Mode hoặc Thất Bại” Tại sao mỗi coding session phải bắt đầu bằng giai đoạn nghiên cứu. Plan mode hoạt động ra sao trong Claude Code. Ví dụ thực tế của các plan bị reject và lý do tại sao.

Phần 3 — “Agent QA” Phương pháp luận đằng sau xác minh code tự động. Những gì agent QA kiểm tra mà người bỏ sót. Vấn đề wiring verification (code được viết ra nhưng không bao giờ được gọi). Log reject thực tế.

Phần 4 — “Debug Dựa Trên Bằng Chứng” Cách cho agent mắt để nhìn. Chrome DevTools MCP, Docker log streaming, Serena semantic code understanding. Sự khác biệt giữa agent đoán mò và agent đo lường.

Phần 5 — “Từ Agent Đến Production” CI/CD pipeline đầy đủ cho agentic code. Smoke tests, rollback strategy, deployment gates. Cách ngủ trong khi agent ship hàng.


Chỉ Số Thực Sự

Tôi từng dành 60-70% thời gian AI coding để test và debug.

Bây giờ tôi dành thời gian đó cho specification và review.

Agent làm nhiều hơn. Tôi chỉ đạo nhiều hơn. Phần mềm tốt hơn.

Đó là lời hứa của agentic engineering. Không phải phép màu — là kỹ thuật.


Đây là Phần 1 của series “Xây Bằng Agentic Engineering”. Tiếp theo: Plan Mode hoặc Thất Bại — Tại Sao Agent Phải Suy Nghĩ Trước Khi Code

Xuất nội dung

Bình luận