Der Code ist nicht mehr der Burggraben

Anfang Oktober 2026 berichtete PetaPixel über ArtCraft. Eine Community baut freie Alternativen zu bekannten Kreativ- und Büroprogrammen. Das klingt zunächst nach der nächsten Runde Vibe-Coding: beeindruckende Screenshots, ein hektisch zusammengebautes Interface und dahinter genug Klebeband, um den nächsten Klick irgendwie zu überleben.

Nur passt diese Erklärung nicht mehr. Zum betrachteten Stand vom 12. Oktober 2026 führte die ArtCraft-Projektseite zwölf Anwendungen auf: darunter Bildbearbeitung, Videoschnitt, Layout, PDF, Vektorgrafik, Audio, CAD, Textverarbeitung, Tabellen und Präsentationen. Nicht alle sind gleich weit, und nicht alle orientieren sich an Adobe oder Microsoft; SoundCraft zielt auf Pro Tools, CADCraft auf AutoCAD. Die Projekte haben eigene Repositories, gehören aber zur selben Entwicklungsgemeinschaft. Dort finden sich Rust-Code, Tests, CI, Release-Pipelines, Dateiformate, Layout-Engines und Regeln für parallele Agentenarbeit.

Beim ersten Blick übersieht man leicht etwas: Einige dieser Programme werden nicht nur mit KI gebaut, sondern auch für Agenten. Bei PhotoCraft und WordCraft greift die Agentenschnittstelle auf fachliche Funktionen zu. MCP ist dort nicht bloß ein Chatfenster, das nachträglich an eine Desktop-Anwendung geschraubt wurde.

Das Erstaunliche ist nicht ein einzelner schneller Klon. Hier entstehen verschiedene Anwendungen parallel, während die Community bereits Releases, Tests und Fehlerkorrekturen organisiert. Die Fälle sprechen für eine massive Beschleunigung der Softwareentwicklung durch KI-gestützte Agentenarbeit. Dazu kommt eine zweite Verschiebung: Agenten können beobachtbares Verhalten bestehender Software untersuchen und in neue Implementierungen übersetzen. Der ursprüngliche Quellcode muss dafür nicht verfügbar sein. Damit gerät der Vorsprung unter Druck, der bislang allein auf dem Aufwand eines Nachbaus beruhte.

Das ist kein gewöhnliches Vibe-Coding mehr

Vibe-Coding hat seinen schlechten Ruf nicht ganz unverdient. Ein Modell erzeugt Code, der Mensch probiert ihn aus, meldet den nächsten Fehler und hofft, dass die nächste Änderung nicht drei alte Fehler zurückbringt. So kann man erstaunlich schnell einen Prototyp bauen. Man kann damit ebenso schnell eine schwer wartbare Ruine errichten.

Die geprüften ArtCraft-Repositories zeigen eine andere Arbeitsweise. Sie enthalten Regeln für Agenten, abgegrenzte Subsysteme, Tests und Kommando-Architekturen. Innerhalb einer Anwendung sollen Agenten nicht irgendwo herumeditieren, sondern an definierten Komponenten arbeiten. Neue Funktionen landen als semantische Kommandos in der jeweiligen Engine.

Über die einzelnen Anwendungen hinaus entsteht gemeinsame Infrastruktur: craft-libs bietet unter anderem Druck- und UI-Bausteine; craft-common-actions wiederverwendbare Build- und Release-Abläufe. Dazu kommen Schriften und ein Launcher. Das bedeutet nicht, dass alle zwölf Anwendungen denselben Codekern verwenden oder Funktionen beliebig zwischen ihnen wandern. In den geprüften Ständen bindet PhotoCraft etwa craft-libs ein, WordCraft nicht. Gemeinsam sind vor allem Projektumfeld und Teile der Arbeitsweise; die fachlichen Engines und ihre Probleme müssen wir getrennt betrachten.

