Workflow ba bước của Cody để agent build một MVP

1. Ba project, cùng một workflow cho MVP

Cody Seibert mở đầu: nếu bạn đang build một ứng dụng hoàn toàn mới, anh sẽ cho bạn xem một trong những workflow anh hay dùng khi build một MVP. Câu hỏi đặt ra là: minimum viable product ở đây là gì, và liệu bạn có lên được toàn bộ plan trước cả khi gửi prompt đầu tiên hay không (theo video đăng ngày 28/06/2026).

Anh đã áp dụng workflow này cho project Mission Control của mình lúc mới tạo nó. Anh cũng áp dụng nó cho Sketch Lab, một trình chỉnh sửa graph 3D mà anh dùng để dạy các paradigm khác nhau. Và anh đang build một thứ tên là GameForge: một ứng dụng vibe coding để các con anh build game, rồi anh chơi cùng các con. Anh còn một loạt project khác nữa, và với tất cả các project này anh đều theo về cơ bản cùng một workflow (theo lời Cody trong video đăng ngày 28/06/2026).

Anh nói thẳng rằng anh không thích thổi phồng workflow, skill hay bất cứ thứ gì. Có lẽ có rất nhiều workflow khác bạn có thể dùng, rất giống thế này, và có thể bạn sẽ có kết quả tốt hơn với chúng. Anh chỉ đang cho bạn xem cách anh thích làm, và anh đã có kết quả tốt với nó, đi từ lúc chưa có dòng code nào cho tới MVP nhỏ đầu tiên (theo video đăng ngày 28/06/2026).

2. Bước một: trò chuyện với agent và hỏi thật nhiều

Theo Cody (video đăng ngày 28/06/2026), bước một là bước quan trọng nhất, bỏ xa các bước khác: thật sự ngồi xuống và trò chuyện với agent của bạn.

Anh thường mở một phiên ChatGPT, trước hết trình bày ý tưởng: anh muốn build cái gì, nó cần làm gì, các tính năng cốt lõi là gì. Rồi anh trao đổi qua lại với nó trong một thời gian rất dài (cách làm anh kể trong video đăng ngày 28/06/2026).

Prompt mở đầu của phiên ChatGPT cho GameForge, như trên màn hình (video đăng ngày 28/06/2026):

Design me a lovable type of clone but for kids wanting to build games and share them for others to play, html5 games using three.js or pixijs for 2d games, help me ideate.  It needs to be a chat interface that kids can use, has push to production ability, can host their games using cloudflare durable objects with game rooms if they choose a multiplayer game, live reload dev environment with iframe live reload with previews, some type of source control, and usage tracking.

Cody kể rằng về cơ bản anh lấp đầy cả context window bằng câu hỏi. Kiểu như: nếu tôi muốn đạt được điều này thì về mặt kỹ thuật tôi nên dùng gì? Có nên dùng R2, Durable Objects không? Có nên dùng Postgres không? Nên dùng database nào? Nên dùng hosting platform nào? User experience nên thế nào nếu anh nhắm tới việc để trẻ em vibe code ứng dụng? Một cửa sổ chat với khung preview bên phải, kiểu như Lovable, có phải là hướng nên đi không? Và vân vân (theo video đăng ngày 28/06/2026).

3. Điểm dừng: model đã hiểu bạn muốn gì

Sau đó bạn sẽ có rất nhiều thứ được nạp vào context. Tới một lúc nào đó bạn sẽ tới điểm dừng. Sau khi đã đọc hết các gợi ý, và đã prompt cho nó những gợi ý của chính bạn cùng hướng bạn muốn đi, model thường hiểu rất rõ bạn muốn build cái gì và implement nó ra sao. Bạn bỏ ra càng nhiều thời gian cho phần này, thông tin bạn đưa được càng tốt, và plan của bạn càng tốt khi bắt tay build project ban đầu đó (theo Cody, video đăng ngày 28/06/2026).

4. "Summarize my needs into a .md file"

Ở cuối cùng, sau khi làm hết những việc trên, là phần Cody gọi là cực kỳ quan trọng của phần đầu workflow. Anh gửi câu sau, như trên màn hình (video đăng ngày 28/06/2026):

Summarize my needs into a .md file with phases and steps I can follow and check off

Lý do anh viết "summarize my needs into an MD file" là anh muốn nó đi lại toàn bộ cuộc trò chuyện giữa anh và nó, mổ xẻ ra để lấy thông tin cốt lõi. Vì trong lúc nói chuyện với agent sẽ có những thứ không quan trọng với MVP của bạn, và cũng sẽ có rất nhiều thứ quan trọng. Anh muốn nó tìm ra những thứ quan trọng. Rồi anh cũng cần nó dựng một plan chia theo phase (theo video đăng ngày 28/06/2026).

