# Thôi micromanage coding agent: workflow bốn phase

[Carl Lindberg](https://homus.dev/speakers/carl-lindberg) · [Carl Lindberg](https://homus.dev/orgs/carl-lindberg)

> Workflow bốn phase với coding agent: grilling theo round, shipit giao code qua Spec Kit, agent review agent, và mức human review theo rủi ro của PR.

Topics: Coding Agents, Workflow, Skills

Canonical: https://homus.dev/talks/i-stopped-micromanaging-my-ai-coding-agents

## 1. Thôi micromanage: hai chỗ đặt sự chú ý

Carl mở đầu bằng một lời thú nhận: anh từng micromanage các coding agent của mình. Anh duyệt từng bước một, và việc đó tốn sự chú ý của anh nhiều hơn phần nó tiết kiệm được. Theo Carl (video đăng ngày 01/11/2026), giờ anh dồn sự chú ý vào hai chỗ, còn mọi thứ ở giữa thì agent làm. Video cho thấy hai chỗ đó là đâu và agent làm những gì khi không có anh. Cuối video là câu hỏi mà anh vẫn chưa có câu trả lời gọn gàng: một con người nên đọc bao nhiêu phần code đó trước khi nó được merge.

![Carl Lindberg ngồi trước camera trong phòng làm việc](https://homus.dev/photos/NKRLirVTOt0-0107.jpg)

Carl Lindberg nói trước camera ở phần mở đầu video đăng ngày 01/11/2026.

Về bản thân, Carl là một cloud consultant: anh thiết kế, viết và review Terraform cho các môi trường Azure production thật. Trong công việc đó anh chạy coding agent mỗi ngày, cho những thứ như Terraform provider nội bộ của công ty và các tool mà team anh dùng. Đây là workflow anh đang dùng cho công việc ấy (video đăng ngày 01/11/2026).

Anh chia việc code với agent thành bốn phase, và nói rằng bạn có thể chép cả bốn (video đăng ngày 01/11/2026):

- **Grilling.** Vì sao misalignment làm hỏng phần lớn công việc với agent, và cách một agent phỏng vấn bạn theo từng round cho tới khi hai bên thống nhất (theo Carl, video đăng ngày 01/11/2026).

- **Delivery.** shipit, một skill do một đồng nghiệp của anh xây, kết hợp grilling với Spec Kit, chạy trực tiếp trên một ứng dụng demo (video đăng ngày 01/11/2026).

- **Agent review agent.** Và vì sao agent viết code không bao giờ là agent review code đó (theo Carl, video đăng ngày 01/11/2026).

- **Review của chính anh.** Khi nào anh merge luôn, và khi nào anh nhờ một agent dẫn mình đi qua feature trước khi merge (video đăng ngày 01/11/2026).

## 2. Ghi chú "how I drive coding agents now"

Mấy hôm trước khi quay, Carl có một insight, và nó khiến anh viết một ghi chú tên là "how I drive coding agents now". Anh kể rằng anh luôn cảm thấy thiếu một thứ gì đó. Anh dùng agentic AI, chạy agent mỗi ngày, nhưng có một việc anh không làm theo cách mà "dân chuyên" làm, nói tạm như vậy vì không tìm được từ nào hay hơn (video đăng ngày 01/11/2026).

![Ghi chú how-i-drive-coding-agents-now mở trong Obsidian](https://homus.dev/photos/NKRLirVTOt0-0154.jpg)

Ghi chú "how-i-drive-coding-agents-now" trong video đăng ngày 01/11/2026: hễ còn chút "sương mù" nào thì grill; xong rồi thì chỉ cần `/shipit` hoặc `/pstack:poteto-mode ship it im stepping away`, thứ mang lại cả tiến độ lẫn sự rõ ràng. Dòng dưới: anh và agent có chung một cách hiểu, và anh thôi micromanage những chuyện nhỏ nhặt.

Điều anh viết trong ghi chú, theo lời anh (video đăng ngày 01/11/2026): một insight anh rút ra khi làm với coding agent là hễ có một chút "sương mù" (fog) nào, cứ grill. Anh dùng skill grill-me của Matt Pocock, nhưng đó cũng có thể là plan mode, hay một slash command `/interview`; anh từng thấy vài skill mang tên đó cùng nhắm tới một việc. Rồi anh nói thẳng: thật lòng thì bạn không nên dùng plan mode. Có những skill tốt hơn plan mode, và theo anh, chuẩn mực (golden standard) có vẻ là grill-me.

Phần thứ hai của ghi chú cũng là lý do video này ra đời: khi grill xong, theo đúng nghĩa đen chỉ cần gõ `/shipit`, hoặc dùng pstack ở poteto mode với câu "ship it, I'm stepping away". Carl giải thích cả hai ở các phần sau. Điều cần biết lúc này: nó dẫn anh tới dòng "anh và agent có chung một cách hiểu, và anh thôi micromanage những thứ nhỏ nhặt nhất" (video đăng ngày 01/11/2026).

Chính việc micromanage là thứ đang "giết" anh, Carl nói. Nó khiến anh, ừ thì, micromanage, và tốn rất nhiều công sức đầu óc vào những thứ rốt cuộc chẳng quan trọng. Anh muốn có được toàn bộ phần năng suất mà coding agent có thể mang lại, chứ không muốn đây chỉ là một cách làm việc mới khiến anh hiệu quả hơn một chút nhưng không nhiều (video đăng ngày 01/11/2026).

Trước khi bạn bấm thoát và cho rằng đây chỉ là lời lảm nhảm của một kẻ điên, Carl hứa video sẽ phân tích cụ thể cách anh biến ghi chú này thành những gì anh làm hằng ngày: các bước anh dùng để tạo ra sản phẩm, và cách anh bảo đảm sản phẩm đó chắc chắn. Anh nói về bốn bước anh đi qua khi chạy coding agent, bước nào cần nhiều sự chú ý của anh, và bước nào giờ anh để hẳn cho agent tự xoay xở (video đăng ngày 01/11/2026).

## 3. Bốn phase và mức chú ý ở từng phase

Theo Carl (video đăng ngày 01/11/2026), bước một, tức phase lập kế hoạch, ở đây là phase grilling, nơi bạn bị một agent phỏng vấn không ngừng, là chỗ tốt nhất để bạn bỏ thời gian vào. Bạn càng bỏ nhiều thời gian và năng lượng vào phase này, mọi thứ còn lại càng tự động tốt lên. Trên sơ đồ, mức chú ý của anh ở giai đoạn này là rất cao.

![Sơ đồ bốn phase: Grilling, shipit/pstack, Agents review, You review, kèm hàng YOUR ATTENTION](https://homus.dev/photos/NKRLirVTOt0-0443.jpg)

1 Planning (Grilling, các round cho tới khi frontier trống), 2 Delivering (shipit / pstack: spec, build, PR, không câu hỏi), 3 Agent review (một model tìm lỗi, model khác sửa), 4 Human review (bạn review PR theo một quy trình bạn tự chỉnh dần). Hàng YOUR ATTENTION: high ở phase 1, "none: nothing waits on you" ở giữa, high ở phase 4.

Phase hai là giao code (delivering). Đó là lúc anh dùng shipit hoặc pstack: từ phase grilling, anh có trong tay một spec, hoặc nếu việc nhỏ thì chỉ là một thứ agent có thể build luôn. Rồi agent mở một PR mà không hỏi gì thêm. Trong phase hai, không có gì chờ anh cả (theo Carl, video đăng ngày 01/11/2026).

Phase ba là agent review. Ngày nay review bằng agent thế nào? Có người sẽ nghĩ đây là review, vậy đây là chỗ con người nhảy vào. Carl nói thực ra là chưa, ít nhất là chưa. Anh vào ở phase cuối, human review, khi đã có một pull request hoàn chỉnh. Ở đó sự chú ý của anh lại cao, nhưng có một điều kiện kèm theo, vì nó còn tuỳ (video đăng ngày 01/11/2026).

Tóm lại, thay vì giữ sự chú ý ở mức cao suốt cả bốn phase, giờ sự chú ý của anh rất cao ở phase lập kế hoạch, nơi thật lòng anh dành phần lớn thời gian. Anh buông tay ở phase giao code và phase review, rồi tới lúc human review thì sự chú ý lại tăng lên (video đăng ngày 01/11/2026).

Carl nói trước: video này là anh chia sẻ chặng mình đang đi trên hành trình trở thành một "agentic engineer". Đây không phải video bảo bạn phải làm thế này ở mọi bước. Nó là tập hợp những gì anh đã đọc, đã học, đã trải qua các thử nghiệm của chính mình và từ việc làm với coding agent mỗi ngày. Đây không phải một cuốn sách hướng dẫn chạy coding agent, chỉ là anh chia sẻ. Nhưng anh có nhiều tài liệu tốt làm cơ sở cho một số quyết định của mình, nên anh vẫn nghĩ video đáng xem vì bạn có thể học được điều gì đó (video đăng ngày 01/11/2026).

## 4. Phase 1: grilling, và vì sao misalignment làm hỏng việc

Phase một là phase lập kế hoạch, mà đôi khi Carl gọi luôn là phase grilling. Nếu bạn chưa thấy skill này, anh gọi nó là một "game changer": skill grill-me của Matt Pocock. Bạn có thể nghĩ về nó như plan mode "uống doping" (plan mode on steroids). Đây là một skill rất nhỏ (theo Carl, video đăng ngày 01/11/2026).

Bạn có thể dùng nó hơi khác nhau tuỳ thứ mình đang làm, nhưng điều cần biết lúc này là nó sẽ phỏng vấn bạn theo từng round về một kế hoạch, một câu hỏi bạn có, hoặc bất cứ khi nào có thứ gì chứa "sương mù". Sương mù ở đây là bất cứ điều gì chưa biết hoặc chưa quyết (theo Carl, video đăng ngày 01/11/2026).

Vì sao chuyện này quan trọng tới vậy? Carl kể đây là điều anh học trực tiếp từ Matt: trong phát triển phần mềm, lỗi phổ biến nhất, hay nói đúng hơn là failure mode phổ biến nhất, là misalignment. Hãy hình dung developer truyền thống và product owner (PO): hai bên tưởng mình biết ý nhau, tưởng hiểu nhau, nhưng có một sự hiểu lầm, và rốt cuộc developer build ra một thứ không phải thứ PO nghĩ lúc đầu (theo Carl, video đăng ngày 01/11/2026).

Ta gặp đúng thách thức đó, nhưng giờ ta là PO, còn trong nhiều trường hợp agent là developer. Agent rất giỏi giao đúng thứ ta bảo nó giao, nhưng không giỏi lắm việc hiểu ý ta thật sự muốn nói. Vì thật lòng mà nói, chính ta cũng không phải lúc nào cũng hiểu ý mình. Carl gọi đó là một "tính năng" của loài người: đôi khi ta nói với nhau một đằng nhưng ý lại là một nẻo. Còn agent thì không phân biệt được (theo Carl, video đăng ngày 01/11/2026).

Theo Carl (video đăng ngày 01/11/2026): agent nhận và giao đúng "what we say", nhưng không phân biệt được nó với "what we mean".

## 5. Grilling theo từng round

Carl minh hoạ trước khi demo, và anh nói sơ đồ này "đẹp". Khi bắt đầu một phase grilling, ta có một mục tiêu (goal). Mục tiêu có thể là build một feature mới, có thể là thay đổi gì đó trong ứng dụng, có thể là một bug, hay "điền vào đây thứ gì cũng được". Ít nhất ta có một mục tiêu. Ta nói mục tiêu cho agent và gọi grill-me (video đăng ngày 01/11/2026).

Cách nó vận hành là ta nhận câu hỏi theo từng round. Theo Carl (video đăng ngày 01/11/2026), lý do bây giờ câu hỏi đi theo round là có những câu hỏi phụ thuộc vào câu hỏi khác: chẳng có ý nghĩa gì khi hỏi về schema trước khi đã giải quyết câu hỏi về storage. Hoặc nếu ta chưa nắm đủ rõ scope của thay đổi, hay scope của ứng dụng, thì chưa bàn tới edge case.

Vậy ở round một, bạn nhận cùng lúc mọi câu hỏi hợp lý ở chỗ mà, như Carl trích lời Matt, "frontier" đang đứng. Khi đã trả lời hết các câu của round một, ta sang round hai và nhận những câu hỏi giờ mới hợp lý. Có câu trả lời cho round một rồi, round hai trở nên rõ ràng hơn (video đăng ngày 01/11/2026).

![Sơ đồ grilling: Goal, round 1 Scope, Who uses it, Storage; round 2 Edge cases, Auth, Schema với ô câu hỏi ROUND 2](https://homus.dev/photos/NKRLirVTOt0-0902.jpg)

Round 1 đã xong (Scope, Who uses it, Storage), round 2 là frontier đang được hỏi (Edge cases, Auth, Schema). Ô ROUND 2 ghi ba câu kèm gợi ý: "Edge cases: empty?" (rec: reject it), "Auth: Entra login?" (rec: yes), "Schema: one table?" (rec: yes, add later). Round 3 (Roles, Migration) còn bị chặn, chờ câu cha; một Subagent tra cứu fact trong repo; khi frontier trống thì "You confirm a shared understanding".

Carl kể rằng ở các phiên bản đầu của grill-me, bạn nhận một câu hỏi và trả lời nó, tức trả lời từng câu một. Việc đó có thể mất rất lâu, và giờ về cơ bản nó được chia thành round. Bạn có thể nhận ba câu ở round một, năm câu ở round hai. Một điều anh nghĩ Matt đã nhận ra, và Matt nhận được nhiều phản hồi về nó, cũng là điều Carl tự cảm thấy: ở đoạn cuối một phiên grilling, anh chỉ còn nói "yes, yes, yes" hay "confirm, confirm", vì phần lớn sương mù đã tan rồi (video đăng ngày 01/11/2026).

Rồi bạn trả lời các câu ở round hai và sang round ba nếu hợp lý. Tuỳ câu trả lời của bạn mà, chẳng hạn, roles có thể trở thành chủ đề đáng bàn. Trên sơ đồ, ô đó có viền xám, nghĩa là nó bị chặn và đang chờ câu hỏi về auth được trả lời (video đăng ngày 01/11/2026).

## 6. Subagent tra cứu, rồi tới shared understanding

Có những thứ không nhất thiết phải do ta trả lời. Theo Carl (video đăng ngày 01/11/2026), đó có thể là thứ cần nghiên cứu hoặc tra cứu, và ở đây có thể dùng một subagent để tìm fact. Có thể câu trả lời đã nằm sẵn đâu đó trong codebase. Hoặc có thể phải lên internet đọc tài liệu. Agent làm được việc đó.

Sau tất cả các round, ta đi tới cái gọi là shared understanding (cách hiểu chung), và chỉ khi đó mới chuyển sang phase hai và ba. Carl nhắc lại: đây là chỗ duy nhất mà anh cảm thấy mình gần như không thể bỏ đủ thời gian vào. Theo anh, đây là thứ tạo khác biệt nhiều nhất cho việc anh có giao được phần mềm tốt hay không (video đăng ngày 01/11/2026).

Theo Carl (video đăng ngày 01/11/2026): câu nào cần tra cứu thì một subagent đi tìm trong codebase hoặc tài liệu; chỉ khi có shared understanding mới chuyển sang phase hai và ba.

Carl nói rõ anh không phải software developer theo nghĩa truyền thống. Các ứng dụng anh giao có thể là cập nhật một Terraform provider mà công ty anh tự build, hay build một ứng dụng CLI bằng .NET để gửi log từ Azure sang Datadog. Anh không build Netflix, không build thứ gì khủng như thế. Nên với anh, cho tới thời điểm quay video (đăng ngày 01/11/2026) và với những thứ anh build, cách này chạy rất tốt.

## 7. Phase 2: GitHub Spec Kit

Sang phase hai, giao code. Bạn đã nghe Carl nhắc shipit. shipit là gì? Theo Carl (video đăng ngày 01/11/2026), đó là một skill mà một người bạn tốt, cũng là đồng nghiệp của anh, phát triển tại nơi hai người làm việc; về cơ bản nó là một lớp vỏ mỏng (thin wrapper) bọc quanh Spec Kit.

Spec Kit là một project của GitHub, một toolkit giúp bạn bắt đầu với spec-driven development. Carl thấy project này khá hay, và anh đã dùng bản trần của nó, tức dùng mà không có shipit bọc bên ngoài. Theo anh (video đăng ngày 01/11/2026), về cơ bản nó gồm một loạt agent và skill chuyên biệt dẫn bạn đi qua vòng đời phát triển phần mềm.

Một ví dụ cách dùng: bạn tạo một constitution, nơi đặt vài nguyên tắc nền cho project. Đây là những điều lúc nào cũng phải đúng, có thể là các nguyên tắc tập trung vào code quality, testing và maintainability. Mỗi khi bạn build feature bằng Spec Kit trong ứng dụng đó, Spec Kit sẽ luôn tuân theo constitution của bạn (theo Carl, video đăng ngày 01/11/2026).

Trong tài liệu của Spec Kit, Carl đi qua các lệnh (video đăng ngày 01/11/2026): `specify` là bạn mô tả thứ cần build; `plan`, theo quan điểm của Spec Kit, là để chọn tech stack; `tasks` để chia nhỏ việc cần làm, nó tạo ra một file `tasks.md`; rồi tới những thứ như `implement`, nơi bạn thực sự build, và ở đây nó dùng `tasks.md` để làm các task trong đó.

![Trang quickstart của Spec Kit với Step 7 speckit-analyze, Step 8 speckit-implement, Step 9 speckit-converge](https://homus.dev/photos/NKRLirVTOt0-1243.jpg)

Trang quickstart của Spec Kit mà Carl mở trong video đăng ngày 01/11/2026: Step 7 `/speckit-analyze` (kiểm tính nhất quán giữa `spec.md`, `plan.md`, `tasks.md`), Step 8 `/speckit-implement` (chạy các task trong `tasks.md` theo thứ tự phụ thuộc), Step 9 `/speckit-converge` (đối chiếu codebase với spec, plan, tasks), rồi mục Key Principles.

Điểm rất tốt của Spec Kit, theo Carl (video đăng ngày 01/11/2026), là nó rất tự chủ (autonomous). Nó cứ thế build feature, tuân theo constitution, lập kế hoạch rồi implement feature. Và bạn có thể quyết định nó có nên mở PR và theo dõi CI hay không, cùng một loạt thứ hay khác.

Thứ anh thấy nó thiếu là phase alignment. Toàn bộ ý nghĩa của grill-me là bạn được align. Carl thấy dùng Spec Kit thì rủi ro gặp misalignment cao hơn. Các đồng nghiệp của anh cũng có cảm giác tương tự, vì thế mới có shipit (video đăng ngày 01/11/2026).

## 8. shipit: grilling ghép với Spec Kit, và bảy quyết định

Trên màn hình là file `SKILL.md` của shipit, phần description ghi: "End-to-end feature delivery pipeline – grill requirements, run specify→plan→tasks→implement with model split, review/fix, then optionally PR/CI and merge/release." Nó có bước grill requirements, tức dùng grill-me; còn Spec Kit lo phần build thật sự, về cơ bản là mọi thứ diễn ra sau grilling (demo trong video đăng ngày 01/11/2026).

Bạn có thể hỏi: sao không dùng luôn bộ skill của Matt cho việc này? Matt có grill-me, nhưng cũng có to-spec, to-tickets, `/implement`, và giờ có `/implement-spec`. Carl nói có thể lỗi là ở phía anh, nhưng cho tới lúc quay video (đăng ngày 01/11/2026) anh cảm thấy các skill của Matt rất tuyệt ở grilling để có shared understanding và alignment đúng nghĩa, nhưng lại đòi anh tham gia quá nhiều ở phase build. Còn Spec Kit thì xuất sắc ở mặt đó, nhưng hơi thiếu ở phase grilling hay phase lập kế hoạch.

Với shipit, việc phát triển trông như sau. Đầu tiên luôn là grill-me, và đây là lúc anh ngồi ở bàn phím trả lời câu hỏi. Phase thứ hai là phase lock. Sơ đồ ghi "7 decisions", và bạn có thể thắc mắc vì sao lại là bảy quyết định khi grill-me đôi khi hỏi anh tới cả trăm câu. Theo Carl (video đăng ngày 01/11/2026), mọi câu hỏi đó dẫn tới một shared understanding, và shared understanding ấy chính là một quyết định.

![Sơ đồ shipit: grill-me, Phase 1 lock với 7 decisions via AskUserQuestion, Phases 2 to 4, Report](https://homus.dev/photos/NKRLirVTOt0-1623.jpg)

Grill-me hỏi "as many as needed", Phase 1: lock có "7 decisions via AskUserQuestion" (7 to confirm), rồi Phases 2 to 4 (spec, build, review, PR, CI, merge, release) với "0 questions, AskUserQuestion is forbidden" và vòng "fix, up to 5 cycles", cuối cùng là Report. Hàng WHERE YOU ARE: ở bàn phím trả lời, rồi away, rồi quay lại review.

Ở phase lock của shipit còn có những thứ khác bạn phải quyết. Chẳng hạn model split: theo Carl (video đăng ngày 01/11/2026), bạn muốn model đắt tiền chạy phần lập kế hoạch, chạy grilling, và về cơ bản mọi thứ thuộc về kế hoạch. Rồi bạn muốn một model rẻ hơn, như Sonnet hay tương tự, làm implementer. Implementer không cần quá thông minh, nó chỉ làm theo spec đã có, rồi có thể nộp PR, và một model thông minh hơn nhiều sẽ review. Review có thể có findings, rồi model "kém thông minh" hơn sửa các findings đó.

Bạn cũng quyết khi nào shipit dừng. Nó merge thẳng vào main? Nó mở PR? Nó mở PR và bảo đảm CI xanh? Nếu CI không xanh, nó được lặp tối đa bao nhiêu lần để làm cho xanh (video đăng ngày 01/11/2026)?

Sau đó về cơ bản là chuyển sang phase 2 tới 4: nó build, nó review, nó sửa các findings nếu có. Nó mở PR, theo dõi CI (continuous integration) và sửa những gì cần sửa. Ở đây Carl không có mặt: không có câu hỏi nào cho anh và anh không làm gì cả. Khi đã có một PR mở và CI đang chạy, điều đó không có nghĩa CI sẽ tự động thành công; đôi khi nó fail. Cái này cũng cấu hình được, nhưng mặc định ở chỗ anh là năm cycle: năm vòng để thử sửa. Cuối cùng là xong, chuyển sang một report để anh xem kết quả, và lúc đó anh quay lại bàn phím để review những gì đã diễn ra (theo Carl, video đăng ngày 01/11/2026).

## 9. Vì sao agent cần một mức trần cho vòng lặp

Vì sao có mức trần (cap) đó? Carl nói nó thực ra đến từ các best practice của Anthropic về building effective agents. Bạn sẽ thấy điều này khi build những thứ như anh và nhóm đang build, hoặc khi build một ứng dụng dùng generative AI theo cách nào đó: người ta thường đặt một max iteration (video đăng ngày 01/11/2026).

Lý do, theo Carl (video đăng ngày 01/11/2026): một agent chỉ là một language model có một mục tiêu và đang chạy một vòng lặp. Đó là agent. Nếu không đặt mức trần cho số vòng lặp, agent có thể lặp vô hạn để cố đạt mục tiêu. Việc đó có thể tốn kém, có thể tệ vì nhiều lý do, và có thể nó sẽ gặp một thứ nó không tài nào giải được, rồi cứ thế lặp mãi. Vì vậy mới có ý tưởng max iterations. Trong trường hợp của anh, nếu chạm mức trần, nó dừng lại và gửi một report, rồi con người có thể can thiệp.

Mức trần vòng lặp theo Carl (video đăng ngày 01/11/2026): không có max iteration, agent có thể lặp vô hạn; có mức trần thì nó dừng và gửi report để con người can thiệp.

## 10. Demo: shipit trên một Terraform Plan Viewer

Để demo, Carl đã build một ứng dụng Terraform plan viewer. Nó chạy trên máy local của anh và cho anh một giao diện xem các plan, hay plan file, để hình dung điều gì sẽ diễn ra giữa các lần deploy Terraform. Vì sao anh có ứng dụng này? Anh nói anh không biết, chắc là vì nó làm ví dụ tốt cho video (demo trong video đăng ngày 01/11/2026).

Anh gọi shipit với một feature mới: sắp xếp các thay đổi theo mức rủi ro, và đánh dấu delete và replace là "one-way door" (cửa một chiều). Lúc đó, nếu anh đưa vào một plan file, nó chỉ hiện mọi thứ lộn xộn. Anh muốn nó sắp xếp, để những thứ mang tính phá huỷ nằm trên cùng, dễ nhận ra, và được đánh dấu là one-way door, nghĩa là nếu bạn huỷ cái này thì nó bị huỷ thật (demo trong video đăng ngày 01/11/2026). Lệnh trên màn hình:

```
/shipit "Sort the changes by risk and flag delete and replace as one-way doors"
```

![Terminal Claude Code v2.1.312, Opus 5.5, gõ lệnh /shipit trong repo demo-grill-then-ship](https://homus.dev/photos/NKRLirVTOt0-1843.jpg)

Lệnh `/shipit` gõ trong Claude Code (v2.1.312, Opus 5.5) ở repo `demo-grill-then-ship`, auto mode đang bật (demo trong video đăng ngày 01/11/2026).

Carl nhắc lại, đây là shipit: theo anh (video đăng ngày 01/11/2026), nó là "best of both worlds", vừa có phần hay của grill-me của Matt Pocock, vừa có phần hay của Spec Kit. Ngay khi chạy, nó báo có thứ cần cập nhật: skill shipit gọi tên grill-me, skill này chưa được cài, nhưng skill grilling thì có, và đó là bản khớp gần nhất. Carl giải thích Matt mới đổi tên các skill grilling của mình (demo trong video đăng ngày 01/11/2026).

Để tiết kiệm thời gian, anh trả lời "yes to all". Nhưng anh nhấn mạnh: đây là chỗ anh bỏ nhiều thời gian nhất. Đây là chỗ anh trả lời câu hỏi. Nếu nó nói điều gì anh không hiểu, anh dùng lúc này để hỏi cho ra lẽ: tôi không hiểu ý bạn, bạn giải thích dễ hơn, đơn giản hơn được không? Bạn build một prototype cho tôi xem được không? Theo Carl (video đăng ngày 01/11/2026), xin prototype cũng là việc rất quan trọng ở giai đoạn này: agent rất dễ đưa cho bạn một bản phác thứ cuối cùng có thể trông ra sao.

Quay lại bảy quyết định trên sơ đồ lúc nãy. Giờ đã xong hết câu hỏi, và tới phần model split. Anh dùng split mặc định: Opus 5.5 cho specify, plan và tasks, những việc cần model thông minh, còn Sonnet cho implementation, model rẻ hơn. Rồi anh chọn điều gì xảy ra sau implementation, tức vòng lặp: anh muốn mở pull request, theo dõi CI và tự sửa mọi lỗi, tối đa năm cycle (demo trong video đăng ngày 01/11/2026).

![Câu hỏi grilling Q5 đến Q7 đã trả lời, rồi hộp chọn Models với Default split (Recommended)](https://homus.dev/photos/NKRLirVTOt0-2023.jpg)

Trong demo của video đăng ngày 01/11/2026: các câu grilling Q5 (Summary count), Q6 (Plan-order toggle), Q7 (Create-before-destroy replaces) đã được trả lời; Carl gõ "yes to all", và shipit chuyển sang hộp chọn nhiều tab (Models, After impl, After CI, Bump, Submit). Tab Models gợi ý "Default split (Recommended): Opus 5.5 for specify, plan and tasks. Sonnet 5.5 for implement", hoặc "Opus for everything" với chi phí cao hơn.

Sau CI, nghĩa là khi PR đã mở và CI xanh thì làm gì? Ở đây anh có thể chọn merge và release luôn, tuỳ project mà việc đó có thể hợp lý. Trong trường hợp này anh chọn dừng khi xanh. Về release bump, anh nói nếu là release thì anh có thể chọn minor, nếu là patch thì... anh không biết nữa, cứ chọn minor cho lần này, rồi submit câu trả lời. Nó bắt tay vào việc: màn hình báo execution plan đã khoá (locked), và giờ nó implement feature (demo trong video đăng ngày 01/11/2026).

Carl muốn nói lại: lần này phần grilling rất nhanh vì anh nói yes với tất cả, nhưng đó chỉ là vì anh đang quay video. Anh nhấn mạnh hết mức rằng phần grilling và phần lập kế hoạch là quan trọng nhất. Anh dùng nó cho kiểu việc này, cho việc lên kế hoạch YouTube, cho những việc khác trong đời, anh dùng nó mọi lúc (theo Carl, video đăng ngày 01/11/2026).

## 11. shipit từng bước, qua sơ đồ

Việc này sẽ mất một lúc; anh nói nó đang nạp các skill Spec Kit và sắp viết spec. Trong lúc đó, Carl đi sâu vào shipit bằng một sơ đồ để bạn thấy chính xác điều gì xảy ra khi anh dùng nó, đúng thứ bạn vừa thấy anh làm (demo trong video đăng ngày 01/11/2026).

Anh gõ `/shipit` rồi nhập một feature. Nếu không nhập chữ nào, nó sẽ hỏi trong chat. Rồi nó grilling, phỏng vấn anh. Sau đó tới khoá bảy quyết định, cũng là thứ bạn vừa thấy anh làm. Đó là phase một: grilling và locking (theo Carl, video đăng ngày 01/11/2026).

Phase hai là lúc Spec Kit tiếp quản. Nó dùng Opus để specify và plan, cũng như chia thành task. Theo Carl (video đăng ngày 01/11/2026), anh muốn một agent, một model thông minh làm việc này để các task được định nghĩa rõ. Khi task đã rõ, anh để nó sang bước kế, chạy implement, và như đã nói, ở đây anh dùng một model rẻ hơn để làm xong các task liệt kê trong `tasks.md`.

Khi tất cả đã xong là tới phase review. Carl nói đến đây ta đang bước sang phase 3, không phải phase 3 trong sơ đồ này mà là phase 3 trong cách anh giao code; anh xin lỗi vì nó gây rối. Dù sao thì review do Opus làm. Theo anh (video đăng ngày 01/11/2026), đó là model thông minh hơn, nên anh muốn nó thật sự xem xét những gì đã build. Feedback và những gì nó tìm ra có thể gửi cho Sonnet, và hai bên có thể qua lại. Chẳng hạn anh đặt tối đa hai lần review, vì như bạn biết nếu đã dùng LLM, số thứ nó tìm ra dường như chẳng có điểm dừng nếu bạn yêu cầu.

Các phase của shipit theo sơ đồ Carl trình bày trong video đăng ngày 01/11/2026: grill và lock, spec và build với model split, vòng review tối đa hai lần, rồi tuỳ cổng đã chọn là đường PR và CI hoặc đường merge và release (mỗi đường tối đa năm lần sửa), và mọi đường đều kết thúc ở report.

Tiếp theo là cổng đầu tiên, tuỳ bạn đã trả lời gì về chuyện xảy ra sau implementation: mở PR, hay đưa một report. Ở trường hợp report, anh chỉ muốn xem điều gì đã diễn ra trước khi có gì được mở. Trong ví dụ của mình anh chọn đường PR, nên nó sẽ mở một pull request, theo dõi continuous integration, xem các pipeline. Nếu fail, nó cố sửa rồi chạy lại. Như đã nói, nó được làm vậy tối đa năm lần (video đăng ngày 01/11/2026).

Rồi tuỳ lựa chọn, anh có thể nhận một report ở đây, và đó là thứ anh chọn trong demo vừa rồi. Nhưng bạn cũng có thể chọn đường merge: merge thẳng vào main, theo dõi release pipeline xem có lỗi gì không. Lại có năm lần thử để sửa, rồi đi tiếp. Còn nếu anh chọn dừng ở đó, merge và release, thì nó cũng tới report (theo Carl, video đăng ngày 01/11/2026).

## 12. Model split: senior lên kế hoạch, junior viết code

Quay lại với agent: nó vẫn đang chạy, vẫn làm việc của nó. Carl đoán nó đang ở phase review; feature không lớn lắm nên chắc khá nhanh. Rồi "đây rồi": PR số 4 đã mở. CI pass ngay lần chạy đầu và không cần sửa gì (demo trong video đăng ngày 01/11/2026). Trên trang PR mà anh mở sau đó, tiêu đề là "Sort plan changes by risk and flag one-way doors #4", với 14 file thay đổi.

Model split anh vừa demo, theo Carl (video đăng ngày 01/11/2026), đến từ các khuyến nghị của Anthropic, và của cả những người khác làm việc với coding agent nói chung. Nó khá giống cách một senior developer và một junior developer làm việc với nhau. Bạn để senior developer lo phần kiến trúc và lập kế hoạch, tức dùng model đắt hơn ở phase này.

Nhưng phần implement thật sự, viết code và chỉ làm kiểu bước một, hai, ba, bốn, thì có thể giao cho một junior để junior học. Hoặc trong trường hợp này, giao cho một model rẻ. Rồi junior quay lại với senior: "này, xem tôi làm gì này, anh xem giúp được không?". Theo Carl (video đăng ngày 01/11/2026), về cơ bản đó cũng là việc anh và nhóm làm với model split: quay lại với senior developer, hay model đắt hơn, để review những gì đã diễn ra. Và bạn có thể để việc qua lại này kéo dài bao lâu tuỳ ý.

Phép so sánh của Carl (video đăng ngày 01/11/2026): model đắt đóng vai senior lo kiến trúc, kế hoạch và review; model rẻ đóng vai junior làm theo các bước rồi quay lại nhờ xem.

Carl chỉ ra một điểm có phần mâu thuẫn: anh và nhóm đang dùng Spec Kit theo kiểu buông tay, nhưng theo anh đây thực ra không phải cách Spec Kit được thiết kế để dùng. Anh nghĩ README của Spec Kit vẫn ghi rằng bạn nên chạy từng bước một: chạy specify, rồi plan, tasks và implement. Với skill shipit, anh và nhóm đang đi xa khỏi cách đó, không dùng nó theo cách những người làm Spec Kit dự định (video đăng ngày 01/11/2026).

## 13. pstack: "I'm stepping away"

Carl có nhắc pstack bên cạnh shipit. Đây là bộ skill (skill stack) do Lauren Tan tạo ra. Trong đó có poteto mode, theo Carl (video đăng ngày 01/11/2026) về cơ bản là một router, chuyển việc tới các principle và skill khác nhau. Video này không đi sâu vào pstack.

Anh chỉ muốn nói rằng đôi khi anh dùng pstack khi không dùng shipit hay Spec Kit. Lý do: nếu muốn áp dụng Spec Kit, nó khá "xâm lấn" project. Ý anh là ngay tuần quay video, anh có một Terraform provider nội bộ mà công ty anh phát triển, và anh phải cài Spec Kit vào đó trước khi chạy được shipit. Riêng PR để cài Spec Kit đã khoảng 7.000 dòng (theo lời Carl, video đăng ngày 01/11/2026).

Không phải lúc nào việc đó cũng làm được. Đôi khi anh làm việc trong repo của người khác, và anh không muốn xâm lấn tới mức đó. Theo Carl (video đăng ngày 01/11/2026), khi đó với pstack bạn có thể nói "I'm stepping away" (tôi đi đây). Đây là một chỉ dẫn giúp agent chuyển tới một số principle và skill nhất định, và bạn sẽ có trải nghiệm gần giống: nó không dừng lại chờ con người. Nó tự lập kế hoạch cho lượt chạy của mình, ghi log mọi quyết định nó đưa ra, và nhắm tới một PR làm sẵn. Tuy nhiên, nếu nó gặp thứ gì giống một one-way door, như deploy hay phải xoá dữ liệu, nó nên dừng lại, và đó là thứ bạn có thể xem qua.

![Sơ đồ pstack: You say ship it im stepping away; The agent plans its own run, logs every decision, pauses at no-undo steps; You find when back](https://homus.dev/photos/NKRLirVTOt0-2636.jpg)

Bạn nói "ship it im stepping away" (ô dưới ghi việc này bật sẵn ở mọi lượt chạy pstack). Agent tự lập kế hoạch (done test, rigor, phase list), ghi mỗi quyết định thành một dòng (what, why, evidence), và dừng ở các bước không đảo ngược được (deploy, force-push, delete data). Khi quay lại bạn thấy một PR làm sẵn kèm playbook nó đã chạy, file log `decisions.tsv` (không nằm trong git), hoặc một lượt chạy đã dừng chờ bạn đồng ý.

Carl nói có lẽ đáng nhắc, dù anh không chắc đó có phải mâu thuẫn không: pstack có một principle là không bao giờ dừng lại chờ con người. Nên nếu không có câu hỏi nào bắt buộc phải trả lời, agent sẽ tự ra quyết định, và bạn có cơ hội lật lại quyết định đó sau. Trong khi với grill-me của Matt, mọi quyết định thuộc về người dùng, thuộc về anh, về bạn. Theo Carl (video đăng ngày 01/11/2026), đó không phải mâu thuẫn lớn, chỉ là những cách làm việc khác nhau. Nhưng dù dùng pstack hay shipit, anh vẫn luôn bắt đầu bằng grill-me.

## 14. Phase 3: agent review code của agent

Quay lại tổng quan: anh đã rời phase hai (giao code), bước vào agent review, và phần nào cũng đã bước vào bước bốn, vì giờ anh có một PR làm sẵn để review. Trước khi đi tiếp, Carl tóm lại bước ba, khi một agent review code của agent khác. Với shipit, như đã nói nhiều, Sonnet implement, Opus review, rồi các findings được gửi lại cho Sonnet sửa, rồi quay lại review, rồi có PR (theo Carl, video đăng ngày 01/11/2026).

pstack đi theo hướng hơi khác. Nó có một thứ gọi là interrogate. Theo Carl (video đăng ngày 01/11/2026), với interrogate, bạn đưa vào diff, tức phần code đã đổi, cùng ý định bạn nêu ra (stated intent), thường là một đoạn văn. Rồi pstack khởi chạy ba subagent. Tuỳ bạn cấu hình, đó có thể là Opus, Sonnet và Haiku; cũng có thể là Fable thay cho Opus. Bạn chọn khi tạo cấu hình. Mỗi subagent có context window riêng, cô lập, và báo findings về cho agent chính (lead). Agent chính áp dụng phán đoán của nó.

![Hai khung: SHIPIT one reviewer in a loop và PSTACK INTERROGATE a panel với ba subagent A opus, B sonnet, C haiku](https://homus.dev/photos/NKRLirVTOt0-2943.jpg)

So sánh trong video đăng ngày 01/11/2026. Bên trái, shipit dùng một reviewer trong vòng lặp: Writer (Sonnet), Reviewer (Opus, context mới, hai subagent song song cho Standards và Spec), Fixer (Sonnet), re-review tối đa 2 lần, rồi CI trên PR với tối đa 5 cycle sửa ("The loop's last judge is not a model"). Bên phải, pstack interrogate là một panel: "Diff + stated intent, one paragraph" đi tới A opus, B sonnet, C haiku với cùng prompt, cùng rubric; Lead judgment (consensus first, dedupe) xếp mỗi finding vào act on, consider, noted, dismissed, và ghi "interrogate never auto-applies".

Một điều rất thú vị ở đây, nhất là với các hệ ngẫu nhiên (stochastic) như LLM, theo Carl (video đăng ngày 01/11/2026): nếu hơn một model tìm ra cùng một finding, thì khả năng cao đó là thứ bạn thật sự nên xem. Vì không chỉ "Opus to xác" hay "Fable to xác" tìm ra, mà cả Sonnet và Haiku cũng tìm ra. Rồi nó xếp các findings vào act on, consider, noted và dismissed, và bạn quyết định mình muốn implement cái nào.

Một điểm chung của cả hai cách: anh và nhóm không để agent viết code ban đầu review chính code của nó. Carl nói người ta đã thấy rằng một LLM nhìn chung sẽ chấm code của chính nó cao hơn. Lại khá giống con người: nếu anh mở một PR có code anh viết, trong đầu anh đó là đoạn code hay nhất từng tồn tại trên hành tinh này, bản cuối, "final". Rồi anh gửi cho một đồng nghiệp, và người đó nói: ơ, anh chưa làm cái này. Và anh kiểu "chết thật" (video đăng ngày 01/11/2026).

Theo Carl (video đăng ngày 01/11/2026), với agent cũng vậy. Subagent được khởi chạy với một context window mới, nhìn code của bạn lần đầu, thì không bị thiên kiến theo nghĩa đó, nói tạm như vậy.

Anh đặt câu hỏi: agent có review lẫn nhau được không, có nên không? Với anh câu trả lời là có, vì giờ đó là một phần của quy trình. Nếu bạn có các hệ stochastic, tức mỗi lần chạy cho kết quả khác nhau, thì chẳng phải khôn ngoan khi chạy lại qua vài lượt khác nhau để xem đâu là những findings trùng nhau rồi xử lý chúng sao (theo Carl, video đăng ngày 01/11/2026)?

Đó là điều đã xảy ra với pull request của anh. Anh mở nó, và bạn cũng thấy nó được shipit giao, nên đã có sẵn một lượt review bên trong. Nhưng anh chưa tự xem nó (demo trong video đăng ngày 01/11/2026). Trên trang PR, phần mô tả ghi "Classification: Internal" và mục "What changed" liệt kê các thay đổi trong `src/plan.ts`, `src/main.ts`, `index.html`, `CLAUDE.md`.

## 15. Phase 4: human review, cửa một chiều và cửa hai chiều

Vậy là tới phase cuối, human review. Carl thấy đây là chỗ cộng đồng chia rẽ nhiều nhất về cách xử lý, nói tạm như vậy. Theo anh (video đăng ngày 01/11/2026), cho tới lúc đó anh nghĩ phần lớn mọi người đồng ý rằng lập kế hoạch là tốt, để agent implement là tốt vì nó viết được nhiều code hơn bạn và anh rất nhiều. Chẳng hạn hôm trước ngày quay anh đã viết một PR 7.000 dòng, thứ mà tự làm có thể mất vài tuần, thậm chí vài tháng. Anh nói thêm: số dòng không đồng nghĩa với tốt hơn hay tệ hơn, nó chỉ là như vậy.

Và có vẻ đồng thuận chung là một agent có thể review agent khác, và nên làm vậy trước khi tự mình xem. Nhưng rốt cuộc phải có ai đó bấm merge, ship nó, và rollout lên production. Đây là chỗ Carl không có câu trả lời rõ ràng (video đăng ngày 01/11/2026).

Lập trường của anh tính tới lúc quay video (đăng ngày 01/11/2026): như anh đã nói vài lần, grilling gánh phần lớn việc nặng cho anh. Vì trong grilling anh có cơ hội gỡ hết sương mù, tức những unknown unknowns. Anh có cơ hội chạy prototype, để thật sự thấy một thứ gì đó, thấy mình đang đi về đâu. Anh có cơ hội đặt câu hỏi, để model dạy anh hệ quả của các quyết định nếu anh chọn A hay B.

Rồi có những pull request là thay đổi nhỏ. Có PR thậm chí không chạm vào code ứng dụng thật: có thể chỉ là cập nhật vài package, hay refactor ở những phần có blast radius nhỏ. Carl dùng khái niệm pull request "one-way door" và "two-way door". One-way door là khi merge xong thì khó quay lại: có thể ta sẽ xoá dữ liệu, cập nhật một bảng database hay tương tự. Two-way door thì dễ quay lại hơn nhiều (theo Carl, video đăng ngày 01/11/2026).

Hai loại pull request theo Carl (video đăng ngày 01/11/2026): one-way door như xoá dữ liệu hay sửa bảng database, khó quay lại; two-way door như cập nhật package hay refactor, dễ quay lại hơn nhiều.

Nên nếu anh có một pull request khá lớn nhưng là two-way door và blast radius rất nhỏ, tức ảnh hưởng một phần nhỏ của ứng dụng, thì anh không lo lắm. Tất nhiên còn tuỳ: nếu ta chạm tới authentication, quản lý mật khẩu người dùng, hay xử lý giao dịch, thì ở đó anh không có câu trả lời. Vì một lần nữa, anh nói mình không phải kiểu software developer đó, mà thật ra anh không phải software developer. Những thứ anh phát triển không hướng ra công chúng theo nghĩa đó: như đã nói ở đầu video, đó có thể là cập nhật Terraform provider của công ty, tạo ứng dụng CLI bằng .NET, hay build một Terraform wrapper, những thứ team anh dùng nội bộ. Điều đó tạo khác biệt lớn (theo Carl, video đăng ngày 01/11/2026).

## 16. Verification: test xanh chưa phải là bằng chứng

Một điều Carl muốn nhắc là thứ anh học từ Lauren, đến từ pstack: verification. Anh học được rằng một agent có thể viết code, viết test, và làm cho mọi test pass. Bạn có thể nghĩ: ồ, mọi test đều pass, chắc feature chạy, hay code chạy. Theo Carl (video đăng ngày 01/11/2026), anh đã học được rằng không phải vậy, vì agent có thể chỉnh test để nó pass. Có một kiểu thiên kiến ở đó.

Theo lời Carl (video đăng ngày 01/11/2026), skill verification sẽ tạo ra một verification skill ở mức sản phẩm, thứ điều khiển app của bạn theo cách một người dùng làm. Nghĩa là nó sẽ thật sự mô phỏng việc chạy ứng dụng. Trong browser, nó có thể chụp screenshot, chụp trước và sau để thật sự kiểm chứng và gom bằng chứng rằng thứ đó đang chạy đúng như ta muốn. Trên trang GitHub của pstack mà anh mở, skill này tên là `create-verification-skill`.

Anh còn đi xa hơn. Khi đã chạy các verification skill và có một verify skill của riêng mình, hợp với ứng dụng của mình, anh đưa nó cho skill wizard của Matt Pocock. Theo Carl (video đăng ngày 01/11/2026), wizard skill tạo ra một bash wizard tương tác, dẫn một người đi qua những bước mà chỉ người đó mới làm được. Nhưng anh dùng nó để agent dẫn anh đi một vòng sản phẩm (product walk).

Chuỗi Carl mô tả trong video đăng ngày 01/11/2026: test pass chưa đủ; verification skill chạy app như người dùng và gom bằng chứng; rồi wizard skill dẫn anh đi một vòng sản phẩm.

Ví dụ, anh đã mở pull request, và anh gõ yêu cầu pstack tạo verification skill để nó thật sự chạy ứng dụng của anh đúng cách. Rồi anh sẽ đưa skill đó cho wizard và nói: "này, dẫn tôi đi một vòng product walk qua những thứ đã thay đổi". Theo Carl (video đăng ngày 01/11/2026), điều rất hay là nó có thể tự mở browser cho bạn, copy thứ cần thiết vào clipboard để bạn chỉ việc dán, nói chính xác bạn cần bấm vào đâu và nên thấy gì.

Và đây là chỗ anh nhận ra rằng dù đã grilling và lập kế hoạch, đôi khi anh vẫn tìm thấy những thứ "không phải ý mình", hoặc anh nghĩ ra điều gì đó khi nhìn thấy nó bằng mắt. Anh nói đây là thứ khá mang tính cách mạng với anh (video đăng ngày 01/11/2026).

## 17. Một PR cần bao nhiêu review

Trong lúc skill đó đang được build, Carl nói về những điều khác anh cân nhắc khi có một pull request cần review. Anh đã lập kế hoạch và grilling, pull request đã mở, rồi anh tự hỏi: nó có thể làm hỏng gì? Theo Carl (video đăng ngày 01/11/2026), nếu là thay đổi nhỏ, như anh đã nói, anh merge luôn.

Còn nếu lớn hơn một chút nhưng hành vi vẫn như cũ, tức không thật sự chạm vào code ứng dụng, có thể thêm guard và test mới, có thể cập nhật vài package, thì cũng không có nhiều việc cho anh. Nhưng như anh đã demo trong video, lần này anh đang build hành vi mới vào ứng dụng: sắp xếp Terraform plan thành một danh sách đặt những thứ phá huỷ nhất lên trên cùng, và xác định đâu là one-way door, đâu là two-way door. Khi đó anh sẽ chạy các verify skill, rồi làm một product walk hay một bản demo (theo Carl, video đăng ngày 01/11/2026).

![Sơ đồ What can it break với bốn mức: Small change, Same behavior, New behavior, Critical like auth](https://homus.dev/photos/NKRLirVTOt0-3823.jpg)

Sau "Plan and grill" (phần lớn thời gian của anh) và "Agent PR arrives" (agent đã review, CI đã chạy) là câu "What can it break?" với bốn mức: 1 Small change (merge, không đọc diff), 2 Same behavior (bump, guards, tests; merge, không đọc diff), 3 New behavior (subagents phân loại, verify, có thể demo), 4 Critical, like auth (`/teach` và hỏi ý kiến đồng nghiệp). Mũi tên dưới cùng: thời gian của anh trên PR đi từ "none" tới "most".

Còn có một bước thứ tư anh đang nghĩ tới tính tới lúc quay video (đăng ngày 01/11/2026): nếu nó quan trọng sống còn, chẳng hạn chạm vào authentication, anh có thể dùng `/teach`, cũng là một skill của Matt. Carl nói Matt đã làm thay đổi hẳn cách anh làm việc. Skill này dẫn anh đi qua và dạy anh mọi thứ anh cần, anh có cơ hội nhận feedback riêng cho mình, đặt câu hỏi và hiểu rõ hơn. Anh có thể làm cả việc đó lẫn tìm ý kiến đồng nghiệp, hay nói đúng hơn là tự nghiên cứu và nói chuyện với những đồng nghiệp giỏi hơn anh nhiều, rồi mới làm.

Theo Carl (video đăng ngày 01/11/2026), tất cả những điều này quyết định anh bỏ bao nhiêu thời gian cho một pull request: ở đầu bên trái thì không nhiều, còn ở đầu bên phải, bước bốn, thì rất nhiều.

## 18. Demo: product tour với wizard skill

Verify skill đã chạy xong. Nó đã chạy ứng dụng của anh và gom một ít bằng chứng để anh xem. Anh mở ra: nó đã chụp một screenshot ứng dụng, và thấy rằng danh sách đã được sắp xếp, những thứ critical nằm trên cùng, đúng như anh yêu cầu. Carl nói thật lòng điều này "đỉnh tới mức không tin nổi" (demo trong video đăng ngày 01/11/2026).

Nếu vẫn chưa đủ và anh muốn đi thêm một bước, anh gõ yêu cầu wizard xem verify skill rồi dẫn anh đi một product tour. Khi một chặng cần plan file mẫu thì viết file đó ra và copy đường dẫn của nó vào clipboard bằng `pbcopy`. Anh nói anh thêm ý đó chỉ để cho thấy nó thật sự đưa được thứ vào clipboard của bạn (demo trong video đăng ngày 01/11/2026).

Có script rồi, anh copy nó, mở một terminal mới, chạy bằng bash. Giờ là một product tour cho Terraform plan viewer. Anh sẵn sàng bắt đầu chưa? Anh chọn bắt đầu. Nó tự mở localhost cho anh, "thật là ngầu". Anh đặt hai cửa sổ cạnh nhau. Trang mở với ví dụ "Next release (mixed changes)", và anh thấy đúng như vậy. Nó đã nạp một plan, màn hình ghi sáu thay đổi, và dòng delete nằm trên cùng (demo trong video đăng ngày 01/11/2026).

![Bên trái terminal chạy product tour, bên phải trang Terraform plan viewer với next-release.json: 6 resource changes, 3 one-way doors](https://homus.dev/photos/NKRLirVTOt0-3942.jpg)

Product tour trong demo của video đăng ngày 01/11/2026: bên trái, terminal của wizard ghi heading phải là "next-release.json: 6 resource changes, 3 one-way doors" và hỏi "See it? Press Enter". Bên phải, Terraform plan viewer xếp DELETE `local_file.legacy_config[0]` trên cùng, hai REPLACE gắn nhãn "one-way door", rồi UPDATE, CREATE, NO-OP.

Wizard bảo đọc các dòng từ trên xuống: chúng đi từ rủi ro nhất tới ít rủi ro nhất. Carl đồng ý. Rồi nó bảo chọn ví dụ "first apply" trong danh sách plan mẫu: đây là lần apply đầu tiên với state trống, nên nó muốn tạo mọi thứ. Carl thấy điều đó rất tuyệt cho một Terraform plan viewer, đó là thứ anh muốn thấy (demo trong video đăng ngày 01/11/2026).

Wizard nói bản mẫu này có đủ sáu action và cả hai kiểu replace. Rồi nó ghi file vào clipboard của anh. Anh bấm Choose File, dùng Command Shift G để đi tới file đó, bấm chọn. Anh nói: bạn thấy tương tác với nó dễ thế nào; anh gọi wizard skill là "insane". Anh có thể làm mọi thứ, và nhận một plan file khác để xem. Việc này cũng minh hoạ rằng bạn có thể nạp plan file của riêng mình (demo trong video đăng ngày 01/11/2026).

Lần kế là một lệnh delete duy nhất, và nó chạy đúng. Rồi một plan không có thay đổi nào: không hiện gì. Tiếp theo, Carl thấy "cái này hay": một plan file, hay file JSON, bị lỗi định dạng, và ứng dụng xử lý được, báo lỗi cho người dùng. Cuối cùng là một action lạ: màn hình báo JSON không đọc được, có action "explode" mà viewer không biết, và Terraform cũng không. Thế là hết tour (demo trong video đăng ngày 01/11/2026).

Carl kết lại: đó là những gì anh đang làm với agentic coding tính tới lúc quay video (đăng ngày 01/11/2026). Tất nhiên có thể khác đi một chút tuỳ việc anh đang làm, nhưng đó là phần cốt lõi. Anh không nhận mình có câu trả lời, không nhận mình đúng hay sai, và thật lòng anh không nghĩ có ai đúng hay sai; anh đoán nó tuỳ vào thách thức bạn gặp. Anh cảm ơn mọi người đã xem.

## Nguồn và liên kết

- Tên gốc: I Stopped Micromanaging My AI Coding Agents
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=NKRLirVTOt0](https://www.youtube.com/watch?v=NKRLirVTOt0)

- Kênh YouTube Carl Lindberg (Carl Lindberg): [youtube.com/channel/UC_jgbqQdOtmP3UEvu5t0-5A](https://www.youtube.com/channel/UC_jgbqQdOtmP3UEvu5t0-5A)

- Repo shipit, skill Claude Code dùng trong demo; README mô tả bốn phase, vòng review tối đa 2 cycle, CI và release tối đa 5 cycle (đọc ngày 01/11/2026): [github.com/carlzxc71/shipit](https://github.com/carlzxc71/shipit)

- Bộ skill của Matt Pocock, gồm grill-me, grilling, wizard và teach (đọc ngày 01/11/2026): [github.com/mattpocock/skills](https://github.com/mattpocock/skills)

- GitHub Spec Kit (đọc ngày 01/11/2026): [github.com/github/spec-kit](https://github.com/github/spec-kit), trang quickstart với các bước `/speckit-*`: [github.github.io/spec-kit/quickstart.html](https://github.github.io/spec-kit/quickstart.html)

- pstack của Lauren Tan, gồm poteto-mode, interrogate và create-verification-skill (đọc ngày 01/11/2026): [github.com/cursor/plugins/tree/main/pstack](https://github.com/cursor/plugins/tree/main/pstack)

- Anthropic, "Building effective agents": bài viết nhắc tới điều kiện dừng như số vòng lặp tối đa để giữ quyền kiểm soát (đọc ngày 01/11/2026): [anthropic.com/engineering/building-effective-agents](https://www.anthropic.com/engineering/building-effective-agents)

Nguồn: https://homus.dev/talks/i-stopped-micromanaging-my-ai-coding-agents · cập nhật 2026-11-01