Hier arbeiten nicht einfach Entwickler mit einem schnelleren Codeassistenten. Viele Beiträge entstehen parallel an Formaten, Layout, Oberfläche, Import, Export und Tests; Menschen und Agenten müssen diese Arbeit integrieren und prüfen. Ob die Ergebnisse tragen, entscheidet sich weiterhin an dieser Prüfung. Neu ist der Maßstab, in dem die Community mehrere Anwendungen zugleich vorantreibt.

Wir haben diese Organisationsentwicklung schon an anderer Stelle gesehen. In Die Agenten bauten sich eine Organisation ging es darum, wie Agenten Rollen, Arbeitsteilung und eigene Koordination entwickeln. ArtCraft zeigt nun die weniger theoretische Seite davon: Am Ende fällt tatsächlich Software aus der Fabrik.

Zwölf Anwendungen gleichzeitig

Der Blick auf nur ein Repository verfehlt die Größenordnung. Am 12. Oktober 2026 führten die jeweiligen Repository-Roadmaps neun der zwölf ArtCraft-Anwendungen als Alpha; DesignCraft, SoundCraft und CADCraft standen noch auf Pre-Alpha. Das sind Selbsteinstufungen der Projekte, keine unabhängigen Produkttests. Alle zwölf hatten öffentliche Releases. Eine gemeinsame Release-Welle lag zwischen dem 10. Oktober um 23:50 Uhr und dem 11. Oktober um 02:12 Uhr UTC, also innerhalb von rund zwei Stunden und 22 Minuten. Bis zur Veröffentlichung dieses Artikels am 12. Oktober hatten sieben Projekte bereits weitere Releases nachgeschoben. Das zeigt einen anhaltenden Veröffentlichungstakt über Bildbearbeitung, Video, Audio, CAD, PDF und Bürosoftware hinweg, nicht nur einen Glückstreffer eines einzelnen Repositories.

Die Kombination aus kurzer Entwicklungszeit, Funktionsbreite und parallelem Aufbau mehrerer Anwendungen ist der entscheidende Befund. Agentenarbeit steht hier nicht außerhalb der Entwicklung, sondern ist Teil ihrer Arbeitsteilung und Integration. Das spricht für einen erheblichen Beschleuniger, nicht bloß für schnelleres Tippen. Wie viel des Tempos auf Agenten, menschliche Arbeit, vorhandene Bibliotheken und automatisierte Integration entfällt, lässt sich aus den Repositories nicht beziffern. Daraus folgt aber nicht, dass die Beschleunigung erst relevant wäre, wenn jedes Produkt die Tiefe seines Vorbilds erreicht.

Der historische Maßstab ist nicht irgendein Wochenendprojekt. Affinity Photo erschien 2015 und wurde anschließend über Jahre weiterentwickelt. LibreOffice wurde 2010 als Fork von OpenOffice.org angekündigt. OpenOffice.org ging wiederum aus StarOffice hervor; die Produktfamilie reicht über StarWriter von 1985 bis in die Achtzigerjahre zurück. Die heutige Reife dieser Programme mit jungen Alphas gleichzusetzen wäre Unsinn. Der Vergleich zeigt die Größe der Aufgabe, nicht eine gemessene Zeitersparnis gegenüber einem identischen Entwicklungsprojekt.

Während PhotoCraft die Schlagzeilen bekommt, wachsen zwei besonders sperrige Bereiche mit. LightCraft nimmt sich Fotokatalog, nichtdestruktive Entwicklung und RAW-Dateien vor – samt der mühsamen Vielfalt aus Kameras, Farbprofilen und Objektiven. PdfCraft will nicht nur PDFs anzeigen, sondern Seiten umordnen, Formulare bearbeiten, kommentieren und vorhandene Inhalte verändern. Gerade hier wird es hässlich: Das Projekt nennt die zuverlässige Bearbeitung bestehenden Textes, besonders bei CJK- und Rechts-nach-links-Schriften, in seiner eigenen Roadmap ausdrücklich als offene Baustelle. Das ist genau der Bereich, in dem ein echter Acrobat-Ersatz seinen Wert erst beweisen muss. Dass parallel überhaupt schon eine solche PDF-Anwendung als Alpha entsteht, ist Teil der Nachricht.

