Nguồn video: - YouTube

Đây là một bài khá hay vì không chỉ nói “AI Agent code nhanh hơn”, mà nói về cách biến Agent từ một công cụ phải giám sát liên tục thành một “đội ngũ kỹ sư AI có thể tự vận hành ở quy mô lớn”.

1. Ý chính nhất của cả bài

Muốn scale AI Agent, vấn đề quan trọng nhất không phải model thông minh đến đâu, mà là bạn có TRUST agent đến đâu.

Tác giả gọi đó là Trust Curve.

Ban đầu:

1 Agent → con người quan sát từng bước → sửa từng lỗi → rất khó scale

Sau khi xây dựng đủ:

• Verification

• Skills

• Evals

• Architecture constraints

• CI / Guardrails

thì có thể tiến tới:

1 Agent → nhiều Agent → Cloud Agents → tự xử lý issue → tự tạo PR → tự merge PR

Tác giả hiện đã đến mức Agent có thể tự merge PR; cô kể có ngày thức dậy thấy khoảng 20 PR đã được Agent merge và kiểm tra trên main.

2. Trust Curve – tư tưởng trung tâm

Tác giả xuất phát từ một vấn đề rất thực tế:

AI Agent thường:

• đoán thay vì kiểm tra

• hallucinate

• tự tin kết luận sai

• nói “đã tìm ra nguyên nhân” nhưng thực tế chưa phải nguyên nhân

• sửa code dựa trên assumption

Nếu engineer không trust Agent, engineer phải:

Agent làm → người kiểm tra → Agent sửa → người kiểm tra → Agent sửa...

Con người trở thành bottleneck.

Vì vậy, không thể ngay lập tức:

“Tôi sẽ spawn 1.000 agents.”

Nếu còn không tin nổi output của 1 Agent thì 1.000 Agent chỉ tạo ra 1.000 lần vấn đề.

3. Bước đầu tiên: Verification

Đây có lẽ là phần quan trọng nhất về mặt kỹ thuật.

Tác giả nói:

Skill quan trọng nhất khi làm việc với Agent là verification.

Verification nghĩa là Agent phải tự kiểm tra kết quả bằng cách chạy hệ thống thật, thay vì chỉ đọc code rồi đoán.

Ví dụ:

• chạy application

• chạy test

• đọc stack trace

• lấy CPU trace

• lấy heap snapshot

• mở iOS simulator

• thao tác UI

• kiểm tra DOM

• kiểm tra behavior thực tế

Mục tiêu đầu tiên chưa phải:

“Agent viết code đẹp.”

Mà là:

“Agent viết code đúng.”

Đây là bước cực kỳ quan trọng để xây dựng trust.

4. Verification Skill

Tác giả lấy ví dụ Cursor.

Ban đầu khi debug performance của application, cô phải tự:

1. mở Chrome DevTools

2. lấy trace

3. xem flame graph

4. tìm nguyên nhân

5. đưa screenshot/trace cho Agent

6. Agent đoán

7. sửa

8. lại kiểm tra

→ Con người là verification bottleneck.

Sau đó cô xây một verification skill để Agent có khả năng:

Launch application
        ↓
Interact with application
        ↓
Collect trace / logs / screenshot
        ↓
Analyze
        ↓
Change code
        ↓
Run again
        ↓
Verify

Đặc biệt với web/Electron/iOS, Agent có thể được dạy cách sử dụng các công cụ điều khiển ứng dụng và simulator.

5. Feature Map – một ý tưởng rất đáng chú ý

Có một vấn đề:

Agent biết cách chạy app nhưng không biết app có những feature gì.

Ví dụ user report:

“Sidebar bị lag.”

Agent không biết:

• Sidebar nằm ở đâu

• component nào

• cách mở Sidebar

• button nào

• DOM selector nào

• keyboard shortcut nào

• feature liên quan nằm ở đâu trong code

Vì vậy tác giả tạo Feature Map.

Feature Map giống như một:

bản đồ của application dành cho Agent.

Nó mô tả:

Feature
 ├── User perspective
 ├── How to reach feature
 ├── Keyboard shortcuts
 ├── DOM elements
 ├── Selectors
 └── Related code

Nhờ vậy Agent có thể nhận một bug report rất mơ hồ hoặc chỉ có screenshot rồi tìm được feature tương ứng.

Đây là một insight rất mạnh:

Agent không chỉ cần “knowledge về code”, mà cần “operational knowledge về hệ thống”.

6. Pstack – Skill không phải magic prompt

Tác giả xây một plugin tên Pstack.

Điểm thú vị là cô không chủ động ngồi thiết kế Pstack từ đầu.

Quy trình là:

Observe Agent
      ↓
Find failure mode
      ↓
Understand why Agent failed
      ↓
Encode solution as Skill
      ↓
Evaluate Skill
      ↓
Improve Skill

Ví dụ:

Agent không đọc đúng code.

→ tạo skill:

“Stop guessing. Search/read the relevant code first.”

Agent không biết navigate application.

