Andreas Olsson’s Post

MCP (Model Context Protocol) for AI integrations... Let's speak about MCP Client and MCP Server. First, what is MCP? MCP is a protocol that standardizes how applications provide structured context to AI models. Instead of sending raw prompts, you send organized, meaningful data. Now, the key roles: - MCP Client This is your Java application. It is responsible for: - Collecting context (user data, system state, external APIs) - Structuring that data using DTOs - Sending requests to the MCP Server - Handling responses Think of it as the context builder and request orchestrator. - MCP Server This sits between your application and the AI model. It is responsible for: - Receiving structured context - Enriching and validating data - Communicating with the AI model - Returning structured responses Think of it as the AI gateway. A simple mental model: Client = builds and sends context Server = processes context and talks to AI Now... how do you actually implement this in Java? Here is a practical approach: - Start with a clean architecture Separate: - Context providers - MCP client layer - AI integration Avoid mixing everything into one service. - Create a Context Layer Aggregate: - User data - System state - External APIs This becomes your Context Aggregator. - Use strong typing (DTOs) Avoid raw strings. Structured data = better consistency and debugging. - Build an MCP Client Service Responsible for: - Formatting requests - Injecting context - Handling retries and errors You can use: - Spring Boot WebClient - OkHttp - Keep prompts minimal, context rich MCP is not about better prompts. It is about better context. - Add observability from day 1 Log: - Context sent - Model responses - Latency Without this, debugging AI becomes guesswork. - Think about scalability - Cache reusable context - Use async processing - Avoid rebuilding the same data If you skip the Client vs Server separation your system quickly becomes hard to scale, test, and evolve. #Java #AI #MCP #SoftwareArchitecture #BackendDevelopment #SpringBoot #CleanCode #Microservices #APIDesign #ScalableSystems #TechLeadership #CloudNative #DeveloperExperience #Engineering

Three years ago I helped do something most people said was impossible. 10 million lines of Java. National Grid's gas management system. Zero tolerance for downtime. Conventional tools couldn't analyse it without years of manual effort. So I architected a proof of concept to prove the approach was viable, then found a commercial partner (vFunction) to scale it. Full codebase analysis: 10 days. Decomposed into 27 microservices. Fully tested and live on Azure: 6 months. The lesson I took from it: Utilising AI is an architectural problem before it's a tooling problem. The hard work is understanding the system well enough to know where AI fails, then designing around those gaps. I've been applying that same thinking ever since. Most recently, I built AuthBuild (authbuild.com), a SaaS platform I shipped solo using Claude Code, Base44, and a Flask/Appwrite backend. The tooling has changed. The principle hasn't. Case study: https://lnkd.in/e7d94396

Lately I’ve been working on something a bit different than regular REST APIs — building MCP-based APIs using Spring Boot. At first, I thought this would just be another API layer. It’s not. When you start integrating backend systems with LLMs, you realize pretty quickly that REST APIs weren’t really designed for that use case. They work great for structured, predictable systems, but AI interactions are more dynamic and context-driven. That’s where MCP started making sense to me. Instead of exposing endpoints just for developers, you expose “tools” that an AI can understand and use reliably. It creates a cleaner boundary between your backend logic and the AI layer. A few things I noticed while working on this: You don’t have to tightly couple your business logic with prompts anymore Error handling and responses need to be more structured (AI-friendly, not just human-friendly) Context becomes a first-class citizen, not something you hack around On the implementation side, I used Spring Boot to: Build MCP-style APIs using tool-based abstractions Standardize exception handling so responses are predictable Design request/response models that work well with LLMs Deploy everything in a scalable setup (Kubernetes) Big takeaway for me: We’ve been building APIs for systems to talk to systems. Now we need to build APIs for systems to talk to AI. Still early in this space, but it definitely feels like a shift worth paying attention to. Curious if others are experimenting with MCP or similar patterns. #ArtificialIntelligence #GenerativeAI #AIEngineering #SpringBoot #Java #Microservices #SystemDesign #BackendArchitecture

