Recently a colleague asked me to show how I use AI as he wanted to understand how I was so productive, and that gave me the idea of sharing it here.

I know that this kind of ‘how I use AI’ post doesn’t tend to age well as things move fast, but maybe it will be useful to someone in the meantime.

As I said on other posts here, I love and hate AI at the same time. I love that it makes me a lot more productive and I can do more, but also it overwhelms me and takes the fun out of some things.

But let’s talk about the usage now.

Claude Code in the Terminal

I used the Copilot plugin and the native AI window in IntelliJ, and they were good. A few months back we switched to Claude. I have the desktop app installed but rarely use it.

What I use is Claude Code in the command line. While I’m not a command line person, I grew to like it. I started there because, as of now, there’s no Claude plugin with an embedded chat window in IntelliJ and our account does not connect to the native AI assistant UI.

I like prompting close to the code that is being changed so I can see what is happening and review it, and running Claude Code in IntelliJ’s terminal makes my life easier.

I usually have many projects open in IntelliJ and each has one or more terminals with Claude sessions. I keep one session per problem or context I’m working on and being able to have more than one helps to parallelize things.

I also start fresh a lot. /clear is by far the command I use the most: 160 times so far, almost twice as often as /code-review. A long session drags old context into the new task, the answers get worse and it burns tokens. When I need to come back to something, I name the session with /rename and pick it up later with /resume.

Also, I got used to the CLI commands to use skills, mention files, etc.

What I don’t like is editing text and especially copying things from the session as they usually don’t copy well-formatted.

Choosing the Model

For the model, I just go with the default one which is Opus 5.5. It does a good job in agentic workflows and in general. I played with Fable a while back but didn’t see much improvement; it just burned tokens faster. Maybe I need to try it again.

My approach is to use the best available model given that I don’t come close to running out of tokens. With Opus 5.5 I have a powerful model and enough tokens for everything.

My CLAUDE.md

I guess this is what sets me apart from my coworkers.

I have a well-tailored global CLAUDE.md with my preferences and best practices. So the code output for any project is already better than average.

The easiest way to build one is to ask Claude to analyze all your sessions and gather the way you work or things you ask frequently. One example is that AI loves to add code comments which goes against clean code, so I put a lot of emphasis on avoiding them.

Each rule is a short heading, the rule itself, and when it matters, a Why and a How to apply line. The why is what makes it work: Claude can use judgment on cases the rule did not foresee instead of following it blindly. A few examples:

## Never commit unless I ask

Do not run git commit, git push, or create a PR unless I explicitly ask.
Finishing the code is the deliverable, committing is a separate decision I make.

## Always open PRs as draft

Create every PR with `gh pr create --draft`.

**Why:** Opening a PR as ready for review pings reviewers before I have looked at the diff myself.

## Default to no comment

Write the change with no comments, then add back only those whose
absence would cause a specific, nameable misreading.

**Why:** A comment is a second copy of the truth with no compiler,
no test and no reviewer checking it. It drifts, and a stale comment
is worse than none because it is believed.

## Read origin/master, not the working copy

Fetch and read the code at origin/master before claiming what it does.

**Why:** A finding that looked verified turned out to be wrong because
the local checkout was months old and the code had already been fixed.

Most of the rules came from a correction I had to give more than once. If I tell Claude the same thing twice, it belongs in the file.

Every two weeks or so I ask Claude to re-analyze the history and check if there is anything worth adding there. Claude writes the changes itself, based on what it thinks is worth adding. I turned this into a custom skill that writes the proposed changes, with the conversations that support each one, to a file I review before anything goes in.

I also enriched the global CLAUDE.md with some architectural guidance I like. I asked it to read some best practices documents we have and add the important stuff.

Second Brain

Due to the nature of my role, I have almost all microservices code locally checked out and that helps me guide Claude to check cross-project references.

I also keep a repository with my notes in markdown. The main thing I did was map out our whole architecture and our products and which services each product flow uses and big picture details of it.

The global CLAUDE.md has a reference to this repository so it knows where to get information when it needs to understand the relationship between services or the product information.

For example, it helps track down issues because it knows, or knows how to get, the information about consumers and producers.

By adding only the references and not the whole thing, we save tokens and keep the context clean, while still telling Claude where to look.

Notes go stale though, so each map records the commits it was read at. Claude treats them as dated evidence to verify, not as the truth, and can diff them against the current code to find what changed.

MCPs and CLIs

MCPs are what give the model real power. We have a few MCPs that are allowed, and where a good CLI already exists, Claude just uses that.

Honeycomb

I am obsessed with observability as it is how we know how our production works, as you may notice from other posts I have here.

Honeycomb is a great tool to understand how a service behaves through its traces. Recently we migrated our classic environment to Environments & Services so now we can use its MCP.

It was basically a night and day difference. Claude now checks not only the code but, more importantly, how the code really runs in prod.

It has helped me find many issues and deliver work based on data rather than guesses.

It is by far the MCP I use the most, with about 2,500 queries in four months. They are mostly counts, error rates, latency and breakdowns by service or client to check how often something really happens. Before writing a query, Claude looks up which spans and fields exist, and when something looks off, it pulls a single trace to follow one request across services.

It is not only for reading. I also use it to audit and tune our triggers and SLOs: checking which alerts are noisy or never fire, adjusting thresholds and creating burn alerts.

One tip: keep a note describing the shape of your telemetry, like which fields are named differently across services and what sampling drops. Without it, Claude writes plausible queries against the wrong field and an empty result looks like proof that code is dead.

Atlassian

