Sie starten drei Coding-Agents mit drei Aufgaben und verbringen die nächsten zwanzig Minuten damit, durch Terminal-Tabs zu springen, um eine einzige Frage zu beantworten: Welcher braucht mich gerade jetzt? Einer läuft noch. Einer wartet auf ein y/n, das Sie nie gesehen haben. Einer ist vor einer Stunde grün beendet worden und hat still und leise das Falsche gebaut. Nichts hat Ihnen irgendetwas davon mitgeteilt. Sie mussten selbst nachsehen.
Genau diese Lücke soll Coding-Agent-Observability schließen. Observability – entlehnt aus dem Systems Engineering – ist die Fähigkeit, aus den Signalen, die ein laufender Prozess aussendet, zu verstehen, was er tut, ohne sich direkt an ihn anzuhängen (OpenTelemetry hat eine gute Einführung). Für Coding-Agents gilt folgender Standard: Sie sollten aus einer geteilten Ansicht heraus beantworten können, „was jeder Agent tut, was fehlgeschlagen ist und was einen Menschen braucht“ – und nicht, indem Sie eine Session mitlesen. Die meisten Setups können das nicht. Sie haben irgendwo einen Status und irgendwo ein Log und nennen das Observability. Das ist es nicht.
Dieser Artikel geht die drei Signale durch, die ein Coding-Agent tatsächlich aussendet, welche Fehlersignale es wert sind, einen Alarm daran zu hängen, und wo eine geteilte Aufgabenebene wie Sharkly rohe Ausgaben in etwas verwandelt, auf das Sie reagieren können. Sharkly sitzt über den Agents, die Sie bereits betreiben; Sie haben bereits Coding-Agents, und hier geht es darum, ihre Arbeit lesbar zu machen, wenn es mehr als einen gibt.
Status, Logs und Fehlersignale sind drei verschiedene Dinge
Diese drei Wörter werden oft synonym verwendet, und diese Verwechslung ist die Wurzel der meisten schlechten Monitoring-Setups. Sie beantworten unterschiedliche Fragen.
Status ist der zusammenfassende Zustand eines Runs. Running, wartend auf Eingabe, fertig oder fehlgeschlagen. Es ist ein einzelnes Feld, billig auszulesen, und es sagt Ihnen, wo ein Run steht, nicht, was er getan hat. Ein Status ist keine Observability; er ist die kleinste Tatsache über einen Run.
Logs sind die rohe Ausführungsspur. Jeder Tool-Aufruf, jede Dateibearbeitung und jede Modellantwort, in Reihenfolge. Logs sagen Ihnen, was passiert ist, nachdem Sie bereits wissen, dass etwas schiefgelaufen ist. Sie sind unverzichtbar für eine Post-Mortem-Analyse und nutzlos als Live-Signal, denn niemand beobachtet fünf gleichzeitig scrollende Logs. Ein Log ist kein Signal, solange nicht etwas Bedeutung daraus extrahiert.
Fehlersignale sind abgeleitete Alarme. Sie sind die konkreten Bedingungen, für die es sich lohnt, Sie zu unterbrechen: ein Agent hängt fest, ein Run ist grün in die falsche Richtung gelaufen, ein Budget ist mitten in der Aufgabe ausgegangen. Ein Fehlersignal ist das, was Sie tatsächlich wollen, und es ist die Ebene, die fast jedes selbstgebaute Setup überspringt – denn sie abzuleiten bedeutet, Logs zu Events zu verarbeiten, statt sie nur zu speichern.
Die Falle ist, bei den ersten beiden stehenzubleiben. Status plus Logs fühlen sich wie Observability an, weil Sie einen Zustand und eine Aufzeichnung haben. Aber die einzige Frage, die skaliert – „Welcher meiner Agents braucht mich?“ – lebt vollständig in der dritten Ebene.
Die Fehlersignale, die wirklich zählen
Web-Service-Observability achtet auf Abstürze und Latenz. Coding-Agents scheitern anders, und die Fehler, die Sie einen ganzen Nachmittag kosten, sind selten die, die sich als roter Status zeigen. Diese Signale lohnt es sich abzuleiten.
| Signal | Was es bedeutet | Warum Status und Logs es übersehen |
|---|---|---|
| Stiller Stillstand | Agent wartet auf eine Eingabeaufforderung oder ein fehlendes Secret und produziert keine Ausgabe | Der Status liest weiterhin „running“; nichts meldet sich |
| Grün, aber falsch | Run wurde erfolgreich beendet und hat das Falsche getan | Status ist „done“; nur das Lesen des Diffs deckt es auf |
| Übersprungene Verifikation | Als fertig gemeldet, ohne Typecheck, Tests oder Build ausgeführt zu haben | Die Logs enthalten die Auslassung, aber niemand liest ein erfolgreiches Log |
| Budget-Erschöpfung | Modell-Kontingent oder Ausgabenlimit mitten in einer Aufgabe erreicht | Der Fehler zeigt sich als abgeschnittene Antwort, nicht als Alarm |
| Latenter Konflikt | Zwei Agents haben dieselben Dateien in getrennten Worktrees bearbeitet | Beide Runs sind „done“; die Kollision wartet beim Merge |
| Thrash | Agent bearbeitet, verwirft und bearbeitet dieselbe Datei in einer Schleife erneut | Jeder einzelne Schritt sieht im Log in Ordnung aus |
Das Muster bei allen sechs: Der Fehler ist auf der Statusebene unsichtbar und auf der Logebene begraben. „Grün, aber falsch“ ist derjenige, den die Leute am meisten unterschätzen. Ein Coding-Agent, der selbstsicher die falsche Aufgabe erledigt, sieht identisch aus wie einer, der sie perfekt getroffen hat – bis das Review mit Evidence auf Aufgabenebene es aufdeckt. Observability, die nur Exit-Codes meldet, wird diesen Fehler als Erfolg melden.
Zwei davon sind struktureller und nicht verhaltensbedingter Natur. Latente Konflikte sind der Grund, warum parallele Arbeit im selben Repo isolierte Worktrees pro Aufgabe braucht, damit Dateiüberschneidungen vor dem Merge und nicht währenddessen auftauchen. Budget-Erschöpfung ist der Grund, warum die Ausgabenverfolgung über Agents hinweg in dieselbe Ansicht wie der Status gehört; ein Run, der still aufgehört hat, weil das Kontingent aufgebraucht war, ist ein Fehlersignal und keine abgeschlossene Aufgabe.
Wie viel Observability Sie brauchen – je nach Teamgröße
Sie brauchen nicht alle sechs Signale vom ersten Tag an. Die richtige Menge an Instrumentierung skaliert damit, wie viele Agents laufen und wie viele Personen sie sehen müssen.
| Setup | Was zu instrumentieren ist | Wo es bricht |
|---|---|---|
| Ein Agent, eine Aufgabe | Nur Status; das Log lesen, wenn es fehlschlägt | Nichts – bis Sie einen zweiten Agent starten |
| Mehrere Solo-Agents | Status pro Run plus Stillstands- und Grün-aber-falsch-Signale | Sie schließen den Zustand aus der Stille und verpassen Stillstände |
| Kleines Team, geteilte Repos | Alle sechs Signale plus Review-Status in einer geteilten Ansicht | Ihr Monitoring läuft auf einem Laptop, den sonst niemand sehen kann |
| Größeres Team, viele Repos | Das Obige plus Ownership pro Run, Budget und Audit-Trail | Niemand kann eine Woche später beantworten, „wer was ausgeführt hat“ |
Die ehrliche Einschätzung: Ein Solo-Entwickler, der einen Agent an unabhängigen Aufgaben laufen lässt, hat die gesamte Observability, die er braucht, in einem einzigen Terminal. Die Gleichung ändert sich in dem Moment, in dem die Agents Ihre Bildschirme zahlenmäßig übersteigen, die Arbeit auf Maschinen läuft, an denen Sie nicht sitzen, oder eine andere Person dasselbe Board sehen muss. Ab dieser Grenze reichen ein Statusfeld und ein Log-Verzeichnis nicht mehr aus.
Wo rohe Logs und eine einzelne Runtime ausreichen
Geben Sie den eingebauten Tools ihre beste Version, denn für einen Großteil der Arbeit gewinnen sie. Claude Code und Codex halten beide eine lesbare Session-Spur, und für einen einzelnen Agent an einer einzelnen Aufgabe ist diese Spur Ihre Observability. Sie haben ihn gestartet, Sie beobachten ihn, Sie lesen das Log, wenn er aufhört. Eine Management-Ebene dort hinzuzufügen, ist reiner Overhead.
Nutzen Sie die eigene Ausgabe der Runtime, wenn Sie ein oder zwei Agents an unabhängigen Aufgaben laufen lassen, die nie an jemand anderen übergeben werden. Greifen Sie zu einer geteilten Observability-Ebene, wenn die Runs Ihre Aufmerksamkeit zahlenmäßig übersteigen, wenn sie irgendwo laufen, wo Sie nicht mitlesen können, oder wenn das Review zu einer Team-Aktivität werden muss statt zu einer privaten. Der letzte Fall ist der stille Killer: Fünf Agents, die parallel fertig werden, sind kein Gewinn, wenn das Review ihrer Diffs sich wieder in eine Warteschlange für einen einzigen Menschen serialisiert. Die Agents wurden schneller; Sie wurden langsamer. Auch das ist ein Observability-Problem, und keine einzelne Runtime löst es, weil das entscheidende Signal – „dieser Run ist fertig und wartet auf Ihr Review“ – über die Agents hinweg lebt, nicht innerhalb eines einzelnen.
Observability, wenn Ergebnisse zur Task zurückkehren
Eine Aufgabenebene ändert die Einheit der Observability von „einem Prozess in einem Pane“ zu „einer Task mit einem Zustand“. Das ist der Wandel, um den Sharkly herum gebaut ist, und er bildet alle drei Signale auf einmal ab.
Jeder Agent-Run hängt an einer Task. Status, Fortschritt, Blocker und Ergebnisse kehren zur Timeline dieser Task zurück, statt in einem Log zu leben, das nur Sie sehen können. Fehlersignale tauchen an einer Stelle auf: Die Runs, die einen Menschen brauchen, landen im Inbox, sodass die Frage nicht mehr lautet „ist irgendetwas fertig geworden?“, sondern „hier ist, was meine Entscheidung braucht.“ Agents recherchieren, führen aus, testen und berichten; Menschen setzen die Richtung, erteilen die Befugnis und akzeptieren das Ergebnis. Die Automatisierung endet dort, wo Team-Urteilsvermögen gefordert ist.
Die Grenze ist wichtig, denn es ist leicht, sie falsch anzunehmen. Sharkly führt den Agent nicht aus und schreibt den Code nicht. Claude Code, Codex und die anderen Runtimes, die Sie bereits nutzen, übernehmen weiterhin die Ausführung. Sharkly fügt die geteilte Task-, Computer-, Kontext- und Review-Ebene um sie herum hinzu, sodass Kontext, Fortschritt, Blocker, Ergebnisse und menschliches Review von der Anfrage bis zum Release sichtbar bleiben. Für das vollständigere Bild davon, was dieses geteilte Board zeigen sollte, siehe was ein KI-Coding-Agent-Dashboard wirklich braucht, und für den Live-Monitoring-Aspekt wie man parallel laufende Coding-Agents überwacht.
Wenn Sie weiterhin mehrere Coding-Agents nutzen möchten, statt sich auf ein Ökosystem festzulegen, ist genau diese geteilte, signalorientierte Ansicht das Problem, um das Sharkly herum konzipiert ist. Sie können Ihre bestehenden Coding-Agents über Sharkly laufen lassen und jede Runtime behalten, die Sie bereits nutzen.
FAQ
Ist Coding-Agent-Observability dasselbe wie Logging? Nein. Logging speichert, was passiert ist. Observability bedeutet, beantworten zu können, was jeder Agent tut, was fehlgeschlagen ist und was Sie braucht, ohne diese Logs einzeln lesen zu müssen. Logs sind eine Eingabe für Observability, nicht ihre Gesamtheit.
Welches ist das wichtigste Fehlersignal, das man zuerst instrumentieren sollte? Der stille Stillstand. Ein Agent, der „running“ anzeigt, während er ewig auf eine Eingabe wartet, die Sie nie gesehen haben, ist die häufigste Art, wie parallele Arbeit still stirbt. Sorgen Sie dafür, dass blockierte Runs sich melden, bevor Sie sich an etwas Ausgefalleneres wagen.
Kann ich das aus der eingebauten Ausgabe meines Coding-Agents bekommen? Für einen Agent: ja. Die eigene Session-Spur der Runtime reicht aus. Die eingebaute Ausgabe hat keine agentenübergreifende Ansicht, kann Ihnen also nicht sagen, welcher von fünf Runs Sie braucht – und genau das ist die Frage, die auftaucht, sobald Sie über einen hinaus skalieren.
