Technischer Kontext
Ich liebe AI-Automatisierung in der Entwicklung, aber bei dem Text von Mario Zechner vom 25. März habe ich zu schnell genickt. Er beschrieb etwas, das ich selbst in agentenbasierten Pipelines sehe: Code wird so schnell generiert, dass die Wartung von Anfang an nicht mithalten kann.
Kurz gesagt, Agenten können zehntausende Zeilen in Stunden produzieren, und dann beginnt der eigentliche Spaß: duplizierte Logik, übersehene Teile des bestehenden Codes, asynchrone Schnittstellen, seltsame Workarounds auf alten Fehlern. Das sind keine "normalen technischen Schulden". Es ist eine neue Form von Schulden, bei der die Komplexität schneller wächst, als aktuelle LLMs sie überhaupt entwirren können.
Besonders nachvollziehbar finde ich seinen Gedanken über die fehlende menschliche Bremse. Ein Mensch wird müde, stolpert, liest noch einmal, spürt den Schmerz einer schlechten Architektur und verlangsamt normalerweise das Tempo. Ein Agent fühlt keinen Schmerz. Er denkt nicht: "Moment mal, sind wir sicher, dass wir noch einen weiteren Service, eine weitere Abstraktionsschicht, einen weiteren Helper brauchen?"
Und genau hier scheitert der naive Ansatz "zuerst generieren, dann refaktorisieren". Bei kleinen Aufgaben funktioniert er noch. Aber auf lange Sicht lässt agentenbasiertes Coding ein Projekt sehr schnell wie Legacy-Code aussehen, den selbst ein gutes LLM nicht mehr als Ganzes erfassen kann und stattdessen in Fragmenten repariert, wobei manchmal benachbarte Teile beschädigt werden.
Im Grunde sagt Mario etwas Einfaches: Die Architektur, die APIs und die allgemeine Form des Systems dürfen nicht gedankenlos dem Autopiloten überlassen werden. Ich würde es noch schärfer formulieren: Wenn Sie keine klaren Modulgrenzen, kurze Review-Zyklen und ein Limit für den Umfang von agentengenerierten Änderungen haben, beschleunigen Sie nicht die Entwicklung. Sie beschleunigen nur das Chaos.
Auswirkungen auf Geschäft und Automatisierung
Für Unternehmen ist die Schlussfolgerung sehr bodenständig. Es gewinnen die Teams, die Agenten als Verstärker in engen Grenzen einsetzen: Generierung von Tests, CRUD-Schichten, Migrationen, interne Dienstprogramme, Dokumentation. Verlieren werden diejenigen, die versuchen, ein Produkt direkt durch Agenten "wachsen zu lassen", ohne eine strikte KI-Architektur.
Den zweiten Effekt sehe ich bei den Betriebskosten. Günstige Codegenerierung heute verwandelt sich leicht in teure Wartung einen Monat später, wenn jede Änderung beginnt, benachbarte Teile des Systems zum Absturz zu bringen.
Daher sieht eine normale Integration von künstlicher Intelligenz in die Entwicklung jetzt langweiliger, aber reifer aus: kleine Änderungen, menschliche Kontrolle über die Architektur, Geschwindigkeitsbegrenzungen, obligatorische Quality Gates. Wir bei Nahornyi AI Lab lösen für Kunden genau diese Aufgabe: nicht nur einen Agenten anzuschließen, sondern die Entwicklung von KI-Lösungen so zu gestalten, dass die Automatisierung keine neue Klasse von Problemen schafft.
Wenn Sie bereits ein Team haben, das sich mit Agenten "beschleunigt" hat, würde ich mir sofort den Umfang der Änderungen, die Qualität der Modulgrenzen und die Kosten jeder nächsten Anpassung ansehen. Wenn Sie das Gefühl haben, dass die Codebasis Ihnen aus den Händen gleitet, können wir dies bei Nahornyi AI Lab in Ruhe gemeinsam analysieren und die AI-Automatisierung so aufbauen, dass sie wirklich Zeit spart und nicht das Budget in zukünftige Reparaturen umwandelt.