Claude Code

I remember the first time I tried a GitHub Copilot suggestion in IntelliJ IDEA. It felt like magic. You start typing a method name, and suddenly the entire implementation materialises in grey ghost text. You press Tab, and — bam — it’s there. That was impressive. But it was still you doing the driving. In 2026, the landscape has shifted. Claude Code feels different. It’s less “autocomplete on steroids” and more “a colleague who sits next to you, holds the entire 1M token context of your codebase in their head, and then just… gets to work.” Let me show you what I mean. ...

In Part 1, I showed you what Claude Code is and what it can do. You saw an AI agent that reads your project, writes code, runs your build, and fixes its own mistakes. Impressive stuff. But here’s the thing. If you just fire up Claude Code and start prompting, the output you get is… generic. It’s correct, sure. But it doesn’t know your team uses MapStruct instead of manual mapping. It doesn’t know your POST endpoints need authentication. It doesn’t know you measure everything with Micrometer and that a controller without metrics is considered incomplete. ...

Claude Code — Teaching It Your Standards with Skills In Part 2, we turned CLAUDE.md into a precision instrument. We wrote down our conventions, our architecture, our rules — and watched Claude Code go from producing generic boilerplate to code that could survive a code review. But here’s the thing I noticed after a few weeks of working this way: my CLAUDE.md was getting fat. It started small. Build commands, naming conventions, a few architecture rules. Then I added a section on how to generate a complete REST slice. Then testing patterns. Then a procedure for running database migrations with Flyway. Before I knew it, the file was 300 lines long, and every single line was loaded into every single session — whether Claude needed it or not. ...

It was a Friday afternoon and I was in the middle of a long debugging session. I had been going back and forth with Claude Code for maybe forty minutes — adding context, correcting assumptions, exploring three different theories about why a JMS listener was silently dropping messages. The session was getting noisy. Old context from theories I’d already ruled out was still sitting there, cluttering the conversation. I didn’t know about /compact yet. ...

Every team has its boilerplate. At clients, every new REST controller we write follows the same shape: a @RestController with a @RequestMapping, constructor injection (never field injection), a @Slf4j logger, ResponseEntity return types, proper HTTP status codes, and a matching service interface already wired in. Oh, and Lombok. Always Lombok. The first few times I asked Claude Code to generate a controller, I typed all of that out. Every time. A paragraph of instructions just to get the scaffolding right before the interesting work could begin. ...

A couple of months ago I was debugging a tricky data issue and I had three windows open. Claude Code on the left. A psql terminal on the right. A schema diagram in a browser tab somewhere behind. The loop went like this: ask Claude what it thought the issue was, copy a query Claude suggested into psql, run it, paste the output back into Claude, repeat. That’s not pair programming. That’s being a tape recorder between two systems that should be talking to each other. ...

I spent forty-five minutes last week undoing a refactor that should have taken ten. The change looked simple. Rename Ticket.getStatus() to Ticket.getStatusText() — we’d added a proper enum-typed getStatusEnum() a while back, and the string version needed to be less ambiguous. I asked Claude Code to do the rename across the codebase. Standard stuff. Claude confidently reported back: “Renamed 47 references to getStatus across 23 files.” It felt fast. It felt done. ...

The moment subagents clicked for me was during a code review I’d already once let through. A colleague had sent through a PR touching one of our JMS message handlers — a service that processes incoming payment-status webhooks from a downstream provider, updates the corresponding ticket, and acknowledges the message back to the broker. Two hundred lines, four external touch-points, and one atomic-looking flow that was actually anything but. The initial review from a single Claude Code thread came back the way these things often do: “The handler looks well-structured. Consider extracting the parsing into a helper class. Log messages could be more descriptive.” Fair points. Also, not the kind of review that catches anything you’d be embarrassed by in production. ...

It took me three months of using Claude Code before I finally installed a hook. It took me about ten minutes after that to wonder why I’d waited so long. The problem was banal. I’d been running Claude Code alongside a Spring Boot project at work, and after a longer refactoring session — twenty-something files touched, an interface renamed, a couple of implementations moved to a new package — I committed and pushed. Everything compiled. Tests passed. Life was good until Jenkins came back thirty seconds later with a red X: spotless:check had failed on eight files. Claude had used its own idea of import ordering, and our project uses a stricter one. ...

There’s a specific moment when a Claude Code setup crosses over from “collection of tricks” to “environment I actually trust.” For me it was a morning at work a few weeks after I’d finished the last big round of .claude/ cleanup. I opened a session on a service I’d been fighting a bug in the day before, typed one sentence about the bug, and Claude Code — before I did anything else — knew what branch I was on, what other work was in progress, what JIRA ticket the bug was tracked in, what the team’s transactional conventions were, and which of the four review subagents I’d want to run before committing. I didn’t have to explain any of that. The setup did. ...