AI generated 102 tasks for a legacy platform migration. I looked at the list and immediately knew it was unusable.

Not because the tasks were wrong. Technically, every one of them was valid. The breakdown was logical. The sequencing made sense if you'd never actually managed a development team. But 102 line items isn't a project plan. It's a spreadsheet that makes developers freeze.

This is something nobody talks about when they praise AI's ability to generate comprehensive output. AI doesn't mind granular. It can produce and track hundreds of items without breaking a sweat. But humans have to execute those items. And the gap between what AI generates and what a team can actually work from is where most AI-assisted projects fall apart.

The Problem Isn't Bad Output

AI's initial 102-task breakdown wasn't a failure. It was a starting point. That distinction matters.

Each task was reasonable on its own. Set up the project structure. Configure database connection pooling. Create authentication middleware. All valid work. But some tasks would take 30 minutes. Others would take 3 days. They were scattered across 21 epics with no clear sense of what a developer should tackle first on Monday morning.

This is what AI does when you ask it to break down a complex project. It generates everything it can think of, at the most granular level it can manage, because it doesn't know what "meaningful work unit" means for your team. It doesn't know that your senior developer can knock out scaffolding, database configuration, and basic middleware in a single focused session. It doesn't know that spreading those across three separate tasks creates overhead that slows people down.

AI sees structure. Humans see a to-do list they'll never finish.

Four Iterations, Not One

It took four rounds of refinement before we had something a team could execute against.

The first pass gave us 21 epics and 102 tasks. Comprehensive but overwhelming. Sub-hour tasks mixed with multi-day efforts.

I told AI that tasks completable in under an hour should be combined. Second pass: 12 epics, 74 tasks. Better, but still too many small items scattered throughout.

Third pass: 10 epics, 66 tasks. Improving, but environment setup was spread across multiple epics. A developer would have to jump between sections just to get their local machine running. I pushed back: "Everything needed to start developing should be in one place."

Final pass: 8 epics, 19 tasks. Each task now represented 1 to 15 days of meaningful work. A developer could look at the list and understand what to do this week, this sprint, this month.

That's a project plan.

The journey from 102 to 19 wasn't about removing work. Every task from the original breakdown still existed inside the consolidated ones. It was about packaging work into units that match how humans actually operate.

The Sequencing Problem

Here's another place where AI's logic diverged from operational reality.

AI suggested converting the stored procedures before tackling the application tiers. The reasoning was sound on paper: stored procedures contain core business logic, so understanding them first would inform the application conversion.

I redirected. Developers need full application context first. If you hand a developer a set of converted stored procedures without the application that calls them, they have no frame of reference. They can't test anything. They can't see how the pieces fit together.

AI agreed immediately. It didn't push back because it didn't have a strong opinion. It had a reasonable default that happened to be wrong for this team and this project.

"AI's suggestions aren't wrong. They're generic. Someone has to inject the specific operational knowledge that turns generic into actionable."

Same thing happened with the production cutover. AI laid it out as three sequential tasks across different days: database migration, application deployment, DNS cutover.

Anyone who's done a production cutover knows that's not how it works. You can't have two systems of record running simultaneously. The database migration happens overnight because you need the latest data. The cutover happens in one coordinated push. You practice the replication runs beforehand so the actual event is boring.

AI didn't know this because it hasn't done cutovers. I have. The difference between a plan that looks right on paper and a plan that works at 2 AM on cutover night — that's the gap AI can't close on its own.

AI's First Output Is a Starting Point

If you're using AI to plan or execute a complex project — a migration, a product build, a proposal, a system redesign — here's the one thing I'd want you to take away from this:

AI's first output is a starting point, not a deliverable. The value isn't in what AI generates. It's in what happens between generation and completion. That's where your experience, your operational knowledge, your understanding of how teams actually work transforms AI output into something real.

Don't accept the 102-task list. Push it down to 19.

I wrote about the full methodology — the decisions behind the decisions, and why the same approach worked across five different production projects — in my book.

The Architect and The Navigator: Building with AI is available now on Leanpub.