KI war nicht immer so gut. Wir haben uns nur daran gewöhnt.

💡 Kurz gesagt: zentrale Punkte

• KI beschleunigt nicht nur die Softwareentwicklung. Sie erweitert die Zahl der Ideen, deren Erprobung ein Unternehmen sich leisten kann.
• Vergangene Teams mit den Werkzeugen von heute zu beurteilen, ist falsch. Die heutige Organisation mit Kosten- und Kapazitätsannahmen von gestern zu führen, ist es ebenso.
• Knappheit verschiebt sich. Wenn Code günstiger wird, gewinnen Problemwahl, Kundenwissen, Distribution und Urteilsvermögen an Wert.
• Mehr Software ist nicht das Ziel. Ziel ist, schneller zu belastbaren Erkenntnissen zu kommen und bessere Entscheidungen zu treffen.

Eine Führungskraft sieht, wie eine fähige Person in wenigen Wochen ein umfangreiches Produkt erstellt. Noch vor wenigen Jahren hätte dieselbe Arbeit offenbar ein Team und Monate an Budget gebraucht.

Die naheliegende Schlussfolgerung lautet:

Unser Softwareteam hat jahrelang gearbeitet. Wenn heute eine Person so viel schaffen kann, hat das frühere Team vielleicht sehr wenig erreicht.

Diese Schlussfolgerung ist falsch. Die Veränderung dahinter ist real.

Das Team von 2023 verfügte nicht über die Werkzeuge von 2026. Wir können heutige Technologie nicht rückwirkend anwenden und daraus einen Leistungsmaßstab machen. Viele Unternehmen machen nun jedoch den umgekehrten Fehler. Sie budgetieren, besetzen und sequenzieren Softwarearbeit noch immer, als wären die neuen Werkzeuge nie erschienen.

Nach fast drei Jahrzehnten in der Softwareentwicklung bin ich vorsichtig damit, jedes neue Werkzeug als grundlegenden Umbruch zu bezeichnen. Dieses verschiebt jedoch eine reale Grenze: die Größe der Arbeit, die wir sinnvoll an KI delegieren können.

Mit dieser Grenze wächst auch die Zahl der Ideen, die ein Unternehmen wirtschaftlich testen kann.

Die Veränderung ist nicht nur Geschwindigkeit

Bis vor wenigen Monaten verlangte die Arbeit mit einem Programmiermodell fortlaufende Aufsicht. Ich teilte die Arbeit in kleine Teile, wiederholte Einschränkungen, korrigierte Fehler und erledigte oft den schwierigen Teil selbst.

Heute kann ich mit dem richtigen Kontext und einem klaren Briefing erheblich größere Arbeitspakete delegieren. Ich prüfe das Ergebnis weiterhin. Kritische Systeme brauchen weiterhin ernsthafte menschliche Aufsicht. Doch die delegierbare Einheit ist von einer Funktion in Richtung eines ganzen Features gewachsen.

Das klingt nach technischer Verbesserung. Die wichtigere Folge ist wirtschaftlich.

Ein Produktivitätsgewinn von zehn Prozent macht ein bestehendes Projekt etwas günstiger. Das Überschreiten einer Schwelle kann eine zuvor unwirtschaftliche Idee testenswert machen. Manche Arbeit bleibt nicht mehr bei „KI kann helfen“. Sie kann delegiert, geprüft und viel früher in nutzbare Erkenntnisse verwandelt werden.

Wir gewöhnen uns bemerkenswert schnell daran. Ein Modell erledigt etwas, das vor wenigen Monaten nahezu unmöglich schien. Einen Tag lang überrascht es uns. Innerhalb weniger Wochen behandeln wir es als normal. Beim nächsten Modell schreiben wir unsere Erinnerung um: „KI konnte das doch schon.“

Meistens konnte sie es nicht – jedenfalls nicht mit derselben Zuverlässigkeit, bei Aufgaben derselben Größe und mit ebenso wenig Eingriff.

Gegenwartsbias, Rückschaufehler und eine wandernde Vergleichsbasis helfen, das zu erklären. Wichtiger als die Begriffe ist die Folge: Wir normalisieren eine neue Fähigkeit und erinnern sie dann, als hätte sie immer bestanden. Das verzerrt sowohl unseren Blick auf frühere Leistung als auch unsere Schätzung heutiger Kapazität.

Die Vergangenheit nicht mit den Werkzeugen von heute umschreiben

Solche Verschiebungen haben wir schon erlebt. IDEs nahmen mechanische Arbeit ab. Stack Overflow verkürzte die Suche nach technischem Wissen. Moderne Frameworks standardisierten wiederkehrende Probleme. Cloud-Dienste reduzierten Wochen Infrastrukturarbeit auf Stunden.

