Angenommen, ein Webshop soll Gutscheincodes bekommen. Die Entwicklerin beschreibt die Aufgabe ihrem Coding-Agenten, und zwanzig Minuten später liegt ein Pull Request vor: neue Datenbanktabelle, Prüflogik direkt im Checkout, ein paar Tests, alles grün. Der Code ist sauber formatiert und tut, was verlangt war. Trotzdem stecken in diesem Pull Request ein halbes Dutzend Entscheidungen, die niemand bewusst getroffen hat. Gehört die Gutscheinlogik wirklich in den Checkout oder in die Preisberechnung? Was passiert, wenn derselbe Code zweimal gleichzeitig eingelöst wird? Und wer darf später die Regeln ändern, das Marketing oder nur die Entwicklung?

Solche Fragen gab es schon immer. Neu ist, wie schnell sie sich stellen. Wenn das Schreiben von Code kaum noch Zeit kostet, wird das Entscheiden zum Engpass. Genau deshalb gewinnt Architekturkompetenz an Gewicht, und zwar nicht nur für Menschen mit „Architekt“ im Titel, sondern für alle, die mit KI-Werkzeugen Software bauen.

Was sich ändert, wenn Code fast nichts mehr kostet

Seit 2025 arbeiten Coding-Agenten wie GitHub Copilot, Claude Code, Cursor oder OpenAI Codex nicht mehr nur als Autovervollständigung. Sie lesen ein Repository, planen mehrere Schritte, ändern Dateien, führen Tests aus und legen das Ergebnis zur Prüfung vor. Ein Formular aus einem Design-Entwurf, eine Schnittstelle zum Anlegen, Lesen, Ändern und Löschen von Datensätzen oder ein Satz Unit-Tests entstehen damit in einem Bruchteil der früheren Zeit.

Das verschiebt die Arbeit, statt sie abzuschaffen. Ein Vergleich hilft: Die Tabellenkalkulation hat das Rechnen in der Buchhaltung beschleunigt, aber nicht die Frage beantwortet, welche Kennzahlen ein Unternehmen steuern sollte. Ähnlich ist es hier. Ein Agent liefert schnell eine plausible Lösung. Ob sie in das Gesamtsystem passt, kann er nur beurteilen, wenn ihm jemand die Grenzen, Regeln und Ziele des Systems mitgeteilt hat.

Hinzu kommt ein Mengeneffekt. Wo früher an einem Tag ein Feature fertig wurde, entstehen heute drei. Jedes davon bringt kleine Strukturentscheidungen mit. Ohne klare Leitplanken wächst die Codebasis schneller als das Verständnis des Teams für sie. Das Ergebnis kennen viele aus Altprojekten: ein System, das funktioniert, aber das niemand mehr gefahrlos ändern kann. Mit KI kann dieser Zustand in Monaten statt in Jahren erreicht sein.

Welche Entscheidungen beim Menschen bleiben

Nicht jede Entscheidung ist gleich wichtig. Ob eine Funktion calculateTotal oder computeSum heißt, darf ein Agent getrost selbst festlegen. Anders sieht es bei Entscheidungen aus, die später teuer zu ändern sind. Sie bilden den Kern dessen, was Architektur ausmacht.

Modulgrenzen und Zuständigkeiten

Wo endet ein Modul, und welche Daten darf es von anderen lesen? Ein Agent wählt in der Regel den kürzesten Weg und greift direkt auf die Tabelle zu, die er braucht. Das funktioniert, verknüpft aber Teile des Systems, die getrennt bleiben sollten. Wie sich Systeme in Bausteine mit klaren Schnittstellen zerlegen lassen, beschreibt der Beitrag zu modularer Software-Architektur nach dem Blackbox-Prinzip.

Datenhoheit und Konsistenz

Welcher Teil des Systems ist für welche Daten verantwortlich, und wie viel Inkonsistenz ist erlaubt? Im Gutscheinbeispiel entscheidet diese Frage darüber, ob ein Code doppelt eingelöst werden kann. Eine Datenbanktransaktion, eine eindeutige Einschränkung auf Tabellenebene oder ein Sperrmechanismus lösen das Problem unterschiedlich gut, je nach Last und Aufbau des Systems. Ein Agent schlägt eine dieser Varianten vor. Welche passt, hängt von Wissen ab, das meist nicht im Code steht.