Lý do có plan chia phase, theo Cody (video đăng ngày 28/06/2026), là để anh đưa nó cho Claude Code hoặc Codex, dùng lệnh /goal để agent cứ thế build ra, phần này anh cho xem ngay sau đó. Cuộn xuống, bạn sẽ thấy tài liệu có context ban đầu của project và các mục tiêu chính. Cuộn tiếp sẽ thấy phần phased development. Đây là phần quan trọng mà plan của bạn cần có: phased development kèm checklist.

5. Dán plan vào một file và để agent chạy từng bước

Khi đã có tài liệu này, Cody về cơ bản copy toàn bộ và có thể tạo một file plan. Anh mở một terminal mới trong ứng dụng Mission Control của mình để cho xem file plan: anh đã dán nguyên plan vào đó, và có thể thấy nó đã được làm một phần. Anh có một agent đang đi qua từng mục một, vừa build vừa test để chắc nó đang build đúng thứ cần build (demo trong video đăng ngày 28/06/2026).

Đó là bước một trong workflow của anh. Lời khuyên của Cody (video đăng ngày 28/06/2026): bạn nên dành 30 phút tới một tiếng, hai tiếng, để thật sự chắc rằng mình đã hỏi đủ những câu cần hỏi, chắc rằng nó hiểu mọi thứ bạn cần ở project này, để nó có thể dựng ra một plan thật tốt cho bạn đi theo.

6. Bước hai: model quan trọng hơn agent

Với phần thứ hai của workflow, Cody khuyên dùng Claude Code hoặc Codex. Lúc quay video (đăng ngày 28/06/2026), anh đang build toàn bộ ứng dụng này (trên màn hình là project gameforge) bằng Cursor, và về cơ bản dùng lệnh /loop.

Theo anh (video đăng ngày 28/06/2026), bạn dùng agent nào không quan trọng, model mới là thứ quan trọng hơn. Anh đang dùng GPT-5.5, bản 1 triệu token context, mức extra high, và anh cho rằng đây là một model rất tốt để build. Dùng Claude Code cũng là một gợi ý tốt. Một lần nữa, phần quan trọng không hẳn là harness, nhưng bạn cần dùng model tốt nhất hiện có nếu được.

7. Prompt anh dùng để agent đi qua plan

Cody chuyển sang phần mà anh gọi là phần thật sự quan trọng của workflow, và lấy ví dụ cách anh prompt Claude Code để đi qua plan. Anh đọc prompt bằng giọng nói, và trên màn hình prompt hiện ra như sau (video đăng ngày 28/06/2026):

I need you to go through the plan.md file and go through the phases in order. And for every step of the phase, I want you to make sure you do test driven development to verify that you're implementing the step accurately and feel free to actually deploy to a real environment so you can verify that the stuff you're adding in is actually working when it's deployed out. Do not finish this step until it is 100% verified to work.

8. Test-driven development và deploy lên môi trường thật

Theo Cody (video đăng ngày 28/06/2026), nếu nghe kỹ prompt vừa rồi thì phần quan trọng nhất là phần test-driven development. Anh đang nói với agent: bạn cần làm thật kỹ để kiểm chứng, dù là thủ công bằng cách mở browser và bấm qua từng thứ, viết Puppeteer, viết integration test hay unit test, và thật sự deploy những thứ này lên đâu đó.

Anh đã thiết lập sẵn key Cloudflare. Anh có API key trên máy mà agent được quyền dùng, để nó tự đi deploy lên môi trường của anh, rồi tự vào xem (setup anh kể trong video đăng ngày 28/06/2026).

Lý do: khi làm vậy, anh thấy các agent làm kỹ hơn. Chúng không bỏ qua thứ gì, và bắt được cả loạt lỗi trên đường đi. Thêm nữa, nói với nó rằng nó được quyền deploy lên một môi trường thật cũng rất có ích, vì đôi khi nó build ra cả một thứ hoàn chỉnh nhưng khi deploy lên thì hỏng, không chạy, có những phần không được tích hợp đúng (theo trải nghiệm của Cody, video đăng ngày 28/06/2026).

9. Ngồi trông key, rồi để nó chạy càng lâu càng tốt

Khi làm theo cách này, Cody nói bạn cần ngồi đó trông nó một chút, vì bạn phải chắc rằng đã có đúng các key. Có thể bạn cần một OpenAI API key nếu đang build một ứng dụng kiểu AI wrapper. Có thể bạn cần key Cloudflare để nó có quyền tạo R2 bucket, tạo Durable Objects, Cloudflare Workers, vân vân (theo video đăng ngày 28/06/2026).

Còn bước hai trong workflow của anh, về cơ bản, là cứ để nó chạy càng lâu càng tốt, build ra thứ thật (theo video đăng ngày 28/06/2026).

