Sehr bescheidene Programmierer

LLMs haben in den letzten ein bis zwei Jahren einen Sprung gemacht.

Vom Nicht-zählen-Können des Buchstabens „r” in „Strawberry” und dem Hineinfallen auf kurze Textzeilen über eine Goldmedaille in den Mathematik-Olympiaden bis zum eigenständigen Schreiben eines C-Compilers.

Der AI Index Report 2026 des Stanford Human-Centered AI Lab bringt es auf den Punkt:

On a key coding benchmark—SWE-bench Verified—performance rose from 60% to near 100% in a single year.

Und natürlich gab es den Hugging-Face-Zwischenfall, in dem eine Flotte von 1.200 KI-Agenten „ausflippte”.

Einige Leute — vor allem CEOs von KI-Laboren — diskutieren einen Entwicklungsstopp für große Sprachmodelle.

Parodien deuten den Standpunkt von Ingenieuren zu dieser Diskussion an: ein aktuelles Video.

Betrachtet man den Hugging-Face-Zwischenfall genauer, bestätigt das diese Sichtweise.

Zuerst entfernte OpenAI alle Schutzmaßnahmen von den Modellen, die Hugging Face „gehackt” hatten.

Das geschah, weil diese Modelle auf ihren „Hacking-Fähigkeiten” anhand eines Tests namens ExploitGym bewertet wurden.

Die Modelle taten also mehr oder weniger, was ihnen gesagt wurde — mit Erlaubnis, alle verfügbaren Mittel einzusetzen.

Betrachtet man weitere Fakten rund um diese Unternehmen, sieht es eher nach einer PR- und Marketingaktion aus.

Der CTO von Hugging Face — Greg Brockman — ist Business Angel bei Hugging Face. Er ist direkt daran interessiert, sowohl OpenAIs Bewertung zu steigern als auch Hugging Face Sichtbarkeit zu verschaffen, und hat in beiden Unternehmen ein großes Netzwerk.

Nvidia, das wertvollste Unternehmen der Welt, kaufte Hugging Face und beschloss, bis zu 100 Milliarden US-$ in OpenAI zu investieren.

Die Abhängigkeiten, die Nvidia und OpenAI aufbauen, sind im Übrigen durchaus interessant — untereinander, mit Oracle oder mit Hugging Face.

Es ist nicht leicht, im aktuellen Umfeld Hype und Lärm von Fähigkeit und Wert zu unterscheiden.

Aber es gibt Daten über den tatsächlichen Nutzen von LLMs aus der Softwarebranche.

Die Adoption im Arbeitsalltag von Softwareentwicklern hat stattgefunden: Mehr als 90% der Entwickler nutzen KI als Teil ihrer Arbeit, und mehr als 80% glauben, dass sie ihre Produktivität erhöht hat (Google-DORA-Studie).

Industrieumfragen finden eine Produktivitätssteigerung von 10–40% beim committeten Code.

Bei Greenfield-Projekten, also Projekten, die von Grund auf neu gestartet werden, werden Steigerungen von 35–40% berichtet. Bei Legacy- oder Brownfield-Codebasen sind die Gewinne jedoch kleiner, bei etwa 10% (Google-DORA-Studie).

Dennoch würden 96% der Ingenieure den Ergebnissen von LLMs nicht blind vertrauen, und 30% vertrauen ihnen gar nicht (Sonar-Entwicklerumfrage).

KI erzeugt Code, der korrekt aussieht, aber nicht zuverlässig ist, laut 61% der Entwickler — allerdings prüfen nur 48% den KI-generierten Code immer (Sonar).

Diese Tatsache verschiebt den Flaschenhals der Softwareentwicklung vom Schreiben von Code zum Verifizieren von Code.

Eine Umfrage fand eine Zunahme des Review-Aufwands um 440%.

Die Superintelligenz-Sicht überlässt oft alle Teile der Arbeit den Modellen.

Wir haben die Zahlen gesehen, wie erfolgreich eine solche Adoption ist.

IBM hat eine Umfrage veröffentlicht, für die NATO- und Five-Eyes-Führungskräfte zu KI befragt wurden. Die Ergebnisse zeigen, dass die meisten KI-Projekte in der Prototypenphase stecken bleiben, weil die Prozesse und Systeme drumherum nicht vorbereitet sind.

