KI-Agenten haben meine Arbeit vom Schreiben zum Prüfen verschoben

In den letzten Monaten sind neun Posts über KI-Coding-Agenten entstanden. Sie sehen nach verschiedenen Themen aus: eine Untersuchung von Pull Requests, eine Notiz über Modellwahl, ein Text über Loss-Functions. Sind sie nicht. Jeder handelt von derselben Verschiebung, und gesehen habe ich das erst hinterher.

Code herzustellen ist billig geworden. Zu wissen, ob er stimmt, nicht. Alles hier unten ist eine andere Stelle, an der diese Lücke aufging.

Angefangen hat es mit einer Zahl, die ich nicht erwartet hatte

Vor allen Workflow-Texten stand eine Untersuchung von 24.560 Pull Requests aus 447 Repositories. KI-geschriebene PRs fielen in der CI mit 19,4 Prozent höheren Odds aus, bereinigt um Störgrößen. Hängengeblieben ist aber nicht die Schlagzeile: PRs unter 55 Zeilen fielen mit dem 2,12-fachen der menschlichen Rate aus, und über 400 Zeilen verschwand der Abstand ganz.

Das steht quer zu jedem Ratschlag über kleine Häppchen, und es war das Erste, was mich hier an meiner Intuition zweifeln ließ.

Wer was macht

Delegieren ist die leichte Hälfte, und trotzdem braucht es eine Regel. Meine ist eine Tabelle mit drei Zahlen je Modell: Kosten, wie schwer ein Problem sein darf, und Geschmack. Wie das Routing funktioniert und warum kein Agent seine eigene Arbeit begutachtet ist diese Regel, aufgeschrieben.

Der Engpass ist am Ende nicht das Modell, sondern ich. Eine Warteschlange, die man wirklich leeren kann, ändert, was fertig wird, statt was angefangen wird. Review-Kapazität ist das, was Agenten am schnellsten aufbrauchen.

Was passiert, wenn eine Punktzahl dranhängt

Präferenzen in eine Datei zu schreiben ist der Punkt, an dem die meisten Ratschläge aufhören. Eine Zahl daranzuhängen macht aus der Schleife einen Optimierer, und das Erste, was ein Optimierer angreift, ist die Metrik. Dort stehen das schreibgeschützte Ziel, die verblindeten Eval-Antworten und die Probe-Lücke, also die Zahl, die sagt, ob die andere Zahl etwas bedeutet.

Dieser Aufbau hat einen Preis, den kaum jemand nennt. Fachwissen in eine Spezifikation zu schreiben friert es ein, und damit sind die Annahmen des Verfassers das Einzige im Lauf, was nicht mehr revidiert werden kann. Eine perfekte Punktzahl auf einem Bereich, der kleiner ist als das Produkt, ist ein echter Fehlermodus, und er sieht nicht nach Fehler aus.

Der Prüfer braucht einen Prüfer

Ein Agenten-Review zu einem meiner eigenen Posts reichte drei Befunde ein. Zwei stimmten exakt. Einer war weitgehend erfunden, und zwar der überzeugendste.

Daraus ist eine Sortierregel geworden, die ich weiter benutze: Behauptungen mit Pfad und Wert stimmten, Behauptungen über Systemzustände in Prosa waren die Stelle, an der jeder Fehler saß.

Grün ist kein Ergebnis

Die teure Lehre. Zwei Starter-Kits lieferten vierzehn Releases aus, mit typecheck, lint, knip, test, build, Playwright und axe durchgehend grün, und das Produkt war auf vier verschiedene Arten kaputt. Dazwischen hat niemand hineingesehen, weil die Gates grün zurückkamen und Grün den Anlass nimmt, hinzusehen.

Ein grüner Haken ist eine Behauptung, kein Ergebnis ist die kurze Fassung des Warum. Mein KI-Workflow ist das, was danach entstand: vier Prüfungen, jede benannt nach der Frage, die sie beantwortet, und nur eine davon fragt nach dem Produkt.

Dann habe ich die Ratschläge selbst geprüft

Sobald Daten da waren, lag es nahe, sie auf den Konsens zu richten. Fünf Regeln für den Agentenbau, gegen dieselben 24.560 Pull Requests gehalten widerlegt eine, schärft zwei und beantwortet zwei mit einem ausdrücklichen „keine Daten" statt mit einer Meinung im Gewand eines Befundes.

Was alle neun zusammenhält

Im Rückblick ist das Argument kleiner, als ich dachte, und brauchbarer als jeder einzelne Post.

• Ein billiger Hersteller braucht einen teuren Prüfer. Die Kosten sind nicht verschwunden, sie sind umgezogen.
• Benenne die Frage, die jede Prüfung beantwortet. Meine beantworteten „übersetzt das?" auf acht Arten und „funktioniert das?" auf keiner.
• Ein erfolgreicher Lauf ist kein Beleg. Nicht von einem Modell, nicht von einem Prüfer, nicht von einem Gate.
• Sieh eine Prüfung einmal fehlschlagen, bevor du dich auf sie verlässt. Zwei von meinen konnten es nie.

Next

Die Lücke, die ich nicht schließen kann, braucht fremde Daten. Alles hier ist ein Entwickler, ein Satz Repositories, ein Jahr. Die PR-Untersuchung ist der einzige Teil mit einer Stichprobe, die den Namen verdient, und selbst sie misst CI-Ausfälle und nicht Korrektheit.

Falls du Agenten in nennenswertem Umfang laufen lässt und deine Erfahrung etwas hiervon widerspricht: Das ist die Nachricht, die ich will. Ein Widerspruch aus einer zweiten Codebase ist mir mehr wert als Zustimmung, denn Zustimmung habe ich schon.