(How I'm able to create massive applications in one to two days)

Watch the YouTube video at: https://www.youtube.com/watch?v=N6YKW_nv9I4

The models and harnesses keep getting better, and my workflow keeps changing to keep up. This post covers what I'm doing right now, in October 2026, to build large,

production-quality applications in one to two days.

Here is the short version:

1. Always use the prompt template. Its main job is to make the agent ask me questions.
2. Always have the agent run the program to verify its work.
3. Use Microsoft Aspire so the agent has a complete, safe, reproducible environment to run in.
4. Design the whole application up front in a master Markdown file, then have the agent break it into sub-files.
5. Give the agent detailed mockups created with Stitch with Google.
6. Use Claude Opus 5.5 at low effort, and let it run for hours.

---

1. Always use the prompt template

Every project starts with the same prompt template. (The template is included at the end of this post.- The template was created By: Saad Awais (https://github.com/imsaadawais))

The most important thing about the template is that it tells the agent to interview me. It does not tell the agent to start coding. Instead, the agent researches the codebase,

works through my requirements, finds the gaps and the ambiguities, and asks me about them, with options and a recommended default for each, before it writes anything.

These questions are where most of the value comes from. Each one is a decision I would otherwise make by accident, or one the agent would quietly make for me (often wrongly) halfway through the build.

The template produces a Markdown file, not code

The output of the template is always a Markdown (.md) file, usually saved in the project's docs directory. That file is the specification, and it is what the agent codes from.

When I tell the agent to write code, I always tell it to code from that MD file.

This is where I do the "heavy work" of programming, and I mean "heavy" in quotes. I read the MD file and tell the agent what to change, add or remove.

We go back and forth on the document, not on the code. Only when I am satisfied with the MD file do I tell the agent to code from it.

Editing a document is far faster than rewriting code, and it is where the real design decisions get made.

---

2. Design the whole application end to end first

Many people build an application with an agent one feature at a time: one MD file, build it, the next MD file, build that, and so on.

I don't do that anymore.

Instead, I work out the entire application from end to end in a single master MD file. When I'm happy with it, I tell the agent to create sub-MD files related to that master file,

covering the individual areas of the application in more detail. I review and modify those as well.

Then I have the agent code the first version of the entire application, end to end, in one pass.

I've found this produces better applications than building step by step. The underlying architecture is much better because the agent knows exactly where the application is going.

When you build step by step, the full picture lives only in your head. The agent makes reasonable choices for step one that turn out to be wrong for step five, and you spend your time refactoring.

When the whole plan is written down, the agent designs the data model, services and UI for the application you will actually end up with.

---

3. Always have the agent run the program

The second most important rule: the agent must run the program and verify everything. Code that compiles is not code that works. The agent needs to launch the application,

click through it, check the results and fix what is broken, without me doing it.

This sounds simple, but in practice it is the hardest part, for two reasons.

Problem 1: Logins

Every application I create now uses Google and/or Microsoft logins. That makes it much harder for an agent to test the application, because it cannot simply walk through an OAuth sign-in on its own.

My solution is simple: I tell the agent to pause when it needs me to log in manually. The agent opens the browser, reaches the sign-in page, and stops. I sign in, tell it to continue, and that's it.

In many cases the agent can hold on to the temporary authentication cookie and sign back in as often as it needs to for the rest of that session. I log in once and the agent tests for hours.

Problem 2: Databases, storage and services

Real applications have a SQL database, storage accounts, a website, one or more APIs, and so on. You can't let the agent run against production,

and even configuring a proper dev environment for all of those pieces can be very complicated.

---

4. Microsoft Aspire for everything

This is why I now use Microsoft Aspire for all of my projects.

Aspire gives the agent an environment where the storage accounts, SQL Server, websites and APIs are all defined in one place and are:

• Easily built. The whole environment is described in code in the AppHost.
• Replicated. Every run gets the same set of resources, isolated from production.
• Executed with a single command. The agent starts everything, and the Aspire dashboard gives it the logs, traces and resource state to diagnose problems.

With Aspire, "run the program and verify everything" is no longer a configuration nightmare. The agent can start the whole system, exercise it from end to end,

read the logs when something fails, fix the code and run it again, all without touching anything real.

Aspire, plus "pause and let me log in," solves the testing problem for me.

---

5. Give the agent detailed mockups

Another big part of my process: I always give the agent mockups. These are not rough wireframes. They are fully detailed mockups created from the specs.

When the MD files are complete, I tell Claude that I want to create mockups with Stitch with Google, and I have it write a detailed prompt for Stitch based on the MD files.

Claude already knows every screen, field and workflow in the application, so it writes a far better prompt than I would by hand.

I paste that prompt into Stitch, and Stitch creates the mockups. I then:

1. Save the mockups into the project's docs directory.
2. Tell the agent to code from the instructions in the MD files, including the mockups in that directory.

The agent now has both the what (the specs) and the how it should look (the mockups). The first version of the UI comes out close to what I want, instead of a generic layout I have to describe over and over.

---

6. Model choice: Claude Opus 5.5 at low effort

I use Claude Opus 5.5, and I run it at low effort.

• It saves money.
• It moves faster.
• The code is just as good as with higher effort settings, at least for the way I work. The planning has already been done in the MD files, so the agent doesn't need to think as hard while coding.

Opus 5.5 also creates and updates tests automatically without being asked. Let it write as many tests as it needs. Don't try to limit it.

Expect it to take hours

When I tell the agent to execute an MD file, or several of them, don't be surprised if it runs for hours. It is building an entire application, running it, testing it and fixing it.

This is another reason I use low effort: on a run that long, the speed and cost savings add up.

Some people use even cheaper models. I've found the savings aren't that large, and I would rather have the application come out 98% to 100% bug-free on the first pass with my current method.

 

---

The Prompt Template

Created By: Saad Awais (https://github.com/imsaadawais)

Copy everything in the block below, list your features at the bottom, and give it to your agent.

--STEP 1

# Task
Plan the features listed at the bottom and save the plan to `Docs/<Feature-Name>-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.

## 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.

## Mermaid rules (VS Code renderer)
- Never put `\n` in a label; VS Code's renderer doesn't support it. Use `<br/>` 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 `<server>`.

## 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
<features>
1. 
2. 
</features>

 

---

7. Have the agent run a security review against the running application

Unit tests prove the code does what you told it to do. They don't prove nobody can make it do something else. Once the application is built and verified, I have the agent do a full security review using the Security Template below.

The important part is that the review is done against the running application, not just the source. Because the project uses Microsoft Aspire and the agent can pause at the sign-in page for me to log in,

it can actually try the things it finds: hitting endpoints without the right role, posting to pages it shouldn't reach, and checking the headers that come back.

The template does a few things on purpose:

• It asks questions first. Deployment target, authentication provider, whether the app is internet-facing, and compliance requirements change what counts as a problem.
• It only reports what is in your code. No generic best-practice lists.
• It has an exclusions list. My private repos keep keys and connection strings in appsettings.json on purpose, so the template tells the agent not to flag them. Add your own accepted risks to that list.
• Every finding is actionable. Each one has an ID, a severity with a reason, the OWASP category, the vulnerable code, the fixed code, and verification steps.
• It ends with a phased remediation plan (Immediate, Short-term, Long-term) that the agent can implement directly.

The output is a Markdown file, Docs/SecurityReview.md. Like every other Markdown file in this workflow, I read it and edit it before any code changes. Then I tell the agent to implement the Immediate phase,

run the application, and use each finding's verification steps to prove the fix works. After that, I have it update the status of each finding in the same file.

 

The Security Template

Paste this into the agent. Replace <add additional exclusions here> with your own accepted risks, or delete that line.

Task:
Perform a security review of the .NET Core web application in this repository.
Create a Markdown file and save it in the Docs/ directory (e.g., Docs/SecurityReview.md).
The file should contain a detailed, structured security assessment and a remediation plan
for every issue found, covering the review areas listed after this instruction.

Requirements:
Use clear section headings.

Review the actual source code, configuration files (appsettings*.json, launchSettings.json,
Program.cs, Startup.cs if present), .csproj files, and any client-side code (Razor, Blazor,
JavaScript). Do not report generic best practices unless they apply to code that exists
in this repository.

Do NOT flag API keys, connection strings, passwords, tokens, or other secrets stored in
appsettings*.json, launchSettings.json, or other configuration files. Storing these values
inline is an intentional decision for this private repository. Do not recommend moving them
to User Secrets, environment variables, or Azure Key Vault, and do not include them in the
findings, severity counts, or remediation plan.

For each finding, include:
- A unique ID (e.g., SEC-001)
- Title
- Severity (Critical, High, Medium, Low, Informational) with a one-sentence justification
- Category (mapped to the OWASP Top 10 2021 category where applicable)
- Affected file(s) and line numbers or member names
- Description of the issue and how it could be exploited
- The vulnerable code snippet
- A recommended fix with a corrected code snippet
- Verification steps (how a developer can confirm the fix works)

Include Mermaid diagrams to illustrate:
- System structure (components, trust boundaries, external services, data stores)
- Authentication and authorization flow
- Request pipeline / middleware order as it exists in Program.cs
- Data flow for any high-severity finding, showing where untrusted input enters and where it is used

Do not put \n inside Mermaid node labels — VS Code's Mermaid renderer doesn't support that.
Do not start edge labels with a number followed by a period, such as "1. User logs in"
— Mermaid's renderer interprets 1. as a markdown numbered list inside the label.
Use "Step 1 - User logs in" or "(1) User logs in" instead.

Include a summary table near the top listing all findings by ID, title, severity, and status.

Include a prioritized remediation plan that groups fixes into phases
(Immediate, Short-term, Long-term) with enough detail that a developer could begin
implementing the fixes based on this document alone.

Use Markdown formatting throughout.

Do not include any file-system commands; simply output the Markdown content.
Do not modify any source code as part of this task.

Output Format:
Return only the contents of the .md file, starting with a top-level # heading.

Suggested document structure:
# Security Review - <Application Name>
## Executive Summary
## Scope and Methodology
## Accepted Risks and Exclusions
## Architecture Overview (with Mermaid diagram)
## Findings Summary Table
## Detailed Findings (grouped by review area)
## Remediation Plan (Immediate / Short-term / Long-term)
## Recommended Security Tests
## Appendix: Package Vulnerability Report

Questions:
If you have any questions, please ask me using the chat window before you create the review.
Only ask if you find gaps after reviewing the Review Areas below, OR ask clarifying questions
to make sure I am not missing anything important (for example: deployment target,
authentication provider, whether the app is internet-facing, compliance requirements).

Accepted Risks and Exclusions:
List these in the "Accepted Risks and Exclusions" section of the document. Do not report
them as findings.
- Secrets, API keys, connection strings, and credentials in appsettings*.json,
  launchSettings.json, and other configuration files are intentional for this private
  repository.
- <add additional exclusions here>

Review Areas to document:

1. Authentication
   - ASP.NET Core Identity / external provider configuration (Entra ID, OAuth, OIDC)
   - Password policy, lockout settings, 2FA support
   - Cookie settings (HttpOnly, Secure, SameSite, expiration, sliding expiration)
   - JWT validation parameters (issuer, audience, lifetime, signing key strength)

2. Authorization
   - Missing [Authorize] attributes on controllers, pages, Blazor components, and minimal API endpoints
   - Improper use of [AllowAnonymous]
   - Role and policy definitions and enforcement
   - Insecure Direct Object References (IDOR) — verify resource ownership checks
   - Authorization enforced server-side, not only hidden in the UI

3. Injection
   - SQL injection via FromSqlRaw, ExecuteSqlRaw, ADO.NET string concatenation, Dapper
   - Command injection (Process.Start with user input)
   - LDAP, XPath, and path traversal (Path.Combine with user input, file downloads/uploads)
   - Prompt injection where user input is passed to LLM / AI services

4. Cross-Site Scripting (XSS)
   - Html.Raw, MarkupString, innerHTML via JS interop
   - Unencoded output in JavaScript contexts
   - Rendering of AI-generated or user-generated content

5. Cross-Site Request Forgery (CSRF)
   - Antiforgery token validation on forms and state-changing endpoints
   - [IgnoreAntiforgeryToken] usage
   - Cookie-authenticated APIs exposed to cross-origin calls

6. Configuration and Secrets Handling
   - (Excluded: secrets stored in appsettings*.json and other configuration files — do not flag)
   - Secrets hard-coded directly in C#, Razor, or JavaScript source files
   - Secrets written to logs, exception messages, or returned in API responses
   - Secrets or configuration values exposed to the client (e.g., Blazor WebAssembly
     wwwroot/appsettings.json, JavaScript bundles, or rendered pages)
   - Environment-specific settings (Development settings leaking to Production)

7. HTTP Security and Middleware
   - HTTPS redirection and HSTS
   - Security headers (Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy)
   - CORS policy (AllowAnyOrigin combined with credentials, overly broad origins)
   - Middleware ordering (UseAuthentication before UseAuthorization, etc.)
   - Developer exception page and detailed errors enabled outside Development

8. Data Protection and Cryptography
   - Data Protection key storage and persistence
   - Weak algorithms (MD5, SHA1, DES, ECB mode), hard-coded IVs or salts
   - Insecure random number generation (System.Random for security values)
   - Sensitive data stored unencrypted

9. File Uploads and Downloads
   - File size limits, extension and content-type validation
   - Storage location (inside wwwroot vs. outside)
   - Filename sanitization and path traversal

10. Input Validation and Model Binding
    - Missing model validation (ModelState.IsValid, DataAnnotations, FluentValidation)
    - Over-posting / mass assignment (binding directly to EF entities)
    - Unsafe deserialization (TypeNameHandling in Newtonsoft.Json, BinaryFormatter)

11. Logging, Error Handling, and Monitoring
    - Sensitive data (PII, tokens, passwords) in logs
    - Stack traces returned to clients
    - Audit logging for security-relevant events (login, permission changes, deletes)

12. Rate Limiting and Denial of Service
    - Rate limiting on login, password reset, and expensive or AI-backed endpoints
    - Request size limits, unbounded queries, missing pagination
    - Blazor Server circuit and SignalR message size limits

13. Server-Side Request Forgery (SSRF)
    - HttpClient calls using user-supplied URLs
    - Allow-listing of outbound hosts

14. Dependencies and Supply Chain
    - Vulnerable or outdated NuGet packages (as reported by dotnet list package --vulnerable)
    - Outdated target framework / end-of-life .NET versions
    - Client-side libraries loaded from CDNs without Subresource Integrity

15. Blazor-Specific Concerns (if applicable)
    - Sensitive logic or secrets in Blazor WebAssembly client code
    - JS interop exposing unsafe operations
    - Authorization state checks in components vs. server enforcement

16. Azure / Hosting Concerns (if applicable)
    - Managed Identity usage vs. keys (do not flag keys stored in configuration files)
    - Storage account, Key Vault, and database firewall and access settings referenced in code
    - Forwarded headers configuration behind a reverse proxy

 

---

8. Have AI create the application user guide

The last thing nobody wants to write is the user guide. The agent is good at it for the same reason it is good at testing: it can run the application, click through every page, and take screenshots.

It also reads the code, so the troubleshooting section quotes the actual error messages a user will see instead of guessing at them.

For Aspire Deploy, the agent wrote docs/User-Guide.md with the same sections as the in-app Guide page: what you need before you start, how it works, numbered tasks in the order you do them, and troubleshooting.

When the UI was redesigned, I had it refresh the screenshots.

Two rules matter here. First, the agent must run the application and not write the guide from the code alone, or it will document what the code seems to do. Second,

it must keep secrets, real resource names, and personal data out of the text and the screenshots.

The User Guide Template

Task:
Create an end-user guide for the application in this repository.
Save it as Docs/User-Guide.md.

Requirements:
Write for the people who will use the application, not for developers.
Do not describe code, classes, or project structure.

Base the guide on the application as it actually exists:
- Read the Razor pages, components, navigation menu, and settings to find every screen and feature.
- Run the application and walk through every page and workflow yourself.
- If the application requires sign-in, pause at the sign-in page and wait for me to log in,
  then continue using that session.
- Capture a screenshot of each screen and each important step. Save them in
  Docs/images/user-guide/ and reference them from the Markdown with relative links.
- Do not document features that do not exist, and do not leave out features that do.

Use this structure:
# <Application Name> user guide
## Before you start
   - What the user needs first: accounts, roles or permissions, software, data.
## How it works
   - A short plain-language overview and one Mermaid diagram of the main workflow.
## Numbered task sections (## 1. ..., ## 2. ...)
   - One section per task, in the order a new user would do them.
   - For each task: when to use it, numbered steps, what the user should see afterwards,
     and a screenshot.
## Troubleshooting
   - A table with Symptom, Cause, and Fix. Build it from the real validation and error
     messages in the code, quoting the message text the user will see.
## Frequently asked questions (only if there are real questions to answer)

Rules:
- Use short sentences and bold the names of buttons, menus, and fields exactly as they
  appear on screen.
- Use placeholders such as <resource-group> or <your-email> instead of real names.
  Do not include passwords, keys, tokens, connection strings, real hostnames, IP addresses,
  or personal data, even if they appear on screen. Blur or crop them out of screenshots.
- Do not put \n inside Mermaid node labels, and do not start edge labels with a number
  followed by a period. Use "Step 1 - Sign in" or "(1) Sign in" instead.
- If the application has an in-app Help or Guide page, use the same section headings and
  anchors so the page and this document stay in sync. If it does not, suggest one at the
  end of your chat reply, but do not create it.
- Do not modify any source code as part of this task.

Questions:
Before you write the guide, ask me in the chat window about anything you cannot determine
from the code or the running application (for example: who the users are, which roles
they have, which features are still in preview).

Output Format:
Return only the contents of the .md file, starting with a top-level # heading.

---

Commentary: The workflow that never sits still

I sometimes get frustrated that we can't seem to settle on the workflow during this rapidly advancing agentic coding revolution. I find myself adapting my workflow weekly,

and sometimes daily. The techniques, the tools and the models all keep changing. It's hard not to miss the predictable workflow we had in the past.

But I've come to think this is actually a positive.

It shows where the human programmer will always be needed. The ecosystem and structure around these AI models, harnesses and tools has to be put together and driven by a human,

someone who brings the initiative and the desire to produce something in the first place.

The ability to do that, and the efficiency to understand and exploit the constantly changing tools and abilities of every part of the ecosystem, is what the programmer brings to the effort.

That will keep changing, and it will keep needing a human brain, with human desires, to direct it and make the decisions.

This is why computers won't replace humans. Humans have a job that only they can do.

This is what I now accept as the job of a programmer.

---

Putting it all together

1. Run the prompt template. Answer the agent's questions.
2. Refine the master MD file in docs until I'm happy with the whole application, end to end.
3. Have the agent create the sub-MD files. Review and adjust them.
4. Have Claude write a Stitch with Google prompt, generate the mockups, and put them in docs.
5. Make sure the project uses Microsoft Aspire, so the agent has a complete, isolated environment.
6. Tell Claude Opus 5.5 (low effort) to code from the MD files and mockups, run the program, and verify everything, pausing when it needs me to log in.
7. Let it run, possibly for hours.
8. Run the Security Template against the running application, review Docs/SecurityReview.md, then have the agent fix and verify each phase.
9. Run the User Guide Template to create Docs/User-Guide.md with screenshots.

That is how I'm able to create massive applications in one to two days.