Großes Software-Projekt mit KI 🚀

Ein Selbstversuch mit KI in der professionellen Enterprise-Softwareentwicklung

In den letzten Jahren sind wir auf YouTube und in sozialen Netzwerken immer wieder mit denselben Schlagzeilen konfrontiert worden:
„Baue eine App in 10 Minuten nur mit Sprache!“
„Kein Coding mehr nötig!“
„Jeder kann jetzt Software entwickeln!“

Das klingt spektakulĂ€r – und ist fĂŒr viele beeindruckend. Aber fĂŒr Menschen, die tagtĂ€glich in der professionellen Softwareentwicklung arbeiten, haben solche Aussagen meist nur begrenzten Wert. Denn die RealitĂ€t in Unternehmen sieht anders aus: Dort geht es nicht um kleine Demo-Apps, sondern um große Architekturen, komplexe Anforderungen, hohe QualitĂ€tsansprĂŒche, Dokumentation, Tests, DevOps, Integrationen und belastbare Systeme, die dauerhaft funktionieren mĂŒssen.

Genau hier setzt das im Video beschriebene Experiment an. Der Autor wollte nicht wissen, ob KI eine hĂŒbsche kleine Demo erzeugen kann. Er wollte wissen:

Die Antwort darauf ist so drastisch, dass sie selbst den Autor nach eigener Aussage „nicht schlafen lĂ€sst“.

https://youtu.be/eLDHrqKplVI

Ausgangspunkt: Eine reale Enterprise-Frage statt YouTube-Hype

Der Kern des Experiments ist im Grunde einfach formuliert, aber enorm anspruchsvoll:

Was passiert, wenn man eine große, echte, fachlich relevante Anwendung mit allem, was in professioneller Softwareentwicklung dazugehört, von Anfang bis Ende mit maximalem KI-Einsatz neu entwickelt?

Dabei ging es ausdrĂŒcklich nicht um eine Spielerei. Es ging um ein reales System: die ĂŒber viele Jahre gewachsene private Backoffice- und Buchhaltungsanwendung des Autors. Eine Software, die er seit rund 18 Jahren verwendet, um Rechnungen, Belege, Kundenverwaltung und weitere GeschĂ€ftsprozesse abzubilden.

Diese Anwendung war allerdings technisch stark veraltet – eine alte .NET-Framework-Anwendung mit ĂŒberholter UI-Technologie. Funktional erledigte sie zwar ihren Grundzweck, aber nur in einem Umfang, der im Laufe der Jahre eher pragmatisch gewachsen als strategisch geplant war. Viele Funktionen, die eigentlich sinnvoll gewesen wĂ€ren, wurden nie umgesetzt.

Das Experiment bestand also nicht nur darin, diese Anwendung neu zu bauen, sondern sie gleichzeitig massiv zu erweitern. Das Ergebnis war am Ende eine Anwendung mit etwa dem 12- bis 15-fachen Funktionsumfang der alten Lösung. 😳

Warum dieses Experiment so relevant ist

Viele Unternehmen stehen heute an einem Wendepunkt. KI wird zwar schon genutzt, aber meist nur punktuell:

Was in den meisten Teams aber noch fehlt, ist ein durchgĂ€ngiger KI-unterstĂŒtzter Software-Lifecycle. Also die Frage:

Was passiert, wenn KI nicht nur beim Coden hilft, sondern durchgÀngig bei
Anforderungen, Architektur, Implementierung, Tests, Dokumentation und Betrieb eingebunden wird?

Genau das wurde in diesem Selbstversuch untersucht. Und das Spannende ist: Der Autor beschreibt einen entscheidenden technischen Wendepunkt Ende 2025 / Anfang 2026.

Der eigentliche Game Changer: Modelltreue gegenĂŒber Richtlinien 🧠

Aus Sicht des Autors ist der große Durchbruch nicht einfach nur „bessere Codegenerierung“.
Der wirkliche Wendepunkt war etwas anderes:

KI-Modelle wurden plötzlich deutlich besser darin, Richtlinien und Vorgaben zuverlÀssig einzuhalten

FrĂŒhere Modelle konnten zwar bereits brauchbaren Code generieren, aber bei grĂ¶ĂŸeren Projekten zeigte sich oft ein bekanntes Problem:

Mit der neuen Modellgeneration Anfang 2026 Ă€nderte sich das offenbar massiv. Der Autor beschreibt, dass Modelle ab etwa der neuen Generation – er nennt als Beispiel „Opus 4.5“ – plötzlich deutlich besser darin waren, sich penibel an vorgegebene Guardrails, Richtlinien und QualitĂ€tsmaßstĂ€be zu halten.

Und genau das ist in professioneller Softwareentwicklung entscheidend.

Nicht der Umstand, dass KI irgendeinen Code generiert, ist revolutionĂ€r – sondern dass sie den Code in der gewĂŒnschten Architektur, im gewĂŒnschten Stil und in der gewĂŒnschten QualitĂ€t generieren kann.

Das ist der Unterschied zwischen einem Gimmick und einem industriell nutzbaren Werkzeug. ⚙

Das Projekt: Eine komplette Business-Plattform statt nur ein Tool

Die neue Anwendung sollte nicht einfach nur die alte Buchhaltungssoftware ersetzen. Sie sollte zu einem vollstĂ€ndig integrierten System werden, das mehrere Bereiche zusammenfĂŒhrt.

Geplante Bestandteile des Systems

1. Backoffice-System

Das Backoffice ist das HerzstĂŒck der Anwendung. Hier werden unter anderem verwaltet:

Im Vergleich zur alten Anwendung sollte dieses Backoffice deutlich umfangreicher, moderner und besser integriert sein.

2. Neue Homepage

Die bestehende Website des Autors war bislang von der Backoffice-Welt entkoppelt. Eingehende Anfragen mussten manuell ĂŒbertragen werden. Die neue Lösung sollte daher Website und interne Systeme direkt miteinander verbinden.

Mögliche Funktionen der neuen Website:

3. Customer Area

ZusÀtzlich wurde ein Kundenbereich vorgesehen, in dem Kunden selbststÀndig mit dem System interagieren können, etwa um:

4. KI-Agent fĂŒr BĂŒroautomation

Das eigentliche langfristige Ziel des Projekts geht aber noch weiter:
Der Autor möchte den Großteil seiner ungeliebten BĂŒroarbeit automatisieren. 😅

DafĂŒr wurde ein KI-Agent namens Hermes vorgesehen, der spĂ€ter ĂŒber APIs auf das System zugreifen und viele Aufgaben autonom erledigen soll, zum Beispiel:

Das Ziel: 80–90 % der BĂŒroarbeit bis Ende 2026 automatisieren.

Besonders wichtig dabei: Diese KI soll lokal laufen und nicht in der Cloud, weil sensible Kundendaten verarbeitet werden. Datenschutz und Vertraulichkeit sind hier also zentrale Anforderungen 🔒

Die Architektur: bewusst „Enterprise“ gedacht

Der Autor betont mehrfach, dass er bewusst eine Enterprise-Architektur gewĂ€hlt hat – nicht weil er sie fĂŒr sein eigenes kleines GeschĂ€ft zwingend gebraucht hĂ€tte, sondern weil er das Experiment auf ein professionelles Niveau heben wollte.

Architekturentscheidungen im Überblick

Microservices

Statt eines Monolithen wurde eine Microservice-Architektur aufgebaut. Fachlich wĂ€re das fĂŒr das konkrete Problem nicht zwingend nötig gewesen. Aber als Architekturbeispiel fĂŒr professionelle Systeme – und auch fĂŒr spĂ€tere Workshops – war es eine spannende Wahl.

API Gateway

Vor die Services wurde ein API-Gateway gesetzt, umgesetzt mit Traefik.

Drei Frontends / Clients

Auf dem Gateway sitzen drei Haupt-Clients:

Workflow Engine mit n8n

Unterhalb der Clients wurde eine Workflow Engine auf Basis von n8n integriert. Diese ĂŒbernimmt die Orchestrierung von GeschĂ€ftsprozessen und die Verarbeitung von Domain-Events.

Beispielsweise können Services Domain-Events auslösen, die anschließend durch Workflows weiterverarbeitet werden.

Externe Integrationen

ZusÀtzlich wurden externe Systeme eingebunden, etwa:

Damit entstehen realistische Business-Prozesse, wie sie in vielen Unternehmen tÀglich vorkommen.

Lokale KI-Infrastruktur

