Introduction

When AI coding assistants first emerged a few years ago they were less than impressive for doing much beyond basic autocomplete tasks.

But then things started to pick up in late 2023 and 2024 when GitHub Copilot Chat hit the scene, Devin AI caused a stir, and finally, Claude and Claude Code began to really win the hearts and minds of web developers and software engineers of all stripes.

Like many of you, I was skeptical of the AI agents at first. GitHub Copilot Chat many times, failed to grasp the basic context or even understand simple code patterns within the file it was told to modify, Devin was eager but again, was ham fisted in its actual code implementation (and difficult to guide via Slack conversation threads), and my initial attempts with Claude resulted in lost time, tokens, and unwieldy amounts of spaghetti code that I ultimately threw away to start over.

Over the past 6+ months, however, I’ve been working with Claude Code, Anthropic’s terminal-based AI coding assistant (and believe me, I’ve never been a terminal dev, IDEs like VS Code are my coding happy place), and learned how to be much more effective when dealing with Claude.

In this article I’m going to share with you the techniques I’ve learned to get the most out of Claude Code and deliver high quality code and features in shorter amounts of time, because like it or not, AI-assisted coding is the future for us all.

Claude Code

The terminal has never been my favorite. I know enough bash to be dangerous and have my go to git commands memorized by heart, but give me a feature-rich, extension-packed IDE like VS Code any day, and I’m off to the races (which probably makes sense since the parts of web development I enjoy most are frontend-focused features).

But Claude Code began life as a terminal-only CLI, and I have to say I’ve gotten quite used to having it open and doing its thing in one terminal window (I use Warp as my preferred terminal), and VS Code open at the same time so I can follow along with the file changes taking place, run the dev server or tests myself, and point out linting and TypeScript errors that Claude might be ignoring or glossing over in an attempt to always be right the first time.

NOTE: Since Claude Code debuted, the team at Anthropic have also released native extensions for Claude Code so it can run inside your preferred IDE of choice, but I have to say, after trying the VS Code extension of Claude, I didn’t like it as much as I like having Claude in a totally separate terminal window.

The extension was a bit buggy for me (unusual crashes or getting stuck in thinking loops until I quit the IDE and restarted), and while I’m sure its reliability has improved, it seemed like the responses weren’t quite as good as what I was coming to expect while working with Claude Code in the terminal. That’s just my opinion though, I have no verifiable proof to back up this impression.

Below, I’ve tried to group the things I’ve learned about getting the most out of Claude Code into broad categories. This isn’t an exhaustive list, but a combination of some (or all) of these tips helps me enjoy the productivity boost Claude can provide for my code, while still feeling in control of the final code outcome. I hope it helps you to dial in your own use of Claude as well, because it really can be quite the coding boost when used effectively.

NOTE: Throughout this article I’ll interchangeably use the terms "Claude" and "Claude Code", but know that with each I am referring to the same thing: the Claude Code CLI that runs in a terminal, not the Claude Desktop program that also exists.

Context matters: give Claude plenty of it

Let’s start with context, because when Claude Code has context of the problem it’s trying to solve, and the existing codebase it’s working within, its solutions will almost guaranteed be better.

Add CLAUDE.md files to your project

CLAUDE.md files are special files you can add to a project that Claude will automatically pull into its context when starting a conversation.

Good things to include in this file are things like:

• General project overview, architecture, and tech stack
• Common development/bash commands and development workflows
• Code style guidelines
• Testing instructions
• Other info you want Claude to remember or be aware of

Providing all of this inside a markdown file for Claude, makes it easy to review, revise, and update as needed, and by checking it in as part of your repo, it means your whole team can give their Claude Code agents the same basic starting point whenever they begin a new session with Claude’s help.

These files can live in the root of a repo, inside specific folders within a repo (like if you have a monorepo), or even in your machine’s home folder (which means it will apply to all Claude sessions everywhere).

To make a new CLAUDE.md file for a project run the /init command inside of Claude Code and it will generate a CLAUDE.md file for you that you can then refine over time.

For example, in one of my projects, there’s a CLAUDE.md file at the root of the project explaining the basic overview of the app and what it does, and CLAUDE.md files inside both the backend/ and frontend/ folders explaining the tech stacks, important npm commands, testing practices, code organization, and PR etiquette among other things.

