Agentic coding workflow trọn vòng trên một feature thật

1. Một vòng lặp, đi trọn trên một feature thật

Damian Galarza mở đầu bằng chuyện anh vừa viết lại toàn bộ agentic workflow của mình, với ba công cụ chính là Claude Code, Codex và Pi. Bản viết trước đó đã cách đây khoảng một năm. Lần này anh kể anh dùng những coding tool nào, những skill nào tạo nên workflow đó, và một ngày làm việc của anh trông ra sao (theo video đăng ngày 29/10/2026).

Hôm nay anh không chỉ kể lại mà đi qua toàn bộ vòng lặp đó trên một feature thật: anh shape công việc thế nào, rồi dispatch nó sang pstack và điều phối tất cả phần việc ấy với nhau ra sao, và đi tiếp cho tới code review rồi ship một số feature. Anh tự giới thiệu: anh là Damian Galarza, đã làm software engineer khoảng 15 năm (theo lời anh trong video đăng ngày 29/10/2026). Rồi anh nói: hãy bắt tay vào shape một phần việc và khởi động các agent.

2. Shaping khác planning, và skill grill me

Phần đầu tiên của vòng lặp là quá trình shaping. Theo Damian, shaping là lúc mình thật sự mở gói ra xem phần việc mình định làm là gì, trước khi bắt tay vào build. Và đây là phần mà dạo này anh dành nhiều thời gian nhất: bảo đảm phần việc được phác ra và có cấu trúc theo cách mà cả anh lẫn một agent đều hiểu được (theo video đăng ngày 29/10/2026).

Anh dặn đừng nhầm shaping với planning hay plan mode. Planning là lúc bàn chuyện phần implementation sẽ thật sự chạy ra sao. Shaping thì chưa nhất thiết đi vào mọi chi tiết kỹ thuật, mà là cái hiểu tổng thể về vấn đề đang cần được giải (theo Damian, video đăng ngày 29/10/2026).

Cách anh thích nhất để shaping là dùng skill grill me của Matt Pocock. Matt Pocock có cả một bộ skill công khai trên mạng, và theo Damian thì tất cả đều rất tốt (video đăng ngày 29/10/2026). Grill me là một trong số đó, và nó có vài biến thể. Một là grill me thuần, bạn dùng được cho cả những cuộc bàn không mang tính kỹ thuật. Hai là grill with docs, dùng bên trong một code repo để tận dụng phần docs nằm ngay cạnh code. Theo Damian, grill with docs dùng domain modeling và domain-driven design để giúp hiểu domain trông ra sao và cách chẻ nó ra thành các phần việc (video đăng ngày 29/10/2026).

Anh đã chuẩn bị sẵn một kịch bản trong đó anh đã đi hết một buổi grilling. Anh không muốn làm trực tiếp trong video, vì một buổi như vậy có thể có rất nhiều câu hỏi và mất nhiều thời gian, nhưng người xem vẫn thấy được thoáng qua quá trình grilling và shaping trông như thế nào.

3. Bối cảnh: rời Attio, tự build một CRM gọn trong PraxisAgent

Để có bối cảnh, Damian giới thiệu ứng dụng của anh: PraxisAgent. Anh gọi nó là lớp trí tuệ (intelligence layer) vận hành Praxis Forward, công ty của anh. Tại thời điểm quay (video đăng ngày 29/10/2026), ứng dụng này được thiết kế để kết nối với một CRM tên là Attio. Theo Damian, Attio là một hệ CRM khá đầy đủ và phức tạp, và nó có rất nhiều feature mà một team nhỏ như anh không thực sự dùng tới, xét về mặt chi phí.

Vì vậy anh đang tính chuyển sang một CRM nhẹ do chính anh build bên trong ứng dụng của mình, rồi sau đó có thể đặt một agentic workflow lên trên. Tức là may đo nó cho đúng những gì hợp lý với tổ chức của anh, thay vì dùng một thứ có sẵn (kế hoạch anh kể trong video đăng ngày 29/10/2026).

Prompt anh gõ vào Claude Code để mở buổi grilling (demo trong video đăng ngày 29/10/2026), chép từ màn hình:

I want to move away from Attio for our CRM. It's quite powerful however it feels expensive for our use case as a small team. Instead I want to build a lightweight CRM for us at Praxis Forward built into Praxis Agent. At first it doesn't need to have any intelligence layer built in. Instead, I want to focus on the foundation layers of it. The basic CRUD aspects of this. I want to design it using Rails conventions but using our typescript application. RESTful routes, SOLID principles, things like that. /grill-me for the first pass of this. Analyze what i have inside of Attio and what we pull out and how.

Damian nói anh gọi /grill-me cho lượt đầu, dù lẽ ra anh nên dùng grill with docs, nhưng đằng nào thì cũng sẽ tới được thứ cần có. Anh chỉ ra rằng ngay từ đầu anh không đưa quá nhiều chi tiết về việc mình định làm. Anh chỉ đưa một cái hiểu ở mức cao về vấn đề muốn giải, rồi hai bên cùng mở gói nó ra.

Theo Damian (video đăng ngày 29/10/2026), model càng ngày càng thông minh thì bạn càng đưa ít mà vẫn nhận được nhiều. Vì vậy anh không đưa một output mô tả chi tiết điều mình muốn, mà đưa một mục tiêu cao về hướng đi, cộng một chút guardrail: anh nhắc tới vài pattern anh muốn theo, muốn dùng các thao tác CRUD cơ bản, và anh dặn nó xem xét những gì đang có trong Attio.

4. Hai agent đi tìm dữ kiện, và những câu hỏi đầu tiên

