Why I Let a Strong AI Model Plan Before a Cheaper One Codes

When I first started building FI Beacon with AI, I did not begin by handing over full features and wishing everyone the best.

I started in a much more cautious way.

I would decide what small piece to build, guide the AI through it, and control the work layer by layer. First one change. Then another. Then maybe the API part. Then the frontend part. Then whatever else looked least likely to explode.

This was not elegant.

It was, however, emotionally responsible.

At that point I still did not trust AI enough to say, “Here is the full feature, please return with something sensible.” I wanted to see how it behaved in smaller areas first. That turned out to be a useful phase, because it helped me learn where the model was strong, where it got sloppy, and where it needed better context.

But over time, something changed.

I wrote earlier about how I used AI to research and brainstorm the FI Beacon app idea , and this was the next stage for me once the project moved from idea validation into implementation.

The more I documented the project context in Markdown so AI would stop guessing and the more I understood how to guide the process, the more obvious it became that the real bottleneck was no longer code generation by itself.

It was planning.

A quick note before we continue: this post was created with the help of AI.
I use AI as a thinking partner to help me structure messy thoughts, explore ideas faster, improve flow, and sometimes save me from staring at a blank page like it personally offended me.

That said, the opinions, experiences, and final judgment are still mine. AI helps me write clearer and faster, but it does not get to sneak in and become the author of my personality.

So yes, AI helped shape this post — but the relaxed coder behind it is still very much human.

At first, I was the traffic controller

Before I trusted AI with full feature work, I used it in a much more supervised mode.

I would decide the sequence. I would choose the layer. I would say what to touch and what not to touch. In practice, that meant I was still doing a lot of the planning manually. The model was helping with implementation, but I was holding the map.

That phase was important.

It taught me that AI can write code, but the quality of the result depends heavily on whether the shape of the work is already clear. If the feature is fuzzy, the implementation gets fuzzy too. If the boundaries are missing, the code starts wandering. If the model is forced to think and implement at the same time without enough context, the results become unpredictable.

In other words, the problem was not really “Can AI code?”

The better question was:

Can AI plan this feature well enough that the coding becomes almost boring?

That was the real shift.

The real problem was not code generation

A lot of people talk about AI coding as if the magic lives in the typing part. But after using it on real app work, I think the more valuable part often happens before the first line of code.

It happens when the feature is translated into something concrete enough to implement safely.

That means clarifying scope. Mapping changes across projects. Deciding what belongs in the API, what belongs in the app, what belongs in the worker, what needs migration work, what needs validation, what needs tests, and what should explicitly stay out of scope for now.

That is planning.

And stronger models tend to be much better at that kind of reasoning than cheaper ones.

That does not mean cheaper models are useless. Not at all. It means I stopped asking them to do the hardest thinking and the fastest typing in the same step.

That was asking for too much.

The workflow that started working

Once I got more confidence in the process, I started using a workflow that looked much better than my earlier layer-by-layer supervision.

The pattern was simple:

• write temporary business requirements for the feature
• keep the project context files available
• ask a stronger model to produce a detailed implementation plan
• review the plan
• let a cheaper model execute the plan

That ended up working surprisingly well.

Not because the stronger model was some kind of software wizard living inside the cloud. But because it was better at turning ambiguity into sequence.

And sequence matters.

The BR file was temporary by design

One important detail: I did not treat the business requirements file as permanent project documentation.

It was temporary.

I would create it for the feature implementation cycle, use it as the anchor for planning, and then remove it after the implementation was done. It was there to define the work clearly at the right moment, not to become one more fossil in the repository.

That distinction mattered for me.

The permanent memory of the project lived in the architecture files, integration guides, and other Markdown docs that described the project itself. The BR file was more like a short-lived planning artifact for a specific feature.

That kept the process cleaner.

The permanent docs explained the system.

The temporary BR explained the job.

Step 1: write the feature in business language first

This part became more important the more I used AI.

Before planning implementation, I wanted the feature described in business terms. What problem it solves, what changes for the user, what rules matter, what the expected behavior is, what is in scope, and what is not.

Not implementation details first.

Business meaning first.

That gave the stronger model something much better to reason from. Instead of jumping directly into repositories, components, and migrations, it could start from what the feature actually needed to achieve.

That reduced a lot of accidental complexity.

It also made it easier for me to review the plan, because I could compare the implementation logic against the actual feature intent instead of just admiring a large amount of confidently arranged text.

Step 2: let the stronger model design the plan

This was the part that changed the workflow the most.

Instead of asking the stronger model to implement the feature directly, I started asking it to design the implementation plan in a way that a less capable model could follow.

That sounds simple, but it changes the behavior a lot.

A good planning prompt pushes the stronger model to do things like:

• read the business requirements first
• cross-check them against architecture and integration docs
• identify affected layers and projects
• sequence the work in a sane order
• call out migrations, contracts, validation, and edge cases
• separate what must happen now from what can wait

That is exactly the kind of thinking I wanted to buy from a stronger model.

Not just more tokens.

Better judgment.

Step 3: review the plan before anyone writes code

This part is not glamorous, but it saves pain later.

Once the stronger model produced the plan, I would review it before handing execution to another model. That gave me one controlled checkpoint where I could notice missing assumptions, weird scope expansion, unnecessary complexity, or mismatches with the actual product intent.

