Ich höre oft: Wenn KI den Code schreibt, braucht es keine Architekten mehr. Ich sehe in den Projekten jeden Tag das Gegenteil.
Die These, die ich oft höre
Die Logik geht so: Ein modernes Modell kennt jedes Design Pattern. Es kann Strategy, Factory, Adapter, alles sauber implementieren. Es kennt jede Bibliothek, jedes Framework, jede Best Practice. Also kann es auch die Architektur.
Der erste Teil stimmt. Der zweite nicht.
Fakt ist: Ein Pattern zu implementieren ist nicht schwer. Die schwierige Frage ist: Wo brauchen wir welches Pattern, und warum? Und wie stellen wir sicher, dass diese Entscheidung im ganzen System gilt, nicht nur in dem Modul, das der Agent gerade vor sich hat?
Was ein Agent sieht und was nicht
Ein Coding Agent sieht seine Aufgabe. Ein Ticket, ein paar Dateien, vielleicht das Repository. Das ist viel, aber es ist nicht das System.
Er weiss nicht, dass wir dieses Problem vor sechs Monaten an einer anderen Stelle schon gelöst haben. Er weiss nicht, warum eine Schnittstelle so aussieht, wie sie aussieht. Warum bestimmte Daten nicht direkt zwischen zwei Systemen fliessen dürfen. Warum wir an einer Stelle bewusst keine neue Abhängigkeit wollen, obwohl es einfacher wäre.
Das ist bei Menschen übrigens nicht anders. Ein neuer Entwickler, egal wie gut, kennt die Gründe auch nicht. Der Unterschied: Er fragt. Ein Agent baut.
Die wichtigste Antwort ist Nein
Was mich in den letzten Jahren am meisten überrascht hat: Die wertvollste Entscheidung eines Architekten ist immer öfter, dass gar nichts gebaut wird.
Früher war neuer Code teuer. Jemand musste ihn schreiben, testen, reviewen. Das hat gebremst, und die Bremse war gesund. Heute erzeugt ein Agent in Minuten tausend Zeilen. Der Ballast fällt zunächst nicht auf, weil er nichts kostet. Er kostet erst später, wenn ihn jemand verstehen muss.
Also braucht es jemanden, der sagt: Nein. Das gibt es schon. Nein, das gehört nicht hierhin. Nein, das Problem lösen wir nicht mit Code, sondern indem wir die Anforderung ändern. Das kann ein Modell heute nicht, weil es dafür das ganze System kennen müsste.
Wissen in eine Form bringen
Die Arbeit des Architekten verändert sich trotzdem. Und zwar in eine Richtung, die ich gut finde.
Früher steckte Architekturwissen in Köpfen. Der eine, der seit zehn Jahren dabei ist. Die andere, die weiss, warum die Datenbank so aufgebaut ist. Wenn die gehen, geht das Wissen mit.
Heute muss dieses Wissen in eine Form, mit der Agenten arbeiten können. Regeln, die ein Agent lesen kann. Contracts, gegen die er baut. Prüfungen, die automatisch laufen. Das ist Arbeit, und es ist genau die Arbeit, die gute Architekten immer machen wollten und nie Zeit dafür hatten.
Bei NeoCoder ist das der Kern: Ein Architekt-Agent schreibt Spezifikation und Contract, bevor irgendjemand Code anfasst. Aber der Architekt-Agent hat seine Regeln von einem Menschen. Und dieser Mensch ist wichtiger geworden, nicht überflüssig.
Die neue Rolle
Der Architekt erklärt der KI nicht mehr, wie man eine Klasse schreibt oder einen Endpoint baut. Er führt das System.
Er definiert Architektur und Regeln. Er entscheidet, welche Patterns wo gelten. Er sorgt dafür, dass nicht fünf Agenten fünf Lösungen für dasselbe Problem bauen. Er bringt Domainwissen in eine Form, mit der KI arbeiten kann. Und er entscheidet, wann die KI falsch liegt.
Das ist eine grössere Rolle als früher, nicht eine kleinere. Und es werden weniger Leute sein, die sie ausfüllen. Fünf Menschen mit zwanzig oder fünfzig Agenten. Aber diese fünf müssen sehr genau wissen, was sie tun und wohin sie wollen (Systemziel).
Code wird Massenware. Was bleibt, ist die Entscheidung, was gebaut wird, was nicht, und warum. Das ist Architektur. Und die stirbt nicht aus. Sie wird gerade erst richtig wichtig.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert unser eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal bleibt ein Hüpfer drin. Das ist dann auch von mir.