Profil
Software-Architekt & Engineer in Berlin. Hier steht, wie ich arbeite, woran ich gerade baue und wofür du mich als Trainer und Architekt buchen kannst.
Ich komme aus der Entwicklung und arbeite als Architekt am liebsten dort, wo mehrere Systeme, Teams und Schnittstellen zusammenkommen. Mich reizt dabei nicht die größte Architektur, sondern die einfachste, die das Problem noch trägt. Heute entwickle ich eigene Produkte und unterstütze Teams mit Architekturarbeit, Coaching und Workshops.
Vom Fachproblem zum Produkt#
Architektur und technische Tiefe bleiben mein Handwerk. Ich fange aber früher an, bei der Fachdomäne: Was soll das Produkt für wen leisten, und welcher erste Schritt lässt sich liefern und betreiben?
Produkt in kleinen Schritten
Ich entwickle Produkt und Architektur zusammen mit dem Team, in kleinen Schritten, die sich jeweils ausliefern lassen. Nach jedem Schritt gibt es Rückmeldung, bevor wir den nächsten planen. Ein großer Zielentwurf am Anfang ist mir weniger wichtig als ein System, das mitwachsen kann.
Fachdomäne und DDD
Am Anfang steht die Sprache der Fachleute mit ihren Begriffen, Regeln und Zuständigkeiten. Mit Domain-Driven Design mache ich daraus Modelle, APIs und Events, in denen man diese Regeln im Code wiederfindet.
Wissen ordnen
Ich ordne Quellen, Aussagen und ihre Versionen so, dass man nachschlagen kann, woher eine Aussage stammt und ob sie noch gilt. Das brauchen Menschen in der Dokumentation genauso wie Agenten, die mit dem Wissen einer Firma arbeiten.
Darstellen und erklären
Bevor ich eine Seite, einen Report oder ein Diagramm baue, kläre ich, welche Frage es beantworten soll. Dann bringe ich Aussagen und Belege in eine Reihenfolge, der man folgen kann. Erst danach wähle ich die Form.
Wie ich denke und umsetze#
Gute Systeme entstehen selten am Reißbrett. Ich taste mich in kurzen Schleifen heran, schreibe Tests, bevor ich mir sicher bin, und werfe Code weg, sobald ich etwas Besseres verstanden habe. Über die Jahre habe ich viele Technologien kommen und gehen sehen. Länger gehalten haben die Systeme mit klaren Schnitten und guten Namen.
Zuhause bin ich in ereignisgetriebenen Architekturen mit CQRS, Event Sourcing und Domain-Driven Design, meist mit Node.js und TypeScript, GraphQL und React oder SvelteKit auf AWS. Wichtig ist mir, dass die fachliche Absicht im Code sichtbar bleibt, durch klare Domänengrenzen und aussagekräftige Typen.
Agentic Engineering#
Seit Ende 2025 arbeite ich täglich mit Coding-Agents. Agentic Coding heißt, dass ein Agent Code liest, ändert und testet. Agentic Engineering ist das System darum: Es sorgt dafür, dass die Ergebnisse auch im Betrieb tragen. Erzeugen wird billig, Prüfen wird der Engpass, und genau dort setze ich an.
Harness und Kontext
Tools, Kontext und ausführbare Prüfungen machen aus einer Aufgabe einen reviewbaren Branch. Das Modell ist dabei selten der Engpass, der Harness macht den Unterschied.
Regeln, die gelten
Instruktionsdateien bleiben Empfehlungen. Was verbindlich sein muss, setze ich im Pfad durch: mit Prüfung vor der Wirkung, Freigabe und Nachweis.
Grounding und Wissen
Antworten stehen auf echten Quellen oder sagen, dass nichts dasteht. Was ein Team dabei lernt, pflegt es wie Code: mit Herkunft, Versionen und Besitzern.
Agenten und Schnittstellen
Ich schneide Agenten entlang der Fachdomäne und verbinde sie über MCP, HTTP, Webhooks und A2A.
Nichts davon ist eine KI-Erfindung. Domain-Driven Design, Freigaben, Versionierung und Audit tragen seit Jahrzehnten, neu ist nur, dass ein Modell in der Schleife handelt. Wie ich dorthin gekommen bin, steht in der Serie Von der Session zum System. Alle Beiträge findest du unter dem Thema KI.
Woran ich gerade arbeite#
Entscheidend ist nicht, dass ein Modell eine Antwort erzeugt. Entscheidend ist, ob ihre Herkunft sichtbar bleibt und ein Mensch sie prüfen kann. Daran arbeite ich in SubKit: Die KI entwirft einen Workflow, ein Mensch prüft ihn und gibt ihn frei, und beim Ausführen entscheidet die KI nichts.
Daneben baue ich zwei Apps. Harmoniqs ist eine App fürs Songwriting auf Mac, iPhone und iPad. TackTics ist ein Segeltrainer und noch in Arbeit: Die App soll NMEA-Daten, Wetter und frühere Fahrten zusammenführen, um Trimm und Manöver nachvollziehbar auszuwerten. Mehr dazu unter Projekte.
Woran man mich messen kann#
Open Source, in echter Nutzung#
Mein Adapter sveltekit-adapter-aws bringt SvelteKit serverless auf AWS — inzwischen läuft er bei anderen in Produktion.
Schreiben seit 2014#
Im Blog schreibe ich über das Handwerk, von Katas über GraphQL und reaktive Architekturen bis zu Delivery, Teamarbeit und Produktdenken. Seit Ende 2025 kommt KI dazu. Erklären zwingt zur Klarheit; das schärft auch den eigenen Code.
Weitergeben#
Seit 2014 schule ich Teams in Architektur, GraphQL, Node.js und Domain-Driven Design, am liebsten an ihren eigenen Aufgaben. Heute gibt es das als Workshops, online, remote oder vor Ort. Die Einführungen zum Mitmachen zu GraphQL, Node.js, React und weiteren Themen sind frei verfügbar.
Abseits vom Bildschirm#
Wenn ich nicht am Code sitze, zieht es mich in die Alpen, auf dem Rennrad, an der Wand oder auf Skitour. Musik gehört genauso dazu: Gitarre und Klavier. Und im Sommer segle ich am liebsten mit meiner Seascape 24 SE auf Havel und Wannsee.
Kontakt#
Schreib mir, wenn du ein Architekturthema besprechen oder einen Workshop für dein Team anfragen möchtest: mike.bild@gmail.com. Ich sitze in Berlin.
Publikationen und Vorträge#
Fachartikel und Vorträge seit 2010, von Coding Dojos bis Serverless, habe ich unter Publikationen und Vorträge gesammelt.