The Code is Clean. The Cache is Fresh. And Other Lies.

Two speakers! Sign up at https://www.javasig.com/#

Is Clean Architecture Still Relevant In The Age Of AI Coding Agents

More and more development organizations are relying on AI to create or even maintain big parts of their software systems. Proven by a recent Stanford study we know that the architectural quality of AI generated code is closely related to the structure of the code base it is working on. For greenfield projects the frontier models generate pretty decent code. But if they work on a big ball of mud, the output is not better than the input. Even worse, if an AI generated change causes a complex issue in a rotten code base, there is a good chance that only the human in the loop can fix it. This is obviously much harder if the code is hard to understand and difficult to read. So alone for this reason I would argue that architecture and clean code still matters, even more than before. And if that is true we need to figure out ways to guide LLM’s to always produce well structured and easy to understand code. For legacy code bases that means that we need to untangle them first before trying to implement major changes. This talk explains how an initial research session with Claude let to the implementation of a powerful MCP server that helps coding agents to do the right thing, even when the underlying code base is not ideal.

Catching Cache Caveats: When Your TTL Is Lying to You
We've all been there. Your Java application returns the wrong data, but nothing appears broken. No exceptions, no alerts, and every test passes. After hours of debugging, you finally find the culprit: a cache that's doing exactly what you told it to do. Months or even years ago, someone picked a Time to Live (TTL) value, and nobody questioned it since. Sound familiar? The problem gets worse when that same TTL applies to data that changes at different rates. Set it too short, and you're making unnecessary calls to external systems. Set it too long, and you're serving stale data. And when those external systems don't tell you when something has changed, your cache can quietly return incorrect results without anyone noticing.

In this session, we'll walk through a real caching system built on these assumptions, what went wrong, and what we learned trying to fix it. We'll explore the tradeoffs between data freshness, performance, and the cost of validating cached data against external systems you don't control. Should different attributes have different expiration times? What happens when checking whether data is still valid costs almost as much as fetching it again? And how can you detect stale data before your users do? We'll look at practical approaches, their limitations, and why cache correctness is often harder than it first appears.

If you've ever added a cache to speed up a Java application, or inherited one that nobody wants to touch, you'll leave this session with a few things worth reconsidering the next time you see a TTL in a configuration file.