Damian đã nối sẵn Attio MCP, nên agent có thể với vào Attio, lấy dữ liệu ra và tự xem dữ liệu ở đó là gì (demo trong video đăng ngày 29/10/2026). Anh nhấn mạnh: lớp context đó rất quan trọng, tức là cho agent kết nối tới những thứ nó cần, mà ở đây là Attio cho phần kết nối với CRM.

Trên màn hình, skill grill me được nạp, và skill grilling cũng được nạp theo vì là dependency. Damian gọi đó là một chồng skill lồng nhau. Rồi agent dispatch hai agent tìm dữ kiện (fact-finding) chạy song song. Anh nói đây là giao diện background agent của Claude Code dạo này (theo video đăng ngày 29/10/2026). Một agent được gửi đi xem workspace Attio hiện có gì, agent kia đi tìm hiểu cách dùng và các convention đã có sẵn trong codebase (demo trong video đăng ngày 29/10/2026).

Trong lúc hai agent đó chạy, nó bắt đầu hỏi Damian. Câu hỏi kiểu grill me mở đầu bằng Q1, và nó đưa cho anh cả danh sách câu hỏi lẫn câu trả lời mà nó nghĩ là hợp lý; anh có thể phản bác lại (demo trong video đăng ngày 29/10/2026).

Q1: thay thế hay cùng tồn tại? Mục tiêu là bỏ hẳn Attio, hay chạy cả hai một thời gian, giữ Attio cho những việc như đồng bộ email? Thay thế hoàn toàn nghĩa là CRM mới là nguồn sự thật duy nhất và dữ liệu Attio được migrate sang. Cùng tồn tại nghĩa là đồng bộ hai chiều, và theo agent thì việc đó tốn hơn nhiều so với giá trị nó mang lại cho một team nhỏ. Đề xuất của nó: thay thế hẳn, lên kế hoạch một lần cutover có migration, chạy Attio ở chế độ chỉ đọc trong một khoảng chồng lấn ngắn, rồi huỷ; không đồng bộ hai chiều (demo trong video đăng ngày 29/10/2026). Damian đồng ý, và anh sẽ trả lời sau rằng anh đồng ý với Q1.

Q2: ai dùng nó? Có phải chỉ nội bộ Praxis Forward, tức vài thành viên team, một workspace, ai cũng thấy mọi thứ, không có kế hoạch đưa cho khách hàng? Damian xác nhận: anh không nhắm biến nó thành một sản phẩm SaaS cho người khác dùng, mà rất có chủ đích chỉ dùng nội bộ, mọi thành viên team đều đọc được. Anh đồng ý với phạm vi đó (demo trong video đăng ngày 29/10/2026).

5. Fixed schema, cách trả lời câu hỏi, và domain model

Q3, theo Damian là câu rất quan trọng, hỏi về schema: fixed schema hay custom attributes. Phần lớn sức mạnh của Attio, và cả độ nặng nề của nó, đến từ các object và attribute do người dùng tự định nghĩa, lưu dưới dạng cấu hình. Lựa chọn kia là một schema kiểu Rails: bảng thật, cột thật, và một migration mỗi khi muốn thêm trường. Agent đưa ba phương án để chọn một (demo trong video đăng ngày 29/10/2026):

• (a) Fixed, typed schema: thêm một trường nghĩa là một migration cộng một thay đổi code (demo trong video đăng ngày 29/10/2026).
• (b) Các cột lõi cố định cộng một túi "custom fields" kiểu JSONB (demo trong video đăng ngày 29/10/2026).
• (c) Attribute kiểu Attio, điều khiển bằng metadata (EAV) (demo trong video đăng ngày 29/10/2026).

Agent đề xuất (a), vì với một team nhỏ thì việc thêm trường hiếm khi xảy ra (demo trong video đăng ngày 29/10/2026). Damian đồng ý: phần lớn sức mạnh của Attio nằm ở custom object và mọi thứ bạn làm được bên trong nó, và anh không thực sự dùng tới chúng. Anh có thể may đo dần khi build.

Rồi anh tua nhanh tới đoạn anh bắt đầu trả lời. Anh chỉ viết một danh sách gạch đầu dòng theo các câu nó hỏi. Q1: có, anh sẽ huỷ hẳn Attio lúc này, tức là đồng ý với nó. Q2: nội bộ Praxis Forward, không có kế hoạch đưa cho khách hàng. Q3: vì mình kiểm soát schema nên không dùng custom attributes. Từ câu một tới câu bảy anh đi lần lượt như thế. Có lúc anh trả lời chi tiết hơn, có lúc anh hỏi lại để nó làm rõ, hoặc chỉ "yes, yes, yes, no, no, no". Theo anh, cách trả lời không cần có cấu trúc hay giáo điều gì (video đăng ngày 29/10/2026).

Tới đây cuộc hỏi đi vào cấu trúc dữ liệu. Q8 là domain model. Model của Attio là chung chung: object và list, mọi người bạn từng email đều thành một record. Và vì anh đã trả lời rằng sẽ không dùng custom attributes, giờ nó xây tiếp trên những câu trả lời trước để đưa thêm chi tiết (demo trong video đăng ngày 29/10/2026).

Domain model nó đề xuất có company, person, opportunity, engagement, note và task. Damian thấy tất cả đều hợp lý, và có thể đào sâu thêm nữa nếu cần (demo trong video đăng ngày 29/10/2026).

6. Decision record sau 36 vòng hỏi, glossary và spec trên Linear

Sau khoảng 36 vòng câu hỏi (theo Damian, video đăng ngày 29/10/2026), agent đề xuất một decision record cuối cùng để anh xem lại. Nó ghi mục tiêu và phạm vi: thay Attio và huỷ nó. Bản V1 chỉ là CRUD cơ bản, tạo, đọc và cập nhật. Không có intelligence layer, không có enrichment, không đồng bộ email hay lịch, không có gì kiểu đó. Record chỉ được tạo có chủ đích, không bao giờ tự sinh ra từ hộp thư. Convention theo Rails nhưng không làm một bản sao ActiveRecord, đó là một trong những điểm hai bên đã đi qua. Rồi thin controller, typed schema, migration và những thứ tương tự. Sau đó là domain model mà hai bên đã lặp qua lại (demo trong video đăng ngày 29/10/2026).

