Dinosaurier, hier kommt dein Asteroid!
Die Meinungen in der KI-Programmierer-Community gehen auseinander, ob KI das Programmieren so vereinfacht, dass sogar ein Höhlenmensch es könnte – oder ob es so schwierig ist, dass nur ein Prompt-Ingenieur mit Spezialkenntnissen es kann. Eigentlich muss man nur ein paar Dinge lernen, aber die lernt man schnell.
Man lernt, Aufgaben in kleinere Segmente aufzuteilen, damit die KI im Kontextfenster nicht den Überblick verliert. Manche Tools wie Claude Code können das sogar ein bisschen selbst und manchmal sogar verlässlich. Und man lernt zu erkennen, wann die KI das Ziel so weit verfehlt, dass man selbst übernehmen muss.
Ein kompetenter Entwickler erarbeitet sich das in weniger als einer Woche nicht übermäßiger KI-Nutzung. Wenn KI aber wirklich jederzeit 2-mal, 10-mal oder 100-mal besser werden könnte, wie überall behauptet wird, wäre alles, was man über die Nutzung von KI gelernt hat, sowieso hinfällig.
Jedesmal, wenn ich auf KI stieß, die "ganz okay" funktionierte, machte mich das seltsamerweise nervöser statt ruhiger. Denn es hieß, dass ich das Geheimrezept nicht finden konnte, mit dem alle anderen so produktiv wurden. Ich hatte es einfach nicht drauf: Dinosaurier, triff deinen Asteroiden, sein Name ist KI!
Schließlich retteten mich ein paar Dinge aus dieser Krise. Eines davon war dieser Artikel von Ludicity(öffnet im neuen Fenster) , der den Behauptungen der KI-Befürworter direkt widersprach.
Doch es gab noch anderes, das mich von dem x10-KI-Imposter-Syndrom befreit hat.
Einfach mal nachgerechnet
Beginnen wir mit einer einfachen Rechnung zur 10- bis 100-fachen Produktivität. Eine 10-fache Produktivität bedeutet zehnmal so viele Ergebnisse, nicht zehnmal so viele Codezeilen. Was man früher in einem Quartal geliefert hat, schafft man nun in anderthalb Wochen. Diese Zahlen sollten selbst den gläubigsten KI-Jünger nachdenklich machen.
Alle Produktideen, Story-Point-Verhandlungen, Bugfixes, Code-Reviews, Wartezeiten für Deployments, Tests und Qualitätssicherung, die traditionell drei Monate Arbeit brauchen, sollen nun in sieben Arbeitstagen erledigt werden? Dafür müsste die Produktivität an jedem einzelnen der Flaschenhälse verzehnfacht werden.
Jeder Softwareentwickler, der schonmal an echtem Code in einem echten Unternehmen gearbeitet hat, weiß, dass das unmöglich ist. Das Hin und Her von drei Monaten Code-Review lässt sich nicht in anderthalb Wochen komprimieren.
Code-Review bedeutet:
- den Reviewer taggen
- hoffen, dass er sich schnell darum kümmert (schwierig, wenn er zehnmal so viel Code wie früher prüfen muss)
- in der Zwischenzeit etwas anderes machen
- eine Benachrichtigung erhalten (vielleicht direkt, vielleicht auch zwei Stunden, nachdem der Reviewer für den Abend offline gegangen ist)
- wieder zurück in den Review-Kontext wechseln
- die Kommentare lesen
- darauf reagieren
- den Vorgang wiederholen
Ein Unternehmen mit guten Standards und Kommunikationsprozessen kann diesen Vorgang ziemlich effizient gestalten. Aber zehnmal so effizient, um zehnmal so viel Arbeit zu bewältigen? Das ist schlicht unmöglich.