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.
In the first part of this series, I described the most important lesson I learned while building a local AI storyteller:
A good LLM application is not a clever prompt. It is software architecture around a probabilistic component.
That sounds reassuringly architectural.
It also leaves one small question:
What exactly are we building around?
As software engineers, we are constantly challenged to explain what we do and how we do it. This communication challenge becomes even more pronounced when we talk to non-technical stakeholders. Now that AI is enabling us to produce more than ever before, this problem has become even greater. But how do we effectively convey complex technical concepts to a non-technical audience?
It was two o’clock in the morning before I noticed the time.
Earlier that evening I had been building an application.
I had written all the work in a backlog.md, a neat list of stories, and I let the AI pick them up one by one.
It would finish a story, ask me to verify everything, and then close with a simple question: shall I pick up the next task?
And every single time, that question was the trigger. It would be a shame to stop now. Just this one more, and then I’ll go to bed.
