Vertrauen aufbauen, bis man zu liefern wagt
Die Korrektheit eines Systems lässt sich nicht beweisen – man kann nur genug begründetes Vertrauen aufbauen, dass das Ausliefern eine verantwortbare Entscheidung wird und keine bloße Hoffnung. Genau darum geht es in der Qualitätsarbeit, und sie hängt ebenso an den Prozessen wie an den Tests: die Testdisziplinen – testgetriebene und verhaltensgetriebene Entwicklung, Embedded-Testing –, die Fehler früh sichtbar machen, und daneben die Arbeit, die aus “wir glauben, es läuft” etwas macht, das man belegen kann: klare Anforderungen, ernst genommene Reviews, Nachvollziehbarkeit und Verifikationsschritte wie Specify and Verify.
Wo das Produkt auf Hardware läuft oder unter Sicherheitsauflagen steht, liegt die Latte höher: Embedded-Testing, Continuous Integration und Safety- und Security-Praxis, weil ein Fehler dort ein Rückruf ist und kein schneller Patch. Und Compliance ist kein nachgereichter Papierkram mehr – für eine wachsende Klasse von Systemen entscheidet der EU AI Act, ob sie überhaupt ausgeliefert werden dürfen.
KI verschärft das, ohne die Disziplin zu verändern. Wird die Umsetzung generiert, sieht der Code fertig und selbstsicher aus, ehe ihn überhaupt jemand geprüft hat. Und genau im Spalt zwischen plausibel und nachgewiesen, wo die Fehler seit jeher sitzen, wird es enger und voller. Dafür kommt genug Sicherheit in den Werkzeugen Ihrer Teams dazu (Claude Code, Cursor, Copilot, Junie), um deren Ergebnisse glaubwürdig zu prüfen und nicht nur von außen.
Ohne Verifikation verhindert Tempo kein Scheitern – es verschiebt es nur auf einen teureren Zeitpunkt. Wo Hardware im Spiel ist, führt die Embedded-Schule die Safety- und Security-Varianten; den Entwickler-Workflow, in dem diese Praktiken stecken, zeigt der Lernpfad KI-gestützte Softwareentwicklung.