🏗️ Spring AI 2.0 or LangChain4j? The Java LLM decision that will define your architecture for years.   Spring AI 2.0 (Milestone 3 — March 2026) is no longer just an integration library. Built on Spring Boot 4, it's become a full AI application platform — and one architectural detail changes everything: MCP (Model Context Protocol) is now first-class.   Your Spring Boot app can now simultaneously act as an MCP client (consuming external AI tools) and as an MCP server (exposing your own business logic as standardized tools). That means plugging into any A2A (Agent-to-Agent) orchestration fabric with zero custom glue code.   On the other side, LangChain4j 1.0 (now at 1.10.x) made a different bet: framework-agnostic, modular, and deliberately unopinionated. It works just as well with Quarkus, Micronaut, or plain Java.   My take as an architect — the decision comes down to two questions: → Are you all-in on the Spring ecosystem? Spring AI 2.0 wins on DX, observability, and native MCP/A2A support. → Do you need portability across runtimes or a greenfield microservice? LangChain4j gives you less magic and more control.   What you should NOT do in 2026 is direct API calls to LLMs without an abstraction layer. Model churn is real — GPT-5.5 just dropped yesterday.   Which path are you taking in your Java AI projects? 👇 Source(s): https://lnkd.in/duAnQJCz | https://lnkd.in/dsR9CYSW | https://lnkd.in/dvZ7qwza   #Java #SpringBoot #SpringAI #LangChain4j #LLM #AIArchitecture #SoftwareEngineering #MCP #BackendDev

🧠 Learning and exploring #AIwithJava using #SpringAI through hands-on projects - moving from simple GenAI APIs to building real-world Autonomous AI Agents that think, plan, and use tools. As a hands-on example, I built J-Agents, evolving from a basic GenAI API to a full agentic system using #SpringAI + local #LLMs (Ollama - Phi3/Llama3). 💡 Why #Java? Because the Java+Spring ecosystem provides a strong foundation for enterprise AI systems - with Spring Boot, Spring AI, and rich supporting libraries that make it easy to integrate LLMs, build scalable services, and design production-ready agent architectures with security, observability, and reliability. 👉 🔗 https://lnkd.in/gN3PBAWT Now exploring further to MCP, LLMs, RAG with vector databases, and MLOps. #Java #SpringAI #SpringBoot #AIAgents #AgenticAI #LLM #RAG #MCP #MLOps #GenerativeAI #Ollama #LearningJourney

API versioning used to be an implementation problem. Now it’s an architecture problem. With tools like IBM Bob, you can generate versioned APIs in Quarkus in seconds. Path versioning, headers, media types — all done automatically. But here’s the catch: if your strategy is wrong, you just created technical debt faster than ever. I broke down the 3 approaches and when they actually make sense 👇 https://lnkd.in/dUs8iMb4 #Java #Quarkus #SoftwareArchitecture #API #BackendDevelopment #AI

Imagine transforming a raw PDF requirements document into fully reviewed, tested, and deployed Java code without a single byte of data ever leaving your machine. 🔒 Meet CodeForgeAI: a 5-agent multi-LLM pipeline built with Spring Boot 4.0.x and Spring AI 2.0.0-M3 that runs 100% on-premise. In an era where cloud-hosted AI tools raise massive red flags for enterprise security, we wanted to see if a developer laptop could handle the entire lifecycle—from requirements to Jira stories to production-quality code—using only local, open-weight models via Ollama. The "Team" Under the Hood: We didn't just build a script; we orchestrated a specialized workforce of 5 AI agents: - Business Analyst: Turns PDFs into structured user stories. - Code Generator: Drafts the implementation. - Code Reviewer: Performs a two-layer (deterministic + LLM) quality check. - Test Generator: Writes JUnit 5 tests. - Test Executor: Compiles and runs everything via Maven. The Real-World Struggles Running multiple LLMs locally on an Intel Core Ultra 7 (CPU-only!) wasn't easy. We hit major roadblocks that most "Hello World" AI tutorials ignore: The Context Window Wall: How do you pass a full codebase to a 7B model without blowing past 16k tokens? We solved this with a "Signatures-Index" trick. The Reload Lag: Why was every agent-to-agent handoff losing 30 seconds? It turns out uniforming num_ctx was the secret breakthrough. Truncated Output: What happens when your LLM stops mid-method? We built auto-repair logic to count braces and close the deficit. Why This Matters We’ve documented the entire architecture, from the PGVector RAG implementation to the real-time Vaadin UI with server push. Whether you are looking to secure your proprietary codebase or just want to see how far local LLMs can be pushed, there is a wealth of "hard-learned" lessons in this project. Ready to see the full tech stack and the "breakthrough" configurations that made it work? Check out the deep dive on the blog and the full source code on GitHub. 👇 https://lnkd.in/gN-mGDk6 #Java #SpringAI #LocalLLM #GenerativeAI #SoftwareEngineering #DataPrivacy #SpringBoot #Ollama

