OpenCode.io.vn
Quay lại Blog
26 tháng 5, 2026Nguyễn Ngô Thượng10 phút đọc

Agentic Engineering là gì? Đừng chỉ vibe code, hãy xây hệ thống để AI làm việc ổn định

Giải thích cực dễ hiểu về agentic engineering: khác gì vibe coding, vì sao system quan trọng hơn model, và cách triển khai workflow plan → execute → review → verify với OpenCode và .config/opencode.

#agentic-engineering#vibe-coding#opencode#workflow#agents#skills#commands#ai-coding

Agentic Engineering là gì? Đừng chỉ vibe code, hãy xây hệ thống để AI làm việc ổn định

Nhiều người đang dùng AI theo kiểu rất quen: giao một việc, thấy sai thì sửa prompt, thấy thiếu thì nhắc thêm, thấy lệch thì kéo lại. Cách đó vẫn có ích, nhưng nó không scale. Bạn đang phải ngồi cạnh AI như một người quản đốc chỉ từng viên gạch.

Ý chính của video rất đơn giản:

Đừng chỉ dùng AI để code từng việc lẻ. Hãy xây một cách làm việc để AI có thể làm việc nhiều lần, ổn định, có kiểm tra, có công cụ, có quy trình.

Bài này sẽ tách rõ 2 khái niệm vibe codingagentic engineering, rồi đi đến phần quan trọng hơn: làm sao biến ý tưởng đó thành workflow thực tế với OpenCode và .config/opencode.


TL;DR

  • Vibe coding là bạn điều khiển AI từng đoạn một.
  • Agentic engineering là bạn thiết kế cả hệ thống để AI tự làm đúng quy trình.
  • Khác biệt lớn nhất không nằm ở model mạnh hay yếu, mà nằm ở system: prompt chuẩn, plan, test, review, quyền truy cập tool, sandbox, quality gates.
  • Nếu làm đúng, AI không còn là "một trợ lý gõ code", mà là một dây chuyền làm việc có thể lặp lại.
  • Với OpenCode, bạn có thể bắt đầu rất thực tế bằng cách chuẩn hóa agents, commands, skills, AGENTS.md và workflow trong .config/opencode.

Vibe Coding là gì?

Vibe coding là cách làm kiểu:

  1. "AI ơi làm feature này đi."
  2. AI viết một bản đầu.
  3. Bạn thấy sai, yêu cầu sửa.
  4. AI sửa tiếp.
  5. Bạn phát hiện thiếu case khác, lại chỉnh tiếp.

Nói ngắn gọn: bạn đang lái AI bằng các câu lệnh rời rạc.

Điểm mạnh của vibe coding là:

  • Nhanh để bắt đầu
  • Phù hợp khi đang thử ý tưởng
  • Hữu ích cho task nhỏ hoặc prototype

Điểm yếu là:

  • Kết quả không ổn định
  • Dễ quên bước test, review, cleanup
  • Khó lặp lại cho team
  • Chất lượng phụ thuộc quá nhiều vào người ngồi prompt

Ví dụ đời thường: bạn đứng cạnh thợ xây và nói từng câu "đặt viên này ở đây", "trét thêm xi măng", "đục chỗ kia ra". Làm được, nhưng mệt và không thành quy trình.


Agentic Engineering là gì?

Agentic engineering không dừng ở chuyện "ra lệnh cho AI". Nó là việc thiết kế môi trường, quy trình và quyền hạn để AI làm việc theo cách có thể kiểm soát được.

Thay vì:

Làm giúp tôi feature này.

Bạn chuyển sang:

Đọc issue, tìm file liên quan, lập plan, implement theo pattern sẵn có, chạy test, nếu fail thì debug, sau đó review và tóm tắt thay đổi.

Đó là khác biệt cốt lõi:

  • Vibe coding = điều khiển từng bước
  • Agentic engineering = thiết kế bộ máy để AI tự đi đúng đường

Trong thực tế, bộ máy đó thường gồm:

  • Prompt chuẩn
  • Agent chuyên trách
  • Checklist chất lượng
  • Tool access đúng phạm vi
  • Test và review tự động
  • Sandbox hoặc approval cho thao tác rủi ro

Nói thẳng: bạn không chỉ dùng AI, bạn thiết kế cách AI làm việc.


Vì sao system quan trọng hơn model?

Nhiều người nghĩ muốn AI làm tốt hơn thì chỉ cần đổi sang model mạnh hơn. Cách nghĩ này thiếu một nửa bức tranh.

Một model mạnh đặt trong workflow lộn xộn vẫn dễ tạo ra:

  • Code thiếu test
  • Sửa đúng bug A nhưng làm vỡ B
  • Prompt vòng lặp dài và tốn token
  • Kết quả khó review

