“We need to add multi-tenant support.”
Six words. Weeks of work hidden inside them. And the hardest part isn’t the coding — it’s figuring out what those six words actually mean in terms of database changes, API modifications, auth updates, migration scripts, and configuration management.
This is planning. The phase most developers rush through because it doesn’t feel like “real work.” But it’s the phase where the most expensive mistakes happen, and it’s where AI is secretly one of the most useful tools in your arsenal.
Why planning with AI works
Developers are good at solving well-defined problems. We’re often terrible at converting vague requirements into well-defined problems. That conversion process — decomposition — is a skill that takes years to develop and still fails under time pressure.
AI is surprisingly good at it. Not because it has better judgment than you — it doesn’t. But because it:
- Considers more dimensions simultaneously. You might think about the API changes and forget about the migration path. The AI thinks about both at the same time.
- Surfaces hidden dependencies. “You’ll need to update the auth middleware before the API endpoints, because the new tenant context needs to be available to the route handlers.”
- Doesn’t skip the boring parts. Humans gloss over “update the config” and “add tests.” AI includes every step because it doesn’t have a boredom filter.
The result: plans that are more complete, more realistic, and more sequenced than what most developers produce alone.
The planning workflow
Here’s the process we use. Not a framework with a cute acronym — just the steps that actually work.
Step 1: Dump the context
Before you ask for a plan, give the AI everything it needs. This is where most people fail — they give a one-line description and expect a detailed plan. That’s like asking an architect to design a house and telling them only “it should be nice.”
Feature: Add team workspaces to the app
Context:
- Current state: single-user app, no concept of teams
- Stack: Next.js 14, Prisma + PostgreSQL, NextAuth
- Users have: profiles, projects, and billing accounts
- We need: users can create teams, invite members, and
share projects within teams
- Constraint: existing single-user projects must keep
working (backward compatibility)
- Timeline: 3 weeks with 2 developers
- Auth: users belong to one or more teams, each team has
admin/member roles
Relevant files:
- Database schema: prisma/schema.prisma
- Auth config: src/lib/auth.ts
- API routes: src/app/api/
- User model usage: anywhere with `session.user`
The more context you provide, the more useful the plan. Include constraints, timeline, team size, and technical context. These shape the plan from “ideal architecture” to “realistic given what we have.”
Step 2: Generate the plan
Now ask for a structured breakdown:
Break this feature into implementation phases. For each phase:
1. What gets built
2. Which files are created or modified
3. Dependencies on other phases
4. Estimated complexity (small/medium/large)
5. How to verify the phase works before moving on
Sequence the phases so we can ship incremental progress
and each phase is independently deployable.
The AI will produce something like:
Phase 1: Data model (Medium, 2-3 days)
- Add Team, TeamMember, and TeamInvite models to Prisma schema
- Create migration
- Add team-aware query utilities to
src/lib/db/ - Verify: migration runs clean, existing user flows unaffected
Phase 2: Team CRUD (Medium, 2 days)
- Create team, update team, delete team endpoints
- Team settings page UI
- Verify: can create and manage teams through the UI
Phase 3: Invitation system (Medium, 2-3 days)
- Invite endpoint with email notification
- Accept/decline invite flow
- Team member listing
- Verify: full invitation lifecycle works end-to-end
Phase 4: Project sharing (Large, 3-4 days)
- Add team_id to projects, migrate existing projects
- Update project queries to respect team membership
- Sharing UI in project settings
- Verify: projects visible to team members, private to non-members
Phase 5: Authorization (Medium, 2 days)
- Role-based access control for team operations
- Middleware updates for team-scoped routes
- Verify: admin-only operations blocked for members, existing auth flows unbroken
That’s a real plan you can put on a sprint board. Not a vague roadmap — concrete phases with verification criteria.
Step 3: Stress test the plan
This is the step most people skip, and it’s the most valuable. Ask the AI to attack its own plan:
Now poke holes in this plan:
- What are the riskiest parts?
- What might take longer than estimated?
- What did we miss?
- Where might backward compatibility break?
- What's the integration risk between phases?
The AI will surface things like:
- “Phase 4 modifies the project query layer that 12 other features depend on. This needs more thorough testing than the estimate allows.”
- “The migration in Phase 1 adds nullable
team_idcolumns, but Phase 4 needs them non-nullable for new projects. You’ll need a two-step migration.” - “You haven’t accounted for updating the billing system — team plans vs. individual plans.”
These are the issues that would have surfaced mid-sprint, causing delays and rework. Now they surface during planning, when they’re cheap to address.
Step 4: Refine and commit
Take the AI’s plan and apply your judgment. Reorder phases based on what you know about the codebase. Adjust estimates based on your team’s experience. Add the risks you flagged to a watch list.
Then put it in your project management tool. The plan is concrete enough to be actionable.
Planning patterns that work
The “what would senior me do” prompt
When you’re stuck on how to approach a feature:
I'm a mid-level developer looking at this feature.
A staff engineer is reviewing my plan. What would
they flag? What questions would they ask? What would
they restructure?
This consistently produces better plans than asking for a plan directly, because it triggers the AI to think about the meta-level: sequencing, risk, reversibility.
The migration-first approach
For features that touch existing data:
Before planning the feature itself, plan the data
migration independently. How do we get from the current
schema to the required schema without downtime, data
loss, or breaking existing queries?
This prevents the common mistake of designing a feature plan that includes an impossible migration as a “one-liner.”
The rollback plan
For high-risk features:
For each phase, describe how to roll it back if something
goes wrong in production. What's reversible? What's a
one-way door?
This forces the plan to be structured around reversibility, which is better engineering practice anyway.
Estimation with AI
AI is genuinely helpful for estimation when you give it the right inputs:
Given our codebase structure, team size (2 devs, both
mid-level, familiar with the stack), and the fact that
we've never built multi-tenancy before — estimate each
phase in developer-days. Include a confidence level
and explain what would make it take longer.
The AI won’t give you a perfect estimate. Nobody can. But it’ll give you a more calibrated estimate than “eh, probably a week” — because it actually considers the complexity of each component rather than vibing on the total.
The planning trap to avoid
Don’t let AI planning become a procrastination tool. The goal isn’t a perfect plan. It’s a good-enough plan that lets you start building with confidence.
A 30-minute planning session with AI replaces the two-day planning session without it. Not because the plan is better (though it usually is), but because you reach the “good enough to start” threshold faster.
Plan. Stress test. Start. Adjust as you learn.
That’s the coductor’s planning playbook.
Plan smarter together
Coductor members share planning templates, real project breakdowns, and estimation techniques that work. Join the community and build your planning muscle.