Auf der Spieleplattform Steam wird derzeit ein angekündigter Shooter diskutiert, den sein Entwicklerteam nach eigenen Angaben größtenteils mit Künstlicher Intelligenz erstellt hat. Die Reaktionen der Spielerinnen und Spieler fallen deutlich aus. Der Vorgang ist über die Gaming-Branche hinaus interessant, weil er eine Frage berührt, die inzwischen jedes Softwareprojekt betrifft: Wie viel maschinell erzeugter Code verträgt ein Produkt, ohne dass Qualität und Glaubwürdigkeit leiden?

Was hinter dem Begriff Vibe Coding steckt

Als Vibe Coding wird eine Arbeitsweise bezeichnet, bei der Entwicklerinnen und Entwickler ein Ergebnis in natürlicher Sprache beschreiben und den Code weitgehend von einem KI-Modell erzeugen lassen, ohne jede Zeile im Detail nachzuvollziehen. Der Reiz liegt auf der Hand: Prototypen entstehen in Stunden statt in Wochen, und auch kleine Teams können Funktionsumfänge abdecken, für die früher mehrere Fachleute nötig waren.

Das funktioniert erstaunlich gut, solange es um Machbarkeitsnachweise, interne Werkzeuge oder abgegrenzte Teilaufgaben geht. Problematisch wird es dort, wo aus dem Prototyp ein Produkt wird, das bezahlt, betrieben und über Jahre gepflegt werden soll. Genau an dieser Schwelle entzündet sich die Kritik im aktuellen Fall.

Warum das Publikum reagiert

Bemerkenswert ist weniger die Technik als die Reaktion. Ein erheblicher Teil der Kritik richtet sich nicht gegen KI an sich, sondern gegen die Erwartung, für ein Ergebnis zu bezahlen, dessen Entstehung als weitgehend automatisiert wahrgenommen wird. Nutzerinnen und Nutzer bewerten in solchen Situationen nicht nur das Produkt, sondern auch den Aufwand und die Sorgfalt, die sie dahinter vermuten.

Diese Wahrnehmung lässt sich nicht wegdiskutieren, aber sie lässt sich beeinflussen. Wer offenlegt, an welchen Stellen KI eingesetzt wurde und wo Menschen geprüft, korrigiert und verantwortet haben, nimmt einem großen Teil der Kritik die Grundlage. Wer den Anteil verschweigt und erst nachträglich damit konfrontiert wird, verliert doppelt: an Produktqualität und an Vertrauen.

Die typischen Schwachstellen generierten Codes

Aus der Projektpraxis lassen sich einige wiederkehrende Muster benennen, die unabhängig vom konkreten Fall gelten:

  • Oberflächliche Korrektheit: Generierter Code läuft oft auf Anhieb, deckt aber Sonderfälle, Fehlerbehandlung und ungewöhnliche Eingaben nur lückenhaft ab.
  • Fehlende Architektur: Einzeln sinnvolle Bausteine ergeben in Summe kein tragfähiges System. Zuständigkeiten überschneiden sich, Logik wird mehrfach implementiert.
  • Sicherheitslücken: Eingabevalidierung, Rechteprüfung und der Umgang mit Zugangsdaten gehören zu den Bereichen, in denen Modelle bekannte Fehlmuster reproduzieren.
  • Wartungsschulden: Code, den niemand im Team wirklich versteht, lässt sich später nur schwer erweitern. Jede Änderung wird zum Risiko.
  • Rechtliche Unschärfen: Herkunft und Lizenzstatus generierter Bestandteile sind nicht immer eindeutig – ein Thema, das spätestens bei Ausschreibungen und Audits aufschlägt.

Was in der Praxis hilft

Der Ausweg liegt nicht darin, KI-Werkzeuge aus dem Entwicklungsprozess zu verbannen. Produktiv eingesetzt sparen sie messbar Zeit. Entscheidend ist, dass sie in einen Prozess eingebettet werden, der Fehler abfängt, bevor sie den Nutzerinnen und Nutzern auffallen.

  1. Review-Pflicht ohne Ausnahme: Jede generierte Zeile durchläuft dieselbe Prüfung wie handgeschriebener Code. Wer Code freigibt, übernimmt Verantwortung dafür – unabhängig davon, wer oder was ihn verfasst hat.
  2. Automatisierte Prüfschichten: Statische Analyse, Abhängigkeits-Scans und eine belastbare Testabdeckung fangen einen Teil der typischen Schwächen ab, bevor ein Mensch hinsehen muss.
  3. Architektur bleibt Menschensache: Datenmodell, Schnittstellen und Modulgrenzen werden vorab festgelegt. Die KI füllt Strukturen aus, sie erfindet sie nicht.
  4. Definierte Einsatzbereiche: Für Tests, Migrationsskripte oder Boilerplate ist der Nutzen hoch und das Risiko gering. Bei Authentifizierung, Zahlungsabwicklung oder Datenschutzlogik gelten strengere Regeln.
  5. Nachvollziehbarkeit: Im Team sollte dokumentiert sein, welche Komponenten mit KI-Unterstützung entstanden sind. Das erleichtert spätere Fehlersuche und beantwortet Fragen von Auftraggebern, bevor sie gestellt werden.

Transparenz ist eine Produkteigenschaft

Der Fall auf Steam zeigt, dass die Kommunikation über den Entstehungsprozess inzwischen Teil des Produkts ist. Zielgruppen entwickeln ein Gespür dafür, wann ein Ergebnis mit heißer Nadel gestrickt wurde, und sie sprechen es öffentlich aus. In Bewertungsportalen, App-Stores oder Foren entsteht daraus binnen Tagen eine Erzählung, die ein Team nur schwer wieder einfängt.

Für Unternehmen heißt das: Die Frage, ob KI eingesetzt wurde, ist weniger heikel als die Frage, ob jemand das Ergebnis geprüft hat. Eine klare Aussage dazu – intern gegenüber der Geschäftsführung, extern gegenüber Kundinnen und Kunden – ist belastbarer als Schweigen.

Einordnung für Web- und Softwareprojekte

Für Website- und Applikationsprojekte verschiebt sich der Schwerpunkt der Arbeit: Nicht das Schreiben von Code ist der Engpass, sondern dessen Prüfung, Strukturierung und langfristige Pflege. Wer KI-Unterstützung einführt, sollte deshalb im selben Schritt in Reviews, Tests und Architekturentscheidungen investieren, sonst verlagert sich der eingesparte Aufwand nur in die Wartungsphase. Und wer den KI-Anteil an einem Produkt offen benennt, verhindert, dass daraus später eine Vertrauensfrage wird.

Quellen