Working with a large codebase using an LLM is a game-changer, but it requires a disciplined approach. Think of the LLM not as a magic black box, but as a brilliant, yet over-confident, junior developer. To get the best out of this partnership, you need a clear, structured workflow, strong communication, and a robust quality assurance process.
Here is a practical guide to help you master this new way of working.
The Three-Phase AI Development Workflow
Adopt a disciplined Research → Plan → Implement workflow. This structured process prevents the LLM from going off-track and gives you key checkpoints for human review.
Research Phase
Before writing any code, instruct the LLM to analyze your existing codebase. Ask it to identify key patterns, architectural decisions, and dependencies. For example, in Claude Code, you can use /init that will generate an overview of your project. But for better results, try to point at specific folders and other repositories for the LLM to make connections and have a better picture.
Init the project first: /init in Claude (it will create a CLAUDE.md file)
Then:
Analyze how the login feature works. It communicates with the rate limiter service at `/path/to/rate-limit-service`
Its deployment code is at `/path/to/cicd`
Planning Phase
Use the LLM to write a detailed technical specification or plan. This is a crucial step for managing complexity.
- Don't allow the LLM to start implementing until you get a satisfactory answer. Some LLMs have a "Read-only" mode. Brainstorm with it until you're satisfied with the direction.
- Ask the LLM for clarification, "Ask me clarifying questions about this feature before you start writing the plan." This forces it to verify its assumptions and can prevent major misinterpretations and avoid it going in the wrong direction.
Here's what it would look like:
Help me to implement [your feature] for the [your service] service.
Ask me any questions before it gets started for anything that's not concrete and specific enough in the plan.
Don't start implementing until we agree to start.
Implementation Phase
Work in small, atomic chunks. Avoid giving the LLM massive, multi-faceted tasks. Break down a feature or bug fix into smaller, isolated sub-tasks. This keeps the context window manageable and makes it easier to catch and correct mistakes.
If you're using Claude, a great guide on using the plan mode is working with Claude Code.
Context Management Strategies
The context window is a key constraint when working with LLMs. You must actively manage it to get reliable results.
Provide Rich Context
Use code and documentation as context. LLMs can (and will) hallucinate without it. Provide the LLM with relevant code snippets, design documents, and API documentation. This gives it the specific, structured information it needs to produce accurate code.
Some MCP servers like Context7 can be connected to your favorite LLM. Set it up and ask your LLM to look it up when planning.
More and more documentation provide llm.txt docs. Look for it and paste it inside your LLM. More and more websites expose the /llms.txt endpoint. For example Stripe or Cloudflare.
If there is no friendly LLM version yet, use tools like gitingest.com for repositories or llm.codes for Apple documentation.
Be careful on Context Management
The context window is a key constraint. Use tools that can automatically summarize conversation history or manually manage context by storing important information in markdown files. Store important context in markdown files that persist across sessions. or Use git commit messages as context storage.
Most of the time, after a brainstorming session, your context will already be bloated. It's good to restart a fresh session then read the plan file you've created.
I always make sure to never go over 50% of the context (/context). If that's over this, I usually don't trust the output, and restart the session.
Never use auto-compact features (/compact in Claude). It works blindly—manually control what gets summarized. We don't know what the LLM removes from the context. It's better to start fresh from a new session and read the markdown files created than auto-compacting.
This is how I do it:
Before implementing, write down in `plan.md`:
1. **Architecture Plan** - tech stack, key decisions, and why
2. **Structured Todo List**
Break down the implementation into the smallest atomic units that allow it to run without input
- Phase 1: ...
- Phase 2: ...
When starting the implementation:
Read `plan.md` and start implementing phase [x]. Make sure to add Session Recovery Notes.
Including detailed notes about:
- Current project state and what's been completed
- Any critical decisions made so far
- Where to resume if this session crashes
Effective AI Communication
Think of yourself as a strong manager for your AI assistant. The clearer your instructions, the better the output will be.
Be a Good Manager for your AI
Think of yourself as managing a junior engineer. Provide clear, unambiguous instructions. Use strong, imperative language like "must," "critical," and "never" to set clear guardrails. Be specific about the desired behavior of the code, not the implementation details.
Encourage Questioning and have multiple options
A powerful technique is to instruct the LLM to ask clarifying questions before it starts generating code. This forces it to verify its assumptions and can prevent it from misinterpreting your intent. Sometimes (or most of the time) you also won't agree with the plan. Ask for multiple options:
Give me multiple options on how to solve the problem.
Ask me any questions before it gets started for anything that's not concrete and specific enough in the plan.
Quality Assurance Framework
Leverage Automation to Enforce Quality
Don't skip code reviews. Instead, change what you review. Use automated tools like pre-commit hooks, linters, and test suites to verify the LLM's output. The LLM can even be instructed to run these checks itself and fix any errors or check the tests.
At each phase implementation, call the `lint` and `compile` and `test` commands
Human Oversight
Always verify the LLM's work, especially in critical sections of the codebase. Be skeptical of "it compiles and runs" without functional testing.
Final Quality Pass
Clean up generated code in a final pass once functionality works. This ensures it adheres to team standards for readability and maintainability.
Implementation Guidelines
Start Small, Scale Up
Start with smaller features to build confidence in your process. Test your workflow on non-critical components first, then gradually increase complexity as you refine your approach.