PhotoCraft: viel Technik in kurzer Zeit

PhotoCraft ist der Photoshop-artige Teil der Suite. Im geprüften Quellstand umfasste das Repository mehr als 1.100 Rust-Dateien, rund 421.000 nichtleere Rust-Zeilen, 25 Bibliotheks-Crates und mehr als 6.000 Testfunktionen. Von den Crates sind 24 fachlich getrennte Bausteine; hinzu kommt die gemeinsame Testinfrastruktur testkit. Die Commit-Historie zeigte weit über tausend Commits und Hunderte Autorenkennungen. Solche Kennungen sagen nichts Verlässliches über die Zahl der beteiligten Menschen aus.

Zeilen, Commits und Testfunktionen sind kein Produkttest. Viele Commits können ebenso gut von Integrationsproblemen erzählen. Der öffentlich einsehbare Quellbaum zeigt aber mehr als eine hübsche Oberfläche über ein paar Bildfiltern. Die Tests haben wir für diese Betrachtung nicht selbst ausgeführt.

Im Quellcode finden sich eine eigene Bild- und Dokumentarchitektur, CPU- und GPU-Compositing, Ebenen, Masken, Auswahlwerkzeuge, Farbverarbeitung und Dateiformate. Auch echte PSD-Dateien werden nicht bloß als flache Vorschau geöffnet: Das Projekt dokumentiert Tests mit geschichteten Dateien und den erneuten Import nach dem Speichern. Nach seiner eigenen Roadmap ist PhotoCraft trotzdem Alpha. Die Selbsteinschätzung „ready for real work“ liegt bei etwa 45 Prozent. Vor allem der Rückweg nach Photoshop ist noch nicht verlässlich: Eine Datei kann in PhotoCraft funktionieren und nach dem Speichern in Photoshop scheitern. Das sind verschiedene Anforderungen an PSD-Kompatibilität.

Der Takt ist selbst Teil der Geschichte. PhotoCraft begann am 30. September 2026, veröffentlichte am 11. Oktober Version 0.7.0 und bereitete am 12. Oktober schon 0.8.0 vor. An diesem Tag standen um 13:49 Uhr UTC bereits 175 neue Commits auf dem Hauptzweig. Zugleich laufen Integration, Tests und Release-Builds für mehrere Plattformen; einzelne Builds können scheitern.

In der öffentlichen GitHub-Monatsübersicht stand die Autorenkennung claude am 12. Oktober 2026 mit mehr als 1.500 Commits an der Spitze der Top-Committer-Grafik. Die Grafik zeigt nur die 15 führenden Kennungen, keine vollständige Aufteilung aller Commits. PetaPixel berichtet zudem, der Entwickler habe den Einsatz von Anthropic Opus 5.5 beschrieben. Agentenarbeit ist damit ein sichtbar großer Teil der Commit-Aktivität, nicht bloß eine Vermutung aus dem Projekttempo. Ein Commit ist aber kein Qualitätsbeweis und keine Maßeinheit für menschliche oder agentische Entwicklungsleistung. Das außergewöhnliche Tempo lässt sich dennoch nicht als gewöhnliches Prototyping abtun.

WordCraft: eine Textverarbeitung in wenigen Tagen

Noch deutlicher wird es bei WordCraft. Der erste Commit stammt in der gespeicherten Autorzeitzone vom 5. Oktober 2026, entsprechend dem 6. Oktober um 00:23 Uhr UTC. Binnen weniger Tage enthielt das Repository im geprüften Stand bereits rund 120.000 nichtleere Rust-Zeilen, 16 Bibliotheks-Crates, drei Anwendungen und mehr als 1.200 Testfunktionen.