MIT findet eine Ausfallrate von 95% bei generativen KI-Pilotprojekten in Unternehmen — wegen falscher Zuweisung auf Marketing und Vertrieb als Zielanwendungen, statt auf die vielversprechenderen Backoffice-Automatisierungsaufgaben, bei denen KI Business Process Outsourcing überflüssig macht und Abläufe strafft.

Gleichzeitig wächst die Regulierungslast in die entgegengesetzte Richtung: der EU AI Act, wirksam ab Juni 2026, der EU Cyber Resilience Act, ab dem 11. Dezember 2027 durchgesetzt, die EU-Maschinenrichtlinie, die zum Beispiel die Robotik ab dem 20. Januar 2027 betrifft, und die Supervisory Expectations der Monetary Authority of Singapore zur verantwortungsvollen KI-Adoption durch Finanzinstitute.

All diese Regulierungen legen die Verantwortung bei den Geschäftsführern ab — sowohl für den verantwortungsvollen KI-Einsatz als auch für Cybersicherheitsvorfälle.

Aus dieser Perspektive sieht das, was als Superintelligenz verkauft wird, inzwischen eher nach einem Werkzeug aus.

Das ist auch die Haltung von Linus Torvalds, dem Vater des Linux-Kernels — dem Betriebssystem, das das Internet, Clouds, Superrechner und viele Entwicklungsumgebungen antreibt. Ihre Server laufen höchstwahrscheinlich irgendwie auf Linux.

Hier ist, was Linus über KI sagt:

„I see that as a tool that can help us be better at what we do”, Linus Torvalds

KI als Werkzeug zu betrachten, vereinfacht den Umgang damit erheblich — meine ich.

Erstens: Bevor man jemandem einen Hammer gibt, stellt man sicher, dass er weiß, wie man ihn benutzt.

Beim Hammer soll der Kopf des Hammers den Kopf des Nagels treffen. Man fängt vorsichtig an, damit der Nagel richtig im Holz sitzt, bevor man mehr Kraft gibt.

Zweitens: Man stellt Sicherheitsstandards sicher, das heißt, man legt Regeln fest.

Man benutzt einen Hammer, um Nägel in Holz zu schlagen. Man benutzt keinen Hammer für Schrauben, und man schlägt auch keinen Nagel in Beton.

Überträgt man das auf KI: Man will Prozesse haben, die KI integrieren — nicht KI, die bei jedem Lauf den Prozess neu erfindet.

Speziell in der Softwareentwicklung gibt es zum Beispiel die ISO/IEEE 15288 für den Software Development Lifecycle, die die Prozessschritte und Ergebnisse festlegt, wie die Software Requirements Specification (IEEE 830) und die Software Design Documentation (IEEE 1016).

Mit dem KI-Hype wurden diese Grundprinzipien jedoch mit weniger Engineering-Disziplin neu erfunden — genannt „spec-driven development”.

Haben wir so etwas in der Softwareentwicklung nicht schon gemacht, seit Dijkstra die Unverständlichkeit großer Softwaresysteme die Softwarekrise nannte?

Die Antwort war damals Software Engineering und Bescheidenheit: Prozessstandards, Modellierungssprachen, Entwurfsmuster — um Klarheit und Sichtbarkeit im gesamten Prozess zu schaffen.

Jetzt haben wir weit mehr und vielfältigere Anwendungen von KI als nur Programmierung.

Ich glaube, die Antwort werden für alle Anwendungen dieselben Prinzipien sein:

1. Hohe Qualitätsstandards & Regulierungskonformität, zum Beispiel durch formale Verifikation durchgesetzt.
2. Volle Sichtbarkeit der Prozessschritte, getragen von bescheidenen Menschen, die Exzellenz und Klarheit anstreben.
3. Werkzeuge einsetzen, um den menschlichen Geist zu befähigen, mehr zu erreichen.

Erfolg bei KI-Projekten kommt mit den ersten beiden.

Ich möchte mit Worten schließen, die Edsger Dijkstra 1972 zum Abschluss seiner Turing-Award-Vorlesung wählte:

This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation, it should give us better control over the task of organizing our thoughts. If it did not do so, to my taste we should not deserve the computer at all!

It has already taught us a few lessons, and the one I have chosen to stress in this talk is the following. We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.