Ngược lại, một model không phải top đầu nhưng chạy trong workflow tốt vẫn cho output đáng tin hơn:

  • Có spec rõ
  • Có plan trước khi code
  • Có quyền đọc context đủ
  • Có test để tự kiểm tra
  • Có review gate trước khi kết luận

Ví dụ đời thường: dao sắc là tốt, nhưng bếp bừa, không công thức, không kiểm chất lượng thì món ăn vẫn hỏng.


5 trụ cột của agentic engineering

1. Agent Harness: bộ khung điều khiển agent

Agent harness là tập hợp các luật, công cụ, quyền hạn và quy trình mà agent phải tuân theo.

Cùng một model, nhưng harness khác thì chất lượng khác.

Ví dụ rất gần với OpenCode:

  • Có agent chuyên explore
  • Có agent chuyên plan
  • Có agent chuyên execute
  • Có agent chuyên review
  • Có rule không sửa file ngoài phạm vi
  • Có command chạy test
  • Có checklist trước khi hoàn thành task

Nếu không có harness, AI sẽ phải tự đoán:

  • Phải đọc gì trước?
  • Có nên lập plan không?
  • Được sửa file nào?
  • Khi nào cần dừng để báo user?

Harness tốt giúp bỏ phần đoán đó đi.

2. Software Factory: nhà máy làm phần mềm

Software factory nghĩa là đừng xử lý từng feature như một công việc thủ công hoàn toàn. Hãy nghĩ theo dây chuyền.

Ví dụ task "xuất báo cáo doanh thu PDF":

Cách làm thủ công

  • Đọc yêu cầu
  • Tự đoán design
  • Code backend
  • Code frontend
  • Tự test
  • Tự sửa bug

Cách làm như một software factory

  1. Có spec template
  2. Có agent đọc codebase
  3. Có agent lên plan
  4. Có agent implement
  5. Có agent viết test
  6. Có agent review
  7. Có pipeline verify kết quả

Lúc này vai trò của senior engineer thay đổi. Bạn không còn chỉ là người tự tay làm từng bước. Bạn là người thiết kế dây chuyền.

3. Extensible Software: phần mềm phải dễ thay đổi

Trong hệ AI, mọi thứ đổi rất nhanh:

  • Model đổi
  • Giá API đổi
  • Tool mới xuất hiện
  • Prompt cũ mất tác dụng
  • Workflow cần tách nhỏ hơn

Nếu code dính cứng vào một provider hoặc một cách gọi tool, bạn sẽ bị chậm.

Ví dụ xấu:

openai.chat.completions.create(...)

Ví dụ tốt hơn:

aiProvider.generateText(...)

Khác biệt ở đây không chỉ là "đẹp code". Nó là khả năng sống sót khi hệ sinh thái đổi quá nhanh.

4. Always-On Agents: chạy nền nhưng phải tạo giá trị

Agent chạy nền không tự động là hay. Thứ cần đo là: mỗi token có tạo ra giá trị thật không?

Ví dụ đốt tiền:

  • Cứ 5 phút tóm tắt một kênh chat
  • Không ai đọc
  • Không ai hành động

Ví dụ có giá trị:

  • Theo dõi lỗi production
  • Phát hiện mẫu lỗi lặp lại
  • Tạo issue
  • Gợi ý patch
  • Mở PR nháp
  • Chỉ ping người khi cần duyệt

Câu hỏi đúng không phải là:

Agent có chạy 24/7 không?

Mà là:

1 đô token này có đổi lại được nhiều hơn 1 đô giá trị không?

5. Agentic Access: agent phải có đúng công cụ

Bạn không thể yêu cầu agent debug payment nhưng lại không cho nó:

  • đọc log
  • xem schema
  • chạy test
  • gọi API test
  • đọc issue liên quan

Khi thiếu quyền truy cập, agent phải đoán. Và mỗi lần đoán là thêm:

  • token tax
  • thời gian
  • sai số

Tuy nhiên, quyền phải đi kèm ranh giới:

  • Không xóa production database
  • Không deploy thẳng nếu chưa duyệt
  • Không chạy lệnh nguy hiểm
  • Mọi quyền nhạy cảm cần human approval

Ví dụ thực tế: từ vibe coding sang agentic engineering

Giả sử bạn muốn làm tính năng xuất báo cáo doanh thu PDF.

Nếu bạn vibe code

Bạn sẽ làm kiểu:

AI ơi làm chức năng xuất PDF cho báo cáo doanh thu.

Rồi sau đó:

  • thêm field
  • sửa format
  • vá bug font
  • vá bug dữ liệu rỗng
  • vá bug permission

Kết quả thường là một chuỗi sửa lẻ tẻ.

Nếu bạn làm theo agentic engineering