Der Quellcode enthält ein eigenes Dokumentmodell, Undo und Redo, Textlayout, Seitenumbruch, Tabellen, Fußnoten, Kommentare, Änderungsverfolgung, Formatvorlagen, Referenzen, Serienbriefe, PDF-Ausgabe und Import beziehungsweise Export mehrerer Dokumentformate. Bei DOCX reicht die Implementierung über das Entpacken einer ZIP-Datei mit Text hinaus: Sie behandelt OOXML-Strukturen für Abschnitte, Tabellen, Kopf- und Fußzeilen, Kommentare, Revisionen, Formen, Textboxen, Gleichungen, Charts, SmartArt und eingebettete Objekte. Auch verschlüsselte DOCX-Dateien und das alte binäre Word-Format tauchen im Code auf, allerdings nicht als Nachweis vollständiger Kompatibilität.

In seiner eigenen Reifegradanalyse nennt sich das Projekt Alpha und schätzt sich auf etwa 60 Prozent „ready for real work“. Die Zahl ist keine gemessene Produktreife: Ein Wechsel der Bewertungsmethode verschob sie zwischen etwa 47 und 60 Prozent, ausdrücklich ohne neue Produktevidenz. Die Entwickler nennen die fehlende Prüfung mit einem realen DOCX-Korpus, Unterschiede bei Seitenumbrüchen, Stabilitätsprobleme, unvollständige internationale Rechtschreibprüfung und das nicht vorhandene Office-Ökosystem. Natives Desktop-Drucken wurde am 12. Oktober über craft-print integriert; Treiberoptionen und die Ausgabe auf echten Druckern sind noch nicht hinreichend geprüft.

Microsoft Word ist nicht binnen weniger Tage ersetzt worden. In dieser Zeit entstand aber eine eigenständige Textverarbeitung mit einer erstaunlich breiten technischen Basis. Die Alpha ist der sichtbare Zwischenstand, nicht die ganze Bedeutung dieses Falls: Dokumentmodell, Layout und Formatbehandlung müssen nicht mehr erst über einen langen Vorlauf aufgebaut werden, bevor überhaupt ein ernsthafter Nachbau beginnt. Wie viel davon im Alltag belastbar ist, entscheidet sich anschließend an realen Dokumenten, Stabilität und Kompatibilität.

MCP ist hier kein angeklebter Chatbot

Der vielleicht wichtigste Teil von ArtCraft steckt nicht in den Screenshots. In WordCraft und PhotoCraft gilt sinngemäß: Alles ist ein Kommando.

Oberfläche, Tastenkürzel, Kommando-Suche, CLI, Makros, JSON-Control-Channel und MCP-Server greifen innerhalb der jeweiligen Anwendung auf deren fachliche Kommando-Engine zu. Ein Agent muss nicht auf Pixelkoordinaten herumklicken und hoffen, dass der Button noch an derselben Stelle sitzt. Er kann ein Dokument öffnen, Text auswählen, Formatierungen ändern, Tabellen erzeugen, den strukturellen Zustand untersuchen, Seiten rendern und das Ergebnis speichern.

Die grafische Oberfläche ist damit nur ein Zugang zur Engine. Ein Skript oder Agent kann dieselben fachlichen Kommandos nutzen, statt die Oberfläche nachzuahmen.

Das verändert nicht nur die Herstellung der Programme. Die Anwendungen werden selbst zu Werkzeugen für weitere Automatisierung. Wer solche Schnittstellen freigibt, muss freilich auch Berechtigungen, Eingaben und Seiteneffekte kontrollieren. Eine Kommando-Engine macht einen Agenten verlässlicher bedienbar, nicht automatisch sicher.

Fallout in fünf Tagen

Ein anderer Fall zeigt, wie weit strukturierte Agentenarbeit selbst bei Spielen reichen kann. Der Entwickler von Fallout: New York beschrieb, wie er innerhalb von fünf Tagen ein umfangreiches Browserspiel erzeugen ließ. Nach seinen Angaben arbeiteten zeitweise bis zu zwölf Agenten parallel. Es gab Builder, Kritiker, Überarbeiter, Verifizierer und einen Integrationsagenten. Der Entwickler berichtete von rund 580 Agentenläufen in 20 Workflows.

