Warum das seit KI-gestützter Entwicklung kein Mangel mehr ist — und wo es aufhört
1. Die These
„Software wird nie fertig" ist einer der ältesten Sätze der Branche. Vierzig Jahre lang war er eine Entschuldigung: für Termine, die nicht hielten, für Fehlerlisten, die nie kürzer wurden, für Systeme, die man irgendwann nicht mehr anfasste, weil jede Änderung teurer war als das Ertragen des Zustands.
Mit KI-gestützter Entwicklung kehrt sich der Satz um.
Wenn eine Anpassung Stunden statt Wochen kostet, ist die nie endende Änderung kein Eingeständnis von Unfertigkeit mehr. Sie wird zur Betriebsart. Man passt die Software an einen geänderten Arbeitsablauf an, während der Ablauf sich ändert — nicht zwei Quartale später. Altlasten wandern nicht mehr in ein Refactoring-Projekt, das nie kommt, sondern werden beim nächsten Deploy mitgenommen, weil das Mitnehmen billiger ist als das Verwalten der Ausnahme.
Aber der Satz gilt nur für eine Hälfte des Systems. Der Code ist billig geworden. Die Daten sind es nicht. Wer das verwechselt, baut sich schneller in eine Sackgasse als je zuvor — genau deshalb steht Abschnitt 4 im Zentrum dieses Papiers und nicht in einer Fußnote.
2. Was sich tatsächlich geändert hat
Nicht die Qualität des Codes hat sich geändert, sondern die Kostenkurve der Änderung.
Klassisch steigt der Aufwand einer Anpassung mit dem Alter des Systems: Einarbeitung, Suche nach der Stelle, Angst vor Nebenwirkungen, Abstimmung, Test. Der größte Posten war nie das Schreiben, sondern das Verstehen. Genau dieser Posten fällt, wenn ein Agent das System in einer Sitzung überblickt, statt es sich über Wochen anzueignen.
Die praktische Folge ist nicht „mehr Features". Sie ist eine andere:
Die Schwelle, ab der sich eine Verbesserung lohnt, sinkt drastisch.
Damit werden Dinge machbar, die vorher als „lohnt nicht" abgelegt wurden: die unglückliche Feldreihenfolge in einer Maske, die drei Klicks, die niemand braucht, die Fehlermeldung, die niemand versteht. Einzeln sind das Kleinigkeiten. Zusammen sind sie der Unterschied zwischen Software, mit der man arbeitet, und Software, gegen die man arbeitet.
Und der Prozess muss das aushalten. Ein Entwicklungsprozess, der auf seltene, große Releases ausgelegt ist, wird bei dieser Kadenz zum Engpass. Unser eigener Prozess ist deshalb um eine Ticket-Schleife gebaut und nicht um ein Release-Ritual — mit einer eigenen Vorstufe für den Fall, dass noch gar kein Auftrag existiert.
3. Der Deploy als Prüfstelle — wie Verbesserung von der Absicht zur Mechanik wird
Kontinuierliche Verbesserung scheitert selten an der Einsicht. Sie scheitert daran, dass sie freiwillig ist. Wer sie freiwillig lässt, bekommt sie in guten Wochen und verliert sie in schlechten — also genau dann, wenn sie gebraucht wird.
Der Ausweg ist unspektakulär: Man hängt die Prüfung an ein Ereignis, das ohnehin stattfindet. Bei Software ist das der Deploy.
| Baustein | Was er leistet |
|---|---|
| Gates | Übersicht aller Punkte, an denen etwas erfüllt sein muss, bevor es weitergeht |
| Deploy-Gate | Die Qualitätsanforderungen laufen bei jedem Deploy, nicht bei jedem zweiten |
| Pflicht-Feedback | Ein Querschnitt: bei jedem Paket-, Deploy-, Bug- und Testabschluss wird festgehalten, was besser laufen muss |
| Befundlauf | Der Fall, dass die Arbeit aus dem System selbst kommt — nicht aus einem Auftrag |
Der Befundlauf ist dabei der eigentlich interessante. Ein Prozess, der nur auf Aufträge reagiert, kann nicht kontinuierlich besser werden — er kann nur abarbeiten. Erst wenn das System selbst Befunde erzeugen darf, die dann wie Arbeit behandelt werden, entsteht der Kreislauf.
ISO-Bezug. Was hier beschrieben ist, ist ISO 9001 § 10.2/§ 10.3 (Verbesserung) und § 9.1 (Bewertung der Leistung) — ohne dass man es so nennen müsste. Die Auditierbarkeit fällt als Nebenprodukt an, nicht als Zusatzaufwand. Für die Software-Qualität selbst ist die maßgebliche Norm ISO/IEC 25010:2023 (Produktqualität, SQuaRE-Familie ISO/IEC 25000).
4. Die Asymmetrie: Der Code ist billig geworden, die Daten sind es nicht
Das ist der Teil, den ein Papier über KI-gestützte Entwicklung üblicherweise auslässt.
Eine Codeänderung ist rückholbar. Sie ist versioniert, sie ist testbar, sie ist im Zweifel ein git revert. Eine Datenoperation auf einem Produktivsystem ist nichts davon:
- Sie ist schlecht rückholbar — ein
UPDATEüber Bestandsdaten hat kein Gegenstück. - Sie ist schlecht testbar — die Testdatenbank hat nie die Daten, an denen es scheitert.
- Sie ist der einzige Schritt, bei dem ein Fehler echten Schaden anrichtet. Ein kaputtes Deployment kostet eine Stunde. Ein falsches
UPDATEkostet den Bestand.
Ein Schema zu erweitern ist einfach. Bestandsdaten zu überführen ist es nicht. Genau diese Verwechslung ist die typische Falle, wenn Änderungen billig werden.
4.1 Ein Fall aus der eigenen Praxis
In einem unserer Projekte wurde ein Feld von Freitext auf ein Auswahlfeld umgestellt. Eine Änderung von Minuten. Die Eingabemaske stürzte danach ab, weil die Bestandswerte nicht mehr in die Auswahl passten.
Bemerkenswert ist nicht der Fehler, sondern seine Begründung im Bugregister:
„Eigener Fehler: Ich hatte eine Migration als ‚Überbau' abgetan."
Das ist die Versuchung in einem Satz. Wenn die Codeänderung fünf Minuten dauert, wirkt die Migration wie Bürokratie — und ist doch der einzige Teil, der nicht wiederholbar ist.
Die Regel daraus: Eine Umstellung von Freitext auf Auswahl braucht immer eine Migration.
4.2 Das Muster, das funktioniert: selbstheilendes Schema
Für eine PHP-Anwendung, die wir betreuen, gibt es dafür eine belegte Antwort: Das Plugin prüft bei jedem Aufruf selbstheilend sein Schema, statt sich auf ein Installationsereignis zu verlassen.
Der Merksatz trifft den Kern:
„Dateien vorhanden" ist nicht „Datenbank migriert". Die Migration ist ein Ereignis, kein Zustand.
Wer Dateien per FTP oder git pull tauscht, hat die Migration nicht ausgeführt — die nach dem Erst-Deploy hinzugefügte Spalte fehlt, die erste Abfrage darauf ist fatal, die ganze Ansicht ist tot.
Und selbst die Lösung hat eine Falle, die man nur durch Schaden lernt: In der ausgelieferten SQL-Datei war CREATE TABLE IF NOT EXISTS verboten — der Anwendungskern liest sie mit einem strikten Muster und stürzt daran ab. Im selbstheilenden PHP-Code ist dasselbe Statement zulässig. Dieselbe Zeile, zwei Orte, entgegengesetzte Regel.
4.3 Was das für die Datenhaltung heißt
Auch für Daten gibt es eine Norm: ISO/IEC 25012 — Datenqualität, dieselbe Familie wie 25010. In den meisten Normlandschaften steht sie am Rand. Sie gehört nicht an den Rand. Wenn der Code billig und die Daten teuer werden, verschiebt sich das Gewicht von 25010 zu 25012.
Praktische Konsequenzen:
- Additiv vor destruktiv. Spalte hinzufügen ist reversibel, Spalte umdeuten nicht. Wo möglich, neues Feld neben dem alten, Übergang in zwei Schritten.
- Die Migration gehört zum Feature, nicht dahinter. Wer sie als getrennten Arbeitsschritt führt, lässt sie unter Zeitdruck weg.
- Selbstheilung statt Installationsereignis. Der Zustand darf nicht davon abhängen, ob jemand den richtigen Knopf gedrückt hat.
- Kein
UPDATEüber Bestandsdaten ohne Vorher-Nachweis. - Zwei Schema-Besitzer sind einer zu viel. Wo sich zwei Migrationswerkzeuge eine Datenbank teilen, entsteht eine Fehlerquelle, die man beim Aufsetzen vermeiden kann und später nicht mehr.
5. Das Gedächtnis: warum Dokumentation hier Voraussetzung ist, nicht Zugabe
Es gibt einen unangenehmen Nebeneffekt billiger Änderungen: Man wiederholt verworfene Ideen schneller.
Wer einen Ansatz vor vier Monaten geprüft und verworfen hat, erinnert sich an das Ergebnis, nicht an die Begründung. Ein Agent erinnert sich an gar nichts — er liest, was dasteht. Steht die Begründung nirgends, wird der Ansatz wieder vorgeschlagen, wieder gebaut und wieder verworfen.
Deshalb ist die dokumentierte Entscheidung hier keine Formalität des Qualitätsmanagements, sondern die Funktionsvoraussetzung des ganzen Modells. Konkret drei Dinge:
- Das Warum, nicht nur das Was. Ein Verlauf, der nur Änderungen listet, verhindert keine Wiederholung. Unsere Verlaufseinträge tragen deshalb was, warum und Kontext.
- Der Ort am Arbeitsplatz. Register liegen im Projekt, nicht in einem Wiki nebenan. Was einen Umweg kostet, wird nicht gepflegt.
- Die Narbe bleibt sichtbar. Jede Regel in einer Arbeitsanweisung ist ein dokumentierter Vorfall. Wer die Regel löscht, löscht die Erfahrung.
6. Der Befund im eigenen Haus
Beim Sammeln der Belege für dieses Papier ist etwas aufgefallen, das nicht in eine Werbeschrift passt und deshalb hier steht:
In unserem verbindlichen Entwicklungsprozess kommt auf 81.658 Zeichen das Wort „Datenbank" null mal vor und „Migration" genau einmal — in einem Dokument, das für alle Softwareprojekte aller Bereiche gilt.
Geregelt sind Tickets, Deploy-Gate, Bugfix, Schlüsselwechsel und das Aufräumen von Branches. Der einzige Schritt, der auf einem Produktivsystem echten, schlecht rückholbaren Schaden anrichten kann, ist nicht geregelt. Kein Migrationsschritt, kein Vorher-Nachweis, keine Rückholstrategie, keine Aussage zu Vorlauf und Datensicherung.
Der Befund ist erfasst und wird entschieden. Wie eine solche Lücke geschlossen wird — welcher Schritt wohin gehört, welcher Nachweis vorher zu erbringen ist, wie der Rückweg aussieht — ist ein eigenes Thema und bekommt ein eigenes Papier.
Warum das hier steht: Die These dieses Papiers lautet, dass die Datenseite die Bremse ist. Ein Papier, das das behauptet und gleichzeitig verschweigt, dass der eigene verbindliche Prozess genau diese Seite nicht regelt, wäre unglaubwürdig. Der Befund ist kein Einwand gegen die These — er ist ihr Beleg.
Und er ist zugleich das Muster, um das es geht: Ein Prozess wird nicht dadurch gut, dass er einmal richtig geschrieben wurde, sondern dadurch, dass Lücken auffallen und behandelt werden. Auch Prozesse werden nie fertig.
7. Was daraus folgt
Für Entwicklungsorganisationen, die KI-gestützt arbeiten:
- Rechnen Sie den Prozess auf die neue Kadenz um. Wer die Änderungskosten senkt, aber die Freigabewege lässt, verlagert den Engpass nur.
- Trennen Sie Code- und Datenänderungen im Kopf. Für Code genügt „rückholbar". Für Daten braucht es einen Vorher-Nachweis und einen Rückweg.
- Regeln Sie die Migration ausdrücklich. Wenn sie in Ihrem Prozess nicht vorkommt, ist sie nicht abgeschafft — sie ist nur unbeaufsichtigt.
- Dokumentieren Sie Begründungen, nicht Änderungen. Sonst bauen Sie verworfene Ideen zum zweiten Mal, nur schneller.
- Prüfen Sie Ihre Normlandschaft auf die Datenseite. ISO/IEC 25010 ist etabliert. ISO/IEC 25012 steht meist daneben, obwohl das Gewicht dorthin wandert.
Die kürzeste Fassung: Der Satz „Software wird nie fertig" ist keine Ausrede mehr. Er ist eine Beschreibung des Normalbetriebs — für den Code. Für die Daten gilt er nicht, und wer den Unterschied nicht kennt, bezahlt ihn genau einmal.
Quellen
- ISO 9001:2015 — Qualitätsmanagementsysteme, insbesondere § 9.1 (Bewertung der Leistung) und § 10.2/§ 10.3 (Verbesserung)
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE): Produktqualitätsmodell
- ISO/IEC 25012:2008 — Data quality model
- Die geschilderten Vorfälle stammen aus dem eigenen Betrieb und sind in unseren Bug- und Lessons-Registern dokumentiert.
Dieses Whitepaper entstand mit Unterstützung eines KI-Assistenten. Recherche, Prüfung und Freigabe liegen bei uns.