Mit KI programmieren: vom Auftrag zur geprüften Änderung
Ein Coding-Agent kann Dateien lesen, Änderungen schreiben und Tests ausführen. Damit eine brauchbare Änderung entsteht, braucht er den Projektkontext und ein überprüfbares Ziel. Der Arbeitsablauf endet bei der geprüften Änderung: mit nachvollziehbarem Verhalten, passenden Tests und einem Review des Ergebnisses.
4 Min. Lesezeit
10 Abschnitte
13 Quellen
Stand: 21. Juni 2026
Den Auftrag am Verhalten festmachen
„Baue einen Login“ lässt viele Entscheidungen offen. Ein genauerer Auftrag beschreibt, wer sich wie anmeldet, welche vorhandenen Komponenten genutzt werden und was bei abgelaufenen Zugangsdaten passieren soll. Gib dem Agenten außerdem die relevanten Projektregeln und Befehle.
Lass ihn vor größeren Änderungen die betroffenen Stellen lesen. Ein kurzer Plan hilft, Annahmen früh zu erkennen. Für eine kleine Korrektur kann derselbe Schritt in einem Satz geschehen; der Umfang sollte zur Aufgabe passen.
Was autonome Aufgabenlängen aussagen
METR misst, bei welcher Aufgabenlänge ein Agent eine bestimmte Erfolgswahrscheinlichkeit erreicht. Die Länge bezieht sich auf die Bearbeitungszeit menschlicher Fachkräfte, nicht auf die Laufzeit des Agenten. Eine 50-Prozent-Marke bedeutet entsprechend: Bei solchen Aufgaben gelingt ungefähr die Hälfte.
Das hilft, Fortschritte zu vergleichen. Es bedeutet nicht, dass der Agent für diese Stundenzahl zuverlässig unbeaufsichtigt arbeiten kann. Für einen Einsatz zählen zusätzlich die Art der Aufgabe, die Umgebung und die Folgen eines Fehlschlags.
Wähle Prüffälle aus deinem Projekt: einen Bugfix, eine kleine Erweiterung und eine Änderung mit mehreren betroffenen Dateien. Nutze dieselben Anforderungen und vergleichbare Werkzeugrechte. Prüfe Ergebnis, Nacharbeit, Laufzeit und Kosten.
Aktuelle Modellwerte stehen im Katalog. Eine alte Empfehlung für eine bestimmte Version altert schnell; deine Prüffälle bleiben als Maßstab nützlich. Achte bei externen Coding-Werten auf Benchmarkvariante, Agentenumgebung und Versuchszahl.
Bei größeren Änderungen lassen sich Prüfperspektiven aufteilen: Ein Reviewer untersucht Zugriffsrechte, ein anderer Datenverarbeitung oder Rückwärtskompatibilität. Eine verantwortliche Instanz führt die Befunde zusammen und entfernt Doppelmeldungen.
Das Muster ist unter anderem in Cloudflares Erfahrungsbericht zum automatisierten Code-Review beschrieben. Es lohnt sich dort, wo die zusätzlichen Prüfungen mehr finden als ein einzelner Durchgang. Für eine Textkorrektur wäre derselbe Aufbau unnötiger Aufwand.
Ein Agent kann beim Prüfen dieselbe falsche Annahme wiederholen, die seine Änderung verursacht hat. Ein frischer Kontext oder ein zweiter Reviewer kann eine zusätzliche Perspektive liefern. Forschung zu Self-Preference bei Sprachmodell-Bewertern ist dafür ein Hinweis, aber kein allgemeiner Beweis über Code-Reviews.
Gib dem Reviewer den Auftrag und die Änderung, nicht nur die Erfolgsmeldung des erzeugenden Agenten. Verlange einen konkreten Fehlerfall mit betroffener Stelle und erwarteter Folge. Eine pauschale Aufforderung, möglichst viele Probleme zu finden, lädt zu Fehlalarmen ein.
Tests und Review ergänzen sich
Ein Test prüft ausführbares Verhalten. Ein Review kann zusätzlich entdecken, dass die falsche Anforderung umgesetzt wurde oder ein wichtiger Fall fehlt. Die CriticGPT-Arbeit von OpenAI zeigt an ihrem untersuchten Aufbau, dass trainierte KI-Kritiker beim Finden von Codefehlern helfen können. Das belegt keine allgemeine Überlegenheit eines beliebigen zweiten Modells.
Für einen Bugfix ist ein Test wertvoll, der am alten Verhalten scheitert und am korrigierten besteht. Ein Test, der nur die neue Implementierung nacherzählt, liefert wenig zusätzliche Sicherheit. Bei Oberflächen gehört die Bedienung der laufenden Anwendung zur Prüfung.
Adversarialer Review als strukturierter Befund (schematisch)json
{"annahme":"Code ist kaputt, bis das Gegenteil bewiesen ist","befunde":[{"klasse":"auth/mandanten-isolation","schwere":"hoch","konfidenz":0.8,"datei":"src/api/orders.ts","zeile":88,"problem":"Tenant-ID aus Request-Body statt aus Session"},{"klasse":"datenverlust/idempotenz","schwere":"mittel","konfidenz":0.6,"datei":"src/jobs/cleanup.ts","zeile":23,"problem":"Retry ohne Idempotenz-Schlüssel kann doppelt löschen"}]}
Befunde nachstellen, bevor du sie übernimmst
Auch ein KI-Reviewer kann Fehler erfinden. Lass dir für jeden wichtigen Befund zeigen, unter welchen Bedingungen er auftritt. Prüfe ihn am Code, durch einen gezielten Test oder in der Anwendung.
Die CriticGPT-Forschung beschreibt ebenfalls Fehlalarme. Zusätzliche Reviews sind deshalb kein automatisches Freigabesiegel. Ein gemeldeter Verdacht wird erst durch die konkrete Prüfung zu einem belastbaren Befund.
Teile umfangreiche Vorhaben in Änderungen, die jeweils ein verständliches Verhalten liefern. Eine Schemaänderung, eine neue API und eine neue Oberfläche lassen sich besser beurteilen, wenn ihre Abhängigkeiten ausdrücklich feststehen.
Lass den Agenten Ergebnisse tatsächlich ausführen und Fehler beheben. Prüfe beim Abschluss den gesamten Diff: Sind unbeabsichtigte Änderungen dabei? Wurden Prüfungen abgeschwächt? Stimmen Dokumentation und Verhalten überein?
MerksatzEine Änderung ist fertig, wenn das geforderte Verhalten geprüft ist – eine Erfolgsmeldung des Agenten reicht dafür nicht.
Produktivität am fertigen Ergebnis messen
Mehr erzeugter Code bedeutet nicht automatisch mehr Produktivität. Zur Arbeit gehören auch Abstimmung, Integration und Fehlerbehebung. Miss bei einem eigenen Versuch deshalb die Zeit bis zur brauchbaren Änderung einschließlich Review und Nacharbeit.
METR fand mit Werkzeugen von Anfang 2025 eine Verlangsamung erfahrener Entwickler in einem bestimmten Versuchsaufbau. Im Update vom Februar 2026 warnt die Organisation, dass die Folgeuntersuchung wegen Auswahleffekten keinen verlässlichen aktuellen Produktivitätswert liefert. Die frühere Zahl lässt sich deshalb nicht als Urteil über heutige Coding-Agenten verwenden.
Ein Coding-Agent braucht für einen lokalen Bugfix gewöhnlich keinen Schreibzugriff auf Produktionsdaten. Trenne Arbeitsumgebung und Produktion, begrenze Zugangsdaten und halte Änderungen über Versionskontrolle nachvollziehbar.
Fremde Dateien und Werkzeugausgaben können Prompt-InjectionAngriff, bei dem fremde Anweisungen über Inhalte eingeschleust werden, die ein Modell nur verarbeiten soll (Website, Dokument, Werkzeug-Ergebnis) – der Agent führt sie aus, als kämen sie vom Nutzer. Anders als beim Jailbreak greift hier ein Dritter an, nicht die nutzende Person.Mehr im Wissen → enthalten. Entscheidend sind technisch durchgesetzte Grenzen: Welche Dateien, Dienste und Aktionen sind erreichbar? Eine Anweisung im Prompt allein schützt keine Datenbank vor einem erlaubten, aber falschen Aufruf.
Den Agenten eng einhegen (schematisch)bash
# Positivliste statt allgemeiner Shell — nur explizit erlaubte Befehle
agent run --aufgabe "Flaky-Test stabilisieren" \
--erlaube "pnpm test, git add, git commit" \
--verbiete "rm -rf, docker volume rm, DROP TABLE" \
--auto-commit # jede Dateiänderung über Git rückgängig-fähig