Wenn die KI programmiert, wozu brauche ich noch Entwickler? Warum das Einbinden eines LLM kein Coding-Problem ist.
Diese Frage stellen sich heute viele Entscheider, und sie ist berechtigt. Also gehen wir sie ehrlich durch, ohne das reflexhafte „ersetzt alle" und ohne das genauso reflexhafte „ändert nichts". Beides stimmt nicht.
Besserer Code. Zugegeben.
Das unterschreibe ich sofort: Ein KI-Agent, selbst mit einem kleinen, lokal gehosteten Modell, liefert saubereren Code, als ich ihn mit 25 Jahren Erfahrung schreiben würde. Er kennt jeden Befehl, weiß genau, was er tut, kennt alle Patterns und hat mit Milliarden Parametern das Wissen, das elegant in Code zu gießen. Sicher, der Prompt muss passen, der Agent muss die Aufgabe verstehen und sie darf seine Fähigkeit zu abstrahieren nicht übersteigen. Abhängig vom Modell. Aber sonst: Die Agents liefern. Was früher Stunden oder Tage gedauert hat, dauert jetzt Minuten. Faktor 100 ist vermutlich noch zu niedrig gegriffen.
Das wird die Produktion von Software massiv vereinfachen. Stundenlanges Runtertippen von Standardaufgaben gehört der Vergangenheit an. Nur: Damit das, was der Agent produziert, am Ende auch brauchbar und gut ist, braucht es eine ganze Reihe anderer Fähigkeiten und die bringt (noch) kein Modell mit.
Die eine Stelle, wo es hapert: LLMs einbinden
Es gibt ein neues Feld in der Programmierung, und genau dort stoßen die Agenten aktuell an ihre Grenzen: Das Einbinden von LLMs in Programme und Prozesse. Denn der Output eines LLM ist diffus. Kann es das gewählte Modell? Ist es der Prompt? Woran scheitert es? Ohne die richtigen Anweisungen drehen sich viele Agenten hier im Kreis.
Und es hängt Geld dran. Braucht ein Prozess ein LLM, ist das schlicht ein ökonomischer Faktor: Was kostet das Modell? Kann ein kleineres Modell die Aufgabe abbilden, kostet es einen Bruchteil eines Top-Modells. Man liest inzwischen fast täglich, dass Tokenkosten in Firmen zum Problem werden. Mitarbeiter verbrauchen schon beim Entwickeln zu viele Token. Kommt die laufende Anwendung obendrauf, ist die Abrechnung fett. Das will keiner. Und da macht es einen Unterschied, ob jemand zielgerichtet ein Ergebnis holt, oder den Agenten stundenlang im Kreis schickt.
Warum das so ist: Es gibt kein „grün"
Ein Coding-Agent ist brillant, wo es ein prüfbares Richtig gibt: ja oder nein; Test grün oder rot. Er iteriert gegen dieses Signal, bis es passt. E
in LLM in einer Anwendung liefert dieses Signal nicht: Es ist nicht-deterministisch (gleicher Input, anderes Ergebnis), es ist statistisch (läuft auf 92 Prozent und stirbt auf den 8, die man nicht getestet hat), und wenn es scheitert, dann nicht mit einem Crash, sondern mit einer plausiblen falschen Antwort. Kein Stacktrace, gegen den man iterieren könnte. An genau dieser Stelle ist der Agent so blind wie jemand, der nur herumprobiert. Dinge, die einen Entwickler zur Verzweiflung bringen können.
Und jetzt das Kontraintuitive: Genau das, was ein LLM so schwer beherrschbar macht, ist auch seine eigentliche Stärke. Es macht Vorschläge, wo noch Lücken sind. Es benennt Dinge so, dass sie auch jemand ohne Fachkenntnis versteht. Diese Offenheit ist der Wert und sie zu bändigen ist die Arbeit. Dass am Ende verlässlich brauchbare Ergebnisse herauskommen, dafür braucht es einen erfahrenen Entwickler: Einen, der versteht, wie ein LLM funktioniert, was das Modell kann, wie man es korrekt anspricht und wo es ausfranst. Und das ist, das ist mir wichtig, vor allem klassisches Engineering-Wissen, nicht Detailwissen über ein bestimmtes Modell. Ein Mensch entwickelt schnell ein Gefühl, wenn er mit der Materie arbeitet. Genau das macht aus einem guten einen fähigen Entwickler.
Testen vs. Probieren
Woran erkennt man schnell, ob jemand mit einem Agenten wirklich entwickelt oder fachfremd herumbastelt?
· Probieren heißt: den Happy Path laufen lassen, es sieht gut aus, passt.
· Testen heißt: es brechen wollen, gegen ein Soll prüfen.
Der Unerfahrene probiert das Ergebnis aus. Der Entwickler geht mit der Brechstange ran und schaut, ob die Anwendung hält. Der Haken dabei: Testen ist durch Kompetenz gedeckelt. Du kannst nur gegen ein Korrektheitsmodell testen, das du schon im Kopf hast. Der Unerfahrene probiert nicht aus Faulheit, Probieren ist das Einzige, was ihm ohne dieses Wissen überhaupt bleibt.
Modell oder Prompt? Diagnose ohne Fehlermeldung
Sobald ein LLM in einer Anwendung steckt, gibt es bei Problemen immer mehrere Verdächtige und der erste lautet: Liegt es am Modell oder am Prompt? Der Agent tut sich schwer, das zu unterscheiden. Er probiert ewig am Prompt herum, will alles über den Prompt lösen. Dann greift man ein: „Nimm mal dieses Modell, und pass den Prompt so an." Und siehe da: es funktioniert. Oft. Nicht immer. Aber oft genug, dass der Entwickler den Unterschied macht.
Nur: Die Modellwahl muss so getroffen sein, dass auch ein späterer Wechsel in ähnlicher Größenordnung noch trägt. Auch das ist Erfahrung und kein Agent bringt sie mit.
Schwache Modelle: Das Netz spannen
Oft kommen gleich die dicken Brummer zum Einsatz. Das Frontier-Modell wird gewählt, weil es auch schlechte Prompts und zu große Aufgaben noch sauber wegbügelt. Frontier deckt die Sünden zu. Sicher, die heutigen Frontier-Fähigkeiten sind in ein paar Monaten in den unteren Klassen angekommen. Aber sauber ist das nicht.
Lernt man dagegen mit einem 35B-Modell die Grenzen im Detail kennen, baut man die Anwendung robuster, performanter und zu einem Bruchteil der Kosten. Der größte Sündenfall ist ohnehin, sich auf das Trainingswissen des Modells zu verlassen. Die großen Modelle wissen unfassbar viel, trotzdem ist es mir lieber, kritische Informationen kommen aus einer API oder einem RAG und werden im Prompt verarbeitet (Single Source of Truth). Modelle werden in der Regel nicht nachtrainiert. Wissen veraltet und wechselt man das Modell: Hat das neue noch dasselbe Wissen? Ich möchte mir gar nicht ausmalen, wie man Tests baut, die das Trainingswissen eines neuen Modells verlässlich abfragen.
Genau dafür habe ich mir Brain gebaut, eine Wissensschicht, die dem Modell die Fakten zur Fragezeit in den Prompt legt, statt sich auf sein Gedächtnis zu verlassen. Der Effekt: Ein 35B mit Brain wird richtig intelligent, weil es aus der Wissensbasis zitiert statt zu halluzinieren. Das ist kein Trick, das ist die Arbeit, die aus einem schwachen Modell ein verlässliches Werkzeug macht. Und es ist Arbeit, die man nur leistet, wenn man weiß, wo das Modell allein kippt.
Der Stolperdraht: Tests, die etwas taugen
Was der Agent auch nicht von selbst sauber baut, sind die richtigen Tests. Wo sagt er dir, dass die Sache mit deinem LLM bricht? Wo sind die Grenzen? Wie müssen Tests aussehen, damit eine Promptänderung sofort auffällt, wenn plötzlich etwas nicht mehr stimmt? Ohne klare Ansage entstehen hier die großen Lücken. Dann hat man schnell ein Projekt, das keiner mehr anfassen will, weil jedes neue Feature zwei, drei andere kaputtmacht. Umsetzen kann der Agent solche Tests hervorragend. Nur: von sich aus baut er sie nicht, und beim nächsten agilen Schritt vergisst er sie wieder. Der Stolperdraht muss von jemandem gespannt werden, der weiß, wo man stolpert.
Der Agent kennt nur die aktuelle Frage
Und dann ist da die Architektur. Es braucht erfahrene Leute, die schon vor der ersten von zig agilen Schleifen wissen, wie man etwas baut, das später noch hält, wenn Feature um Feature draufkommt. Woher soll der Agent das wissen? Er bekommt immer nur den Prompt für genau das, was jetzt zu tun ist. Er weiß nicht, wohin die Reise geht. Er macht gute Vorschläge – aber nur auf die Fragen, die man stellt. Eine Frage nicht gestellt, keine Antwort. Es gibt (noch) keinen Coding-Agenten, der sich von sich aus meldet und sagt: „Pass auf, hier sollten wir vorher noch …" Diese Voraussicht muss der Mensch mitbringen.
Die ehrliche Grenze
Damit man mich nicht falsch versteht: Das heißt nicht „Agenten können das nie". Die mechanischen Teile werden sie zunehmend übernehmen, die Test-Harness bauen, sobald die Metrik steht. Was menschlich bleibt, ist das Definieren: Was heißt „gut genug"? Was traue ich dem Modell zu? Welche Fehlerrate trägt mein Geschäft? Das sind Risiko- und Domänenentscheidungen, keine Coding-Aufgaben. Und der Wert liegt im kalibrierten Eingreifen, nicht im Dauerbremsen: Zu wissen, wann man stoppt und wann man das Ding einfach laufen lässt, ist selbst schon Urteil.
Was heißt das für den Entscheider?
Die schöne neue Welt heißt Turbo. Für einen Entwickler, der immer schon eher Architektur und Rahmen gesetzt hat, ist ein Coding-Agent mehr als das, das Tempo beschleunigt sich unfassbar, die Möglichkeiten explodieren, das Limit ist nur noch das Abo. Aber wehe, man kann damit nicht umgehen: Dann wird auch jede Menge Mist produziert. Wir werden in den nächsten Jahren Anwendungen sehen, die von Unerfahrenen gebaut wurden und in denen sich im Detail richtig schlimme Böcke verstecken.
Die Antwort auf „wozu brauche ich noch Entwickler" ist deshalb nicht „gar keine mehr" und auch nicht „genauso viele wie bisher". Sie ist: weniger, bessere, und andere. Weniger Code mehr Prompts tippen, mehr Urteil, Architektur, Review. Die knappe Ressource ist nicht mehr die Codingarbeit, es ist das Urteil. Und dieses Urteil regiert jetzt den zehnfachen Output.
Die eigentliche Lektion
Der Agent schreibt den Code. Die Unsicherheit verwaltet er nicht. Und ein LLM in ein Produkt einzubinden ist zu großen Teilen genau das: Unsicherheit verwalten. Das ist Erfahrung, kein Werkzeug.
smartllm und readableAudit sind mit einem Coding-Agenten gebaut, er war essenziell. Dass daraus echte Systeme geworden sind und keine Mogelpackungen, liegt nicht am Werkzeug. Es liegt an der Führung. Gleiches Werkzeug, anderer Führer, anderes Ergebnis.