Agenda

In this talk, we'll build a CLI from scratch in Go, engineering it for dual consumption. We’ll cover why Go is an ideal language for building command line tools and how simple architectural tweaks can transform a standard terminal utility into an agent-friendly execution engine.

What you'll learn:

- How to automatically switch between human UI (colors, spinners) and machine output (JSON/NDJSON) using TTY checks.

- Techniques for stream separation (stdout vs. stderr) and token-efficient output filtering.

- How to structure CLI errors so AI agents can self-correct and retry autonomously.

This talk is about what happens when none of that is available - no internet, no cloud infrastructure, no external key management, no maintenance window. Just an operational requirement for real-time collaborative editing in an air-gapped defence environment.

Operational transformation algorithms were designed with certain network assumptions baked in. This talk covers what breaks when those assumptions don't hold, how to build a security model without external key infrastructure, and how to make deployment decisions when the target runtime is locked and non-negotiable.

Everything in this talk comes from a system that is running in production today and in an environment where failure is not an option.

Cover core patterns such as pub/sub, orchestrator, and supervisor for managing agent communication, memory, and workflow state. Discuss interoperability with MCP (Model Context Protocol) and how Java event streaming tools like Kafka, Pulsar, and Spring Messaging facilitate high throughput and reliability.

Are we becoming better engineers, or simply faster at producing software we don't fully understand? Through real-world examples, a bit of humor, and some uncomfortable questions, we'll explore the difference between writing code and engineering software, why fundamentals matter more than ever, and what it really means to be a software engineer in the age of AI. Because the future isn't just about how fast we can write code. It's about whether we understand what we're building.

In practice, Claude can join a TDD or BDD cycle. I have used it to draft specifications, write failing tests, make them pass, and refactor afterwards. The output is good enough that I keep coming back to it.

Today I can tell you that I ship faster and that I trust more of my tests. That has less to do with Claude than you might think. A coding assistant amplifies whatever habits you bring. Bad habits get worse. Good habits compound. Mine were already test-first.

I will show examples from real production code. You will see where Claude pulls its weight and where it does not. By the end you should know what AI pairing is worth in test-first work, and what habits you need before you start.

In this session, we’ll take a real-world inspired use case: a startup company helping friends split expenses using Open Banking APIs. Using strategic design techniques such as impact mapping and event storming we’ll uncover the core business concepts and translate them directly into code. Along the way, we’ll build a modular Spring Boot application structured around business domains rather than framework layers, with modules communicating through Kafka events. But distributed systems are rarely as straightforward as they seem. 

The highlight of the session will be a live coding challenge centred on a subtle yet common pitfall: extending a business transaction with an IO operation that can fail. Together, we'll examine the solutions developers typically reach for, explore their impact on customer experience, and uncover the trade-offs hidden beneath the surface.  

We'll wrap up with a deep dive into the Transactional Outbox Pattern and see how Spring Modulith helps enforce architectural boundaries, making event-driven systems more modular, reliable and easier to evolve. 

Many companies responded to this by either banning AI, buying a Data Loss Prevention (DLP) product, or signing an enterprise deal with an expensive vendor. However, bans get ignored, DLP doesn't understand prompts, and enterprise deals means you live with whatever models and rules that vendor locks you into.

At ArdanLabs we went a different direction and started building Kuzco. We believe this is a better approach to solving this and other related problems.

In this talk, I'll go over the Kuzco architecture, explain why the usual answers fall short, and what we're doing differently. Such as:

- Each user gets an isolated AI machine that only has the data and tools that user is allowed to access.
- All model and tool calls go through a single gateway, so you can control and report on every model interaction.
- Companies should have ownership of the source code and the ability to customize the platform for their data needs.