How I Use Claude Code and Cursor to Speed Up Full-Stack Development

I get asked about this a lot lately: "Do you actually use AI to write the code?" The short answer is yes — Claude Code and Cursor are part of my daily workflow on real client projects. The longer answer is more useful, because how you use these tools is the difference between shipping faster and shipping a mess.

This post is a practical look at where these tools genuinely save me time on full-stack work, where they don't, and how I keep the output at a quality I'd happily put my name on.

Two tools, two jobs

People lump all "AI coding tools" together, but I use them for different things.

• Cursor lives inside the editor. It's great for fast, in-context edits — refactoring a component, writing a function while I watch, autocompleting the obvious next few lines. It shines when I'm in the flow and want to stay there.
• Claude Code works at the project level from the terminal. I lean on it for larger, multi-file tasks — "wire this new endpoint through the service, controller, and types," or "find every place this old API is called and update it." It's better at holding a whole change in its head.

Neither one replaces understanding the codebase. They make me faster at things I already know how to do.

The business problem: developer time is your most expensive resource

If you're paying for a build, you're really paying for hours. Anything that turns a one-hour task into a fifteen-minute task — without lowering quality — directly lowers your cost and shortens your timeline.

The catch is that "without lowering quality" part. AI tools can produce code that looks finished but isn't. So the real skill isn't typing prompts — it's knowing which work to delegate, and reviewing the output like you would a junior developer's pull request.

Where these tools save me real time

Boilerplate and plumbing

Every full-stack feature has a predictable shell: a typed endpoint, request validation, a database query, the matching frontend form, loading and error states. This is necessary but not interesting work, and it's where AI gives the biggest, safest speed-up. I describe the shape, the tool drafts it, I review and adjust.

Repetitive, mechanical changes

Renaming a concept across forty files, updating every call site after an API change, converting a batch of components to a new pattern — this is tedious and error-prone by hand. Claude Code does it quickly and consistently, and I diff the result before accepting.

Tests I'd otherwise be tempted to skip

Under deadline, tests are the first thing people drop. AI makes it cheap to write the cases I'd skip — the empty list, the expired token, the duplicate submission. More coverage for less effort is a straightforward win.

Understanding unfamiliar code

When I join an existing project, I can ask Claude Code to explain how a subsystem hangs together instead of reading every file cold. It's a faster way in, and I still verify what it tells me.

Where I don't lean on them

The line I've settled on isn't really about the tool — it's two questions: how reversible is this change, and can I prove it's correct? If something is cheap to revert and easy to verify with tests, I'm comfortable letting AI do a lot of it. If it creates long-lived constraints, AI is a drafter at most, and the final call stays mine.

• Architecture and data modelling. These decisions compound. I make them myself and only use AI to stress-test the options. A schema that looks fine and generates in thirty seconds can bite you weeks later.
• Anything security-sensitive. Auth, permissions, payment flows, tenant isolation — I write and review these carefully. AI will happily generate an endpoint with no authorization check.
• Subtle business logic. If the rules are unusual or have real money attached, I want a human fully in control of the details.
• Failure handling. The happy path generates beautifully; it's the partial failures, retries, and idempotency that AI quietly guesses wrong — and you don't find out until it's running in production.

The deeper risk usually isn't the code itself — it's the assumptions it bakes in without telling you. A generated function can pass every test while silently assuming "this field is always there" or "this list never gets big." Nobody wrote that down, so nothing is watching for it. My real filter is: does this code encode an operational assumption that nothing else is checking? For validators, CRUD, and UI states those assumptions are local and visible, so I'm relaxed about them. For the data model and the integration seams they're global and silent — which is exactly where a confident wrong guess survives review.

A realistic example

A lot of my recent work has been on multi-tenant SaaS platforms and ticketing systems — the kind of projects with a NestJS or Node backend, a typed React or Next.js frontend, and a lot of CRUD surface area across many modules: users, events, tickets, payments, notifications.

On that kind of codebase, the pattern is repetitive by design — each module looks similar to the last. That's the sweet spot for AI assistance. I can scaffold a new module's endpoints, DTOs, validation, and frontend forms in a fraction of the usual time, then spend my actual attention on the parts that differ: the permission rules, the edge cases, how it fits the existing architecture.

The honest result isn't magic — it's that the boring 70% goes faster, which leaves more time and energy for the 30% that decides whether the feature is actually good.

Common mistakes I see

• Accepting big AI changes without reading them. The bigger the diff, the more likely something subtle is wrong.
• Prompting instead of thinking. If you don't know what good looks like, AI can't tell you — it'll just produce something.
• Skipping the data model step. A schema rushed by AI is a schema you'll fight for months.
• No tests. Speed without a safety net just means you break things faster.
• Letting style drift. Without guidance, AI writes code in its own style, not the project's. I keep it matching the surrounding code.
• Ignoring subtle coupling. The expensive bug is rarely syntax — it's one generated helper quietly becoming the place where auth, billing state, and product assumptions all meet. It ships fast and charges interest later.
• No visibility into who's using AI on what. You can have flawless review discipline and still get wrecked if half the team is feeding production schemas to an AI tool without telling anyone. Governance — without being paranoid about it — is its own problem.

How I keep the quality high

1. Small, reviewable changes — I'd rather guide ten focused edits than accept one giant one.
2. Read everything — every AI-written line gets the same review a teammate's PR would.
3. Tests on the important paths — especially the failure cases.
4. Match the existing patterns — the code should look like the rest of the codebase, not like it came from a different project.
5. Keep the human decisions human — architecture, security, and money logic stay in my hands.
6. Make every AI change account for itself — for anything non-trivial, I want the change to surface what it actually touched: which tables, routes, or permissions changed, what could corrupt data or leak between tenants, before/after proof, tests added or deliberately skipped, and a rollback path. That receipt matters more than which tool produced the code.

If you're curious about the bigger picture of building lean products this way, I wrote about how AI-assisted development helps build MVPs faster without losing quality.

Want a developer who uses modern tools properly?

Using AI well is a skill — it's the difference between a faster, cleaner build and an expensive cleanup later. I use these tools every day to ship full-stack web and mobile projects faster without cutting the corners that matter.

If that's the kind of developer you want on your project, take a look at my work or reach out and tell me what you're building.