My AI Coding Stack: A Practical Guide to Using ChatGPT, Cursor, Claude Code, and Lovable

I’m coming back to this one after another few months of actually building with these tools. Some of what’s below held up, some of it didn’t — updating it in place felt more honest than writing a second post.

Let me share my current AI stack and, more importantly, what you can actually do with each tool. This isn’t theory — it’s my daily workflow.

I use a combination of ChatGPT, Claude Code, Lovable, and Cursor. Each has its place. Here’s how to use them effectively.

---

ChatGPT: The Brainstorming Layer

I only use ChatGPT when I need to brainstorm something at a super high level. Projects, quick ideas, that kind of stuff.

What you can do:

• Use it for initial ideation before you have any structure
• Brainstorm features, user flows, or architecture concepts
• When things get more complicated, move to Cursor or straight into Claude Code

ChatGPT is the start, not the destination.

That’s a different thing from calling GPT models directly via API for specific tasks inside my coding workflow — more on that in the Claude Code section below.

---

Cursor: Your Spec-Driven Command Center (For a While, At Least)

For a long stretch, this is where I spent most of my time reasoning and planning. Here’s why Cursor worked so well for me: I could see file structure.

That might sound basic, but it’s huge. When you’re building something complex, seeing how your folders and files are organized helps you think better. Claude Code, back then, didn’t give me that visual structure.

That was true. It’s less true for me now — most of that day-to-day reasoning has moved into the Claude Code CLI (more on why in the next section). Both things were true, just at different times. The underlying approach hasn’t changed — only where I do it.

What You Should Do (Wherever You Reason)

1. Create a “Specs” Repository

Create a dedicated repository that acts as your single source of truth. Inside it:

• All your database schemas
• Specs for each model or microservice
• Architecture decisions
• API definitions

This is called a spec-driven approach, and it’s especially powerful when your team grows or you have multiple collaborators. Everyone points to the same source.

2. Organize Your Specs in Folders

Structure your specs by domain. One folder per microservice. One folder per feature area. The structure itself becomes documentation.

3. Do Your Deep Reasoning in Writing

I write a lot of .md files. I used to do this mostly in Cursor; these days I mostly do it in the Claude Code CLI. I discuss with the LLM, iterate on ideas, refine specs. The conversation plus the file structure helps me think through problems — wherever that conversation happens.

4. Research and Enhance

You can search online from Cursor and enhance your spec files. You can even batch-transform file formats. It’s flexible.

5. Build a “Scripts” Repository

Separate from your specs repo, create another repo with small utilities:

• Scripts to check database consistency
• Data validation scripts
• One-off automation scripts

Keep these isolated. They’ll save you hours when coordinating with other teams.

6. Switch Models Freely

One thing that first pulled me into Cursor: you can switch between models right there. Want to test GPT-5.2? GPT-5.3-Codex? Opus? You can do it all in one place.

I still value that flexibility. I just get it a different way now — Opus and Sonnet inside Claude Code, and GPT via a direct API call when I need it. More on that below.

7. Use Skills and Commands (and Let AI Create Them)

Both Cursor and Claude Code support Skills and Commands. I use AI to create them for me — you don’t need to learn the syntax. For repetitive tasks, I find Commands work better than Skills. They’re more specific and faster to trigger. Skills, on the other hand, are useful when you need the LLM to understand where to look — for example, when a Skill guides it to check something across multiple repositories.

---

Claude Code: The Execution Engine (Increasingly, Just “The Tool”)

Here’s the thing about Cursor: if you use Opus a lot, it gets expensive. That’s why I originally switched to Claude Code for execution. What’s changed since is that “execution” quietly became most of what I do. These days Claude Code is my go-to tool. My partner in crime, full stop.

What You Should Do in Claude Code

1. Use the CLI, Not the UI

I don’t use the Claude Code UI. I use the CLI. It’s a bit techier, sure, but it’s way easier and way faster once you’re used to it, and it’s more lightweight overall. The real unlock: the CLI lets me run multiple agents at once inside the same IDE. That’s not something the UI gives me as cleanly.

2. Execute Your Stories

Once you have your specs ready — in Cursor, in Claude Code itself, wherever — divide them into incremental stories and move to execution. Run multiple agents that each pick one story, develop it without dependencies, and ship it.

3. Ask for Testing Before You Review

