KI-Assistenten haben die Softwareentwicklung an einer klar messbaren Stelle verändert: Der Weg von der Anforderung zum ersten lauffähigen Code ist kürzer geworden. Eine aktuelle Studie, über die der Branchendienst DataCenter-Insider berichtet, weist auf die Kehrseite hin: Die Qualitätssicherung – also Reviews, Tests und Abnahmen – hält mit diesem Tempo oft nicht Schritt. Daraus entstehen Risiken für Unternehmen.

Das ist weniger eine Aussage über die Qualität generierter Codezeilen als eine über Prozesse. Wenn ein Teilschritt in der Entwicklungskette deutlich schneller wird und alle anderen unverändert bleiben, verschiebt sich der Engpass. Er verschwindet nicht.

Warum das Testing zum Engpass wird

Codegenerierung lässt sich gut automatisieren, weil sie ein klar umrissenes Ergebnis hat. Qualitätssicherung ist dagegen verteilte Arbeit: Sie besteht aus fachlichen Abnahmen, Code-Reviews durch Kolleginnen und Kollegen, automatisierten Tests, manuellen Prüfungen in verschiedenen Browsern und Freigaben durch Fachabteilungen.

Diese Schritte hängen an Menschen, an Terminen und an vorhandener Testinfrastruktur. Sie skalieren nicht dadurch mit, dass ein Assistent schneller Vorschläge liefert. Typische Muster, die daraus entstehen:

  • Review-Staus: Es liegen mehr Änderungen zur Prüfung vor, als das Team in vertretbarer Tiefe durchsehen kann.
  • Oberflächliche Prüfung: Wird trotzdem im gleichen Zeitfenster geprüft, sinkt die Kontrolltiefe pro Änderung.
  • Verlagerte Fehlersuche: Was im Review nicht auffällt, fällt später auf – in der Abnahme, im Betrieb oder beim Kunden. Dort ist die Korrektur teurer.

Das Vertrauensproblem bei generiertem Code

Ein zweiter Punkt kommt hinzu. Code, den ein Mensch geschrieben hat, trägt implizit eine Begründung mit sich: Die Autorin kann erklären, warum eine Lösung so und nicht anders aussieht. Bei generiertem Code fehlt dieses Wissen im Team, wenn niemand die Ausgabe wirklich durchgearbeitet hat.

Der Code funktioniert dann möglicherweise im Normalfall – aber niemand kann zuverlässig sagen, wie er sich bei fehlerhaften Eingaben, unter Last oder bei einem Update der zugrunde liegenden Bibliothek verhält. Genau diese Fragen beantwortet normalerweise die Qualitätssicherung.

Konsequenzen für Web- und TYPO3-Projekte

In Webprojekten wirkt sich das besonders unmittelbar aus, weil die Anwendungen öffentlich erreichbar sind. Ein Fehler in einem internen Werkzeug fällt in der Abteilung auf. Ein Fehler in einem Formular auf der Unternehmensseite fällt Interessenten auf, oder er führt dazu, dass Daten falsch, unvollständig oder ungesichert verarbeitet werden.

Relevante Bereiche sind vor allem:

  • Datenverarbeitung in Formularen: Validierung, Speicherung, E-Mail-Versand, datenschutzrelevante Pfade.
  • Rechte und Zugriffe: Wer darf im Redaktionssystem welche Inhalte sehen und ändern? Solche Regeln sind schnell formuliert und selten vollständig getestet.
  • Erweiterungen und Updates: Eigenentwicklungen müssen Versionswechsel des Systems überleben. Ohne Tests merkt man Inkompatibilitäten erst beim Update.
  • Ausgabe und Zugänglichkeit: Generiertes Frontend-Markup ist nicht automatisch semantisch sauber oder barrierefrei.

Was sich organisatorisch nachziehen lässt

Die naheliegende Antwort ist nicht, KI-Unterstützung zurückzufahren, sondern die Prüfseite mit gleicher Konsequenz zu behandeln wie die Erstellungsseite. Dafür bieten sich mehrere Ansatzpunkte an.

Automatisierte Tests als Teil der Definition of Done. Wenn zu jeder Änderung Tests gehören, wächst die Prüfbasis im gleichen Tempo wie der Code. Tests lassen sich ihrerseits mit KI-Unterstützung entwerfen – allerdings gilt hier derselbe Vorbehalt: Ein Test, den niemand gelesen hat, prüft möglicherweise die falsche Annahme.

Reviews priorisieren statt gleichmäßig verteilen. Nicht jede Änderung braucht die gleiche Prüftiefe. Sinnvoll ist es, Risikobereiche zu definieren – Authentifizierung, Zahlungsprozesse, personenbezogene Daten, Schnittstellen – und dort verbindlich intensiver zu prüfen.

Automatisierte Pipelines. Statische Codeanalyse, Abhängigkeitsprüfungen und Testläufe bei jedem Commit fangen einen Teil der Standardfehler ab, ohne Personalzeit zu binden. Das ersetzt kein Review, entlastet es aber.

Nachvollziehbarkeit sichern. Es hilft, im Team festzuhalten, an welchen Stellen mit welcher Unterstützung gearbeitet wurde. Nicht als Kontrolle, sondern damit spätere Fehlersuche weiß, wo Kontextwissen fehlen könnte.

Die Budgetseite

Für Entscheidungen ist ein Punkt zentral: Die Zeitgewinne der Codegenerierung sind sichtbar und werden früh im Projekt realisiert. Die Kosten unzureichender Qualitätssicherung entstehen später und tauchen in anderen Budgets auf – in Support, Wartung, Nachbesserung oder im Ausfall.

Wer die Ersparnis der einen Seite einplant, ohne die Prüfseite mitzufinanzieren, verschiebt Aufwand in die Zukunft, statt ihn zu senken. In Angeboten und Projektplänen sollte der Testanteil daher als eigener Posten erkennbar sein, nicht als Restgröße.

Einordnung

Für Web- und Softwareprojekte verschiebt sich damit der eigentliche Hebel: Der Gewinn liegt nicht in mehr generiertem Code, sondern in einer Prüfkette, die diesem Output gewachsen ist. Wer Testautomatisierung, klare Review-Regeln und definierte Risikobereiche früh im Projekt verankert, kann das Tempo tatsächlich nutzen. Wer sie nachträglich einführt, bezahlt den Unterschied im Betrieb.

Quellen