Wo Architekturentscheidungen auf Bühnen und in Fachmedien landen: Themen aus der Praxis, für Teams, die liefern müssen.
JavaLand · W-JAX · RabbitMQ Summit · code.talks · Golem.de
Konferenzvorträge zu Softwarearchitektur, Teamkomplexität und technischen Entscheidungen im Mittelstand.
KI-Assistenten sind nur so gut wie der Kontext, den sie bekommen. In diesem Talk zeige ich, wie Architekturdokumentation zum entscheidenden Hebel wird — für das Team und für KI-gestützte Entwicklung.
Dave Thomas und Andy Hunt haben mit "The Pragmatic Programmer" das Design moderner Programmiersprachen beeinflusst. Kotlin ist eine solche moderne Sprache, die die Robustheit der JVM mit modernen Paradigmen verbindet. In diesem Talk gebe ich Beispiele zum Thema Pragmatic Programming und stelle Ihnen dabei Kotlin vor.
In diesem unterhaltsamen Talk zeige ich anhand eines prominenten Beispiels, welche Auswirkungen unzureichende Performance haben kann. Anhand von 8 Lektionen zeige ich, welche Werte Sie vertreten müssen, um ein solches Disaster zu verhindern.
Was mache ich, wenn mein Produkt durch die Decke geht? Wie stelle ich mein Team für die Situation auf? In dieser Keynote schauen wir auf das "Performance Mindset".
Wie wendet man die Philosophie eines Pragmatic Programmers mit Kotlin an? Dieser Frage gehe ich im Oktober auf der KKON nach.
Im Spring Framework gibt es viele Features. Ich gebe praktische Tipps und Tricks, um die Lehren aus "The Pragmatic Programmer" mit Spring umzusetzen.
Spring NRW ist eine kölner User Group rund um die Entwicklung mit Spring. Ich präsentierte meinen Talk (k)lean JPA mit Updates aus dem letzten Jahr.
JPA hat viele Fallstricke. Diese müssen mit Kotlin neu betrachtet werden. Dieser Talk beleuchtet die Hintergründe und gibt Empfehlungen für den Umgang mit diesen.
Mit mehr als 1.600 Teilnehmern war die code.talks die größte deutsche Entwicklerkonferenz 2019. Über 400 erlebten live die Diskussion über robustes Software Design.
Fachartikel und Beiträge zu Softwarearchitektur, Systementwurf und technischer Führung.
Pragmatische Architekturdokumentation mit arc42, AsciiDoc und draw.io: Bewährte Methoden für nachhaltige Softwareentwicklung und effiziente Teamkommunikation.
Interview mit Atlassians Head of Product über Cloud-Bedenken, Tool-Komplexität und neue Features wie Focus und Compass.
Eine Softwarearchitektur für ein Projekt festzulegen, klingt nach einer Entscheidung für die Ewigkeit. Warum sie das nicht ist — und auch nicht sein sollte.
Viele mittelständische Unternehmen haben erkannt, dass Microservices für sie Overengineering sind. Was nun?
Kleine und mittlere Unternehmen wollen alles machen wie die Großen — und merken oft gar nicht, wie sie sich durch Overengineering schaden.
Anfangs setzen IT-Teams schnell neue Features um, dann wird die Entwicklungszeit meist länger. Accidental Complexity ist häufig die Ursache.
Gespräche über Architektur, Komplexität und die Fragen, die Teams wirklich beschäftigen.
Tomas Stiller spricht mit Marcus Held über den praktischen Einsatz von KI-Agenten in der Softwareentwicklung: das 8-Level-Modell der KI-Adoption, Context Engineering, die Veränderung von Junior- und Senior-Rollen und wie ein praxistauglicher Workflow mit AGENTS.md, Skills, Sub-Agenten und MCPs aussieht.
Tomas: Willkommen bei einer neuen Folge des airdys-Podcasts. Mein Name ist Tom, und wir geben euch nicht nur Orientierung im KI-Dschungel, sondern bauen auch ein tiefes Verständnis rund um KI auf. Wenn euch das Format gefällt, abonniert gerne den Kanal oder lasst uns einen Kommentar da. Auf unseren heutigen Gast freue ich mich besonders: Marcus Held ist Softwarearchitekt, Gründer und Geschäftsführer der Backendhance und freier Autor.
Marcus, hi! Erzähl uns doch kurz für alle, die dich noch nicht kennen, wer du bist und was du machst. Und als kleine Warm-Up-Frage dazu: Über welche Aufgabe freust du dich am meisten, dass du sie heute dank KI nicht mehr tun musst – oder worauf fieberst du hin, dass sie dir endlich abgenommen wird?
Marcus: Hi, freut mich auch sehr, dass ich dabei sein darf, und ich freue mich auf das Gespräch. Vielen Dank für die kurze Intro – ich erzähle gerne etwas über mich.
Wie du schon korrekt gesagt hast, bin ich freiberuflicher Softwarearchitekt. Ich habe mich darauf spezialisiert, mit dem deutschen Mittelstand zusammenzuarbeiten und dessen technische Anstrengungen in echten Wert zu verwandeln. Das mache ich durch das Alignment von Technologie, Prozess und Menschen. Ich fokussiere mich also nicht ausschließlich auf die Technik, sondern betrachte das Softwareprodukt als Ganzes und arbeite mit den Teams daran, dass sie die Werte schaffen, die das Unternehmen schaffen möchte – und entwickle dabei auch die Teams dort weiter, wo sie im Moment stehen.
Mein ganzheitlicher Ansatz richtet sich vor allem an Unternehmen, die im Mittelstand eine Nische besetzt haben und dort groß geworden sind, aber nicht in großen Strukturen arbeiten. Die typischen Kunden, mit denen ich zusammenarbeite, haben Entwicklungsteams von 20 bis maximal 50 Entwicklern. Dort werden besondere Anforderungen an die Strukturen und an die Technik gestellt, wie eine Software aufgestellt wird. Und in den letzten Jahren ist vermehrt das Thema KI und agentic Coding in den Fokus gerückt, wo ich Unternehmen jetzt auch dabei unterstütze, eine Strategie aufzubauen und sie umzusetzen.
Zu mir als Person noch ein bisschen Background: Ich entwickle Software seit ungefähr 15 Jahren. Ich habe eine relativ klassische Entwicklerlaufbahn hinter mir, habe als Backend-Entwickler gestartet und war viele Jahre in der Spielebranche in Hamburg unterwegs. Das größte Projekt hatte damals 220 Millionen registrierte User. Später bin ich wieder ins Rheinland gezogen, hatte ein paar Jahre die Abteilungsleitung bei einem Subunternehmen von Vodafone inne und habe ein Entwicklungsteam mit zu Höchstzeiten 30 Entwicklern geleitet. Vor etwas mehr als drei Jahren habe ich mich entschieden, mich selbstständig zu machen. Seitdem bin ich unter dem Markennamen Backendhance unterwegs.
Tomas: Und welche Aufgabe konntest du dank KI schon automatisieren – oder wünschst du dir?
Marcus: Ich habe über das letzte Jahr sehr viel umgesetzt. Was ich heute viel automatisiere, sind vor allem lästige Aufgaben für meine Selbstständigkeit. Beispielsweise das Produzieren von Content war immer schon zeitaufwendig. Da habe ich mir verschiedene Automatisierungen gebaut. Ein Beispiel: Für LinkedIn tippe ich die Beiträge nicht komplett selbst, sondern dafür habe ich KI-Agenten, die ich mit meinem Content befülle. Denen habe ich beigebracht, wie meine Markensprache ist und wie sie das Drumherum mitklären. Auch Angebotserstellungen, Arbeiten an meiner Webseite – das ist ein Riesenhelfer geworden. Wenn ich heute arbeite, habe ich eigentlich hauptsächlich OpenCode als Terminal auf meinem Hauptbildschirm, und darin mache ich alles.
Tomas: Wenn du beim Kunden bist – was ich oft höre, sind Widerstände gegen KI bezüglich Datenschutz oder manchmal auch bezüglich des Vertrauens. Hast du da auch oft Widerstände bei deinen Kunden?
Marcus: Du sprichst zwei wichtige Punkte an. In meinem Alltag erlebe ich, dass viele Kunden offen sind zu lernen und auszuprobieren, was mit KI-Agenten heute möglich ist. Datenschutzbedenken waren bei den Kunden, die ich in letzter Zeit betreut habe, glücklicherweise weniger ein Thema. In den meisten Modellen, die ich benutze, ist es möglich, das Training auf den Daten auszuschließen. Das ist eine Grundvoraussetzung und auch eine Garantie, die ich meinen Kunden gebe.
Den zweiten Punkt – dass KI-Agenten wenig Vertrauen genießen – das beobachte ich tatsächlich. Aber weniger bei meinen Auftraggebern direkt, sondern mehr in den Entwicklungsteams selbst. Ich habe im März einen Vortrag auf der JavaLand in Brühl gehalten – „Kontext ist alles". In diesem Vortrag hatte ich ungefähr 50 Leute im Raum. Am Anfang habe ich die Frage gestellt, auf welchem Level sich die Zuschauer in der KI-Adoption befinden. Es gibt da ein Modell, das Steve Yegge in seinem Blogpost „Welcome to Gravetown" beschrieben hat. Er beschreibt acht Adoptionslevel von Softwareentwicklern im Umgang mit AI.
Das Erstaunliche war: Als ich die Level durchgegangen bin, waren nach Level 2 und 3 schon die Hälfte aller Hände unten, und ab Level 6 – also mehrere KI-Agenten parallel händisch – war gar keine Hand mehr übrig. Das fand ich eine total spannende Erkenntnis. Die KI-Adoption in unserer Branche ist ziemlich niedrig, weil man das selbst noch nicht erlebt hat.
Tomas: Wie würdest du diese Parallelität beschreiben? Geht es darum, auf mehreren Repos zu arbeiten? Oder geht es darum, dass ein Agent schon QA macht auf dem Stand eines Entwickler-Agents, der bereits an der nächsten Aufgabe ist?
Marcus: Beides ist inkludiert. In meiner Praxis ist es so: Wenn ich an einem Projekt arbeite, habe ich immer mehrere Git Worktrees auf meinem Rechner, wobei jeder dieser Worktrees von genau einem Agenten bearbeitet wird. Es ist wie in einem Team: Da würde man auch schauen, dass die einzelnen Teammitglieder unabhängige Aufgaben bekommen und sich nicht gegenseitig blockieren. Man muss schauen, dass man den kompletten Entwickler-Loop hinbekommt – über die eigentliche Implementierung, das lokale Testen bis hin zum Deployment. Wenn das soweit möglich ist, kann man den KI-Agenten vollständige Aufgaben geben, und sie können selbstständig validieren, dass ihre Arbeitsergebnisse korrekt sind.
Tomas: Seniors werden mit agentic Coding stärker parallelisieren können. Dadurch werden Juniors aber nicht mehr so herangezüchtet. Wie siehst du die Entwicklung der Rollen Junior und Senior?
Marcus: Mit dem Hebel, den die KI-Agenten jetzt bieten, haben wir eine fundamentale Veränderung in der Art und Weise, wie wir als Entwickler arbeiten. Wir können aber Parallelen aus der Vergangenheit ziehen. Als Compiler eingeführt wurden, gab es sehr vergleichbare Bedenken wie heute. Später, mit Garbage Collector und Virtual Machines, gab es die Bedenken, dass Entwickler nicht mehr in der Lage sind, Memory Management zu verstehen. Als IDEs eingeführt wurden, gab es Bedenken, dass Entwickler die SDKs nicht mehr verstehen. Es waren immer ähnliche Bedenken.
Junior-Entwickler, die heute anfangen, erleben eine ganz andere Welt, wie man Software entwickelt, und müssen das auch anders lernen. Manche Dinge, die wir Entwicklern erst später beigebracht haben, werden wir früher beibringen müssen. Mit KI-Agenten hat man den größten Hebel, wenn wir in der Lage sind, sie zu parallelisieren. Dafür müssen wir aber ein paar Dinge gelernt haben: wie man gute Anforderungen erhebt, wie man Edge Cases betrachtet, wie man das in den größeren Kontext des Gesamtunternehmens setzt. Das haben wir Junior-Entwicklern üblicherweise noch nicht beigebracht.
Tomas: Es geht um den Kontext. Kannst du da ein bisschen in die Tiefe gehen?
Marcus: Der Hintergrund ist, dass Code-Autovervollständigung sich den Kontext nur in einem sehr beschränkten Rahmen zusammensucht. Wir bekommen nur das Ergebnis von KI-Agenten oder LLMs, das in den Trainingsdaten und im Kontext des LLMs vorhanden ist. Das einzige, womit wir dagegenwirken können, ist, dem KI-Agenten beizubringen, was eigentlich gute Praxis ist und was umzusetzen ist. Wenn ich KI-Agenten nutze, um Code zu schreiben, der Hibernate als Framework nutzt, sollte ich dem Agenten vorher sagen: Folgende Praktiken sollst du nutzen, folgende sollst du nicht nutzen. Dafür gibt es in sämtlichen KI-Agenten ein Konzept, das nennt sich Skills.
Für einzelne Projekte geht das natürlich noch weiter. Wir haben ja nicht nur das allgemeine Wissen über Best Practices zu den Technologien, die wir nutzen, sondern auch sehr großes Domänenwissen, das für die Anwendung und ihre Entwicklung wichtig ist. Dieses Wissen müssen wir dem KI-Agenten bereitstellen, damit er die richtigen Entscheidungen treffen kann. Es gab eine Studie im Januar 2026 zu AGENTS.md. Dort wurde über 124 Pull Requests hinweg analysiert, welcher Impact entsteht, wenn man eine gute AGENTS.md mit sauberem Kontext für die Anwendung bereitstellt. Das Ergebnis: bis zu 30 Prozent Laufzeit gespart und entsprechend bis zu 16 Prozent weniger Output-Tokens.
Marcus: Es gibt ein paar Stichwörter, mit denen man sich auseinandersetzen sollte. Eins der großen Stichwörter ist Context Engineering. Dafür gibt es verschiedene Layer für verschiedene Anwendungsfälle.
Wir haben eben schon über die AGENTS.md gesprochen. Das ist eine Art Systemprompt, der in jedem Chat automatisch mit eingelesen wird. Dort will ich allgemeine Informationen haben: wie das Repository aufgebaut ist, was der Use Case der Applikation ist, wie ich die Anwendung teste und starte.
Als zweites Werkzeug die genannten Skills. Das ist Spezialwissen, das man im Repository hinterlegen kann. Technisch sind das einfach Markdown-Files mit dem Wissen, plus zusätzlich eine Meta-Information mit einer Beschreibung, wann dieses Wissen hinzuzuziehen ist.
Es gibt eine dritte Ebene, die sogenannten Agents. Ich habe mir ein komplettes Entwicklungsteam als Agenten abgebildet. Ich habe beispielsweise einen Product-Owner-Agenten, einen Backend-Entwickler als Agenten, einen Legal Advisor, einen UX-Experten, einen QA-Experten.
Die letzte Ebene, wie man Kontext bereitstellen kann, sind die MCPs – das Model Context Protocol. Das ist eine Möglichkeit, die Funktionalität zu erweitern, die ein LLM ausführen kann. Ich habe in den meisten Projekten irgendwann einen Debug-MCP-Server geschrieben, der sich im Projekt registriert und tatsächliche Funktionalität bereitstellt.
Tomas: Software-as-a-Service ist ein bisschen auf dem absteigenden Ast. Zumindest prognostiziert man SaaS-Firmen nicht die beste Zukunft, weil sehr viel Software einfach on demand von den Firmen geschrieben werden kann.
Marcus: Ich sehe das ein bisschen differenzierter. Zum einen kann ich deine Beobachtung bestätigen. Gerade für kleine Use Cases gehe ich immer häufiger hin und baue mir schnell etwas selbst, das für mich funktioniert. Nichtsdestotrotz glaube ich, dass damit nicht das Ende der SaaS-Unternehmen eingeläutet wird. Die große Herausforderung ist nicht das Bauen von Software, und war es auch vorher nie. Die große Herausforderung ist immer der Product Market Fit und das langfristige Betreiben der Software. Wo ich Schwierigkeiten sehe, ist bei diesen Micro-SaaS-Unternehmen. Aber die großen SaaS-Unternehmen werden deswegen nicht unter Druck geraten, weil das Betreiben von Software immer noch das ist, was am teuersten ist.
Tomas: Guckst du noch jeden Code an?
Marcus: In der Praxis ist es so: Ich tue das nicht mehr. Es hat sich verändert. Wenn ich heute auf Code schaue, den ich mit KI produziere, dann schaue ich ihn mir immer noch an. Es ist nicht so, dass ich blind in Main merge, das mache ich nicht. Aber ich schaue mir nicht mehr Zeile für Zeile alle Details an, sondern es ist eher ein grobes Rüberscannen. Ich kontrolliere, ob die grundlegende Architektur zu dem passt, wie ich mir das vorstelle. Ähnlich arbeite ich auch mit Entwicklern zusammen. Wenn ich ein Team leite oder geleitet habe, bin ich auch nicht hingegangen und habe Zeile für Zeile jede Contribution angeschaut. Aber ich habe mir trotzdem angeschaut: Passt das strategisch, was da umgesetzt wurde?
Üblicherweise entwickle ich mehrstufig ein Feature oder eine Änderung in der Anwendung. Ich gehe erst hin, mache die Planung. Dann lasse ich das natürlich von KI-Agenten umsetzen. Aber als Nächstes lasse ich immer noch einen Refactoring-Agenten drüber laufen, der Kenntnis darüber hat, wie sauberer Code geschrieben werden soll. Als letzten Schritt habe ich noch einen Review-Agenten, der sich anschaut: Gibt es offensichtliche Bugs in dem Code, gibt es Seiteneffekte, die erzeugt werden könnten, und gibt es Security-Lücken, die hier aufgemacht werden?
Tomas: Sehr spannend. Das war ein sehr umfassender Blick, wie agentic Coding und KI dein Arbeiten verändert haben. Wenn man von dir mehr hören und lesen möchte, wo connectet man sich am besten?
Marcus: LinkedIn ist ein super Kanal. Dort einfach nach Marcus Held mit C suchen. Alternativ gerne Kontakt über meine Webseite aufnehmen, unter www.backendhance.com. Das ist übrigens ein Wortspiel aus Backend und Enhance. Dort findet man auch Artikel von mir aus den letzten Jahren. Ich freue mich immer über eine Kontaktaufnahme und einen Austausch in der Praxis.
Tomas: Super Schlusswort. Vielen Dank, Marcus. Wir sehen uns dann hoffentlich beim nächsten Mal.
Marcus: Ich freue mich. Vielen Dank, Tomas.
Wer konkrete Entscheidungen vor sich hat, braucht keinen weiteren Vortrag — sondern einen Sparringspartner, der die Situation einschätzt. Das ist der Ausgangspunkt für ein Architektur-Review.
