Software factory tự cải tiến: từ Sentry, PostHog tới PR đã merge

1. Một software factory tự build và tự cải tiến

Eric mở đầu bằng một lời khẳng định: nếu bạn đang dùng AI để build ứng dụng, bạn cần biết chính xác cách build ứng dụng một cách hoàn toàn autonomous, và hơn thế nữa là tự cải tiến (self-improving). Theo anh, ứng dụng hoàn toàn có thể tự cải tiến bằng cách dùng dữ liệu telemetry, ví dụ Sentry (theo dõi lỗi) và PostHog (analytics người dùng). Từ những tín hiệu đó, hệ thống tự soạn ra ticket hay task, rồi đưa ticket đi qua cả một "nhà máy" (factory).

Trong nhà máy này có những specialist agent, mỗi agent tập trung vào một phần cụ thể: building, QA và review. Khi một vòng xong, hệ thống quay lại thu thập thêm ticket mới và tiếp tục cải tiến ứng dụng, tự nó làm, không cần người thúc.

2. Mô phỏng một team phát triển thật, mọi thứ ghi lại trong GitHub issue

Cả chu trình, theo Eric, thực chất đang bắt chước một team phát triển phần mềm production thật: có một builder, một QA và một reviewer. Giả sử QA không pass, ticket sẽ bị gửi ngược lại cho builder để sửa (revision), y như ngoài đời.

Mỗi ticket được theo dõi trong GitHub issues. Phần description của issue mô tả việc cần làm; bên trong còn có pull request, và cả comment của từng agent đã đi qua ticket đó. Nhờ vậy, bất kỳ agent nào, hay bất kỳ người nào, cũng có thể mở issue log ra xem chính xác chuyện gì đã xảy ra và agent đã làm những gì.

3. Nhiều tháng dùng thật, guard, hook và bản open source

Eric kể anh đã dùng agentic framework này nhiều tháng: để build ứng dụng, để fix bug, và để tự động giảm tỉ lệ người dùng rời bỏ (churn rate). Đi kèm là những guard và hook phù hợp, để chắc chắn agent build mọi thứ theo đúng cách.

Giờ anh đã open source toàn bộ software factory cùng các skill, và làm cho cả quy trình dễ bắt đầu, dễ onboard. Mỗi skill bên trong dùng những skill tốt nhất mà anh đã chọn lọc khi review trên kênh, cộng với những skill anh tự build và dùng trong công việc phát triển hằng ngày, tất cả được nhúng vào software factory.

Bạn cũng có thể chạy software factory này trên bất kỳ model nào bạn thích.

Video có một đoạn quảng cáo cho cộng đồng của chính Eric trên Skool. Trong đoạn đó anh giới thiệu mình từng là senior AI software engineer ở Amazon và Microsoft.

4. Bức tranh tổng: telemetry, super-collect và super-board

Sau đó Eric đi vào cách mọi thứ vận hành. Điểm bắt đầu là telemetry, như Sentry và PostHog, nơi bạn theo dõi hiệu năng hệ thống và analytics người dùng. Với tất cả những nguồn như vậy, anh dùng một skill tên là super-collect: nó thu thập các vấn đề theo lịch (on a schedule) và cuối cùng thêm chúng thành ticket trên GitHub project board.

Tiếp theo, ticket đi qua skill super-board. Đây là nhà máy gồm các specialist agent tập trung vào building, QA và toàn bộ quá trình review. Như đã nói, ticket được xử lý từng cái một trên kanban board thật. Một điểm cần lưu ý: nếu một ticket cần con người duyệt (human approval), hệ thống sẽ đơn giản là đưa nó sang cột Blocked.

Eric nhắc lại rằng bạn có thể chạy nó trong bất kỳ harness hay model nào: dù bạn dùng Claude Code hay Codex, muốn đổi sang model khác thì cũng làm được, việc đổi model rất dễ. Setup thì rất, rất đơn giản: chỉ cần chạy bước onboard là bạn thiết lập được các check, tài khoản GitHub, kết nối với đúng project board, dùng đúng branch, cùng system prompt, policy, review và mọi thứ còn lại. Setup một lần xong là gần như mọi thứ sẵn sàng.

