Eine Queue, die leer werden kann: T3 Codes Inbox-Sidebar

Ich lasse meine Coding-Agenten seit einer Weile über T3 Code laufen, seit kurzem trage ich auch selbst auf GitHub dazu bei. T3 Code ist kein eigenes Harness, sondern eine Oberfläche über Codex, Claude, Cursor und OpenCode. Du bringst dein eigenes Abo mit und bekommst dafür Git-Worktrees, Kontextübergabe zwischen Modellen verschiedener Anbieter, einen Diff-Viewer und einen Pull Request per Klick.

Am 22. Juli kam die v2-Sidebar in den Nightly Build, versteckt hinter einem Schalter in den Einstellungen. Sie hält offene Sessions — Threads, wie T3 Code sie nennt — wie eine Inbox. Ich habe sie eingeschaltet und mit einer Kosmetikänderung gerechnet.

Es war keine. Sie hat verändert, wie ich Arbeit fertig bekomme.

Damit klar ist, was dieser Text leisten kann: Es sind erste Eindrücke nach gut einer Woche. Eine Vorher-Nachher-Zahl habe ich nicht, weil ich meine eigene nie mitgeschrieben habe — und die erfinde ich nicht. Was geht: den Mechanismus beschreiben, die Zahlen von jemandem zitieren, der mitgezählt hat, und eine Stelle zeigen, an der dieser Workflow meiner eigenen Studie zu widersprechen scheint.

Was die Sidebar macht

Theo, der sie gebaut hat, hat es so beschrieben:

The new T3 Code sidebar is available on the latest nightly build. It's a toggle in settings. It's a VERY different workflow.

Think of it more like an inbox. When you're done with a thread, click the "settle" button and it slides to the bottom.

— @theo, 22. Juli 2026

Mehr ist es nicht. Ein Thread ist eine Aufgabe oder ein Gespräch mit einem Agenten. Ihn zu settlen heißt: als erledigt markieren. Er verschwindet aus der aktiven Liste und rutscht ans Ende der Sidebar.

Zwei Tage später schrieb Theo:

I've landed 11 PRs in the last 17 hours.

It's honestly kind of stupid that this simple UX change has improved my productivity so greatly.

— @theo, 24. Juli 2026

Der zweite Satz ist der ehrliche. Theo verkauft hier keine Erkenntnis, sondern wundert sich darüber, dass ein Button, der fertige Arbeit ausblendet, so viel bewirkt. Das deckt sich nah genug mit dem, was ich erlebt habe, dass ich glaube: da ist etwas dran.

Woran es meiner Einschätzung nach liegt

Vor der Sidebar lagen meine Threads in einer Liste, die immer nur länger wurde. Alles blieb sichtbar — fertig, halbfertig, aufgegeben, wartet auf mich. Optisch identisch, alles gleich präsent.

So eine Liste kennt keinen Zustand „erledigt". Sie hat ein oberes Ende, und alles darunter ist schlechtes Gewissen.

Eine Inbox hat einen Boden. Settlen ist eine klare Handlung, die etwas aus dem Blickfeld nimmt, und die Liste kann grundsätzlich leer werden. Das verschiebt, worauf ich hinarbeite. Ich fange seltener Neues an, nur weil Anfangen billig ist, und bringe stattdessen zu Ende, weil das die Sicht freiräumt.

Theo trifft es besser, als ich es könnte: „I've never felt so much drive to get PRs landed just so I can get them out of my sidebar."

Ich würde das trotzdem nicht als Psychologie verkaufen. Für einen Mechanismus habe ich keinen Beleg außer „so fühlt es sich an, und zwei Leute berichten dasselbe" — das ist dünn. Sicher bin ich mir bei der Verhaltensänderung, weil ich sie an dem sehe, was rausgeht: weniger offene Threads, mehr gemergte Arbeit, und deutlich seltener diese Archäologie, bei der ich einen zehn Tage alten Branch öffne und erst mal rekonstruieren muss, was ich da eigentlich vorhatte.

Für alle, die an Agenten-Werkzeugen bauen, würde ich das unterstreichen: Der Engpass war nicht das Modell. Es war eine Liste, die nie leer werden konnte. Am restlichen Stack hat sich nichts geändert.

Wo das meiner eigenen Studie zu widersprechen scheint

Und jetzt wird es interessant.

Der Contributing-Guide von T3 Code ist bei der PR-Größe ungewöhnlich deutlich:

What We Are Most Likely To Accept: Small, focused bug fixes. Small reliability fixes. Small performance improvements.

What We Are Least Likely To Accept: Large PRs. Drive-by feature work. Opinionated rewrites.

If you open a 1,000+ line PR full of new features, we will probably close it quickly and remember that you ignored the clearly written instructions.

— T3 Code CONTRIBUTING.md

Durchgesetzt wird das automatisch. Ein Size-Label bekommt jeder Pull Request anhand seiner geänderten Zeilen, damit Reviewer schon vor dem Öffnen sehen, was ein Review kosten wird.

