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: ...
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. ...
A few years ago, a colleague of mine was convinced that a memory leak had crept into one of our microservices. The heap was consistently at 70% after startup — before a single request had been processed. We profiled it, combed through the GC logs, and eventually concluded that no, nothing was leaking. It was just object overhead. Lots of small objects, each carrying its overhead around like a briefcase it didn’t need. ...
In the last article, BrightCart got its first real feature: an endpoint that summarizes support tickets. The system prompt that powered it was a triple-quoted string sitting in a @Bean method. It worked, it was readable, and for one prompt it was completely fine. But I’ve been writing Spring AI applications long enough to know what happens next. One prompt becomes three. Three become a dozen. Someone wants the summary to mention the customer’s loyalty tier. Someone else wants a different prompt for priority tickets. Before long you’ve got string concatenation scattered across five service classes, nobody remembers which prompt is the good one, and changing the wording means a recompile and a redeploy. ...