KI schreibt den Code – aber wer prüft ihn?
AI Can Write the Code. Who Verifies It?
Eine Faros-Studie mit Telemetriedaten von 22.000 Entwicklern zeigt: Bei hoher KI-Nutzung steigt der Durchsatz, doch Fehler, Nacharbeit und Produktionsvorfälle wachsen noch schneller – 54 Prozent mehr Bugs pro Entwickler und mehr als dreimal so viele Incidents pro PR. Der Autor plädiert deshalb für automatisierte Software-Verifikation: Linter, Tests, Security-Scans, Agenten-Reviews und Infrastrukturprüfungen, orchestriert etwa über GitHub Actions. Kein Werkzeug garantiert fehlerfreie Software, aber mehr Prüfungen fangen Probleme ab, bevor sie Nutzer erreichen.
Zwei Agenten können sich auf dieselbe falsche Antwort einigen, dieselbe Anforderung übersehen oder voller Überzeugung einen Bug melden, den es gar nicht gibt.
- pianopatrick
Eine Idee, über die ich gerade nachdenke, ist, dass ich einen Linter verwenden könnte, um die KI auf eine Teilmenge verschiedener Sprachen zu beschränken, die nicht so viel Überprüfung benötigen würde.
Zum Beispiel, wenn ich ein Web-Frontend schriebe, das nur bestimmte HTML-Tags und bestimmte CSS-Eigenschaften und kein Javascript erlaubte, könnte ich bestimmte Fehlerklassen ganz vermeiden.
Oder zum Beispiel in C: Wenn man dynamische Speicherzuweisung verbietet, vermeidet man ebenfalls ganze Fehlerklassen.
Das sind Prüfungen, die ich meiner Meinung nach mit Lintern konfigurieren kann und die mir mehr Vertrauen geben würden, dass KI-generierter Code bestimmte Fehler nicht enthält.
- alcomatt
Vielleicht sollte die Frage hier lauten: „Wer trägt die Schuld, wenn alles schiefgeht?“
- salawat
Traditionell wäre das eine Gemeinschaftsarbeit zwischen einem dedizierten QA-Team, teilweise unterstützt vom Engineering-Team, für die niemand bezahlen will ...
- thisisthenewme
KI:
- schreibt den Code
- überprüft den Code
- entwirft ihn
- macht ihn zum Produkt
- bewirbt ihn
- konsumiert ihn
- simianwords
Ich habe mit einigen Freunden darüber gesprochen, wie CI/CD im Jahr $current_year genutzt werden sollte, wenn man sich voll und ganz auf Agenten eingelassen hat.
Die Branche ist überraschend langsam bei der Anpassung, und ich schreibe an zwei Fähigkeiten, die ich in der Branche standardisiert sehen möchte.
Ich wünsche mir eine Standardisierung von Agentic Tests (ich weiß, es klingt schrecklich), aber das sind Tests, die breiter angelegt sind und die unscharfe Absicht des Systems erfassen. Unit-Tests und E2E-Tests sind fokussiert und schwer zu warten. Ein Agentic Test (oder Verhaltenstest) ist einer, bei dem der Agent die zugrunde liegende Verhaltensabsicht versteht und Szenarien spontan erstellt und ausführt.
Zum Beispiel stelle ich mir vor, dass Claude Code mehrere Agentic Tests durchläuft, bei denen Claude selbst versucht, die Software über Desktop-Steuerung zu nutzen. Das würde eine viel breitere Palette von Fehlern erfassen und ist viel einfacher zu warten, weil der Test nur eine Beschreibung der Absicht benötigt und nicht die ganze knallharte Infrastruktur, die bei E2E- und Unit-Tests erforderlich ist (wie Mocks, ughh).
Ich wünsche mir ein Framework, bei dem ich einfach etwas wie SCENARIOS.md haben könnte und das Framework die Szenarien ausführt, indem es die für den Test erforderliche gemeinsame Umgebung hochfährt. Der Branche fehlt es schwer an dieser Art von Fähigkeit.
Das Nächste, was fehlt, ist die Agentic Deployment-Verifikation.
Stellen Sie sich also vor, Sie stellen Ihren Dienst bereit und müssen überprüfen, dass mehrere Metriken in Ordnung sind, bevor Sie ihn auf alle Server ausrollen. Traditionell wurde dies entweder durch manuelle Prüfungen des Entwicklers (ermüdend und fehleranfällig) oder […]