As a consultant I am part of a lot of different Java projects. Some of these project use Lombok. When you use a Lombok annotation code gets generated when the code is compiled. This code is not visible in the IntelliJ IDEA editor which could be a problem when you want to debug your application and need to add a breakpoint for the generated code. Suppose you have a Java class with a simple constructor without using Lombok annotations. You can place a breakpoint in the constructor and when you debug the application in IntelliJ IDEA the execution stops at the breakpoint. Now you can check for example the values of parameters that are passed into the constructor call. But when you use a Lombok annotation like @RequiredArgsConstructor the code for the constructor is generated and not visible in your editor. If you want to check the values of parameters passed into the constructor you need to set a breakpoint at the line that has the @RequiredArgsConstructor statement. When you debug your application IntelliJ IDEA will stop execution when the constructor is invoked and you can check values of parameters.

If you work with Azure Durable Functions, you likely use the Fan-Out / Fan-In pattern to process data in parallel. In practice, trusting default queue scaling in production often triggers HTTP 429 (Too Many Requests) storms, connection pool exhaustion, and downstream outages.

It’s finally mature: a framework to define nullability in Java. There have been so many attempts, but JSpecify is here to stay. Now that this has been addressed, another challenge comes to mind: How can we eliminate the boilerplate of handling incoming null arguments?

Our colleague Jacob shed a light on working with AI in a post he wrote back in June, Contemplations. One of his points was that, with AI being more and more ubiquitous in our work as software developers, sophisticated programming concepts are starting to become irrelevant. The AI doesn’t care how elegant the code is, it spits out something that works. In the end that’s what matters to the business; it just works.

I learned about Rich Sutton’s "Bitter Lesson" recently, and I can’t help but draw parallels between the work on the cutting edge he describes and our daily work using AI as software engineers.

Over the past few weeks, I’ve been on a rewarding journey. As a Managing Director who is no longer a full-time software developer, finding the time to code and keep up with the relentless pace of new technologies is a real challenge. While my colleagues are experimenting with the latest frameworks and tools daily, I know I’m not alone in feeling that the tech landscape evolves faster than the hours in a day allow — or faster than what client projects typically permit you to explore.

That’s why I cherish internal projects. Earlier this year I posted about Posting our blog feed to social networks using Slack. And recently I set out to build a couple of internal tools for our Google Workspace environments, but I decided to try something different than what maybe most developers would do.

Instead of relying solely on traditional documentation or enabling an autopilot AI assistant directly inside my IDE or terminal (like a Claude Code subscription), I used the standard Google Gemini web client. It comes included with our company’s Google Workspace account — proving that you don’t need expensive premium subscriptions or complex local LLMs to get value.

In Nushell almost everything is a data structure. This mind set is also applied to XML structures in Nushell. A XML tag can be described as a record with the attributes tag, attributes and content. The tag attribute has a string value that is the tag name. Attributes are defined with a record structure. The key is the attribute name and the value is the attribute value. Finally the content attribute is a list containing a string value for text content or new record structures for nested XML tags. With this basic record structure you can describe XML content. To actually transform it to a XML string value you can use the command to xml. This command will use the data in the record structure and will output XML.

If you have read my blogs before, you probably know about my passion for sports, and for Michael Jordan in particular. But there is a second passion I rarely write about, and that is music. Not just any music, but the kind that truly makes an impact, at least on me. And the more I think about it, the more I suspect these two passions are not so far apart after all.

In our projects we have been using ArchUnit for years to write unit tests that fail when the code no longer follows the architecture we chose. Over the last year, we’ve written more and more of these tests. What changed? Our audience grew. These tests no longer just help fellow developers stick to the architecture; they help our coding agents too.

Coding agents are getting quite good at making larger changes to existing codebases. Give an agent a task, some context and a test suite, and it often finds its way surprisingly well. But one type of context is much harder to provide: the architecture we intended. That is exactly the gap ArchUnit fills.

In this blog post I explain why ArchUnit becomes more valuable when working with coding agents, and I show some rules that actually help to guide them. The list is far from complete, but I hope it inspires you to capture your own architecture in rules, whether you write them yourself or let your agent do it.

Long story short: I’ve switched to using Actalis ^[1], the Italian Certification Authority and eIDAS ^[2]-qualified Trust Service Provider owned by the Aruba Group.

In the first part of this series, I described the most important lesson I learned while building a local AI storyteller:

That sounds reassuringly architectural.

It also leaves one small question:

What exactly are we building around?