Theo Cody (video đăng ngày 28/06/2026), có vài kỹ thuật bạn có thể dùng, ví dụ một dynamic workflow với một trăm agent để build ứng dụng. Cho nó dùng lệnh /workflow có thể giúp nó chạy nhanh hơn, kỹ hơn, research nhiều hơn, và đốt thật nhiều token để chắc thứ bạn build là tốt. Nhưng theo anh, chỉ một lệnh /goal thôi thật lòng cũng đủ tốt rồi. Bạn có thể thêm một câu như "spin up sub agents when you think it would help make the task faster", để agent biết rằng nó có thể dùng thêm sub-agent nếu việc đó giúp công việc nhanh hơn.

Nhưng tới một lúc bạn phải nhận ra rằng đây không phải một cuộc đua. Cứ để nó build, để nó làm kỹ, vì nếu có quá nhiều thứ cùng làm việc trên codebase một lúc, nó sẽ làm hỏng mọi thứ, và nó sẽ không hiểu hết mọi thứ (lời khuyên của Cody, video đăng ngày 28/06/2026).

10. Loop khoảng một phút, và chuyện chạm limit

Đó là prompt tổng thể anh đã dùng. Như đã nói, khi làm trong Cursor, Cody chỉ dùng một loop khoảng một phút. Rồi anh làm đúng việc đó: tiếp tục đi qua file plan MD, đánh dấu những mục đã xong, làm test-driven development, chắc chắn rằng những thứ được thêm vào deploy đúng. Anh đã thiết lập sẵn đúng các key để nó deploy lên R2. Theo anh, chính kiểu prompt đó là thứ quan trọng cho bước hai (video đăng ngày 28/06/2026).

Làm workflow này thì bạn sẽ chạm limit. Cody kể anh đang dùng gói Claude Code 100 đô một tháng, đã dùng hết phiên hiện tại và sắp chạm trần của tuần (theo video đăng ngày 28/06/2026).

Vậy nên hãy nhớ rằng nếu muốn build một MVP, bạn sẽ đốt rất nhiều token và rất nhiều credit. Hoặc nâng lên gói cao hơn, hoặc cứ năm tiếng quay lại một lần và kick off lại. Khi bạn chạm limit, Claude Code sẽ hỏi bạn có muốn dừng và tạm nghỉ không; bạn trả lời OK, quay lại khi limit được làm mới và gõ "continue", rồi nó sẽ chạy tiếp từ chỗ dừng và tiếp tục implement (theo Cody, video đăng ngày 28/06/2026).

11. Bước ba: tự dùng thử và iterate

Đó là bước một và bước hai trong cách Cody làm workflow này. Theo anh (video đăng ngày 28/06/2026), bước ba mới là phần thật sự khó. Đây là lúc bạn phải mở ứng dụng ra và bắt đầu dùng thử. Ví dụ, anh mở Sketch Lab ngay trong browser.

Đây là lúc bạn phải thật sự chơi với thứ mình đang build, vì có thể bạn sẽ nhận ra rằng những gì đã build trong MVP không thật sự đáp ứng nhu cầu của người dùng, hay thậm chí của chính bạn. Đôi khi bạn có ý tưởng này, plan này từ đầu, build nó ra, rồi nhận ra mình bỏ sót vài thứ, hoặc một số tính năng chẳng có ý nghĩa gì với người dùng (theo Cody, video đăng ngày 28/06/2026).

Anh kể anh đã iterate trên project này rất nhiều lần. Và anh nói thật: trong tất cả các bước của workflow, đây là bước quan trọng nhất, vì đôi khi bạn vào một project mà không bắt đầu từ con số không. Bạn bước vào một project có sẵn và phải iterate trên nó. Theo Cody (video đăng ngày 28/06/2026), các phase iterative development của agentic coding là thứ quan trọng nhất cần hiểu, bỏ xa các phần khác: về cơ bản là đi qua sản phẩm, dùng nó, rồi khi nhận ra có gì đó chạy không đúng, hoặc nhận ra có một tính năng hay có thể thêm vào…

12. Ví dụ: tính năng layer trong Sketch Lab

Để minh hoạ ý anh về iterative development, Cody cho xem Sketch Lab: trong ứng dụng này có thể vẽ ra các layer, và một layer có thể trỏ xuống các layer bên dưới (demo trong video đăng ngày 28/06/2026).

Anh tự hỏi: thứ này có hữu ích cho việc vẽ diagram không? Anh nghĩ là có, vì trong phát triển phần mềm bạn thường có một kiểu phát triển theo tầng: có những abstraction ở mức cao, rồi đi xuống thấp dần, thấp dần cho tới CPU và memory. Nên có một cách dùng các layer này để nói về các ý tưởng software engineering có thể sẽ hữu ích. Và nó cũng là một thứ rất hay để anh làm trên YouTube của mình (theo Cody, video đăng ngày 28/06/2026).