When you’re writing these files just keep them succinct and easily human-readable, and you should be starting from a good place.

Don’t be afraid to have Claude re-review this file from time to time either, and update it as the project continues to evolve - it’s meant to be a living document.

Copy paste all the things to Claude

They say a picture is worth a thousand words and once I learned I could simply paste all sorts of things into Claude Code’s terminal, I began using it liberally to give Claude more context.

I regularly take screenshots of what I’m seeing while manually testing Claude’s implementation in the browser to show Claude weird styling and layout issues, console feedback and errors, or code that’s just not behaving the way it’s supposed to, and paste it into Claude’s terminal (there’s a better way to debug this sort of thing with Claude Code that I’ll cover later in the article). Likewise, if VS Code is lighting up like a Christmas tree with TypeScript or linting errors or my GitHub Action workflows are failing in GitHub, I’ll copy the text from those and paste that into Claude. Or if there’s a web page that I want Claude to read for additional info or examples of what I’m trying to achieve, I’ll paste that in and instruct Claude to visit it.

Claude has proven pretty adept at being able to deduce possible issues and solutions just from screenshots, so it’s definitely worth your time to feed some images to Claude with a short comment about where the screenshot came from or what it pertains to to see if Claude can pinpoint the problem.

Use the /resume slash command to rehydrate previous conversations

Oftentimes, I’ll finish a new feature, open a pull request, and get it reviewed and merged in, only to pick up another feature that builds off the one I was working on previously. When this happens, using Claude’s /resume command allows me to go back through previous conversations I’ve had with Claude and continue one of those conversations.

In this way (assuming the context window isn’t already full and the conversation has to be compacted immediately), Claude already has prior context to draw from as I instruct it in how to extend the new feature I want.

When you use the /resume command after starting up Claude Code in the terminal, Claude will present a list of previous sessions to choose from that happened within that repo, along with details like when the conversation happened, how many messages were in the conversation, and even the name of the feature branch the conversation took place in, which makes finding the right conversation to resume from easier.

NOTE: This can be extra helpful when you may have worked on other things in between related features and need to reacquaint yourself with the code. Claude can give you a quick summary of a conversation after choosing to resume it to help get you back in the right mental model faster.

Keep Claude’s sessions focused

I know I just said "give Claude lots of context," but at the same time, keep sessions (and context) focused. What I mean when I say this is don’t use the same session with Claude for working on different tickets or features.

Claude has enough trouble staying on track with one feature, especially when you start to factor in things like writing or updating unit tests, fixing TypeScript or linting errors, adhering to the project’s style guide lines or documentation requirements, etc. Throwing Claude a curveball in the middle of a session is as disruptive to it as when someone sends you an email or pings you on Slack when you’re in the middle of deep thinking and your mental model is locked in.

Also, previous conversations in the same session just serve to distract Claude from the new task you’re setting for it and fill its context window with (now irrelevant) details.

If you’ve finished up a task with Claude and are ready to start on something new, either:

• Open a new terminal window and start a fresh Claude Code session
• Use the slash command /clear inside of your current Claude Code session. /clear clears the previous conversation history and frees up context so you can begin again.

Targeted conversations help keep Claude on task and less prone to wander or touch files not related to what it’s currently working on.

If you like GUIs, try the Claude Code VS Code extension

If you’re a diehard IDE fan like me, you may really dig the Claude Code native extension you can install inside of VS Code (or your IDE of choice). The extension got a big upgrade since the release of Sonnet 4.5 and Claude Code v2 a few weeks back, and it has many of the slash command features in Claude Code built in as drop downs and selection menus. Plus, if you’ve already got the relevant code open in one window of your IDE and Claude open in another, it’s pretty easy to direct Claude to where you want it to focus on in the codebase.

Personally, I’ve gotten so used to working with Claude Code in the terminal that I probably won’t switch over to this workflow anytime soon, but if you’re newer to using Claude and you like the experience of having your AI agent and your editor all in one, it’s definitely worth trying out.

Claude does better with code examples to guide it

Another thing I’ve noticed about working with Claude Code is that it tends to do better when it has already existing coding conventions within a repo to look to for guidance. This goes beyond what you’d typically include in a CLAUDE.md file though.

