Viele behaupten, dass KI die Softwareentwicklung deutlich günstiger machen wird. Sie stellen sich vor, dass Modelle Ingenieure ersetzen und Aufgaben erledigen

Viele behaupten, dass KI die Softwareentwicklung wesentlich günstiger machen wird. Sie stellen sich vor, wie Modelle Ingenieure ersetzen und Aufgaben in Minuten erledigen. Diese Erzählung ist verlockend, aber nicht ganz wahr. Die Ökonomie der Softwareentwicklung hat sich verschoben, nicht aufgelöst. Technische Schulden sind nicht verdampft, als der erste Coding-Assistent auf den Markt kam. Wir haben lediglich einen neuen Weg gefunden, sie zu finanzieren.

Die alte Rechnung: Mitarbeiterzahl

Jahrzehntelang erzeugten technische Schulden eine vertraute Abwärtsspirale. Eine Codebasis wurde spröde. Features, die einst Tage dauerten, beanspruchten plötzlich Wochen. Fristen wurden gerissen, woraufhin das Management weitere Stellen ausschrieb. Größere Teams verlangsamten die Prozesse weiter. Der Koordinationsaufwand blähte sich auf, Stand-ups häuften sich an, und das Conway-Gesetz trat in Kraft: Die Software begann, die Kommunikationsprobleme der Menschen widerzuspiegeln, die sie entwickelten. Mehr Bugs schlichen sich ein. Jeder Patch fügte neue Komplexitätsebenen hinzu. Unternehmen bezahlten diesen Verfall mit der einzigen Währung, die sie kannten: Personalkosten. Die Kosten waren offensichtlich. Sie traten bei jeder vierteljährlichen Budgetprüfung deutlich zutage.

Die neue Rechnung: Tokens und Kontext

Generative KI hat diesen Kreislauf nicht durchbrochen. Sie hat lediglich einen alternativen Zahlungsplan eingeführt. Anstatt fünf Ingenieure einzustellen, um die Reibungsverluste zu überwinden, lässt ein Unternehmen nun eine Kreditkarte für mehr Rechenleistung glühen. Die Symptome sehen anders aus, aber die zugrunde liegende Krankheit ist dieselbe.

Wenn ein Modell zu versagen beginnt – interne APIs halluziniert, kritische Edge-Cases übersieht oder Tests generiert, die aus den falschen Gründen bestehen – ist der Reflex selten ein Refactoring. Der Reflex ist es, Geld für Inferenz auszugeben. Teams kaufen Upgrades für das Kontextfenster, basteln Multi-Agenten-Retry-Loops zusammen, verlagern Workloads auf größere Frontier-Modelle oder drücken immer wieder auf den Regenerieren-Button, bis der Diff akzeptabel aussieht. Diese Taktiken erhalten die scheinbare Geschwindigkeit für ein oder zwei Sprints. Das Jira-Board bleibt grün. In der Zwischenzeit bleibt die eigentliche Architektur unberührt: dieselben verstrickten Abhängigkeiten, derselbe veränderliche globale Zustand, derselbe Monolith, den niemand im aktuellen Team vollständig versteht.

Warum unsauberer Code Tokens kostet

Große Sprachmodelle können am besten auf Basis sauberer Abstraktionen schlussfolgern. Die meisten Enterprise-Repositories sind jedoch archäologische Ausgrabungsstätten. Sie enthalten zirkuläre Paketabhängigkeiten, versteckte Seiteneffekte in Initialisierungs-Skripten und Geschäftslogik, die über Datenbank-Trigger, Middleware-Schichten und Front-End-Komponenten verteilt ist. In einer solchen Umgebung verbraucht das Modell seine Energie nicht für das Schreiben neuer Logik. Es verbrennt Tokens für das Verständnis.

Ein erheblicher Teil eines 128.000-Token-Kontextfensters kann allein dafür verbraucht werden, die Struktur des Systems im Speicher zu halten. Der verbleibende Bruchteil ist das, was für die eigentliche Problemlösung übrig bleibt. Es ist, als würde man einen Bauingenieur bitten, ein neues Stockwerk zu entwerfen, während man ihn zwingt, vor jeder Berechnung die Blaupausen des bestehenden Gebäudes aus dem Gedächtnis neu zu zeichnen. Das Ergebnis sind oberflächliche Lösungen. Das Modell spiegelt das Chaos wider, das es sieht, weil ihm die Befugnis oder der architektonische Kontext fehlt, zuerst aufzuräumen.

Schnellerer Output, langsamere Auslieferung

Die reine Generierungsgeschwindigkeit überträgt sich nicht auf die Release-Geschwindigkeit. Wenn Ihrer Architektur die Modularität fehlt, erfordert jede KI-generierte Änderung eine erschöpfende menschliche Überprüfung und Regressionstests. Ein Modell kann an einem Nachmittag zehn Pull Requests erstellen, aber diese Pull Requests müssen dennoch Integrationsumgebungen, Security-Scanner, Compliance-Checklisten und Production-Canaries durchlaufen. Ohne klare Modulgrenzen führt KI Bugs mit Maschinengeschwindigkeit ein. Sie kann eine gemeinsam genutzte Utility modifizieren, drei entfernte Aufrufstellen mit subtil falschen Annahmen aktualisieren und Race Conditions einführen, die Menschen erst bei einem Alarm um 3 Uhr morgens bemerken. Der Flaschenhals verlagert sich von der Tastatur zur Validierungspipeline, und diese Pipeline wurde nicht dafür ausgelegt, ein zehnfach höheres Änderungsvolumen zu bewältigen.

Die verborgene Obergrenze

In der Ära vor der KI war das harte Limit das Budget für Neueinstellungen. Das war zumindest leicht in einer Tabelle abzulesen. Jetzt ist die Einschränkung in Posten verborgen, die die meisten Finanzteams kaum verfolgen: Inferenzkosten, Embedding-Speicherung, Erweiterungen des Kontextfensters und ein Stillstand bei automatisierten Tests, der die CI-Runner erstickt. Produktivitäts-Dashboards leuchten grün, während die tatsächlichen Kosten jedes neuen Features im Stillen kumulieren.

Architektonische Entropie ist hier der wahre Bösewicht. LLMs skalieren die Code-Produktion hervorragend, aber sie reduzieren nicht die Komplexität. Sie entwirren keine Microservices, eliminieren keinen toten Code und vereinfachen keine Vererbungshierarchien. Sobald ein System die Schwelle überschreitet, an der Menschen Schwierigkeiten haben, es logisch zu durchdringen, hat auch die KI damit zu kämpfen. An diesem Wendepunkt steigen die Kosten steil an, egal ob Sie