5. super-build bước một: chuẩn bị với Ponytail

Đó là bức tranh lớn. Phần tiếp theo, theo Eric là phần mạnh nhất: các specialist agent làm việc thế nào. Anh đã review rất nhiều skill spec-driven development và skill phát triển giúp build ứng dụng chính xác, theo best practice. Anh gom tất cả những skill chọn lọc đó vào các specialist agent này để chúng xử lý mọi việc đúng cách.

Khi bạn chạy /super-board run, mỗi khi một ticket rơi vào cột Building (cột của builder), nó sẽ kích hoạt super-build. Trên skill map có thể thấy super-build chia thành các bước, đầu tiên là chuẩn bị (Prepare), rồi Build, rồi Check. Bước chuẩn bị gồm hai skill dùng để chuẩn bị trước khi code: trước khi viết bất kỳ dòng code nào, hai skill này được gọi trước.

Trên skill map, lane super-build có 14 node: cột Prepare có ponytail và context7 (docs); cột Build có implement, diagnosing-bugs, codebase-design và tdd từ bộ skill của Matt Pocock; cột Check có verification, code-review và humanizer; cuối cùng là Hand off ghi kết quả lên GitHub Project board.

Skill đầu tiên được gọi là Ponytail. Eric nói skill này rất, rất phổ biến, theo anh đã có hơn 100.000 star trên GitHub, một trong những skill phổ biến nhất hiện nay. Việc của nó là giảm độ phức tạp của code trong codebase. Bởi vì, tin hay không thì tùy, rất nhiều AI agent viết code cứ duplicate nối tiếp duplicate; một file có thể dài tới 1.000 hay thậm chí 100.000 dòng.

File SKILL.md của Ponytail mở đầu bằng câu "You are a lazy senior developer. Lazy means efficient, not careless.": agent đóng vai một senior lười theo nghĩa hiệu quả, đã thấy đủ codebase over-engineered, và tin rằng code tốt nhất là code không bao giờ phải viết.

Cách Ponytail làm là đi theo một chiếc thang (ladder) để xét xem đoạn code này có thật sự nên được viết ra hay không. Eric nói có bảy bậc. Đầu tiên nó kiểm: tính năng này có cần tồn tại không? Rồi xem tính năng này đã có sẵn trong codebase để tái sử dụng chưa, có thể là một hàm util hay một component có sẵn. Có thư viện chuẩn (standard library) hay tính năng native của nền tảng nào dùng ngay được không? Hay một dependency đã cài sẵn giải quyết được việc này? Và kể cả khi đó, có làm được trong một dòng không?

Những câu hỏi như vậy giúp giảm duplicate code và giảm cả số token tiêu tốn, vì code viết ra càng nhiều thì token tốn càng nhiều và thời gian cũng càng lâu. Nên nếu đã có giải pháp sẵn, hãy cố dùng giải pháp sẵn có nếu được.

6. Context7: đọc docs của dependency trước khi viết code

Skill chuẩn bị thứ hai là Context7. Khả năng cao là ứng dụng của bạn dùng cả đống dependency: Vercel, React, có thể NestJS, bất kể bạn dùng gì, cộng thêm các thư viện bên thứ ba. Bạn cần biết chính xác documentation của chúng. Vì thế Eric dùng skill Context7 để đọc documentation thật của từng thư viện, để AI biết chính xác cách dùng những thư viện đó trước khi viết một dòng code nào.

Chỉ sau khi xong phần chuẩn bị này, quy trình mới chuyển sang bước build thật sự.

7. Bước build với Matt Pocock skills, rồi check và handoff

