KI-Engineering · Praxisleitfaden

Wählen Sie Agentenarbeit danach aus, wie klar sich das Ergebnis prüfen lässt

Coding-Agenten entwickeln sich von Vorschlägen zu zugewiesener Arbeit. Die nützliche Frage für Engineering-Leads lautet nicht, wie viel Arbeit ein Agent versuchen kann, sondern ob sich das Ergebnis anhand der Anforderung prüfen lässt, bevor es die Nutzer erreicht.

Von Nythrex-Team5. November 20264 Min. Lesezeit

Softwareentwickler bei der Arbeit. — daudi_mukiibi · CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0/) · https://commons.wikimedia.org/wiki/File%3ASoftware_developer_at_work_02.jpg

Ein Backlog-Ticket kann klein wirken und trotzdem ein schlechter Kandidat für autonome Arbeit sein. „Den Account-Ablauf aktualisieren“ kann mehrere Services berühren, von unausgesprochenen Produktregeln abhängen und keinen Test haben, der beweist, dass das Verhalten stimmt. Ein enger Fehlerbericht mit reproduzierbarem Fall lässt sich oft deutlich sicherer übergeben, auch wenn die Codeänderung größer ist.

Dieser Unterschied wird wichtiger, je mehr delegiert wird. Der GitHub-Octoverse-Bericht vom 28. Oktober 2026 sagt, dass im September mehr als 40 % der Pull Requests auf GitHub mit dem ersten Entwurf eines Agenten begannen, verglichen mit 17 % im März. Wachsendes Volumen sagt einem Team aber nicht, welche Aufgaben es delegieren soll. Neuere Benchmark-Forschung bietet eine nützlichere Linse: die Struktur der Aufgabe und die verfügbaren Nachweise für ihre Prüfung zu betrachten.

Anteil der GitHub-Pull-Requests, die im September 2026 mit dem ersten Entwurf eines Agenten begannen, nach 17 % im März. GitHub Octoverse, Oktober 2026.: >40 %
Anteil der von Agenten gestarteten Pull Requests, die mehrere Dateien ändern, gegenüber 79 % der Pull Requests ohne erkannte Agentenbeteiligung. GitHub Octoverse, Oktober 2026.: 87 %
Berichteter AUC-Wert für die Vorhersage der Aufgabenschwierigkeit aus statischen Aufgabenmerkmalen in der Studie CoderForge-Preview. Al-Haque und Johnson, 2026; das ist ein Studienergebnis, kein Wert für ein bestimmtes Team oder einen bestimmten Agenten.: 0,863

Die Form einer Aufgabe ist ein nützliches Warnsignal

In einem ESEM-Paper vom Oktober 2026 untersuchten die Forschenden Ebtesam Al-Haque und Brittany Johnson Verläufe von Coding-Agenten über 51.000 Aufgaben zur Behebung von Software-Issues. Sie berichten, dass strukturelle Merkmale, vor allem die Fragmentierung des Patches und die Größe des Repositorys, die Schwierigkeit der Aufgabe in ihrem Datensatz vorhersagen. Der Befund ist keine allgemeingültige Auswahlregel: Er misst Zusammenhänge in einer Benchmark-Sammlung, nicht garantierten Erfolg im privaten Backlog eines Teams.

Ein weiterer Benchmark vom Oktober 2026, AgentSWE, testet Agenten, die andere Agenten bauen, bearbeiten und optimieren. Die Autoren berichten von wiederkehrenden Lücken zwischen Entwicklungsfällen und zurückgehaltenen Fällen sowie von Ergebnissen, die vollständig aussahen, aber bei der Ausführung scheiterten. Das ist ein spezialisierter Benchmark und belegt daher keine Fehlerquoten für gewöhnliche Feature-Arbeit. Er stützt aber einen praktischen Punkt: Ein sauber aussehender Patch oder eine selbstbewusste Erfolgsmeldung ist ein schwacher Nachweis, solange keine Prüfung die Anforderung tatsächlich ausübt.

Wählen Sie delegierte Arbeit nach der Qualität der Nachweise, die Sie prüfen können, nicht danach, wie klein das Ticket klingt.

Redaktionelles Fazit auf Grundlage von Al-Haque und Johnson (2026) sowie Wang et al. (2026).

Der Prüfweg gehört in die Schätzung