FĂŒr den autonomen KI-Agenten wurde eine lokale KI-Lösung auf eigener Hardware aufgebaut. Genannt wird ein Modell von Alibaba/Qwen mit 36 Milliarden Parametern. Dieses wird ĂŒber einen MCP-Server in die interne Infrastruktur eingebunden, sodass der Agent definierte Systemoperationen ausfĂŒhren kann.

Das ist besonders spannend, weil es zeigt, dass KI hier nicht nur als Chat-Funktion gedacht wird, sondern als aktiver Systemakteur in einer realen Business-Architektur.

Auch DevOps wurde ernst genommen đŸ› ïž

Ein hĂ€ufiges Problem vieler KI-Demos ist, dass sie sich fast nur auf Code konzentrieren. In echten Projekten reicht das natĂŒrlich nicht. Deshalb wurde auch der DevOps-Bereich realitĂ€tsnah abgebildet.

Umgebungen

Es gab zwei zentrale Umgebungen:

Infrastruktur

Die Infrastruktur lief nicht auf einer großen Enterprise-Serverlandschaft, sondern pragmatisch auf:

Entwicklungssetup

Die KI-Coding-Agents hatten Zugriff auf:

Das heißt: Die Agents konnten nicht nur Code generieren, sondern ihn auch direkt deployen, starten, Logs prĂŒfen und Fehler analysieren.

Git & Build

Verwendet wurde Gitea/Gitty als leichtgewichtige GitLab-Alternative. Von dort aus wurden Builds in Test- und Produktionsumgebungen verteilt.

SSH-Zugriffe

Der KI-Agent bekam weitreichende Rechte auf der Testumgebung und eingeschrÀnkte Rechte auf Produktion. Besonders interessant: Er konnte Produktions-Logs auswerten, um Probleme zielgerichtet zu analysieren.

Das ist ein sehr realistisches Setup, weil es genau in die Richtung geht, in die moderne AI-Assisted-Development-Workflows aktuell wandern:
Nicht nur generieren, sondern beobachten, prĂŒfen, anpassen und operativ unterstĂŒtzen.

Die QualitĂ€tssicherung: Tests als zentrales Fundament ✅

Der Autor wollte nicht nur „funktionierenden Code“, sondern nachweisbar belastbare QualitĂ€t. Deshalb spielte das Thema Testing eine zentrale Rolle.

Fokus auf zwei Testarten

1. API-Tests

Die einzelnen Microservices wurden ĂŒber ihre Endpunkte getestet. Dabei wurden nicht nur Responses verifiziert, sondern auch:

2. Workflow-Tests

Da n8n eine wichtige Rolle spielte, wurden auch komplette Workflows getestet – inklusive Zusammenspiel mehrerer Services und Datenbanken.

Dabei wurden echte Testdaten verwendet, um sicherzustellen, dass die orchestrierten GeschÀftsprozesse korrekt funktionieren.

Mocking externer Systeme

Externe Systeme wie Office 365 oder Google konnten natĂŒrlich nicht eins zu eins in der Testumgebung laufen. Deshalb wurde WireMock genutzt, um externe Aufrufe abzufangen und kontrollierte Mock-Antworten zurĂŒckzugeben.

Damit entstand eine Testumgebung, in der die fĂŒr den spĂ€teren KI-Agenten wichtigsten Komponenten – Backend und Workflows – realistisch und ausreichend abgesichert werden konnten.

Die eigentliche Methodik: Vom Prompting zum Voice Driven Development đŸŽ™ïž

Einer der spannendsten Teile des Videos ist die Beschreibung, wie sich die Arbeitsweise im Laufe des Projekts verÀndert hat.

Der Autor beschreibt im Grunde fĂŒnf Entwicklungsphasen.

Phase 1: Micromanagement

Am Anfang arbeitete er klassisch promptbasiert:

Das ist die Art, wie viele heute mit KI arbeiten. Sie funktioniert – aber sie ist kleinteilig, anstrengend und oft ineffizient. Gerade in großen Projekten fĂŒhrt sie schnell dazu, dass das Modell Code und Strukturen erzeugt, die nicht wirklich zum Gesamtbild passen.

Phase 2: Quality Driven Development

Hier kam der sogenannte Harness ins Spiel.

Was ist ein Harness?

Der Harness ist im Grunde ein Satz von Regeln, Vorgaben und Kontextdateien, die dem Modell erklÀren:

Man kann sich das wie Leitplanken fĂŒr das Modell vorstellen.

