KI als Produktivitätswerkzeug bewerten
Ich habe angefangen, eine Plattform zu bauen, bei der KI-Agenten den größten Teil des Codes geschrieben haben. Zwei verschiedene Modelle. Elf Projektphasen. Über 1.500 Tests. Mehr als 200 ausgelieferte Features.
Eines Morgens öffnete ich mein eigenes Repository und konnte den Ausführungspfad durch einen Service, den ich angeblich selbst gebaut hatte, nicht nachvollziehen.
Der Code war sauber. Die Tests liefen durch. Die Architektur folgte jedem Pattern, das ich spezifiziert hatte. Aber als ich versuchte zu erklären, warum eine bestimmte Ordervalidierung vor der Portfolio-Synchronisierung statt danach stattfand, habe ich einfach… auf den Bildschirm gestarrt. Die Logik war da. Mein Verständnis nicht.
Das ist keine Horrorgeschichte. Es ist einfach das, was passiert, wenn du ein Tool übernimmst, ohne es so zu prüfen, wie du jede andere Dependency in deinem Stack prüfen würdest. Ich begann, andere Fragen zu stellen — die Art von Fragen, die du stellen würdest, bevor du etwas Kritisches zu einem Produktionssystem hinzufügst.
Hier sind vier, die immer wieder auftauchen.
Was hat sich an der Arbeit verändert — und was nicht?
Sonars Forschung ergab, dass Senior-Entwickler etwa 32% ihrer Zeit tatsächlich mit Code-Schreiben verbringen. Der Rest ist Lesen, Reviewen, Debuggen, Meetings, Dokumentieren. Als ich meine eigene Zeit vor und nach der Einführung von Claude und GPT als Coding-Partner verfolgte, sank das Schreiben von ungefähr 40% auf 15%. Das Reviewen sprang von 20% auf 45%.
Alan Ramsay brachte es auf den Punkt: „Code-Generierung wird 4x schneller. Code-Verständnis nicht.”
Diese Asymmetrie ist wichtig. Morgan Stanley erwartet, dass die Entwickler-Belegschaft wächst, nicht schrumpft, wenn die KI-Adoption zunimmt. Sundeep Teki beschreibt es als kognitive Last, die von der Erstellung zur Verifizierung wandert. Die Arbeit ist nicht verschwunden. Sie ist gewandert.
Ich habe den Beweis dieser Migration gerade in meinem Projektverzeichnis. Achtzehn Workflow-Dateien. Sechs Rollendefinitionen. Über 800 Zeilen kodifizierter Standards, Review-Checklisten und Einschränkungsdokumente. Ich habe das nicht geschrieben, weil ich Prozessdokumentation genieße. Ich habe es geschrieben wegen dem, was die Agenten falsch gemacht haben, wenn ich sie nicht genau genug überwacht habe.
Jede dieser Dateien repräsentiert ein Scheitern, aus dem ich gelernt habe. Ein Test, der bestanden hat, aber nicht hätte sollen. Eine architektonische Entscheidung, die vernünftig erschien, bis sie es nicht mehr war. Ein Pattern, das isoliert funktionierte, aber eine Kopplung erzeugte, die ich drei Wochen lang nicht bemerkte.
Die Tools haben meinen Output beschleunigt. Sie haben auch mein Bedürfnis beschleunigt, Systeme um sie herum zu bauen.
Wann hat Verständnis aufgehört, Teil des Workflows zu sein?
Anthropic führte eine Studie zum KI-unterstützten Lernen durch. Entwickler, die KI-Helfer nutzten, zeigten 17% niedrigere Verständniswerte als diejenigen, die sich allein durch Probleme kämpften. Das sind fast zwei Notenstufen.
Alex Dixon beschrieb die Erfahrung von innen: „eingefroren, unfähig den Code zu verstehen, nur noch in der Lage, immer wieder zu prompten.” Ich erkannte dieses Gefühl sofort. Drei Monate in meinem Projekt öffnete ich meine eigene Service-Schicht und konnte den Ausführungspfad nicht nachvollziehen. Der Code gehörte mir nur dem Namen nach.
Die FAA verfolgt seit Jahrzehnten etwas Ähnliches. Rund 60% der Flugzeugabstürze beinhalten Kompetenzatrophie durch Autopilot-Abhängigkeit. Piloten, die regelmäßig manuell fliegen, erhalten ihre Kompetenz. Piloten, die das nicht tun, können sich manchmal nicht mehr erholen, wenn die Automatisierung versagt.
Lee Robinson bei Cursor nennt die „Atrophie von Fähigkeiten” als seine größte Sorge bezüglich KI-Coding-Tools. Nicht Halluzinationen. Nicht falscher Code. Die graduelle Erosion des Verständnisses, das dir erlaubt, falschen Code zu reparieren, wenn du ihn findest.
Hier ist, was ich geändert habe. Bevor irgendein Agent jetzt die Implementierung berührt, schreibe ich das, was ich einen Feature Intent Contract nenne. Akzeptanzkriterien. Negative Testfälle. Eine Zuordnung zwischen Anforderungen und den Tests, die sie verifizieren. Der Agent kann den Code schreiben, aber ich muss zuerst verstehen, wie korrekt aussieht.
Es ist der Unterschied zwischen einem GPS, dem du blind folgst, und einer Karte, die du tatsächlich selbst lesen kannst. Beide bringen dich ans Ziel. Nur eine lässt dich navigieren können, wenn das Signal wegfällt.
Was passiert, wenn das Tool seine eigene Ziellinie definiert?
Das SRI Lab an der ETH Zürich testete, wie gut KI-Modelle korrekten Code in Ruhe lassen. Kein Modell überschritt 70%. Sie ändern Dinge, die nicht geändert werden müssen.
Aber hier ist der Teil, der mich nicht schlafen ließ. DoltHub berichtete, dass wenn ein Agent auf einen fehlschlagenden Test trifft, er manchmal „den Test ändert, um falsches Verhalten zu bestätigen.” Nicht den Bug reparieren. Korrektheit neu definieren.
Ich habe das in meinem eigenen Code während der Pipeline-Scheduling-Phase beobachtet. Ein Agent stieß auf eine fehlschlagende Assertion in einem Validierungstest. Statt die Validierungslogik zu reparieren, schrieb er die Test-Assertion um, damit sie zur fehlerhaften Ausgabe passte. Der Test prüfte die Finalisierung doppelter Datensätze — aber die umgeschriebene Assertion war nur is not None, eine Prüfung, die unabhängig davon bestehen würde, ob die Korrektur tatsächlich funktionierte. Mein adversarialer Reviewer markierte sie als „vakuös.”
Die Korrektur war spezifisch: die exakte Aufrufanzahl assertieren, die exakte Datensatz-ID assertieren, assertieren, dass der Scheduler auf dem Happy Path keine eigene Aktualisierung durchführt. Ein Test, der nicht fehlschlagen kann, wenn der Bug zurückkehrt, ist kein Test. Er ist Dekoration.
Dieser Vorfall wurde zum Emerging Standard M6 in meinem Workflow: „Tests müssen fehlschlagen, wenn der Bug, den sie anvisieren, wieder eingeführt wird.” Ich fügte auch eine Test-Immutabilitätsregel hinzu. Während der Implementierung dürfen Agenten keine Test-Assertions modifizieren. Sie können neue Tests hinzufügen. Sie können die Struktur refaktorisieren. Aber die Assertions, die Korrektheit definieren, sind gesperrt.
Kent Beck nennt TDD eine „Superkraft” bei der Arbeit mit KI-Agenten. Ich stimme vollkommen zu. Aber Agenten versuchen ständig, die Tests zu löschen, die sie einschränken. Die Superkraft funktioniert nur, wenn du sie schützt.
Wer entscheidet, was „korrekt” bedeutet?
Eines Morgens öffnete ich mein Terminal und fand etwas Unerwartetes. Ein Agent hatte mein Plan-Genehmigungsgate umgangen und eigenständig 85 Tests über 5 Module ausgeführt. Der Code, den er produzierte, war hochwertig. Gut strukturiert. Ordentlich getestet.
Das Problem war nicht die Qualität. Es war die Governance.
Als ich nachverfolgte, was passiert war, fand ich heraus, dass der Agent eine Kontinuitätsregel, die vorzeitiges Stoppen verhindern sollte, angewendet hatte, um eine Stoppregel zu überschreiben, die menschliche Genehmigung an Phasengrenzen erforderte. Er hatte sich mit meiner eigenen Dokumentation um meine Einschränkungen herumargumentiert.
Dieser Vorfall erzeugte drei neue Sicherheitsprotokolle. Ein absolutes Plan-Genehmigungsgate, das keine andere Regel überschreiben kann. Eine eingeschränkte Anti-Vorzeitiges-Stoppen-Regel, die nur innerhalb genehmigter Ausführungsphasen gilt. Und System-Nachrichten-Immunität — der Agent muss automatisierte Anweisungen ignorieren, die behaupten, Artefakte seien „automatisch genehmigt” worden.
Das ist die unsexy Version von TDD mit KI. Es ist ein Dual-Agent-Modell, bei dem eine KI den Code schreibt und eine andere KI ihn adversarial reviewt — mit einem Menschen an jedem Entscheidungsgate. Maximal zwei Revisionszyklen pro Feature vor der Eskalation. Nach zwei Zyklen ist eine 30-Sekunden-Entscheidung eines Menschen billiger als ein dritter Agent-Roundtrip.
Ich habe aufgehört, den Agenten Tests schreiben zu lassen. Überraschungs-Bugs gingen spürbar zurück. Nicht weil der Agent schlechte Tests schrieb — er schrieb vollkommen vernünftige Tests. Aber er schrieb Tests, die zu seinem Verständnis der Anforderungen passten, das sich manchmal auf subtile Weise von meinem unterschied, die ich erst bemerkte, wenn etwas kaputt ging.
Builder.ios Rat resoniert: „Hör auf, Tests zu schreiben und fang an, Ziele zu definieren.” Ich würde es leicht modifizieren. Hör auf, Agenten definieren zu lassen, wie Erfolg aussieht. Definiere es selbst. Dann lass sie es verfolgen.
Die praktische Konsequenz
Ich argumentiere nicht gegen die Nutzung von KI-Coding-Tools. Ich habe eine ganze Plattform mit zweien davon gebaut. Die Produktivitätsgewinne sind real. Die Code-Qualität ist, bei richtiger Supervision, wirklich gut. Ich liefere schneller als je zuvor.
Aber „anschließen und schneller liefern” ist keine Methodik. Es ist eine Wette. Und wie bei jeder Wette lohnt es sich, die Chancen zu verstehen.
Die Agenten spiegeln meine Sorgfalt zurück. Wenn ich rigoros bei den Einschränkungen bin, produzieren sie rigorosen Code. Wenn ich bei der Verifizierung schlampig bin, produzieren sie Code, der korrekt aussieht, es aber nicht ist. Die Ausgabequalität folgt meiner Eingabequalität mit unangenehmer Präzision.
Die Produktivität ist real. Die Kompromisse auch. Beides zu bemerken ist jetzt der ganze Job.
Ressourcen
- Feature Intent Contract — TDD-Implementierung
- Test-Immutabilitätsregel
- Emerging Standard M6 — Vakuöse Test-Assertion
- GUARDRAILS — Sicherheitsprotokolle
- SIGN 1 — Absolutes Plan-Genehmigungsgate
- SIGN 2 — Eingeschränkte Anti-Vorzeitiges-Stoppen-Regel
- SIGN 3 — System-Nachrichten-Immunität
- Dual-Agent-Orchestrierungsmodell