KI macht Entwickler ersetzbar, aber gute Architekten nicht

Vor einigen Monaten habe ich an dieser Stelle beschrieben, wie künstliche Intelligenz die Softwareentwicklung verändert und warum bestimmte Tätigkeiten in diesem Berufsfeld mittelfristig wegfallen werden. Die Reaktionen darauf waren gemischt: von Zustimmung über Skepsis bis hin zu offener Ablehnung. Doch eine Frage tauchte in den Kommentaren und in Gesprächen auf Konferenzen immer wieder auf: Wenn KI tatsächlich Code schreiben kann, was bleibt dann für Menschen übrig?

Diese Frage ist berechtigt. Sie verdient eine ehrliche Antwort. Und diese Antwort führt uns zu einem Thema, das in der Debatte um KI in der Softwareentwicklung oft zu kurz kommt: die Rolle der Architektur, des Domänenwissens und der konzeptuellen Arbeit. Meine These lautet: Diese Bereiche werden nicht weniger wichtig, sondern wichtiger. Die Wertschöpfung verschiebt sich von der Umsetzung zur Konzeption. Und genau das hat weitreichende Konsequenzen für alle, die in diesem Feld arbeiten, von der Entwicklerin am Anfang ihrer Karriere bis zur Führungskraft, die Investitionsentscheidungen trifft.

Was KI heute kann und was nicht

Beginnen wir mit einer ehrlichen Bestandsaufnahme dessen, was moderne KI-Systeme im Bereich der Softwareentwicklung leisten. Die Fortschritte der letzten zwei Jahre sind beeindruckend, und wer sie leugnet, macht sich etwas vor. LLMs (Large Language Models) können heute Funktionen, Klassen und ganze Module auf Zuruf generieren. Sie erkennen Muster in bestehendem Code und wenden Best Practices an, ohne dass man sie explizit darauf hinweisen muss. Sie schreiben Tests, die tatsächlich sinnvolle Randfälle abdecken. Sie erstellen Dokumentation, die oft besser ist als das, was überarbeitete Entwickler um 23 Uhr produzieren. Sie schlagen Refactorings vor, die technische Schulden reduzieren.

Wer heute mit GitHub Copilot, Claude, ChatGPT oder ähnlichen Werkzeugen arbeitet, erlebt täglich, wie viel Routinearbeit diese Systeme abnehmen können. Eine REST-API mit Standard-CRUD-Operationen, die früher einen halben Tag gekostet hätte, entsteht in dreißig Minuten. Ein Datenmigrationsskript, für das man früher Stack Overflow durchsucht hätte, generiert sich fast von selbst. Das ist real, das ist nützlich, und es wird noch besser werden.

Das ist die beeindruckende Seite. Und sie wird noch beeindruckender werden. Die Modelle werden besser, die Integration in Entwicklungsumgebungen wird nahtloser, die Anwendungsfälle werden breiter. Wer glaubt, dass wir den Höhepunkt dieser Entwicklung bereits erreicht haben, unterschätzt das Tempo des Fortschritts.

Doch es gibt auch blinde Flecken, die bei aller Euphorie nicht übersehen werden dürfen. Und diese Flecken werden nicht kleiner, wenn die Modelle größer werden – denn sie sind struktureller Natur.

KI-Systeme arbeiten auf der Ebene von Syntax und Mustern. Sie haben gelernt, welche Codezeilen typischerweise auf welche anderen folgen. Sie wissen, wie ein Repository-Pattern in C# aussieht, weil sie Zehntausende davon gesehen haben. Aber sie wissen nicht, warum ein bestimmtes System dieses Pattern verwenden sollte, oder ob es überhaupt das Richtige ist. Sie kennen die Form, nicht die Bedeutung.

Das zeigt sich besonders deutlich bei Halluzinationen. Ein LLM kann eine Funktion generieren, die syntaktisch korrekt ist, alle Konventionen einhält und auf den ersten Blick vernünftig aussieht, aber inhaltlich falsch ist. Nicht, weil das Modell lügt, sondern weil es gar nicht weiß, was „richtig“ in einem bestimmten fachlichen Kontext bedeutet. Es optimiert Wahrscheinlichkeiten für Zeichenfolgen, nicht für Geschäftslogik. Es produziert, was statistisch plausibel ist, nicht was sachlich korrekt ist.