For instance, if you have a particular way of handling errors, logging requests, or writing tests, pointing Claude towards these files and asking it to write code that’s similar for some new feature you’re implementing usually works out pretty well. Don’t expect Claude to be aware of helper functions or to recognize when it’s writing redundant code for multiple functions - you’ll still have to point that out and tell Claude to DRY it up or use the helper function instead of writing a new one, but if there is code that Claude can look to for preferred code syntax or styling, it will help.

On a greenfield project where everything is new, it will be more up to you to make good architectural decisions about your codebase up front and establish code patterns that you like, then to lean on Claude for designing a robust, scalable, maintainable codebase.

Use Claude’s planning capabilities

Just like a typical developer, Claude’s final code tends to be better when it has planned ahead.

This advice really goes hand in hand with the above tips about giving Claude more context so it can be more effective, but beyond telling Claude to look at particular files, read its CLAUDE.md file, and visit those URLs, there’s specific commands and techniques you can use to nudge Claude in the right direction and help it stay on track (and hopefully result in less rewrites when reviewing Claude’s work).

Engage Claude’s extended thinking modes

I only learned about this trick relatively recently, but Claude actually has what it calls "extended thinking mode", which gives Claude additional computation time to evaluate alternatives more thoroughly (i.e. think through a problem and solution more carefully).

To trigger these increasing levels of thinking, you’ll instruct Claude Code to:

• "Think"
• "Think hard"
• "Think harder"
• Or "Ultrathink" (the name of this thinking level cracks me up)

Claude’s different thinking modes

Frequently, I’m less than impressed with Claude’s quickest responses when I tell it about a bug I’m encountering while testing a new feature it’s helped implement, because Claude tends towards the simplest solution that fails to take into account the nuances of this bug (or the impact that the solution might have on other parts of the system that also use the same helper function, reusable component, API endpoint, etc.).

In these instances, usually after Claude’s first attempt to fix it has failed, I’ll tell it the same bug is still there and to "think" or "think hard" about how to solve this. This will trigger Claude to spend more time on the solution: it will read and search the repo for files related to the bug (if you’ve provided a screenshot or pointed to a specific file that might be the culprit), maybe run a bash command or two, then eventually provide a better solution to solve the problem in a more thoughtful manner.

If you want to see what Claude is thinking to itself, in the terminal, you can expand a condensed thinking block with CTRL + O. Here’s an example of the kind of thoughts you might see when you open a detailed transcript of what Claude Code is thinking as it’s going about its tasks.

The kinds of detailed notes you’ll see when you expand one of Claude Code’s condensed thinking text blocks

NOTE: I don’t believe I’ve ever invoked Claude’s Ultrathink thinking mode, but I’ve had good luck with its lower levels of thinking. If you’ve used Ultrathink I’d love to know if you thought its output was worth the extra tokens and processing time.

Tell Claude to make a plan

One tip that helped immensely with Claude, is telling it to formulate a plan at the start of a fresh session or new feature.

Typically, I’ll start a new session, tell Claude what I’m trying to build a new feature for, and point it towards any existing relevant code, docs already written about the topic, or any other helpful info I can think of, and then I’ll ask Claude to think about how it would tackle this feature and make a plan.

This serves two purposes:

1. It makes Claude use one of its extended thinking modes, which almost always guarantees a better end-result.
2. Claude comes up with a discrete set of tasks or todos to accomplish this that I can review ahead of time and approve (or tell it to revise) before it starts actually touching code.

Once I’m satisfied with the plan, I’ll tell Claude to write the plan as a Markdown file inside the project so that it can come back to the plan for reference whenever it needs to (like say, if its current context window fills up and it needs to compact the conversation before resuming work), and I also have a refresher document for future me if I need to refamiliarize myself with that feature again. Once I have verified the final code looks good, I’ll tell Claude to review the plan document again and make sure it did everything agreed upon up front, as well as update any changes that occurred as the feature work progressed.

At first, I thought about tossing these docs after Claude had completed the work, but lately I’ve been thinking of keeping them in the project in a /docs/ folder that I can look to (or point Claude towards) in the future. It can serve as another way to keep useful project context close at hand that can be referenced only when needed instead of plugging it all into CLAUDE.md files that Claude will see every time a new session is begun.

