„Es gibt keine dummen Fragen" ist einer jener freundlichen Sätze, die wir uns gegenseitig sagen, und für Menschen stimmt das auch. Ein neues Teammitglied, das fragt, wo der Abrechnungscode liegt, lernt gerade die Struktur des Systems kennen; die Frage schafft gemeinsamen Kontext, und die Antwort dauert eine Minute. Ein autonomer Agent ist jedoch kein neues Teammitglied, das sich erst zurechtfinden muss. Er kann das gesamte Repository in der Zeit lesen, die Sie brauchen, um diesen Satz zu lesen. Für einen Agenten gibt es tatsächlich dumme Fragen – und die dümmsten sind die, die er durch bloßes Nachsehen selbst hätte beantworten können.
Was für einen Agenten eine dumme Frage ist
Eine dumme Frage ist eine, deren Antwort bereits in der Codebasis steckt. „Wo liegt der Code, der das hier verarbeitet?" „Wie lautet der Build-Befehl?" „Gibt es dafür schon ein Muster?" Ein Mensch könnte all das an seinem ersten Arbeitstag durchaus fragen. Ein Agent, der das tut, signalisiert damit, dass er sich den Kontext lieber servieren lässt, als ihn selbst zu suchen – obwohl genau das Suchen die eine Sache ist, die er Ihnen gegenüber zweifelsfrei voraushat.
Das Erkennungsmerkmal: Die Antwort ist auffindbar. Wenn der Agent sie durch das Lesen einer Datei, ein Grep über den Verzeichnisbaum, einen Blick in die CI-Konfiguration oder das Lesen der letzten Commits in diesem Bereich hätte finden können, dann ist es keine Vorsicht, Sie danach zu fragen. Es ist, eine Arbeit an Sie zurückzugeben, die der Agent selbst hätte erledigen sollen.
Ein asynchroner Agent bezahlt Fragen in ganzen Tagen
Für einen Chat-Assistenten, der neben Ihnen sitzt, ist eine Frage billig: Sie sind da, Sie antworten, er macht weiter. TaskGoblin sitzt nicht neben Ihnen. Er wird durch eine Issue-Zuweisung, eine Erwähnung oder einen neuen Merge Request ausgelöst und erledigt seine Arbeit in einer Sandbox, während Sie in einem Meeting sitzen, schlafen oder sich in einer anderen Zeitzone befinden. In dieser Welt ist eine Frage keine Pause – sie ist ein vollständiger Stillstand.
Ein Agent, der fragt „Soll ich das in services/ oder lib/ ablegen?" und dann wartet, hat aus einem Lauf, der in Minuten hätte fertig sein können, einen gemacht, der erst endet, wenn Sie zufällig wieder in den Thread schauen. Eine einzige Ja-Nein-Frage, im falschen Moment gestellt, kann für dreißig Sekunden tatsächliches Nachdenken einen ganzen Tag Realzeit kosten. Genau das asynchrone Modell ohne Menschen im Regelkreis, das den Agenten wertvoll macht, ist es auch, das eine vermeidbare Frage so teuer werden lässt.
Überspezifizieren ist derselbe Fehler, nur früher begangen
Die naheliegende Verteidigung gegen einen fragefreudigen Agenten besteht darin, alles im Voraus zu beantworten: die Verzeichnisstruktur in den Prompt kopieren, die Befehle auflisten, die Namenskonventionen ausbuchstabieren, einen Codeausschnitt des zu befolgenden Musters einfügen. Das fühlt sich verantwortungsbewusst an. Es ist derselbe Fehler in Verkleidung.
Handgeschriebener Kontext veraltet in dem Moment, in dem sich der Code weiterentwickelt. Wenn Sie den Prompt vorab mit „Repositories legen wir in app/Repositories ab" füllen, wetten Sie darauf, dass das noch immer stimmt, dass Sie jedes relevante Detail berücksichtigt haben und dass nichts davon den Agenten in Richtung des gestrigen Ansatzes verzerrt. Meist geht mindestens eine dieser Wetten nicht auf, und der Agent baut nun selbstbewusst auf einer Tatsache auf, die Sie ihm geliefert haben, statt auf der Wahrheit, die er selbst hätte lesen können. Sie haben die eigentliche Arbeit – den aktuellen Zustand des Systems zu verstehen – durch Arbeit über diese Arbeit ersetzt und dabei das Ergebnis verschlechtert.
Ein guter Agent beantwortet seine eigenen Fragen
Der Ausweg ist kein besserer Prompt. Es ist ein Agent, der Ihre Anweisung als Ziel behandelt und selbst losgeht, um die Fakten zu ermitteln.
Deshalb beginnt ein TaskGoblin-Lauf damit, das gesamte Repository in seine Sandbox zu klonen – nicht nur den zu prüfenden Diff, sondern den kompletten Arbeitsbaum –, sodass die Fakten direkt vor Ort zum Lesen bereitliegen. Er liest die Dateien, die Historie des Bereichs, den er ändert, das Issue, das ihn ausgelöst hat, samt der zugehörigen Diskussion, sowie das Übergabegedächtnis aus früheren Läufen desselben Threads. Er kann die eigenen Befehle des Projekts in der Sandbox ausführen, um zu sehen, was tatsächlich baut und durchläuft, statt einem Build-Befehl zu vertrauen, den jemand vor sechs Wochen in einen Prompt getippt hat. Wo er den aktuellen Zustand Ihrer Werkzeuge benötigt, liest er ihn direkt über seine Integrationen aus, statt Sie zu bitten, ihn weiterzugeben.
Das Ergebnis: Der Agent gelangt zu demselben Verständnis, das ein guter Entwickler nach einer Stunde Lesen erreichen würde – nur dass er dafür Sekunden braucht und sich dabei auf den Code stützt, wie er heute ist, nicht wie ihn jemand in Erinnerung hatte.
Wann er trotzdem fragen sollte
Das bedeutet nicht, dass ein Agent niemals etwas fragen sollte. Die Fragen, die es wert sind, gestellt zu werden, sind die, die der Code wirklich nicht beantworten kann: welches von zwei akzeptablen Verhalten Sie tatsächlich wollen, ob eine riskante Migration im Umfang der Aufgabe liegt, eine Produktentscheidung, die nur in Ihrem Kopf existiert. Das sind keine dummen Fragen – es sind die Ermessensentscheidungen, die Ihnen obliegen, und ein guter Agent bringt sie klar und frühzeitig zur Sprache, statt zu raten.
Genau darin liegt der Unterschied. Ein Agent, der Sie fragt, wo der Code liegt, verschwendet das, worin er am besten ist. Ein Agent, der Sie fragt, welches von zwei Produkten Sie eigentlich bauen wollen, nutzt Ihre Zeit für die eine Sache, die nur Sie am besten können. Wir haben TaskGoblin so gebaut, dass er die erste Art von Fragen selbst beantwortet, damit bei Ihnen nur die Fragen ankommen, die Ihre Aufmerksamkeit wirklich verdienen.