Đọc xong, anh thấy cả phần kiến trúc các lớp, phần API, các endpoint trông ra sao, API authentication có thể thế nào. Cuối cùng nó hỏi: điều này có khớp với cách anh hiểu không? Khi anh xác nhận, nó có thể viết spec lên Linear bằng spec writer, rồi chẻ ra thành các lát cắt theo từng ticket bằng issue writer (demo trong video đăng ngày 29/10/2026).

Damian nói đó là bước kế tiếp của shaping: lấy buổi grilling này và ghi lại mọi điều đã quyết. Anh và agent trích ra một glossary các thuật ngữ dùng chung để sau này tham chiếu, rồi tạo một spec. Anh mở Linear, vào project Praxis Agent CRM mà anh tạo để theo dõi việc này. Anh xác nhận là đúng với cách anh hiểu, và dặn nó commit glossary cùng phần domain modeling; nó làm theo (demo trong video đăng ngày 29/10/2026).

Tiếp theo nó nạp skill spec writer của Damian và viết spec lên Linear. Anh kể skill spec writer của anh lấy cảm hứng từ skill to-spec của Matt Pocock, và tạo một spec trên Linear. Đó là một trong những khác biệt chính giữa bản của anh và bản của Matt, cùng vài điểm khác. Trong Linear, spec là một document, có thể gắn vào project, initiative, issue và những thứ tương tự. Nó giữ phần nền móng của toàn bộ thứ đang build (theo video đăng ngày 29/10/2026).

7. Rules có ID, issue writer, và lần chuyển từ Next.js sang Rails

Spec có một phần rules, hay requirements. Một số rule đã bị retired, và Damian nói sẽ quay lại chuyện đó sau. Có những rule như: tài khoản Slack của một user lấy từ việc liên kết tài khoản Slack đã có sẵn trong Praxis. Tất cả các rule này về cơ bản được trích ra từ những gì đang build, hay từ những gì đã đi qua trong buổi grilling, để gói mọi câu trả lời và quy tắc về từng mảnh của thứ đang build. Chúng nằm đó để tham chiếu bất cứ khi nào cần, cả khi build lẫn trong các issue Linear (demo trong video đăng ngày 29/10/2026).

Các rule có chữ cái kèm số như R19 là ID của rule, để có thể tham chiếu bên trong các issue Linear. Xong phần spec, agent chạy skill issue writer. Mở phần issues ra là thấy tất cả các issue được trích cho phần việc, mỗi mảnh một issue nhỏ, chi tiết. Từ đó có thể giao cho một agent: mọi phần việc đã được trích ra và sẵn sàng để các agent nhận làm (demo trong video đăng ngày 29/10/2026).

Rồi "Damian của tương lai" chen vào: sau khi đã làm buổi grilling và shape xong phần việc này, anh đã làm lại cách xây nền của PraxisAgent. Ban đầu nó là một ứng dụng TypeScript dùng Next.js, nhưng sau đó anh chuyển nó về Ruby on Rails và build lại theo hướng đó. Vì vậy spec phải sửa lại một chút. Nhưng vì lúc trước không đi quá sâu vào chi tiết implementation kỹ thuật, phần lớn nội dung vẫn giữ lại được.

Theo Damian (video đăng ngày 29/10/2026), đó là một lợi ích của loại spec này: nó không đi vào planning hay chi tiết implementation quá mức, mà nói về kết quả cần đạt, gần giống user story. Anh đã lấy spec và các issue, đi qua gần như một buổi grilling nhỏ sau khi chuyển sang Rails, và agent cập nhật spec cùng mọi thứ trên đường đi. Giờ thì đã sẵn sàng nhận phần việc và giao xuống cho các agent.

8. Xoá context, Opus 5.5 và advisor tool

Damian xoá session để context window trống trở lại. Anh đang dùng Claude Code với Opus 5.5 (video đăng ngày 29/10/2026). Sau khi clear context, anh đưa lại spec trên Linear một lần nữa để nó có lại context đó, và nhờ nó giúp khởi động phần việc. Prompt trên màn hình bảo nó xem lại spec trong document Linear (kèm link), rồi viết tiếp: "The project has the issues broken up as well. Review those and identify the right order to begin the work. Do not start implementing anything yet." Ý anh là để nó dùng spec và các issue Linear để nắm context của thứ sắp build trước khi bắt đầu implement.

Trên màn hình hiện dòng "Advising using Opus 5.5". Damian giải thích: một trong những feature gần đây của Claude Code là advisor mode (theo video đăng ngày 29/10/2026). Bạn bật nó lên và chọn một model khác để làm advisor. Ví dụ đôi khi bạn có thể ghép một agent implementation chạy Sonnet với một agent Opus 5.5 làm advisor. Về cơ bản, Claude Code tự quyết khi nào chuyển sang advisor để giúp nó quyết định hoặc tìm câu trả lời trước khi đi tiếp, mà người dùng không phải can thiệp.

Anh nói đây là feature mới, và anh nghĩ lúc quay nó vẫn ở dạng beta mà bạn tự chọn bật lên. Anh đã dùng và khá thích, nó chạy khá tốt (theo video đăng ngày 29/10/2026). Trang docs của Claude Code về advisor tool (đọc ngày 30/10/2026) ghi advisor tool đang ở dạng experimental, cần Anthropic API, và có ba cách bật: lệnh /advisor, setting advisorModel, hoặc flag --advisor.

9. Thứ tự làm việc, pstack và poteto mode