Bước build gồm những việc như implement tính năng mới hay fix bug. Ở đây Eric đang dùng bộ Matt Pocock skills. Anh đã review rất nhiều skill spec-driven development trên kênh: GSD, GStack, Superpowers, và cả Matt Pocock skills. Nhìn chung, anh thấy Matt Pocock skills gọn nhẹ (lightweight) và thực sự theo best practice để tận dụng năng lực của model khi viết code.

Cụ thể, super-build dùng skill implement cho tính năng mới, diagnosing-bugs cho việc fix bug, và codebase-design cho refactor. Nếu bạn muốn xem phân tích đầy đủ mọi skill của Matt Pocock, Eric đã làm một video tutorial riêng về chúng.

Sau khi build xong là bước check: verification, code review, và skill humanizer để chắc chắn AI không viết ra những từ ngữ phức tạp khó hiểu. Cuối cùng là phần handoff: gói lại mọi thứ đã hoàn thành và ghi vào GitHub issue tương ứng.

8. super-qa: vì sao testing là critical

Sau quá trình build là super-qa. Eric gọi đây là phần quan trọng nhất, vì super-qa tập trung vào việc xác minh ticket đã thật sự hoàn thành. Từng làm senior software engineer ở Amazon và Microsoft, anh coi testing là cực kỳ quan trọng: một tính năng nhỏ, khi đã ship, có thể được hàng triệu, thậm chí hàng trăm triệu người dùng, và chỉ một bug có thể gây thiệt hại thật trong một ứng dụng production.

Trên màn hình là toàn bộ flow của lane super-qa: chuẩn bị với tdd-v2, build với tdd, diagnosing-bugs, ask-matt, vitest và Playwright practices, check với verification, testing-strategy và humanizer, rồi hand off bằng script ghi bug và PR body lên GitHub Project board.

Kênh của anh đã review rất nhiều skill về testing. Điều làm skill QA này khác những skill khác, theo Eric, là nó dùng đúng thư viện testing. Khả năng cao là bạn đang dùng Playwright cho việc test, nhưng đó thực ra là bước test cuối cùng.

9. Kim tự tháp test: từ unit lên tới end-to-end

Bạn muốn test tầng dưới cùng trước, tức là tầng unit testing nền tảng, rồi mới đi dần lên integration testing, hay component testing để test các React component thật, vì các tầng này phụ thuộc lẫn nhau: component gọi tới các hàm khác nhau hay các hook khác nhau.

Vì vậy, điều thật sự quan trọng là testing phải hoàn chỉnh ở tầng dưới cùng trước. Khi component testing đã xong, lúc đó mới chuyển sang Playwright hay Cypress, tức các bài test end-to-end khác nhau cho UI component. Còn với backend, có thể có cả loạt test khác như stress test, integration test và nhiều thứ nữa, nhưng video này không đi vào phần đó.

Có rất nhiều thư viện testing, nên dùng đúng thư viện cho đúng ticket là điều quan trọng. Eric đã nhúng toàn bộ kiến thức này vào skill super-qa, để nó biết chính xác cách dùng đúng thư viện testing cho đúng bản fix.

10. super-review và super-collect: vòng tự cải tiến

Cuối cùng trong ba lane là super-review. Trên màn hình là toàn bộ flow của super-review, và phần quan trọng nhất gồm ba thứ: Ponytail review, code review, và codebase-design để chắc chắn code cũng đã được refactor hoàn chỉnh.

Và cuối cùng là super-collect, skill gom ticket từ các nguồn khác nhau như Sentry và PostHog. Nguồn cũng có thể là ý tưởng: nếu bạn muốn brainstorm tính năng mới, bạn có thể dùng các skill brainstorm để đổ các ý tưởng đó (brain dump) thành GitHub issue. super-collect sẽ đi qua quy trình để xác minh mọi thứ, xác nhận, rồi thêm vào backlog.

11. UI refinement loop với grilling và impeccable

