Fangen wir mit der Ironie an. Excel hat vier Jahrzehnte Software überlebt, die es verdrängen sollte, und es kam selbst nach oben, indem es jemand anderen verdrängte. Die Tabellenkalkulation hat es nicht erfunden. Das haben Dan Bricklin und Bob Frankston 1979 mit VisiCalc getan. Microsofts erster Versuch, Multiplan, jagte VisiCalc hinterher und verlor gegen Lotus 1-2-3. Excel war der zweite Versuch, 1983 unter dem Codenamen Odyssey begonnen, und es war darauf angelegt, Lotus den Markt abzunehmen, indem es kompatibel genug blieb, um die Lotus-Nutzer herüberzuziehen. Es kopierte sogar die Datumsfehler von Lotus, damit die Migration nicht wehtat. Ein erfolgreiches Programm abzukupfern war Routine. Es war auch eine Plackerei: Monate oder Jahre Reverse Engineering durch einen Raum voller Ingenieure. Geändert hat sich zuletzt der Preis. Heute können Sie das, bis zu einem gewissen Punkt, per Prompt bestellen. Das hat das Klonen an manchen Stellen billig gemacht und an anderen teuer gelassen, und interessant ist die Lücke zwischen diesen beiden Zuständen.
Zwei aktuelle Projekte liegen an den entgegengesetzten Enden dieser Lücke. Das eine ist Ammaar Reshis Port von Command & Conquer: Generals Zero Hour auf iPhone und iPad, entstanden, indem er Claude Code auf das Problem ansetzte und ackern ließ. Das andere stammt von Matthew Berman, der einem Agenten auftrug, Excel kurzerhand zu klonen, und ihn zwölf Tage laufen ließ. Das erste dauerte einen Nachmittag und wurde ausgeliefert. Das zweite brachte einen Klon hervor, den sein Autor perfekt nannte, was, wie sich zeigte, den Teil von Excel meinte, den man in einer Demo sehen kann. Dieselbe Art von Aufgabe, unterschiedlich weite Wege. Das liegt nicht daran, dass einer von beiden das bessere Modell hatte. Es liegt daran, wogegen jeder von ihnen seine Arbeit prüfen konnte.
Das leichte Ende: ein Port in den Kleidern eines Klons
Die C&C-Geschichte wurde als Klon erzählt. Das stimmt aber nicht: Es war ein Port, kein Klon. Der Unterschied ist wichtig und ändert, was die Sache beweist.
Drei Dinge standen schon fest, bevor Reshi anfing. EA hatte Anfang 2025 den vollständigen Quellcode von Generals und Zero Hour unter GPL v3 veröffentlicht, der eigentliche Engine-Code lag also auf GitHub. Ein Community-Projekt, GeneralsX, hatte den wirklich schweren Teil bereits erledigt: eine Codebasis von 2003, DirectX 8, nur für Windows, überhaupt dazu zu bringen, auf anderen Plattformen zu kompilieren und zu rendern. Und das Original lief noch, sein Verhalten stand also direkt zum Vergleich bereit. Reshi forkte GeneralsX und ließ Claude Code die Apple-Schicht ergänzen: den Build für iOS und iPadOS, die Umleitung des Dateisystems (die Engine erwartete eine beschreibbare PC-Festplatte, eine iOS-App bekommt ein gesperrtes, code-signiertes Bundle, also mussten Spielstände und Cache-Pfade umziehen) und Touch-Steuerung für ein Spiel, das immer nur eine Maus gekannt hatte. Als Leute danach den Commit-Graphen prüften, kam sein Fork auf rund zwanzig Commits über einer Basis von zweitausend Commits.
Nichts davon schmälert das Ergebnis. Zero Hour läuft nativ auf einem iPhone mit Touch-Steuerung, das gab es eine Woche zuvor noch nicht, und das Debugging war echte Arbeit. Aber die Ausgangslage war die stärkste, die ein Agent haben kann. Der Quellcode war die Spezifikation. Ein funktionierender Referenz-Build zeigte, wie „korrekt“ aussah. Am laufenden Original ließ sich das Verhalten direkt vergleichen. Wenn das Modell etwas falsch machte, war die Schleife, die den Fehler fing, billig und schnell: kompilieren, starten, hinschauen, vergleichen, korrigieren. Reshi verbrauchte genau damit im Lauf von zwei Tagen sein gesamtes Claude-Max-Kontingent. Ein Nachmittag ist das, was eine große, langweilige Übersetzung kostet, wenn nichts erraten werden muss und sich alles prüfen lässt.
Das schwere Ende: die Bugs klonen
Setzen Sie nun dieselbe Art von Werkzeug auf Excel an, ohne Quellcode, auf den Sie sich stützen könnten. Das hat schon jemand getan, öffentlich und mit vollem Anspruch. Matthew Berman gab OpenAIs Codex ein Ziel aus sechs Wörtern, clone Excel, full feature parity, und ließ es laufen. Der Agent öffnete das echte Excel auf Bermans Rechner, studierte jede Funktion, die er finden konnte, und baute sie in einem eigenen Fenster nach. Er lief zwölf Tage unbeaufsichtigt, bis Berman ihn stoppte, und das Ergebnis war wirklich beeindruckend: verstellbare Spalten, Zellformatierung, Live-Formeln, Sortieren, etwas, das man mit zusammengekniffenen Augen für das Original halten konnte. Berman nannte es perfekt.
Aber perfekt ist hier das falsche Wort. Die Demo zeigt den Kern: eins plus zwei eingeben und drei bekommen, eine Spalte sortieren, eine Zelle formatieren. Was zwölf Tage nicht zutage fördern, ist der Rest von Excel, und der ist der größte Teil von Excel: mehrere hundert weitere Funktionen, Pivot-Tabellen, die Makrosprache, Diagramme, die Reihenfolge, in der ein Blatt neu berechnet wird, und das Dateiformat, in dem jede bestehende Tabelle bereits vorliegt. Volle Feature-Parität war die Anweisung im Prompt. Auf dem Bildschirm war sie nicht zu sehen. Der Klon reproduzierte den Teil, den man in einem Zwei-Minuten-Video sehen kann, und das war nie der schwere Teil.
Dass der Rest nicht billig zu haben ist, liegt daran, dass ein Klon, auf den jemand tatsächlich umsteigen kann, diese bestehenden Dateien lesen und schreiben und dieselben Ergebnisse berechnen muss, bis hinunter zu den Fällen, in denen Excel absichtlich falsch liegt. Der berühmte Fall: Excel behandelt 1900 als Schaltjahr und akzeptiert deshalb den 29. Februar 1900, einen Tag, den es nie gab. Microsoft hat das der Dateikompatibilität wegen von Lotus 1-2-3 übernommen und seither beibehalten, weil eine Korrektur jede Datumsseriennummer in jeder Arbeitsmappe der Welt verschieben würde. Ein Excel-Ingenieur sagte Joel Spolsky einmal, es sei die einzige Möglichkeit, Lotus-Arbeitsblätter zu importieren.
Dieser Bug ist heute eine schriftliche Anforderung im OOXML-Dateiformatstandard hinter .xlsx. Eine streng korrekte, gregorianische Implementierung ist die nicht konforme, und sie wird stillschweigend jeder echten Datei und jeder anderen Excel-Kopie widersprechen. Die Spezifikation, die Sie treffen müssen, lautet also nicht „was eine Tabellenkalkulation tun sollte“. Sie lautet „was Excel tut“, zu Anforderungen beförderte Fehler inklusive, und das Schaltjahr ist nur der Fehler, der zufällig aufgeschrieben wurde. Das übrige Verhalten, das Sie treffen müssten, steht nirgends außer im laufenden Binary.
Deshalb ist die Abdeckung der teure Teil, und es lohnt sich, genau hinzusehen, was diese zwölf Tage wirklich bewiesen haben, nämlich weniger als die Schlagzeile. Bermans Agent konnte sich am laufenden Programm prüfen, bei allem, worauf er kam, und so hat er den Kern hinbekommen. Der Long Tail ist alles, worauf niemand gekommen ist, und er ist riesig. Berman selbst meinte, der Agent könnte mit mehr Zeit irgendwann alles schaffen. Vielleicht hat er recht. Niemand hat gezeigt, dass sich der Long Tail schließt, und niemand hat gezeigt, dass er es nicht kann; das ist eine einzelne Anekdote, aufschlussreich, aber kein Beweis. Was sie sauber zeigt, ist die Form: Der Kern ist billig und schnell, und alles danach kostet zunehmend mehr.
Die Achse ist Verifikation, nicht Quellcode
Die naheliegende Art, die Lücke zwischen diesen beiden Projekten zu beschreiben, lautet „der eine hatte den Quellcode, der andere nicht“. Das kommt nah heran, zeigt aber auf die falsche Variable.
Keinen Quellcode zu haben heißt nicht, dass Sie nichts zum Prüfen haben. Selbst wenn Sie Excel anhand seines Verhaltens klonen, steht das echte Excel direkt daneben, und Sie können Zelle für Zelle vergleichen, bei jeder Eingabe, die Ihnen einfällt. Sie haben eine Referenz zum Prüfen. Was Ihnen fehlt, ist eine vollständige und billige. Die Variable, die diese Aufgaben tatsächlich ordnet, ist die Vollständigkeit und der Preis der Verifikation, nicht das Vorhandensein von Quellcode. C&C ist die gute Ecke: Die Referenz ist der Quellcode selbst, die Verifikation ist nahezu lückenlos, und jede Iteration ist ein schnelles Kompilieren und Vergleichen. Excel ist die schlechte Ecke: Die Referenz ist beobachtbares Verhalten über einen Eingaberaum, den Sie nicht ausschöpfen können, die Verifikation bleibt also partiell, und jede weitere Neun an Abdeckung kostet mehr als die vorige. Alles andere, was Leute „Klonen“ nennen, ist ein Punkt auf dieser einen Linie.
Das erklärt auch, warum Coding und Mathematik in den letzten zwei Jahren allem anderen vorausgelaufen sind, und daran ist nichts Geheimnisvolles. Das sind die Domänen, in denen eine Maschine ihre eigene Arbeit gratis prüfen kann. Code kompiliert oder eben nicht. Ein Test läuft durch oder eben nicht. Der C&C-Port funktioniert überhaupt nur deshalb in einer Schleife, weil die Schleife bei jedem Schritt einen billigen, ehrlichen Richter hat. Nehmen Sie den Richter weg oder machen Sie ihn teuer, und dasselbe Modell bleibt stecken. Reshis Hinweis, dass Opus 4.8 den Port nicht fertigstellen konnte, bis er das Modell wechselte, ist ein Datenpunkt zu den Fähigkeiten, aber er baut auf der grundlegenderen Tatsache auf, dass die Aufgabe überhaupt prüfbar war. Keine noch so hohe Modellqualität rettet eine Aufgabe, die Sie nicht billig prüfen können.
Die eigentliche Grenze des automatischen Klonens ist also die Grenze der automatischen Verifikation. Fortschritt heißt, dass Modelle in zwei bestimmten Dingen besser werden: verborgenes Verhalten von außen zu erschließen und eigene Test-Harnesses zu bauen, um eine Reproduktion gegen eine Referenz zu prüfen, wenn ihnen niemand eine in die Hand gibt. Je besser sie darin werden, sich ihre eigene Referenz aus dem Verhalten zu bauen, desto mehr verschiebt sich die Linie zwischen der C&C-Ecke und der Excel-Ecke. Sie verschiebt sich von unten nach oben. Die Spitze des Raums, wo sich Verhalten gar nicht beobachten lässt oder wo das Wertvolle nie reproduzierbare Logik war, wird durch besseres Prüfen nicht überwunden.
Sie klonen den Ausschnitt, nicht die App
All das setzt voraus, dass das Ziel die Reproduktion des Ganzen ist. Das ist es fast nie, und genau diese Annahme schmuggelt „decke alle Funktionen ab“ mit hinein. Volle Parität ist deshalb so teuer, weil ihre Spezifikation „alles, was Excel tut“ lautet, eine unbegrenzte Menge, die niemand aufgeschrieben hat. Aber Sie haben Excel heute Morgen wegen eines Budgets geöffnet, wegen eines Trackers, wegen einer Tabelle mit drei Formeln. Dieser Ausschnitt hat eine Spezifikation, die auf eine Karteikarte passt, und Sie sind die Person, die sie schreiben kann.
Wenn Sie den Umfang auf das reduzieren, was Sie nutzen, ändert sich das Problem aus den letzten beiden Abschnitten. An die Stelle der unbegrenzten, undokumentierten Oberfläche, die die Verifikation aussichtslos gemacht hat, tritt eine kleine, begrenzte Menge, die Sie vollständig kennen. Sie brauchen keine Referenz mehr, die Sie nicht bauen können, denn Sie werden selbst zur Referenz. Die paar Funktionen, die Sie wirklich nutzen, lassen sich an einem Nachmittag prüfen, und wenn Sie später eine weitere brauchen, ergänzen Sie sie im Werkzeug, statt die vierhundert nachzubauen, die Sie nie anfassen werden. Das Ergebnis ist kein eingefrorener Klon, den Sie fertigstellen müssen. Es ist ein kleines Werkzeug, das wächst, wenn Sie an eine Wand stoßen.
Deshalb ist Feature-Parität der falsche Test, wie ich ausführlicher in The End of Renting the Small Things dargelegt habe. Ein persönlicher Trello-Klon scheitert nicht daran, dass ihm die Enterprise-Administration fehlt. Er scheitert nur, wenn die Person, die ihn nutzt, Enterprise-Administration gebraucht hätte, und meistens hat die niemand gebraucht. Das ist der Wandel, der tatsächlich im Gang ist, und es ist der leise: nicht eine ganze Anwendung, aus einem Satz herbeigezaubert, sondern der nützliche Ausschnitt einer Anwendung, auf eine einzige Aufgabe zugeschnitten und erweitert, wenn sich die Aufgabe ändert.
Klonbar ist nicht dasselbe wie verdrängbar
In der Lesart „Software ist jetzt Massenware“ steckt noch eine letzte Falle, und an Excel lässt sie sich am saubersten sehen. Selbst ein perfekter Excel-Klon würde Excel nicht verdrängen.
Seit Jahren versuchen Leute, es zu ersetzen. Bloomberg hat Excel eine ganze Reportage gewidmet, als KI-resistentem Kern eines Geschäfts von mehreren Billionen Dollar, und der wiederkehrende Befund lautet, dass die Möchtegern-Nachfolger Nachahmer oder Add-ons sind, die am Ende doch Excel-kompatible Dateien erzeugen. Ein Partner von Andreessen Horowitz fasst die Startups der Kategorie so zusammen: Sie setzen alle auf Excel auf, statt es zu ersetzen. Die Rechen-Engine lässt sich knacken. Der Wert von Excel lag nie in der Rechen-Engine. Er liegt in der installierten Basis, im Dateiformat, das alle ohnehin austauschen, im Muskelgedächtnis von irgendwo zwischen 750 Millionen und einer Milliarde Nutzern und im Vertrauen, dass die Zahl in der Zelle die Zahl ist. Nichts davon erbt ein Klon am ersten Tag. Deshalb kommt der Druck auf einen solchen Platzhirsch nie als Klon. Er kommt als Erosion an den Rändern. Die kleinen Workflows, die nur deshalb bei Excel waren, weil der Bau des Ausschnitts früher zu viel kostete, wandern einer nach dem anderen ab, und der Monolith behält alles, worin ein Monolith gut ist.
Das lässt sich verallgemeinern. Wenn Reproduktion billig wird, wird der Teil zur Massenware, der prüfbar war, und das ist meist der Teil, der ohnehin am wenigsten zu verteidigen war. Den Preissturz überlebt alles, was sich einer billigen Verifikation entzieht, und dazu alles, dessen Wert nie im Code lag: die Daten, der Vertrieb, die Integrationen, die Verantwortung. Ein Modell kann das Artefakt nachbauen. Die Gründe, aus denen Menschen vom Original abhängen, kann es nicht nachbauen.
Die Zukunft von „klone das und decke alle Funktionen ab“ ist also real, aber sie ist ein Gradient, kein Schalter, und der Gradient ist Verifikation. Der Prompt funktioniert genau so gut, wie Sie „alle Funktionen“ billig und vollständig prüfen können. Wo diese Prüfung gratis ist, wie bei einem Port mit verfügbarem Quellcode und einer laufenden Referenz, liefert eine Person an einem Nachmittag aus. Wo sie partiell und unbegrenzt ist, wie beim gesamten Excel, bringen dieselben Werkzeuge Ihnen den Kern billig und verlangen für jeden weiteren Schritt mehr. Der Hebel, den die meisten übersehen: Den Umfang legen Sie selbst fest. Sie können das, was Sie reproduzieren, so weit schrumpfen, bis es prüfbar wird, und der Ausschnitt, den Sie wirklich brauchen, ist das meist schon. Die erste Frage ist also nie, welches Modell Sie nehmen. Sie lautet, wogegen Sie das Ergebnis prüfen, wie vollständig diese Prüfung ist und was jede Prüfung kostet. Diese Zahl sagt das Ergebnis besser voraus als alles im Datenblatt des Modells.
Aus dem Englischen übersetzt: zum Originalbeitrag