Wenn eine Aufgabe Module überschreitet, von impliziten Regeln abhängt oder nur wenige einfache Beispiele hat, wird das Review schwieriger. Der Agent erzeugt womöglich mehr Code in mehr Dateien, wie die GitHub-Zahlen nahelegen, während die Ingenieurin oder der Ingenieur trotzdem die Absicht rekonstruieren und Prüfungen entwerfen muss. Das ist ein Problem der Arbeitsverteilung: Die scheinbar gesparte Programmierzeit kann von Klärung, Testentwurf und der Nachverfolgung des Verhaltens im Repository aufgezehrt werden.

Das legt eine Delegationsgrenze nahe. Beginnen Sie mit Arbeit, deren erwartetes Verhalten sich formulieren, ausführen und prüfen lässt, ohne auf undokumentiertes Urteilsvermögen angewiesen zu sein: ein reproduzierbarer Fehler, eine abgegrenzte Migration mit Kompatibilitätsprüfungen oder Tests für ein vereinbartes Verhalten. Aufgaben mit unklaren Produktentscheidungen, weitreichenden Architektur-Abwägungen oder folgenreichen Änderungen sollten unter enger menschlicher Führung bleiben, bis das Team sie spezifizieren und verifizieren kann. Das sind Ausgangskategorien, keine Garantien.

Nutzen Sie einen Delegations-Check, der bei der Verifikation beginnt

Bevor Sie einem Agenten in diesem Monat eine Aufgabe zuweisen, bitten Sie die verantwortliche Ingenieurin oder den verantwortlichen Ingenieur, vier Dinge aufzuschreiben: das zu ändernde Verhalten, die Fälle, die weiterhin funktionieren müssen, die voraussichtlich betroffenen Bereiche des Repositorys und die Nachweise, die als „fertig“ gelten. Ordnen Sie die Aufgabe dann informell ein. Eine klare Anforderung plus starke ausführbare Prüfungen ist ein guter Pilot. Eine fragmentierte Änderung in einer großen oder schlecht verstandenen Codebasis braucht einen Zerlegungsschritt durch Menschen. Kann niemand sagen, was das Ergebnis widerlegen würde, halten Sie die Arbeit explorativ und lassen Sie eine Ingenieurin oder einen Ingenieur entscheiden.

Vergleichen Sie in einem kleinen Pilot ähnliche Aufgaben mit und ohne Agentenhilfe. Erfassen Sie die Ingenieurzeit für Klärung, Kontextvorbereitung, Verhaltensprüfung, Überarbeitung des Patches und dessen Pflege nach dem Merge. Werten Sie Fehlschläge als Hinweis auf die Aufgabendefinition oder die Testgrenzen aus, nicht nur auf das Modell. Zählen Sie eine Aufgabe nicht als erledigt, weil ein Agent einen Pull Request geöffnet oder Erfolg gemeldet hat; zählen Sie sie, wenn die üblichen Abnahmeprüfungen des Teams bestehen und die verantwortliche Reviewerin oder der verantwortliche Reviewer bestätigt, dass die Änderung die Anforderung erfüllt.

Quellen

Häufige Fragen

Wie sollten Engineering-Teams Aufgaben für Coding-Agenten auswählen?

Beginnen Sie mit Aufgaben, die ein klares erwartetes Verhalten haben und Prüfungen, die zeigen können, ob die Änderung es erfüllt. Behandeln Sie breite, fragmentierte oder schlecht spezifizierte Arbeit als etwas, das menschliche Zerlegung und engere Führung braucht.

Beweist eine bestandene Testsuite, dass die Änderung eines Agenten korrekt ist?

Sie ist ein Nachweis, aber nur für die Fälle, die die Suite abdeckt. Die AgentSWE-Studie berichtet in ihrem Benchmark von Lücken zwischen Entwicklungs- und zurückgehaltenen Fällen; Teams sollten daher auch Anforderungen und relevante Randfälle prüfen.

Was sollten Teams in einem Agenten-Pilot messen?

Erfassen Sie den gesamten Ingenieuraufwand rund um jede Änderung: Klärung, Kontextvorbereitung, Review, Überarbeitungen und spätere Pflege, zusammen mit der Frage, ob die Abnahmeprüfungen bestehen. Ein Pull Request oder eine Erfolgsmeldung des Agenten allein belegt nicht, dass die Arbeit erledigt ist.

Schluss mit Raten.
Fangen Sie an zu sehen.

Konto erstellen Demo buchen

Ohne Karte und ohne Abo: Bezahlpläne sind noch nicht gestartet.