We’ve been working on a green field SaaS application over the past several weeks. It’s not too complex (~35,000 lines of code) but has a Typescript + React front end with a Typescript + Postgres + Drizzle back end accompanied by some BullMQ workers. We started out with Cursor + Claude Sonnet 3.7 and then moved to Claude Code + Claude Opus 4 when it was released.
The jump in capability has seriously impressed us!
-
Cursor would often get into “doom oscillations” where it would try to implement something using approach A, fail, try approach B, fail, and then try A again. It was super annoying. Claude Code seems much more stable in this regard and nearly always makes good forward progress, with only occasional times where we need to nudge it with simple hints.
-
Claude Code’s planning mode (press SHIFT-TAB until you get into it) will prevent it from altering anything while you are working out the details of what you want it to do. We find this much more natural than asking it not to code and hoping it still remembers that several rounds later in conversation. Cursor seemed to strongly want to move to implementation so it was really annoying when it would start coding when you weren’t ready.
-
Claude Code’s use of tools for digging out code context is really impressive and mimics many things we do as experienced developers: grep, read docs, trace things through the front end and back end, and many others. Even better, it’s very transparent as to what it is doing so we can abort if it’s on the wrong track or seems to be struggling. It was harder for us to see what Cursor was doing, though it seems to have improved with some newer updates, such as adding a TODO list to organize its plan.
-
In general, the quality of output from Claude Code is really good. It can still get in the weeds or try to carry out bad approaches, but it’s fairly easy to avoid that if you don’t run in auto-accept mode. By reviewing things incrementally and accepting each change manually, you can keep an eye on where it’s going and steer it before it goes too far in the wrong direction. Cursor seems to run off on its own in a way that’s harder to steer, quickly dumping edits to many files. You can of course reject its suggestions but it seems more difficult to clean up than using Claude Code in serial mode.
-
The $200/month paid plan for Claude Code is enough for a solo developer to work intensely to near burnout levels. You can do a 5 or 6 hour session before hitting the cool off period, after which you will be moved from Claude Opus 4 back to Sonnet, which is still very usable. This is an amazing amount of value for $200, but it does feel a little scary for the future of our industry where people will be expected to operate at far higher levels of productivity than before, even though these tools require a lot of human input to work well in their current state. As these tools improve rapidy there’s little doubt this will get much better.
Based on our experience so far, here are some tips and best practices:
-
Write docs first - We’ve found very good results with complex changes by running a design pass with Claude Code, giving it a goal to produce a Markdown doc about the work to be done. This process can proceed really quickly since it’s doing most of the writing, and we don’t have to review this super carefully since it’s mostly saved context for the LLM. Once that’s in good shape we can simply ask Claude Code to implement the design in the doc and it’ll run with it. By having the LLM check off checklists in the doc as it goes it’s easier to checkpoint work and continue later, and you have better confidence that things are eventually complete.
-
Update docs after implementing, or remove them - Since these design docs were more tactical than historical we were having the LLM do light updating after implementation was done and then we moved them into an archive directory in the code repository. This ended up being a liability because ideas from the docs that had drifted during implementation would often confuse the Claude Code, so we ended up just deleting these docs once we were done. It was very cool that Claude Code would grep around, find, and read these docs but if you leave docs around you’ll need to ensure they are carefully maintained.
-
Read the documentation for these tools - Anthropic has created some really nice documentation for Claude Code and there are things in there that aren’t obvious. One huge thing we discovered this way is that Claude Code can consume pasted screenshots - you have to use CTRL-V to paste (not CMD-V like you’d normally use on a Mac). You can have it debug your CSS! Read through also the section on how to use a CLAUDE.md file to capture practices you want Claude Code to apply to all its work (there’s also a # command to let the LLM help keep this up to date and remember things on the fly).
-
Claude Code’s IDE integration is really nice - We’ve been running Claude Code in a terminal outside of any IDE and then connecting it as needed. Currently we’re using Cursor to view its proposed changes (you can just hit CMD-S to save the file in the diff view in Cursor and Claude Code will move on and accept the changes). Cursor is still handy for little, focused changes or if we want to work in another area of the code in parallel with what Claude Code is doing, so we’ve kept up a basic $20/month Cursor subscription for that.
-
Use the LLM to refactor early and often - It’s really nice that annoying refactors can be fairly easily passed to the LLM to knock out instead of adding to a TODO list and tackling later (and sometimes never). There are lots of ways to specify these kinds of changes and the LLM is really good at applying patterns. For example, we’ve had good success with really high level task descriptions like “make X work using the same pattern we did for Y” and having the LLM one shot a reasonable update.
If you don’t provide careful supervision it’s clear even the best of these tools would produce pretty bad code given enough development iterations. With the current state of the art, though, if you are a skilled reviewer with a good handle on software architecture you can leverage Claude Code to quickly make specification docs and then crank out code that you carefully review as you go along. We’ve been getting days worth of work in hours this way so there’s huge leverage, especially for the cost.