Mir wurde neulich ein Schulungsangebot gemacht. Es versprach mir, mit KI ein Softwareprojekt von 15.000 bis 30.000 Euro auf einen Bruchteil zu drücken.
Zwei Dinge sind mir dabei sofort aufgefallen. Erstens ist 15.000 bis 30.000 Euro keine Softwareskala. Das ist eine isolierte App, ein kleines Werkzeug. Es ist nicht das, was in der echten Softwarewelt Kosten und Probleme eskalieren lässt. Zweitens reduziert die Werbung den Preis eines Softwareprojekts auf das Tippen. Tippen ist der kleinste Teil.
Den eigentlichen Preis zahlt man später: bei der Integration, beim Wachsen des Produkts, bei der Wartung. Das ist der Unterschied zwischen Netto und Brutto. Die Werbung zeigt das Netto, also Stunden gespart, Prototyp in Minuten. Das Brutto kommt später.
Tippen ist der kleinste Teil
Wer noch nie ein Stück Software über Jahre begleitet hat, unterschätzt diesen Punkt. Eine neue Software entsteht selten in einem Wurf. Sie wächst. Heute eine Funktion, morgen eine Schnittstelle, im Quartal darauf eine andere Datenbank. Damit das später nicht eskaliert, muss am Anfang viel durchdacht werden, was erst Monate später kommt.
Vor dreißig Jahren hat man dafür den Weg der Agilität entwickelt. Nicht weil das Tippen zu langsam war, sondern weil das Aneinander-vorbei-Reden das Kernproblem ist. Jemand, der keine Software-Brille trägt, beschreibt das, was er will, völlig anders, als ein Entwickler es umsetzen würde. Die KI ändert daran nichts. Sie nimmt die Beschreibung wörtlich, baut etwas, das funktional aussieht, und der Anwender denkt: „So habe ich das nicht gemeint."
Was KI sichtbar verbessert, ist die Geschwindigkeit, mit der ein Prototyp steht. Das ist nützlich. Der Weg zu guter Software, die das erfüllt, was der Anwender wirklich braucht, bleibt davon unberührt.
Architektur ist Diskussion, nicht Beschreibung
Bei kleinen Werkzeugen mag eine Beschreibung reichen. Sobald etwas wachsen oder mit anderen Systemen sprechen muss, wird Softwarearchitektur zur eigenen Disziplin. Und Architektur entsteht selten, indem man kurz beschreibt, was man haben will. Sie entsteht in Diskussionen.
In einem ernsthaften Software-Team sitzen verschiedene Rollen am Tisch. Fachexperten für die Domäne, Architekten für die Struktur, Spezialisten für Datenbanken, Schnittstellen, Sicherheit. Sie spielen viele Anforderungen am Anfang mental durch, legen sie auf den Tisch und wägen sie gegeneinander ab. Da dreht man einige Runden, bevor das Bild solide ist.
Ein einzelner Experte mit KI an seiner Seite kann sich vielfältiger Fragen stellen lassen und kommt schneller zu Ideen. Aber er sitzt allein. Die zweite Meinung, die dritte Perspektive, das Hineindenken aus anderen Fachgebieten fehlt. Bei komplexeren Systemen lässt sich das schwer ersetzen.
Inzwischen versucht man, dieses Zusammenspiel mit KI-Agenten nachzubauen: einer plant die Architektur, andere übernehmen einzelne Programmieraufgaben. Die Frage ist nur: Worauf sollen diese Agenten trainiert worden sein?
Was die KI gelernt hat: Muster, aber kein Gesamtbild
Gerade Enterprise-Software hat eine Eigenschaft, die das Training schwierig macht: Sie ist gewachsen. Eher chaotisch. Irgendwann erreichen viele dieser Systeme einen Zustand, in dem sie kaum noch manövrierbar sind. Das ist selten die Ausnahme, das ist die Regel.
Was an Lernmaterial im Internet vorliegt, ist funktional, oft jedoch unausgearbeitet. Wirklich durchdacht sind nur einzelne, bewusst getroffene kleinere Entscheidungen. Genau das hat sich auch der Entwickler-Alltag der letzten Jahre zunutze gemacht: Problem in Google eintippen, auf Stack Overflow landen, ein Snippet übernehmen, weiterarbeiten. So funktionieren auch viele Teams in der Praxis.
Und so funktioniert auch die generative KI: Sie lernt auf Mustern, sie gibt gelernte Muster gut wieder. Im Kleinen ist das hilfreich. Im Großen wird es schwierig. Gerade Enterprise-Systeme sind als Gesamtsystem hochgradig individuell, auch wenn einzelne wiederkehrende Muster darin stecken.
Wir kennen das aus der Softwareentwicklung seit Jahrzehnten. Design Patterns gibt es seit den Neunzigern. Sie sind notwendig, sie helfen. Und doch macht ihre Existenz aus dem Code, der sie nutzt, noch keine gute Software.
Ich habe selbst eine Zeit lang aus Neugier für Data-Annotation-Plattformen gearbeitet. Also die Arbeit gemacht, die rund um die Transformer-Modelle gebaut wird, damit sie Coding-Aufgaben überhaupt verlässlicher lösen. Dabei wurde sehr deutlich, was generative KI an Leitplanken braucht und wie diese Leitplanken entstehen: durch viele kleine, menschliche Entscheidungen, die wiederum von einer KI bewertet werden.
Wer diese Entscheidungen trifft, bleibt von außen unsichtbar. Welche Kriterien angelegt werden, bleibt unsichtbar. Wenn ich als Architektin eine elegantere, weniger typische Lösung wählte, wurde sie unter Umständen aussortiert, weil sie ins Raster nicht passte. Welches Raster? Steht nirgends. Und genau dieses Raster sitzt später beim Coding mit am Tisch.
Code Review bei einem Kollegen, den man nicht kennt
Angenommen, das alles ist geklärt. Der Architekt hat die Tasks identifiziert, vergibt sie an kleine Programmieragenten und stellt sich vor, wie es dort vor sich hin werkelt. Was er bekommt, muss er prüfen. Code Review.
Ein guter Code Review hängt davon ab, dass man den Kollegen kennt. Wer hat das geschrieben, wo liegen seine Stärken und Schwächen, wie sieht sein Stil aus? Programmieren hat selten nur eine Lösung. Welche Algorithmik entsteht, hängt vom Stil des Entwicklers ab. Wenn man den Kollegen kennt, kann man im Review in seine Gedankenwelt eintauchen und das Stück Code in den Gesamtkontext stellen.
Bei einem KI-Agenten arbeitet jemand im Hintergrund, dessen Modell ständig von anderen nachjustiert wird. Wie gut der Kollege auf der anderen Seite der Leitung gerade arbeitet, lässt sich vorher kaum sagen. Das kostet kognitiven Aufwand: prüfen, wie er heute tickt, prüfen, wie das Ergebnis in das eigene System passt. Und gleichzeitig braucht der Agent eine sehr präzise Beschreibung, damit er das tut, was man wirklich gemeint hat, statt nur das, was man gesagt hat.
Mit Agenten arbeiten heißt mehr nachdenken
Wer mit KI-Agenten ernsthaft arbeitet, denkt vorher mehr nach, nicht weniger. Ich setze mich hin und überlege, welche Tasks ich brauche, definiere sie präzise und schicke die Agenten los. Die Antwort kann länger dauern. Ich weiß aber: Wenn ich zurückkomme, muss ich die Antworten strukturiert durchgehen.
Das ist Rüstzeit im Kopf: Mich wieder ins Thema einarbeiten, den Kontext rekonstruieren, dann der Code Review. Beides ist Arbeit. Während die Agenten laufen, kann ich oft nichts wirklich Anderes anfangen, weil ich den Kontext im Kopf behalten muss. Bei vielen Werkzeugen sehe ich nur einen Fortschrittsbalken oder eine Drehscheibe und weiß nie genau, wann das Ergebnis kommt.
Das alles ist machbar. Aber es ist etwas anderes als das, was die Werbung verspricht. Die Versprechen vergleichen die Sekunden zum Tippen, nicht die Stunden zum Durchdenken, Spezifizieren und Reviewen.
Wo das Brutto wirklich steht
Eine randomisiert kontrollierte Studie aus dem Jahr 2025 hat den Effekt beziffert. Das US-amerikanische Institut METR ließ 16 erfahrene Open-Source-Entwickler 246 echte Aufgaben in ihren eigenen Codebasen bearbeiten. Per Zufall wurde entschieden, ob KI-Tools (vor allem Cursor Pro mit Claude 3.5/3.7 Sonnet) erlaubt waren oder nicht. Vorher hatten die Entwickler erwartet, mit KI 24 Prozent schneller zu sein.
Eine einzelne Studie ist kein Endurteil, ihre Methodik ist allerdings die strengste, die in diesem Feld bisher verfügbar ist. Und der Befund deckt sich mit dem, was im Maschinenraum spürbar ist: Zwischen dem, was sich nach Beschleunigung anfühlt, und dem, was tatsächlich gespart wurde, liegt eine breite Zone. In dieser Zone steht das Brutto.
Es steht in der Spezifikation, die der Agent braucht. Im Code Review eines unbekannten Kollegen. In der Nacharbeit an Code, der zwar funktioniert, aber selten wirklich durchdacht ist. In der Wartung von Systemen, deren tragende Entscheidungen niemand mehr nachvollziehen kann.
Das ist keine Aussage gegen KI. Sie ist im Maschinenraum angekommen und ein gutes Werkzeug für viele Schritte. Was bei ihrem Einsatz weiterhin Sache des Menschen bleibt: das Denken davor, das Abwägen mittendrin und die Verantwortung danach.
Wer den Einsatz von KI ernsthaft kalkuliert, rechnet das ein. Wer auf den Schulungs-Pitch hereinfällt, der zeigt, wie das 15.000-Euro-Projekt zum Bruchteil wird, hat das eigentliche Spiel übersehen. Es geht nicht um das kleine Projekt, das Sie schon vorher kannten. Es geht darum, wie viel Sie wirklich brauchen, wenn die Software wachsen soll.