𝗧𝗵𝗲 𝗵𝗼𝘁𝘁𝗲𝘀𝘁 𝘀𝗸𝗶𝗹𝗹 𝗶𝗻 𝘁𝗵𝗲 𝟮𝟬𝟮𝟲 𝗝𝗮𝘃𝗮 𝗠𝗮𝗿𝗸𝗲𝘁? 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝘂𝘀𝗶𝗻𝗴 𝗦𝗽𝗿𝗶𝗻𝗴 𝗔𝗜 𝘊𝘰𝘮𝘱𝘢𝘯𝘪𝘦𝘴 𝘥𝘰𝘯'𝘵 𝘫𝘶𝘴𝘵 𝘸𝘢𝘯𝘵 𝘈𝘐 𝘵𝘩𝘢𝘵 𝘵𝘢𝘭𝘬𝘴; 𝘵𝘩𝘦𝘺 𝘸𝘢𝘯𝘵 𝘈𝘐 𝘵𝘩𝘢𝘵 𝘋𝘖𝘌𝘚. I've just released Part 6B of my series on Enterprise GenAI. We're moving beyond text responses and into the world of 𝗦𝗽𝗿𝗶𝗻𝗴 𝗔𝗜 + 𝗠𝗖𝗣 (𝗠𝗼𝗱𝗲𝗹 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗣𝗿𝗼𝘁𝗼𝗰𝗼𝗹). This is the standard that allows LLMs to securely reach into your private databases, call your APIs, and execute transactions without custom "integration sprawl." For Java and Spring Boot developers, mastering the Action Layer is the most lucrative transition you can make right now. Don't just be an engineer; be an 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿. Check out the architecture and code here: https://lnkd.in/geJ5dcph #Java #SpringBoot #SpringFramework #SpringAI #JavaDeveloper #GenerativeAI #GenAI #ArtificialIntelligence #LLMs #TechTrends #AI #DataScience #Cloud #AWS #SoftwareDevelopment

Your system processes orders using a queue: → API receives request → Pushes event to queue → Worker processes it ⸻ Everything seems fine. Until production shows: • Some orders processed twice • Some orders never processed ⸻ What’s going on? Your queue guarantees at-least-once delivery. Which means: 👉 Messages can be delivered more than once 👉 But never guaranteed exactly once ⸻ So how do you fix it? ✔ Idempotency key Each order gets a unique ID → Store processed IDs → Ignore duplicates safely ✔ Atomic processing Use DB transaction or upsert → Ensure “process once” behavior ✔ Retries with DLQ Failed messages go to Dead Letter Queue → No silent drops ✔ Acknowledgement discipline Only ACK after successful processing → Prevent message loss ⸻ Can we achieve exactly-once? Not really (in most practical systems). What we actually build is: 👉 At-least-once delivery + idempotent consumers ⸻ Takeaway: Duplicates are not a bug in distributed systems. They are a guarantee. Your system should be designed to handle them. #distributedsystem #backend #java #learninpublic #SoftwareEngineering #AI #CareerGrowth #BuildInPublic #TechLeadership

How I 10x'd My Spring Boot Development Speed with Claude Code I recently built a large-scale Spring Boot API service—dozens of CRUD endpoints with consistent business logic across multiple modules. Instead of writing boilerplate manually, I turned Claude Code into my pair programmer. Here's the system that worked: The Strategy: Structured Context > Wall of Text Rather than dumping everything into a single prompt, I created a modular agent_instructions/ folder with surgical precision: agent_instructions/ ├── developer.md # Global standards (layering, naming, patterns) └── modules/ ├── module1/ │ ├── service_logic.md # Business rules & edge cases │ ├── api_spec.md # Endpoints, methods, responses │ ├── dtos.txt # Request/Response models │ └── schema.sql # Table structures └── module2/ └── ... Why This Works: > Separation of Concerns – Each file serves a single purpose. The agent doesn't confuse database schema with API contracts. Incremental Development – I tackled one module at a time. This kept code quality high and prevented context overload. > Consistency by Design – The developer.md file enforced patterns across the entire codebase (Controller → Service → Repository structure, DTO validations, exception handling, Liquibase migrations). > Scalability – Adding a new module? Just drop in 4 files and let Claude Code generate the skeleton. The Results: ✅ Uniform code structure across 20+ controllers ✅ Near-zero manual errors in boilerplate ✅ Development time reduced from weeks to days ✅ Maintainable, readable code that passes review on the first pass Key Takeaway: AI agents perform best with structured, modular context—not massive prompts. Treat your instructions like a well-architected codebase: layered, cohesive, and purpose-driven. If you're curious about the exact standards I used, I've open-sourced the developer.md template: 👉 https://lnkd.in/gx9QsaC9 Have you experimented with AI-assisted development? What patterns worked (or didn't) for you? #SpringBoot #ClaudeCode #AIPairProgramming #DeveloperProductivity