ZusÀtzlich wurden statische Analysewerkzeuge eingebunden, insbesondere:

Dadurch wurde nicht nur „gefĂŒhlt“ geprĂŒft, ob der Code passt, sondern toolgestĂŒtzt.

Der entscheidende Wechsel war:
Nicht mehr der Mensch korrigiert stÀndig den Code, sondern der Mensch verbessert schrittweise den Harness, bis das System konsistent gute Ergebnisse liefert.

Das ist ein enorm wichtiger Gedanke. 💡
Der Entwickler schreibt nicht mehr nur Code – er gestaltet das Produktionssystem fĂŒr Code.

Phase 3: Spec Driven Development

Im nĂ€chsten Schritt wurden nicht mehr nur Prompts ĂŒbergeben, sondern Spezifikationen, also fachliche Anforderungen in Story-Form.

Das Modell lernte, wie es aus Anforderungen:

Das ist der Übergang von „Schreibe mal diese Funktion“ zu „Hier ist die Story – setze sie professionell um“.

Phase 4: Test Driven mit KI

Hier wurde Testing auf eine neue Stufe gehoben. Tests wurden nicht auf Basis des bereits existierenden Quellcodes generiert, sondern direkt aus Anforderungen und Akzeptanzkriterien abgeleitet.

Das ist ein fundamentaler Unterschied.

Viele KI-Demos zeigen:

  1. Code ist da
  2. KI generiert Tests dafĂŒr

Das ist nett, aber im Grunde testet man damit oft nur das bereits implementierte Verhalten.

In diesem Experiment ging es darum, dass Tests das gewĂŒnschte Systemverhalten verifizieren – also das, was aus den Anforderungen hervorgeht.

So wurde das System zunehmend spezifikationsgetrieben.

Phase 5: Idea Driven und Voice Driven Development

Hier wird es wirklich radikal.

Der Autor beschreibt, dass sich seine Rolle immer weiter verschoben hat:

Am Ende konnte er Ideen einfach per Sprache formulieren. Das Modell diskutierte diese Ideen mit ihm, stellte kritische RĂŒckfragen, erinnerte an bestehende Systemregeln, rechtliche Anforderungen und ZusammenhĂ€nge im Gesamtsystem.

Ein besonders eindrucksvolles Beispiel:
Auf einer Autofahrt nach Wien diskutierte er mehrere Stunden lang per Voice-Mode mit dem Modell ĂŒber ein großes Modul zur Workshop-Planung.

Das heißt: Die eigentliche „Entwicklung“ bestand am Ende nicht mehr primĂ€r darin, Code zu schreiben, sondern darin:

Das ist vermutlich einer der wichtigsten Gedanken des gesamten Videos.
KI verschiebt die Rolle des Entwicklers von der manuellen Umsetzung hin zur strukturierten SystemfĂŒhrung.

Die Ergebnisse des Projekts 📊

Und jetzt zu den Zahlen, die das Ganze so spektakulÀr machen.

Umfang des Systems

Am Ende entstanden:

ZusÀtzlich auf Code-Ebene:

Das ist kein kleines Bastelprojekt mehr. Das ist ein ernstzunehmendes Softwaresystem.

Die QualitĂ€t der Ergebnisse: Der eigentliche Schock đŸ€Ż

Der Autor sagt selbst: Dass KI 420.000 Zeilen Code erzeugen kann, war keine Überraschung.

Die wirkliche Überraschung war die QualitĂ€t.

QualitÀtsmetriken

Testabdeckung

Die fehlenden 15 % waren bewusst nicht vollstĂ€ndig abgedeckt, weil manche extern getriggerten Office-/Outlook-Prozesse nicht gemockt wurden. Laut Autor wĂ€re 100 % prinzipiell möglich gewesen, aber der Aufwand war fĂŒr ihn nicht mehr sinnvoll.

Strukturelle Schulden

Das ist einer der spektakulÀrsten Punkte des gesamten Berichts. Gemeint ist:
Die Anwendung hÀlt sich vollstÀndig an die definierten Architektur- und Designvorgaben.

Dokumentation

Gerade der letzte Punkt ist in realen Projekten fast revolutionĂ€r. Denn eine der grĂ¶ĂŸten SchwĂ€chen klassischer Softwareprojekte ist, dass Dokumentation mit der Zeit veraltet. Hier wurde das Problem durch automatisierte Regeneration praktisch systematisch beseitigt. 📚