Nach dem Entwicklerbericht war die Anwendung spielbar, aber keineswegs fehlerfrei oder inhaltlich so tief wie ein über Jahre entwickeltes Rollenspiel. Die Fallout-Version ist inzwischen offline; ein öffentliches Source-Repository ist nicht verfügbar. Ob Quellcode zuvor öffentlich zugänglich war, ist nicht belegt. Die Mengenangaben lassen sich daher nicht unabhängig reproduzieren und bleiben Angaben des Entwicklers.

Nach Darstellung des Entwicklers seien Modelle, Texturen und Sounds neu erzeugt worden. Diese Herkunft lässt sich heute nicht unabhängig prüfen; ob vorhandener Fallout-Code untersucht wurde, bleibt ebenfalls offen. Auch New York war keine bereits vorhandene Fallout-Spielwelt. Die Nähe zum Franchise war trotzdem gewollt: Der Auftrag lautete „exactly like Fallout“, mit Pip-Boy, V.A.T.S., S.P.E.C.I.A.L., Vault-Tec und Nuka-Cola. Der nachträglich ergänzte Disclaimer nennt die Marken selbst. Laut Entwickler folgte eine Unterlassungsaufforderung. Neue Assets beantworten weder die Frage nach der Code-Herkunft noch die nach Marken und Produktidentität. Technisch möglich, rechtlich doof.

REA und Replica machen aus Beobachtung einen Prozess

ArtCraft zeigt den Aufbau neuer Software entlang bekannter Anwendungsklassen. REA und Replica ergänzen die Rekonstruktionsseite: bestehende Software untersuchen, Verhalten und Struktur beschreiben, daraus eine Implementierung ableiten und sie mit dem Original vergleichen. Dabei sind Beobachtung von außen und Binäranalyse verschiedene Zugänge. Keiner setzt voraus, dass der ursprüngliche Quellcode öffentlich vorliegt.

REA stellt Agenten Werkzeuge für Binäranalyse, Pseudocode, Call Graphs, Referenzen sowie Browser-, Netzwerk- und Laufzeitanalyse zur Verfügung. Wichtiger als die Werkzeugliste ist die Trennung von Beobachtung, Ableitung, Schlussfolgerung und Unbekanntem: Aus einer Untersuchung soll eine nachvollziehbare Evidenzkette werden, nicht bloß eine überzeugend klingende Modellantwort. Das Projekt dokumentiert auch begrenzte Rekonstruktionen. Beim DX-Ball-Fall wurde eine Berechnung für die räumliche Tonposition aus dem Binärcode in C rekonstruiert; laut Fallstudie stimmen die Ergebnisse in 3.205 Vergleichsfällen und die 63 kompilierten Funktionsbytes mit dem Original überein. Das ist ein konkreter Funktionsnachbau, kein vollständiger Spielklon und kein von uns ausgeführter Test.

Replica beschreibt den Ablauf für einen Nachbau: Anwendung vermessen, Zielarchitektur ableiten, implementieren, visuell und funktional vergleichen. Ein Agent kann Bedienfolgen und Zustände erfassen, ein anderer die entsprechenden Funktionen implementieren und ein weiterer Abweichungen zum Original prüfen. So wird beobachtbares Verhalten zur schrittweise vervollständigten Spezifikation. Das Repository beschreibt diesen Arbeitsprozess, enthält aber keinen nachprüfbaren fertigen Fremdprodukt-Klon. Werkzeug, Methode und erfolgreicher Nachbau bleiben verschiedene Belegstufen.

AnyPS5: der Extremfall

AnyPS5 treibt diese Entwicklung in einen Bereich, der bisher hoch spezialisierten Teams vorbehalten war. Das Projekt arbeitet an Binärformaten, Systembibliotheken, ABI-Rekonstruktion, Shaderübersetzung und nativen Zielprogrammen für Linux und Windows. Der Relinker kann auch macOS-Ausgabe erzeugen; die dafür nötige Laufzeit ist im Hauptzweig noch nicht vollständig integriert.