Hinzu kommt das Problem des lokalen Optimums: KI optimiert das Offensichtliche. Wenn Sie nach einer Lösung für ein Problem fragen, bekommen Sie die wahrscheinlichste Lösung basierend auf den Trainingsdaten. Das ist oft eine gute Lösung. Aber es ist selten die beste Lösung für Ihren spezifischen Kontext, denn den kennt das Modell nicht. Es weiß nicht, dass Ihr Team nur aus zwei Personen besteht und keine Zeit für eine Microservices-Architektur hat. Es weiß nicht, dass Ihre Datenbank-Performance der eigentliche Engpass ist. Es weiß nicht, dass der Fachbereich nächstes Jahr alles umwerfen wird.

Die Schlussfolgerung daraus ist einfach: KI ist ein hervorragendes Werkzeug für die Umsetzung. Aber das setzt voraus, dass jemand weiß, was umgesetzt werden soll. Die entscheidende Frage verschiebt sich damit von „Wie schreibe ich diesen Code?“ zu „Welchen Code sollte ich überhaupt schreiben?“. Und diese Frage kann KI nicht beantworten.

Die Rolle des Architekten neu betrachtet

Damit sind wir bei der Architektur. Und hier lohnt es sich, zunächst zu klären, was dieser Begriff eigentlich bedeutet, denn er wird (zu) oft missverstanden.

Architektur ist nicht das Diagramm mit den großen Boxen und Pfeilen, das in jeder Projektdokumentation auftaucht und nach dem Kick-Off nie wieder angeschaut wird. Architektur ist auch nicht die Entscheidung für ein bestimmtes Framework oder eine bestimmte Cloud-Plattform. Architektur ist vielmehr die Summe der Entscheidungen, die schwer zu ändern sind. Es sind die Entscheidungen über Struktur, über Kommunikationswege, über Grenzen zwischen Komponenten, über Verantwortlichkeiten. Es sind die Entscheidungen, bei denen eine Änderung später teuer wird, sei es technisch, organisatorisch oder beides.

Diese Entscheidungen sind aus mehreren Gründen nicht automatisierbar. Und diese Gründe werden auch nicht verschwinden, wenn die Modelle größer werden.

Erstens erfordern Architekturentscheidungen Kontextwissen, das nicht im Code steht. Um zu entscheiden, ob ein System als Monolith oder als verteiltes System gebaut werden sollte, muss man die Organisation kennen, die es betreibt. Wie groß ist das Team? Wie sind die Deployment-Zyklen? Welche Teile des Systems ändern sich häufig, welche selten? Wie sieht die bestehende Infrastruktur aus? Welche Kompetenzen sind vorhanden, welche fehlen? Diese Informationen stehen in keinem Repository. Sie existieren in Köpfen, in Gesprächen, in der gelebten Praxis einer Organisation.

Zweitens erfordern Architekturentscheidungen Abwägungen zwischen konkurrierenden Zielen. Soll das System maximal performant sein oder maximal wartbar? Soll es schnell ausgeliefert werden oder langfristig stabil sein? Soll es flexibel erweiterbar sein oder einfach zu verstehen? Diese Trade-offs haben keine objektiv richtige Antwort. Sie hängen von Prioritäten ab, die Menschen setzen müssen, basierend auf Geschäftszielen, Ressourcen und Risikobereitschaft.

Drittens erfordern sie Voraussicht. Was könnte sich in zwei Jahren ändern? Welche Annahmen, die wir heute treffen, werden sich als falsch herausstellen? Welche Teile des Systems müssen flexibel bleiben, welche dürfen in Beton gegossen werden? Wo lohnt sich Investition in Abstraktion, wo ist sie Over-Engineering? Diese Fragen erfordern Erfahrung, Intuition und die Fähigkeit, mit Unsicherheit umzugehen. Sie erfordern das, was erfahrene Architekten „Bauchgefühl“ nennen: eine internalisierte Mustererkennung, die sich nicht in Regeln fassen lässt.

Viertens erfordern sie Dialog. Architektur entsteht nicht im stillen Kämmerlein. Sie entsteht im Gespräch mit Fachbereichen, mit Stakeholdern, mit dem Entwicklungsteam. Sie erfordert die Fähigkeit, zuzuhören, nachzufragen, zwischen verschiedenen Welten zu übersetzen. Ein Architekt muss verstehen, was der Vertrieb meint, wenn er von „flexiblen Rabatten“ spricht, und das in eine technische Struktur übersetzen. Diese Übersetzungsleistung ist zutiefst menschlich.

