I held the first iteration of this talk in July 2025 at the very first Agentic Coding Meetup in Hamburg.

Why robot vacuums with laser swords?

My TLDR back then was to focus on the result of your agent and not too much on the ways he takes to get to that result.

I think that aged well!

Don't worry: This is a completely new presentation!

If you're wondering what TreeOS is about: It's about running AI-powered apps and skills in a safe environment locally without any dependence to cloud computing. Accessible from anywhere via Tailscale.

In the beginning there was the pflichtenheft

you can feel how it sucks out all the energy of the room.

Brings me back to University in 2005.

All projects in my first years on iOS were all fixed price and fixed scope.

I only started agile programming in 2011 when I joined XING, it was a completely new world for me.

short feedback cycles, regular checkins, retros, a lot of honesty about hidden complexity

all in all a very humane work environment, but also a lot of chaos and exploitation.

Another way of putting it: 2024 vs 2026

There is no point in starting slowly. Going to 100% code written by the agents is the path that makes most sense.

You task is to create the environment where that is possible!

Agents are worth the effort!

Humans have feelings about their code, Agents don't.

This is a huge advantage in working with them.

Go for absolute suicide missions, or let multiple agents compete.

I say this as ex team lead, full of respect for my former team members. Balancing all the different needs in a team is a lot of work, that is not very rewarding.

Software Development means chartering through unknown territory. Avoid too predefined paths.

Spec'ing everything at the beginning does not work.

A good working software product consists of 100s of prototypes

The tools are catching up to this quite well, with save points.

XNGDataFetcher example from XING. Every new employee learned in the first few weeks that this thing is ugly and not convenient to use. But that it’s a very central class. If you think about software and hardware, (black and white) , but that’s not the whole truth. There’s a whole spectrum of gray colors in software, even in your project.

Another Word For this is Tribal Knowledge.

It's hard to be that transparent!

Liquid Engineering is not about everything being liquid all the time, just the right parts.

Think about your spec like your very high level test suite. How can the agent self -check that their solution is correct?