→ tạo:

Verification Skill + Feature Map.

Agent thường chọn shortcut nguy hiểm.

→ tạo:

Architecture constraints / CI rules.

7. Skill thực chất là “Engineering Knowledge được encode”

Đây là một ý rất quan trọng.

Skill có thể đơn giản chỉ là Markdown chứa:

• instructions

• conventions

• workflow

• constraints

• domain knowledge

• cách verify

• cách sử dụng tools

Tức là thay vì engineer giỏi phải tự làm, ta biến kinh nghiệm của engineer thành thứ Agent có thể sử dụng.

Có thể hình dung:

Senior Engineer Experience
          ↓
      Skill / Rules
          ↓
       AI Agent
          ↓
   Consistent execution

Đây chính là cách biến engineering judgment → machine-executable knowledge.

8. Evals = Unit Test cho Agent

Đây là phần cực kỳ quan trọng nếu bạn muốn xây AI-DLC / Multi-Agent.

Tác giả gọi:

Eval ≈ Unit Test cho Agent/Skill

Ví dụ bạn tạo một Skill mới.

Không nên chỉ nghĩ:

“Có vẻ Agent làm tốt hơn.”

Mà phải có evaluation:

Task
 ↓
Spawn multiple agents
 ↓
Run Skill
 ↓
Measure result
 ↓
Judge result
 ↓
Compare versions

Có thể có:

• coordinator agent

• nhiều sub-agents

• judge agent

• rubric

• score
  

Đặc biệt tác giả còn dùng model khác để judge, tránh trường hợp model tự đánh giá chính mình quá thiên vị.

9. Skill phải được maintain giống code

Một Skill tốt hôm nay chưa chắc tốt sau 3 tháng.

Codebase thay đổi:

Application changes
      ↓
Feature changes
      ↓
Architecture changes
      ↓
Skill may become stale

Do đó phải:

• observe Agent

• chạy eval

• phát hiện degradation

• sửa Skill

• chạy eval lại

Tác giả mô tả quá trình này giống hill climbing:

liên tục cải thiện Skill dựa trên score của Eval.

10. Từ Local Agent → Cloud Agent

Tác giả khuyến nghị:

Giai đoạn đầu

Local trước.

Vì local giúp bạn quan sát:

• Agent đang làm gì

• gọi tool nào

• interaction với application ra sao

• verification có hoạt động không

Sau khi verification đủ tốt:

Scale lên Cloud Agent

Ví dụ:

Bug report
     ↓
Cloud Agent
     ↓
Launch application
     ↓
Reproduce bug
     ↓
Investigate
     ↓
Fix
     ↓
Run verification
     ↓
Create PR

11. Ví dụ “Benny”

Đây là ví dụ rất hay.

Benny là một Agent nhận bug report.

Nó tự:

Bug report
    ↓
Start computer in cloud
    ↓
Run Cursor
    ↓
Run application
    ↓
Try to reproduce bug
    ↓
Analyze

Có trường hợp Benny reproduce được bug nhưng phát hiện:

bug thực ra đã được fix trên main.

Con người không cần ngồi cả tiếng để xác minh nữa.

Điểm quan trọng:

Verification Skill một khi đã xây được thì không chỉ giúp 1 engineer. Nó có thể trở thành infrastructure cho cả team/company.

12. Không được nhảy thẳng lên 1.000 Agent

Lộ trình mà bài nói đề xuất là:

Manual Agent
     ↓
Verification
     ↓
Skills
     ↓
Evals
     ↓
Trusted Local Agent
     ↓
Cloud Agent
     ↓
Multiple Agents
     ↓
Automated PR
     ↓
Auto Merge

Không nên:

Agent chưa đáng tin
       ↓
1000 Cloud Agents
       ↓
💥

Vì:

• tốn token

• tốn tiền

• tạo nhiều code rác

• khó debug

• mất kiểm soát

Tác giả nhấn mạnh Trust phải được xây dựng từng bước, không có shortcut.

13. Architecture – phần cực kỳ đáng chú ý

Đây là phần mình nghĩ rất liên quan đến hướng AI-DLC Multi-Agent.

Tác giả đưa ra một luận điểm:

Agent rất thích shortcut.

Vậy đừng chỉ bảo Agent:

“Don't take shortcuts.”

Mà hãy:

Thiết kế architecture sao cho shortcut cũng chính là con đường đúng.

Ví dụ:

Feature
 └── everything related to feature

Thay vì code của một feature nằm rải rác khắp repository.

Agent nhìn vào:

/onboarding

là biết:

“À, tôi đang làm onboarding → phần lớn code cần thiết ở đây.”

14. Nguyên tắc rất hay: “Shortest path = best path”

Đây là một trong những câu đáng nhớ nhất của bài.

Agent thường tìm:

con đường ngắn nhất để giải quyết task.

Vậy architecture phải được thiết kế sao cho:

con đường ngắn nhất cũng là con đường đúng nhất.

Ví dụ:

❌ Good architecture
     ↳ 5 layers
     ↳ 8 files
     ↳ complex convention

Agent → tìm shortcut → phá architecture


✅ Agent-friendly architecture
Feature
 └── related code
      └── obvious pattern

Agent → copy existing pattern → đúng

Đây là architecture dành cho Agent, không đơn thuần là architecture dành cho human.

15. Brownfield vs Greenfield

Tác giả có một quan sát thú vị:

Brownfield

Codebase cũ nhưng đã có:

• architecture

• conventions

• CI

• guardrails

• permission

• framework

• patterns

→ Agent đôi khi lại làm khá tốt.

Vì guardrails đã tồn tại.

Greenfield

Đặc biệt dự án được:

vibe coding rất nhanh

thì nguy hiểm hơn.

Vì:

No architecture
No constraints
No conventions
No tests
No guardrails
        ↓
Agent chooses easiest solution
        ↓
Codebase grows organically
        ↓
Architecture becomes messy
        ↓
Future agents become harder to control

Tác giả gọi vấn đề này là organic architecture.

16. CI không chỉ để test — CI trở thành “luật vật lý”

Đây là một insight rất quan trọng.

Tác giả không chỉ dùng:

Rules
Skills
AGENTS.md
Style Guide

mà đưa những rule quan trọng vào hard enforcement.

Ví dụ trong hệ thống của họ:

• cấm useEffect

• kiểm tra dependency graph

• cấm import sai giữa Electron main/renderer

• lint

• compiler diagnostics

• performance constraints

• stability checks

Nếu vi phạm:

CI = RED

Agent không thể merge.

17. 5 lớp kiểm soát Agent

Có thể gom tư tưởng của tác giả thành:

                 AI Agent
                    │
        ┌───────────▼───────────┐
        │       Skills          │
        │ Knowledge / Workflow  │
        └───────────┬───────────┘
                    │
        ┌───────────▼───────────┐
        │        Rules          │
        │ Engineering practices │
        └───────────┬───────────┘
                    │
        ┌───────────▼───────────┐
        │    Verification       │
        │  Runtime correctness  │
        └───────────┬───────────┘
                    │
        ┌───────────▼───────────┐
        │       Evals           │
        │ Agent quality testing │
        └───────────┬───────────┘
                    │
        ┌───────────▼───────────┐
        │     CI / Guardrails   │
        │ Hard enforcement      │
        └───────────────────────┘

Và architecture/codebase nằm xuyên suốt bên dưới để giới hạn những gì Agent có thể làm.

Tác giả đặc biệt nhấn mạnh không nên chỉ dựa vào Skill/Rule, vì Agent vẫn có thể quên hoặc không tuân thủ nhất quán. Hard constraints trong CI mạnh hơn.

18. Vai trò Engineer thay đổi như thế nào?

Đây là thông điệp lớn thứ hai của bài.

Engineer truyền thống:

Engineer
 ↓
Write code
 ↓
Test
 ↓
Debug
 ↓
Review
 ↓
Ship

Engineer trong Agentic Engineering:

Engineer
 ↓
Design architecture
 ↓
Define constraints
 ↓
Create skills
 ↓
Create verification
 ↓
Create evals
 ↓
Orchestrate agents
 ↓
Monitor quality
 ↓
Improve system

Tác giả dùng analogy:

Head Chef

Bạn không còn tự nấu từng món.

Bạn:

• thiết kế kitchen

• chia station

• phân công task

• đặt quy trình

• kiểm soát chất lượng

Agent giống như đội ngũ line cooks.

19. Một câu chốt lại toàn bộ bài

Nếu phải nén bài này thành một công thức, mình sẽ viết:

AI Agent Productivity
        =
      Model
        ×
     Skills
        ×
   Verification
        ×
       Evals
        ×
    Architecture
        ×
   Guardrails
        ×
       Trust

Trong đó Trust không phải thứ được cho sẵn.

Nó là kết quả của:

Observe
  ↓
Find failure
  ↓
Create skill
  ↓
Verify
  ↓
Evaluate
  ↓
Add constraints
  ↓
Repeat
  ↓
Trust increases
  ↓
Parallelize
  ↓
Automate

20. Nếu ánh xạ trực tiếp với bài toán AI-DLC Multi-Agent

Bài này có thể map rất đẹp vào kiến trúc AI-DLC Multi-Agent:

Đặc biệt, insight quan trọng nhất để mang sang AI-DLC là:

Đừng cố làm Agent thông minh hơn trước. Hãy xây một môi trường khiến Agent khó làm sai hơn, dễ verify hơn, và con đường ngắn nhất cũng là con đường đúng.

Đó mới là thứ cho phép từ 1 Agent → Multi-Agent → Autonomous Engineering System.

Nếu bạn đang đọc series CCAR-P → AI-DLC Multi-Agent, thì bài chia sẻ này thực ra cung cấp một lớp tư duy rất quan trọng để bổ sung vào kiến trúc: Verification + Eval + Guardrail + Trust/Autonomy loop.