Agent đọc hết spec và 13 issue, đối chiếu với code hiện tại, và báo chưa có gì được implement, đúng hoàn toàn. Nó đưa một kế hoạch tấn công (demo trong video đăng ngày 29/10/2026). Bắt đầu song song: PRX-582, biến catalog clients thành Companies ở /companies, ticket kỹ thuật duy nhất không bị gì chặn; và PRX-583, export workspace Attio. Damian nói PRX-583 là việc thủ công của anh, và anh sẽ bảo nó khởi động phần đó. Phần của anh sẽ chặn bước sau, vì tiếp theo là PRX-584: thêm các CRM record và một lần chạy thử (dry run) import Attio. Ticket này thêm mọi record mới, people, opportunities, notes và các thứ khác, cộng với importer chạy dry run.

Giờ anh để nó điều phối (orchestrate) phần việc này. Việc đầu tiên là dùng pstack ở poteto mode. Damian giới thiệu: pstack là của Lauren Tan, còn được biết đến với tên poteto. Đó là một bộ skill và một plugin chị làm riêng cho Cursor, nhưng dùng được với các agent khác, về cơ bản đóng gói nhiều thực hành của chị với tư cách một principal software engineer vào trong coding agent (theo video đăng ngày 29/10/2026). Theo Damian, nó cho phép bạn giao một bài toán khó cho agent và để agent tự chạy, tự "nấu" trong lúc implement.

Cách nó chạy: bạn đặt nó vào poteto mode, chế độ mà nó nhận diện phần việc trước mặt rồi cho chạy qua một trong cái mà chị gọi là 23 playbook khác nhau (theo video đăng ngày 29/10/2026; README của pstack, đọc ngày 30/10/2026, cũng ghi "twenty-three playbooks"). Damian mở rộng danh sách ra và đọc vài ví dụ:

• investigation: một câu hỏi chỉ đọc. Nó chạy thế nào? Vì sao được build theo cách này? Mình có chắc không? Tức là chế độ cho lúc bạn hỏi một câu, chỉ cần câu trả lời, không cần build gì (video đăng ngày 29/10/2026).
• bug fix: tái hiện một lỗi, tìm root cause, sửa kèm bằng chứng lúc chạy (video đăng ngày 29/10/2026).
• perf: lần theo một sự chậm đã đo được và cải thiện nó so với baseline (video đăng ngày 29/10/2026).
• hillclimb: cải thiện một metric một cách bền bỉ và khoa học so với một mục tiêu, lặp các giả thuyết với số đo trước và sau, mỗi lần thắng được chấp nhận là một commit. Damian nói nó hơi giống auto research (video đăng ngày 29/10/2026).
• refactoring: thay đổi cấu trúc hay hình dạng mà giữ nguyên hành vi (video đăng ngày 29/10/2026).
• prototype: một bản phác dùng xong bỏ, để ra một quyết định design hay hành vi với chi phí thấp, hoặc chốt một ngã rẽ thực nghiệm bằng cách quan sát (video đăng ngày 29/10/2026).
• orchestrate: một project dài hạn giao cho một chat điều phối duy nhất, kéo dài nhiều ngày, nhiều stacked PR, cả đội agent. Damian nói đây chính là thứ anh sắp dùng (video đăng ngày 29/10/2026).
• autopilot-full: đưa các PR độc lập tới merged, mỗi PR một chủ; một swarm verify mỗi head đã sẵn sàng, và mỗi thay đổi sau đó trên patch được kiểm lại từ đầu (video đăng ngày 29/10/2026).

10. Các skill trong pstack, lệnh khởi động và verification

Ngoài playbook, trong pstack còn nhiều skill mà Damian thấy rất hữu ích (theo video đăng ngày 29/10/2026). Có /why, để giải thích vì sao một thứ được build theo cách đó: nó đi qua các MCP, tra các cuộc hội thoại cũ, kiểm source control, issue tracker và những nguồn tương tự để hiểu một mảnh code. Có /recall, mà anh thấy cực kỳ hữu ích khi bạn đang làm dở, bỏ xuống, rồi không chắc mình đang ở đâu: chạy /recall để bắt kịp và hiểu "à, mình dừng ở đây". Có /architect, khi bạn sắp viết code và muốn nó giúp định hình code sẽ trông ra sao.

Đó đều là những skill bạn gọi tay được. Damian nói anh không hay gọi tay nhiều; thỉnh thoảng anh gọi /recall và /why, nhưng phần lớn chúng được gọi ngầm bên dưới poteto mode khi nó cần (theo video đăng ngày 29/10/2026).

Anh gọi pstack với /pstack:poteto-mode. Như đã nói, đây là plugin thiết kế cho Cursor, nhưng chính plugin đó cũng có bản cho Claude Code trong cùng repo. Theo Damian, còn có vài bản fork mã nguồn mở theo dõi plugin của chị và chạy được với Pi, Codex, Claude Code và các agent khác (theo video đăng ngày 29/10/2026).

Prompt anh gõ (demo trong video đăng ngày 29/10/2026), chép từ màn hình:

/pstack:poteto-mode I wannt you to orchestrate this work for me, delegating to other agents to do the job. Open PRs as you deem fit. Use stacked-prs to stack the work in github to make it easier to review. Ensure each PR is babysat to make sure it's ready to be merged. Verify we uselogical commits in our work. Start the first batch. Use either Sonnet 5.5 as the agent for implementation..

Lúc gõ, anh định thêm một lựa chọn khác cho agent implementation nhưng rồi thôi, giữ như vậy, và nói sẽ cho xem sau một ví dụ dùng loại agent khác. Anh bấm Enter, rồi bấm Escape ngay để thêm một ý: mỗi agent implementation cũng nên dùng poteto mode trong lúc implement. Đó là một lời làm rõ để bảo đảm các subagent cũng chạy poteto mode ở phía implementation (demo trong video đăng ngày 29/10/2026).

