30-jähriger Veteran erklärt, warum KI Software-Architekten nicht ersetzen kann

Warum praktische Architekturarbeit im KI-Zeitalter nach wie vor gewinnt

Dennis Doma ist ein Software-Engineering-Veteran mit 30 Jahren Erfahrung, Microsoft MVP und der Schöpfer von Fluent Assertions — einer der beliebtesten Open-Source-Testbibliotheken für .NET. Als Coding Architect bei Aviva Solutions hat er Jahrzehnte damit verbracht, gegen die Komplexität zu kämpfen, die Enterprise-Software zerstört. In diesem Gespräch mit Beyond Coding schildert er, wie KI-Tools seinen Workflow verändern — und wo sie an ihre Grenzen stoßen.

Über Architekten, die aufhören zu coden: “If you stop coding, if you actually stop building production systems, you lose that experience. If I had stopped coding for the last 3 years, I would have probably missed the whole AI scene.” (Wenn man aufhört zu coden, wenn man tatsächlich aufhört, Produktionssysteme zu bauen, verliert man diese Erfahrung. Hätte ich die letzten 3 Jahre nicht mehr gecoded, hätte ich die gesamte KI-Entwicklung verpasst.) Doma argumentiert, dass Software-Architekten, die sich auf abstrakte Diagramme zurückziehen, die Fähigkeit verlieren zu beurteilen, ob Lösungen tatsächlich funktionieren. Die praktische Feedbackschleife — bauen, ausliefern, Fehler beheben — ist unersetzlich.

Über die Verantwortung für KI-generierten Code: “I treat all AI-generated code as mine.” (Ich behandle allen KI-generierten Code als meinen eigenen.) Als GitHub Copilot den Großteil seiner neuen Open-Source-Mocking-Bibliothek aus einem einzigen Issue heraus erstellte, war Doma beeindruckt — übernahm aber sofort die Verantwortung. Er überprüft KI-generierte Tests Zeile für Zeile, refaktoriert Code, der seinen Standards nicht entspricht, und aktualisiert iterativ Instruction-Dateien, damit zukünftige Generierungen besser werden. Der Code ist nicht “KI-Code” — er ist seine Verantwortung.

Über versehentliche Komplexität: Teams kopieren blind Architekturmuster — Onion Architecture, Clean Architecture — ohne zu verstehen, warum diese existieren. Entwickler mit 10 bis 15 Jahren Erfahrung werden “übereifrig” an SOLID-Prinzipien gebunden und schwingen sie wie Schutzschilde gegen Pragmatismus. “Yeah, but you don’t need this abstraction. Yeah, but it’s ready for the future. You don’t need this abstraction. That’s a smell.” (Du brauchst diese Abstraktion nicht. Ja, aber sie ist zukunftssicher. Du brauchst diese Abstraktion trotzdem nicht. Das ist ein Warnsignal.)

Über Junior-Entwickler und KI: Es entstehen zwei Archetypen — diejenigen, die KI meiden, um ihre Lernfähigkeiten zu bewahren, und diejenigen, die sie überall einsetzen, ohne die Ausgaben zu verstehen. Doma traf auf einen Entwickler, dessen Pull Request funktionierte (Tests bestanden), der aber nicht erklären konnte, was der Code tat. Seine Reaktion: “I don’t care if you don’t practice TDD properly, but make sure the code is designed the way we want it and we can maintain it.” (Es ist mir egal, ob du TDD nicht korrekt anwendest, aber stell sicher, dass der Code so gestaltet ist, wie wir es wollen, und dass wir ihn warten können.)

Über die Nachhaltigkeit von Open Source: Das Tailwind-Team entließ 75 % seiner Mitarbeiter, weil KI ihre Premium-Komponenten replizieren kann. Domas Gegenargument: Menschen unterschätzen chronisch die Komplexität hinter ausgereiften Bibliotheken. „Ich habe 15 Jahre damit verbracht, Fluent Assertions zu perfektionieren. Jemand sagt: ‚Das kann ich in ein paar Tagen nachbauen.’ Klar.” Open-Source-Code kann schnell zu dem Code werden, den man selbst warten muss — das sollte man einkalkulieren.

5 Lektionen eines Coding Architects über KI-gestützte Entwicklung

• Tests sind dein Sicherheitsnetz — Egal ob Code von Menschen oder KI stammt, robuste Tests sind das ultimative Validierungswerkzeug. „Wenn du die Software als Blackbox betrachtest und dein Sicherheitsnetz deine Tests sind, dann solltest du ihnen besondere Aufmerksamkeit widmen.”
• Dokumentation potenziert sich mit KI — ADRs, Commit-Messages und Entscheidungsdokumente werden dramatisch wertvoller, wenn KI-Tools sie durchsuchen können. Unternehmen, die in reichhaltigen Kontext investieren, werden „meilenweit voraus” sein.
• Lass Teams ihre eigenen KI-Tools wählen — Standardisiere nicht auf ein einziges Tool. „Lass die Leute das KI-Tool verwenden, das sie wollen, weil es sich ständig verändert.” Nutzung verfolgen, Lizenzen erweitern, aber Experimentieren nicht einschränken.
• Kontext ist wie Milch — Doma musste auf die harte Tour lernen, was Kontext-Komprimierung bedeutet: Seine KI hat experimentellen Code in den Main-Branch gemergt und gepusht. Feature-Branches und häufige Commits sind unverzichtbare Sicherheitsvorkehrungen.
• Open Source lohnt sich noch immer — „Du gibst, aber du bekommst so viel zurück: Wissen, Erfahrung, neue Tools, neue Erkenntnisse, Sichtbarkeit.” Der ROI liegt nicht nur im Code — er liegt in der Feedbackschleife der Community.

Was das für KI-gestützte Software-Teams bedeutet

Domas Perspektive durchschneidet den Hype: KI-Coding-Tools sind für die Ausführungsgeschwindigkeit wirklich transformativ, ersetzen aber nicht das architektonische Urteilsvermögen, das aus jahrzehntelanger praktischer Erfahrung entsteht. Die Entwickler, die erfolgreich sein werden, sind jene, die KI als Kraftwerkzeug einsetzen und dabei kritisches Denken bewahren — die verstehen, warum Muster existieren, und sie nicht nur blind anwenden. Für Organisationen lautet die Botschaft klar: Investiert in Dokumentation, Testqualität und architektonisches Mentoring. Das sind die Werte, die sich potenzieren, wenn die KI das Tippen übernimmt.