Ein Infrastrukturteam, das vor fünfzehn Jahren Wochen brauchte, um eine Umgebung aufzusetzen, hat nicht zwangsläufig versagt. Dass wir dieselbe Arbeit heute an einem Nachmittag erledigen können, ändert daran nichts. Das Team hatte andere Werkzeuge und Beschränkungen.

Dieselbe Logik gilt für KI. Ein kostengünstigerer Prototyp im Jahr 2026 beweist nicht, dass das Team von 2023 schlecht gearbeitet hat.

Historische Fairness bedeutet aber nicht, das alte Betriebsmodell zu bewahren. Sie ist keine Verteidigung heutiger Trägheit.

Beurteilen Sie frühere Leistung mit den Werkzeugen ihrer Zeit. Setzen Sie heutige Erwartungen mit den Werkzeugen, die jetzt tatsächlich existieren.

Wert sammelt sich bei Domänenwissen und Verantwortung

Softwareentwicklung bewegt sich über die Softwareabteilung hinaus. Eine Logistikfachkraft kennt die Ausnahmen in der Routenplanung. Eine Finanzfachkraft versteht die Abstimmungsregeln. Eine Person im Marketing erkennt Reibung in Kampagnen früher als ein allgemeines Produktteam.

Bei klar begrenzten Problemen kann eine starke Fachexpertin oder ein starker Fachexperte mit leistungsfähiger KI ein besseres Ergebnis erzielen als ein durchschnittliches Softwareteam. Diese Person weiß, was im realen Betrieb stimmen muss.

Mit wachsendem Risiko und mehr Abhängigkeiten rückt gute Ingenieursarbeit wieder ins Zentrum. Kundengerichtete, regulierte oder umsatzkritische Systeme brauchen weiterhin Zuverlässigkeit, Datenintegrität, Sicherheit und Support.

Die Schlussfolgerung lautet nicht, dass Entwicklerinnen und Entwickler überflüssig sind. Wert verlagert sich vom Übersetzen eines definierten Auftrags in Code hin zur Wahl der richtigen Intervention, zum Setzen sicherer Grenzen und zur Verantwortung für das Ergebnis.

Mehr Software bedeutet nicht mehr Wert

Manche Ideen, die früher als „drei Entwickler für sechs Monate“ im Plan standen, lassen sich heute in Wochen testen.

Testen ist das entscheidende Wort. Das ist nicht die Behauptung, eine Person ersetze ein Team. Es bedeutet, dass ein Unternehmen wichtige Fragen vor einer großen Investition beantworten kann. Wollen Kunden das? Beseitigt der Arbeitsablauf tatsächlich Kosten? Verbessert er Geschwindigkeit, Qualität oder Umsatz?

Hunderte Features in drei Monaten zu erzeugen, beweist nur, dass Software erzeugt wurde. Es beweist nicht, dass jemand sie will oder dass das Ergebnis Jahre der Wartung verdient.

Wenn Code günstiger wird, ändern sich die knappen Ressourcen. Kunden verstehen, das richtige Problem finden, Vertrauen gewinnen und den Markt erreichen werden wertvoller. Ich habe an anderer Stelle argumentiert, dass KI Unternehmen durch die Einstellungen verändern kann, die nie nötig werden. Dieselbe Hebelwirkung erlaubt kleineren Teams auch, Ideen zu testen, die früher kein Budget bekommen hätten.

Modelle machen weiterhin Fehler. Eine überzeugende Demo ist keine verlässliche Software. Zwischen beidem liegen Daten, Integration, Einführung, Support, Wartung und Verantwortung. Schnellere Produktion macht Prüfung und Verantwortung wichtiger. Sonst wird Geschwindigkeit zu Verständnisschulden.

KI erleichtert das Problem, mehr Software zu erzeugen. Dafür macht sie eine andere Frage wichtiger: Welche Software lohnt es sich zu erzeugen?

In wenigen Monaten werden sich die heutigen Fähigkeiten gewöhnlich anfühlen. Gerade deshalb lohnt es sich, die Vergleichsbasis jetzt festzuhalten.

Beurteilen Sie die Vergangenheit mit den Werkzeugen, die sie hatte. Führen Sie das Unternehmen von heute mit den Werkzeugen, die es hat. Die Führungsaufgabe besteht darin zu entscheiden, wo günstigere Software schnelleres Lernen ermöglicht – und wo sie nur ein weiteres zu wartendes System schafft.