Scope and Conversation Management

Why Projects Go Sideways

By the time you reach this guide, you know how to prompt, iterate, review code, and write documentation. You've built things that work. The challenge now is keeping them working as the project grows.

Most AI-directed projects don't fail because of bad code. They fail because of scope creep (the project keeps expanding beyond what was planned) and context degradation (the conversation gets too long and the AI loses track of earlier decisions).

These are management problems, not coding problems. And they have management solutions.

Context Window Management

The Problem

Every AI has a context window — a limit on how much text it can process at once. Think of it as the AI's total working memory for the entire conversation. When you hit the limit, the AI starts silently dropping earlier messages. It doesn't tell you. It just forgets.

Symptoms of a degraded context window:

• AI contradicts decisions made earlier in the conversation
• AI re-introduces code or patterns you explicitly rejected
• AI "forgets" your tech stack and uses different libraries
• AI generates code that conflicts with what it wrote previously
• Quality of responses noticeably drops

The Solution: Conversation Hygiene

Keep it to one feature per conversation.

Don't build your entire application in one chat. Separate conversations by feature or component:

Chat 1: Project setup + database schema
Chat 2: Authentication (login, register, sessions)
Chat 3: Dashboard UI
Chat 4: API endpoints for data
Chat 5: Testing and bug fixes

Each chat starts with your requirements docs attached, so the AI has full context without needing to "remember" previous conversations.

Know when to start fresh.

End each chat with a summary.

Before closing a productive chat, ask:

Before we wrap up, summarize what we built in this session:
1. What files were created or modified
2. What decisions were made and why
3. What's left to do next
4. Any issues or TODOs that need attention

I'll use this summary to start the next session.

Save this summary. Paste it at the start of your next chat. It's a handoff note that bridges the gap between conversations.

Test the AI's memory — don't ask it to self-report.

Here's something most people don't realize: the AI has no idea how much context it has left. It can't check its own token count. If you ask "what percentage of your context window is remaining?" it will confidently make up a number — "about 62%" — and you'll plan around fiction.

Instead, quiz it. Ask the AI to recall specific details from earlier in the conversation:

Before we continue, repeat back to me:
1. The exact data schema we're using (field names and types)
2. The three technical constraints we set at the start
3. What files we've modified so far and what each change did

If it nails the details, the context is solid. If it hallucinates a field name, forgets a constraint, or gets vague about what you've been working on — the window is degrading and it's time to start fresh.

When to quiz:

• After 15–20 back-and-forth exchanges
• Before starting a complex subtask late in a conversation
• After a big refactor or multi-file edit (these eat context fast)
• Whenever the responses start feeling less sharp

Think of it like a pop quiz, not a fuel gauge. You're not asking the AI how it feels — you're checking what it actually knows.

Scope Management

Feature Creep — The Quiet Killer

You start building a "simple to-do app." Three chats later, you're implementing team collaboration, recurring tasks, notification systems, and a mobile app. None of this was in your original plan.

How it happens: You get excited. The AI makes things feel easy. Each new feature takes "just one more prompt." But each addition makes the codebase more complex, creates more potential bugs, and moves you further from a working, shippable product.

The BRD Is Your Scope Contract

This is why the Plan Before You Build workflow matters so much. Your BRD defines what's in scope for v1. When you're tempted to add something, ask:

Is this in the BRD?
├── Yes → Build it
└── No
    ├── Is it critical for v1?
    │   ├── Yes → Update the BRD first, then build
    │   └── No → Add to "Future Features" list, move on
    └── Am I adding it because it's cool or because users need it?
        ├── Cool → Future Features list
        └── Users need it → Update the BRD, reassess scope

The key habit: if it's not in the docs, it doesn't get built until the docs are updated. This prevents features from sneaking in without being properly thought through.

The MVP Discipline

Ship the simplest version that works, then improve from there. This is harder than it sounds because AI makes adding features feel cheap. But each feature adds:

• More code to maintain and debug
• More potential for bugs
• More complexity for the AI to track
• More time before you have a working product

The question isn't "Can we add this?" — it's "Should we add this before we ship?"

Managing Multiple Files and Components

As your project grows beyond a few files, you need to be deliberate about how you direct the AI:

Always Provide File Context

❌ "Fix the login bug"
✅ "Fix the login bug in src/routes/auth.js.
   Here's the current code: [paste]
   Here's the error: [paste]
   The User model is defined in src/models/User.js: [paste relevant parts]"

In a chat interface, the AI can't see your file system — every file it needs must be explicitly provided. In an IDE like Cursor or Antigravity, the AI can index your codebase automatically, but it still benefits from knowing which files are relevant to the current task.

Use a File Map

For larger projects, maintain a simple map that you can paste at the start of each chat:

Project structure:
/src
  /routes     - API endpoints (auth.js, users.js, posts.js)
  /models     - Database models (User.js, Post.js)
  /middleware - Auth middleware, error handling
  /utils      - Helper functions, validators
  /tests      - Test files mirror src structure

Database: PostgreSQL
Auth: JWT tokens stored in httpOnly cookies
API: RESTful, all routes prefixed with /api/v1

This 10-line summary gives the AI more useful context than a 200-message conversation history.

Putting It All Together

Here's what a typical daily workflow looks like once you've got the hang of it:

Starting a Session

1. Open a new chat
2. Attach relevant requirements docs
3. Paste the summary from the last session
4. State clearly what you're building today

During Development

5. Ask for one feature or fix at a time
6. Review every response against the BRD
7. Give specific feedback using the iterate loop
8. Commit working code after each feature (Git)

Ending a Session

9. Ask AI for a session summary
10. Save the summary
11. Commit and push to Git
12. Note any items for the next session

When Things Go Wrong

13. If the conversation degrades → start fresh with docs
14. If features are creeping → check the BRD
15. If bugs are cascading → read When to Start Over

The Long Game

The skills in this guide aren't flashy. Context management and scope discipline sound boring compared to "generate an entire app with one prompt." But they're the difference between someone who builds a demo and someone who ships a product.

The tools are easy. The discipline is hard. But the projects that ship aren't the ones with the most code — they're the ones with the most discipline. Manage your context, manage your scope, and the code takes care of itself.