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. ...
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. ...
If you’ve been following the evolution of Project Loom, you’ll know that Structured Concurrency has been on quite a journey. It started as an incubator module in JDK 19, became a preview API in JDK 21, and has now re-previewed five more times since — JDK 22, 23, 24, 25, and 26. JEP 533 is the seventh preview, targeting JDK 27, and this time the changes are meaningful enough that it’s worth taking a proper look. ...
Somewhere in articles 1 and 2, I kept writing this line and asking you to take it on faith: java chatClient.prompt().user(question).call().content(); It works. It reads nicely. And if you’re anything like me, the fact that it works without you understanding why has been quietly bothering you since article 1. Today we fix that. This article takes ChatClient apart — every method in that chain, every configuration option that matters, and the parts of the API we haven’t even touched yet. By the end, the fluent API won’t be a magic incantation anymore. It’ll just be… an API. A well-designed one, but still. ...
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. ...
Same Feature, Fifth Time Around If you read my JEP 530 post at the tail end of the Java 26 series, this one is going to feel familiar. Very familiar. JEP 532 is the fifth preview of “Primitive Types in Patterns, instanceof, and switch”, now targeting JDK 27. And here’s the honest headline: nothing has changed. No new syntax, no removed methods, no behavioural tweaks. The JDK team looked at JEP 530, decided it was in good shape, and re-proposed it as-is to bake for another release cycle. ...
Intro In the previous article, we ran a Spring AI application in about twenty lines of Java. It worked. A ChatClient appeared out of nowhere, we called .prompt().user(...).call().content(), and Claude answered. That’s the magic of Spring Boot autoconfiguration — and also the danger of it. When things work without explanation, you’re fine right up until you need to debug something, customise something, or explain to a colleague what exactly is happening. Then you’re stuck. I’ve been there more times than I care to admit — staring at a NoSuchBeanDefinitionException at 4pm on a Friday, completely unable to explain why a bean that “should just be there” isn’t. (It was a missing property. It’s always a missing property.) ...
I still remember the moment it clicked — and the much longer stretch before it did. I’d been building Spring Boot applications for years. I knew the ecosystem. I knew how to wire beans, configure starters, and navigate the autoconfiguration magic without panicking. Then I started exploring Spring AI, and suddenly I was lost again. Embeddings. Vector stores. RAG pipelines. Advisors. ChatClient vs ChatModel. A wall of new terminology that felt completely disconnected from everything I already knew. ...