The Complete AI Vibe Coding Framework (Part 2)

 From Planning to Production: Mastering the Blueprint, Forge & Vault

"A Product Requirements Document tells you what to build. The next three stages determine how you actually build it."

Author: Abhinav Chowdary

Series: The AI Coding Series — Part 2

Table of Contents

• Introduction
• Stage 2 - Blueprint: Plan Before You Build
• Applying Blueprint to NoteHive
• Stage 3 - Forge: Build With Focus
• Applying Forge to NoteHive
• Stage 4 - Vault: Capture Ideas, Protect Momentum
• Applying Vault to NoteHive
• Keeping Everything Together
• Key Takeaways
• What's Next?

Introduction

Welcome back.

In Part 1, we created the Genesis Doc for our project, NoteHive.

We identified:

• The problem
• The target users
• The core features
• The user flow
• The technology stack
• The definition of done

At this point, many developers make a mistake. They immediately open ChatGPT, Claude, Gemini, Cursor, Antigravity, or whichever AI tool they're using and type: Build my application.

And surprisingly, the AI starts building it. For the first few prompts, everything feels amazing. The login page appears. The dashboard appears. The backend appears. The database appears. It feels like you're building software at lightning speed. Then reality arrives. The authentication breaks when you add search. The search breaks when you add AI summaries. The database schema changes three times. The frontend and backend stop agreeing with each other.

And suddenly you're spending more time fixing AI-generated mistakes than building features. The problem isn't the AI. The problem is that we skipped the stages between planning and implementation. In this article, we're going to continue building NoteHive using the next three stages of the AEN Build Loop:

• Blueprint
• Forge
• Vault

We'll also use the same approach I personally use when building projects with AI tools such as Antigravity.

By the end of this guide, you'll know how to transform a Product Requirements Document into a working application without drowning in context windows, token usage, and endless rewrites.

Let's begin.

Stage 2 — Blueprint

Plan Before You Build

The Blueprint is the bridge between an idea and a working product. Think about building a house. The Genesis Doc gave us the architectural requirements. It answered questions such as:

• What are we building?
• Who is it for?
• What features should it have?

The Blueprint answers a completely different question: How exactly are we going to build it?

Without a Blueprint, the AI is forced to guess. And every time AI guesses, there's a chance it's guessing wrong. That's where wasted tokens, broken code, and endless iterations come from.

Step 1 — Define the MVP

One of the biggest mistakes developers make is trying to build everything at once. When we created the Genesis Doc for NoteHive, we identified several possible features:

• Upload notes
• Search notes
• Generate AI summaries
• Generate quizzes
• Ratings
• Comments
• Professor verification
• Study groups
• AI recommendations
• Flashcards

Should we build all of them? Absolutely not. Our MVP only needs enough functionality to prove that the product solves the original problem. For NoteHive, that means:

1. User Authentication
2. User Profiles
3. Upload Notes
4. Search Notes
5. AI Summary Generation
6. AI Quiz Generation

Everything else goes into future versions. A good MVP answers one question: Does this product provide value to users?

If the answer is yes, we can improve it later.

Step 2 — Break the Project into Phases

Now we convert the MVP into development phases.

Phase 1 — Foundation

Features:

• User Registration
• User Login
• JWT Authentication
• User Profiles
• Protected Routes

Definition of Done: A user can create an account, log in, and access protected pages.

Phase 2 — Notes System

Features:

• Upload Notes
• Cloudinary Integration
• Categories
• Search

Definition of Done: Users can upload notes and retrieve them using search.

Phase 3 — AI Layer

Features:

• AI Summaries
• AI Quiz Generation

Definition of Done: Users can upload notes and generate useful summaries and quizzes.

Phase 4 — Engagement Layer

Features:

• Ratings
• Comments
• Leaderboards

Definition of Done: Users can interact with and evaluate notes.

Step 3 — Create the Project Structure

Before generating code, we define the structure.

client/
server/
├── controllers
├── routes
├── middleware
├── models
├── services
├── utils
└── config

Why? Because changing architecture later is expensive. Changing architecture before writing code is almost free.

Step 4 — Design the Database

For NoteHive we need:

Users Collection

Stores:

• Name
• Email
• Password
• College
• Profile Image

Notes Collection

Stores:

• Title
• Description
• Subject
• File URL
• Uploaded By

Ratings Collection

Stores:

• User
• Note
• Rating

Comments Collection

Stores:

• User
• Note
• Comment

Planning relationships before development prevents major redesigns later.

Step 5 — Plan APIs

Before implementation, we define the API contract.

Examples:

POST /auth/register
POST /auth/login

POST /notes
GET /notes
GET /notes/:id

POST /notes/:id/summarize
POST /notes/:id/quiz

Now everyone including the AI knows exactly how the system communicates.

Applying Blueprint to NoteHive

This is where Antigravity becomes powerful. Instead of asking: Build NoteHive.

We ask:

"Act as a Senior Software Architect.

Using the Product Requirements Document (PRD) provided, create a complete implementation roadmap for the project.

Break the implementation into multiple development phases.

For each phase, provide the following details:

