Evidence-Driven Development
Die fehlende Disziplin in der KI-gestützten Entwicklung
Die Teams führten KI-Codierungstools ein, sahen kurzfristige Geschwindigkeitsspitzen und zahlten die Verifizierungssteuer später bei Debugging, Regressionen und Produktionsvorfällen.
Die Lücke ist keine Generation. Die Lücke ist ein Beweis. Evidence-Driven Development verwandelt diese Lücke in einen wiederholbaren Workflow mit expliziten Gates.
Die Schleife
Das Modell ist einfach: Absicht definieren, Lücke beweisen, Basislinie erfassen, implementieren, Erfolg beweisen, Ergebnis erfassen und Qualitätsdimensionen vor der Überprüfung überprüfen.
Die entscheidende Einschränkung ist die Reihenfolge. Schritte vor der Umsetzung schaffen Sicherheit; Schritte nach der Umsetzung schaffen Vertrauen.
| Phase | Was passiert | Warum es wichtig ist | | --- | --- | --- | | Dokument | Schreiben Sie vor der Implementierung auf, was „erledigt“ bedeutet. | Verhindert driftende Anforderungen und vage Erfolgskriterien. | | Test: Nicht bestanden | Definieren Sie Tests, die beweisen, dass die Lücke besteht, und führen Sie sie durch. | Bestätigt, dass Sie Verhalten und keine Annahmen testen. | | Aufnahme: Vorher | Zeichnen Sie die Ausgangsergebnisse auf, bevor Sie mit der Implementierung beginnen. | Bietet nicht verhandelbare Beweise für Gutachter und zukünftige Audits. | | Implementieren | Wenden Sie die Änderung mit KI-Unterstützung unter Einschränkungen an. | Die Ausführung bleibt schnell, während die Messlatte menschlich definiert bleibt. | | Test: Bestanden | Führen Sie gezielte Tests durch und bestätigen Sie, dass das Verhalten jetzt erfolgreich ist. | Validiert die Änderung und löst die genauen Akzeptanzkriterien. | | Aufnahme: Nachher | Sammeln Sie gleichwertige Artefakte nach der Änderung. | Ermöglicht einen klaren Vorher-/Nachher-Vergleich. | | Überprüfen | Überwachen Sie Sicherheit, Zugänglichkeit, Leistung, Dokumente und Drift. | Fängt Fehlermodustests allein auf, die fehlschlagen. | | Rezension | Der menschliche Prüfer akzeptiert oder lehnt auf der Grundlage von Beweisen ab. | Hält die Verantwortung gegenüber den Ingenieuren, nicht gegenüber Eingabeaufforderungen. |
:::Grafikname: ImplementationLoopDiagram-Beschriftung: Die Implementierungsschleife: Vom Menschen definierte Einschränkungen, KI-unterstützte Ausführung. :::
| Phase | Was passiert | Warum es wichtig ist |
|---|---|---|
| Document | Schreiben Sie vor der Implementierung auf, was „erledigt“ bedeutet. | Verhindert driftende Anforderungen und vage Erfolgskriterien. |
| Test: Nicht bestanden | Definieren Sie Tests, die beweisen, dass die Lücke besteht, und führen Sie sie durch. | Bestätigt, dass Sie Verhalten und keine Annahmen testen. |
| Aufnahme: Vorher | Zeichnen Sie die Ausgangsergebnisse auf, bevor Sie mit der Implementierung beginnen. | Bietet nicht verhandelbare Beweise für Gutachter und zukünftige Audits. |
| Implement | Wenden Sie die Änderung mit KI-Unterstützung unter Einschränkungen an. | Die Ausführung bleibt schnell, während die Messlatte menschlich definiert bleibt. |
| Test: Bestanden | Führen Sie gezielte Tests durch und bestätigen Sie, dass das Verhalten jetzt erfolgreich ist. | Validiert die Änderung und löst die genauen Akzeptanzkriterien. |
| Aufnahme: Nachher | Sammeln Sie gleichwertige Artefakte nach der Änderung. | Ermöglicht einen klaren Vorher-/Nachher-Vergleich. |
| Verify | Überwachen Sie Sicherheit, Zugänglichkeit, Leistung, Dokumente und Drift. | Fängt Fehlermodustests allein auf, die fehlschlagen. |
| Review | Der menschliche Prüfer akzeptiert oder lehnt auf der Grundlage von Beweisen ab. | Hält die Verantwortung gegenüber den Ingenieuren, nicht gegenüber Eingabeaufforderungen. |
Bevor Beweise in der Praxis irreversibel sind
Teams können theoretisch nach Beginn der Implementierung eine Baseline rekonstruieren, aber fast niemand tut dies. Die Dynamik verlagert sich auf die Fixierung nach vorne.
Aus diesem Grund wird das Fehlen von Vorher-Beweisen in disziplinierten Schleifen als Reset-Bedingung behandelt.
:::grafischer Name: MaturityLadder-Beschriftung: Reifegradmodell: Ad-hoc für auditverifiziertes Engineering. :::
Das Audit: Zehn Dimensionen
| Dimension | Was es erkennt |
|---|---|
| Build | Kompilierung, Lint und Suite-Integrität |
| Telemetry | PII-Lecks und unsichere Protokollierungsnutzlasten |
| Accessibility | Orientierungspunkte, Tastaturfluss, Überschriftenhierarchie |
| Security | Geheimnisse, Injektionsrisiko, Abhängigkeitsfehler |
| Performance | N+1 Pfade, unbegrenzte Schleifen, Speicherlecks |
| Documentation | Spezifikations- und Implementierungsdrift |
| Testabdeckung | Verhaltensänderungen ohne Matching-Tests |
| TODO-Schulden | Übersprungene Folgeanfragen und ungelöste Platzhalter |
| Fehlerbehandlung | Verschluckte Fehler und durchgesickerte Interna |
| KI-Ausführlichkeit | Redundante Kommentare und unnötige Abstraktionen |
Das Audit: Zehn Dimensionen
| Dimension | Was es fängt | | --- | --- | | Bauen | Kompilierung, Lint und Suite-Integrität | | Telemetrie | PII-Lecks und unsichere Protokollierungsnutzlasten | | Barrierefreiheit | Orientierungspunkte, Tastaturfluss, Überschriftenhierarchie | | Sicherheit | Geheimnisse, Injektionsrisiko, Abhängigkeitsfehler | | Leistung | N+1 Pfade, unbegrenzte Schleifen, Speicherlecks | | Dokumentation | Spezifikations- und Implementierungsdrift | | Testabdeckung | Verhaltensänderungen ohne Matching-Tests | | TODO-Schulden | Übersprungene Follow-ups und ungelöste Platzhalter | | Fehlerbehandlung | Verschluckte Fehler und durchgesickerte Interna | | KI-Ausführlichkeit | Redundante Kommentare und unnötige Abstraktionen |
:::Grafikname: AuditRadarChart-Bildunterschrift: Prüfungslage vor und nach evidenzbasierten Prüfungen. :::
Beispielnachweise nach Bereich
| Bereich | Nachweis davor | Nachweis danach |
|---|---|---|
| API-Endpunkt | Curl-Antwort mit falschem Status | Curl-Antwort mit erwartetem Status und Schema |
| Datenbankmigration | Abfrage vor der Migration | Abfrage mit neuen Spalten und ausgefüllten Werten |
| Infrastructure | Aktuelle Planausgabe | Gewünschte Ausgabe planen und anwenden |
| Performance | Benchmark-Basislinie | Benchmark-Delta nach der Optimierung |
| Sicherheitspatch | Scannerfund | Scanner-Reinigungsbericht |
Die Beweislast bei Pull-Anfragen
Quellen
- Kent Beck (2025) Augmented Coding: Beyond the Vibes
- ThoughtWorks (2025) KI-gestützte Test-First-Entwicklung
- METR (2025) KI-Tools machten erfahrene Entwickler um 19 % langsamer
- Addy Osmani (2026) KI schreibt Code schneller. Ihre Aufgabe besteht immer noch darin, zu beweisen, dass es funktioniert.
- Microsoft .NET (2026) Zehn Monate mit Copilot Coding Agent in Dotnet/Runtime