I build the boring half
of the AI system.

I have been building software since 2009. I started as an apprentice, when the interesting problem was making a build reproducible, and I have not run out of interesting problems since.

Today I lead the Applied AI unit at nerdware GmbH in Nürnberg. That puts me on both sides of a project: the discovery call with a managing director who wants to know what this is worth, and the architecture review with the engineers who have to live with the answer.

I do not write much code by hand anymore, and I think that is the point. Most days I run agents and build what sits around them: the context they work from, the guardrails they stay inside, the quality gates that decide whether their output ships, and the platforms that keep the result maintainable rather than merely fast. The craft moved up a level. Whether a loop is a for or a forEach stopped being the interesting question; whether the result holds did not. It still shows up as commits, and I am usually the busiest committer on the platforms my unit builds. They are just not typed one line at a time.

What I actually care about is the distance between an AI demo and an AI system. Demos are cheap now. Getting one to survive an enterprise system landscape, a compliance review, and a Tuesday afternoon outage is still rare. So that is where the time goes: agent harnesses tuned to one specific codebase, evaluation setups that tell you whether a prompt change actually helped, and the gateways and guardrails that let a company use models without every team inventing its own.

Before the AI work I spent a decade on event-driven systems, AWS architecture, and enterprise integration. None of that stopped being relevant. If anything, it is the reason the agent work reaches production.

If you want the shape of the work rather than the opinions, that is on the work page.

How these posts are made

I do not write the posts on this blog by hand. They come out of a pipeline I built, which is the honest description and also the more interesting one. It reads my commits and working notes, picks a pattern that keeps recurring in the work, and drafts a case study around it. It publishes on a schedule, which is why there are more posts here than any person with a job could write.

What that means for reading them: the patterns are real. The forgotten cloud bill, the queue that swallowed twelve thousand emails, the test suite nobody trusted anymore. Those are things I have seen, usually more than once. The specific incident in a given post is constructed: the company, the numbers, the sequence of events. Nothing here is a report of something that happened to a client of mine, and no client material goes into the pipeline.

So treat a post as a case study rather than a war story. The engineering judgement is mine and I will defend it. The anecdote around it is scaffolding.