This project demonstrates AI-assisted development using spec-kit with the AIDE extension in GitHub Copilot (VS Code). Starting from an empty directory, a full-stack web application — Spring Boot 4 backend with an embedded React 19 frontend — was scaffolded and built entirely through structured agent workflows invoked from VS Code's Copilot Chat panel. The steps below document exactly what was done — you can follow the same process to build your own projects.

Note on the workflow: This is a greenfield project. There is no pre-existing codebase — the AIDE extension generates vision, roadmap, progress tracking, work queues, and individual work items from scratch, then executes them one by one. The workflow is iterative: create an item, execute it, create the next.

• uv — Python package manager used to install spec-kit
• GitHub Copilot — VS Code extension with chat panel
• Java 25 — required to build and run the Spring Boot backend
• Maven — build tool (or use the Maven wrapper)
• Docker — required for the PostgreSQL database and containerized deployment

specify init . --ai copilot

This scaffolded the spec-kit structure and installed the Copilot custom agents.

specify extension add aide --from https://github.com/mnriem/spec-kit-extensions/releases/download/aide-v1.0.0/aide.zip

The AIDE extension adds a set of slash commands to Copilot Chat that drive a structured development lifecycle: vision, roadmap, progress tracking, work queues, work items, execution, and feedback loops.

The speckit.aide.create-vision agent was invoked from Copilot Chat:

/speckit.aide.create-vision

Create a web based trading platform that I can use for my personal and
family trades. Make sure we have it properly protected with logins. Make
sure it is mobile friendly so I can use it on the go. It must be
Dockerized running Spring 4, JDK 25 and with an embedded React frontend.
For database use PostgreSQL. As this is an MVP prototype do not heavily
lean on testing for now. Expand on this vision with what you think should
be added to the application to make it easy to use, insightful. Note I do
expect graphs, tables, lists, cards, recommendations etc.

This created docs/aide/vision.md — a comprehensive vision document covering goals, architecture, user experience, and testing philosophy. The agent expanded the initial prompt with additional features it deemed relevant for a family trading platform: portfolio analytics, performance dashboards, recommendation engines, and more.

/speckit.aide.create-roadmap

Execute

This created docs/aide/roadmap.md — a multi-stage development roadmap derived from the vision, breaking the project into ordered delivery stages.

/speckit.aide.create-progress

Execute

This created docs/aide/progress.md — a table tracking the completion status of every deliverable from the roadmap.

/speckit.aide.create-queue

Execute

This created docs/aide/queue/queue-001.md — a prioritized queue of the next batch of work items to implement, drawn from the roadmap's first stage.

/speckit.aide.create-item

Execute

This created the first work item in docs/aide/items/ — a detailed specification with acceptance criteria, implementation steps, dependencies, and verification instructions. The item covered the Spring Boot project scaffold (Maven, JDK 25, Spring Web/Data JPA/Security/Actuator).

After reviewing the generated item, the testing section was heavier than expected given the "lean on testing" directive from the vision:

In the vision I asked for lean on testing. Is this the minimal testing?

Copilot confirmed the testing section was too heavy for a scaffold item with zero business logic and trimmed it down.

/speckit.aide.feedback-loop

Show me feedback

The agent returned 4 recommendations for improving the work item. Crucially, the feedback loop doesn't just refine individual items — it refines the process itself. Recommendations can surface misalignments between the vision, roadmap, and generated artifacts, allowing the entire workflow to self-correct as you go. The recommendations were applied:

Apply the recommendations

/speckit.aide.execute-item

Execute

The agent implemented all deliverables from the work item specification, creating the project scaffold, configuration files, and Docker setup.

/speckit.aide.create-item

Execute

The second work item was created — Docker Compose setup (Spring Boot + PostgreSQL 17, volume, .env config).

/speckit.aide.execute-item

Execute

The second work item was completed.

/speckit.aide.create-item

Execute

