# Agentic coding tháng 10/2026: ứng dụng lớn trong một đến hai ngày

[adefwebserver](https://homus.dev/speakers/adefwebserver) · [adefwebserver](https://homus.dev/orgs/adefwebserver)

> Quy trình agentic coding tháng 10/2026 của adefwebserver: prompt template bắt agent hỏi, spec Markdown, mockup Stitch, Aspire và Opus 5.5 low effort.

Topics: Coding Agents, Workflow, Context Engineering

Canonical: https://homus.dev/talks/agentic-coding-where-i-am-at-now-october-2026

## 1. Bản tóm tắt: sáu quy tắc của tháng 10/2026

Video mở bằng tiêu đề "Agentic Coding, where I am at now, October 2026" và một câu giới thiệu: đây là cách adefwebserver tạo ra được những ứng dụng rất lớn (massive applications) chỉ trong một đến hai ngày. Con số một đến hai ngày là theo adefwebserver, cho quy trình của tác giả tính đến tháng 10/2026 (video đăng ngày 18/10/2026).

![Slide tiêu đề Agentic Coding: Where I Am At Now [October 2026], phía trên là dòng chữ Blazor Help Website](https://homus.dev/photos/N6YKW_nv9I4-0003.jpg)

Slide mở đầu của video đăng ngày 18/10/2026: tiêu đề "Agentic Coding: Where I Am At Now [October 2026]" và dòng chữ "Blazor Help Website" phía trên.

adefwebserver nói (video đăng ngày 18/10/2026) rằng các model và các harness cứ liên tục tốt lên, nên workflow của tác giả cũng cứ phải thay đổi để theo kịp. Bài này ghi lại những gì tác giả đang làm ngay lúc này, tháng 10/2026, để build các ứng dụng lớn, chất lượng production, trong một đến hai ngày.

Trước khi đi vào chi tiết, adefwebserver đưa ra bản ngắn gọn gồm sáu ý, là các quy tắc của tác giả tính đến tháng 10/2026 (video đăng ngày 18/10/2026):

- Luôn dùng prompt template. Việc chính của nó là bắt agent đặt câu hỏi cho tác giả (quy tắc của adefwebserver, video đăng ngày 18/10/2026).

- Luôn để agent chạy chương trình để tự kiểm chứng việc nó làm (quy tắc của adefwebserver, video đăng ngày 18/10/2026).

- Dùng Microsoft Aspire để agent có một môi trường đầy đủ, an toàn và tái tạo được (reproducible) để chạy trong đó (quy tắc của adefwebserver, video đăng ngày 18/10/2026).

- Thiết kế cả ứng dụng ngay từ đầu trong một file Markdown chính (master), rồi để agent chia nó ra thành các file con (quy tắc của adefwebserver, video đăng ngày 18/10/2026).

- Đưa cho agent các mockup chi tiết làm bằng Stitch with Google (quy tắc của adefwebserver, video đăng ngày 18/10/2026).

- Dùng Claude Opus 5.5 ở mức low effort, và để nó chạy hàng giờ liền (quy tắc của adefwebserver, video đăng ngày 18/10/2026).

![Slide Agentic Coding Workflow October 2026 với sáu ô: Prompt Template, Master MD File, Sub MD Files, Mockups, Code with Claude Opus 5.5, Run and Verify](https://homus.dev/photos/N6YKW_nv9I4-0023.jpg)

Slide "Agentic Coding Workflow, October 2026" (video đăng ngày 18/10/2026) xếp sáu bước thành một hàng: Prompt Template (agent hỏi), Master MD File (cả ứng dụng, từ đầu đến cuối), Sub MD Files (review và chỉnh), Mockups (Stitch with Google), Code with Claude Opus 5.5 (low effort, chạy hàng giờ) và Run & Verify (bên trong Microsoft Aspire).

## 2. Luôn dùng prompt template: để agent phỏng vấn mình

Quy tắc đầu tiên, theo adefwebserver (video đăng ngày 18/10/2026): mọi project của tác giả đều bắt đầu bằng cùng một prompt template. Template đó được đặt ở cuối bài; toàn văn nằm ở các phần 13 đến 16 bên dưới.

Điều quan trọng nhất ở template, theo lời tác giả (video đăng ngày 18/10/2026), là nó bảo agent phỏng vấn tác giả (interview me). Nó không bảo agent bắt đầu viết code. Thay vào đó, agent đi nghiên cứu codebase, xem xét kỹ các yêu cầu của tác giả, tìm ra những chỗ hổng (gaps) và những chỗ mơ hồ (ambiguities), rồi hỏi tác giả về chúng. Mỗi câu hỏi đi kèm các lựa chọn và một lựa chọn mặc định được khuyến nghị (recommended default), và tất cả diễn ra trước khi agent viết bất cứ thứ gì.

Theo adefwebserver (video đăng ngày 18/10/2026), những câu hỏi này là nơi tạo ra phần lớn giá trị. Mỗi câu là một quyết định mà nếu không có nó, tác giả sẽ đưa ra một cách tình cờ, hoặc là một quyết định agent sẽ lặng lẽ tự đưa ra thay cho tác giả, mà thường là sai, ở đâu đó giữa quá trình build.

![Slide Always use the prompt template: sáu ô Research, Interview Me (gắn nhãn Most Important), Write the Plan, Verify, Independent Review, Report](https://homus.dev/photos/N6YKW_nv9I4-0140.jpg)

Slide "1. Always use the prompt template" (video đăng ngày 18/10/2026): ô "2. Interview Me" được làm nổi và gắn nhãn "Most important", vẽ agent đưa ra "Option A" và "Option B" có chữ "Recommended". Các ô khác là Research, Write the Plan (một file `Docs/Feature-Plan.md`), Verify, Independent Review và Report.

## 3. Template tạo ra một file Markdown, không phải code

Đầu ra của template, theo adefwebserver (video đăng ngày 18/10/2026), luôn luôn là một file Markdown, thường được lưu trong thư mục docs của project. File đó chính là bản đặc tả (specification), và là thứ agent dựa vào để viết code. Mỗi khi bảo agent viết code, tác giả luôn bảo nó code từ chính file Markdown đó.

Đây là chỗ tác giả làm "phần việc nặng" của lập trình, và tác giả nói rõ chữ "nặng" là đặt trong ngoặc kép. Tác giả đọc file Markdown rồi bảo agent cần đổi gì, thêm gì, bỏ gì. Tác giả và agent trao đổi qua lại trên tài liệu, không phải trên code. Chỉ khi tác giả hài lòng với file Markdown thì mới bảo agent code từ nó (quy trình của adefwebserver, video đăng ngày 18/10/2026).

Theo adefwebserver (video đăng ngày 18/10/2026), sửa một tài liệu nhanh hơn rất nhiều so với viết lại code, và đó cũng là nơi những quyết định thiết kế thật sự được đưa ra.

![Slide The real work happens in the MD file: developer sửa docs/Plan.md, vòng lặp Review, Request changes, Agent updates MD, rồi Satisfied và Code from the MD file](https://homus.dev/photos/N6YKW_nv9I4-0243.jpg)

Slide "The real work happens in the MD file" (video đăng ngày 18/10/2026): developer dán các ghi chú "Change this", "Add this", "Remove this" lên `docs/Plan.md`, vòng lặp Review, Request changes, Agent updates MD lặp lại "until satisfied", và chỉ sau ô "Satisfied?" mới tới "Code from the MD file". Dòng dưới cùng ghi "Edit the document, not the code".

## 4. Thiết kế cả ứng dụng từ đầu đến cuối trước

Quy tắc tiếp theo là thiết kế cả ứng dụng end-to-end trước. Theo adefwebserver (video đăng ngày 18/10/2026), nhiều người build ứng dụng cùng agent theo kiểu từng feature một: một file Markdown, build nó; file Markdown tiếp theo, build tiếp, cứ thế. Tác giả nói mình không làm như vậy nữa.

Thay vào đó, tác giả tính toán toàn bộ ứng dụng từ đầu đến cuối trong một file Markdown chính duy nhất. Khi đã ưng file đó, tác giả bảo agent tạo các file con liên quan tới file chính, mỗi file đi sâu hơn vào một khu vực riêng của ứng dụng. Tác giả cũng review và chỉnh các file con này. Sau đó tác giả mới để agent code phiên bản đầu tiên của cả ứng dụng, end-to-end, trong một lượt (quy trình của adefwebserver, video đăng ngày 18/10/2026).

Theo adefwebserver (video đăng ngày 18/10/2026), cách này cho ra ứng dụng tốt hơn so với build từng bước. Kiến trúc bên dưới tốt hơn nhiều, vì agent biết chính xác ứng dụng sẽ đi tới đâu. Khi build từng bước, bức tranh đầy đủ chỉ nằm trong đầu bạn. Agent đưa ra những lựa chọn hợp lý cho bước một nhưng hóa ra lại sai cho bước năm, và bạn dành thời gian đi refactor. Khi cả kế hoạch đã được viết ra, agent thiết kế data model, các service và giao diện người dùng cho đúng cái ứng dụng mà cuối cùng bạn sẽ thật sự có.

![Slide Design the whole application end to end first: bên trái các bước Step 1 đến Step 4 dẫn tới một khối gạch đổ, bên phải Master MD chia ra các Sub MD dẫn tới các tầng UI, Services, Data](https://homus.dev/photos/N6YKW_nv9I4-0337.jpg)

Slide "2. Design the whole application end to end first" (video đăng ngày 18/10/2026): bên trái, các bước Step 1 đến Step 4 nối nhau và dẫn tới một khối gạch xiêu vẹo có nhãn "Wrong early choices"; bên phải, một "Master MD" chia ra nhiều "Sub MD" đổ vào ba tầng UI, Services, Data, với nhãn "First version in one pass" và "Better architecture".

## 5. Luôn để agent chạy chương trình, và vấn đề đăng nhập

Đây là quy tắc quan trọng thứ hai, theo adefwebserver (video đăng ngày 18/10/2026): agent phải chạy chương trình và kiểm chứng mọi thứ. Code biên dịch được không phải là code chạy đúng. Agent cần tự khởi động ứng dụng, bấm qua từng phần, kiểm tra kết quả, rồi sửa những gì đang hỏng, mà tác giả không phải tự làm việc đó.

Nghe thì đơn giản, nhưng theo tác giả (video đăng ngày 18/10/2026), trên thực tế đây là phần khó nhất, vì hai lý do.

Vấn đề thứ nhất là đăng nhập. Theo adefwebserver (video đăng ngày 18/10/2026), mọi ứng dụng tác giả tạo bây giờ đều dùng đăng nhập bằng Google hoặc Microsoft, hoặc cả hai. Điều đó khiến agent khó test ứng dụng hơn nhiều, vì agent không thể tự mình đi qua một màn hình đăng nhập OAuth.

Giải pháp của tác giả rất đơn giản (quy trình của adefwebserver, video đăng ngày 18/10/2026): bảo agent dừng lại khi cần tác giả đăng nhập bằng tay. Agent mở trình duyệt, tới trang đăng nhập, rồi dừng. Tác giả đăng nhập, bảo agent tiếp tục, vậy là xong. Trong nhiều trường hợp, agent có thể giữ lại cookie xác thực tạm thời và đăng nhập lại bao nhiêu lần tùy ý trong suốt phần còn lại của session đó. Tác giả đăng nhập một lần, còn agent test hàng giờ.

![Slide Run the program and verify everything: vòng Launch App, Click Through, Check Results, Fix Code quanh một agent; bên phải ô PAUSE Please log in với nút Sign in with Google và Sign in with Microsoft](https://homus.dev/photos/N6YKW_nv9I4-0423.jpg)

Slide "3. Always have the agent run the program" (video đăng ngày 18/10/2026): vòng lặp Launch App, Click Through, Check Results (logs, screenshots, data), Fix Code quanh một agent. Bên phải là ô "PAUSE: Please log in" với hai nút Sign in with Google và Sign in with Microsoft, mũi tên "Continue" quay lại vòng lặp, và nhãn "Session cookie reused".

## 6. Vấn đề thứ hai: database, storage và các service

Vấn đề thứ hai là database, storage và các service. Theo adefwebserver (video đăng ngày 18/10/2026), ứng dụng thật có một SQL database, các storage account, một website, một hoặc nhiều API, và còn nữa. Bạn không thể để agent chạy trên production, và ngay cả việc cấu hình một môi trường dev đàng hoàng cho tất cả các thành phần đó cũng có thể rất phức tạp.

![Slide Problem 2: Databases, storage and services: một developer rối giữa các dây nối tới Storage Account và đám mây Production?! có dấu cảnh báo; bên phải một agent cạnh SQL Server](https://homus.dev/photos/N6YKW_nv9I4-0543.jpg)

Slide "Problem 2: Databases, storage and services" (video đăng ngày 18/10/2026): bên trái một developer bối rối giữa mớ dây nối tới "Storage Account" và một đám mây ghi "Production?!" kèm dấu cảnh báo đỏ; bên phải là một agent đứng cạnh một khối SQL Server, mở đầu cho phần giải pháp.

## 7. Microsoft Aspire cho mọi project

Đây là lý do, theo adefwebserver (video đăng ngày 18/10/2026), tác giả bây giờ dùng Microsoft Aspire cho tất cả các project của mình. Aspire cho agent một môi trường trong đó các storage account, SQL Server, website và API đều được định nghĩa ở cùng một chỗ, và có ba đặc điểm sau, theo cách tác giả kể (video đăng ngày 18/10/2026):

- **Dễ dựng (easily built).** Toàn bộ môi trường được mô tả bằng code trong app host (theo adefwebserver, video đăng ngày 18/10/2026).

- **Được nhân bản (replicated).** Mỗi lần chạy đều có cùng một bộ resource, tách biệt khỏi production (theo adefwebserver, video đăng ngày 18/10/2026).

- **Chạy bằng một lệnh duy nhất (executed with a single command).** Agent khởi động mọi thứ, và Aspire dashboard cho nó log, trace và trạng thái resource để chẩn đoán sự cố (theo adefwebserver, video đăng ngày 18/10/2026).

Với Aspire, theo adefwebserver (video đăng ngày 18/10/2026), việc chạy chương trình và kiểm chứng mọi thứ không còn là một cơn ác mộng cấu hình nữa. Agent có thể khởi động cả hệ thống, chạy thử nó từ đầu đến cuối, đọc log khi có gì đó lỗi, sửa code rồi chạy lại, tất cả mà không đụng vào bất cứ thứ gì thật.

Aspire, cộng với việc dừng lại để tác giả đăng nhập, là thứ giải quyết bài toán test cho tác giả (theo adefwebserver, video đăng ngày 18/10/2026). Trang tài liệu chính thức của Aspire mô tả nó là cách compose, debug và deploy các ứng dụng phân tán với một AppHost viết bằng code, còn dashboard cho xem log, distributed trace, metric và tình trạng resource ([aspire.dev](https://aspire.dev/get-started/what-is-aspire/), đọc ngày 27/10/2026).

![Slide Microsoft Aspire for everything: khối Aspire Dashboard với Logs, Traces, Resource State; bên dưới ba nhãn Easily Built, Replicated, Executed with One Command](https://homus.dev/photos/N6YKW_nv9I4-0634.jpg)

Slide "4. Microsoft Aspire for everything" (video đăng ngày 18/10/2026): phía trên là các ô Website, API và Storage Account; ở giữa là "Aspire Dashboard" với ba ô Logs, Traces, Resource State; phía dưới là ba nhãn "Easily Built", "Replicated" và "Executed with One Command".

## 8. Đưa cho agent mockup chi tiết làm bằng Stitch

Một phần lớn khác trong quy trình của tác giả, theo adefwebserver (video đăng ngày 18/10/2026), là luôn đưa mockup cho agent. Đây không phải những wireframe sơ sài. Chúng là những mockup chi tiết đầy đủ, được tạo ra từ chính bản đặc tả.

Cách làm, theo adefwebserver (video đăng ngày 18/10/2026): khi các file Markdown đã hoàn chỉnh, tác giả nói với Claude rằng mình muốn tạo mockup bằng Stitch with Google, và để Claude viết một prompt chi tiết cho Stitch dựa trên các file Markdown. Theo tác giả, Claude đã biết mọi màn hình, mọi trường dữ liệu và mọi workflow trong ứng dụng, nên nó viết prompt tốt hơn nhiều so với khi tác giả tự viết bằng tay. Tác giả dán prompt đó vào Stitch và Stitch tạo ra các mockup. Trang chủ Stitch tự giới thiệu là công cụ tạo UI cho ứng dụng mobile và web ([stitch.withgoogle.com](https://stitch.withgoogle.com/), đọc ngày 27/10/2026).

Sau đó tác giả làm hai việc (quy trình của adefwebserver, video đăng ngày 18/10/2026):

- Lưu các mockup vào thư mục docs của project (bước của adefwebserver, video đăng ngày 18/10/2026).

- Bảo agent code theo hướng dẫn trong các file Markdown, bao gồm cả các mockup trong thư mục đó (bước của adefwebserver, video đăng ngày 18/10/2026).

Lúc này agent có cả "cái gì" (what), tức các spec, lẫn "trông như thế nào" (how it should look), tức các mockup. Theo adefwebserver (video đăng ngày 18/10/2026), phiên bản đầu tiên của giao diện ra gần với điều tác giả muốn, thay vì một layout chung chung mà tác giả phải mô tả đi mô tả lại.

![Slide Detailed mockups from the specs: năm bước MD Files, Claude Writes the Prompt, Stitch with Google, Save to /docs, Code from MD + Mockups](https://homus.dev/photos/N6YKW_nv9I4-0743.jpg)

Slide "Detailed mockups from the specs" (video đăng ngày 18/10/2026) vẽ năm bước: 1. MD Files, 2. Claude Writes the Prompt (một tờ "Stitch prompt"), 3. Stitch with Google (các màn hình UI 1, UI 2, UI 3), 4. Save to /docs (`mockup1.png`, `mockup2.png`, `mockup3.png`), 5. Code from MD + Mockups, với hai nhãn "The WHAT: specs" và "The HOW IT LOOKS: mockups".

## 9. Chọn model: Claude Opus 5.5 ở low effort

Về model, tính đến tháng 10/2026 (video đăng ngày 18/10/2026), adefwebserver dùng Claude Opus 5.5 và chạy nó ở mức low effort. Tác giả đưa ra lý do:

- Nó tiết kiệm tiền (theo adefwebserver, video đăng ngày 18/10/2026).

- Nó chạy nhanh hơn (theo adefwebserver, video đăng ngày 18/10/2026).

- Code viết ra tốt ngang với khi dùng các mức effort cao hơn, ít nhất là với cách làm việc của tác giả. Phần lập kế hoạch đã được làm xong trong các file Markdown, nên agent không cần phải suy nghĩ nhiều khi code (theo adefwebserver, video đăng ngày 18/10/2026).

Theo adefwebserver (video đăng ngày 18/10/2026), Opus 5.5 còn tự tạo và cập nhật test mà không cần được yêu cầu. Lời khuyên của tác giả: cứ để nó viết bao nhiêu test tùy nó cần, đừng cố giới hạn.

Lựa chọn model của adefwebserver theo video đăng ngày 18/10/2026: Claude Opus 5.5 ở low effort, với bốn điều tác giả nêu, gồm cả ý "code tốt ngang effort cao hơn" mà tác giả giới hạn ở cách làm việc của mình.

## 10. Chuẩn bị tinh thần cho những lượt chạy hàng giờ

Theo adefwebserver (video đăng ngày 18/10/2026), khi tác giả bảo agent thực thi một file Markdown, hoặc vài file cùng lúc, đừng ngạc nhiên nếu nó chạy hàng giờ. Nó đang build cả một ứng dụng, chạy nó, test nó và sửa nó.

Đây cũng là thêm một lý do tác giả dùng low effort, theo adefwebserver (video đăng ngày 18/10/2026): với một lượt chạy dài như thế, phần tiết kiệm về tốc độ và chi phí cộng dồn lại.

Có người còn dùng các model rẻ hơn nữa. Theo adefwebserver (video đăng ngày 18/10/2026), tác giả thấy khoản tiết kiệm đó không lớn lắm, và tác giả thà để ứng dụng ra lò sạch bug từ 98 đến 100% ngay lượt đầu với cách làm hiện tại của mình.

![Slide so sánh Cheaper Model với Opus 5.5 Low Effort trên một cái cân: bên trái More bugs to fix, More of YOUR time; bên phải Slightly more cost, 98–100% bug-free, Writes its own tests](https://homus.dev/photos/N6YKW_nv9I4-0903.jpg)

Slide trong phần "Expect it to take hours" (video đăng ngày 18/10/2026) đặt hai cột lên một cái cân có nhãn "Clear Advantage": cột "Cheaper Model" ghi "Small savings", "More bugs to fix" và "More of YOUR time"; cột "Opus 5.5, Low Effort" ghi "Slightly more cost", "98–100% bug-free" và "Writes its own tests".

## 11. Ghép tất cả lại

adefwebserver gom toàn bộ quy trình lại thành một chuỗi bước, là quy trình của tác giả tính đến tháng 10/2026 (video đăng ngày 18/10/2026):

- Chạy prompt template (bước của adefwebserver, video đăng ngày 18/10/2026).

- Trả lời các câu hỏi của agent (bước của adefwebserver, video đăng ngày 18/10/2026).

- Chỉnh file Markdown chính trong thư mục docs cho tới khi tác giả hài lòng với cả ứng dụng, từ đầu đến cuối (bước của adefwebserver, video đăng ngày 18/10/2026).

- Để agent tạo các file Markdown con, rồi review và điều chỉnh chúng (bước của adefwebserver, video đăng ngày 18/10/2026).

- Để Claude viết một prompt cho Stitch with Google, tạo các mockup và đặt chúng vào thư mục docs (bước của adefwebserver, video đăng ngày 18/10/2026).

- Bảo đảm project dùng Microsoft Aspire để agent có một môi trường đầy đủ và tách biệt (bước của adefwebserver, video đăng ngày 18/10/2026).

- Bảo Claude Opus 5.5 ở low effort code theo các file Markdown và các mockup, chạy chương trình và kiểm chứng mọi thứ, dừng lại khi cần tác giả đăng nhập (bước của adefwebserver, video đăng ngày 18/10/2026).

- Để nó chạy, có thể là hàng giờ (bước của adefwebserver, video đăng ngày 18/10/2026).

Đó là cách, theo adefwebserver (video đăng ngày 18/10/2026), tác giả tạo ra được những ứng dụng rất lớn trong một đến hai ngày.

![Slide From idea to application in 1–2 days: cột Day 1 gồm Answer questions, Refine master MD, Review sub MD files, Create mockups; cột Day 2 gồm Agent codes end to end, Runs in Aspire, Tests and fixes, Done](https://homus.dev/photos/N6YKW_nv9I4-1023.jpg)

Slide "From idea to application in 1–2 days" (video đăng ngày 18/10/2026) chia quy trình thành hai cột: DAY 1 là Answer questions, Refine master MD, Review sub MD files, Create mockups, với một developer ngồi gõ máy; DAY 2 là Agent codes end to end, Runs in Aspire, Tests & fixes và Done!, với một agent và một developer giơ ngón cái.

## 12. Bình luận: một workflow không bao giờ đứng yên

Phần cuối của bài là một đoạn bình luận mang tên "the workflow that never sits still". adefwebserver kể (video đăng ngày 18/10/2026) rằng đôi khi tác giả thấy bực vì dường như chúng ta không thể chốt được một workflow nào trong cuộc cách mạng agentic coding đang tiến rất nhanh này. Tác giả thấy mình phải điều chỉnh workflow hằng tuần, có khi hằng ngày. Kỹ thuật, công cụ và model đều liên tục thay đổi. Khó mà không nhớ cái workflow dễ đoán mà chúng ta từng có trước đây.

Nhưng theo adefwebserver (video đăng ngày 18/10/2026), tác giả đã đi tới chỗ nghĩ rằng đây thật ra là một điều tích cực. Nó cho thấy chỗ mà lập trình viên con người sẽ luôn được cần tới.

Lập luận của tác giả (video đăng ngày 18/10/2026): cả hệ sinh thái và cấu trúc quanh các model AI, các harness và các công cụ này phải được một con người ghép lại và điều khiển, một người mang tới sự chủ động (initiative) và mong muốn tạo ra một thứ gì đó ngay từ đầu. Khả năng làm việc đó, cùng sự hiệu quả trong việc hiểu và khai thác những công cụ và khả năng luôn thay đổi của mọi phần trong hệ sinh thái, là thứ người lập trình đóng góp vào công việc. Điều đó sẽ còn thay đổi, và sẽ còn cần một bộ óc con người với những mong muốn của con người để định hướng nó và đưa ra quyết định.

Theo adefwebserver (video đăng ngày 18/10/2026), đây là lý do máy tính sẽ không thay thế con người: con người có một việc mà chỉ họ làm được. Và đó là điều tác giả giờ chấp nhận như công việc của một lập trình viên.

![Slide The job of a programmer: một lập trình viên ở giữa, xung quanh là AI Models, Harnesses, Workflows, Techniques, Tools, Initiative and Desire, và nhãn Changes weekly sometimes daily](https://homus.dev/photos/N6YKW_nv9I4-1143.jpg)

Slide "The job of a programmer" trong phần bình luận (video đăng ngày 18/10/2026): một lập trình viên ngồi giữa, nối tới các ô AI Models, Harnesses, Workflows, Techniques và Tools, với "Initiative & Desire" ở trên, nhãn "Changes weekly... sometimes daily" bên phải, và dòng dưới cùng ghi "Humans direct, decide and exploit the changing tools, a job only they can do".

## 13. Prompt template, phần 1: Task, Research, Interview me

Cuối bài là toàn bộ prompt template mà tác giả dùng tính đến tháng 10/2026 (video đăng ngày 18/10/2026). Cách dùng theo lời tác giả: chép mọi thứ trong khối bên dưới, liệt kê các feature của bạn ở cuối, rồi đưa nó cho agent. Template được trình bày dưới đây thành bốn khối theo đúng thứ tự trong video; ghép bốn khối lại là được template đầy đủ.

Phần đầu là **Task**. Template (video đăng ngày 18/10/2026) bảo agent lập kế hoạch cho các feature liệt kê ở cuối và lưu kế hoạch vào thư mục docs dưới tên dạng feature-name-plan. Nó nói rõ đây chỉ là lập kế hoạch: không sửa source code, và không dùng lệnh terminal để tạo file. Nếu file đã tồn tại thì phải hỏi trước khi ghi đè. Nếu các feature không liên quan tới nhau, agent phải hỏi người dùng muốn một kế hoạch chung hay mỗi feature một kế hoạch. Kế hoạch sẽ được giao cho một developer, hoặc một agent session mới, chưa từng thấy cuộc chat này, nên nó phải tự đứng được một mình.

Phần **Research** của template (video đăng ngày 18/10/2026) bảo agent đọc file agents và file copilot-instructions nếu chúng tồn tại, và làm theo. Agent dùng các subagent để nghiên cứu từng khu vực của codebase mà các feature đụng tới. Mỗi subagent báo lại các file và hàm liên quan (kèm link), những pattern sẵn có để tái sử dụng, và bất cứ điều gì khiến feature khó hơn vẻ ngoài của nó. Agent không được mô tả code mà nó chưa đọc.

Phần **Interview me** là phần tác giả gọi là quan trọng nhất ở mục 2 (video đăng ngày 18/10/2026). Trước khi viết, agent hỏi về các edge case, ranh giới phạm vi (scope boundaries) và những đánh đổi (trade-offs) mà người dùng có thể chưa nghĩ tới. Không hỏi điều mà code đã trả lời sẵn. Hỏi tất cả trong một lượt; mỗi câu hỏi đưa ra các lựa chọn, lựa chọn mặc định được khuyến nghị, và lý do câu hỏi đó quan trọng. Bỏ qua bước này nếu không có gì quan trọng còn chưa rõ.

```
# Task
Plan the features listed at the bottom and save the plan to `Docs/-Plan.md`. This is planning only: do not modify source code, and do not use terminal commands to create the file. If the file already exists, ask before overwriting it. If the features are unrelated, ask whether I want one plan or one per feature. The plan will be handed to a developer, or a fresh agent session, who has not seen this chat, so it must stand on its own.

## 1. Research
- Read `AGENTS.md` and `.github/copilot-instructions.md` if they exist, and follow them.
- Use subagents to research each area of the codebase the features touch. Each reports back the relevant files and functions (with links), existing patterns to reuse, and anything that makes the feature harder than it sounds.
- Do not describe code you have not read.

## 2. Interview me
Before writing, ask about edge cases, scope boundaries and trade-offs I may not have considered. Do not ask anything the code already answers. Ask in one batch; for each question give options, your recommended default, and why it matters. Skip this step if nothing important is unclear.
```

## 14. Prompt template, phần 2: Write the plan

Phần **Write the plan** của template (video đăng ngày 18/10/2026) bắt đầu bằng chỉ dẫn: liệt kê trực tiếp thư mục docs, vì thư mục này có thể bị loại khỏi tìm kiếm. Nếu trong đó đã có các file kết thúc bằng "-Plan.md", agent phải theo đúng cấu trúc và độ sâu của file tốt nhất trong số đó.

Kế hoạch phải bao gồm, theo template (video đăng ngày 18/10/2026): phần tóm tắt; mục tiêu và những gì không phải mục tiêu (goals and non-goals); các quyết định, mỗi quyết định kèm phương án bị loại và lý do; hiện trạng, kèm link tới file; thiết kế, kèm một sơ đồ cấu trúc; các contract, tức chữ ký hàm, schema, config key và tham số dòng lệnh với kiểu dữ liệu và giá trị mặc định, cùng input và output mẫu; các flow, mỗi flow chính một sơ đồ, gồm cả các nhánh lỗi; một bảng thay đổi theo từng file với các cột File, New/Modified và Change; bảo mật và quyền riêng tư; kế hoạch test; rủi ro và cách giảm thiểu; các implementation task dưới dạng danh sách checkbox có thứ tự, mỗi task cỡ một pull request, kèm một điều kiện "done when"; tiêu chí nghiệm thu (acceptance criteria); và các câu hỏi còn mở.

Hai luật cuối của phần này, theo template (video đăng ngày 18/10/2026): mọi khẳng định về code hiện có hoặc là một link tới file chứng minh nó, hoặc phải được đánh dấu là "(assumed)". Ưu tiên bảng, chữ ký hàm và ví dụ hơn là văn xuôi, và không viết implementation đầy đủ.

```
## 3. Write the plan
List the `Docs/` folder directly; it may be excluded from search. If it contains `*-Plan.md` files, match the structure and depth of the best one. Cover:
- summary
- goals and non-goals
- decisions, each with the rejected alternative and why
- current state, with file links
- design, with a structure diagram
- contracts: function signatures, schemas, config keys and CLI parameters with types and defaults, sample input and output
- flows: one diagram per major flow, including failure paths
- a file-by-file change table with columns File | New/Modified | Change
- security and privacy
- test plan
- risks and mitigations
- implementation tasks: an ordered checkbox list, each task one PR in size, with a "done when" check
- acceptance criteria
- open questions

Every claim about existing code is either a link to the file that proves it, or is marked **(assumed)**. Prefer tables, signatures and examples over prose. Do not write full implementations.
```

## 15. Prompt template, phần 3: Mermaid rules và Hard rules

Tiếp theo là các luật cho sơ đồ Mermaid, viết cho trình render Mermaid của VS Code. Template (video đăng ngày 18/10/2026) liệt kê năm luật, mỗi luật kèm lý do mà chính template đưa ra:

- Không bao giờ đặt chuỗi escape xuống dòng (dấu gạch chéo ngược và chữ n) trong một label, vì trình render của VS Code không hỗ trợ; dùng thẻ ngắt dòng HTML thay vào, hoặc rút ngắn label (theo template, video đăng ngày 18/10/2026).

- Không bao giờ bắt đầu một label bằng số một và dấu chấm, vì nó bị hiểu thành một danh sách Markdown và làm hỏng label. Viết "Step 1:" thay vào, và trong sequence diagram thì dùng autonumber (theo template, video đăng ngày 18/10/2026).

- Đặt trong ngoặc kép mọi label có chứa ngoặc tròn, ngoặc vuông, ngoặc nhọn, dấu hai chấm, dấu chấm phẩy, dấu gạch chéo, dấu thăng hoặc dấu và (&), vì đó đều là cú pháp Mermaid. Ví dụ trong template là một node A với label "Parse config (JSON)" đặt trong ngoặc vuông và ngoặc kép (theo template, video đăng ngày 18/10/2026).

- Node ID chỉ gồm chữ và số. Không bao giờ dùng các từ end, graph hoặc subgraph, vì đó là từ khóa dành riêng (theo template, video đăng ngày 18/10/2026).

- Giữ mỗi sơ đồ ở khoảng 20 node, và tách những sơ đồ lớn hơn ra (theo template, video đăng ngày 18/10/2026).

Sau đó là **Hard rules** (template trong video đăng ngày 18/10/2026): không có mật khẩu, token, connection string, hostname thật, địa chỉ IP hay dữ liệu cá nhân trong kế hoạch, vì tài liệu sẽ được chia sẻ ra ngoài team. Dùng placeholder, chẳng hạn như chữ server.

```
## Mermaid rules (VS Code renderer)
- Never put `\n` in a label; VS Code's renderer doesn't support it. Use `
` or shorten the label.
- Never start a label with `1.`: it is parsed as a Markdown list and breaks the label. Write `Step 1:`; in sequence diagrams use `autonumber`.
- Quote labels containing ( ) [ ] { } : ; / # &, because those are Mermaid syntax. Example: `A["Parse config (JSON)"]`
- Node IDs are alphanumeric only. Never use `end`, `graph` or `subgraph` (reserved words).
- Keep each diagram to about 20 nodes; split larger ones.

## Hard rules
No passwords, tokens, connection strings, real hostnames, IPs or personal data in the plan, because docs get shared outside the team. Use placeholders such as ``.
```

## 16. Prompt template, phần 4: Verify, Independent review, Report

Phần **Verify** của template (video đăng ngày 18/10/2026) bảo agent render mọi sơ đồ Mermaid và sửa những sơ đồ bị lỗi. Nếu agent không có công cụ render, nó phải kiểm từng sơ đồ theo từng dòng đối chiếu với các luật Mermaid, và nói trong báo cáo rằng sơ đồ chưa được render. Agent cũng phải mở lại mọi file và hàm đã được link tới, và xác nhận chúng tồn tại đúng như mô tả.

Rồi tới **Independent review** (template trong video đăng ngày 18/10/2026). Agent khởi động một subagent mới và chỉ đưa cho nó đường dẫn tới kế hoạch cùng quyền truy cập codebase, không đưa cuộc chat này. Vai của subagent đó là một senior engineer đa nghi. Agent nhờ nó tìm: những bước mà một developer không thể làm nếu không phải đi hỏi ai đó; những khẳng định mâu thuẫn với code; những trường hợp lỗi bị bỏ sót; và những task quá lớn. Sau đó agent sửa những gì subagent tìm ra.

Cuối cùng là **Report** (template trong video đăng ngày 18/10/2026). Trong chat, agent chỉ trả lời bằng: đường dẫn file; một bản tóm tắt từ ba đến năm gạch đầu dòng; những quyết định agent đã đưa ra thay cho người dùng; những phát hiện của review mà agent không xử lý; sơ đồ đã được render hay chỉ kiểm bằng tay; và các câu hỏi còn mở. Sau đó là tiêu đề "Features to document", nơi bạn điền danh sách feature của mình.

```
## 4. Verify
- Render every Mermaid diagram and fix any that fail. If you have no rendering tool, check each diagram line by line against the Mermaid rules and say in the report that it was not rendered.
- Re-open every linked file and function and confirm it exists as described.

## 5. Independent review
Start a fresh subagent and give it only the plan's path and access to the codebase, not this conversation. Its role is a skeptical senior engineer. Ask it to find:
- steps a developer couldn't carry out without asking someone
- statements that contradict the code
- missing failure modes
- tasks that are too large

Fix what it finds.

## 6. Report
In chat, reply with only:
- the file path
- a 3–5 bullet summary
- decisions you made on my behalf
- review findings you didn't act on
- whether the diagrams were rendered or only checked by hand
- open questions

# Features to document

1.
2.

```

Sáu bước của prompt template mà adefwebserver dùng (video đăng ngày 18/10/2026): bước Interview me được tác giả gọi là điều quan trọng nhất của template; kết quả là một file kế hoạch trong thư mục Docs, được một subagent mới review trước khi agent báo lại.

adefwebserver khép video ở đó, với dòng "Features to document" chờ người dùng điền danh sách feature của mình vào.

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

- Tên gốc: Agentic Coding: Where I Am At Now [October 2026]
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=N6YKW_nv9I4](https://www.youtube.com/watch?v=N6YKW_nv9I4)

- Kênh YouTube adefwebserver (adefwebserver): [youtube.com/channel/UCU2M7fnTZ_5OyxRPqFha-Ww](https://www.youtube.com/channel/UCU2M7fnTZ_5OyxRPqFha-Ww)

- Microsoft Aspire, trang "What is Aspire?" (mô tả Aspire là cách compose, debug và deploy ứng dụng phân tán với một AppHost viết bằng code; đọc ngày 27/10/2026): [aspire.dev/get-started/what-is-aspire](https://aspire.dev/get-started/what-is-aspire/)

- Aspire dashboard (xem log, distributed trace, metric và tình trạng resource; đọc ngày 27/10/2026): [aspire.dev/dashboard/overview](https://aspire.dev/dashboard/overview/)

- Stitch, "Design with AI" của Google (tạo UI cho ứng dụng mobile và web; đọc ngày 27/10/2026): [stitch.withgoogle.com](https://stitch.withgoogle.com/)

Nguồn: https://homus.dev/talks/agentic-coding-where-i-am-at-now-october-2026 · cập nhật 2026-10-27