Der geprüfte Stand umfasste mehr als 5.000 Commits und Hunderte Autorenkennungen. Autorenkennungen sind keine Kopfzahl. Auch die schiere Menge beweist keine vollständige Kompatibilität; das Repository dokumentiert selbst zahlreiche technische Schulden und unbekannte Verhaltensweisen.

Wichtiger ist der Produktionsmodus. Der Projektgrundsatz verlangt, nicht unterstütztes Verhalten sichtbar scheitern zu lassen, statt fehlendes Wissen mit plausibel klingenden Stubs zu verdecken. Die Regeln erlauben allerdings eng begrenzte Silent Stubs, wenn sie einen Titel freischalten und nur UI-Verhalten betreffen; diese müssen als technische Schuld dokumentiert werden. Dokumentierte Ausnahmen existieren bereits, darunter Audio-Aufrufe, die Erfolg zurückgeben, ohne die entsprechenden Befehle zu erzeugen. Die Regel ist also kein ausnahmsloser Ist-Zustand. Entscheidend ist, dass solche Lücken sichtbar bleiben: Ein Sprachmodell kann aus fehlendem Wissen sehr leicht eine überzeugende Fiktion erzeugen.

Sichtbarer Code, offene Rechtsfragen

Dieser Artikel entscheidet nicht, welches dieser Projekte rechtlich zulässig ist. Dafür unterscheiden sich Ziele, Methoden, verwendete Materialien, Lizenzen und Rechtsordnungen zu stark. Wir sind weder Richter noch auf einmal Juristen, nur weil wir ein paar Repositories gelesen haben.

Technisch behandeln die Beispiele unterschiedliche Aufgaben: neue Anwendungen, Funktionsrekonstruktion, Kompatibilitätsarbeit und ein nur begrenzt überprüfbares Spielprojekt. Sie sind keine gleichwertigen Beweise für vollständige Produktklone. Sie zeigen aber, wie Agenten Implementierung und Analyse übernehmen können. Produktreife und die Zulässigkeit des konkreten Einsatzes folgen daraus nicht automatisch.

Der Fallout-Fall zeigt, dass behauptete technische Eigenständigkeit Fragen nach Marken und Produktidentität nicht erledigt. Bei ArtCraft liegt die Sache anders: WordCraft und PhotoCraft setzen auf eigenen Code und nach Projektdarstellung auf eigene oder offen lizenzierte Assets. Zugleich orientieren sie sich bewusst an bekannten Arbeitsabläufen und Dateiformaten etablierter Anwendungen. Welche rechtlichen oder wirtschaftlichen Antworten Microsoft und Adobe erwägen, wissen wir nicht. Aus einer Ähnlichkeit folgt weder eine Rechtsverletzung noch, dass die Hersteller bereits Schritte vorbereiten.

REA und Replica sind ebenfalls nicht automatisch rechtswidrig. Dieselben Werkzeuge können bei Malwareanalyse, Sicherheitsforschung, Migration oder Interoperabilität helfen – oder zum Nachbau fremder Produkte und zur Untersuchung von Schutzmechanismen dienen. Die Werkzeuge und Verfahren sind öffentlich dokumentiert. Was sie in einem konkreten Einsatz leisten und wie dieser rechtlich zu bewerten ist, bleibt eine andere Frage.

Die Entwicklung wartet allerdings nicht auf eine abschließende juristische Einordnung. Repositories können sich täglich ändern; belastbare Regeln und Rechtsprechung entstehen langsamer. Das macht präzise technische Beschreibungen wichtiger, nicht rechtliche Schnellurteile.

Was verliert hier eigentlich seinen Wert?

Software wird nicht wertlos. Auch Entwickler werden nicht plötzlich überflüssig. Unter Druck gerät der Vorsprung durch sichtbare Funktionen allein.