Before you even look at the code, ask Claude Code to:

• Write end-to-end tests
• Run the tests
• Give you a confidence report

Let the model be confident first. Then you review.

4. Use Cloud Environments and Autonomous Modes for Async Work

This is powerful. Claude Code can work in a Cloud environment — meaning it runs remotely, not on your local machine — while you’re doing something else, even from your phone. Lately I’ve been combining that with a mix of auto-mode and bypass-permissions, especially to let it work through the night, unattended. It works.

You can literally be driving (don’t actually code while driving) or in a meeting and still have work progressing.

5. Route the Right Model to the Right Job

I default to Opus for actual code — it’s the model I trust most for that. But whenever I need to write something that isn’t code — copy, text, anything closer to writing than engineering — I switch to Sonnet. Partly because it’s better suited to that kind of writing, partly because it keeps me inside my subscription instead of burning API usage, which is something I actively try to avoid.

For a handful of specific tasks I’ve also built a small script to call GPT directly via API when that’s the better tool for the job. I tested Fable too, for what it’s worth. Way too slow for what I needed — not useful enough to keep around.

6. Compare Costs

Claude Code is significantly cheaper than running Opus through Cursor. If you’re doing heavy agent work, the savings add up.

7. Use the CLAUDE.md File — Don’t Learn It, Ask AI

Claude Code has a CLAUDE.md file for configuration. You don’t need to learn it. Just know it exists: when you need to set something up or change how things work, ask the AI to explain it and do it for you while you’re coding.

---

Lovable: The UI Specialist

Here’s where Lovable shines: the UI is better.

When you generate UI with Claude Code or Cursor, the scaffolding is fine. They can fix bugs, discover issues, do amazing things. But the visual quality? It tends to be repetitive. Same patterns over and over.

Lovable generates fresher, more polished UIs. I don’t know exactly how — they’re also using Opus — but something in their pipeline produces better visual output.

What You Should Do in Lovable

1. Connect to an Isolated Branch

Don’t let Lovable work on your main branch. Connect it to a separate branch, let it generate UI, and merge when you’re ready.

2. Use It for Visual Brainstorming

When you need to explore a new UI direction or create something visually fresh, start in Lovable. Then bring it back to your main codebase.

3. Understand the Limitations

Lovable has one chat. One queue. It’s more straightforward but also more limited than Cursor or Claude Code, where you can have multiple chats and branches open simultaneously.

---

The Multi-Repo Workflow (This Changed Everything)

Here’s what unlocked real productivity for me: working across multiple repositories at once.

In both Cursor and Claude Code, you can have your specs repo open while working in your main project. Reference your specs while you build. Update specs as you learn.

You can’t do this in Lovable. But in Cursor and Claude Code, this cross-repo workflow is ideal for keeping your single source of truth actually true.

---

Practical Tips Before You Start

Watch Your Costs

Especially with APIs. Subscription costs are predictable, but API usage can surprise you. I once spent $500 in a weekend classifying 25K items because I didn’t optimize.

What to do:

• Experiment with smaller, cheaper models first
• Use prompt caching when available
• Don’t default to the most expensive model for every task

Build an “AI Committee”

Find friends who are also deep into AI tools. Create a group. Share news, test models together, evaluate gut feelings.

Why? Because the landscape changes constantly. Maybe tomorrow a new model outperforms everything. Having people who test and share saves everyone time.

Experiment to Find Your Stack

We’re all opinionated when it comes to AI. At the end of the day, you need to find your best tech stack — and it might be different from someone else’s. There are other tools — Google Antigravity, OpenAI’s Codex app, others. Try them. Find what clicks for you.

Get an Engineer on Your Team

If you’re not a developer, have someone technical who can:

• Review code before production
• Understand what the AI generated
• Catch issues you might miss

Don’t push to production without human review. Same goes for DevOps support.

---

Final Thought: This Isn’t “Vibe Coding” Anymore

Let’s stop treating AI-assisted development as a second-class citizen. It’s not vibe coding. It’s just a different way of coding.

The tools are mature enough that with the right stack — and the right discipline — you can ship real products.

These days I think of myself less as “a product person who can also code” and more as an AI product engineer — product mindset, real engineering skill, and enough leverage from the stack above to actually ship. I don’t know if that’s an official job title yet. I think it should be.

Find your stack. Build your workflow. And please, share what works for you.