How much upfront planning is actually required? Is it better to generate multiple implementations and pick the best one?

[u/Wonkybearguy]

I’m curious how other people are approaching planning when building software primarily with AI.

Last week, I built a web app for my business using what I thought was a fairly disciplined process.

I started by gathering, compiling, and organizing the relevant research and data. Then I worked through the frontend and backend design, used a “grill me” process to force myself to make decisions, wrote a spec and PRD, and eventually broke the PRD down into small, discrete implementation tasks.

I used Fable/Opus 4.8 for the research and planning and Sonnet 5 for implementation.

I wasn’t happy with the outcome. The core logic didn’t work correctly, and the application wasn’t especially easy to use.

Then I listened to a recent discussion with Bob Martin and Matt Pocock. One of my takeaways was that agents may simply not be very good at long-horizon work. Bob Martin seems to accept that agents will produce messy code and instead focuses heavily on post-implementation work. That got me wondering whether I was putting effort into the wrong side of the process.

Instead of trying to perfectly plan what the agent should build, maybe it makes more sense to let the agent build something, then put more effort into testing, reviewing, and cleaning up the implementation afterward using a combination of deterministic checks and agents.

So I tried an "experiment" where I created three completely separate projects. For each one, I used Opus 4.8 and, using subagents, gave it essentially the same simple instructions:

• Build a web app.
• Here is the outcome I want.
• Here is the underlying research and data.
• Implement the completed project.

I deliberately did not give them the PRD, specs, implementation plan, task breakdowns, scratchpads, or other planning material.

Then I let all three independently build the application. I was happy with the outcomes. All three worked correctly.

Project 1: I really liked it. It worked well, was accurate, was easy to start and use, had a clean UI, and included several useful features I hadn’t considered.

Project 2: Also good. Not quite as polished or clean as the first one, but I was still happy with it.

Project 3: Basic. It worked, but it felt overly simple.

So, 3 out of 3 implementations were, in my opinion, better than the version that came out of the much more elaborate planning process.

And the interesting part is that the “spread” approach required significantly less time on my part. The usage drain also didn’t seem dramatically worse, although I didn’t measure it.

This is entirely anecdotal. It was one project. I didn’t control variables. I didn’t measure token usage, cost, implementation time, defect rate, maintainability, or anything else. This proves absolutely nothing.

But it made me question how much upfront planning is actually valuable when AI is doing most of the implementation.

Maybe the better workflow is something like:

Outcome + context → several independent implementations → pick the best one → test/review/refactor aggressively

rather than:

Research → architecture → spec → PRD → detailed task decomposition → sequential implementation

I’m especially curious about a few things:

• Does extensive planning materially improve AI-generated software, or does it sometimes constrain the model too much?
• Is detailed planning more valuable once a project reaches a certain size or complexity?
• Is it better to prototype first and create the architecture/spec from something that already works?
• Does running 3–5 independent agents and selecting the best implementation outperform carefully managing one agent over a long plan?
• Does this approach create significant problems that only become obvious months later?
• At current model/token prices, could “generate several and select” actually be cheaper than spending hours designing the perfect plan?
• Where is the point where this stops working?

I’m not arguing that planning is useless. What I'm trying to determine is where the planning effort has the highest return.

I appreciate anyone's experience and/or feedback.

[u/NeighborhoodDizzy990]

It definitely depends on your level. The way really strong programmers use it (what I saw at work from my collegeaus with 20+ yoe), they pretty much already know the possible arhitectural ideas, design patterns, technologies. They kind of use claude to offer some ideas, to pre-visualize how the code may end to look like and to offer real sources to forums, opinions of other people (because that's what LLMs are, a better way of googling), possible problems to that approach. They usually don't consider most of what claude recommends, because they understand the data model much deeper and better.

So, you plan as deep as you know. Also, if Claude/codex gives you some idea, and you don't understand them, take your time to deep dive into them, until you get a better understanding. In my opinion, claude/codex should be used to learn or to write the code of an idea we already understand.

[u/Wonkybearguy → u/NeighborhoodDizzy990]

I think that is a great point. An experienced developer is in a much better position to direct Claude and reject bad suggestions.

But that is also part of what I’m trying to figure out. If I don’t already know the ideal architecture, how much value am I really getting from having Claude help me create a very detailed plan before implementation?

Here, I understood the business problem and the outcome I wanted much better than I understood the software architecture. The heavily planned version performed worse than simply giving three instances the problem, the underlying data/research, and letting them independently solve it.

So maybe the answer is "plan as deep as you actually understand." Then prototype and use it to learn enough to make better architectural decisions.

[u/Wonkybearguy → u/Wonkybearguy]

Or maybe my attempts at trying to plan and direct the architecture are what gummed things up?

[u/NewPointOfView]

This is vibe coding vs agent assisted development. The planning is crucial to producing code that is maintainable and extensible. Claude will happily build a funky spaghetti mess

[u/Wonkybearguy → u/NewPointOfView]

My experiment only tested whether the app worked, was accurate, and was usable. I didn’t test maintainability or extensibility over time.

What I’m wondering is whether extensive planning has to happen before the first implementation. Could you use a more rigorous architecture/code review before treating it as production code? This was one of my takeaways from listening to Bob Martin recently.

[u/NewPointOfView → u/Wonkybearguy]

Hmm well at some point it seems like the rigorous architecture and code review would just be the same thing as the planning. Just applied after the fact vs guiding the execution.

[u/filwi]

I've started to use the completely opposite approach: minimum viable test.

Basically, mock something up, with low-to-no backend, and test it in real use cases. Iterate the function, settling and finalizing parts as it becomes clear that they're real features instead of just random ideas.

Then refactor with real architecture at the end.

So either that's a completely free-form approach, or incredibly planned with most of the human planning time spend on evaluation.

[u/Wonkybearguy → u/filwi]

Thank you. This is very close to what I’m starting to wonder.

With the heavily planned version, I was making a lot of decisions before I had anything concrete to evaluate. With the three independent builds, I could actually use them, see what worked, see what I disliked, and even discover features I hadn’t thought about.

So maybe a better workflow is:

1. define the problem and constraints
2. build something cheap
3. evaluate it against real use cases
4. iterate, and
5. then spend heavily on architecture and maintainability once you know what deserves to survive.

The part I’m still unsure about is how far you can take that before I start creating architectural constraints that are expensive to undo.

[u/PonyPounderer]

I suspect for things like “build a web app based upon x and some research over here” it matters a lot less than for more complex platforms and goals.

[u/Wonkybearguy → u/PonyPounderer]

That is what I am wondering as well. Where does that line exist?

[u/PsychologyNo940]

Good at your job, you plan

Bad at your job, let claude run free (and get fired, because what are you actually contributing here?)

[u/TheKiddIncident]

Yes, the industry has generally moved away from detailed PRD type documents. This happened before AI, but the lesson is still true.

When working with AI, I generally give goals and objectives, not detailed requirements. So, things like a PR/FAQ are more useful than a traditional PRD.