Verhalten im Fehlerfall

Was geschieht, wenn der Zahlungsdienstleister nicht antwortet? Wird die Bestellung abgebrochen, später erneut versucht oder zur manuellen Prüfung markiert? Solche Fragen nach Ausfallsicherheit, Wiederholbarkeit und Zeitüberschreitungen sind fachliche Entscheidungen mit technischen Folgen. KI-generierter Code behandelt den Normalfall meist gut und den Fehlerfall oft nur so weit, wie die Aufgabenbeschreibung es verlangt.

Sicherheit, Datenschutz und Betrieb

Welche Daten werden protokolliert, wer darf welche Schnittstelle aufrufen, wo laufen die Daten physisch? Wenn ein Agent ein Logging einbaut, das versehentlich E-Mail-Adressen mitschreibt, ist das ein Datenschutzthema nach DSGVO und kein Stilfehler. Auch die Frage, ob ein Feature einen zusätzlichen Dienst, eine neue Abhängigkeit oder eine weitere Cloud-Ressource braucht, gehört in menschliche Hand, denn sie bestimmt Kosten und Wartungsaufwand über Jahre.

Vom T-Profil zum Pi-Profil

In der Personalentwicklung ist das Bild des T-förmigen Profils verbreitet: tiefes Wissen in einem Fachgebiet, dargestellt als senkrechter Balken, und ein breiter Überblick über benachbarte Gebiete als Querbalken. Für die Arbeit mit KI-Werkzeugen beschreibt ein anderes Bild die Anforderungen besser, das Pi-Profil nach dem griechischen Buchstaben π mit zwei senkrechten Balken.

Der Querbalken steht für genug Wissen über Frontend, Backend, Datenhaltung, Infrastruktur und Sicherheit, um Entscheidungen in jedem dieser Bereiche einordnen zu können. Gemeint ist kein Expertenwissen überall, sondern die Fähigkeit, eine Lösung des Agenten in einem fremden Bereich zu lesen und die richtigen Rückfragen zu stellen. Wer nur Frontend kennt, merkt nicht, dass der vorgeschlagene Datenbankzugriff bei großen Datenmengen zum Problem wird.

Der erste senkrechte Balken steht für Produkt- und Fachverständnis: aus einer vagen Anforderung herauszuarbeiten, was eigentlich gebraucht wird. Das ist genau der Teil, den ein Agent nicht selbst leisten kann, weil er die Nutzer, das Geschäftsmodell und die Vorgeschichte des Projekts nicht kennt.

Der zweite senkrechte Balken steht für Engineering-Tiefe: Lösungen so umzusetzen, dass sie unter Last, im Fehlerfall und nach Jahren der Weiterentwicklung tragen. Hier zeigt sich der Unterschied zwischen Code, der den Test besteht, und Code, der in Produktion besteht.

Das Pi-Profil bedeutet also nicht weniger Spezialisierung, sondern zwei Schwerpunkte und mehr Breite. Ein Begriff aus diesem Umfeld ist der „Product Engineer“, eine Rolle, die Produktverantwortung und technische Umsetzung in einer Person bündelt. Ob sich dieser Titel durchsetzt, ist offen. Die Richtung, dass Übergaben zwischen Spezialisten seltener werden und eine Person mehr Verantwortung über den ganzen Weg von der Anforderung bis zum Betrieb trägt, ist in vielen Teams bereits sichtbar.

Fähigkeiten, die an Gewicht gewinnen

Aus diesem Bild lassen sich einige Fähigkeiten ableiten, die beim Arbeiten mit Coding-Agenten den Unterschied machen. Sie sind nicht neu, werden aber häufiger gebraucht.

