Command Palette

Search for a command to run...

988

Command Palette

Search for a command to run...

Blog

How I Ship Faster with Claude Code, Cursor, and Codex

I use AI coding tools every day — not as a novelty, but because they measurably cut delivery time. Here's my actual workflow across Claude Code, Cursor, and Codex, and where each one fits.

I've been freelancing for 8 years. In the last two, AI coding tools have changed how I work more than any framework, language, or deployment platform ever did. Not because they write code for me — they don't, not reliably — but because they compress the boring parts and let me spend more time on the decisions that actually matter.

I use three tools daily. Each one fills a different gap.

The Stack

Claude Code — my primary tool for complex, multi-file refactors, codebase analysis, and anything that needs deep context. It reads entire projects, understands architectural decisions, and can execute multi-step plans across dozens of files.

Cursor — my daily editor. VS Code with AI baked in. Tab-completion that understands my codebase, inline edits that respect surrounding code style, and Cmd+K for quick transformations.

Codex — background tasks. I kick off longer-running work (test generation, migration scripts, documentation) and come back to the results. Useful for parallelising work I'd otherwise do sequentially.

Claude Code: The Architect

Claude Code is where I go when the task is bigger than a single file. Examples from the last month:

Codebase refactors. I recently stripped a shadcn component registry out of a Next.js portfolio — about 150 file deletions, 30 file moves, and dozens of import rewrites. Claude Code read the entire project, identified every dependency chain, migrated shared components to new locations, updated all importers, and verified the build passed. What would have been a full day of careful manual work took about an hour of review.

Architecture exploration. When I pick up a new client codebase, the first thing I do is point Claude Code at it and ask "explain the data flow from the API route to the database." It reads the actual code — not documentation that might be stale — and gives me a map I can verify in minutes instead of hours.

Bug investigation. "Why does this page crash when GITHUB_CONTRIBUTIONS_API_URL is undefined?" Claude Code traces the call chain, finds the unguarded fetch(), and proposes a defensive fix with fallback — including the error handling I'd forget to add if I was fixing it manually at 11pm.

What it's not good for: quick one-line edits, anything where opening a terminal is faster than explaining the task. I don't use it for git commit or npm install. The overhead of describing simple tasks exceeds the time saved.

Cursor: The Daily Driver

Cursor is where I spend 80% of my coding time. The AI features I actually use daily:

Tab completion. Not GitHub Copilot-style single-line suggestions — Cursor's tab completion understands multi-line context. I write a function signature and the first line of logic, hit tab, and get a completion that matches my code style, uses the right imports, and handles edge cases I was about to write anyway. I accept about 60% of suggestions. The other 40% I reject and write myself, which is fine — the time saved on the 60% compounds fast.

Cmd+K inline edits. Select a block of code, hit Cmd+K, type "add error handling" or "convert to async/await" or "extract this into a hook". The edit respects surrounding code — it doesn't reformat your file or change variable names you didn't ask it to touch. This is where Cursor beats copy-pasting into a chat window.

Codebase-aware chat. When I need to understand how something works, I @-mention a file or function in Cursor's chat and ask questions. It reads the actual implementation, not a cached summary. "How does the reranking layer weight inventory vs. similarity?" with @rerank.py gives me a precise answer grounded in my code.

What I've turned off: auto-suggestions in markdown files (too noisy), suggestions in config files (wrong too often), and the "generate commit message" feature (I write my own — they're documentation, not busywork).

Codex: The Background Worker

Codex fills a specific niche: tasks I want done but don't want to babysit.

Test generation. "Write integration tests for the checkout flow covering happy path, insufficient inventory, and payment failure." I review the output, adjust assertions, and merge. The tests aren't perfect — they over-mock and sometimes miss edge cases — but they're a solid starting scaffold that saves 45 minutes of boilerplate.

Migration scripts. "Generate a Python ETL script that reads products from this WooCommerce REST API schema and writes them to Medusa v2's product module format." The output needs debugging, but the structure and API call patterns are right, which is the tedious part.

Documentation. "Write JSDoc for all exported functions in this module." Straightforward, correct 90% of the time, and saves me from the task I'd otherwise never do.

What I don't use it for: anything requiring judgment about architecture, security-sensitive code, or anything I need to ship without thorough review. Codex output is a first draft, never a final product.

The Workflow in Practice

Here's what a typical feature build looks like:

  1. Understand the requirement. Read the ticket. If the codebase is unfamiliar, use Claude Code to map the relevant code paths.

  2. Plan in Claude Code. For anything non-trivial, I describe the feature and ask for an implementation plan. Not code — a plan. "What files need to change, what's the order of operations, what are the risks?" This catches architectural mistakes before I write a line of code.

  3. Build in Cursor. Open the files, start coding. Tab completion handles the repetitive parts. Cmd+K for transformations. Chat for "wait, how does this utility work again?"

  4. Kick off background tasks in Codex. While I'm building the feature, I have Codex generating tests, writing migration scripts, or documenting the module I just created.

  5. Review and integrate. Review Codex output, merge the useful parts, discard the rest. Run the test suite. If something breaks, Claude Code is faster than me at tracing the failure.

  6. Commit. Write the commit message myself. Ship.

This workflow means I'm rarely blocked. If one tool is slow or gives bad output, I switch to another. The tools complement each other — Claude Code for breadth and planning, Cursor for speed and flow state, Codex for parallelisation.

What AI Tools Don't Do

I want to be honest about this because the marketing around AI coding tools oversells the reality.

They don't replace understanding. If I don't understand the system I'm building, AI tools make me faster at building the wrong thing. The architecture decisions, the "should we use pgvector or Pinecone" calls, the "this abstraction is wrong" realisations — those come from experience, not from a model.

They don't write production code unsupervised. Every line of AI-generated code gets reviewed. I've caught subtle bugs — off-by-one errors in pagination, missing await on async calls, SQL injection in dynamically constructed queries — that would have shipped if I'd trusted the output blindly.

They don't save time on hard problems. A gnarly race condition, a performance cliff in a specific data shape, a business logic edge case that requires domain knowledge — these take the same amount of time with or without AI tools. The tools help with everything around the hard problem, which frees me to focus on the hard problem itself.

They do save time on everything else. Boilerplate, refactors, test scaffolding, import management, API integration code, documentation, data transformations, schema migrations. The volume of "I know exactly what to write but it's going to take 20 minutes of typing" work in a typical project is enormous. AI tools compress that by 50-70%.

The Numbers

I don't have rigorous before/after metrics — I didn't run a controlled study on myself. But based on project tracking:

  • Feature delivery time is roughly 30-40% faster than two years ago, accounting for the fact that I'm also working on harder problems now.
  • Context switching cost is lower. Instead of "let me read this whole module to understand it," I ask Claude Code and get a summary I can verify in 2 minutes.
  • First-draft test coverage goes from "I'll write tests later" (which means never) to "Codex wrote them, I reviewed them, they're merged."

The biggest win isn't speed — it's consistency. I ship with tests, documentation, and error handling that I'd skip under deadline pressure if I had to write them manually.


If you're not using AI coding tools yet, start with Cursor. It has the lowest friction — it's just VS Code with better autocomplete. Once you're comfortable with that, add Claude Code for the tasks that need whole-project context. Codex is the last one to adopt because it requires trust in async output you'll review later.

The tools are multipliers, not replacements. They multiply whatever engineering judgment you already have. If your judgment is good, you ship faster. If it's not, you ship bad code faster. Invest in understanding first, then let the tools handle the typing.