Mostly reading. Claude reads our Confluence documents for extra context if needed, and pulls Jira tickets to understand the task or to search for an existing ticket before creating a duplicate.

It also writes: it creates tickets, moves them through statuses, adds comments and creates or updates Confluence pages. Automating these parts is really good. My favorite thing is to create bug tickets.

IntelliJ

IntelliJ also exposes an MCP, so Claude can use the IDE’s call hierarchy to find the real callers of a method instead of relying on text search. That matters when deciding if code is safe to delete, since a grep misses calls through interfaces and finds matches in comments.

GitHub CLI

I wasn’t sure if Claude used the GitHub MCP or the CLI, so I checked my session history: it is 100% the gh CLI. You don’t need an MCP for everything when a good CLI already exists.

Creating PRs, checking failures, etc. have never been so easy. Claude creates and edits PRs, reads the logs of failed CI runs, reads files from repositories I don’t have checked out and searches code across the whole organization to find who uses something.

Claude also updates branches from master, fixes conflicts, etc.

Skills

The main native skills that I use are:

  • /code-review: spins up review agents that look at the diff with fresh eyes, and with --fix applies what they find.
  • /simplify: reviews the changed code for reuse and simplification, not bugs.
  • /init: generates a CLAUDE.md for a repository the first time I work on it, so the next session starts with the build commands and conventions.
  • skill-creator: helps write and test new skills.

I have a few custom skills that I created to automate some of the things I do repeatedly:

  • Dependabot triage: my most used one. It goes through a backlog of open Dependabot PRs, classifies each one as superseded, stale, on a dead code path or current, rebases the stale ones and approves a safe subset.
  • Incident investigation: lives in the repository of the service it covers, so the whole team gets it. Given an incident, it finds the root cause in the code at the deployed commit, the evidence in Honeycomb, similar past incidents in Jira, the change that introduced it and how many clients were affected.
  • Architecture map refresh: lives in my notes repository. It compares the commits each map was read at with the current code and reports which claims may be out of date, so I only rescan what changed.
  • Production issues analysis: finds what is actually broken in a service from Honeycomb, ranks it by how many clients it affects rather than error volume, links each one to the code that throws it and checks whether our alerts would have caught it.
  • Kill with fire: a family of skills that find and delete unused dependencies, dead code and endpoints nobody calls. They check production telemetry before deleting anything, so “no references in the repo” is not the only evidence.
  • Migration playbooks: when the same migration has to happen in many services, like moving services to OpenTelemetry, I do the first one with Claude and turn it into a skill for the rest.
  • Revise global CLAUDE.md: the history analysis I described above.

A skill is just a markdown file with instructions, so whenever I catch myself explaining the same multi-step process twice, I ask Claude to turn the conversation into one. Where it lives matters too: a skill in my global folder works everywhere for me, a skill in a repository is shared with everyone who works on it.

From Problem to PR

I’m probably a bit guilty of overusing AI, but with my current setup it produces very good results, so I think it is worth it. Fixing problems that impact clients is more important than perfect code.

In general, my workflow depends on how I find the problem or how it gets to me.

I usually try to investigate whether the problem is really what is described or has other angles, so I fix or work on the correct problem. This is where the setup pays off: Claude reads the code, checks how it actually behaves in production with Honeycomb and uses my notes to find which other services are involved.

Then I like to write a test to cover it, so we can reproduce the problem and make sure the fix is working, and it is usually Claude that writes it.

Next comes the fix: making sure the test now passes, and running the service to reproduce it locally if possible.

After that, I like to ask for /code-review high --fix so it spins up a review agent that takes a fresh look. It usually finds nice things to fix.

After all the AI reviews, it’s my turn to review and make sure it is ok.

I then ask Claude to open a draft PR. If it is complex, I like to add a mermaid diagram in the PR description to make it easier for reviewers.

Sometimes I add inline comments in the PR to explain the solution.

Guardrails

The more Claude can do, the more I want to be the one deciding what leaves my machine. My CLAUDE.md says it never commits, pushes or opens a PR unless I ask for it, and when it does, the PR is a draft so reviewers are not pinged before I have read the diff. When I only want an answer from Honeycomb, I tell it to query only and create nothing, so it does not create boards or triggers on the way.

What Still Goes Wrong

It is not perfect, and the mistakes come in the same confident tone as the right answers.

Once, Claude gave me a finding with code references that looked verified, and it was wrong: my local checkout was months behind and the code had already been fixed. Now it reads the latest master before claiming what the code does.

Subagents, the helpers Claude spins up to work in parallel, have been wrong in both directions: calling live code dead and calling configuration unused when it was in use. I treat their reports as leads and verify the important claims myself.

And as I said in the Honeycomb section, an empty telemetry result is not proof the code is dead.

Every one of these became a rule in my CLAUDE.md, which is why that file matters so much.

By the Numbers

I started using Claude Code at the end of June 2026. In about four months, my session history shows:

  • 555 sessions over 76 active days, across 56 repositories.
  • About 6,800 prompts from me and about 102,000 tool calls from Claude, roughly 15 actions for each thing I asked.
  • About 39,000 shell commands and 8,600 file edits.
  • About 2,500 Honeycomb queries.
  • 415 subagents launched for parallel work.
  • A global CLAUDE.md with 33 rules in 298 lines, and 11 custom skills.

Final Thoughts

None of this is magic. Most of the value comes from context: instructions that capture how I work, notes that explain how the system fits together, and tools that show what really happens in production. The model is the same one everybody else has.

I still love and hate it. But if you only take one thing from this post, start a global CLAUDE.md and add a rule every time you correct Claude twice.