Prompt-getriebene Entwicklung, oft Vibe Coding genannt, beschreibt einen Arbeitsmodus, in dem Code überwiegend aus natürlichsprachigen Anweisungen an ein KI-Modell entsteht. Das Ergebnis ist schnell sichtbar: eine Funktion, ein Formular, ein Endpunkt. Was dabei nicht automatisch mitwächst, ist das Verständnis für das System, in dem dieser Code später leben muss.

Genau an diesem Punkt setzt eine aktuelle Diskussion aus der Testing-Community an. Richard Seidl spricht mit Marc Bless und Thomas Ronzon darüber, dass die Mittelschicht an Entwicklerinnen und Entwicklern wegbricht – also jene Erfahrungsstufe zwischen Einstieg und Spezialistentum – und dass das nicht ohne Folgen für die Praxis bleibt.

Warum die mittlere Erfahrungsstufe so wichtig ist

In Projekten übernimmt diese Gruppe traditionell Aufgaben, die selten im Angebot stehen, aber über die Wartbarkeit entscheiden: Code lesen und bewerten, Zusammenhänge zwischen Modulen erklären, Testfälle sinnvoll schneiden, Reviews mit Begründung statt mit Bauchgefühl. Sie ist zugleich das Bindeglied, über das Wissen von erfahrenen Architektinnen zu neuen Teammitgliedern gelangt.

Fällt diese Schicht dünner aus, entsteht eine Lücke, die Werkzeuge nur scheinbar schließen. Ein Modell kann eine Klasse erzeugen, aber es kennt nicht die stillen Regeln eines gewachsenen Systems: welche Komponente historisch als Single Point of Failure gilt, welche Datenbanktabelle andere Fachbereiche mitnutzen, welche Änderung eine Schnittstelle zu einem Drittsystem stört.

Die typischen Risiken in Projekten

Aus der Praxis lassen sich mehrere Muster beschreiben, die bei rein prompt-getriebener Arbeit auftreten:

  • Lokal korrekt, global falsch: Der generierte Code erfüllt die Anforderung im Ausschnitt, verletzt aber Konventionen oder Verantwortlichkeiten der Gesamtarchitektur.
  • Redundanz statt Wiederverwendung: Funktionen werden neu erzeugt, obwohl es sie im Projekt bereits gibt – oft leicht abweichend, was Pflegeaufwand vervielfacht.
  • Tests als Beiwerk: Wenn Tests ebenfalls generiert werden, prüfen sie im Zweifel genau das, was der Code tut, nicht das, was fachlich gefordert ist.
  • Unklare Verantwortung: Niemand im Team kann den Code vollständig erklären. Bei Störungen verlängert sich die Zeit bis zur Ursache erheblich.
  • Sicherheits- und Datenschutzfragen: Berechtigungen, Eingabevalidierung und Protokollierung sind Themen, die aus einem kurzen Prompt selten vollständig hervorgehen.

Keines dieser Risiken ist neu. Neu ist die Geschwindigkeit, mit der sie sich anhäufen können, weil die Erzeugung von Code deutlich billiger geworden ist als dessen Verständnis.

Was KI-Tempo verlässlich macht

Die Antwort liegt nicht darin, KI-Unterstützung aus Projekten zu verbannen. Sie liegt darin, die Prüfstellen zu stärken, die bisher informell durch Erfahrung abgedeckt wurden. Vier Bausteine haben sich bewährt:

  1. Architekturentscheidungen dokumentieren: Wenige Seiten, die festhalten, welche Schichten es gibt, wo Fachlogik liegt und welche Abhängigkeiten bewusst gewählt wurden. Dieses Dokument ist zugleich Kontext für Menschen und für Modelle.
  2. Tests vor dem Prompt denken: Wenn die erwartete Fachlogik zuerst als Testfall formuliert wird, verschiebt sich die Prüfung vom Gefühl zur Zusage. Automatisierte Tests sind das Sicherheitsnetz, das Tempo überhaupt erst erlaubt.
  3. Reviews mit klarer Frage: Nicht nur „funktioniert es?“, sondern „passt es in dieses System, und würde ich es in sechs Monaten wiederfinden?“. Reviews sind dabei bewusst Menschenarbeit, weil sie Systemwissen aufbauen.
  4. Wissen aktiv weitergeben: Pair-Arbeit, gemeinsame Durchsprachen und nachvollziehbare Commit-Historien ersetzen das, was früher durch Mitlaufen im Projekt entstand.

Konsequenzen für die Zusammenarbeit mit Dienstleistern

Für Auftraggeber verschiebt sich damit auch die Frage, worauf beim Einkauf von Entwicklungsleistung zu achten ist. Ein niedriger Tagessatz oder eine kurze Umsetzungszeit sagen wenig aus, wenn unklar bleibt, wie Qualität abgesichert wird. Sinnvolle Fragen sind: Welche Testabdeckung existiert für die kritischen Pfade? Wer im Team kann die Architektur erklären, ohne in den Code zu schauen? Wie werden KI-generierte Anteile geprüft und dokumentiert?

Diese Fragen sind unbequem, aber sie schützen vor der teuersten Variante eines Projekts: einem System, das kurzfristig funktioniert und langfristig niemandem gehört. Gerade bei Plattformen wie TYPO3, die über Jahre erweitert werden und in Bestandsprozesse eingebunden sind, entscheidet Wartbarkeit stärker über die Gesamtkosten als die erste Umsetzung.

Einordnung

KI-Werkzeuge verändern nicht, was gute Software ausmacht – sie verändern, wo der Engpass liegt. Nicht mehr das Schreiben von Code ist knapp, sondern das belastbare Urteil darüber, ob dieser Code in ein System passt. Für Web- und Softwareprojekte heißt das: Tests, Architekturdokumentation und echte Reviews sind keine Zusatzposten, sondern die Voraussetzung dafür, das gewonnene Tempo überhaupt nutzen zu können.

Quellen