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