These docs are also helpful when submitting PRs in GitHub, because I can reference them for which files were changed, what work was done, and so on, easily.

NOTE: Anthropic introduced a specific Claude Code Plan Mode back in June of 2025 for this very thing. Plan Mode is a special operating mode that allows Claude Code to research, analyze, and create implementation plans without making any actual code changes. To activate it manually in a Claude Code session press Shift + Tab twice.

I’ve used it a few times now, and haven’t seen a tremendous difference between Plan Mode and when I just tell Claude to plan, but I’d like to know how you think it stacks up if you’ve tested the two modes as well.

Help Claude help itself with MCP tools

Similar to how devs are constantly opening browser tabs to research, test, read docs, and figure things out, you can give Claude similar powers to help itself through the use of model context protocol (MCP) tools.

MCP is an open-source standard for AI-tool integrations, which allows Claude Code (and other AI agents like Cursor) to connect to hundreds of external tools and data sources so that it can be more useful and effective while doing its work.

There’s truly no shortage of MCP servers out there already (many of which are for specific SaaS tools and services), but a couple of more generic MCP servers I’ve gotten benefit from so far are:

• context7 MCP - This MCP provides up-to-date, version-specific documentation and code examples for LLMs and AI code editors. This means that if you’re using the latest version of Svelte, but Claude’s training data is with the previous version, you can tell Claude to "use context7" to look up the latest docs and use those to guide it.
• Playwright MCP - This MCP provides the browser automation capabilities of Playwright so LLMs can open their own web pages, take snapshots, and examine browser output the same way a developer would. This reduces the need to copy paste screenshots of browsers into Claude Code manually.
• Chrome DevTools MCP - This MCP lets Claude control and inspect a live Chrome browser. It goes a few steps beyond Playwright by giving Claude access to the DevTools console, network tab, and even things like Lighthouse for perf testing.

Adding any of these MCP servers to Claude’s arsenal is easy to do. They all have documentation in their GitHub README.md files showing how to install them in all of the popular AI coding agents, and it’s usually something as simple as running a command like this inside of an open Claude session:

claude mcp add playwright npx @playwright/mcp@latest

Once the server is installed, you may need to restart the terminal and resume the session for it to take effect, but going forward, you’ll be able to use the slash command /mcp and see all the currently active MCP servers that Claude has access to.

Then, when you want Claude Code to use any of these MCP servers, you’ll simply instruct it to "use context7 to look up docs for XYZ" or "use Playwright to check what the browser is rendering to the user". You’re helping Claude Code to help itself.

NOTE: The first time Claude uses Playwright to pop open a new browser and navigate to some page of a locally running application on its own is a pretty surreal experience. It was for me anyway.

Lean on Claude’s expertise in unfamiliar territory

Although Claude’s not the best at starting a project from ground zero, it can be very useful for updating files, explaining code, or using programming languages you may be less familiar with because it has been well trained on a large variety of programming languages.

Pair program with Claude to learn while you go

Claude can be helpful as a guide for codebases you’re new to, or even just parts of the code you haven’t touched before but need to work on now.

For instance, recently I had to update the Terraform infrastructure files in a project I work on, but Terraform is not something I’m well versed in. Other folks on my team are the devops go-to people and I’m happy to let them handle it, but in this case, the task fell to me. I told Claude what I needed to accomplish (update these files to point to a new set of URLs in production), and as it helped me update the files I asked questions along the way to make sure I was getting a better understanding of how the Terraform setup works, and which files should or shouldn’t be touched to make sure things kept running smoothly in production.

Now, I hope I don’t need to use that newfound Terraform knowledge much in the future, but when I encounter unfamiliar code or a programming language I don’t know much about, I feel fairly confident with Claude Code by my side that we can figure it out together.

Let Claude write your [fill-in-the-blank] scripts for you

Shell scripting can be a powerful tool for developers, but it’s also one of those syntaxes that, if you don’t use it for a while, quickly starts to slip from working memory (at least for me). So in the case when I need a one-off bash script, a regex function, a new GitHub Action workflow, or [fill-in-the-thing-you-always-forget-the-syntax-for-here], Claude can really come in handy.