1. Objective
   • The primary goal of the phase.
   • What business or technical problem this phase solves.
2. Features
   • List all features to be implemented in this phase.
   • Include both user-facing and backend/system features.
3. Dependencies
   • Prerequisites required before starting this phase.
   • External services, libraries, infrastructure, or previous phases that this phase depends on.
4. Folder Structure
   • Recommended project folder structure relevant to this phase.
   • Include frontend, backend, database, infrastructure, and shared modules where applicable.
5. Database Changes
   • New collections/tables to be created.
   • Schema modifications.
   • Relationships, indexes, constraints, and migration requirements.
6. API Endpoints
   • Endpoints introduced in this phase.
   • HTTP method.
   • Purpose of the endpoint.
   • Request and response overview.
7. Definition of Done
   • Clear completion criteria for the phase.
   • Functional requirements completed.
   • Testing requirements completed.
   • Documentation requirements completed.
   • Deployment readiness requirements completed.

Additional Requirements:

• Start with a high-level project overview.
• Include architecture evolution across phases.
• Identify risks and technical considerations for each phase.
• Keep the roadmap implementation-focused.
• Do not generate any source code.
• Do not generate UI designs.
• Focus exclusively on planning, architecture, development sequencing, and execution strategy.
• Present the roadmap in a structured and detailed manner suitable for engineering teams.

Do not generate code yet focus on only planning."

Notice something important. We're still not writing code. We're removing ambiguity. That's the entire purpose of the Blueprint.

Stage 3 - Forge

Build With Focus

Now the coding begins. This is where most AI projects either succeed or collapse. The mistake most developers make is simple: They build the entire application inside one conversation.

At first it works. Then the context becomes enormous. The AI starts modifying unrelated files. Features begin breaking each other. Token costs increase. Productivity drops.

The Forge solves this with one rule: One Phase. One Chat. One Goal.

Example

Suppose we're building Phase 2 of NoteHive. That phase only contains:

• Upload Notes
• Search
• Categories
• Cloudinary Integration

That's all the AI sees. It does not need authentication files. It does not need AI summary code. It does not need future features. By reducing context, we increase accuracy.

Git Strategy

Another habit that dramatically improved my workflow was committing after every completed phase.

Example:

git add .
git commit -m "Complete Phase 2 - Notes Upload & Search"

Why? Because AI makes mistakes. Sometimes those mistakes are spectacular. A clean Git history allows us to roll back safely.

Testing Every Phase

Before moving forward:

• Test uploads
• Test search
• Test API responses
• Test edge cases

Never assume generated code works. Verify it.

Applying Forge to NoteHive

Prompt:

You are helping me build Phase 2 of NoteHive.

Objective:
Implement note upload, categories, Cloudinary integration, and search.

Current Files:
[Paste relevant files]

Constraints:

- Do not modify authentication.
- Do not create future features.
- Only implement Phase 2 requirements.

Before writing code:
Explain the architecture and implementation plan.

Notice how focused this prompt is. The AI knows exactly what phase it's building. Nothing more. Nothing less.

Stage 4 — Vault

Capture Ideas, Protect Momentum

This is one of the most underrated stages in the entire framework. While building NoteHive, new ideas constantly appear. For example:

• Flashcards
• Study Groups
• Professor Verification
• AI Recommendations
• Collaborative Notes

Most developers immediately start building them. That's a mistake. Every new feature creates:

• More code
• More bugs
• More testing
• More complexity

Instead, we store the idea. That's the Vault.

Building the NoteHive Vault

Example:

Feature	Priority	Complexity
Flashcards	High	Medium
AI Recommendations	High	Medium
Professor Verification	Medium	High
Study Groups	Low	High

Nothing gets lost. Nothing interrupts development.

Applying Vault to NoteHive

Prompt:

Act as a Product Manager.
Organize the following feature ideas into:
- Must Have
- Should Have
- Could Have
- Won't Have Yet
Estimate:
- Business Value
- Complexity
- Development Time
Help me prioritize future development.

The Vault ensures we're improving the product intentionally instead of emotionally.

Keeping Everything Together

At this point our workflow looks like this:

Idea -> Genesis -> Blueprint -> Forge -> Vault

The Genesis removes uncertainty. The Blueprint removes confusion. The Forge removes implementation friction. The Vault removes feature creep.

Key Takeaways

• A Blueprint transforms ideas into an actionable roadmap.
• The Forge keeps AI focused through isolated development phases.
• Git commits are your safety net.
• Testing after every phase prevents major failures later.
• The Vault captures good ideas without destroying momentum.
• Great AI-assisted development is a process, not a prompt.

What's Next?

In Part 3, we'll complete the AEN Build Loop with the final three stages:

Stage 5 — Vault Sprint

Turning stored ideas into meaningful product improvements.

Stage 6 — Crucible

Testing, optimization, security reviews, and bug fixing.

Stage 7 — Launchpad

Deployment, documentation, demos, and presenting your project to the world.

By the end of Part 3, you'll have a complete framework for taking an idea from concept to a production-ready product using AI.

Part-3: link
You can follow me in:  LinkedIn, GitHub, Instagram

— Abhinav, Abhinav Engineering Notes