The third work item was created — React 19 frontend scaffold (MUI 6, frontend-maven-plugin, static resources).

/speckit.aide.execute-item

Execute

The third work item was completed. The React frontend now builds via Maven and is served by the Spring Boot backend at http://localhost:8080.

The full AIDE workflow and how the feedback loop connects to every step:

flowchart TD
    A[1. Create Vision] --> B[2. Create Roadmap]
    B --> C[3. Create Progress]
    C --> D[4. Create Queue<br/>~10 items per batch]
    D --> E[5. Create Item<br/>Pick item & create spec]
    E --> F[6. Execute Item<br/>Implement & update progress]

    F -->|More items<br/>in queue| E
    F -->|Queue empty| D
    F -->|All stages<br/>complete| End[Project Complete]

    A -.-> G[7. Feedback Loop]
    B -.-> G
    C -.-> G
    D -.-> G
    E -.-> G
    F -.-> G
    G -.-> A
    G -.-> B
    G -.-> C
    G -.-> D
    G -.-> E
    G -.-> F

From this point forward, the workflow is a simple loop:

A. /speckit.aide.create-item "Execute"        — create the next work item
B. /speckit.aide.execute-item "Execute"       — implement it
C. /speckit.aide.create-queue "Execute"       — when the queue is empty, create the next batch

Rinse and repeat A, B, and C until all items are done.

If at any time you want to change the created work item, you can edit it manually before executing. If the process breaks down or produces unexpected results, use the feedback loop:

/speckit.aide.feedback-loop "Show me feedback"

Then apply any recommendations you think should be applied. The feedback loop is essential — it doesn't just improve individual artifacts, it allows the overall process to be refined. Patterns that don't work get caught and corrected, making each subsequent cycle smoother than the last.

This demo intentionally stops after the first three work items. The full roadmap contains dozens of deliverables across multiple stages — authentication, portfolio management, trade logging, dashboards, and more. The purpose here is to demonstrate the workflow, not to build the entire application. You can continue from where this left off by running the repeating cycle above until every item in the roadmap is complete.

A greenfield full-stack web application — Spring Boot 4 (JDK 25) backend with an embedded React 19 (MUI 6) frontend, PostgreSQL database, and Docker Compose orchestration — scaffolded and built entirely through structured agent workflows. The application serves the React UI directly from the Spring Boot backend at http://localhost:8080 with no separate frontend server required in production.

The vision prompt did most of the heavy lifting. The detailed initial prompt — specifying the tech stack, security requirements, mobile-friendliness, and UI expectations — gave the agents strong constraints from the start. This is the right approach: front-load context into the vision, and every downstream artifact benefits.

Work items could have been reviewed more carefully before execution. The first item had an overly heavy testing section that had to be trimmed after the fact. Reading each generated work item before executing it — and using speckit.aide.feedback-loop proactively rather than reactively — would catch these misalignments earlier.

Manual edits are fine. The work item specs are Markdown files. If a generated item doesn't match your intent, edit it directly before running execute-item. The agents will respect whatever is in the file — they don't assume their own output is immutable.

This walkthrough demonstrates that the AIDE extension for spec-kit can drive a complete greenfield development lifecycle — from a single vision prompt to a running full-stack application — through structured, repeatable agent workflows in VS Code. Each step produces a concrete artifact (vision, roadmap, progress tracker, work queue, work item) that feeds into the next, creating an auditable trail of decisions and deliverables.

The key insight: the agents are only as good as the context you give them. A detailed vision prompt produced well-structured downstream artifacts with minimal correction needed. The feedback loop is the mechanism that makes this sustainable — it doesn't just fix individual work items, it refines the process itself. Each round of feedback can surface systemic issues (overly heavy testing, misaligned scope, missing constraints) that improve every subsequent artifact, not just the current one.

For teams considering this workflow: treat the vision and work item review steps as investments, and use the feedback loop liberally. The few minutes spent refining each artifact before execution will save significantly more time than debugging misaligned implementations after the fact.