The trick here though (and I’ll go in-depth more on this in the next section), is that you need to be able to quickly test and verify that whatever Claude has given you actually works.

Run that shell script, test that regex, watch that GH Action workflow progress, and check the output. Because Claude may produce something that looks sensible (especially in a programming language you don’t use often or at all), and it will be just as confident in its code that doesn’t work as its code that does work until you call it on it. Then you’ll get the standard "You’re absolutely right!"-response and Claude will try again.

Also, ask Claude to explain how the script works if it’s having trouble getting it right. Sometimes, Claude checking its own code helps it find and fix bugs in them as well.

Think outside the box: use Claude for tasks beyond coding

Maybe this isn’t news to anyone else, but I’ve just begun using Claude Code for non-programming related tasks.

Here’s a couple of examples off the top of my head:

• I had Claude Code draft up a PowerPoint presentation outline (and even a couple of diagrams for the presentation itself courtesy of Mermaid diagrams).
• My friend had Claude Code use some family photos and design a nice scrapbook layout to showcase them, that converted to a perfect 8.5" x 11" PDF for printing.

Claude has become synonymous with coding in particular, but it can do a solid job at other things. It can also be quite creative in how it solves a problem since it’s limited to the terminal and can’t actually generate traditional images. So even if you’re tasked with something not directly programming-focused, Claude may be a good sounding board or have some skills that can help you get the job done quicker or in a different way than you may have imagined before.

Don’t trust Claude: review and verify

Ok, this is probably the best thing you can do to get the most value out of Claude Code (and have the least amount of refactoring after the fact to bring Claude’s code in line with your standards and expectations): review and verify everything Claude does. Claude Code is a useful tool, but it must be watched like a hawk (and its code tested often and thoroughly) to keep it on task and making progress towards the goal you want.

Follow along with Claude’s changes in VS Code

In the first version of Claude Code, it would show the code changes it wanted to make to a file inside the terminal itself with the name of the file at the top so devs could see which file it intended to touch. For some devs this may be enough, but for me, I also have VS Code open at the same time to watch the changes being made as Claude goes.

In the current version of Claude Code, there’s a setting you can enable in the /config called "Auto-connect to IDE" that lets Claude show the changes it wants to make to the file in VS Code, which is great. It still waits for permission to make the changes or tell it to do something different, but at least this way you can see the other code in the file along with the changes Claude wants to make.

How to enable Claude Code’s "Auto Connect to IDE" feature in its config settings

When the feature is enabled and the VS Code repo is open on your local machine, Claude will show in its terminal "Opened changes in Visual Studio Code" and pop open the file and display the code changes it wants to make inside the file, very similar to how you see diffs in GitHub PRs. Here’s a screenshot of the Claude Code terminal instance and the file in VS Code Claude wants to modify.

Following along with the changes in the repo and having my own server running (or automated tests, etc.) to frequently test the changes Claude is making and ensure code is working correctly tends to lead to better outcomes and a shorter feedback cycle.

Do not let Claude YOLO (aka "Allow all edits in a session"). Course correct early and often

This may be an unpopular opinion, but I never let Claude make any code changes without my permission. For best results, you cannot "set it and forget it."

I will never choose option 2: "Yes, allow all edits during this session." Claude needs constant supervision.

I have learned through trial and error that allowing Claude to autonomously make decisions without oversight is a recipe for throwing away a bunch of useless code because it took a wrong turn and started going down a bad path and no one stopped it until it was too late.

Yes, it is a bit annoying when Claude asks you for permission to visit a URL you’ve just given it, or view an image you’ve pasted into its terminal, but when it makes a code suggestion and you realize it forgot to account for an edge case or it’s making an assumption that’s false, or it just plain forgot to include something you wanted it to, being able to review the changes, select Option 3 from the dropdown "No, and tell Claude what to do differently", and get it back on the right track is worth the extra time, in my opinion.

It’s much easier to course correct earlier on in the process than when the PR is complete and waiting for review, so keep a tight leash on Claude.

Make Claude test its own code changes

One of the best ways I’ve found to get Claude to catch bugs in the code it’s generated is by having it write unit tests for said code. I know that plenty of folks expound on the benefits of Test Driven Development (TDD), but I’m not one of them. I agree with it in theory, but don’t actually do it in practice.

