Also, probier es aus: Tipp in irgendeinen Agenten „mach mir mal eine super Kontaktverwaltung". Fünf Minuten später hast du etwas, das grossartig aussieht. Eine Liste, eine Suche, ein Formular, ein Export, hübsche Farben, alles responsive. Zeig das einem Entscheider, und er sagt: Warum hat das bei uns drei Monate gedauert? Ich arbeite jeden Tag mit diesen Werkzeugen, und ich will nicht, dass jemand den falschen Schluss daraus zieht. Was du in den fünf Minuten bekommst, ist nicht das System. Es ist ein Foto davon, wie die meisten Kontaktverwaltungen im Netz aussehen.
Der Satz
„Super Kontaktverwaltung" sagt nichts. Für wen? Für einen Verkäufer mit fünfzig Kunden oder für eine Firma mit zwanzigtausend, die in drei Systemen liegen? Mit welchem CRM muss sie reden? Was passiert, wenn zwei Leute denselben Kontakt gleichzeitig ändern? Wer darf was sehen? Was ist mit dem Datenschutz, wenn jemand gelöscht werden will? Und vor allem: Welcher Prozess läuft hier eigentlich, vom ersten Anruf bis zur Rechnung?
Der Agent fragt das nicht. Er kann es nicht fragen, weil er nicht weiss, dass es diese Fragen gibt. Er nimmt den Satz und baut das, was zu diesem Satz am wahrscheinlichsten passt. Und das Wahrscheinlichste ist, was er am häufigsten gesehen hat.
Was man bekommt: die Oberfläche
Was man bekommt, ist eine Oberfläche. Im doppelten Sinn: ein Bildschirm, der gut aussieht, und eine Lösung, die nicht tiefer geht als dieser Bildschirm. Die Liste ist da, aber die Daten liegen in einer Tabelle, die mit dem bestehenden CRM nichts zu tun hat. Die Suche funktioniert, auf tausend Einträgen, nicht auf zwanzigtausend mit Dubletten in drei Schreibweisen. Das Formular speichert, aber es gibt keinen Prozess dahinter: kein „wer hat das angelegt, wer muss es freigeben, was passiert danach". Es suggeriert ein fertiges Produkt. Es ist eine Demo, die sich als Produkt verkleidet.
Der Durchschnitt von allem, was gut gefunden wurde
Woher kommt das, was der Agent baut? Aus dem, was er gelernt hat, und das ist das Netz. Tausende Kontaktverwaltungen, Tutorials, Vorlagen, Beispielprojekte. Das Modell hat daraus gelernt, was eine Kontaktverwaltung typischerweise hat, und baut den Mix der besten gefundenen Lösungen. Ich sage es als Bild, nicht als Messung: Du bekommst, was im Netz zu über achtzig Prozent als gut gilt. Den Durchschnitt des Gelungenen.
Das ist für vieles genau richtig. Für ein Login, ein Formular, einen Export will ich den Durchschnitt des Gelungenen, dafür muss niemand mehr nachdenken. Aber es ist per Definition keine Innovation. Es ist nicht der Prozess, den deine Firma braucht und keine andere. Es ist nicht das Ende-zu-Ende-Denken, bei dem jemand fragt, was vor der Kontaktverwaltung passiert und was danach, und ob man die Verwaltung überhaupt braucht, wenn man den Prozess anders schneidet. Innovation ist, was noch nicht tausendmal im Netz steht. Genau das kann das Modell nicht aus dem Satz holen, weil es nicht im Satz steht und nicht im Netz.
Gute Software beginnt mit Architektur
Softwareentwicklung war noch nie nur Code schreiben. Wer über Jahre Unternehmensanwendungen gebaut hat, weiss, dass der Aufwand selten in der Implementierung liegt. Er liegt darin, fachliche Anforderungen zu verstehen und daraus eine Architektur zu machen, die zuverlässig läuft, sicher ist und sich über Jahre weiterentwickeln lässt.
Eine Anwendung ist keine Sammlung von Funktionen und Klassen. Welche fachlichen Domänen gibt es, wo sind ihre Grenzen, wie reden die Komponenten miteinander? Welche Patterns passen, welche Abhängigkeiten dürfen entstehen? Wann synchron, wann asynchron? Wie gehen wir mit Transaktionen, Fehlern, Datenkonsistenz um? Und über alle Grenzen hinweg: Wie funktionieren Authentifizierung, Autorisierung, sicherer Datenaustausch? Dazu die Modularisierung: klar abgegrenzte Module mit definierten Verantwortlichkeiten, so dass eine Änderung in einem Modul möglichst wenig im Rest bewegt. Das klingt selbstverständlich. In der Praxis ist es das Schwierigste am ganzen Beruf.
Die hundertste Änderung ist der Test
Ein System zu bauen ist eine Sache. Es über Jahre zu warten und ständig zu erweitern eine ganz andere. Wie schnell lässt sich eine neue Funktion integrieren? Müssen dafür fünf andere Komponenten angefasst werden? Entstehen neue Abhängigkeiten? Besteht das Risiko, etwas anderes zu beschädigen? In einer sauber geschnittenen Architektur sind die meisten Erweiterungen gezielt und überschaubar. In einer schlecht strukturierten wird irgendwann jede kleine Änderung ein Projekt.
Die KI kennt die Patterns. Hält sie sich daran?
Moderne Modelle kennen praktisch alle Architekturkonzepte. Sie können Domain-Driven Design erklären, Microservices entwerfen, Patterns anwenden. Das ist beeindruckend. Aber ein Konzept zu kennen und es über die ganze Lebensdauer eines Systems konsequent einzuhalten, sind zwei verschiedene Dinge.
Ein Agent kann eine Funktion korrekt implementieren und dabei die Architektur beschädigen. Er legt eine direkte Abhängigkeit zwischen zwei Domänen an, die nur über eine Schnittstelle reden sollten. Er dupliziert eine Funktion, die es schon gibt, weil er sie in seinem Ausschnitt nicht sieht. Er baut eine Lösung, die funktioniert und dabei eine Sicherheitsregel umgeht. Das Gefährliche daran: Es fällt nicht auf. Die Anwendung läuft, die Tests sind grün, die Funktion ist da. Erst bei der nächsten Erweiterung merkt man, dass das System unnötig kompliziert geworden ist. Ich habe das bei den Riesenklassen beschrieben, und ich habe es vor einer Woche live gesehen, als ein Agent 169 Dateien überschrieben hat, weil er liefern wollte.
Das eigentliche Problem: der verlorene Kontext
Hier liegt für mich die grösste Schwäche der heutigen Werkzeuge. Ein Agent arbeitet mit dem, was er gerade sieht. Solange er die Zusammenhänge kennt, liefert er sehr gute Ergebnisse. Aber ein Unternehmenssystem besteht aus weit mehr als dem Code, den er gerade analysiert: fachliche Regeln, Architekturentscheidungen, historische Abhängigkeiten, Sicherheitskonzepte, Integrationen mit anderen Systemen. Vieles davon ist nicht dokumentiert und steht nicht im Code.
Dazu kommt, dass Agenten ihren Kontext nicht unbegrenzt behalten. Informationen werden zusammengefasst, verdrängt, sind in der nächsten Sitzung weg. Der Agent weiss dann nicht mehr, warum zwei Domänen strikt getrennt wurden. Er baut eine Lösung, die für seine Aufgabe sinnvoll aussieht und dem Gesamtkonzept widerspricht. Mit jeder Änderung kommen Abhängigkeiten, Duplikate, strukturelle Probleme dazu. So produziert KI technische Schulden, ohne dass man es merkt, und zwar schneller, als Menschen es je konnten. Ein grosses Kontextfenster löst das nicht. Das Wissen muss ausserhalb des Fensters leben.
Erst verstehen, dann verändern
Ich bin überzeugt, dass Agenten künftig ganze Arbeitspakete übernehmen, von der Analyse über die Implementierung bis zu Tests und Dokumentation. Damit das zuverlässig funktioniert, muss man anders vorgehen. Es reicht nicht, einem Agenten ein Repository zu geben und zu sagen, bau das ein. Und es reicht erst recht nicht, ihm einen Satz zu geben und auf die Screens zu schauen.
Zuerst das Wissen aufbauen. Welche Domänen und Module gibt es? Wie hängen sie zusammen? Welche Schnittstellen dürfen verwendet werden? Welche Entscheidungen gelten, welche Sicherheitsregeln? Strukturiert, dauerhaft, ausserhalb des Kontextfensters, und bei jeder Änderung nachgeführt.
Dann den Prozess, nicht den Screen. Was passiert vor der Kontaktverwaltung, was danach, wer entscheidet, wer gibt frei, was muss mit welchem System reden. Erst wenn das steht, ist klar, was „super" hier überhaupt heisst, und oft ist es etwas ganz anderes als die Liste mit Suche.
Dann planen, ändern, prüfen. Der Agent plant auf dem Wissen, macht gezielte Änderungen und prüft, ob sie mit der Architektur vereinbar sind. Nicht derselbe Agent, der gebaut hat. Und die Regeln werden geprüft, nicht gewünscht.
Genau das ist der Ansatz bei NeoCoder: nicht, wie KI schneller Code erzeugt, sondern wie Agenten ein bestehendes System verstehen und über Jahre zuverlässig weiterentwickeln. Erst wenn das Wissen über ein System erhalten bleibt und die Architekturregeln überprüfbar sind, trägt die Grundlage für mehr Autonomie. Ohne das wird aus jeder super Kontaktverwaltung in zwei Jahren das System, das niemand mehr anfassen will.
Was bleibt
Natürlich ist es beeindruckend, wenn ein Agent in Minuten baut, wofür ein Entwickler Stunden gebraucht hat. Aber die Ersparnis ist wenig wert, wenn man später ein Vielfaches braucht, um die Abhängigkeiten zu korrigieren, die dabei entstanden sind. Darum sollten wir Produktivität nicht an Codezeilen oder abgeschlossenen Aufgaben messen, sondern an anderen Fragen: Wie schnell lassen sich neue Anforderungen umsetzen? Wie stabil bleibt die Architektur? Wie hoch ist der Wartungsaufwand? Wie entwickeln sich Qualität und Komplexität über die Zeit?
Vor Kurzem habe ich wieder gelesen, wir seien nie dafür bezahlt worden, Code zu schreiben, sondern Probleme zu lösen. Im Kern stimmt das. Aber die eigentliche Leistung ist nicht, für ein Problem eine funktionierende Implementierung zu finden. Sie ist, eine Lösung zu bauen, die sich in ein bestehendes System einfügt, dessen Architektur respektiert und auch in Zukunft einfach zu warten und zu erweitern ist. Die fünf Minuten können das nicht. Nicht, weil das Modell schlecht wäre. Weil niemand ihm gesagt hat, was das System ist, und weil der Satz es nicht enthielt.
„Mach mir mal eine super Kontaktverwaltung" liefert die Oberfläche: schöne Screens, den Durchschnitt von allem, was im Netz gut gefunden wurde, keine Innovation, keinen Prozess. Die entscheidende Frage ist nicht, ob KI heute eine Anwendung bauen kann. Die Frage ist, ob sie diese Anwendung nach hundert Erweiterungen noch sauber, modular, sicher und wartbar hält. Daran müssen wir arbeiten. Denn funktionierender Code ist noch lange keine gute Software.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert ein eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal wird daraus ein Mix. Ich lese natürlich alles nochmal, aber niemand ist unfehlbar. Was drin bleibt, ist dann auch von mir.