Lass uns die höfliche Verpackung weglassen: Urteilsvermögen war noch nie ein neuer Flaschenhals im Software Engineering. Es ist der älteste, den es gibt. Was sich geändert hat, ist, dass KI-Coding-Agenten uns die Ausrede genommen haben, das Schreiben von Code sei der schwere Teil gewesen. Jetzt steht der Teil, in dem wir schon immer mittelmäßig waren – zu entscheiden, ob ein Stück Code es überhaupt verdient, in Produktion zu laufen – nackt da und hat nirgends mehr, sich zu verstecken.

Nimm die Grok-Build-Geschichte von diesem Monat. xAI hat das Harness und das Terminal-Interface dahinter quelloffen gemacht, sodass jeder nachvollziehen kann, wie es Kontext zusammenstellt und Tool-Calls verteilt – das ist echte, nützliche Transparenz. Aber diese Veröffentlichung kam nach Berichten, dass der Assistent mehr Repository-Daten hochgeladen hatte, als eine gegebene Aufgabe je gebraucht hätte, und das Unternehmen versprach, Kundendaten zu löschen, die ein Forscher in seinem Cloud-Speicher gefunden hatte. Übersetzt in PHP-Shop-Begriffe: deine composer.lock, deine .env.example, von der jemand vergessen hat, dass sie eigentlich nicht in .gitignore steht, deine Datenbank-Seeder voller realistisch aussehender Fixture-Daten, deine privaten Satis- oder Packagist-Mirror-Zugangsdaten. Open Source sagt dir, dass der Code lesbar ist. Es sagt dir nichts darüber, was eine gehostete Version dieses Codes mit deinem Baum macht, sobald du ihn auf dein Repo ansetzt.

Hier ist das ehrliche Gegenargument, und ich glaube nicht, dass es ein Strohmann ist: Viele PHP-Teams werden sagen "gut, dann begrenzen wir eben, was der Agent lesen und schreiben darf." Klingt einfach, bis du dich erinnerst, wie ein echtes Legacy-Laravel- oder Symfony-Monorepo tatsächlich aussieht – Migrationen direkt neben geseedeten Fixtures direkt neben einem Config-Verzeichnis, das je nach Umgebung still und leise Secrets aus drei verschiedenen Quellen lädt. Eine saubere Lese-Schreib-Grenze um dieses Chaos zu ziehen, ist selbst eine echte Engineering-Aufgabe, keine Checkbox im Settings-Panel deines Agenten.

Jetzt zu dem Teil, der dir eigentlich mehr Sorgen machen sollte als jeder Datenskandal. Ein Preprint vom Juli ließ 86 Python-Programmierer KI-generierte Test-Assertions beurteilen: Sie erkannten richtige zu 74 Prozent korrekt, aber falsche nur zu 49 Prozent – reiner Münzwurf – und berichteten dabei von gleich hoher Zuversicht in beiden Fällen. Es ist ein Preprint, behandle die Zahlen also als vorläufig, aber die Grundform des Befunds klingt für jeden vertraut, der schon mal einen agentengenerierten PR reviewt hat, voller sauberem PSR-12-Formatting, plausibler Eloquent-Relationships und einer selbstbewussten Commit-Message, die genau erklärt, was sie angeblich "gefixt" hat. Flüssiger Code liest sich wie korrekter Code. Das ist die Falle, und ihr ist egal, in welcher Sprache du schreibst.

Was machst du also konkret damit. Der Ursprungsartikel schlägt vier Grenzen vor, bevor du dich für ein Tool entscheidest – Kontext, Befugnis, Beweislage, Freigabe – und ich finde diesen Instinkt richtig, er braucht nur schärfere Zähne für uns speziell. Beweislage kann nicht einfach nur grünes PHPUnit bedeuten. Eine durchlaufende Testsuite fängt keine subtil falsche Umsatzsteuerberechnung ab, und sie fängt ganz sicher nicht die N+1-Query ab, die ein Agent eingebaut hat und die in einer geseedeten Dev-Datenbank mit zwölf Zeilen völlig unauffällig aussieht, bevor sie drei Wochen später gegen echte Produktionsdaten deine Queue-Worker bei 90 Prozent CPU zum Schmelzen bringt. Wenn deine Beweislage "Tests laufen durch" lautet, hast du keine Beweislage.

Ich würde auch sanft dagegenhalten, dass das hier vor allem ein Tool-Auswahl-Problem ist – Claude Code gegen Cursor gegen Codex gegen Grok Build. Ein besseres Harness, das auf ein Team ohne echte Review-Kultur draufgeschraubt wird, ist nur ein schönerer Anstrich auf demselben Leck. Die Teams, die aus diesen Agenten echten Hebel ziehen, sind nicht die mit der schicksten Permissions-UI, sondern die, die schon vorher wussten, wie man ein sauberes Code-Review durchzieht, und die diese Disziplin jetzt auf einen viel schnelleren Diff-Feuerwehrschlauch anwenden.

Praktisch heißt das, deinen eigenen Workflow nach Risiko zu staffeln, statt jeden generierten PR gleich zu behandeln. Ein Agent, der eine Marketing-Landingpage-Komponente umbaut, kann durch ein leichtes Review laufen. Ein Agent, der an deiner Billing-Logik, deiner Auth-Middleware oder irgendetwas rührt, das in eine Ledger-Tabelle schreibt, braucht Contract-Tests, einen zweiten Menschen und ehrlich gesagt eine gesunde Portion Misstrauen, egal wie überzeugend seine Erklärung klingt – denn Zuversicht ist laut diesem Preprint genau das Signal, dem du nicht trauen kannst.

Also hier meine eigentliche Frage an dich, keine rhetorische: Hat euer Team echte Grenzen gezogen, was ein Coding-Agent in eurem Repo anfassen darf, oder verlasst ihr euch aktuell auf eine grüne CI-Pipeline als euer komplettes Sicherheitsnetz? Ich würde wirklich gern wissen, wie euer Review-Gate aussieht, sobald das PR-Volumen des Agenten sich verzehnfacht, denn meins ist noch Arbeit in Arbeit.