KI-Tools erfinden das Rad täglich neu

Ein Gedankenexperiment: Stell dir einen Handwerker vor. Jeden Morgen betritt er seine Werkstatt. Er schaut sich um, als wäre er noch nie hier gewesen. Er prüft, ob es Holz gibt. Er prüft, ob es Nägel gibt. Dann baut er sich eine Säge. Er sägt ein Brett. Nächster Morgen? Dasselbe Ritual. Die Säge von gestern? Weg.

Absurd? Genau so arbeiten die intelligentesten KI-Coding-Tools der Welt.

Das Murmeltier-Problem

Ich beobachte das seit Monaten bei jedem großen KI-Coding-Tool — Claude Code, OpenAI Codex, Cursor, Windsurf, Aider. Das Muster ist immer dasselbe.

Session startet. Der KI-Agent orientiert sich. ls — was ist hier? cat — was steht in dieser Datei? grep — wo ist der relevante Code? Er liest seine Umgebung wie ein Amnesie-Patient, der jeden Morgen aufwacht und keine Ahnung hat, wo er ist.

Dann schreibt er ein Skript. Ein kleines Python-Programm. Wegwerfware. Er führt es aus, liefert das Ergebnis, und das Skript verschwindet im digitalen Müll.

Nächste Anfrage, nächste Session: Dasselbe Ritual von vorne. Dieselben Bash-Befehle, dieselbe Orientierungsphase, dasselbe Wegwerf-Skript — nur mit leicht anderen Variablen diesmal.

Was hier fehlt, ist so offensichtlich, dass es fast wehtut: Wiederverwendung.

Jeder Junior-Entwickler lernt das in seiner ersten Woche: Wenn du etwas zweimal brauchst, mach eine Funktion daraus. Wenn du es zehnmal brauchst, mach ein Modul daraus. Wenn du es hundertmal brauchst, mach eine Bibliothek daraus.

Die angeblich intelligentesten Code-Generatoren des Planeten haben dieses Prinzip nicht verinnerlicht.

Was eigentlich passieren sollte

Stellen wir uns einen KI-Agenten vor, der arbeitet wie ein erfahrener Entwickler — sagen wir, einer mit 30 Jahren Berufserfahrung. Was würde er anders machen?

Er würde einen Werkzeugkasten pflegen. Das erste Mal, wenn er eine CSV-Datei parsen muss, schreibt er ein solides Parse-Tool. Parametrisiert. Getestet. Mit Fehlerbehandlung. Das zweite Mal nimmt er es aus dem Regal, passt die Parameter an, fertig.

Er würde Anwendungsstrukturen aufbauen. Keine losen Skripte in /tmp/, sondern ein organisiertes Projekt. /tools/, /utils/, /templates/ — eine wachsende, versionierte Toolchain, die mit jedem gelösten Problem reicher wird.

Er würde aus Fehlern lernen. Hat das Parse-Tool bei einer bestimmten CSV-Variante versagt? Fixen, Version hochzählen, weitermachen. Nicht morgen dasselbe Skript von null schreiben und wieder denselben Bug treffen.

Er würde sein Domänenwissen kodifizieren. Die KI hat enormes Wissen über Programmiersprachen, Frameworks, Best Practices. Aber statt dieses Wissen in stabile, wiederverwendbare Tools zu destillieren, streut sie es jedes Mal aufs Neue in Wegwerf-Code.

Das klingt so selbstverständlich, dass man sich fragen muss: Warum passiert es nicht?

Drei Gründe — und einer davon ist unbequem

1. Das Context-Window-Problem (der technische Grund)

Large Language Models haben ein begrenztes Arbeitsgedächtnis. Alles, was der Agent weiß, muss in sein Context Window passen — eine Art Kurzzeitgedächtnis von typischerweise 128.000 bis 200.000 Tokens. Was nicht drin ist, existiert nicht.

Das bedeutet: Der Agent kann sich schlicht nicht an das Skript von gestern erinnern. Niemand reicht es ihm rüber. Es gibt kein persistentes Werkzeugregal, auf das er zugreifen könnte.

Das ist real. Das ist eine technische Einschränkung. Aber es ist keine unlösbare. Man könnte dem Agenten eine Toolchain geben, ein versioniertes Repository seiner eigenen Tools, einen Index, den er abfragen kann. Die Technologie existiert — sie wird nur nicht konsequent eingesetzt.

2. Das Vertrauensproblem (der vorsichtige Grund)

