Lange Zeit lautete die Frage bei Coding-Agenten, ob sie die Arbeit tatsächlich erledigen können. Diese Frage klärt sich still und leise. Bei gut abgegrenzten Aufgaben, mit dem Repository vor sich und der Möglichkeit, die Tests auszuführen, liefern gute Agenten echte Änderungen, die den Review bestehen. Und in dem Moment, in dem Sie darauf vertrauen, stoßen Sie auf ein Problem, vor dem Sie niemand gewarnt hat: Ihnen fällt nicht genug Arbeit ein, um sie beschäftigt zu halten.
Die Ausführung ist nicht mehr der Engpass
Bei einem Softwareprodukt gibt es immer unendlich viel zu tun. Das Backlog ist nie leer; die Liste der Dinge, die besser sein könnten, ist endlos. Deshalb klingt es seltsam zu behaupten, einem Team könnte die Arbeit für einen Agenten ausgehen. Aber „es gibt unendlich viel Arbeit" und „es gibt Arbeit in einer Form, die ein Agent aufnehmen und abschließen kann" sind zwei sehr unterschiedliche Aussagen, und in der Lücke dazwischen bleiben Teams stecken.
Ein Agent kann eine klar definierte Aufgabe in Minuten ausführen. Diese klare Aufgabe zu formulieren – mit ausreichendem Kontext, dem richtigen Umfang und einer Definition von „fertig" – kostet eine Person nach wie vor dieselben zwanzig Minuten wie immer. Solange die Ausführung der langsame Teil war, war das kein Problem; die Spezifikation machte fünf Prozent des Aufwands aus, die restlichen fünfundneunzig Prozent waren Ausführung. Sinken die Ausführungskosten gegen null, kehrt sich dieses Verhältnis um. Jetzt ist die Spezifikation die teure Hälfte, und ein Team, das einen Agenten auslasten konnte, stellt fest, dass es keine drei auslasten kann.
Der Engpass ist stromaufwärts gewandert, zu Ihnen
Das ist das Problem der Aufgabenversorgung: Die Beschränkung agentengestützter Entwicklung liegt nicht mehr in der Fähigkeit des Agenten, Dinge zu tun, sondern in der Fähigkeit der Organisation, gut formulierte Dinge zu produzieren, die zu tun sind. Und diese Beschränkung trifft ausgerechnet die knappsten Personen, die Sie haben – diejenigen mit genug Kontext, um zu sagen, was als Nächstes geschehen sollte und warum.
Sie spüren das als eine eigenartige Art von Druck. Der Agent ist schnell und zuverlässig, sodass sich die Warteschlange schneller leert, als Sie sie auffüllen können, und das Auffüllen ist genau der Teil, der Urteilsvermögen, Produktgespür und Wissen darüber erfordert, wohin sich das System entwickelt. Der Engpass ist nicht verschwunden. Er ist von der Tastatur in den Kopf der Person gewandert, die weiß, was die Tastatur eigentlich tun sollte.
Der Agent muss bei der Aufgabenversorgung helfen
Der einzige Weg, ein Versorgungsproblem zu überwinden, besteht darin, das Angebot zu erhöhen – und die Person, die Aufgaben definiert, skaliert nicht. Also muss der Agent, der die Arbeit ausführt, damit beginnen, sie auch mit zu generieren – nicht indem er sinnlose Beschäftigung erfindet, sondern indem er Signale, die bereits durch Ihre Systeme fließen, in konkrete, sofort ausführbare Aufgaben verwandelt.
TaskGoblin tut heute bereits eine Version davon, an zwei Stellen, die Sie vielleicht nicht als „Aufgabengenerierung" betrachtet haben:
- Review-Befunde werden zu Arbeit. Jeder Merge Request, den der Agent überprüft, erzeugt konkrete, genau verortete Befunde – diese Funktion hat einen Korrektheitsfehler, dieser Pfad ist nicht abgedeckt, das riecht nach einem Sicherheitsproblem. Jeder dieser Befunde ist faktisch eine vorgeschriebene Aufgabe mit einer Definition von „fertig". Antworten Sie mit
@taskgoblin fix, und der Befund wird zu einer Änderung. Niemand musste sich hinsetzen und dieses Ticket schreiben; der Review hat es geliefert. - Dauerhafte Schleifen werden zu Arbeit. Eine Loop ist ein Aufgabengenerator, der nach der Uhr läuft: „Suche jeden Werktag nach gemergter Arbeit, deren Issues noch offen sind, und schließe sie", „Achte darauf, ob eine CI zu lange rot bleibt." Die Anweisung wird einmal geschrieben und produziert danach fortlaufend konkrete Arbeit – oder erzeugt korrekterweise nichts, wenn es nichts zu tun gibt – ohne dass jemand die Warteschlange von Hand nachfüllt.
In beiden Fällen wartet der Agent nicht darauf, dass man ihm sagt, was zu tun ist. Er liest den Zustand des Systems und schlägt das konkrete, abschließbare Nächste vor.
Warum Kontext das ganze Spiel ist
Der Grund, warum vom Agenten vorgeschlagene Arbeit meist wenig wertvoll ist, liegt nicht daran, dass das Modell nicht klug genug wäre. Es liegt daran, dass der Agent nicht weiß, was Ihnen wichtig ist. Ohne Einblick in die Produktabsicht schlägt ein Agent bereitwillig die zwanzig Refactorings vor, die er sehen kann, aber keine der einen Änderung, die das Geschäft tatsächlich voranbringt – weil der Code ihm sagt, was möglich ist, nicht was wichtig ist.
Deshalb sind die nützlichen Oberflächen für die Aufgabengenerierung genau die, die an echter Absicht verankert sind. Ein Review-Befund ist wichtig, weil er auf einer Änderung sitzt, die jemand bewusst vorgenommen hat. Eine geplante Schleife ist wichtig, weil ein Mensch entschieden hat, dass es sich lohnt, Issues und Merges täglich synchron zu halten. Der Kontext, der eine vorgeschlagene Aufgabe lohnenswert macht, steckt nicht allein im Code; er steckt in den Issues, den Diskussionen und den Entscheidungen rund um den Code – und ein Agent, der in diesen Systemen lebt, wie unserer, kann diese Absicht lesen, statt sie zu erraten.
Wo der Wert jetzt liegt
Es lohnt sich, klar zu sagen, wohin das den Vorteil verschiebt. Während sich die Modelle darin annähern, fast alles ausführen zu können, fließt der unverhältnismäßige Wert nicht mehr zu dem, der den klügsten Agenten hat, sondern zu dem, der gute Agenten fortlaufend mit Arbeit versorgen kann, die zählt. Der entscheidende Zug ist kein raffinierteres Modell. Es ist, die Schleife zwischen der über Ihre Tools verstreuten Absicht und dem Agenten, der danach handeln kann, zu schließen – damit „Was sollten wir als Nächstes tun" aufhört, ein Engpass zu sein, der persönlich Sie sind.
Das ist das Problem, gegen das wir tatsächlich anbauen. Den Agenten dazu zu bringen, programmieren zu können, war die erste Hälfte. Sicherzustellen, dass er immer weiß, was es wert ist, getan zu werden – und Ihren Kontext in die nächste konkrete Aufgabe verwandeln kann, ohne auf Sie zu warten –, ist die Hälfte, die entscheidet, wie viel die erste wert war.