Es gibt noch einen fünften Punkt, der oft übersehen wird: Architekturentscheidungen sind soziale Akte. Sie formen Teams, sie definieren Schnittstellen zwischen Menschen, sie beeinflussen, wer mit wem zusammenarbeiten muss. Die Entscheidung, ein System in drei Services aufzuteilen, ist nicht nur eine technische Entscheidung. Sie ist auch eine Entscheidung darüber, wie die Arbeit verteilt wird, welche Teams entstehen, wie Kommunikation fließt. Diese organisatorischen Implikationen zu verstehen und zu gestalten, erfordert Einfühlungsvermögen und politisches Gespür. All das sind Eigenschaften, die kein Sprachmodell besitzt.

Ein LLM kann das Observer Pattern implementieren. Aber es kann nicht entscheiden, wann dieses Pattern die richtige Wahl ist. Es kann Microservices generieren. Aber es kann nicht beurteilen, ob Microservices für eine bestimmte Organisation überhaupt sinnvoll sind, oder ob sie die Komplexität nur verlagern, statt sie zu reduzieren. Die wertvollste Architekturentscheidung ist oft die Entscheidung, etwas nicht zu bauen. Und genau diese Entscheidung liegt außerhalb dessen, was ein generatives Modell leisten kann.

Kein LLM kennt die Domäne

Das führt uns zum zweiten Bereich, der durch KI nicht ersetzt wird: das Domänenwissen.

Jede Software existiert, um ein Problem in einer bestimmten Domäne zu lösen. Ein Bestellsystem löst Probleme im E-Commerce. Eine Patientenakte löst Probleme im Gesundheitswesen. Eine Handelssoftware löst Probleme an den Finanzmärkten. Eine Produktionssteuerung löst Probleme in der Fertigung. Die Software ist nie Selbstzweck. Sie ist immer Mittel zu einem fachlichen Zweck. Diese Erkenntnis klingt banal, wird aber in der Praxis erstaunlich oft vergessen.

Um gute Software zu bauen, muss man diesen Zweck verstehen. Man muss die Domäne verstehen. Und genau hier stößt KI an eine fundamentale Grenze, die sich nicht durch größere Modelle oder bessere Trainingsdaten überwinden lässt.

LLMs wurden auf öffentlich verfügbarem Text trainiert. Sie kennen, was über Domänen geschrieben wurde. Sie kennen die allgemeinen Konzepte von Bestellungen, Patienten, Handelspositionen, Fertigungsaufträgen. Aber sie kennen nicht die spezifische Logik eines bestimmten Unternehmens. Sie wissen nicht, dass in Ihrem Unternehmen eine „Bestellung“ drei verschiedene Zustände haben kann, die nirgendwo dokumentiert sind, weil das historisch so gewachsen ist. Sie wissen nicht, dass der Begriff „Kunde“ in der Buchhaltung etwas anderes bedeutet als im Vertrieb. Sie wissen nicht, dass bestimmte Produkte aus regulatorischen Gründen anders behandelt werden müssen als andere.

Die richtige Frage ist nicht „Wie baue ich ein Bestellsystem?“. Die richtige Frage ist: „Was bedeutet eine Bestellung in diesem Geschäft? Wann beginnt sie? Wann endet sie? Was passiert, wenn sie storniert wird? Was passiert, wenn sie teilweise geliefert wird? Wer darf sie ändern, und unter welchen Bedingungen? Welche Ereignisse in der Domäne sind relevant, welche nicht?“

Diese Fragen lassen sich nicht durch Prompt-Engineering beantworten. Sie erfordern Gespräche mit Fachexperten. Sie erfordern das geduldige Herausarbeiten von implizitem Wissen, das oft nicht einmal den Fachleuten selbst bewusst ist. Es ist Wissen, das in Routinen steckt, in Ausnahmen. In den Geschichten, die erzählt werden, wenn etwas schiefgelaufen ist. Dieses Wissen sichtbar zu machen, erfordert Methoden wie Event-Storming oder Collaborative Modeling, bei denen Menschen gemeinsam an einem Whiteboard stehen und rekonstruieren, was in ihrer Domäne eigentlich passiert.