Bạn chuẩn hóa thành workflow:

  1. Tạo spec: gồm ai dùng, dữ liệu gì, layout gì, lỗi nào cần xử lý.
  2. Giao agent explore đọc codebase để xem đang dùng thư viện PDF nào.
  3. Giao agent plan chia task backend, UI, rendering, test.
  4. Giao agent build implement theo pattern sẵn có.
  5. Giao agent test tạo test cho dữ liệu rỗng, dữ liệu lớn, lỗi phân quyền.
  6. Giao agent review kiểm tra maintainability và security.
  7. Chỉ khi mọi gate đạt thì mới coi là xong.

Đây là lúc AI bắt đầu giống một team có quy trình, thay vì một bàn tay gõ code theo cảm hứng.


Cách triển khai với OpenCode và .config/opencode

Phần này là chỗ quan trọng nhất nếu bạn muốn biến tư duy trên thành thứ dùng được ngay.

Cấu trúc đề xuất

Bạn nên tách 2 lớp:

  • ~/.config/opencode/: thứ dùng lại cho nhiều project
  • .opencode/ trong project: thứ gắn với codebase cụ thể

Ví dụ:

~/.config/opencode/
├── agent/
│   ├── planner.md
│   ├── reviewer.md
│   └── tester.md
├── command/
│   ├── plan.md
│   ├── review.md
│   └── ship.md
└── skill/
    └── task-breakdown/
        └── SKILL.md

project-root/
├── AGENTS.md
├── .opencode/
│   ├── agent/
│   │   └── web-developer.md
│   └── command/
│       ├── check.md
│       └── exec.md

1. Chuẩn hóa AGENTS.md

AGENTS.md là nơi bạn nói cho agent biết:

  • project này là gì
  • style code ra sao
  • workflow phải đi theo thứ tự nào
  • agent/persona nào đang có sẵn
  • task nào phải plan trước, task nào được làm ngay

Nếu file này mơ hồ, agent sẽ phải đoán.

Checklist tối thiểu:

  • mô tả project và stack
  • coding standards
  • workflow plan → execute → review
  • quyền và giới hạn
  • nơi lưu docs/plans/tasks

2. Tách agent theo vai trò, không nhồi một prompt khổng lồ

Thay vì một agent "biết hết mọi thứ", hãy chia vai trò:

  • planner: đọc yêu cầu, chia task
  • explore: đọc codebase, tìm file liên quan
  • builder: implement
  • reviewer: review thay đổi
  • tester: nghĩ test cases và xác minh

Ví dụ ~/.config/opencode/agent/reviewer.md:

---
description: Review code changes for correctness, regression risk, maintainability, and missing tests
mode: subagent
model: anthropic/claude-sonnet-4
tools:
  write: false
  edit: false
  bash: true
---

You are a strict code reviewer.

Review priorities:
1. Behavioral regressions
2. Security and data safety
3. Missing tests
4. Maintainability

Do not edit files. Provide findings first.

Mục tiêu là giảm ambiguity, không phải làm prompt "ngầu".

3. Chuẩn hóa commands cho workflow lặp lại

Commands giúp bạn đỡ phải viết lại cùng một hướng dẫn.

Ví dụ ~/.config/opencode/command/plan.md:

---
description: Create an implementation plan before coding
agent: planner
---

Read the user request, inspect the codebase, identify constraints, then produce:
1. Scope
2. Risks
3. Step-by-step implementation plan
4. Verification plan

Ví dụ ~/.config/opencode/command/review.md:

---
description: Review current changes before closing task
agent: reviewer
---

Review the current workspace changes.
Prioritize correctness, regressions, and missing tests.
Return findings first, then open questions, then a short summary.

Command tốt là command ngắn, rõ, tái sử dụng được.

4. Dùng skills để nhúng cách làm, không chỉ nhúng persona

Agent là "ai đang làm".
Skill là "cách làm việc cho loại task đó".

Ví dụ ~/.config/opencode/skill/task-breakdown/SKILL.md:

---
name: task-breakdown
description: Break implementation work into concrete, verifiable steps
---

Use when a task affects multiple files or has non-trivial behavior.

Steps:
1. Read the requirement carefully
2. Identify impacted modules
3. Separate implementation from verification
4. Call out migration or rollout risk
5. Define done criteria

Nếu không có skills, agent thường biết "vai" nhưng không có đủ "quy trình".

5. Thêm quality gates bắt buộc

Đây là phần biến workflow từ "thông minh có vẻ đúng" thành "đáng tin hơn".

Mỗi task nên có ít nhất 4 gate:

  1. Đã đọc codebase liên quan chưa?
  2. Đã có plan chưa?
  3. Đã verify bằng test/lint/manual check chưa?
  4. Đã review rủi ro regression chưa?

Bạn có thể encode những gate này ngay trong:

  • AGENTS.md
  • command /check
  • reviewer agent
  • task templates trong docs/plans/

TODO list thực thi với .config/opencode