Đó là cách Damian khởi động một loạt việc. Và vì đang dùng Claude Code, mà theo anh Claude Code có khả năng giao việc giữa nhiều agent khá tốt (video đăng ngày 29/10/2026), nên lúc này anh không dùng Herdr cho phần multi-agent. Herdr sẽ vào cuộc khi anh muốn chạy những loại agent khác, như Pi hay Codex, trong phần việc của mình, và anh sẽ cho xem một ví dụ cùng lý do sau. Phần này sẽ chạy một lúc, đi qua code và cố build một thứ gì đó.

Trong lúc đó, anh nói về một điểm quan trọng: phải bảo đảm agent có cách verify công việc của mình. Trong pstack có skill create verification, và thực ra có vài skill: create verification skill, maintain verification skill, create formal verification skill và maintain formal verification skill. Theo Damian (video đăng ngày 29/10/2026), đó là những cách cho agent tự verify công việc qua nhiều đường: có thể là test, có thể là dùng browser đi end-to-end tương tác với ứng dụng để thật sự kiểm kết quả.

Anh giải thích vì sao: đây là một trong những cách quan trọng nhất để có một vòng lặp thật sự agent-native, nơi agent chạy được một thời gian không cần anh mà vẫn hoàn thành việc. Agent cần một cách để hiểu: mình đã hoàn thành việc mình đặt ra chưa? Và nó không biết được điều đó nếu không có verification. Skill create verification có thể tạo sẵn phần nền đó để nó có khi cần (theo video đăng ngày 29/10/2026).

11. Agent hỏi lại, việc export và agent con trong Claude Code

Quay lại terminal, agent báo nó tìm thấy một PR đang mở implement PRX-610, PR này mâu thuẫn với cách spec CRM xử lý engagements, và PRX-582 sửa cùng những file đó (demo trong video đăng ngày 29/10/2026). Damian đồng ý đó là một điểm hay. Agent đề xuất cho PR #155 vào trước, PRX-582 stack lên trên nó và đổi tên client thành company, mang theo lead và lifecycle; ADR-003 bị thay thế, PRX-590 bị huỷ, và opportunity chỉ gắn với một company; nó sẽ cập nhật spec. Damian chưa chắc, nên anh bảo nó giải thích kỹ hơn phương án một trong thực tế nghĩa là gì.

Agent còn hỏi về PRX-583 (demo trong video đăng ngày 29/10/2026): việc export được giao cho anh, và fixture của exporter phải khớp với hình dạng dữ liệu export; nó có nên tự chạy export qua Attio MCP vào một thư mục riêng tư nằm ngoài repo không? Damian trả lời: có, anh thích nó tự làm để anh khỏi phải làm. Anh nhắc lại: cho agent công cụ và context cần thiết để đẩy việc đi với ít sự tham gia nhất của anh là chìa khoá.

Agent báo đang bắt đầu export Attio. Damian làm rõ thêm: phải giao việc export cho một agent khác. Theo anh, đôi khi nó không giao việc đi, và anh phải nhắc lại trên đường đi (theo video đăng ngày 29/10/2026). Agent trả lời đã hiểu: agent export sẽ lo mọi thứ về export, kể cả tìm quyền truy cập Attio; nó chỉ ghi lại điểm chặn và viết brief. Rồi nó chuẩn bị một brief dạng Markdown để chuyển cho agent kia làm (demo trong video đăng ngày 29/10/2026).

Trên màn hình thấy agent mới được tạo để nhận việc export. Ở dưới cùng là trải nghiệm mới: agent chính, cái anh đang trò chuyện, và anh có thể nhảy vào agent export Attio, một trong những agent export đang chạy việc đó. Damian nói đây là ý anh khi bảo Claude Code có giao diện và cách implement riêng để một agent giao việc cho các agent khác; mỗi agent có thể có worktree riêng để làm việc trong đó (theo video đăng ngày 29/10/2026).

Quay lại câu anh hỏi, agent giải thích (demo trong video đăng ngày 29/10/2026): phương án một, cho #155 vào rồi chỉnh CRM theo nó, trong thực tế nghĩa là về data model, mỗi tổ chức có một record và không có bảng engagement. Damian xác nhận đúng vậy. Client trở thành company và mang hai nhóm trường: từ #155 là lead ID, lifecycle (planned, active, completed) và Notion page ID; từ spec CRM là owner, relationship status, kind và domains. Chi tiết delivery nằm ngay trên company.

12. Gộp hai trường status, và duyệt lệnh bằng /permissions

Agent nêu hai chỗ chồng lấn anh cần chốt (demo trong video đăng ngày 29/10/2026). Lifecycle và relationship status mô tả gần như cùng một thứ: với client, active gần với client, completed gần với past. Lifecycle cũng chẳng có nghĩa gì với một prospect, partner hay vendor. Đề xuất của nó là một danh sách status duy nhất bao cả hai, ví dụ prospect, onboarding, active, dormant, past, do not pursue. Theo nó, hai trường có thể mâu thuẫn nhau thì tệ hơn. Damian đồng ý.

Nó cũng liệt kê những gì đổi trong spec: R6 bị bỏ, gồm engagements, kênh Slack và meetings; contacts vốn đã trỏ về client. R15 biến mất, và opportunity chỉ thuộc về một company (demo trong video đăng ngày 29/10/2026). Damian thấy hợp lý với mọi deal, và anh đồng ý với tất cả.

Agent hỏi về một script kiểm quyền mà anh tự chạy; anh trả lời có và đi tiếp. Rồi chuyện permissions: một trong các agent đã cố chạy một thứ và bị auto classifier từ chối. Damian chạy /permissions để xem những gì vừa bị từ chối và duyệt chúng. Duyệt xong anh bấm Escape rồi Enter, và ghi chú lại cho agent rằng anh đã duyệt qua /permissions (demo trong video đăng ngày 29/10/2026).

