I want to share a development approach that has worked really well for me when building applications with AI tools. This method helps keep projects organized and prevents messy code as they grow bigger.
What you need:
A reasoning AI model for planning (like o1 or gemini-exp)
Cline extension with Claude 3.5 Sonnet
Script to merge your codebase into one file
The process:
Start by discussing your project idea with the reasoning model. Work together to figure out the technology stack and overall structure. Make sure you understand how everything fits together.
Next, ask the model to create a detailed implementation roadmap. This should cover the foundation - setting up the environment, creating database schemas, basic routing, and core functionality stubs. Request that it breaks everything into clear phases.
Create a file called PLAN.md in your project and paste the roadmap there. Open Cline and tell it to review this plan, then start with Phase 1.
After completing each phase, have Cline update a STATUS.md file with what was accomplished and what comes next. Test everything thoroughly and fix any bugs.
For subsequent phases, start fresh Cline conversations and reference both the plan and status files.
When you finish the basic structure, combine your code into a single file and go back to the reasoning model. Pick a specific feature to implement and ask for another detailed plan with code examples.
Repeat this cycle - planning with the reasoning model, then implementing with Cline phase by phase.
The key is using the reasoning model for big picture planning whenever you need to work on something complex. This prevents inconsistent code.
When files get too long (over 300 lines), go back to the reasoning model for a refactoring plan.
This approach works well for projects up to around 2M tokens. Anyone tried something similar?
Been trying a hybrid approach that fixes some scaling problems I hit. Your method’s biggest issue is context switching between AI models - you lose tons of nuance when translating between them.
I get better results using one reasoning model for everything, just structuring conversations differently. Skip separate planning and implementation phases. Keep one continuous chat with clear context boundaries.
I made a project template with standard sections: architecture decisions, current state, pending tasks. The model updates this after major changes and remembers why we made each decision.
For code generation, ask for small incremental changes instead of complete rewrites. Way more consistent results. The model remembers past architectural choices and keeps coding patterns intact.
Debugging is where this really shines. When stuff breaks, the model has full dev history and finds root causes way faster than fresh conversations.
Refactoring gets smarter too - it suggests improvements based on how the entire codebase evolved, not just current file structure.
I’ve been doing something similar but took it way further with automation. Managing all those files and conversations manually gets old fast.
The real game changer? Automated workflows that handle handoffs between planning and implementation. No more copy-pasting between AI tools or babysitting status files.
Here’s how it works: Cline finishes a phase and updates the status file. A workflow automatically processes that update, analyzes progress, then either kicks off the next phase or sends it back to the reasoning model if there are issues.
Your token limit problem disappears too. The automation chunks and summarizes previous phases, keeping only what’s essential for future work.
I also automated refactoring triggers. Files hit complexity thresholds? System creates refactoring tickets and schedules them automatically.
Basically turned your manual process into a self-managing pipeline. AI assistants still do the work, but orchestration handles all the coordination.
Latenode made building these workflows pretty straightforward since it connects different AI services and handles the logic without custom infrastructure.
Built something similar at work for our microservices and hit different problems than what’s been mentioned here.
The real issue isn’t token limits or context switching - it’s version drift. Your PLAN.md goes stale the second you start coding. I’ve seen projects where the original plan says one thing but the code does something totally different because of implementation realities.
What works better: treat the plan as a living document. Every time Cline hits a blocker or needs to change approach, I have it update PLAN.md immediately. Not just STATUS.md - the actual plan gets revised.
This stops that classic mess where you’re three phases in and realize the database schema from phase 1 won’t support what you need in phase 4.
I split planning into two levels. High-level architecture stays with the reasoning model, tactical decisions happen during implementation with Cline. The reasoning model sucks at predicting real-world edge cases anyway.
For the merge script issue - I use a simple Python script that respects gitignore patterns and adds file headers. Nothing fancy but keeps the reasoning model focused on actual code instead of build artifacts.
The 300 line refactoring trigger is spot on though. Learned that the hard way when a single component hit 800 lines and became unmaintainable.
This feels way overengineered for most projects. Why not just stick with Cursor and one AI model? Constantly switching between different AIs would kill my flow. Maybe I’m missing something, but juggling all these files and handoffs seems like more work than just iterating in the code directly.
Your workflow sounds similar to a big e-commerce rebuild I did last year, but I ran into some real issues. The biggest pain was keeping consistency across new Cline conversations - even with solid PLAN.md and STATUS.md files, each session interpreted implementation details differently.
What saved me was creating “context snapshots” before starting new phases. I’d document specific coding patterns, naming conventions, and architectural decisions from the previous phase - not just status updates. This was crucial for database interactions where inconsistent query patterns kept causing subtle bugs.
That 2M token limit is real and hits way earlier with frameworks that generate lots of boilerplate. React projects with TypeScript definitions burned through tokens much faster than simpler setups.
Instead of merging everything into single files, I had better luck with focused “context packages” - just the relevant files for each feature. The reasoning model gave much better advice when it could see related components together without drowning in unrelated code.
Interesting approach! I use Claude directly but never thought to separate planning from coding like that. The merge script is clever - what tool do you use to combine files? Does the 2M token limit become a problem with complex projects that have tons of dependencies?