Tim Sweeney, Chef von Epic Games, baut die Spieleentwicklung seines Unternehmens massiv um und richtet sie auf KI-Werkzeuge aus. Seine Erwartung: ein goldenes Zeitalter für Computerspiele. Mehr Details nennt die Meldung nicht – und genau deshalb lohnt der Blick weniger auf die Ankündigung selbst als auf die Frage, was ein solcher Umbau in einer Entwicklungsorganisation praktisch auslöst.
Denn der Schritt ist kein Einzelfall. Dass ein etablierter Softwarehersteller seine Produktionsweise nicht punktuell ergänzt, sondern grundsätzlich neu zuschneidet, ist der eigentliche Vorgang. Für mittelständische Unternehmen, die Webplattformen, Shops oder TYPO3-Installationen betreiben, stellt sich dieselbe Frage in kleinerem Maßstab: Wo verändert KI nur das Werkzeug – und wo verändert sie die Arbeitsteilung?
Vom Hilfsmittel zum Bestandteil des Prozesses
Die erste Stufe der KI-Nutzung in der Entwicklung ist meist unauffällig: Entwicklerinnen und Entwickler lassen sich Codevorschläge generieren, Tests entwerfen oder Fehlermeldungen erklären. Das bleibt individuell, freiwillig und ohne Auswirkungen auf den Projektablauf.
Die zweite Stufe sieht anders aus. Hier werden KI-Agenten – also Programme, die mehrere Arbeitsschritte selbstständig hintereinander ausführen – fest in den Entwicklungsprozess eingebunden: Sie erzeugen Pull Requests, also Änderungsvorschläge am Quellcode, aktualisieren Abhängigkeiten oder migrieren Code zwischen Versionen. Ab diesem Punkt ist KI keine persönliche Arbeitserleichterung mehr, sondern ein Produktionsfaktor, der geplant, überwacht und verantwortet werden muss.
Wer diesen Übergang nicht bewusst gestaltet, bekommt ihn ungeplant: In vielen Teams ist die erste Stufe längst Alltag, ohne dass jemand geregelt hätte, was davon in den produktiven Code darf.
Rollen verschieben sich, sie verschwinden nicht
Wenn Code schneller entsteht, wird nicht das Schreiben zum Engpass, sondern das Prüfen. Review, Architekturentscheidungen und das Verständnis für die fachlichen Anforderungen gewinnen an Gewicht. Gleichzeitig steigt der Bedarf an Menschen, die präzise beschreiben können, was gebaut werden soll – eine ungenaue Anforderung führt mit KI-Unterstützung schneller zu viel unbrauchbarem Ergebnis als ohne.
Für Projektverantwortliche heißt das konkret:
- Senior-Kompetenz wird wichtiger, nicht überflüssig – jemand muss generierten Code bewerten können.
- Einstiegsaufgaben verändern sich; klassische Routinearbeit als Lernfeld für Juniors fällt teilweise weg und muss ersetzt werden.
- Fachliche Spezifikation rückt näher an die Entwicklung heran, weil sie direkt in Prompts und Agentenaufträge einfließt.
- Die Verantwortung für das Ergebnis bleibt beim Team, unabhängig davon, wer oder was den Code erzeugt hat.
Qualitätssicherung wird zum Nadelöhr
KI-generierter Code sieht häufig plausibel aus. Genau das ist das Risiko: Fehler sind seltener offensichtlich, sondern subtil – eine falsch behandelte Sonderregel, eine ungeprüfte Eingabe, ein Zugriff ohne Rechteprüfung. In TYPO3-Projekten kommen typische Fallstricke dazu, etwa der korrekte Umgang mit Caching, mit mehrsprachigen Inhalten oder mit Erweiterungen, deren Schnittstellen sich zwischen Hauptversionen ändern.
Was in dieser Situation trägt, ist nicht mehr Kontrolle im Nachhinein, sondern eine belastbare technische Grundlage:
- Automatisierte Tests, die fachliche Regeln abbilden und nicht nur Syntax prüfen.
- Statische Codeanalyse und einheitliche Coding Standards als harte Schranke in der Pipeline.
- Verpflichtendes Review durch Menschen für alles, was in den produktiven Branch geht.
- Nachvollziehbarkeit: dokumentieren, welche Änderungen maschinell entstanden sind.
- Klare Regeln, welche Daten und welcher Quellcode an externe KI-Dienste übergeben werden dürfen.
Der letzte Punkt ist kein Formalismus. Wer Kundendaten, interne Geschäftslogik oder lizenzierten Fremdcode verarbeitet, braucht eine dokumentierte Entscheidung darüber, welche Werkzeuge zulässig sind – auch mit Blick auf Datenschutz und Urheberrecht.
Warum Tempo allein kein Ziel ist
Geschwindigkeitsgewinne in der Entwicklung verpuffen, wenn der Rest der Organisation nicht mitzieht. Wenn Abstimmungen, Freigaben oder Inhaltspflege weiterhin Wochen brauchen, ändert schnellerer Code wenig am Liefertermin. Der Hebel liegt deshalb seltener im Werkzeug als im Gesamtprozess: in kurzen Entscheidungswegen, sauber abgegrenzten Zuständigkeiten und in Deployments, die ohne manuelle Zwischenschritte funktionieren.
Hinzu kommt ein Punkt, der in Umbauankündigungen selten vorkommt: Jede Automatisierung erzeugt neuen Pflegeaufwand. Agenten brauchen Konfiguration, Zugänge, Leitplanken und regelmäßige Überprüfung. Wer das nicht einplant, tauscht manuelle Arbeit gegen eine schwer durchschaubare Werkzeugkette.
Ein realistischer Einstieg
Ein radikaler Umbau wie bei einem großen Spieleentwickler ist für die meisten Unternehmen weder nötig noch sinnvoll. Tragfähiger ist ein begrenzter Einstieg: ein klar umrissener Anwendungsfall, etwa die Unterstützung bei einer TYPO3-Versionsmigration, bei Testabdeckung oder bei wiederkehrenden Wartungsaufgaben. Danach wird gemessen, ob sich Durchlaufzeit und Fehlerquote tatsächlich verbessern – und erst dann ausgeweitet.
Wichtig ist, die Bewertung vorher festzulegen. Ohne definierte Kennzahlen bleibt die Einschätzung ein Gefühl, und Gefühle fallen bei neuen Werkzeugen regelmäßig zu positiv aus.
Einordnung
Für Web- und Softwareprojekte verschiebt sich der Schwerpunkt von der Codeerstellung hin zu Spezifikation, Review und automatisierter Qualitätssicherung. Wer KI produktiv einsetzen will, braucht deshalb zuerst eine saubere technische Basis: Tests, Pipelines, Versionsstände und klare Zuständigkeiten. Die Ankündigung aus der Spielebranche ist dafür vor allem ein Anlass, die eigenen Prozesse zu prüfen – nicht ein Grund, die Entwicklungsorganisation kurzfristig umzubauen.