Die Kosten: extrem niedrig im VerhĂ€ltnis zum Ergebnis 💾

Der Autor investierte ĂŒber etwa ein halbes Jahr hinweg 45 volle Arbeitstage Ă  8 Stunden in das Projekt – zusĂ€tzlich zu seinem normalen Beruf.

Personalkosten

Bei einem angenommenen Vollkostensatz von 500 € pro Entwickler-Tag ergeben sich:

KI-Kosten

Er nutzte zunÀchst Codex, spÀter fast nur noch Claude. Insgesamt wurden dabei gigantische Mengen Tokens verarbeitet:

Rechnet man das zu regulÀren Tokenpreisen, wÀren laut seiner Aussage etwa:

TatsÀchlich nutzte er jedoch Abos:

Gesamtkosten

Damit lag das gesamte Projekt ungefÀhr bei:

FĂŒr ein System dieser GrĂ¶ĂŸe und QualitĂ€t ist das bemerkenswert.

Der Vergleich mit menschlichen Teams đŸ‘„

Um die Ergebnisse einordnen zu können, zog der Autor zwei reale Entwicklungsteams aus Kundenprojekten als Vergleich heran.

Vergleichsteams

Team 1

Team 2

Beide Teams sollten das Spektrum des Projekts – also Specs, DevOps, Architektur, Coding, Testing und Dokumentation – einschĂ€tzen.

Die SchÀtzungen lagen bei:

ZusĂ€tzlich ließ der Autor Claude und Codex schĂ€tzen, die auf ca. 20 Personenjahre kamen. Seine eigene SchĂ€tzung lag bei 18 Personenjahren.

Der gemittelte Wert lag am Ende bei:

Der Faktor: 93x schneller 😼

Und damit kommt der eigentliche Paukenschlag:

Das ergibt einen Faktor von:

93x schneller

Selbst wenn man das als zu optimistisch betrachtet und massiv nach unten korrigiert, argumentiert der Autor:

Selbst dann wÀre der Vorsprung immer noch enorm.

Und das bei besserer Struktur, besserer Dokumentation und besserer Testabdeckung als in den herangezogenen Vergleichsprojekten.

Was bedeutet das fĂŒr die Softwareentwicklung? 🌍

Hier liegt die eigentliche Brisanz des Videos.

Der Autor macht sehr deutlich:
Es geht nicht nur darum, dass KI „ein bisschen unterstĂŒtzt“.
Es geht nicht nur um ProduktivitÀtssteigerung im Bereich von 20 oder 30 Prozent.
Wenn sich solche Ergebnisse verallgemeinern lassen – auch nur annĂ€hernd –, dann reden wir ĂŒber einen massiven strukturellen Umbruch in der Branche.

Die wichtigsten Konsequenzen

1. Geschwindigkeit wird neu definiert

Was frĂŒher Monate oder Jahre dauerte, könnte kĂŒnftig in Wochen entstehen.

2. QualitÀt muss nicht leiden

Die alte Annahme „schneller = schlechter“ wird durch solche Experimente massiv in Frage gestellt.

3. Entwicklerrollen verschieben sich

Weniger reine Implementierung, mehr:

4. Dokumentation und Tests können erstmals dauerhaft synchron gehalten werden

Ein riesiges Problem klassischer Projekte könnte systematisch abnehmen.

5. Der Engpass ist nicht mehr das Tippen von Code

Der Engpass verschiebt sich hin zu:

Aber: Das kann nicht einfach jeder sofort

Trotz aller Begeisterung relativiert der Autor an einer wichtigen Stelle sehr klar:

Nein, nicht jeder kann sofort mit derselben QualitÀt und Geschwindigkeit solche Systeme bauen.

Warum?
Weil die QualitÀt am Ende nicht zufÀllig entstanden ist.

Sie entstand, weil er:

Das ist ein ganz wichtiger Punkt. KI ersetzt hier nicht das Wissen – sie verstĂ€rkt es.

Oder anders gesagt:
Wenn man nicht weiß, wie gute Architektur, gute Tests, gute Anforderungen und gute Entwicklungsprozesse aussehen, wird man auch mit KI kein vergleichbares Ergebnis erzielen.

Deshalb ist seine Empfehlung sehr klar:

Grundlagen bleiben entscheidend

Wer mit KI professionell entwickeln will, sollte weiterhin verstehen:

Denn genau dieses Wissen braucht man, um der KI gute Leitplanken zu geben.

Die vielleicht wichtigste Erkenntnis des ganzen Videos

Wenn man den Kern des Experiments auf einen Satz reduzieren mĂŒsste, dann vielleicht auf diesen:

Der grĂ¶ĂŸte Hebel von KI in der professionellen Softwareentwicklung liegt nicht darin, dass sie Code schreibt, sondern darin, dass sie unter guten Leitplanken komplette Entwicklungsarbeit konsistent, schnell und qualitativ hochwertig umsetzen kann.

Das verÀndert alles.

Es verÀndert:

Und vor allem verÀndert es die ökonomische Logik von Softwareentwicklung.

Wenn es möglich ist, mit einem Bruchteil der Zeit und Kosten bessere Ergebnisse zu erzielen, dann wird sich die Branche zwangslÀufig daran anpassen.

Kritische Einordnung: Was man bei aller Euphorie nicht vergessen darf

So beeindruckend das Experiment ist, sollte man es natĂŒrlich auch nĂŒchtern betrachten.

Einige wichtige Einordnungen:

1. Es ist ein Einzelfall

Das Projekt wurde von einer sehr erfahrenen Person durchgefĂŒhrt, die das DomĂ€nenwissen, die Architekturkompetenz und die QualitĂ€tsmaßstĂ€be selbst mitgebracht hat.

2. SchÀtzvergleiche sind keine realen Parallelprojekte

Der Faktor 93 basiert auf SchÀtzungen von Teams, nicht auf einem live parallel entwickelten Vergleichsprojekt.

3. Das Setup war sehr bewusst optimiert

Harness, statische Analyse, Teststrategie, Modellwahl, Tooling und Arbeitsweise wurden gezielt aufgebaut und iterativ verbessert.

4. Der DomÀnenkontext war dem Autor vertraut

Es handelte sich um seine eigene Anwendung, also um ein Gebiet mit hohem FachverstÀndnis.

Trotzdem bleibt das Ergebnis selbst unter konservativer Betrachtung extrem stark. Denn selbst bei deutlicher AbschwÀchung der Zahlen bleibt noch ein massiver ProduktivitÀts- und QualitÀtsgewinn.

Fazit: Wir sind an einem Wendepunkt đŸ”„

Dieses Video beschreibt nicht einfach nur ein beeindruckendes KI-Projekt. Es beschreibt einen möglichen Blick in die unmittelbare Zukunft professioneller Softwareentwicklung.

Die Kernaussage ist nicht:

„Programmierer werden ĂŒberflĂŒssig.“

Die Kernaussage ist vielmehr:

„Die Art, wie professionelle Softwareentwicklung funktioniert, verĂ€ndert sich fundamental.“

Der Entwickler der Zukunft ist nicht mehr nur jemand, der möglichst schnell möglichst viel Code tippen kann.
Er oder sie wird zunehmend zu jemandem, der:

Das ist einerseits faszinierend.
Andererseits ist es – wie der Autor sehr offen sagt – auch beunruhigend.

Denn wenn ein einzelner, KI-unterstĂŒtzter Entwickler in 45 Tagen ein System liefert, fĂŒr das klassische Teams im Schnitt 19 Personenjahre ansetzen, dann ist klar:
Diese Entwicklung wird nicht folgenlos bleiben.

Aber genau deshalb ist jetzt der richtige Zeitpunkt, sich ernsthaft mit dem Thema zu beschĂ€ftigen. Nicht oberflĂ€chlich. Nicht nur mit ein paar Prompts. Sondern tief, strukturiert und professionell. 💡

Die zentrale Botschaft fĂŒr Entwickler und Unternehmen

FĂŒr Entwickler

FĂŒr Unternehmen

Schlussgedanke

Was dieses Experiment so bemerkenswert macht, ist nicht nur der Faktor 93.
Es ist die Kombination aus:

Wenn sich dieser Ansatz weiter bestĂ€tigt, dann war das hier tatsĂ€chlich nicht nur ein interessantes Experiment – sondern vielleicht wirklich einer der Momente, an denen sich die Softwareentwicklung dauerhaft verĂ€ndert hat.

Revision #1
Created 2026-06-25 00:32:08 UTC by art10m
Updated 2026-06-25 00:37:03 UTC by art10m