You're Not Using Claude Code Right If You Don't Do This

If you are reading this, it is because you use or are considering using Claude Code for programming. And if so, then friend stay because we are going to review a complete flow and I am going to show you that perhaps you are not getting the maximum performance you could.

Programming with AI is already a reality. There are better and faster tools every time to help us launch products in a simpler way and at breakneck speed.

But all that speed is of little use if you don’t check what you are doing, if you don’t demonstrate that it really works.

The organized madness of Boris Cherny

Recently I saw a thread on Twitter from none other than Boris Cherny, the creator of Claude Code. And the guy is crazy, but in the best possible way.

Boris has 5 instances of Claude Code running at the same time on his PC, but he also has 5 to 10 more in the cloud. He uses Opus 4.5 as it could not be otherwise, and has a claude.md file to write the project rules.

But what struck me most is that many of his sessions always start in plan mode.

The power of planning before coding

Before writing a single line of code, he starts discussing the plan with Claude: what is going to be touched, why, what options are there and which is the best. And until that plan convinces him, he doesn’t move on to execute anything.

When the plan is clear, he switches to the mode of accepting changes automatically and, according to him, many times Claude gets it first time. He literally says that a good plan is almost everything.

Then he talks about using slash commands for any repetitive flow he does many times a day. He puts all that in versioned commands inside the project, so as not to have to repeat prompts or explanations over and over again.

That is, he is not “talking” to Claude constantly, he is reusing behaviors.

What nobody is talking about: validation

And here comes the interesting part. In this entire thread, Boris talks about planning, rules, agents, workflows… but at no time does he go into detail about testing as such.

He doesn’t talk about unit tests, he doesn’t talk about pipelines, he doesn’t talk about coverage. He talks about verifying, checking that everything works, but always from a more global point of view.

That’s why I want to show you what I use to validate everything that Claude Code generates for me.

TestSprite: real testing for AI-generated code

I use nothing more and nothing less than an MCP (Model Context Protocol). If you still don’t know what an MCP is, in short it is basically the connector for your assistant to talk to external tools.

And the tool we are going to connect to is TestSprite, an MCP that is going to help us do our tests, try them and give us tangible results.

Installation in Claude Code

First you need a TestSprite API key. You create an account, go to the API keys section and copy it.

Now, you go to your project directory:

cd /path/to/your/project

And run the command to add the MCP server to Claude Code:

# In PowerShell (Windows)
$env:API_KEY = "your-api-key-here"

# Add the MCP
claude mcp add-json testsprite-mcp '{
  "type": "stdio",
  "command": "npx",
  "args": ["@testsprite/testsprite-mcp@latest"],
  "env": {
    "API_KEY": "${API_KEY}"
  }
}'

To verify that everything is fine:

claude mcp list

And ready, you have the complete installation.

The complete flow: from code to evidence

For the demo I’m going to use a frontend with a couple of typical flows: login, navigation and a mini checkout. The important thing is that I’m going to raise it locally:

npm run dev

The magic command

And now comes the part that I like, because it is very “okay, do it”. I go to the Claude Code chat and say:

“Can you test this project with TestSprite?”

And here something key happens: Claude is no longer giving an opinion. It is calling tools.

It opens a configuration in the browser where you define:

Type: frontend
URL: your localhost
Scope: you can choose codebase to make a complete pass
And if there is login, you give it test credentials (never use your real account)

And from here… I literally do nothing. The agent analyzes the project, generates a normalized PRD if you give it one, and starts preparing the tests.

Tangible results, not opinions

When it finishes, it leaves you a folder in the project with results and reports. And I like this because it is tangible: it is not “the AI told me”, it is that there are artifacts.

It generates reports in Markdown and HTML. And in the report you have what everyone wants to see:

Coverage of tests
What failed
Why it failed
And the star data: pass rate

And this is where you realize something: what you thought was “fine”… sometimes is half fine.

The power of visual bugs

But the wildest thing is when there is a visual bug. Because here most tools tell you: “element not found”, “timeout” and that’s it.

Here you have preview/playback of how the test was executed. That is, you see it.

And this is very important for UI, because there are bugs that are literally:

“The button exists, but it is covered”
“On mobile it gets misplaced”
“The modal blocks the click”

You can see the test trying to click and failing. And in the playback video you understand in two seconds what happened. This is what I call: “no opinion, visual evidence”.

Closing the loop: test → fix → retest

Seeing the bug is fine, but what we want is to close the complete loop:

test → failure → fix → retest

So I go back to Claude Code and say:

“Please fix the codebase based on TestSprite testing results.”

And now Claude does what it does best: touch the code. But no longer blindly. It touches it with a goal: to fix the failure that the test has demonstrated.

The moment of truth

You re-execute the flow and look at the report again. And the satisfying moment is when you see:

Fewer failures
Better pass rate
And the visual bug no longer appears

And this, for me, is the difference between “I did vibe coding” and “I shipped with confidence”.

The final reflection

I leave you with an idea for you to keep.

Boris optimizes the building loop: plan mode, multiple agents, guidelines… But if you don’t optimize the validation loop, your speed is dangerous.

Because quality is not negotiable. What happens is that before quality was given to you by time. And now, since you go fast… you need a system.

And for me, these testing integrations with MCP are exactly that: a real system.

Who is responsible?

And now I ask you: If today your code is written by an agent… who is responsible for it working?

Because “I thought it worked” is not valid in production.

Try TestSprite

If you want to try it, TestSprite has a Free plan and the Starter one which is great to start because the first month is free. I leave the link in the video description.

And if you try it, tell me in the comments: what bugs has it found for you? Because I swear sometimes it brings out things you hadn’t even considered.

See you in the next post.

O que você achou?

Deixe sua opinião, pergunta ou sugestão. Os comentários são sincronizados com GitHub Discussions .