Claude Code do's and don't's

AI is moving very quickly. Assume this post will be obsolete by April 2026.

At the risk of having read too much into too few examples (ironically, one of the ways humans still beat AI is that we do this much more effectively than any machine learning system), here's my experience with one of the current leaders in GenAI as a coding assistant:

Don't use the chat interfaces. Yes, chat interfaces can make code, and it can even be good code, but command line tools like Claude Code have all the extra tooling (and possibly fine tuning to use that tooling) needed to turn a cycle of:
```
prompt
do {
  copy reply
  paste reply into IDE
  compile
  test
  copy test result
  paste test result into chat window
} while not done
```
into
```
prompt
do {
  answer questions and requests for permission
} while not done
```
Do configure a test system. Preferably something the LLM can use directly, but even if you're testing something that's a matter of taste, e.g. video game difficulty balancing, make sure testing is easy.
LLMs can write tests. Take advantage of this to get 100% test coverage if at all possible; sure, some things don't make sense to test, but for anything less than 100% make sure that a good reason and not just a voice in your head going "ugh" after you imagine yourself writing those tests. Remember, the usual human intuition about "100% test coverage is expensive" no longer applies: having an LLM churn out the equivalent of "I spent this month doing nothing but writing tests" costs about as much as a 30 minute meeting between you and your boss, even if both of you only earned the US federal minimum wage.
Never accept less than 100% pass rate from your tests. If you have 100% coverage and 98% of tests pass, your code is very broken. Watch out for this, as LLMs will still applaud themselves for 98%.
LLMs know a lot about testing, but will also quite happily write their own testing system or try to install tools you may not want them to install, so you should pay attention here.
You still need to perform project management, don't just dive in with your next goal. Think sprint planning sessions, or something like that. This is because if you ask Claude Code to attempt a task which is only a bit beyond its competence, it won't warn you, it will just start churning out code and get into dumb loops and make edits to dozens of files and spit out a PR that either doesn't fix the problem, or does but introduces new ones. What you end up with will take so long to perform a real code review on that your valuable human time will get stuck in a cycle of dealing with merge conflicts from other developers (LLM assisted or otherwise) while the main branch gets updated before this solution is ever ready to merge.
LLMs can also assist with project management. Just as scrum masters don't need to estimate ticket complexity themselves and instead simply ask the devs for estimates, so too is your role here: ask the LLM itself to break down large tasks into small tasks, you shouldn't spend time on doing that yourself manually. My anecdotal experience is that taking some big task and asking an LLM to break it down into steps that would each take a normal developer less than 1.5 or 2 hours (durations I took from the METR study), result in, to my surprise almost total success. The reason for my surprise is that the METR study said this should only have worked on 50% of the tasks, therefore something weird is going on.
You can give an LLM an entire sprint's worth of easy tasks to do, so long as each task is itself small. Even a TODO list will handle this, though when all the tasks on that list are done you may want to clear that file, because the LLM tends to mark items as done rather than remove them from the file.
Those sprints will take a few hours of wall-clock time, during which your role is to think about the questions Claude Code gives you, and to perform code review on the PRs it makes. Do not blindly accept PRs: I know it was always tempting to skim-read PRs from other humans and respond "LGTM", and these models are good enough that it can be very tempting to vibe code in the original sense (i.e. to blindly accept everything), but this is setting yourself up for a fall.

When your preferred LLM is working correctly, the code it produces won't be hard to follow, it won't be hard to perform a PR; conversely, when the code it gives you is hard to follow, that's a warning sign that you need to intervene: pay down any technical debt, and/or make the requirements cleaner, and/or break the task down into smaller steps.
Technical debt is still a thing. The feel of the code that LLMs currently (early Jan 2026) churn out is still very much closer to "junior who specifically gets a kick out of writing code" than "senior who specifically describes themself as 'lazy' during job interviews as a positive selling point". Therefore, you should absolutely allocate "sprints" to just refactoring.
LLMs can perform code review. They can put the result of the code review into a document, itemise it as tasks, and work through those tasks. You should look at this file before saying "yes", as the items on it are not always going to be relevant for your business interests.
Business domain knowledge is important. One of the things I had Claude Code write for me was a game, and the LLM's code review of itself was worried about users cheating by editing their scores, or injecting JavaScript into the highscores chart because the name field was freeform text. These would be perfectly valid concerns if it wasn't a local-only game running in a web browser, where the user would be able to cheat from the console and the only person affected by a JS injection would be themselves.

Tags: AI, Artificial intelligence, business, Coding, list, Opinion, Programming, software engineers, Technological Singularity, Technology

Categories: AI, Opinion, Professional, Software, Technology,