Am 21. Juli 2026 veröffentlichte Stephen Wolfram einen umfangreichen Essay mit dem Titel Towards a Theory of Bugs: The Ruliology of the Unexpected. Der Beitrag versucht, eine formale Theorie für Software-Bugs zu begründen. Seine zentrale These lautet: Bugs sind die unvermeidliche Konsequenz der rechnerischen Unreduzierbarkeit (computational irreducibility).
Der Artikel erzielte auf Hacker News enorme Aufmerksamkeit, erreichte 1.294 Punkte sowie 508 Kommentare und stieg zum Spitzenbeitrag des Tages auf. Dennoch herrschte in den Kommentaren eine spürbare Skepsis vor nach dem Motto: “Wovon sprichst du eigentlich?”
Das große Narrativ eines Mathematikers
Wer ist Wolfram? Wer nicht selbst programmiert, kennt seinen Namen vielleicht aus einem anderen Kontext: als Gründer von Mathematica, Schöpfer der Antwortmaschine Wolfram Alpha und Verfechter von A New Kind of Science. Er pflegt die tief verwurzelte Gewohnheit, sämtliche Phänomene in das Korsett seines “Prinzips der rechnerischen Äquivalenz” (Principle of Computational Equivalence) zu zwängen.
Diesmal hat er Software-Bugs ins Visier genommen.
Wolframs Argumentationskette verläuft wie folgt: Selbst extrem einfache Programme – wie etwa eine Turing-Maschine mit nur 3 Zuständen und 2 Farben – können bei bestimmten Eingaben “unerwartetes Verhalten” an den Tag legen. In seinem Essay führt er ein konkretes Beispiel an: Eine Turing-Maschine, die augenscheinlich n+1 berechnet, liefert für die Eingaben 0 bis 6 korrekte Ergebnisse, gibt aber bei der Eingabe 7 unerklärlicherweise eine 9 aus.
Er demonstriert einen noch extremeren Fall: Eine 4-Zustände-Turing-Maschine arbeitet für Eingaben von 0 bis 62 einwandfrei, gibt jedoch bei der Eingabe 63 urplötzlich eine 72 aus.
Diese “unerwarteten Anomalien” sind aus Wolframs Sicht die Urform von Bugs. Und ihre Ursache liegt in der von ihm so genannten “rechnerischen Unreduzierbarkeit”.
Rechnerische Unreduzierbarkeit: Die Go-Metapher
An dieser Stelle müssen wir innehalten, um dieses Schlüsselkonzept zu erläutern, da sich der gesamte Streit darum dreht.
“Rechnerische Unreduzierbarkeit” ist ein Begriff, den Wolfram 2002 in seinem Buch A New Kind of Science einführte. Die Kernintuition lässt sich in einer einfachen Frage zusammenfassen: Kann man den Ausgang einer Partie Go exakt bestimmen, ohne jeden einzelnen Zug durchzuspielen?
Nein. Jeder Zug im Go hängt von der Antwort des Gegners ab, die wiederum den nächsten eigenen Zug bestimmt. Abgesehen vom tatsächlichen Ausspielen der Partie gibt es keine Abkürzung, um das Endergebnis präzise vorherzusagen.
Genau das bedeutet “unreduzierbar”: Wenn ein Programm ausgeführt wird, kann sein Verhalten durch kein “schnelleres Berechnungsverfahren” vorausgesagt werden. Der einzige Weg, sein Verhalten zu erfahren, besteht darin, es Schritt für Schritt bis zum Ende auszuführen.
Wolframs Logik ist dementsprechend geradlinig: Wenn ein Bug im Wesentlichen ein “unerwartetes Verhalten” darstellt und die rechnerische Unreduzierbarkeit bedeutet, dass jedes ausreichend komplexe Programm zwangsläufig Verhaltensweisen erzeugt, die sich nicht im Voraus berechnen lassen – dann sind Bugs nicht bloß das Resultat menschlicher Programmierfehler, sondern eine mathematische Notwendigkeit.
Er stellt sogar die Behauptung auf, dass jedes Programm, dessen Ausführung sich lohnt (weil es eine sinnvolle Berechnung durchführt), unvorhersehbare Abschnitte enthalten muss und somit potenziell fehlerhaft ist. Das klingt nach einem existenziellen Dilemma: Entweder schreibt man ein Programm, das so trivial ist, dass es keine Bugs hat, oder man akzeptiert Bugs als den Preis der Berechnung selbst.
Die Antwort der Ingenieure: “Das deckt sich nicht mit meiner Praxis”
Wäre die Geschichte hier zu Ende, bliebe sie die philosophische Betrachtung eines Mathematikers. Das eigentliche Drama spielte sich jedoch in den Kommentaren ab.
Der Kommentar des HN-Nutzers gjm11 wurde rasch an die Spitze gewählt. Er wies auf eine eklatante Diskrepanz hin: Die von Wolfram diskutierten “Bugs” haben kaum etwas mit den Fehlern zu tun, mit denen Softwareentwickler täglich konfrontiert sind.
gjm11 unterschied zwischen zwei grundlegend verschiedenen Szenarien:
Szenario 1: Man möchte ein Programm schreiben, das Aufgabe X erfüllt. Man durchdenkt die Logik für X gründlich und schreibt einen Code, von dem man überzeugt ist, dass er das Ergebnis X liefert – begeht dabei aber Fehler. So entsteht die überwältigende Mehrheit realer Bugs: Entwickler machen Denkfehler in der Logik, behandeln Randfälle falsch oder missverstehen API-Dokumentationen.
Szenario 2: Man generiert eine Vielzahl zufälliger Programme, testet sie einzeln durch, findet ein Programm, das bei Stichproben Aufgabe X zu lösen scheint, und setzt es ein – bis es bei bestimmten Randfällen versagt.
Wolframs Essay befasst sich ausschließlich mit Szenario 2. Er nutzt zufällig generierte Turing-Maschinen als Beispiele – Maschinen, die zufällig “in den meisten Fällen” das Richtige tun und bei spezifischen Eingaben scheitern. Das hat jedoch nichts mit Szenario 1 zu tun, bei dem Ingenieure ein System zielgerichtet entwerfen und ihnen dabei Unachtsamkeiten unterlaufen.
gjm11 bezeichnete Wolframs Argumentation unverblümt als “albern” (silly) und betonte, dass Wolfram lediglich versuche, sein Lieblingskonzept der rechnerischen Unreduzierbarkeit in einen Kontext zu erzwingen, in den es schlicht nicht passt.
Tiefer liegende Differenzen
Ein anderer HN-Nutzer, seanhunter, brachte eine weitere Schwachstelle auf den Punkt: Wolfram hat seine Kernkonzepte nie streng definiert.
Das “Prinzip der rechnerischen Äquivalenz” und die “Rechnerische Unreduzierbarkeit” dienen in Wolframs Denkgebäude als universelle Erklärungsmodelle, lassen jedoch formale Präzision vermissen. In der wissenschaftlichen Praxis gilt: Was nicht definiert ist, kann weder überprüft noch widerlegt werden. Eine Theorie, die sich der Überprüfung entzieht, gleicht weniger einer Wissenschaft als vielmehr einem Glaubensbekenntnis.
Die Beobachtung von PaulHoule fiel noch nüchterner aus. Er verwies auf ein wiederkehrendes Muster bei Wolfram: Wann immer dieser eine neue Regelklasse entdeckt, stößt er darin auf faszinierende Muster (wie etwa “Regel 30”) und verkündet begeistert die Entdeckung einer neuen “Theorie” – ohne jedoch außer der Aussage “auch dies ist rechnerisch unreduzierbar” nennenswerte tiefere Erkenntnisse zu liefern.
Darin liegt womöglich die größte Ironie: Eine Bewegung, die als “Eine neue Art von Wissenschaft” angetreten ist, hat in zwei bis drei Jahrzehnten im Kern lediglich eine fundamentale Erkenntnis hervorgebracht: Viele Dinge sind unvorhersehbar.
Das Echo einer älteren Debatte
Tritt man einen Schritt zurück, wird klar, dass diese Debatte keineswegs neu ist.
Wolframs These von der “Unvermeidbarkeit von Bugs” versucht im Kern, eine alte Ingenieurerfahrung mathematisch zu begründen: Softwarefehler lassen sich nie vollständig eliminieren. Mit dieser Erkenntnis steht er keineswegs allein da – Turings Halteproblem hat bereits vor Jahrzehnten bewiesen, dass kein allgemeiner Algorithmus entscheiden kann, ob ein beliebiges Programm stoppen wird. In der Praxis akzeptieren die meisten Entwickler, dass komplexe Softwaresysteme immer Bugs enthalten.
Das Problem liegt jedoch in der steilen These, dass “rechnerische Unreduzierbarkeit die Theorie der Bugs” sei – hier werden entscheidende Zwischenschritte übersprungen.
Wolframs Argumentation springt über verschiedene Abstraktionsebenen hinweg. Von den mathematischen Eigenschaften von Turing-Maschinen springt er direkt zu Fehlerphänomenen in der alltäglichen Softwareentwicklung. Dieser Sprung ignoriert eine zentrale Tatsache: Die überwiegende Mehrheit aller Produktionsfehler hat ihre Ursache in den kognitiven Grenzen des Menschen – in übersehenen Randfällen oder missverstandenen Anforderungen – und nicht in einer tiefen rechnerischen Unreduzierbarkeit.
Zwar mögen diese “menschlichen Bugs” über Umwege eine gewisse Verbindung zur rechnerischen Unreduzierbarkeit aufweisen (da menschliche Kognition letztlich auch ein Informationsverarbeitungsprozess ist), doch Wolfram gelingt es in seinem Essay nicht, diese Brücke zu schlagen. Er verpackt ein Phänomen, das sich viel nüchterner beschreiben ließe, lediglich in ein hochgestochenes mathematisches Gewand.
Fairerweise hat Wolfram nicht ganz unrecht
Als Gedankenexperiment ist das Narrativ “Rechnerische Unreduzierbarkeit verursacht Bugs” keineswegs wertlos.
Einerseits berührt es eine intuitiv schwer greifbare Wahrheit: Selbst einfachste regelbasierte Systeme können unvorhersehbares Verhalten an den Tag legen. Dies ist im Zeitalter der künstlichen Intelligenz von besonderer Relevanz – wenn Machine-Learning-Modelle Code generieren und selbst die Entwickler nicht mehr vollständig durchschauen, was im latenten Raum des Modells geschieht, greift das traditionelle Erklärungsmuster “Der Programmierer hat einen Fehler gemacht” zu kurz.
Andererseits sind die von Wolfram angesprochenen Grenzen der formalen Verifikation (Formal Verification) eine reale Tatsache. Kein formales Verifikationssystem kann alle denkbaren Eingabebereiche abdecken; dies ist in den Grundgrenzen der Berechenbarkeitstheorie verankert. Insofern hat das Verständnis der “Uneliminierbarkeit” von Bugs für sicherheitskritische Software – etwa in der autonomen Fahrzeugsteuerung oder bei Medizintechnikgeräten – durchaus praktische Bedeutung.
Doch wie zahlreiche Kommentatoren anmerkten, handelt es sich hierbei eher um ein Umverpacken bekannter Tatsachen: Die Unentscheidbarkeit des Halteproblems und die immensen Kosten formaler Verifikation sind in der Softwaretechnik längst alter Hut. Wolframs Beitrag beschränkt sich im Wesentlichen darauf, diesen Binsenweisheiten ein neues Etikett aufzukleben.
Die Selbstgefälligkeit des Mathematikers und der Pragmatismus des Ingenieurs
Hinter dem Streit verbirgt sich ein tiefgreifender Kulturkonflikt.
Wolfram denkt als Mathematiker und Theoretiker. Seine Methode besteht darin, aus den ersten Prinzipien ein grandioses Theoriegebäude zu errichten und damit alles zu erklären. Er sammelt keine empirischen Bug-Daten und analysiert keine realen Fehlerberichte; stattdessen “simuliert” er Fehlerphänomene durch die Generierung zufälliger Turing-Maschinen.
Ingenieure denken genau umgekehrt. Sie sind mit der Unordnung der realen Welt konfrontiert: einer NullPointerException, einer Race Condition oder einem fehlgeschlagenen Zahlungsvorgang aufgrund falscher Zeitzonenberechnung. Die Ursachen dieser Bugs sind extrem konkret und durch zahlreiche Abstraktionsschichten von der “rechnerischen Unreduzierbarkeit” getrennt. Für den Praktiker wirkt Wolframs Theorie weniger wie eine Erklärung, sondern eher wie störendes Rauschen.
Dies war der entscheidende Punkt in gjm11s Kritik: Wolfram verwechselt zwei grundlegende Debugging-Pfade. Ingenieure folgen dem ersten Pfad: Code verstehen, Logikfehler identifizieren, Fehler beheben. Der von Wolfram beschriebene zweite Pfad – “man nehme einen Zufallscode, der bei kleinen Eingaben funktioniert, und bete, dass er überall läuft” – ist keine Debugging-Methodik, sondern ein Antipattern.
Fazit: Die Grenzen der Theorie
Dass Wolfram versucht, mit der rechnerischen Unreduzierbarkeit eine “ultimative Erklärung” für Bugs zu liefern, zeigt zumindest, dass er sich einer unbequemen Wahrheit der Softwaretechnik stellt: Wir werden niemals völlig fehlerfreie Software schreiben können.
Doch um die Praxiserfahrung “Bugs sind unvermeidbar” zu einer echten “Theorie der Bugs” zu erheben, braucht es mehr als eindrucksvolle Begriffe. Es bedarf empirischer Daten, anwendbarer Vorhersagekraft und eines tiefen Verständnisses der praktischen Softwareentwicklung – all das lässt Wolframs Arbeit vermissen.
Das bedeutet nicht, dass Wolframs Ansatz wertlos ist. Die rechnerische Unreduzierbarkeit beschreibt ein reales Phänomen der Informatik absolut zutreffend. Um jedoch jene Bugs zu erklären, mit denen Softwareentwickler täglich kämpfen – Fehler durch Unachtsamkeit, mangelnde Kommunikation, geänderte Anforderungen oder übersehene Spezialfälle im Code-Review – ist dieses Konzept schlicht zu grobkörnig.
Wie ein Kommentator treffend bemerkte: Womöglich hat Wolfram “nur einen weiteren Ort entdeckt, an dem Regel 30 auftaucht, und glaubt nun begeistert, eine neue Theorie entdeckt zu haben”. Auf der Skala des rechnerischen Universums mag das stimmen. Für einen Ingenieur, der nachts einen Produktionsausfall behebt, ist das Wissen, dass “Bugs wegen der rechnerischen Unreduzierbarkeit existieren”, jedoch etwa genauso hilfreich wie die Erkenntnis, dass “alle Menschen sterben müssen”, wenn man ein Mittel gegen Erkältung sucht.
Weiterführende Links:
- Stephen Wolfram: Towards a Theory of Bugs: The Ruliology of the Unexpected
- Hacker News Diskussion (item?id=49033114)
- Rechnerische Unreduzierbarkeit – Wikipedia
- Wolfram: Principle of Computational Equivalence
Alle Abbildungen in diesem Artikel stammen von der Originalseite von Stephen Wolfram.