13. Plugin heads up, PR docs và autonomous run

Damian giới thiệu một plugin anh mới bắt đầu dùng gần đây: nó hiện một "heads up" bên trong Claude Code, và theo anh thì cực kỳ hữu ích (video đăng ngày 29/10/2026). Về cơ bản, nó có một agent chạy nền, giống như theo dõi cuộc hội thoại. Hội thoại càng dài thì càng nhiều thứ bật lên và dễ lạc mất giữa chừng. Plugin này nhận diện những điều có thể quan trọng đã bị trôi đi trong hội thoại và làm nổi chúng lên, ghim cố định ở dưới cùng dưới dạng heads up.

Heads up lúc đó ghi: danh sách status ví dụ của agent chính, prospect, onboarding, active, dormant, past, do not pursue, đang được ghi vào spec CRM như giá trị cuối cùng. Anh có thể chọn learn more, "tôi biết rồi", hoặc dismiss. Anh chọn learn more, và nó giải thích (demo trong video đăng ngày 29/10/2026): các giá trị status của CRM đang được chốt; anh đã chọn gộp lifecycle của #155 với relationship status của spec thành một danh sách; các giá trị agent chính đưa ra chỉ là ví dụ; agent chính đang ghi đúng danh sách đó vào spec Linear; mọi worker sau đó sẽ build từ các giá trị này. Giá trị lifecycle cũ chuyển như sau: planned thành onboarding, active giữ active, completed thành past. "Client" không còn là một giá trị status, giờ nó nghĩa là một company đang onboarding hoặc active. Hãy kiểm danh sách trong spec đã cập nhật trước khi PRX-584 bắt đầu, vì đổi sau này nghĩa là thêm một migration.

Theo Damian (video đăng ngày 29/10/2026), plugin chỉ nhắc lại rằng những gì vừa quyết có hệ quả, và làm nổi chúng lên cho anh. Anh có thể chọn một: understood, hai: chat trong session chính, hoặc không: dismiss. Anh chọn understood, chấp nhận điều đó dựa trên những gì đã làm.

Việc export bị chặn, và anh sẽ thiết lập phần đó. Trong lúc đó, agent kia đang chạy một lượt docs realign để cập nhật docs theo những gì vừa bàn và những thay đổi nó thấy trong một ticket Linear khác đang làm dở. Rồi anh thêm key đó. Agent đã mở PR cho phần cập nhật docs, chỉ đổi docs, gồm cả glossary vừa đưa vào; khá đơn giản (demo trong video đăng ngày 29/10/2026).

Khi CI và phần review của factory chạy xong thì có thể merge. Praxis Factory đang xem PR đó. Agent đang làm phần export. Damian merge PR docs, quay lại, và agent nói trước khi sang phần kế tiếp thì #155 cần được merge. Anh hỏi nó có thể stack phần việc lên trên PR đó luôn thay vì phải chờ không. Theo anh, đó lại là một lợi thế của stacked PR khi làm việc kiểu này (video đăng ngày 29/10/2026). Agent khởi động việc cho một agent khác build lên trên PR kia (demo trong video đăng ngày 29/10/2026).

Anh cũng bảo nó chạy phần điều phối này như một autonomous run, nhắc lại autonomous run là tên một playbook trong pstack. Trên màn hình thấy skill loop được nạp; anh nghĩ đó là một skill khác, nhưng đằng nào thì nó cũng báo (demo trong video đăng ngày 29/10/2026): phần điều phối giờ chạy theo nhịp riêng của nó; nó sẽ chạy tiếp cho tới khi mọi ticket CRM từ PRX-582 tới PRX-594, trừ ticket đã huỷ, đều có một PR mở trong cùng một stack, mỗi PR sẵn sàng merge và đã verify ở commit hiện tại. Hai ticket ở lại với anh: lần import production và việc huỷ Attio, điều mà anh thấy hoàn toàn hợp lý. Nó sẽ tiếp tục chạy ở chế độ auto đó; anh để vòng lặp chạy và sẽ quay lại xem kết quả.

14. Herdr, Pi và model local trên DGX Spark

Phần việc đang chạy tự động, nhưng Damian đưa thêm một chỉ dẫn: những lát việc nhỏ hơn mà đã rõ ràng thì có thể giao cho một Herdr worktree và một Herdr Pi agent dùng Qwen 3.8 Flash-Next (demo trong video đăng ngày 29/10/2026). Như vậy, thay vì dùng subagent của Claude Code, nó sẽ dùng Herdr để tạo Herdr worktree và điều khiển các Herdr agent.

Theo Damian (video đăng ngày 29/10/2026), cách này cho phép nhiều loại coding agent làm việc cùng nhau rất dễ: tất cả chạy trong Herdr, và nếu có skill Herdr thì chúng nói qua nói lại với nhau được. Lý do anh làm vậy: anh trỏ Pi vào model local chạy trên chiếc DGX Spark đặt ngay sau lưng anh, cho những phần việc nhỏ. Những thứ đã có spec khá rõ, mình hiểu rõ chúng trông ra sao và không cần nghiên cứu nhiều, thì giao cho agent đó, để giảm tải cho gói subscription Claude Code của anh mà dùng máy local thay vào.

Quay lại sau một lúc, đã có một phần việc được quyết định giao cho một Pi agent. Trên màn hình thấy nó dùng các lệnh Herdr để khởi động Pi agent trong Herdr và tạo một worktree. Bên trái có PraxisAgent và vài worktree, và PRX-584 là phần nó quyết định giao cho Qwen 3.8 Flash-Next (demo trong video đăng ngày 29/10/2026). Bấm vào đó, Damian kể lại những gì lẽ ra đã thấy: Herdr worktree được tạo trong terminal, Pi agent được gọi qua CLI và nhận việc, và có thể thấy lệnh hay prompt gửi cho agent. Prompt đó bảo agent đọc file task trong thư mục brief của orchestrate cho PRX-584 và làm đúng như vậy.

