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?

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.

I wanted to understand what happens when you stop treating an LLM as a chatbot and start treating it as a component in a software system.

So I built a local AI storyteller using a local LLM through an OpenAI-compatible API.