Ngoài ra còn có UI refinement loop. Giả sử bạn muốn làm đẹp một component hay một trang cụ thể trong ứng dụng, và trang đó trông như "AI slop". Làm sao để nó tự cải tiến trong vòng lặp? Eric tạo một custom skill tên ui-refine-loop. Skill này dựa nhiều vào Matt Pocock skills và skill impeccable. Nếu bạn chưa biết, impeccable đơn giản là một skill giúp thiết kế UI bớt "AI slop".

Trên skill map, /ui-refine-loop gồm sáu bước: Refine a UI (trang hoặc component), Grill + save direction (dùng skill grilling của Matt Pocock để thống nhất ý muốn), Check the UI (impeccable xếp hạng vấn đề), Fix by routed verbs (các lệnh của impeccable), Review each fix (humanizer), rồi Draft PR. Mặc định 5 vòng; dừng sau hai lần check sạch lỗi P0/P1, hai vòng bị revert, hoặc khi agent chết.

Cách dùng: bạn đưa ra một hướng, ví dụ thiết kế lại một trang hay một component, và nói chính xác những vấn đề bạn thấy. Skill sẽ hỏi bạn vài câu để làm rõ ý định, chẳng hạn bạn muốn đi theo hướng nào. Màn hình minh họa câu hỏi "Which direction do we go for?" với ba lựa chọn Minimal, Bold, Playful, và Bold được chọn.

Sau đó nó chạy theo vòng lặp. Đầu tiên là chẩn đoán (diagnose): critique, rồi audit. Tiếp theo đi qua nhóm sửa như harden, clarify; phần này bạn có thể đọc thêm trong documentation. Rồi tới styling, motion (thêm chuyển động), polish, và cuối cùng quay lại bước diagnose để xem còn vấn đề nào cần sửa. Thường nó chạy vài vòng, và bạn sẽ có thiết kế UI tốt hơn nhiều so với ban đầu.

12. git-sync, guardrail và README luôn mới

Bộ này còn có vài sub-skill, ví dụ git-sync: nó giải quyết conflict, pull code về, và dùng best practice để viết commit message tốt nhất có thể. Trên skill map, bước Build của /git-sync dùng skill resolving-merge-conflicts của Matt Pocock, bước Check đi qua hook guard-protected-push.

Thêm nữa là các guardrail đúng chỗ: những hook phù hợp để chặn mọi secret bị ghi vào repository. Nó cũng tự động thiết lập eval cho các skill và cập nhật file README: mọi phần documentation README đã lỗi thời đều được tự động cập nhật.

13. Tổng kết và setup trong ba bước

Đó gần như là toàn bộ software factory của Eric. Trong video, anh đã đi qua software factory là gì, nó tự cải tiến ra sao, và nó build mọi thứ hoàn toàn autonomous theo cách chính xác nhất thế nào. Anh đã gói vào đây domain knowledge của mình, bảy năm làm senior software engineer ở Amazon và Microsoft: tất cả hiểu biết về cách phát triển phần mềm tốt hơn với AI được đóng gói thành các skill, cùng với những skill chọn lọc anh đã review trên kênh, tất cả nằm chung trong một repository.

Quy trình setup được giữ rất đơn giản, chỉ ba bước. Cài đặt xong, bạn chạy onboard; bước này đảm bảo mọi dependency đều được kết nối đầy đủ. Sau đó chỉ cần chạy lệnh run, nó sẽ fan out ra nhiều agent khác nhau, có thể tối đa ba agent, để "rút cạn" (drain) các ticket đang nằm trong cột Ready.

Ba bước theo README của repo:

curl -fsSL https://raw.githubusercontent.com/EricTechPro/super-board/main/get.sh | bash

/super-board onboard

/super-board run my-app

Eric khép lại bằng lời nhờ người xem like video và tặng repository một star nếu thấy thích. Anh cũng giới thiệu một video khác của mình về toàn bộ vòng đời cách team của Anthropic thực sự build ứng dụng, rồi chào tạm biệt.