Đây không phải thứ anh từng nghĩ tới. Anh chưa bao giờ nghĩ sẽ thêm nó vào, thậm chí không nghĩ nó sẽ hữu ích. Nhưng một người anh nói chuyện trên Discord đã gửi anh một ảnh chụp màn hình ứng dụng của anh, và AI đã quyết định thêm layer vào cho anh. Anh thấy "ồ, cái này hay đấy", và quyết định cứ thêm nó vào (theo lời kể trong video đăng ngày 28/06/2026).

13. Thứ không có trong plan ban đầu

Theo Cody (video đăng ngày 28/06/2026), đó lại là cách tiếp cận iterative development, khi bạn không biết sản phẩm sẽ đi về đâu. Bạn phải thử nghiệm. Đây là những thứ bạn sẽ không có được ở plan mode. Đây là thứ anh chưa từng nghĩ tới trong plan mode ở bước một.

Anh muốn bạn nhận ra điều này: để build ra một sản phẩm tốt, bạn phải liên tục dùng nó, tìm ra cái gì cần thay đổi, cái gì cần bỏ, cái gì có thể cải thiện, tính năng hay nào có thể thêm vào. Rồi tới một lúc bạn sẽ có một sản phẩm được tinh chỉnh kỹ, mà người ta muốn dùng và thật sự nói về nó (lời khuyên của Cody, video đăng ngày 28/06/2026).

Ví dụ, anh thêm được icon vào các node. Anh nói node này có thể là một cache, còn node kia có thể là một máy, chẳng hạn một server. Mọi thứ anh đang demo ở đây đều không nằm trong plan ban đầu. Nó cần rất nhiều thử nghiệm, rất nhiều lần chơi với nó, rồi cuối cùng anh mới tới được điểm mà anh thấy "được rồi, cái này thật sự khá hữu ích và khá hay" để dùng tạo diagram (demo trong video đăng ngày 28/06/2026).

14. Project ở chỗ làm, và chuyện agentic looping 24/7

Đó là ba bước chính trong workflow của Cody khi làm một MVP. Anh nói thêm rằng bước ba, về mặt kỹ thuật, là workflow mặc định của anh cho các project ở chỗ làm. Thường thì bạn sẽ làm trên một project đã tồn tại nhiều năm. Bạn không thể cứ thế viết một plan khổng lồ rồi để AI chạy suốt đêm build ra. Bạn phải dùng sản phẩm. Về cơ bản bạn phải tìm các user story mà product owner tạo ra, hoặc những thứ người khác báo lại kèm bug, và đi qua từng cái một (theo video đăng ngày 28/06/2026).

Anh muốn nói thêm về một thứ đang được thổi phồng lúc quay video (đăng ngày 28/06/2026): ý tưởng agentic looping. Theo lời anh, có người lập luận rằng bạn có các agent chạy 24/7, build ứng dụng, tự nghĩ ra ý tưởng và thêm chúng vào sản phẩm.

Trên thực tế, Cody không nghĩ điều đó hữu ích cho sản phẩm về lâu dài, vì rốt cuộc bạn sẽ để AI thêm vào cả đống tính năng có khi chẳng hữu ích gì. Và càng thêm nhiều thứ vào sản phẩm, bạn càng tạo ra nhiều bloat và càng làm người dùng rối (quan điểm của anh trong video đăng ngày 28/06/2026).

15. Human in the loop và phần polish cuối

Vì vậy, lời khuyên của Cody (video đăng ngày 28/06/2026) là bạn nên ngồi trước máy. Bạn nên là human in the loop, và nên prompt cho nó tính năng tiếp theo mà bạn nghĩ sẽ hữu ích. Đừng để AI nghĩ xem nên thêm tính năng nào. Đừng để nó nghĩ xem nên thay đổi ứng dụng của bạn thế nào. Bạn cần có mặt ở đó, dùng nó, vì rốt cuộc, nếu bạn đang cố bán một sản phẩm sẽ được con người dùng, thì nên có một con người trong vòng lặp chơi với sản phẩm để chắc nó thật sự chạy tốt.

Theo anh (video đăng ngày 28/06/2026), với nhiều tính năng, AI có thể build ra, có thể tự tìm ra cách làm, có lẽ còn làm theo UX best practice và cứ thế đưa nó ra ngoài. Nhưng khi quay lại để làm phần polish cuối cùng, anh nghĩ vẫn phải có một con người làm việc đó.

Cody kết lại rằng đây là workflow chính của anh cho tất cả các side project anh đã build, và anh thấy nó rất, rất hữu ích (theo video đăng ngày 28/06/2026).