Prompt-getriebene Entwicklung, umgangssprachlich auch Vibe Coding genannt, beschreibt eine Arbeitsweise, bei der Entwicklerinnen und Entwickler Funktionalität überwiegend in natürlicher Sprache beschreiben und den eigentlichen Quellcode von einem KI-Modell erzeugen lassen. Lange galt das als Spielwiese für Prototypen und kleine Skripte. Ein aktuelles Beispiel zeigt, dass der Ansatz inzwischen auch größere Vorhaben trägt.

Konkret geht es um eine quelloffene Engine für den Strategieklassiker Total Annihilation. Sie ist nach Angaben der Berichterstattung weitgehend mithilfe von KI entstanden und bringt das Spiel sowohl auf moderne Rechner als auch in den Browser. Eine Engine ist dabei der technische Unterbau eines Spiels: Sie kümmert sich um Darstellung, Eingaben, Spiellogik und Ressourcenverwaltung – also um genau jene Schichten, die klassischerweise als besonders anspruchsvoll gelten.

Warum gerade dieses Beispiel aufhorchen lässt

Ein Reimplementierungsprojekt dieser Art ist kein Wochenendprojekt. Es verlangt den Umgang mit vorhandenen Datenformaten, mit Performance-Fragen und mit einer Zielplattform, die sich technisch deutlich vom Original unterscheidet. Dass ein solches Vorhaben überwiegend prompt-getrieben entstehen kann, verschiebt die Erwartung an KI-Werkzeuge: weg vom Autovervollständigen einzelner Zeilen, hin zur Mitarbeit an zusammenhängenden Systemen.

Gleichzeitig lohnt ein nüchterner Blick auf die Rahmenbedingungen. Günstig für KI-gestützte Entwicklung ist ein Projekt immer dann, wenn

  • ein klar umrissenes Zielverhalten existiert, an dem sich das Ergebnis messen lässt,
  • Fehler schnell sichtbar werden, weil sich das Resultat unmittelbar ausprobieren lässt,
  • keine regulatorischen oder personenbezogenen Risiken im Spiel sind,
  • und das Vorhaben in kleine, einzeln testbare Bausteine zerfällt.

Ein Spiel erfüllt diese Punkte in weiten Teilen. Eine Buchhaltungsschnittstelle oder ein Kundenportal mit Datenschutzanforderungen tut das deutlich weniger. Die Übertragbarkeit auf das eigene Projekt sollte man deshalb nicht pauschal annehmen.

Was die KI übernimmt – und was nicht

Erfahrungsgemäß verschiebt KI-gestützte Entwicklung den Arbeitsschwerpunkt, statt ihn abzuschaffen. Die Zeit, die vorher in das Schreiben von Code floss, wandert in drei andere Tätigkeiten.

Erstens: Architektur. Die Entscheidung, wie ein System geschnitten wird, welche Module existieren und wie sie miteinander sprechen, bleibt eine Entwurfsleistung. Ein Modell kann Vorschläge liefern, aber die Konsequenzen einer Architektur zeigen sich erst Monate später – in Wartbarkeit, Erweiterbarkeit und Betriebskosten.

Zweitens: Review. Generierter Code sieht oft plausibel aus. Plausibilität ist jedoch kein Korrektheitsnachweis. Gerade bei Nebenläufigkeit, Speicherverwaltung oder Grenzfällen in der Eingabeverarbeitung braucht es jemanden, der den Code liest und versteht, statt ihn nur zu starten.

Drittens: Qualitätssicherung. Automatisierte Tests gewinnen an Gewicht, wenn große Codemengen schnell entstehen. Sie sind das Netz, das verhindert, dass eine Korrektur an einer Stelle still eine andere bricht.

Geschwindigkeit ist nicht gleich Reife

Ein häufiges Missverständnis in Entscheidungsrunden lautet: Wenn die erste lauffähige Version schneller da ist, ist das Projekt entsprechend früher fertig. In der Praxis beschleunigt KI vor allem den Weg zum sichtbaren Zwischenstand. Die anschließenden Phasen – Stabilisierung, Barrierefreiheit, Sicherheit, Performance unter Last, Dokumentation – folgen weiterhin ihrer eigenen Logik.

Hinzu kommt die Frage der Verantwortung. Wer Code einsetzt, haftet für sein Verhalten, unabhängig davon, wer oder was ihn geschrieben hat. Bei Open-Source-Projekten kommt die Lizenzfrage hinzu: Herkunft und Weiterverwendbarkeit von Komponenten müssen nachvollziehbar bleiben.

Praktische Konsequenzen für Teams

Aus dem Beispiel lassen sich einige nüchterne Arbeitsregeln ableiten, ohne dass man den Ansatz überhöhen muss:

  1. Prompt-getriebene Entwicklung dort einsetzen, wo sich Ergebnisse schnell und objektiv prüfen lassen.
  2. Vor dem ersten Prompt die Architektur festlegen, nicht danach.
  3. Testabdeckung als Voraussetzung behandeln, nicht als nachgelagerte Aufgabe.
  4. Jede generierte Änderung denselben Review-Standards unterwerfen wie handgeschriebenen Code.
  5. Festhalten, welche Teile wie entstanden sind – das erleichtert spätere Wartung und Lizenzprüfungen.

Interessant ist auch der kulturelle Aspekt: Ein Projekt wie dieses entsteht im Open-Source-Umfeld, wo Zwischenstände öffentlich sind und von Dritten nachvollzogen werden können. Diese Transparenz ist selbst ein Qualitätsmechanismus – einer, den geschlossene Unternehmensprojekte durch interne Prozesse ersetzen müssen.

Einordnung

Für Web- und Softwareprojekte heißt das: KI-gestützte Code-Generierung ist kein Randwerkzeug mehr, sondern eine ernstzunehmende Option für Umfänge, die bislang klassisch geplant wurden. Der Gewinn liegt in der Geschwindigkeit der Umsetzung, nicht im Wegfall von Entwurf, Review und Qualitätssicherung – diese Aufgaben werden eher wichtiger, weil mehr Code in kürzerer Zeit entsteht. Wer den Ansatz produktiv nutzen will, sollte ihn deshalb in klar abgegrenzten Modulen erproben und die eigenen Prüfprozesse vorher auf das höhere Tempo einstellen.

Quellen