Tức là Claude ghép một prompt để chuyển cho agent này, ghi nó ra một file, rồi chuyển prompt đó sang Pi agent để thực thi (demo trong video đăng ngày 29/10/2026). Giờ có thể thấy Claude Code đang quản lý một agent không phải Claude. Theo Damian, đây là nơi sức mạnh của một thứ như Herdr thật sự lộ ra: điều phối nhiều loại agent khác nhau. Anh giao được việc cho model local trên DGX Spark thay vì dùng subscription. Việc này chạy tiếp, và agent chính tiếp tục theo dõi agent kia như thể đó là một Claude agent, giống cách nó quản lý các agent khác; nó dùng Herdr để qua lại hội thoại và quản lý những phần việc đó (demo trong video đăng ngày 29/10/2026).

15. Một ngày sau: stack 12 PR và conventional commits

Khoảng một ngày sau khi dispatch stack sang pstack ở poteto mode, đã có một loạt PR chờ review. Có một stack PR lớn được tạo ra, sâu khoảng 12 PR; Damian đã merge một cái, và có thể thấy agent đã làm được những gì (demo trong video đăng ngày 29/10/2026). Anh mở một PR đang ở trạng thái changes requested, đó là PR thứ hai trong stack, và chỉ cho ai chưa quen cách GitHub hiển thị stack.

Từ đây Damian nói về phần còn lại của build loop: chu trình review và chu trình ship, gộp chung khi bàn. Điểm đầu tiên là tiêu đề PR và các commit bên trong. Tiêu đề là feat(crm): add CRM records, relationship status, and provenance. Bên trong có 10 commit, tất cả theo cùng một kiểu: một cái cho test, một cái cho fix, một cái khác cho tests (demo trong video đăng ngày 29/10/2026).

Cách đặt đó theo một chuẩn gọi là conventional commits. Damian giải thích: conventional commits là một đặc tả để viết commit message mà cả người lẫn máy đọc được, về cơ bản là một style guide cụ thể mà commit nên theo. Nó cũng đi rất hợp với SemVer nếu bạn theo SemVer, chẳng hạn cho một package hay bất kỳ kiểu đánh version nào, để nhận ra loại thay đổi nào đang đi vào. Trang conventionalcommits.org (bản 1.0.0, đọc ngày 30/10/2026) ghi dạng <type>[optional scope]: <description>, với fix tương ứng PATCH và feat tương ứng MINOR trong Semantic Versioning.

Anh đã viết một agent skill tên conventional commits, chỉ dẫn agent dùng pattern này mỗi khi build. Đó là một mảnh khác trong stack của coding loop của anh, cho commit message (theo video đăng ngày 29/10/2026).

16. Review sáu lens, conventional comments và adversarial check

Tiếp theo là phía review, có hai phần. Một, các review đi qua software factory của Damian, Praxis Factory. Theo anh (video đăng ngày 29/10/2026), lúc quay Praxis Factory chuyên làm code review, nhưng theo cùng nguyên tắc với agent skill anh viết tên Team Code Review. Team Code Review nằm trong bộ agent skill của anh và đặt ra một pattern để làm code review.

Cuộn xuống PR, thấy review từ factory: nó giữ lại một finding, finding đó là blocking, và nó chạy qua nhiều lens (demo trong video đăng ngày 29/10/2026). Mỗi review có một agent độc lập xem phần architecture, readability, testing, maintainability, security và documentation. Tức là khoảng sáu agent chạy, mỗi agent review độc lập cho đúng trọng tâm của nó.

Với code review dựa trên agent, theo Damian (video đăng ngày 29/10/2026) một trong những điều quan trọng nhất là có context window mới tinh khi review, vì bạn không muốn context window đã đầy và thiên vị theo những thay đổi chính bạn vừa làm. Nên lúc nào cũng nên dựng code review thành một agent riêng, và anh luôn làm vậy khi review. Anh cũng có các agent lens khác nhau để mỗi agent tập trung vào một kiểu review. Sau đó một supervisor agent xem lại review của các agent kia và về cơ bản quyết định những finding nào thật sự áp dụng được; cái nào không thì có thể bị gạt đi, còn lại thì giữ. Vì vậy mới ghi "1 kept". Cũng thấy có vài lần retry.

Trong đó còn có một convention khác: dòng issue (blocking): keep legacy ownerless companies editable during the compatibility window. Đó là theo một chuẩn gọi là conventional comments. Damian giải thích nó giống conventional commits: một đặc tả để cấu trúc comment trên PR sao cho cả người lẫn máy đọc được. Anh theo chuẩn đó, và có thêm một skill nữa để tối ưu cách comment review được đặt lên PR (theo video đăng ngày 29/10/2026). Trang conventionalcomments.org (đọc ngày 30/10/2026) ghi dạng <label> [decorations]: <subject> kèm phần discussion.

Điều nữa là trong vòng lặp pstack đang chạy, nó nhận ra feedback đã về, tức là review requested changes có blocking này, rồi tự nhận việc, sửa và force push lên nhánh. Factory thấy thay đổi đó, review lại và lần này approve (demo trong video đăng ngày 29/10/2026).

Mảnh cuối là adversarial check ở dưới cùng. Theo Damian (video đăng ngày 29/10/2026), nếu một review không có finding nào, nó làm một lượt kiểm cuối để soát lại mọi thứ đã review, dựng một lập luận đối nghịch cho một review lẽ ra nên được gửi, rồi thả kết quả đó vào đây. Tất cả các PR đều đi qua quy trình này. Sau đó có thêm thay đổi đi vào stack, rồi lại có một PR review khác với các thay đổi blocking cần xử lý.