Wenn eine Anwendung öffentlich zeigt, wie sie sich verhält, lässt sich dieses Verhalten beobachten, beschreiben und schrittweise neu implementieren. Dateiformate liefern Struktur, Screenshots visuelle Ziele, Handbücher und Tutorials die Bedienlogik. Die ursprüngliche Implementierung kann dabei verborgen bleiben. Mit Agenten lässt sich der Weg von der Beobachtung zur Implementierung und zum Vergleich immer stärker automatisieren. Das ergibt keine vollständige Spezifikation: Unsichtbare Sonderfälle und reale Testdaten fehlen oft. Aber ein laufendes Produkt liefert mehr Bauanleitung, als vielen Herstellern lieb sein dürfte.

Knapp bleiben andere Dinge:

  • reale Daten und Testkorpora,
  • jahrzehntelang gesammelte Edge Cases,
  • Distribution und bestehende Kundenbeziehungen,
  • Marken, Rechte und Lizenzen,
  • Vertrauen, Support und stabiler Betrieb,
  • Integration in Unternehmen und bestehende Prozesse,
  • und die Verantwortung, wenn das Produkt im Alltag versagt.

Das sind keine kleinen Restposten. Sie entscheiden, ob aus einem beeindruckenden Alpha ein Produkt wird, dem Menschen ihre Fotos, Verträge, Abschlussarbeiten oder Unternehmensdaten anvertrauen.

Der technische Burggraben wird damit dort flacher, wo bisher vor allem der Implementierungsaufwand geschützt hat. Ein Nachbau muss nicht jeden Sonderfall seines Vorbilds beherrschen, um für einen begrenzten Einsatz brauchbar zu sein. Wie schnell daraus belastbare Konkurrenz entsteht, hängt von der Anwendung ab. Doch „Das nachzubauen dauert ohnehin Jahre“ ist keine verlässliche Verteidigung mehr.

Software bleibt. Ihre Herstellung verändert sich.

Bei ArtCraft liegt die Verschiebung im Maßstab: zwölf verschiedene Codebasen werden unter ähnlichen organisatorischen Bedingungen parallel vorangetrieben. PhotoCraft und WordCraft sind getrennte technische Implementierungen, nicht zwei Oberflächen derselben Engine. Fallout: New York ergänzt einen Entwicklerbericht über ein improvisiertes Spielestudio. AnyPS5 zeigt einen großen, offenen Versuch im Bereich Kompatibilität und Reverse Engineering; REA dokumentiert begrenzte Funktionsrekonstruktionen, Replica den Arbeitsablauf für weitergehende Nachbauten. Die Fälle haben unterschiedliche Reichweiten. Zusammen ergeben sie ein starkes Indiz dafür, dass KI nicht nur einzelne Codeaufgaben, sondern umfangreiche Entwicklungsarbeit erheblich beschleunigt.

Ein belastbarer Beschleunigungsfaktor lässt sich daraus nicht berechnen. Ebenso wenig sind Rechenkosten, menschliche Prüfung und spätere Wartung verschwunden. Die Entwicklung verändert sich schon vor dem fertigen Produkt: KI-gestützte Agentenarbeit verkürzt den Aufbau komplexer Implementierungen und macht den Nachbau beobachtbaren Softwareverhaltens praktikabler. Die breiten Alphas sind ein sichtbarer Zwischenstand dieser Veränderung. Dass Produktionsreife noch Arbeit verlangt, widerlegt die Beschleunigung nicht.

Software bleibt. Doch der bloße Besitz sichtbarer Funktionen schützt immer weniger. Was ein Produkt vorführt, kann zur Vorlage eines Nachbaus werden; Agenten übernehmen zunehmend die Arbeit zwischen Vorlage und neuer Implementierung. Der Vorsprung verschiebt sich zu den Dingen, die sich nicht so leicht beobachten und reproduzieren lassen: reale Daten, seltene Sonderfälle, verlässlicher Betrieb und das Vertrauen der Kunden.

Projekte und Berichte

Weitere Beiträge

Zum Blog-Archiv →