When I started building Lexio—a personal vocabulary learning tool—I made a deliberate choice: use Claude in two completely different ways, and never mix them up.
One Claude for thinking. One Claude for coding.
This isn’t just a workflow quirk. It’s a separation that keeps my development process sane.
The Problem with “Just Ask Claude to Do Everything”
The most obvious way to use AI for development is to throw everything at Claude Code: describe a feature, let it generate the code, repeat. And it works, to a point.
But I found a friction point fairly quickly. When I’m writing code, I don’t want to stop and debate whether I should use SM-2 or Leitner for my review algorithm. That decision-making loop and the implementation loop are cognitively different tasks. Mixing them in a single Claude Code session produces scattered, unfocused results.
So I split them apart.
Two Claudes, Two Roles
Claude Project: The Thinking Partner
I created a dedicated Claude Project for Lexio. This is where all the architectural and product thinking happens—before a single line of code is written.
The Project has full context: the tech stack (Rails, Inertia.js, React, shadcn/ui), the data model, the feature roadmap, my preferences and constraints. When I want to figure out the next step, I come here.
Typical conversations look like:
- “I want to add a review session feature. What’s the right data model for SM-2 with per-vocabulary scheduling?”
- “Should the Telegram Bot use webhooks or long polling for this use case?”
- “I’m thinking about adding an audit log. What columns make sense given how users interact with vocabulary?”
The Project gives me a recommendation—not a list of options, but an actual decision with reasoning. Once I agree with the direction, I ask for one more thing.
The Key Step: Generating the Prompt
Here’s the part that makes the workflow click: I ask the Claude Project to write the prompt I’ll use in Claude Code.
Not “here’s what you should build”—a precise, scoped prompt that Claude Code can execute without ambiguity. Something like:
“Add a
review_sessionstable with these columns:[...]. Create aReviewSessionmodel withbelongs_to :userand astarted_at/completed_atlifecycle. The service objectReviewSession::Creatorshould implement SM-2 scheduling based on the existingvocabulariestable.”
I copy that prompt directly into Claude Code. No paraphrasing, no rewriting.
Claude Code: The Executor
Claude Code gets a clear, well-scoped task and executes it. It writes the migration, the model, the service object, the specs. I review the output and commit.
Because the decision-making already happened, I’m not evaluating architecture while reviewing code. I’m just checking that the implementation matches the intent.
What This Looks Like in Practice
Building Lexio’s OCR feature is a good example. The feature lets users photograph text and extract vocabulary from it using Claude’s vision API.
In the Project, I discussed the integration approach: should OCR be a synchronous Rails controller action or an async job? We settled on synchronous for the MVP—simpler, and latency is acceptable for a personal tool. The Project also suggested the right abstraction: a VocabularyExtractor service that wraps the Claude API call, keeping the controller thin.
In Claude Code, I pasted the generated prompt: build VocabularyExtractor with a specific interface, integrate it into the PhotosController#create action, handle API errors gracefully. Claude Code produced working code on the first pass.
I didn’t have to think about architecture while reading the code. The architectural work was already done.
The Honest Trade-offs
This workflow isn’t frictionless. A few things worth knowing:
The code style won’t be yours. Claude Code writes clean, functional code—but it has its own style. Variable naming, how it structures service objects, where it puts validation logic. Sometimes it matches my preferences, sometimes it doesn’t. I’ve learned to accept this and only correct the things that will matter long-term.
It’s slower than it looks. The “Project → prompt → Code → review” loop is more steps than just writing the code yourself. The speed gain comes from not getting stuck, not from raw coding velocity. For a solo developer with limited time, that trade-off is worth it.
You still have to understand what you’re building. Claude Code doesn’t substitute for engineering judgment. The thinking step in the Project isn’t optional—it’s where you validate the approach before spending time on implementation. If you skip it and ask Claude Code to figure out the architecture too, you get inconsistent, patchwork code.
Why Keep Them Separate at All?
Someone might reasonably ask: why not just use Claude Code for everything? It can discuss architecture too.
The honest answer is that I find context mixing degrades quality. When Claude Code is in the middle of writing a migration, I don’t want it also reconsidering the data model. Keeping a separate Project with full product context means the “thinking” Claude has everything it needs to reason well—feature history, design constraints, my preferences. The “coding” Claude gets a narrow, precise task.
It’s the same reason good engineering teams separate planning from execution. Not because the same people can’t do both, but because switching modes mid-task is expensive.
What I’d Tell Someone Starting Out
If you’re building a personal project with AI assistance:
Set up a Project first. Give it context about your stack, your data model, your preferences. Treat it as a technical co-founder you can think out loud with.
When you’re ready to build something, don’t go straight to Claude Code. Spend ten minutes in the Project: what are you building, why, and what’s the right shape for it? Then ask the Project to write you a prompt.
Copy that prompt to Claude Code. Review the output against the spec, not against your gut.
The split sounds like overhead. In practice, it’s the difference between coherent code and a patchwork of context-switching that you’ll spend weeks untangling.
Lexio is a personal vocabulary learning tool I’m building with Rails, Inertia.js, and React. This post is part of an ongoing series on building solo projects with AI assistance.