Damian tóm lại: đó là review sáu lens, lúc quay do software factory đảm nhận; pstack cũng tự làm code review trong quá trình lặp của nó (theo video đăng ngày 29/10/2026). Nếu bạn muốn chạy kiểu review sáu lens tương tự, anh có một agent skill tên Team Code Review, và một bản riêng tên Herdr Team Code Review. Theo anh, khi chạy, bản Herdr tự spawn một Herdr agent mới rồi bảo nó chạy Team Code Review trên các thay đổi trong nhánh, hoặc trên PR nếu bạn đưa PR thay vào. Bằng cách đó bảo đảm có context window mới khi review.

17. Codebase chính là context: codebase readiness và agent ready

Theo Damian (video đăng ngày 29/10/2026), một trong những phần quan trọng nhất của tất cả chuyện này là context, và một trong những phần quan trọng nhất của context lại chính là codebase. Anh nói Lauren Tan, tức poteto, cũng nói về điều này khá nhiều khi kể về pstack và workflow của chị. Lý do: agent sẽ bắt chước các pattern có sẵn trong codebase, sẽ xem toàn bộ nội dung trong codebase để quyết định nên làm thế nào. Vì vậy rất quan trọng là codebase phải sẵn sàng cho một agent làm việc bên trong.

Anh có một agent skill tên codebase readiness. Nếu bạn không chắc codebase của mình đang ở tình trạng nào, chạy codebase readiness và nó sẽ đánh giá theo tám chiều để xác định trạng thái codebase (theo video đăng ngày 29/10/2026): test foundation, architectural clarity, type safety, feedback loops, documentation as code, dependency health, development environment và code consistency. Nó xem qua tất cả, đánh giá, viết báo cáo và cho điểm từ 0 tới 100 để bạn hiểu codebase của mình đang ở mức nào cho agent làm việc.

Thang đó trải từ 100, nghĩa là bạn có thể để agent tự đi làm việc của nó với rất ít hướng dẫn, cho tới phía thấp hơn, nơi bạn có thể đã sẵn sàng làm việc với một coding agent trong codebase nhưng có lẽ cần cầm tay nó nhiều hơn một chút. Theo Damian (video đăng ngày 29/10/2026), skill này cho bạn số đo và cái hiểu đó về codebase dựa trên bộ tiêu chí (rubric) kia.

Anh còn có một skill khác tên agent ready. Theo anh (video đăng ngày 29/10/2026), nó lấy báo cáo đó nếu bạn đã chạy, hoặc tự làm một lượt đánh giá nhanh hơn, rồi giúp bạn dựng một codebase agent-ready, hoặc ít nhất là phần nền của nó. Nghĩa là thêm documentation, thêm một file AGENTS.md cho đúng, thêm ADR, và kiểm xem bạn có linter chưa, có những thứ như vậy chưa, để bảo đảm codebase sẵn sàng và có guardrail. Vì như anh đã nói ở trên, rất quan trọng là agent phải verify được công việc trong lúc làm.

18. Railbed và RubyCritic làm quality gate

Cuối cùng, nếu bạn làm Ruby on Rails và đang thêm một feature, hoặc bắt đầu một repo mới, Damian nhắc tới Railbed: một project mã nguồn mở do anh tạo, một template cho ứng dụng Ruby on Rails để có ngay một codebase agent-ready (theo video đăng ngày 29/10/2026). Anh nói nó rất "opinionated". Theo lời anh trong video, nó dùng Tailwind CSS, Postgres và ViewComponent; có thiết lập riêng cho RSpec và FactoryBot với shoulda matchers; có WebMock; có Bullet để phát hiện N+1 cho agent tìm ra; có Sorbet với strict mode ngay từ đầu; có cấu hình riêng cho RuboCop và các thứ tương tự.

Nó cũng có strong migrations để agent được cảnh báo nếu định làm điều gì không ổn trong migration, và có Brakeman. Nó có sẵn các skill anh đã nhắc: conventional commits, conventional comments, một code review kiểu team hiểu Rails, và những thứ tương tự. Nó còn có vài custom RuboCop cop cho một số finding để dẫn agent đi đúng hướng (theo video đăng ngày 29/10/2026).

Một trong những phần quan trọng nhất mà Damian thấy là RubyCritic. RubyCritic làm phân tích tĩnh codebase để hiểu chất lượng code. Theo anh (video đăng ngày 29/10/2026), nó rất hữu ích trong việc bảo đảm agent thật sự hướng tới việc chẻ code thành một cấu trúc có tổ chức, theo các nguyên tắc chuẩn của lập trình hướng đối tượng, và không tạo ra những class khổng lồ khi build. Ngay từ đầu, Railbed đặt điểm tối thiểu 95 cho mọi thứ đi qua; README trên màn hình ghi "RubyCritic with a 95/100 aggregate minimum score and a changed-code complexity gate". README của RubyCritic (đọc ngày 30/10/2026) mô tả nó là một gem bọc các gem phân tích tĩnh như Reek, Flay và Flog để tạo báo cáo chất lượng cho code Ruby.

Nhờ vậy, theo Damian, agent viết code, nhận feedback nhanh từ RubyCritic và cải thiện code ngay trong lúc làm, thay vì bạn phải tự canh tất cả. Anh nói điều này rất tốt để giữ độ phức tạp trong tầm kiểm soát khi một codebase lớn dần: agent làm codebase lớn lên, và nếu không dập những pattern xấu từ sớm thì chúng sẽ được làm theo khi codebase lớn lên, và càng ngày càng khó bảo trì. Đó là điều Railbed cố tránh (theo video đăng ngày 29/10/2026).

Damian cảm ơn người xem.