Warum KI Software nicht über Nacht neu erfinden wird: Benedict Evans über die Grenzen generativer Werkzeuge

Benedict Evans' neuester Aufsatz, "KI, Tools und Transformation", widerspricht der Silicon-Valley-Vorstellung, dass KI es Nutzern ermöglichen wird, spontan die benötigte Software zu generieren und damit traditionelle Unternehmenssoftware überflüssig zu machen. Sein Kernargument: Der Engpass liegt nicht im Bauen von Tools, sondern darin zu wissen, welche Tools man bauen soll und Hunderte von Menschen dazu zu bringen, sie zu übernehmen.

Der "Ingenieurs-Witz" umgekehrt

Evans beginnt mit dem klassischen Witz: Ein Ingenieur verbringt eine Stunde damit, eine Aufgabe zu automatisieren, die 10 Minuten dauert. Aber mit KI "kannst du dieses Tool in fünf Minuten erstellen, und du musst kein Ingenieur sein." Die berauschende Idee ist, dass Software dynamisch, generativ, formlos wird – massiv mehr Aufgaben werden mit massiv weniger Code automatisiert. Doch er warnt, dass dies missversteht, wie Software in echten Unternehmen übernommen wird.

Warum die meisten Nutzer keine Tool-Entwickler sind

Mit Blick auf die Realität eines typischen Großunternehmens – Hunderte von SaaS-Apps, Skripten und Tabellenkalkulationen – stellt Evans fest, dass die meisten Menschen nicht wie Silicon-Valley-Ingenieure sind. "Wenn du ein wirklich großartiger Scheidungsanwalt bist, verbringst du deinen ganzen Tag mit deinen Fällen und Mandanten, nicht damit, was großartige juristische Discovery-Software tun würde." Deshalb gibt es Tabellenkalkulationsvorlagen und 'Datei/Neu'-Vorschläge: Sie versuchen, die Lücke für Nicht-Entwickler zu schließen, bleiben aber Teillösungen.

Die verpassten Chancen sind für diejenigen, die sie haben, oft unsichtbar. Evans nennt die neue Rolle des 'forward-deployed engineer' – jemand, der durch eine Anwaltskanzlei oder ein Architekturbüro gehen und Automatisierungspotenzial erkennen kann, das der Experte nicht sieht, so wie ein technisch versierter Teenager sagen könnte: "Papa, wusstest du, dass du es einfach so machen könntest?"

Das Problem zu sehen ist der schwierige Teil

Über die individuelle Wahrnehmung hinaus waren viele transformative Automatisierungen nicht einmal für Ingenieure offensichtlich. "Wir können alle Beispiele von Dingen nennen, die wir täglich nutzen und bei denen unsere erste Reaktion war: 'Warum sollte ich das wollen?'" Das Problem kann in einem anderen Arbeitsablauf eingebettet sein, und die richtige Lösung zu finden erfordert oft, das Problem selbst neu zu definieren – etwas, das bei vielen erfolgreichen Softwareunternehmen ein halbes Dutzend fehlgeschlagener Versuche brauchte.

Automatisierung betrifft Abteilungen, nicht nur Einzelpersonen

Die Skalierung einer Workflow-Änderung über einen einzelnen Benutzer hinaus nennt Evans das "institutionalisiert bis improvisiert"-Spektrum. Eine Bottom-up-Tabelle kann eine Abteilung bewältigen, aber ein neuer Kreditorenprozess betrifft fünf Abteilungen, drei Systeme der Aufzeichnung und vier Regulierungsregime. Diese Änderung "muss ein Kauf, eine Entscheidung und ein 18-monatiger Verkaufsprozess sein", nicht nur ein schneller KI-Prompt.

Nichts davon wird dadurch gelöst, dass man das Schreiben von Code erleichtert. Die schwierigen Teile – das Erkennen des Bedarfs, das Definieren des Tools und die Förderung der Akzeptanz – bleiben hartnäckig menschlich und organisatorisch. Das ist ein nüchterner Gegenpol zur Erzählung der 'Demokratisierung der Softwareentwicklung', die wir so oft hören.