Cursor · AI Development · Workflow

AI-Assisted Programming With Cursor: A Practical Guide

I've shipped $1M worth of freelance work using this workflow. Here's how I actually use Cursor day to day — the right mindset, the right modes, and the habits that keep AI from making a mess of your codebase.

Gabriel Higareda · 7 min read · Development

Why This Matters

I've seen firsthand what AI can do when used properly. I've also seen what happens when it's not — bloated code, compounding bugs, features that technically "work" until they don't. The goal here isn't to replace your thinking. It's to amplify it.

Think of AI as a junior developer, not an architect. You bring the ideas, the architecture decisions, and the critical thinking. AI handles the tedious implementation work. That mental model changes everything about how you prompt, how you review, and how much you actually trust what it ships.

This approach has let me build features in minutes that would normally take hours. But it only works if you stay in control.

The Right Mindset

Your thought process is everything. Don't dump a massive list of requirements on AI and expect magic. That's how you end up with a tangled mess that takes longer to fix than if you'd written it yourself.

Think step by step. Break your feature into small, logical phases. Handle one piece at a time. Validate as you go. This isn't slower — it's faster, because you catch issues early and avoid compounding problems.

Big prompts with lots of requirements lead to big problems. Keep it incremental. One piece, one conversation, one commit.

Getting Set Up

Download Cursor from cursor.com and open your project. The first thing I do on any new codebase — even one I wrote — is switch to Ask mode and run this prompt:

Cursor prompt · onboarding

"I'm a new developer joining this project. Give me a quick breakdown of how this codebase is structured, the main folders, where the key pieces live, and how things are connected. Keep it high-level so I can get oriented fast."

Cursor walks you through the folder structure, key files, and how everything connects — tailored to whatever's actually in the repo. Takes 30 seconds and saves you an hour of digging.

On model switching: Auto mode is fine for building code. For planning or complex questions, switch to a heavier model like Claude Opus or a thinking model. Better reasoning when you need it. Just don't burn premium tokens on simple prompts — right model, right task.

The Four Modes

Knowing when to use each mode is where most people go wrong. Here's how I use them:

Before you build
Planning Mode

Use this before writing a single line. Let Cursor lay out a detailed plan without touching any code. Get a solid plan, poke holes in it, cover edge cases. Only move to Agent once the plan is tight.

When you're ready to ship
Agent Mode

This is where actual coding happens. Cursor edits files, creates components, implements features. Use after planning. Stay engaged — guide it phase by phase, don't just let it run.

When you have questions
Ask Mode

For exploring ideas, clarifying requirements, or getting information. If you're in Agent mode and ask a question, Cursor might start editing files when you didn't want it to. Switch modes.

When something's broken
Debug Mode

For problems that aren't obvious. Give it as much context as you can — error messages, what you've tried, what behavior you're seeing vs. what you expected. More context = faster resolution.

The Workflow

The rhythm I use on every project, every feature, every fix:

01

Start small

Don't ask AI to build an entire feature at once. Break it down. Building a login screen? Start with just the UI layout. Then form validation. Then API integration. Each piece gets its own conversation.

02

Request a testing checklist

After AI generates code for a phase, ask it: "Give me a checklist to validate this work." This forces you to verify what was built before moving on. Don't skip this. AI makes mistakes — sometimes subtle ones.

03

Clean and refactor

AI-generated code works, but it's not always pretty. Before you commit: remove unnecessary comments, fix naming that doesn't match your conventions, refactor anything clunky. This is your code now. Own it.

04

Commit at checkpoints

Once a phase is working and clean, commit it. Don't wait until the whole feature is done. Small, frequent commits mean you can roll back if the next phase goes sideways. It also makes code review infinitely easier.

The rhythm is: build → validate → clean → commit → repeat.

What Not to Do

Don't hide behind AI. If you can't explain what the code does, you shouldn't be committing it. AI is a tool, not an excuse. You're still responsible for understanding and maintaining everything in your codebase.

Don't skip validation. AI makes mistakes. Sometimes subtle ones that only surface in production. Test everything before you commit. If it breaks later, that's on you, not the AI.

Don't build everything at once. Big prompts with lots of requirements lead to big tangled messes. Keep it incremental. One feature phase at a time.

Don't skip the PR. AI-generated code especially needs a second set of eyes. PRs catch edge cases, naming inconsistencies, and logic that looks right but isn't. They also force you to understand what you're shipping.

PRDs for Bigger Features

For anything significant, write a PRD (Product Requirements Document) before you start building. Yes, you can use AI to help write it — but you hold the baton. You set the tone, you make the decisions, you identify the edge cases.

The more work you put into planning, the easier implementation becomes. Think through the data flow. Decide how things should behave before you write a single line. A solid PRD becomes context for AI during implementation, and it becomes your reference when things inevitably go sideways.

It also changes how you debug. Instead of "please fix this," it becomes: "This is the issue. This is what I've tried. This is what I found. Help me fix it." That's a completely different conversation — and it gets you to a solution faster every time.

Token Management

Be intentional about which model you're using. Auto mode is cheaper and works great for straightforward coding tasks — file edits, component generation, routine implementation. Switch to a heavier model when you're planning a complex feature, debugging something tricky, or need real reasoning depth.

Don't burn premium tokens on simple prompts. Right model, right task, right time. That discipline adds up over a long project.

Want to Build Like This?

I take on a limited number of projects. If you're working with an existing codebase, building something new, or just need someone who actually knows how to use these tools — reach out.

Hire me on Upwork