Posts

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. ...

I checked in on the Vector API the way you check in on a home renovation that’s been “almost done” for years. You poke your head in, nothing’s changed, and someone tells you it’s waiting on one more delivery. Except this delivery has been “arriving soon” since 2014. That’s JEP 537. Twelfth incubation round. Let’s talk about what it actually does, and why it’s still sitting in the waiting room. ...

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. ...

Somewhere in one of my customers repo there’s a private method that parses -----BEGIN PRIVATE KEY----- blocks by hand: strip the header, strip the footer, Base64-decode what’s left, hand the bytes to a KeyFactory, hope you picked the right algorithm. I wrote something almost exactly like it years ago. It wasn’t hard. It was just the kind of tedious that makes you wonder why the JDK never gave you this for free. ...

At the end of article 6, something slightly magical happened and I asked you to just accept it. The model requested a tool call, and Spring AI executed the method and fed the result back — looping until the model was satisfied — without us writing a single line of orchestration. I called it “Spring’s tool-calling machinery” and moved on. Time to name that machinery. It was an advisor. Specifically a built-in one called ToolCallAdvisor, sitting quietly in the request pipeline, running the whole tool loop on our behalf. ...

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. ...

At the end of the last article, BrightCart’s classifier did something impressive and something useless, at the same time. Impressive: it read a chaotic customer rant and pulled out orderNumber: "BC-48291" as a clean, typed field. Useless: it had absolutely no idea whether order BC-48291 exists, what’s in it, or where it is. It extracted that order number the same way it would extract BC-99999 or BC-BANANA — by pattern-matching text. The model was working entirely from the customer’s words, and customers, as we’ve established, are not a reliable source of truth. ...

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. ...

A few years back, someone on my team attached a .jfr file to a vendor support ticket. Nothing unusual — Flight Recorder is the go-to tool when you need to show “here’s what the JVM was actually doing.” Except that recording also happily included the database password we’d passed in as a -D system property on startup. Nobody noticed until the ticket had already left the building. That’s the problem JEP 536 fixes. It’s not glamorous. It won’t make a conference keynote slide. But if you’ve ever shipped a JFR recording to a vendor, uploaded one to a shared bucket, or attached one to a bug report, you’ve probably leaked something you didn’t mean to. ...

Let me show you the exact moment a Spring AI demo turns into a Spring AI application. In the last two articles, BrightCart’s summarizer happily returned prose, and prose was the right answer — a human support agent reads it. But the moment I tried to make the system do something with a model’s answer, I hit a wall. I wanted to classify tickets so they could be routed automatically: delivery problems to the logistics team, billing issues to finance, and so on. So I asked the model to classify a ticket, and it cheerfully replied: ...