Wenn ein Agent auf selbstgebaute Tools zugreift, stellt sich eine berechtigte Frage: Stimmt das Tool noch? Hat sich die Umgebung verändert? Funktioniert der CSV-Parser von letzter Woche noch mit dem neuen Datenformat?

Anbieter nehmen lieber den Overhead des Neuschreibens in Kauf, als ein stilles Fehlverhalten durch veraltete Tools zu riskieren. Frisch geschriebener Code ist garantiert auf den aktuellen Kontext zugeschnitten — auch wenn er zu 90% identisch mit dem Code von gestern ist.

Das ist defensiv, aber nicht unvernünftig. Im Software Engineering gibt es eine Faustregel: "Known unknown > unknown unknown." Lieber bewusst neu schreiben als unbewusst auf etwas Veraltetes vertrauen.

Allerdings: Menschen lösen dieses Problem seit Jahrzehnten mit Versionierung, Tests und Dependency Management. Es ist kein ungelöstes Problem. Es wird nur nicht angegangen.

3. Das Token-Problem (der unbequeme Grund)

Und hier wird es unangenehm.

Jeder Bash-Befehl verbrennt Tokens. Jedes ls, jedes cat, jedes frisch geschriebene Skript — das sind Input- und Output-Tokens. Tokens sind die Währung der KI-Industrie. Mehr Tokens bedeuten mehr Umsatz.

Ein Agent, der effizient arbeitet — der sein Tool aus dem Regal nimmt, einen Parameter anpasst und in drei Tokens fertig ist — wäre eine wirtschaftliche Katastrophe für den Anbieter. Der aktuelle Agent, der sich erst orientiert (500 Tokens), dann ein Skript schreibt (2.000 Tokens), es ausführt (500 Tokens) und das Ergebnis interpretiert (500 Tokens), ist ein Token-Multiplikator.

Ich behaupte nicht, dass Anbieter dieses System absichtlich so gebaut haben, um Tokens zu verbrennen. Aber ich behaupte, dass es keinen starken wirtschaftlichen Anreiz gibt, es zu ändern.

Was es gibt — und warum es nicht reicht

Es gibt Ansätze. Anthropics Model Context Protocol (MCP) ist im Kern genau die richtige Idee: standardisierte, wiederverwendbare Tool-Schnittstellen, die der Agent nutzen kann, ohne sie jedes Mal neu zu bauen. Ein "Werkzeugregal-Protokoll", wenn man so will.

Sogenannte Skills-Systeme gehen in dieselbe Richtung — vorgefertigte Best-Practice-Anleitungen für wiederkehrende Aufgaben. Memory-Systeme versuchen, dem Agenten ein Langzeitgedächtnis zu geben.

Aber keiner der großen Anbieter hat den konsequenten Schritt gemacht: Dem Agenten zu erlauben, seine eigene wachsende Toolchain zu pflegen. Eine Sammlung selbstgebauter, getesteter, versionierter Tools, die er bei Bedarf abruft und anpasst.

Stattdessen bekommen wir: Zustandslose Agenten mit Amnesie, die jede Session das Rad neu erfinden und dabei eine beeindruckende Menge Tokens verbrennen.

Der Elefant im Raum

Die KI-Industrie verkauft uns "intelligente" Coding-Assistenten, die an der fundamentalsten Ingenieurtugend scheitern: Effizienz durch Wiederverwendung.

Es ist, als würde Toyota seine Autos am Fließband bauen, aber die Werkzeuge, die zum Bau jedes Autos nötig sind, jedes Mal von Grund auf neu erfinden. Kein Autobauer würde so arbeiten. Kein erfahrener Softwareentwickler würde so arbeiten. Aber die angeblich fortschrittlichsten Code-Generatoren der Welt tun genau das.

Die Lösung ist nicht kompliziert. Sie erfordert keine Durchbrüche in der KI-Forschung. Sie erfordert nur die konsequente Anwendung von Prinzipien, die jeder IT-Fachmann seit den 1970er-Jahren kennt:

• Modularisierung statt Wegwerf-Skripte
• Persistente Toolchains statt zustandsloser Amnesie
• Versionierung statt Neuschreiben
• Parametrisierung statt Hardcoding
• Wachsende Werkzeugkästen statt täglichem Murmeltier-Tag

Die Frage ist nicht, ob es besser geht. Die Frage ist, warum es nicht besser gemacht wird.

Und es gibt nur zwei mögliche Antworten: Entweder haben die Anbieter das Problem nicht erkannt. Oder sie haben keinen Anreiz, es zu lösen.

Beides wäre bedenklich.