• Präzise formulieren. Ein Agent setzt um, was beschrieben ist, und füllt Lücken nach Wahrscheinlichkeit. Wer Ziele, Randbedingungen und Abnahmekriterien klar aufschreiben kann, bekommt bessere Ergebnisse. Wie sich dieser Gedanke zu einem festen Ablauf ausbauen lässt, zeigt der Beitrag über Spec-Driven Development mit GitHub Spec Kit.
• Kritisch lesen. Generierten Code zu prüfen ist anspruchsvoller, als ihn selbst zu schreiben, weil man die Gedanken dahinter nicht kennt. Gute Reviewer fragen nicht nur, ob der Code funktioniert, sondern warum er so gebaut ist und welche Alternative der Agent verworfen hat.
• Abwägen. Fast jede Architekturentscheidung ist ein Kompromiss zwischen Geschwindigkeit, Kosten, Sicherheit und Änderbarkeit. Wann reicht ein schneller Prototyp, wann rechtfertigt die Lage gründlichere Arbeit? Diese Abwägung bleibt Kopfarbeit.
• In Zusammenhängen denken. Eine lokale Optimierung kann das Gesamtsystem verschlechtern, etwa wenn ein Agent zur Beschleunigung einer Seite einen Cache einbaut, der an anderer Stelle veraltete Preise anzeigt. Systemisches Denken heißt, solche Wechselwirkungen vorherzusehen.
• Muster statt Werkzeuge lernen. Frameworks und KI-Werkzeuge wechseln in kurzen Abständen. Prinzipien wie lose Kopplung, klare Schnittstellen und einfache Datenflüsse bleiben. Einen Überblick über bewährte Strukturen gibt der Beitrag zu den wichtigsten Software-Architekturmustern.

Architektur so festhalten, dass Agenten sie befolgen

Architekturwissen, das nur in den Köpfen steckt, hilft einem Agenten nicht. Ein praktischer Nebeneffekt der KI-Werkzeuge ist, dass sich gute Dokumentation plötzlich unmittelbar auszahlt. Drei Ansätze haben sich bewährt.

Architekturentscheidungen schriftlich festhalten. Architecture Decision Records, kurz ADR, sind kurze Textdateien im Repository, die jeweils eine Entscheidung beschreiben: Kontext, Entscheidung, Status, Konsequenzen. Das Format wurde lange vor der KI für menschliche Teams entworfen. Heute lesen auch Agenten diese Dateien und können sich daran halten, wenn sie Teil ihres Kontexts sind.

Projektregeln für Agenten pflegen. Die meisten Coding-Agenten lesen eine Anweisungsdatei im Projekt, etwa AGENTS.md, CLAUDE.md oder .github/copilot-instructions.md. Dort gehören keine allgemeinen Programmiertipps hinein, sondern die Regeln dieses einen Systems: welche Schichten es gibt, welche Bibliotheken gesetzt sind, welche Zugriffe verboten sind. Je konkreter, desto besser.

Regeln automatisch prüfen. Was sich als Regel formulieren lässt, sollte eine Maschine kontrollieren. Werkzeuge wie ArchUnit für Java oder dependency-cruiser für JavaScript und TypeScript prüfen in der Build-Pipeline, ob Module nur auf erlaubte andere Module zugreifen. In der Fachliteratur heißen solche automatisierten Architekturtests auch „Fitness Functions“. Sie sind das wirksamste Mittel gegen schleichende Verschlechterung, weil sie Verstöße melden, egal ob ein Mensch oder ein Agent sie verursacht hat.

Für den Review-Prozess folgt daraus eine Arbeitsteilung: Automatische Prüfungen fangen Stil, Typen, bekannte Sicherheitsmuster und Strukturregeln ab. Menschliche Reviews konzentrieren sich auf die Fragen aus dem Abschnitt oben, also Zuständigkeit, Daten, Fehlerfälle und Sicherheit. Die Verantwortung für das Ergebnis bleibt in jedem Fall beim Team, nicht beim Werkzeug.

Wie Sie Breite gezielt aufbauen

Wer seine Kompetenz in Richtung Pi-Profil erweitern möchte, muss nicht zurück an die Hochschule. Einige Wege haben sich in der Praxis als wirksam erwiesen.

Ein Ansatz ist, bewusst Aufgaben außerhalb des eigenen Schwerpunkts zu übernehmen. Eine Backend-Entwicklerin baut die Oberfläche für ihr eigenes Feature, ein Frontend-Entwickler richtet die Deployment-Pipeline ein. KI-Werkzeuge senken die Einstiegshürde dafür deutlich. Wichtig ist, sie dabei als Lehrer zu nutzen und nicht nur als Lieferanten: sich den erzeugten Code erklären lassen, nach Alternativen fragen, die Erklärung mit der offiziellen Dokumentation abgleichen.