What if a work item doesn't execute correctly? Stay in the same chat session and keep talking to the agent until the issue is resolved. If execution missed something, tell it what's wrong — it will continue working. You don't need to re-run execute-item from scratch; just chat through the problem until the deliverable matches what you want.

What is the feedback loop for? Use /speckit.aide.feedback-loop "Show me feedback" at the end of a chat session — after a work item is done — to analyze what went well, what went wrong, and where human intervention was needed. It's a retrospective step that refines the process itself, not a debugging tool for in-progress work. The recommendations it surfaces improve the quality of future work items and reduce the need for manual correction over time. Don't forget to ask the agent to apply the recommendations you want it to apply!

What if I disagree with the generated vision or roadmap? Edit the Markdown files directly. They live in docs/aide/ and are plain text. After editing, re-run the agents from the level below the document you changed so downstream artifacts reflect your updates. For example, if you edit the vision, re-run create-roadmap, then create-progress, then create-queue, and so on. Changes don't cascade automatically — each downstream document needs to be updated by the agent.

What if the agent generates a work item I don't want? Work items are created from the descriptions in the queue, so the queue is where you intervene. Review the queue before running create-item — if you don't want an item, remove it from the queue. If the item is fine but the description is wrong, update the description in the queue so the generated work item reflects what you actually need. If you've already generated the work item, you can delete it from docs/aide/items/ and remove it from the queue. Running create-item again will then pick the next item in the queue. Alternatively, edit the work item directly before executing it.

What if I want to change the tech stack mid-project? It depends on whether it's a platform pivot. Swapping PostgreSQL for MongoDB, replacing React with Angular, or moving from Spring Boot to Quarkus are platform pivots — once you have code, that's a migration, not a fresh build. Your project is now brownfield. Restart with the AIDE in-place migration preset (soon to be released) from create-vision to perform the migration as its own structured workflow before you continue adding new features.

If the change isn't a platform pivot — adding features, expanding scope, evolving the vision, even significantly — just update the vision and roadmap documents, re-run the downstream agents, and continue the normal cycle. As long as you're building on the same platform, the existing new workflow handles it.

What if the execution introduces a bug? Fix it in the same chat session — you're already there while executing the work item, so keep talking to the agent until it's resolved. Once fixed, continue the cycle. If the bug pattern suggests a systemic issue, use the feedback loop at the end of the session to surface it so future items avoid the same mistake.

What if I want to add something not in the roadmap? Edit docs/aide/roadmap.md and docs/aide/progress.md to include the new deliverable. The next queue generation will pick it up. Alternatively, create a work item manually in docs/aide/items/ and execute it.

Can I run multiple items in parallel? Yes, but you'll need to isolate their environments — for example, using Dev Containers or Docker — to avoid conflicts. You'll also need to specify the queue and work item numbers explicitly so parallel executions don't trample on each other by picking the same next item.

Does this work for brownfield projects? Not out of the box. The AIDE extension's default workflow (shown in this demo) is designed for greenfield projects. For brownfield scenarios, AIDE presets (soon to be released) will tailor the workflow for each scenario:

• Feature development — adding new features to an existing project
• Bug-fixing — diagnosing and fixing bugs with root cause analysis and regression testing
• Addressing technical debt — improving code design and quality while keeping the same technology stack
• In-place migration — replacing one technology with another within the existing codebase
• Side-by-side migration — rebuilding with old and new codebases coexisting on disk during development

What are Spec Kit presets? Presets layer on top of the AIDE extension, shaping what the agents produce by overriding and/or augmenting the templates and commands that guide them. Each preset provides at minimum its own 7 prompts covering vision through execution and feedback. Beyond development scenarios, presets can also encode company practices, industry standards, or regulatory requirements. For more information, see Making Spec Kit Your Own: Extensions & Presets in the Spec-Kit README.