Right Tool, Right Job

I spent a good stretch of time trying to make whatever AI I had open do everything. One window, one conversation, every kind of question. It wasn't a strategy — it was just the path of least resistance. And for a while it worked, loosely. Until it didn't.

The problems weren't dramatic. They were slow. Context getting muddy. Outputs that were fine for what I asked but wrong for what I actually needed. The feeling that the tool was doing its job and I was using it wrong.

The fix wasn't finding the perfect tool. It was accepting that no single tool should be doing everything. Here's what I landed on after enough mistakes to make it feel earned.

Claude and Cursor: for the big stuff

When I'm in a project with real scope — something that's going to run for weeks, touch multiple systems, and require consistent judgment across many sessions — I reach for Claude or Cursor. Both handle complexity over time, and both have genuinely different strengths.

Cursor lives inside the codebase. It writes code, executes diffs, understands the repository. Claude handles the work that lives outside: writing, skills, agentic tasks, planning. Together they cover most of what building something substantial requires. The key is keeping them scoped — large projects need discipline about what goes into each context, not just which tool to open.

Other chatbots: for quick knowledge

Gemini, ChatGPT, local models — I use these differently. Not for building, but for checking in. A concept I need to understand quickly. A syntax question. Documentation that makes no sense. I open one, get what I need, and close it. The context disappears. That's the point.

Trying to use these for long-running work is where people get burned. They're fast and broad, and those are good qualities for exactly this use case. Let them be that.

Personal skills: for workflow

This one took the longest to figure out, and it's still the part of my stack I'm most active about. I build skills that do specific things in my workflow — writing .md files, manifesting conversations into documents, structuring agentic sessions. These aren't AI tools in the general sense. They're my tools. Built around how I actually work, not how someone else thought I might.

The difference between a skill you built and a feature someone shipped for you is that the skill knows what you're trying to do. The feature knows what most people might want.

Third-party products: for the foundation

Some things you don't build, you pick. Supabase for the database. Vercel for deployments. GitHub for version control. These are the infrastructure layer and the right move is to choose carefully, then stop questioning them. The goal isn't to optimize this layer — it's to stabilize it so you can build on top of it.

Small self-built apps: for the gaps

Every workflow has gaps that no product is going to fill, because they're too specific to the way you work. I fill them with small apps — tools built for myself that do one narrow thing well. Not products. Not things I'm shipping. Just the specific piece of automation or interface that makes the day work better.

This is the most personal layer of the stack, and the hardest to talk about because it's different for everyone. But it's also often where the most leverage lives.

The whole thing took longer to arrive at than it should have. Part of that was trial and error. Part of it was paying attention to what people in the community were doing — not copying their stacks, but understanding the logic behind their choices. The tools change. The logic behind choosing them is what's worth developing.

A workflow isn't something you download. It's something you earn.