Ein zweiter Ansatz sind gemeinsame Reviews über Fachgrenzen hinweg. Wenn die Datenbankspezialistin regelmäßig Pull Requests aus dem Frontend-Team liest und umgekehrt, wächst das gegenseitige Verständnis schneller als in jeder Schulung.

Drittens lohnt es sich, Prototypen selbst zu bauen, statt nur Konzepte zu schreiben. Wer als Architekt einen Entwurf in einem Nachmittag mit einem Agenten prototypisch umsetzt, merkt schnell, wo das Konzept hakt. Der Prototyp ist dabei ein Werkzeug zum Lernen und kein Produktionscode.

Was das für Ihr Team bedeutet

Unsere Einschätzung: Architekturwissen wird durch KI nicht entwertet, sondern verteilt. Früher konnte ein Team einen großen Teil der Strukturentscheidungen bei einer erfahrenen Person bündeln, weil der Code ohnehin langsam entstand. Heute fallen diese Entscheidungen bei jedem Agentenlauf an, und damit bei jeder Person, die einen Agenten startet. Teams, die das ignorieren, erleben in kurzer Zeit eine wachsende Codebasis mit abnehmender Änderbarkeit.

Für Entscheider heißt das: In Werkzeuglizenzen zu investieren, reicht nicht. Mindestens ebenso wichtig sind Zeit für Reviews, schriftlich festgehaltene Architekturregeln und automatische Prüfungen. Überschätzt wird oft der Geschwindigkeitsgewinn beim Schreiben, unterschätzt der Aufwand beim Prüfen.

Für Entwickler:innen heißt das: Die Breite über die eigenen Fachgrenzen hinaus ist kein Nice-to-have mehr. Wer generierten Code aus allen Schichten eines Systems beurteilen kann, wird gebraucht. Wer nur die Ausführung beherrscht, konkurriert mit einem Werkzeug.

Wie sich die Rolle von Softwareentwicklern durch KI insgesamt verschiebt, vom Schreiben zum Gestalten und Prüfen, beleuchtet der Beitrag Software Engineering in der KI-Ära. Wer Architektur, Werkzeugwahl und den Einsatz von Coding-Agenten für ein konkretes Vorhaben klären möchte, findet Beratung und Seminare im Bereich Softwareentwicklung und Frameworks.

Häufige Fragen zu Architekturkompetenz und KI

Macht Full-Stack-Kompetenz Spezialisierung überflüssig?

Nein. Das Pi-Profil verlangt ausdrücklich zwei Bereiche mit echter Tiefe. Breite ergänzt die Spezialisierung, sie ersetzt sie nicht. Gerade bei Sicherheit, Datenbanken oder verteilten Systemen braucht es weiterhin Menschen, die tiefer sehen als ein Agent.

Welche KI-Werkzeuge sollten Architekt:innen kennen?

Wichtiger als einzelne Produkte sind die Kategorien: Coding-Agenten in Editor und Terminal (etwa GitHub Copilot, Claude Code, Cursor oder Codex), Werkzeuge für spezifikationsgetriebene Abläufe wie GitHub Spec Kit sowie automatische Review- und Testwerkzeuge. Die Produkte ändern sich schnell. Entscheidend ist, neue Werkzeuge rasch einordnen und ihre Ergebnisse kritisch prüfen zu können.

Wie viel Architekturdokumentation braucht ein kleines Team?

Weniger als oft befürchtet. Eine kurze Anweisungsdatei für die Agenten, eine Handvoll ADR zu den wichtigsten Entscheidungen und ein paar automatische Strukturtests reichen für viele Projekte aus. Wichtig ist, dass diese Dokumente aktuell bleiben, denn Agenten befolgen auch veraltete Regeln.

Können Coding-Agenten selbst Architekturentscheidungen treffen?

Sie können Vorschläge machen, Varianten vergleichen und Vor- und Nachteile auflisten, oft sogar recht gut. Was ihnen fehlt, ist das Wissen über Rahmenbedingungen außerhalb des Codes: Budget, Teamgröße, Betriebsmodell, rechtliche Vorgaben, Pläne für die nächsten Jahre. Die Entscheidung und die Verantwortung dafür bleiben deshalb beim Team.