# AI coding setup mới giúp ship hơn 30 PR mỗi ngày

[Thomas Kim](https://homus.dev/speakers/thomas-kim) · [Your Average Tech Bro](https://homus.dev/orgs/your-average-tech-bro)

> Thomas Kim chia việc giữa Codex và Cursor cloud agent, dùng pstack và verification skill, và giao từng feature cho một Grok Bot làm chủ.

Topics: Coding Agents, Workflow, Skills, Grok Bot

Canonical: https://homus.dev/talks/my-new-ai-coding-setup-that-helps-me-ship-30-prs-a-day

## 1. AI coding stack đổi liên tục, và lần này đổi gần như toàn bộ

Thomas Kim mở video bằng mục tiêu: kể lại AI coding stack hiện tại của anh. Stack này thay đổi liên tục, vì AI đi nhanh đến khó tin. Anh tự nhận mình là một serial builder và là người "chronically online", lúc nào cũng ở trên mạng, nên anh rất thích thử các AI coding setup mới tinh. Theo lời anh, 90% số lần thử như vậy phá nát hoàn toàn năng suất của anh. Nhưng 10% còn lại thì các tool hay workflow mới thật sự tốt, và năng suất của anh tăng lên đáng kể. Video này là về những thứ thuộc 10% đó.

![Thomas Kim nói trước camera, bên trái là dòng chữ AI Coding Stack](https://homus.dev/photos/54D1hFfaju8-0003.jpg)

Thomas Kim ở đầu video, với dòng chữ "AI Coding Stack" chạy trên màn hình: chủ đề của cả video là bộ công cụ code bằng AI anh đang dùng hằng ngày.

Lần gần nhất anh làm một video kiểu này là bốn tháng trước. Khi đó anh nói mình đang dùng NeoVim và Claude Code. Bây giờ anh không còn dùng NeoVim, cũng không dùng Claude Code nữa; anh đã ngừng làm subscriber của Claude Code được ba tháng. Nghĩa là đã có rất nhiều thay đổi.

Anh hứa ba phần. Thứ nhất là các tool cụ thể anh dùng. Thứ hai là workflow mới và cách anh dùng các tool đó, vì nó khác khá nhiều so với video bốn tháng trước. Cuối cùng, anh kể thêm một vài AI agent và automation anh dùng để vận hành startup nói chung, không thuần chuyện code.

## 2. Bối cảnh: Yorby, một startup hai người với doanh thu thật

Cho người mới xem kênh, Thomas giới thiệu: anh là một serial app builder, đã build hơn 14 app khác nhau trong năm năm qua. App anh đang build hiện tại tên là Yorby. Đó là một AI social media marketing tool cho startup: giúp các startup làm content marketing có khả năng viral và vận hành toàn bộ phần social media marketing, để họ quảng bá sản phẩm, quảng bá doanh nghiệp của mình trên mạng xã hội.

Vài tháng trước, Yorby đạt đỉnh khoảng hơn 11 nghìn USD doanh thu một tháng (anh nói "a high 11k a month"). Giờ con số đang ổn định quanh mức từ khoảng 9 nghìn rưỡi tới 10 nghìn rưỡi USD monthly recurring revenue. Anh nói thẳng: anh không phải "larper", không phải người đóng vai. Anh là một builder thật, có sản phẩm thật, có khách hàng thật. Vì vậy chuyện ship feature, đặc biệt là feature chất lượng cao và không gây bug, là cực kỳ quan trọng với anh.

![Dashboard Stripe của Yorby AI với biểu đồ MRR và Net volume trong sáu tháng](https://homus.dev/photos/54D1hFfaju8-0115.jpg)

Dashboard thanh toán của Yorby AI trong sáu tháng gần nhất: MRR đang ở 9.337,71 USD, con trỏ chỉ vào đỉnh ngày 22/7 là 11.273,96 USD; bên phải là Net volume 49.073,60 USD.

Anh build startup này với một team rất lean, chỉ có anh và người co-founder. Anh là người build chính, co-founder là người làm marketing chính, nhưng anh ấy cũng build và Thomas cũng làm marketing. Họ giữ mọi thứ gọn nhẹ và rất "AI native": dùng AI trong mọi việc, từ build, marketing đến bán hàng. Đó là phần bối cảnh để hiểu những gì anh kể tiếp theo.

## 3. Codex và Cursor, mỗi bên 200 USD một tháng

Vào phần tool. Thomas nói anh "daily drive", tức dùng hằng ngày, hai thứ: Codex và Cursor. Anh biết Cursor sẽ khiến người xem bất ngờ: anh từng là fan cuồng của Cursor, rồi bỏ (churn) khá lâu, và giờ mới quay lại. Lý do quay lại là anh thấy Cursor đang làm việc rất tốt, nhất là sau khi được SpaceX AI mua lại ("SpaceX, AI, Grok, gọi sao cũng được", anh đùa). Anh cực kỳ lạc quan về tương lai của Cursor.

Trước khi nói khi nào dùng Codex, khi nào dùng Cursor (vì anh dùng cả hai), anh nói rõ một điều: setup agentic coding này không rẻ, thậm chí khá đắt. Anh trả 200 USD một tháng cho gói Codex và 200 USD một tháng cho gói Cursor, bằng tiền túi của mình. Và với việc Fable 5.1 vừa ra mắt, anh còn đang bị cám dỗ đăng ký lại Claude Code. Nên đây không phải setup cho người cần tiết kiệm; đây là setup cho hiệu quả tối đa, chấp nhận trả giá rất cao để xong việc.

Thomas chia việc theo loại: việc local và frontend chi tiết đi Codex, việc chạy trên cloud agent đi Cursor. Tổng chi phí hai gói là 400 USD mỗi tháng.

Cách anh chia việc giữa Cursor và Codex phụ thuộc vào loại việc đang làm. Anh thích dùng Codex mỗi khi làm việc trên laptop, trong local dev environment, với một local agent. Anh nhấn mạnh chữ "local" vì anh vừa ra một video riêng về cloud coding agent và việc cloud coding agent đã thay đổi workflow của anh thế nào; phần đó anh sẽ nói sâu hơn ở đoạn sau. Cursor thì anh dùng chủ yếu cho cloud coding agent.

## 4. Codex cho local dev và việc frontend tỉ mỉ

Thomas thích trải nghiệm local developer của Codex hơn hẳn, và lý do khá đơn giản: anh thấy app desktop Codex là app desktop "thuần" tốt nhất. Nó chạy mượt nhất. Anh chưa từng gặp vấn đề hiệu năng khi chạy nhiều worktree cùng lúc. Ngược lại, khi chạy nhiều worktree trên máy với Cursor, tức nhiều coding agent trên các local worktree, anh thấy Cursor bị lag và chậm đi đáng kể so với app ChatGPT / Codex. Điểm thứ nhất vì vậy là: app ChatGPT và Codex hiệu quả nhất, nhất là khi làm với nhiều local worktree.

Ngoài ra, Codex còn có rất nhiều tiện ích nhỏ (quality of life). Nói ra thì nghe vụn vặt, nhưng cộng dồn lại theo thời gian thì đáng kể. Anh demo một ví dụ: trong app, anh mở một local browser, ở đây trỏ tới Google, nhưng cứ giả sử đó là local dev environment của anh. Anh muốn xem app trông ra sao ở các viewport khác nhau. Dĩ nhiên anh có thể test giao diện mobile bằng cách kéo nhỏ panel lại, hoặc kéo rộng ra để xem full screen cho desktop. Nhưng khi chuyển sang full screen để xem bản desktop, cửa sổ chat cùng lịch sử hội thoại biến mất, bị thu thành một viên nhỏ (pill) ở dưới đáy màn hình, và điều đó làm anh rất khó chịu.

![App Codex với cửa sổ chat bên trái và browser bên phải ở chế độ device toolbar, kích thước iPhone 15 Pro Max](https://homus.dev/photos/54D1hFfaju8-0423.jpg)

Trong app Codex, browser tích hợp bật device toolbar: thanh "Dimensions" chọn iPhone 15 Pro Max, 430 × 932, trong khi lịch sử chat vẫn mở bên trái. Ô chọn model ở dưới ghi "5.6 Sol Medium".

May là Codex có một nút bật device toolbar. Với nó, anh đổi độ phân giải ngay từ thanh công cụ, trong khi toàn bộ lịch sử chat vẫn mở ở bên cạnh mọi lúc. Anh thừa nhận đây là một ví dụ rất nhỏ, nhưng có rất nhiều chi tiết nhỏ kiểu này cộng lại thành một trải nghiệm local developer tốt hơn nhiều.

Anh tóm lại điểm số một: app desktop thuần tốt hơn, và anh ưu tiên dùng nó mỗi khi làm local development cần nhiều chỉnh sửa tinh (fine-tuned), mà thường là các task nặng về frontend. Anh thấy annotation tool của ChatGPT, công cụ để khoanh và ghi chú lên giao diện, tốt hơn, chạy mượt hơn và nhanh hơn nhiều. Với frontend, anh muốn thấy thay đổi mình làm qua những vòng lặp nhanh hơn. Vì vậy việc frontend thuần, như dịch từng pixel nhỏ hay tối ưu chi tiết, anh làm trên local developer environment, và luôn luôn bằng ChatGPT / Codex.

## 5. Cursor và cloud agent có máy ảo riêng

Chuyển sang Cursor. Như anh nói trong một video trước, Thomas cho rằng Cursor đang có một thời "phục hưng" (renaissance), và anh dùng Cursor nhiều hơn hẳn nhờ hỗ trợ cloud agent. Muốn có hướng dẫn chi tiết hơn thì xem video đó. Nói ngắn gọn, đây là các coding agent chạy trên cloud, mỗi agent có một desktop environment riêng, đầy đủ.

![Danh sách cloud agent trong Cursor, một PR đã merge và diff của file SKILL.md](https://homus.dev/photos/54D1hFfaju8-0303.jpg)

Cursor với danh sách cloud agent của project Yorby bên trái (các task fix, PostHog, TikTok, Instagram...). Agent đang mở đã chạy /babysit-pr rồi review, báo "CI on that commit is green. PR #2152 is already merged"; bên phải là diff của một file SKILL.md trong thư mục .agents/skills.

Anh mở một cloud agent rồi mở phần desktop của nó: đó là một máy ảo desktop hoàn chỉnh. Anh có thể vào đó, test app thật, mở browser, làm bất cứ thứ gì trong một môi trường desktop thật sự. Tài liệu của Cursor mô tả đúng điều này: cloud agent dùng chung nền tảng với agent thường nhưng chạy trong máy ảo cô lập trên cloud, với môi trường phát triển đầy đủ, nên chúng build, test và tương tác được với phần mềm vừa sửa.

![Desktop của một cloud agent Cursor đang mở Chrome với trang Google](https://homus.dev/photos/54D1hFfaju8-0525.jpg)

Desktop của một cloud agent: một máy ảo chạy Chrome, có thanh dock và nút "Stop Control" ở góc trên để người dùng thôi điều khiển máy ảo.

Cách anh dùng các cloud agent này đã thay đổi nhờ một skill mới, hay đúng hơn một stack mới anh đang dùng, tên là pstack. Phần này anh nói kỹ sau đoạn quảng cáo.

## 6. Đoạn quảng cáo

Video có một đoạn quảng cáo cho Fish Audio, dịch vụ text-to-speech mà Thomas kể đội anh đã chọn khi làm tính năng thêm giọng đọc vào video trên Yorby, một tính năng người dùng yêu cầu nhiều.

## 7. pstack: bộ skill của một kỹ sư ở SpaceX AI

Thomas nói: nếu bạn giống anh và dành thời gian trên Tech X (Tech Twitter), có lẽ bạn đã gặp người này. Tên cô là Lauren, một kỹ sư trong team SpaceX AI, làm cụ thể về Grok Bot. Cô tạo ra một engineering stack tên là pstack, và nó đang "chiếm lĩnh" internet lúc này.

Theo Thomas, nó không quá khác so với lúc Garry Tan, người đứng đầu Y Combinator, làm ra gstack. Nhưng anh có cảm giác gstack bị khá nhiều kỹ sư khác chế giễu; bản thân anh chưa từng dùng gstack. Còn pstack thì anh muốn thử, và nó được tối ưu rất kỹ cho Cursor. Anh thấy nó rất, rất tốt. Đây là bộ skill mặc định anh dùng để chạy và phát triển mọi ứng dụng của mình dạo này, cụ thể hơn nữa là bên trong Cursor cloud agent.

![Thư mục pstack trong repo cursor/plugins trên GitHub với danh sách skill](https://homus.dev/photos/54D1hFfaju8-1023.jpg)

Thư mục pstack trong repo cursor/plugins trên GitHub. Cây thư mục bên trái liệt kê các skill như architect, arena, blast-radius, create-verification-skill, maintain-verification-skill, interrogate và một loạt skill "principle-..."; README mở đầu bằng lời giới thiệu của tác giả, từng làm với hàng triệu dòng code ở Meta, Netflix và Cursor.

Anh muốn làm hẳn một video riêng về pstack vì còn nhiều sắc thái quanh nó. Nhưng nhìn ở mức cao, pstack về cơ bản là một nhóm skill được gói lại với nhau, giúp bạn viết code hiệu quả hơn và tự động hơn. README của repo cũng nói cách cài là lệnh `/add-plugin pstack` trong Cursor, rồi chạy skill setup để chọn reasoning budget và các model muốn dùng.

## 8. Nguyên tắc một: nhiều model cùng lập kế hoạch, một judge chốt

Với Thomas, có hai thành phần lớn nhất của pstack đã thay đổi tận gốc cách anh để agent viết code cho mình.

Thành phần thứ nhất: pstack tận dụng việc Cursor có sẵn nhiều model. Nó cho nhiều model cùng đi lập kế hoạch để build một feature cụ thể. Sau đó có một "judge", một orchestrator, đọc tất cả các phương án đến từ các model khác nhau, rồi tạo ra một kế hoạch cuối cùng từ đầu vào của tất cả các model đó.

Nguyên tắc thứ nhất của pstack theo cách Thomas mô tả: nhiều model lập kế hoạch song song, một model thông minh hơn làm judge gộp lại thành một kế hoạch, rồi các model tiết kiệm chi phí hơn thực thi.

Anh rất thích cách tiếp cận này vì gần đây có nhiều nghiên cứu từ các AI lab khác cho thấy: cho một loạt model rẻ hơn thử nhiều hướng khác nhau, rồi gộp phần tốt nhất của từng kế hoạch riêng lẻ qua một model judge / orchestrator thông minh hơn, sẽ cho hiệu năng ngang frontier với chi phí chỉ bằng một phần nhỏ. Đó là phần một.

Tiếp theo, từ các phương án khác nhau, judge xác định đâu là cách implement tốt nhất, rồi đi implement nó bằng các model tiết kiệm chi phí hơn. Vì theo anh, bạn không thật sự cần một Fable 5.1, một GPT 5.6 Sol Max, một model siêu cao cấp và siêu đắt để làm phần gõ code thô. Các model rẻ hơn làm phần implement code thô tốt hơn nhiều. Đó là nguyên tắc số một của pstack mà anh nghĩ dẫn tới chất lượng engineering rất cao.

## 9. Nguyên tắc hai: agent tự chứng minh thay đổi chạy được

Thành phần thứ hai: pstack nhấn mạnh rằng các AI agent chạy trên Cursor cloud agent, vốn điều khiển được máy ảo desktop của chính cloud agent đó, phải đi kiểm chứng (validate) thật sự các thay đổi chúng đã làm. Với bất kỳ task nào bạn giao, agent không chỉ sửa rồi nói "xong rồi, chúc may mắn". Không. Nó thật sự đi tái hiện, test và chứng minh rằng feature đó chạy được trên máy ảo thật.

Với Thomas, đây là một bước nhảy thật sự (step function) về năng suất, vì giờ anh không còn phải tự mở browser, bấm khắp nơi để chắc mọi thứ chạy đúng nữa.

![Cloud agent của Cursor báo Prove It Works sau khi chạy lệnh kiểm chứng, bên phải là desktop máy ảo](https://homus.dev/photos/54D1hFfaju8-0758.jpg)

Một cloud agent sửa lỗi bắt đầu bằng playbook bug-fix ("Laziness / Subtract Before Add. Smallest robust diff only"), chạy lệnh kiểm chứng nằm trong `.cursor/skills/verify-yorby-web/bin/`, rồi báo "Prove It Works. That helper ran after the fix. Doctor passed. Vitest passed." kèm PR #2155, chưa merge.

Thay vào đó, framework pstack được dựng sao cho các model, trong lúc liên tục dùng và test app của bạn, tạo ra các verification skill: những skill tái sử dụng được, hướng dẫn AI model, các agent, cách dùng và tương tác với app của bạn, cách test từng feature trong ứng dụng. Chúng làm việc này bằng các skill như create verification skill và maintain verification skill (hai thư mục `create-verification-skill` và `maintain-verification-skill` trong pstack). Mỗi lần bạn bảo nó build một feature, nó đi test và xác nhận rằng feature đúng. Thêm vào đó, nó ghi lại chính xác những gì nó đã làm để tái hiện workflow đó, lần này qua lần khác, để các agent sau này tham khảo.

## 10. Verification skill: khoản đầu tư quan trọng nhất

Thomas mở repo Yorby để minh hoạ. Trong thư mục skill của anh có verify-yorby-web, và nhìn quanh sẽ thấy cả một loạt: verify-remotion-lambda, verify-resend, verify-tiktok-connect, verify-yorby-web. Anh có đủ các bộ hướng dẫn về cách kiểm chứng và test từng phần khác nhau của ứng dụng.

![Repo Yorby trên GitHub, thư mục .agents/skills/verify-yorby-web với artifacts, bin, features và SKILL.md](https://homus.dev/photos/54D1hFfaju8-1043.jpg)

Thư mục `.agents/skills/verify-yorby-web` trong repo Yorby: gồm artifacts, bin, features và SKILL.md. Cây bên trái cho thấy các verification skill khác như verify-remotion-lambda, verify-resend, verify-tiktok-connect, cạnh các skill khác như thermo-nuclear-code-quality-review, vibe-code và yorby-logging.

Điều này đã mở mắt anh về việc agent có thể mạnh hơn bao nhiêu. Anh thậm chí dám đưa ra giả thuyết rằng đầu tư vào verification skill có lẽ là việc quan trọng nhất một team engineering AI native có thể làm. Trước đây, mỗi khi AI viết code, nó chỉ giả định code sẽ chạy, trong phạm vi khả năng tốt nhất của nó. Còn quá trình test thô vẫn rơi vào tay con người: vào app, bấm hết các nút, chắc chắn mọi thứ chạy đúng.

Khi đầu tư nhiều vào verification skill tốt trong toàn bộ ứng dụng, các agent thật sự tự chủ hơn nhiều, và bạn tin được output, tin được agent khi nó nói "xong" nhiều hơn hẳn. Lý do: riêng trong Cursor cloud agent, chúng còn ghi lại được một bản playback những gì đã làm. Anh lục tìm một ví dụ để cho xem: các model vào test ứng dụng, xác nhận rằng chúng đã thật sự build feature, sửa feature hay sửa bug bạn yêu cầu, bằng cách chụp screenshot thật của ứng dụng và gửi cho bạn như bằng chứng rằng nó chạy. "Pretty incredible stuff", anh nói.

Nhờ vậy bạn không còn phải tự kiểm thủ công nữa, vì agent đã chứng minh nó chạy. Việc còn lại của bạn chỉ là review code, mà cũng chỉ khi bạn muốn, để chắc nó hợp chuẩn của bạn và các quyết định architecture bạn muốn tuân theo.

Đây là thứ chiếm một phần rất lớn thời gian engineering của anh dạo này. Anh cảnh báo: lúc đầu dùng các cloud agent này, dùng pstack hay bất kỳ stack nào bạn chọn, mọi thứ sẽ rất chậm. Anh thì thích pstack và thấy nó khá tốt, nhưng bạn dùng bộ feature, bộ tool, stack nào cũng được. Điều anh thấy là chìa khoá mở khoá lớn nhất là đầu tư mạnh vào verification skill, vì đó là thứ đưa AI lên tầng tiếp theo: không chỉ viết code, mà thật sự test app và các thay đổi nó vừa làm.

## 11. Grok Bot làm đồng nghiệp: mỗi feature một bot làm chủ

Còn cách anh gọi và dùng pstack cùng các verification skill thì vẫn thay đổi nhiều, nhưng anh khá thích cái anh đang có. Anh tự nhận mình đang "GrokBot pilled", nghiện Grok Bot. Anh từng làm một video về Grok Bot, có nhắc tới Grok Bot, và họ từng tài trợ một video của anh, nhưng cá nhân anh dùng nó nhiều khủng khiếp. Anh yêu Grok Bot, kiểu bị ám ảnh luôn.

Cách anh làm như sau. Vì Grok Bot được build bởi team SpaceX AI, cũng là bên đã build và sở hữu Cursor, nên Grok Bot về cơ bản kích hoạt được cloud agent cho bạn ngay trong Cursor để làm toàn bộ phần việc engineering. Anh điều phối mọi thứ bằng nhiều Grok Bot, không chỉ coi chúng là coding tool mà thật sự coi chúng là đồng nghiệp, là teammate.

![App Grok Bot với danh sách bot theo feature của Yorby và một tin nhắn về knowledge maintenance](https://homus.dev/photos/54D1hFfaju8-1543.jpg)

Danh sách bot của Thomas: UGC Studio, Yorby Error Fix, Account Spy, Autumn Code Reviews, Content Calendar, Analytics, Content Coach, Autumn Customer Support. Tin nhắn trong khung chat Analytics mô tả hai routine giữ knowledge luôn mới: làm mới khi có PR được merge trên repo, và một lượt rà soát vào sáng thứ Bảy.

Cụ thể, anh tạo các bot riêng cho từng feature của app. Ví dụ, có UGC Studio bot, bot phụ trách AI content studio của Yorby, nơi cho phép startup tạo video marketing viral hiệu quả cao với nhiều định dạng video khác nhau. Bot này là chủ (owner) của feature đó. Nó đã khám phá code base, "nghịch" code base, tự dùng thử tool, và có được cả một knowledge base về tool này và cách nó vận hành.

Anh làm tương tự với các feature khác. Yorby có feature account spy, cho phép bạn theo dõi tài khoản mạng xã hội của đối thủ và nhận thông báo khi content của họ đang viral, để bạn làm theo content đó và cũng viral, quảng bá sản phẩm của mình trên mạng xã hội. Bot account spy là chủ hoàn toàn của tool đó. Tương tự với feature analytics, feature content coach (AI viết kịch bản content), và một feature content calendar đang làm dở, tự động tạo content cho bạn ở chế độ nền.

Anh coi chúng là các staff engineer, các tech lead, các full stack engineer làm chủ những feature này. Mỗi khi muốn build gì đó trong một feature cụ thể, anh gọi cloud agent ngay bên trong Grok Bot.

## 12. Sửa một bug như giao việc cho teammate

Anh cho xem một ví dụ. Trong AI content studio có một bug: Yorby cho người dùng chọn một chat model và một image model, nhưng khi họ dùng thật và cửa sổ chat bị thu nhỏ, chỉ còn thấy chat model, image model thì không còn hiện nữa.

![Mockup giao diện AI Content Studio của Yorby, bản hiện tại bị lỗi với thanh dưới cắt mất image model](https://homus.dev/photos/54D1hFfaju8-1134.jpg)

Mockup bot tạo ra cho bug này: tab "Current (broken)" cho thấy khung chat thu hẹp, thanh dưới chỉ còn "Chat model" và phần image model bị cắt; các tab A Wrap, B Compact chips, C Models popover là ba phương án sửa.

Anh đối xử với bot như một teammate, một đồng nghiệp thật. Anh bảo nó: đây là một bug, hãy đi sửa. Rồi làm một chút UI/UX exploration, và kiểm chứng rằng nó chạy bằng cách gửi cho anh kết quả thật, "biên lai" thật (the real receipts) rằng nó đã chạy. Bot xử lý đúng như một teammate thật sẽ làm, và nó kích hoạt một cloud agent thật để làm phần việc, cloud agent này hiện ngay trong Cursor của anh.

![Khung chat của bot UGC Studio với nguyên nhân bug, PR và ảnh so sánh các phương án](https://homus.dev/photos/54D1hFfaju8-1148.jpg)

Bot UGC Studio báo lại: nguyên nhân là khung chat thu hẹp còn khoảng 30% cùng một footer không xuống dòng và `overflow-hidden` cắt mất Image model (và Plan mode). Kèm theo là cloud agent đã xong (18 file, +760 −77, nút View PR và Open in Cursor), ảnh so sánh bản lỗi với phương án A, B, C, và câu hỏi "Which composer layout should we implement?" với khuyến nghị phương án A.

Và mỗi khi một PR được merge, anh bảo Grok Bot đang làm chủ feature đó merge PR và làm thêm hai việc. Thứ nhất, xem các thay đổi vừa được làm và cập nhật knowledge base của mình, với tư cách staff engineer, tech lead, owner của feature, về cách mọi thứ vận hành. Thứ hai, tạo và duy trì verification skill mới cho phần giao diện (surface) này, để các agent sau này khi làm trên phần tương tự của tool stack đã có sẵn một bộ skill định nghĩa rõ cách dùng phần đó của ứng dụng.

Nhờ vậy bot ngày càng thông minh hơn: nó tự cập nhật hiểu biết của mình khi có thêm PR, trong lúc review PR và viết thêm ngày càng nhiều verification skill.

## 13. Group chat giữa các bot, buông việc đọc code, và engineering dồn về đầu

Một điều Thomas rất háo hức muốn làm mà chưa làm: nếu bạn build một feature chéo, chạm vào nhiều surface, bạn có thể tạo hẳn một group chat. Ví dụ anh định làm gì đó dính cả feature analytics lẫn UGC studio. Bạn tạo một group chat với các bot của mình, như một team engineering thật, bảo chúng kiểm tra công việc của nhau, brainstorm với nhau và tìm ra cách build feature đó. Anh chưa làm việc này, nhưng rất háo hức chờ lúc cần tới, vì anh thấy nó rất, rất, rất ngầu.

Anh thừa nhận đây rõ ràng là thứ bleeding edge, cutting edge, và thật điên khi nói rằng chúng ta đã tới lúc có thể đối xử với AI bot như teammate, đồng nghiệp thật sự. Nhưng anh đã ở điểm đó. Anh nghĩ để vượt lên tầng tiếp theo, trở thành "AI 10x engineer", bạn phải buông việc đọc toàn bộ code, phải tin agent hơn một chút. Và cách duy nhất để tin agent hơn, rồi đọc ít code hơn, là tạo ra các verification skill và code standard cực kỳ chặt để model tuân theo và implement. Phía bạn thì chỉ cần lo các quyết định architecture ở tầng cao hơn.

Anh chắc chắn bug sẽ xảy ra, nhưng bug cũng xảy ra với team engineering toàn người. Anh nói rõ anh không bảo mọi người phải làm thế này; đây chỉ là việc anh đang làm. Nó rất thú vị với anh, và anh thật sự thích "paradigm" engineering mới này.

Theo Thomas, phần engineering giờ dồn vào khâu viết spec: một ticket chi tiết như giao cho junior engineer, sau đó stack tốt gần như tự chạy.

Thậm chí anh thấy với paradigm mới này, toàn bộ phần engineering thực ra diễn ra ở giai đoạn đầu. Nó giống như bạn tạo một ticket GitHub mới, một ticket Linear, một task để giao cho một junior engineer. Anh viết task và các mục trong ticket cực kỳ chi tiết. Điều đó buộc anh làm phần engineering ngay từ đầu, trong prompt đầu tiên, vì về cơ bản bạn phải nói rõ: mình muốn thay đổi gì, chạm vào những surface nào, đây là các kịch bản verification phải pass, và đây là các kịch bản khác để chắc thay đổi không gây regression nào.

Nên bây giờ, prompt để build một feature của anh mất khoảng 10 đến 15 phút, vì đó là thời gian anh cần để viết một spec thật tốt. Nhưng nó thật sự đáng: khi bạn viết một prompt cực chi tiết để build một feature, có phần verification, có context, có tài liệu tham chiếu và mọi thứ, và bạn build nó bằng một engineering stack mạnh (không nhất thiết là pstack, đó chỉ là thứ anh dùng), thì một engineering stack tốt với AI tooling tốt để kiểm chứng tính đúng đắn, kiểm rằng thay đổi thật sự chạy, gần như tự vận hành. Nó one-shot, verify mọi thứ, review code theo chuẩn cao. Việc của bạn chỉ là liếc qua rồi approve hoặc yêu cầu sửa. "Pretty incredible stuff."

## 14. Agent chăm sóc khách hàng

Thomas chuyển sang phần dùng thêm AI agent để vận hành startup nói chung, với vài thứ muốn chia sẻ. Thứ nhất là một customer support agent. Anh không bấm vào để cho xem các đoạn chat, vì trong đó có thông tin khách hàng. Trước đây họ dùng Intercom, nhưng rồi chuyển sang chỉ dùng email thuần để xử lý toàn bộ customer support.

Customer support agent của Yorby: tự xử lý các tình huống đã có hướng dẫn, chuyển tình huống mới cho hai founder, rồi được bổ sung hướng dẫn sau mỗi lần như vậy.

Bot này là "nhà" của toàn bộ customer support tự động. Họ cho nó hướng dẫn cách xử lý các tình huống khác nhau, và nó theo dõi một support inbox riêng. Gặp tình huống đã biết cách xử lý, nó tự xử lý. Gặp tình huống không có trong hướng dẫn tường minh, nó gọi Thomas và người co-founder vào can thiệp, và họ tự giải quyết. Giải quyết xong, họ cập nhật customer support agent ngay đó với hướng dẫn mới: đây là cách xử lý tình huống này nếu nó lặp lại.

## 15. Bot sửa lỗi trực 24/7 và quyền tự merge

Tiếp theo là Yorby error fixing bot. Đây là on-call agent trực 24/7, 365 ngày một năm, nhận mọi lỗi đổ về từ PostHog. Họ dùng PostHog để bắt mọi lỗi, và lỗi nào đến bot cũng xem.

Đầu tiên, nó triage. Nó xem lỗi này có nằm ở một surface rất cụ thể không: trong UGC studio? trong account spy? trong content calendar, analytics, content coach? Nếu có, nó gói lỗi lại, gom đủ thông tin cần thiết rồi chuyển cho engineer chuyên trách, tức bot staff engineer, tech lead đang làm chủ surface đó, để bot ấy sửa. Còn nếu không chuyển được cho ai cụ thể, chính nó trở thành người sửa các bug lặt vặt (miscellaneous bug fixer).

![Khung chat bot Yorby Error Fix với hai bản sửa lỗi lúc nửa đêm, mỗi bản có bug gốc, cách sửa và bằng chứng](https://homus.dev/photos/54D1hFfaju8-1843.jpg)

Bot Yorby Error Fix báo hai bản sửa "Midnight misc fix ready", đang chờ duyệt. Mỗi báo cáo có ba phần: 1) Original bug (lỗi PostHog về snapshot workflow của Facebook Page, lỗi refresh token của TikTok), 2) How the fix works, 3) Proof (ví dụ "doctor PASS, 16 Vitest passed").

Bot chạy 24/7, 365 ngày, và phần lớn thời gian nó không tự merge code. Nhưng anh có thêm vài chỉ dẫn vào prompt của nó: nếu bạn thấy đây là một bug lan rộng, xảy ra với nhiều user chứ không phải một sự cố cá biệt, thì anh cho bạn toàn quyền merge bản sửa. Anh thừa nhận giao cho một bot mức tin tưởng như vậy là rất lớn, nhất là khi nó xử lý giữa đêm. Nhưng lý do anh dần có được niềm tin để cho bot làm vậy là vì anh đã đầu tư nhiều hơn hẳn vào verification skill trong ứng dụng. Nên anh tin được output và các thay đổi bot của mình làm ra hơn nhiều.

Chuyện đó không xảy ra thường xuyên, vì anh đặt ngưỡng rất cao. Về cơ bản anh hỏi: đây có phải lỗi cấp P00, khẩn cấp tuyệt đối, ảnh hưởng tới toàn bộ hoặc phần lớn user không? Nếu có, bot được merge mà không cần anh review và approve. Nên nó hiếm khi xảy ra, nhưng nếu xảy ra thì anh tin nó, nhờ khoản đầu tư vào verification skill anh đã làm trong AI coding stack của mình.

## 16. Kết: chưa bao giờ thấy mình mạnh như bây giờ

Thomas khép lại: đó là tất cả cho hôm nay. Đây là một thời điểm điên rồ để được sống và được làm kỹ sư, hơi đáng sợ một chút mà cũng hơi phấn khích cùng lúc. Không ai biết chuyện gì sẽ xảy ra. Nhưng nhìn chung anh cực kỳ háo hức, anh yêu những gì mình đang làm và yêu hướng mọi thứ đang đi.

Anh nói chưa bao giờ trong đời thấy mình mạnh mẽ như một builder đến vậy, và rất háo hức với những gì mọi người có thể tiếp tục build trong tương lai. Video đã đi qua khá nhiều thứ thú vị. Anh mời mọi người để lại câu hỏi hoặc bình luận; anh cố trả lời càng nhiều càng tốt, nhất là trong vài ngày đầu sau khi video ra. Anh cảm ơn mọi người đã xem và hẹn gặp ở video sau.

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

- Tên gốc: My New AI Coding Setup That Helps Me Ship 30+ PRs A Day
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=54D1hFfaju8](https://www.youtube.com/watch?v=54D1hFfaju8)

- Kênh YouTube Your Average Tech Bro (Thomas Kim): [youtube.com/channel/UCfQk5qGOEO5cPPDFlQe2lFQ](https://www.youtube.com/channel/UCfQk5qGOEO5cPPDFlQe2lFQ)

- Yorby, AI social media marketing tool mà Thomas đang build cùng co-founder (trang có giới thiệu Thomas Kim là co-founder): [yorby.ai](https://www.yorby.ai)

- pstack trong repo plugin của Cursor (README có lệnh cài, bước setup chọn model và danh sách skill, gồm create-verification-skill và maintain-verification-skill): [github.com/cursor/plugins/tree/main/pstack](https://github.com/cursor/plugins/tree/main/pstack)

- gstack của Garry Tan, bộ skill Thomas nhắc tới để so sánh: [github.com/garrytan/gstack](https://github.com/garrytan/gstack)

- Tài liệu Cursor về Cloud Agents (agent chạy trong máy ảo cô lập trên cloud, build, test và tương tác được với phần mềm vừa sửa): [cursor.com/docs/cloud-agent](https://cursor.com/docs/cloud-agent)

- Tài liệu PostHog Error Tracking, nơi bot sửa lỗi của Yorby lấy lỗi: [posthog.com/docs/error-tracking](https://posthog.com/docs/error-tracking)

Nguồn: https://homus.dev/talks/my-new-ai-coding-setup-that-helps-me-ship-30-prs-a-day · cập nhật 2026-10-16