Nếu muốn bắt đầu từ mức thực dụng nhất, đây là checklist tôi khuyên dùng.

Giai đoạn 1: bỏ vibe coding hoàn toàn ngẫu hứng

  • Tạo ~/.config/opencode/agent/planner.md
  • Tạo ~/.config/opencode/agent/reviewer.md
  • Tạo ~/.config/opencode/agent/tester.md
  • Tạo ~/.config/opencode/command/plan.md
  • Tạo ~/.config/opencode/command/review.md
  • Tạo ~/.config/opencode/command/check.md
  • Viết rõ output format cho từng agent

Giai đoạn 2: chuẩn hóa theo project

  • Tạo AGENTS.md cho từng project
  • Ghi rõ stack, conventions, test commands, forbidden actions
  • Tạo .opencode/command/exec.md để chạy workflow theo pattern của project
  • Tạo .opencode/agent/<domain-agent>.md nếu project có domain riêng như web-developer, security-review, dbt-engineer
  • Chuẩn hóa nơi lưu plan: docs/plans/<feature>/plan.md

Giai đoạn 3: thêm quality gates

  • Mọi task không tầm thường phải đi qua bước plan
  • Reviewer agent phải ưu tiên bug, regression, missing tests
  • Tester agent phải liệt kê edge cases trước khi kết luận xong
  • Command /check phải nhắc lại trạng thái plan, task pending và verification
  • Cấm kết thúc task nếu chưa có ít nhất một bước verify cụ thể

Giai đoạn 4: tối ưu token economics

  • Xác định workflow nào thực sự tạo giá trị nếu chạy định kỳ
  • Không bật always-on agent cho việc không ai đọc
  • Theo dõi task nào agent phải đoán vì thiếu access
  • Mở thêm quyền đọc log/schema/docs nội bộ cho agent ở môi trường an toàn
  • Thêm approval gate cho lệnh nguy hiểm hoặc thao tác production

Giai đoạn 5: làm hệ thống dễ mở rộng

  • Gom phần gọi model/provider qua abstraction chung
  • Tách prompt dùng chung ra khỏi prompt theo project
  • Không hard-code provider ở nhiều nơi
  • Viết lại command/skill để thay model vẫn không phải đổi toàn bộ workflow
  • Định kỳ review agent configs như review code

Mẫu khởi đầu cực gọn cho .config/opencode

Nếu bạn muốn bắt đầu ngay hôm nay, chỉ cần 3 file này là đủ để thấy khác biệt.

~/.config/opencode/agent/planner.md

---
description: Analyze requests and create concrete implementation plans
mode: subagent
model: anthropic/claude-sonnet-4
tools:
  write: false
  edit: false
  bash: true
---

Before any substantial coding work:
1. Read relevant files
2. Restate scope
3. Identify risks
4. Produce a concrete plan
5. Define verification steps

~/.config/opencode/command/plan.md

---
description: Plan the requested work before editing code
agent: planner
---

Inspect the codebase first, then create a focused implementation plan.
Do not write code until the plan is complete.

~/.config/opencode/command/check.md

---
description: Check execution progress against the plan
---

Report:
1. What is done
2. What is pending
3. Risks or blockers
4. What should happen next

Chỉ riêng việc này đã đủ để workflow của bạn bớt ngẫu hứng đi rất nhiều.


Khi nào vẫn nên vibe code?

Không cần cực đoan. Vibe coding vẫn có chỗ đứng nếu bạn đang:

  • thử một ý tưởng nhỏ
  • spike prototype
  • explore API mới
  • cần một bản nháp thật nhanh

Nhưng khi task bắt đầu có:

  • nhiều file
  • rủi ro regression
  • logic nghiệp vụ
  • test và deploy
  • nhiều người cùng làm

thì nên rời khỏi vibe coding càng sớm càng tốt.


Kết luận

Điều đáng nhớ nhất của video không phải là một thuật ngữ mới. Nó là sự đổi vai của developer trong thời AI.

Senior engineer mạnh không phải là người prompt từng dòng giỏi nhất. Người mạnh là người biết:

  • dựng harness
  • chuẩn hóa workflow
  • cấp đúng access
  • thêm quality gates
  • biến AI từ "một trợ lý" thành "một hệ thống làm việc"

Nói ngắn gọn:

Đừng chỉ thuê một trợ lý AI. Hãy xây cả bộ máy để trợ lý đó làm việc như một team có quy trình.

Nếu bạn đang dùng OpenCode, nơi bắt đầu thực tế nhất không phải là săn model mới mỗi tuần. Nơi bắt đầu là dọn lại .config/opencode, chuẩn hóa AGENTS.md, và buộc mọi task quan trọng đi qua plan → execute → review → verify.

Đọc tiếp

Một vài bài liên quan có thể bạn sẽ thích