Das ist zutiefst menschliche Arbeit. Es ist Arbeit, die Geduld erfordert, die Ambiguitätstoleranz verlangt, die manchmal frustrierend ist, weil die Antworten nicht sofort klar sind. Es ist Arbeit, die man nicht beschleunigen kann, indem man schneller tippt. Und genau deshalb wird sie durch KI nicht obsolet, sondern im Gegenteil: Je mehr die Umsetzung automatisiert wird, desto wichtiger wird es, das Richtige umzusetzen. Und um das Richtige zu identifizieren, benötigt man Domänenwissen.

Ich erlebe in meiner Beratungsarbeit regelmäßig, dass Projekte scheitern, nicht weil die Technik schlecht wäre, sondern weil niemand die richtigen Fragen gestellt hat. Das neue System wurde gebaut, es funktioniert technisch einwandfrei – aber es bildet die falschen Prozesse ab, verwendet die falschen Begriffe, macht die falschen Annahmen. Das sind keine Fehler, die KI verhindern wird. Es sind Fehler, die entstehen, wenn man die Domäne nicht versteht. Und sie werden häufiger werden, wenn die Illusion entsteht, dass schnelle Codegenerierung auch schnelles Verstehen bedeutet.

Die neue Arbeitsteilung

Was bedeutet das alles für die Praxis? Wie verändert sich die Arbeitsteilung in der Softwareentwicklung? Diese Fragen höre ich oft, und die Antworten sind weniger düster, als manche befürchten. Vorausgesetzt, man versteht die Richtung der Veränderung.

Zunächst das Offensichtliche: Routineaufgaben werden schneller und günstiger. Code, der früher Stunden gebraucht hat, entsteht heute in Minuten. Die Einstiegshürde „etwas zu bauen“ sinkt dramatisch. Das ist grundsätzlich positiv. Es demokratisiert den Zugang zur Softwareentwicklung und ermöglicht schnellere Experimente. Ideen können ausprobiert werden, bevor man sich auf eine teure Implementierung festlegt.

Aber es birgt auch eine Gefahr: die Gefahr, das Falsche sehr effizient zu bauen. Wenn es einfach wird, Code zu generieren, besteht die Versuchung, sofort loszulegen, ohne vorher gründlich nachzudenken. Das Ergebnis sind Systeme, die technisch funktionieren, aber am eigentlichen Bedarf vorbeigehen. Oder Systeme, die kurzfristig funktionieren, aber langfristig nicht wartbar sind. Die Geschwindigkeit der Codegenerierung kann eine trügerische Sicherheit vermitteln. Man fühlt sich produktiv, obwohl man eigentlich nur schneller in die falsche Richtung läuft.

Bestimmte Fähigkeiten werden in dieser neuen Welt wichtiger:

• Abstraktionsfähigkeit: die Fähigkeit, das Wesentliche vom Unwesentlichen zu trennen, komplexe Sachverhalte auf ihre Kernstruktur zu reduzieren.
• Kommunikationsfähigkeit: die Fähigkeit, zwischen Fachbereich und Technik zu übersetzen, Anforderungen zu verstehen und technische Implikationen zu erklären.
• Urteilsvermögen: die Fähigkeit zu entscheiden, wann KI hilft und wann sie schadet, wann man ihrem Output vertrauen kann und wann eine manuelle Prüfung nötig ist.
• Systemdenken: die Fähigkeit, Wechselwirkungen zu verstehen, nicht nur einzelne Komponenten isoliert zu betrachten.

Andere Fähigkeiten verlieren an Bedeutung. APIs und Syntax auswendig zu kennen, wird weniger wertvoll, wenn man jederzeit nachfragen kann. Boilerplate-Code zu schreiben war nie besonders erfüllend und wird künftig noch weniger nötig sein. Routine-Debugging bei Standardproblemen lässt sich zunehmend automatisieren. Das ist kein Verlust, sondern eine Befreiung, vorausgesetzt, man nutzt die gewonnene Zeit für wertvollere Tätigkeiten.

Eine besondere Warnung möchte ich an dieser Stelle aussprechen: Hüten Sie sich vor der Prompt-Engineering-Illusion. Die Vorstellung, dass man nur „die richtige Frage stellen“ müsse, um von KI perfekte Ergebnisse zu bekommen, ist gefährlich. Ja, gute Prompts führen zu besseren Ergebnissen. Aber wer die richtige Frage nicht kennt, bekommt bestenfalls plausible Antworten auf die falsche Frage. Prompt Engineering ersetzt kein Domänenwissen. Es setzt es voraus. Wer nicht versteht, was gebaut werden soll, kann auch nicht sinnvoll danach fragen.