So after I’ve followed Claude’s code implementation and done manual testing via the API or the UI (depending on the feature), I’ll ask Claude to write unit tests, integration tests, end to end tests - whatever is most appropriate for the situation. Test writing is not something I enjoy doing (all the data setup, the mocks, the spies, the particular testing framework syntax whether you’re using Mocha, Jest, Vitest, Cypress, Selenium, etc., etc.), but I know the value it provides, and the speed with which Claude can produce new test files or update existing test files (especially when pointed towards an existing test file that shows the preferred testing libraries and syntax) is great.

By and large, Claude’s tests (at least in JavaScript and TypeScript) are good. And they have actually caught bugs in the code that Claude wrote. One example that springs to mind, is a timing function where Claude forgot to add a set of times together for the final value in the actual code, but it did correctly calculate what the final time should be in the test. The unit test revealed the bug and with a little prompting from me to review the actual code implementation, Claude found and fixed its error.

Be warned though, even though Claude will happily run test suites for you all day long, it will sometimes say that failing unit tests aren’t due to code changes it made (even though they are) and won’t offer to fix them proactively. In this case, I just tell Claude to fix them anyway - I don’t really care whose fault Claude thinks it is.

Claude can refactor well

Another thing Claude Code can do pretty well is refactor already existing code, although again, it won’t suggest this to you. You must suggest it to Claude.

This might occur when I’ve had Claude implement a more complex feature: functions get big and unruly and try to do too many things, there’s duplicate code for functions that do similar things, or there’s just too much code to look at in one file and it needs to be broken down into smaller, easier-to-understand chunks of code.

Many times I’ve pointed Claude towards a file that’s getting out of hand and told it to either simplify the file by breaking down the big functions into smaller ones, search for duplicate code that can be handled with a reusable helper function, or even refactor out code into separate files altogether. Those files can get pretty gnarly at times, and letting Claude sort out what props need to be passed into newly created functions or UI components saves time and makes the code more readable in the future.

Again, test the refactors after they’re done to make sure everything still works, but I’ve had pretty good success with this in TypeScript-based projects.

Have the AI agents review each other’s work

Like any true developer, the Claude Code session adding new code to a repo is proud of its own output. Bringing in another, more impartial set of eyes, like that of GitHub Copilot doing a PR review or even another Claude instance reviewing the new code, helps keep Claude more honest.

Typically, I will tag GitHub Copilot as a reviewer when I open a new PR in GitHub, and then I’ll take any relevant comments it makes (some comments are irrelevant, so be sure to screen those out using your own good judgement first), and feed them back to Claude Code. Almost always the comments I share with Claude to review and revise end up making the code better and more robust than it was before.

Depending on what GitHub Copilot or Claude Code plans you have, it may make sense for you to have one or the other (or if you really want to go all out, both) review the new code with a critical eye: that’s why we have code reviews after all, and if Claude can write code, it can certainly review it as well.

Conclusion

I don’t believe, based on what I’ve seen, that AI agents are going to replace flesh and blood software engineers anytime soon, but they can be pretty helpful in doing a lot of the day-to-day coding we used to have to do by hand.

By far, my favorite tool to help me code faster is Anthropic’s Claude Code. There was a learning curve to get over: learning what context to provide it, how to engage its different thinking modes for more complex tasks, and to always manually test new features it’s implemented to make sure it’s accounted for everything, but overall, I’m happy with the results I get.

I’m sure I’m not using Claude to the extent that some power users may be, but I feel like the things I’ve picked up about working with Claude Code in the past 6 months or so, have helped me to write good quality code at a faster clip than I would have otherwise (and even improve the DX in existing codebases with nice little, one-off features Claude can whip up in no time).

Thanks for reading, hopefully, if you haven’t given Claude Code a try yet, this will inspire you to do so, and if you have, I hope you learned some new helpful tips to get even better results from it.

So what do you think? Did I miss any tips and tricks you’ve found particularly helpful when using Claude Code? I’d love to hear them.

References & Further Resources

• Claude Code
• Claude Code best practices article
• MCP tools with Claude Code

Want to be notified first when I publish new content? Subscribe to my newsletter.