This is where I could still say things like:

• that part is too much for the first version
• this should stay in the backend, not the frontend
• this dependency is wrong
• this change belongs in a different project
• that extra improvement can wait

That review step made the rest of the process calmer. By the time a cheaper model touched the code, the shape of the work was already much clearer.

That was a good sign.

Step 4: let a cheaper model execute the plan

Once the feature had a solid plan, the execution phase became much more realistic for a cheaper model.

At that point, the task was no longer “understand the whole feature, figure out the architecture, invent the sequence, and then implement everything perfectly.”

The task became closer to:

“Follow this plan carefully. Make these changes in this order. Respect these boundaries. Update these contracts. Do not drift.”

That is a much better use of a cheaper model.

It reduces the amount of expensive reasoning you need, while still letting you move quickly on the implementation side. And because the plan is already architecture-aware, the cheaper model is less likely to improvise its way into a mess.

Not impossible.

Just less likely.

Step 5: keep the project context files in the loop

The stronger model was not planning from the BR file alone.

That is a very important part of the workflow.

The plan became much better when the model also had access to the Markdown files that explained the project itself: architecture, integration guides, product behavior, external service notes, and whatever else helped define the real boundaries of the system.

That meant the planning step was based on two layers at once:

• the temporary feature definition
• the permanent project context

That combination is what made the output useful. The BR explained what the feature should do. The project docs explained where that feature had to fit.

Without both, the plan was weaker.

With both, it became much easier to hand off safely.

Why this worked better than my earlier layer-by-layer approach

I still think the earlier approach had value. It was a good way to build confidence and understand the model’s behavior.

But it did not scale as well.

When I was guiding the implementation layer by layer, I was still doing a lot of manual orchestration in my own head. I had to keep the dependencies, sequence, risks, and cross-project changes mentally stitched together while also supervising the code.

That is tiring.

The plan-first workflow moved more of that work into a deliberate step. Instead of improvising the sequence feature by feature, I could get a structured plan first, review it, and then use it as the backbone for execution.

That made the whole process feel less reactive and much more intentional.

It also made full-feature implementation more realistic. I no longer had to break everything down manually before every session. A stronger model could help create the map, and a cheaper model could help walk it.

What a good implementation plan needs

Not every plan is useful just because it is long.

A good plan should make the next model safer, not just busier.

For me, the most useful implementation plans usually include:

Affected projects and layers

The plan should clearly say which project changes are needed and why. API, app, worker, tests, docs, contracts, migrations, whatever applies.

Order of work

The plan should not just say what to change. It should say in what order to do it. That matters a lot when several pieces depend on each other.

Validation and edge cases

This is one of the places where stronger models are worth it. A good plan notices where behavior can go wrong, not just where files can be edited.

Contract updates

If the feature changes API responses, request models, integration rules, or user-visible behavior, the plan should call that out explicitly.

Acceptance thinking

A good plan should make it easier to answer, “How do we know this feature is correctly implemented?” Not formal perfection. Just enough clarity that the implementation is not finished merely because the code exists.

That is a much higher-quality handoff than “please build feature X.”

Mistakes to avoid

A few things consistently made this workflow worse when I ignored them.

Asking for implementation before the feature is clear

This is the fastest path to busy-looking code and confused results.

If the feature is still fuzzy, asking for implementation is basically asking the model to invent product decisions while coding. That rarely ends well.

Using a weaker model for the hardest reasoning

A cheaper model can often implement well enough from a strong plan. But asking it to do the planning too is where the quality drops much faster.

That is where the savings become fake savings.

Treating the temporary BR like permanent documentation

The BR file served a purpose, but I did not want a repo full of dead planning artifacts pretending to be the source of truth.

Once the feature was done, I preferred to keep the permanent project docs updated and remove the temporary BR file that had served its job.

That kept the project memory cleaner.

A process you can copy

If I had to reduce the whole workflow into something reusable, it would look like this.

1. Define the feature in business language

Write the temporary BR file clearly. Focus on intent, behavior, scope, and rules.

2. Give the model the permanent project context too

Include the architecture and integration docs that explain how the project is built and how it talks to other systems.

3. Ask the stronger model for a reviewable implementation plan

Be explicit that you want planning, not code. The goal is a detailed plan that another model can execute safely.

4. Review the plan yourself

This is where human judgment still earns its salary.

5. Hand execution to a cheaper model

Once the shape is clear, let the cheaper model do the more mechanical part of the work.

That is the workflow I trust much more now.

Final thoughts

The funny thing is that I started by using AI in the most cautious way possible. Small tasks. Tight supervision. Layer by layer. And that was the right way to begin, because it taught me where the real risk was.

It was not the coding by itself.

It was unclear planning.

Once I understood that, the workflow got much better. Stronger models became planning partners. Cheaper models became execution helpers. Temporary BR files gave the feature a clear definition at the right moment. Permanent Markdown docs gave the project stable context. And my role shifted from manually orchestrating every small move to reviewing the plan and steering the bigger decisions.

AI still needs judgment.

But if you let the stronger model do the harder thinking first, the coding part becomes a lot more manageable, a lot more affordable, and a lot less chaotic.