Label	Geänderte Zeilen	Gegen meine Daten
size:XS	0–9	mitten im Risikoband
size:S	10–29	mitten im Risikoband
size:M	30–99	überspannt die 55-Zeilen-Schwelle
size:L	100–499	reicht dorthin, wo sich die Lücke schließt
size:XL	500–999	kein messbarer Unterschied
size:XXL	ab 1.000	kein messbarer Unterschied

Dagegen halte ich, was bei der Auswertung von 24.560 Pull Requests aus 447 Repositories herauskam, gematcht auf acht Kovariaten:

• Unter 55 geänderten Zeilen scheitern KI-PRs in CI etwa doppelt so oft wie vergleichbare menschliche Änderungen — Odds Ratio 2,12.
• Über 400 Zeilen ist der Unterschied verschwunden. Die größten KI-PRs schneiden sogar minimal besser ab.
• Insgesamt lösen KI-PRs 76 % mehr Lint-Verstöße aus.

Nebeneinandergelegt sieht das nach einem Widerspruch aus. Ein Repository, das für Agentenarbeit gebaut ist, schreibt genau die Größenordnung vor, in der meine Daten KI-Code am unzuverlässigsten zeigen.

Ein Widerspruch ist es trotzdem nicht, und daran hängt der eigentliche Punkt.

Ihre Regel schützt Review-Kapazität. Einen Fix über dreißig Zeilen kann ein Maintainer ordentlich lesen, einen Feature-Dump über tausend gar nicht. Meine Zahlen sagen etwas anderes: Sie beschreiben, was in CI landet, ohne dass vorher ein Mensch draufgeschaut hat. Beides stimmt. In entgegengesetzte Richtungen zeigen die beiden nur, wenn man die zweite Variable vergisst.

Die Auflösung habe ich an anderer Stelle schon aufgeschrieben, nämlich in dem Text darüber, wie ich mit Agenten arbeite: Größe ist bloß ein Stellvertreter. Gemessen wird damit in Wahrheit, wie viel menschliche Beteiligung vor CI in eine Änderung geflossen ist. Ein Zwölf-Zeilen-Diff, in einem Rutsch erzeugt und ungelesen gepusht, spielt die schlechtesten Karten im gesamten Datensatz. Derselbe Diff, absichtlich geprompted, gelesen und bewusst gepusht, verhält sich wie eine menschliche Änderung derselben Größe.

Und genau das ist der Settle-Schritt, soweit ich das sehe: ein Punkt im Ablauf, an dem du die Sache ansehen und für fertig erklären musst. Klein und gelesen ist etwas anderes als bloß klein.

Die Labels können noch etwas anderes

Ein Nebenschauplatz, weil er ein Problem löst, das ich nicht habe, viele andere aber schon.

Neben size:* vergibt T3 Code an jeden Pull Request ein vouch:*-Label für den Vertrauensstatus. Externe Beitragende bekommen vouch:unvouched, solange sie nicht ausdrücklich in einer Liste im Repo stehen. Der Guide begründet das offen: Sie nehmen derzeit keine Beiträge an und sagen das lieber, als Leute stillschweigend hinzuhalten.

Ich betreue nichts im Open Source, insofern ist das nicht mein Problem. Wer aber welches betreut und ungefragt KI-generierte Pull Requests bekommt, hat hier einen billigen Filter: ein Vertrauens-Label, automatisch beim Öffnen vergeben. Abgelehnt wird damit nichts. Die Queue sortiert sich nur von selbst in „für diesen Menschen hat jemand gebürgt" und „jemand hat ein Modell auf dein Repo gerichtet", und du kannst deine Aufmerksamkeit danach verteilen.

Noch ein Hinweis dazu: Die geschlossenen PRs, die du in dem Repo unter author:t3dotgg findest, sind Theos eigene Arbeit an seinem eigenen Projekt, keine eingehenden Beiträge. Hinter dem Volumen steckt keine Community, sondern eine Person mit einem Workflow.

Next

Was hängen bleibt:

• Eine Liste, die nur wächst, kennt kein „fertig". Eine Inbox, die leer werden kann, schon.
• Bewegt hat meinen Output eine Entscheidung in der Oberfläche, kein besseres Modell.
• Agenten-PRs klein und gelesen halten. Klein allein ist die riskante Hälfte — wenn du der einzige Mensch in der Schleife bist, schick zusätzlich einen Review-Bot auf den Pull Request.
• Lies selbst bis zu hundert Zeilen Code am Tag. Das findet Dinge, und es hält dich im Stoff.
• Wer eingehende PRs annimmt: Automatische Vertrauens-Labels kosten nichts und sortieren die Queue.

Als Nächstes reizt mich das Naheliegende: T3 Code labelt jeden Pull Request automatisch nach Größe, und das Repository ist öffentlich. Das sind dieselben Größendaten, auf denen meine Studie aufbaut, bereits erhoben, an einer Codebase, die selbst von Agenten entwickelt wird. Ich will wissen, ob das Muster, das ich über 447 Repositories gemessen habe, in einem Repo auftaucht, das absichtlich so gebaut ist. Wenn nicht, ist das der interessantere Ausgang.

Falls du einen Settle-Workflow ausprobiert hast — oder irgendwo eine Liste hast, die nie leer wird, und dich damit arrangiert hast — würde mich interessieren, wie du damit umgehst.