Fire-and-Forget-Coding: Der Aufstieg von Background Agents im Jahr 2026

Letzte Woche habe ich einem Agent ein Ticket gegeben, den Laptop zugeklappt und bin Mittag essen gegangen. Als ich zurückkam, wartete ein Pull Request — Tests grün, eine kurze Zusammenfassung, ein Diff, der elf Dateien berührt hatte. Es hat funktioniert. Ich habe gemergt.

Die anderen drei, die ich an diesem Morgen losgeschickt hatte, liefen nicht so gut. Einer hat leise ein Feature Flag gelöscht, weil es "nicht referenziert wurde" (war es, aus einer Config-Datei, die der Agent nie gelesen hat). Einer hat ein paar Dollar damit verbrannt, herauszufinden, dass unsere Test-Suite einen Datenbank-Container braucht, den er nicht starten konnte. Einer hat einen Diff produziert, der so plausibel und so falsch war, dass ich ihn auf einem Telefonbildschirm fast genehmigt hätte.

Das ist die ehrliche Lage bei Background Agents im Jahr 2026. Eine gute Run fühlt sich wie Betrug an. Schlechte Runs fühlen sich an wie das Managen eines Juniors, der um 3 Uhr morgens arbeitet, nie Fragen stellt und sehr selbstbewusst ist.

Kurz gesagt: Background Agents haben das Problem "Code schreiben, während ich nicht zuschaue" im Wesentlichen gelöst. Was sie nicht gelöst haben — was sie sogar verschlimmert haben könnten — ist das Review. Der Engpass hat sich verlagert. Früher war es, wie schnell ein Modell tippen konnte. Jetzt ist es, wie schnell du Arbeit lesen, ihr vertrauen und mergen kannst, bei deren Entstehung du nicht dabei warst. Wenn du dafür keinen Prozess aufbaust, bekommst du keinen Force Multiplier; du bekommst einen Rückstau halb gebackener PRs.

Was "Background Agent" jetzt wirklich bedeutet

Ein Background Agent ist ein asynchroner Coding-Agent, der irgendwo außerhalb deiner Vordergrundaufmerksamkeit läuft — meistens eine Cloud-VM —, die Aufgabe erledigt und dir später ein Ergebnis übergibt. Du weist Arbeit zu und gehst weg. Das ist das ganze Versprechen, und per Mitte 2026 liefert jedes große Harness eine Version davon.

Cursor hat in Version 3.0 seine gesamte Oberfläche darum herum neu gebaut. Die Release-Notes sind unverblümt über den neuen Schwerpunkt: Du kannst "viele Agents parallel über Repos und Environments laufen lassen: lokal, in Worktrees, in der Cloud und auf Remote-SSH" (cursor.com/changelog/3-0). Ihre Cloud-Agents laufen in Sandboxes, "iterieren, bis sie ihre Ausgaben validiert haben," und verwandeln Linear- oder Jira-Issues direkt in PRs (cursor.com/cloud). Futurums Einschätzung des Folge-Releases 3.2 nannte die IDE "neu gerahmt als Agent-Execution-Runtime" (futurumgroup.com) — etwas marketing-nah, aber in der Richtung korrekt.

Claude Code ging denselben Weg, behielt aber die Begriffe präzise. Ihre Docs unterscheiden vier Wege zum Parallelisieren: Subagents (delegierte Worker innerhalb einer Session), Agent View (claude agents — "Sessions im Hintergrund dispatchen und überwachen," eine Research Preview), Agent Teams (ein Koordinator leitet Worker, "experimentell und standardmäßig deaktiviert") und Dynamic Workflows (ein Skript, das viele Subagents auffächert und gegenseitig prüft) (code.claude.com/docs/en/agents). Die vier sind nicht austauschbar, und die Namen leisten echte Arbeit.

Devin, das diese Kategorie mehr oder weniger begründet hat, verbrachte 2026 damit, einen autonomen Agent in viele zu verwandeln. Das Release vom 19. März fügte "Devin Manages Devins" hinzu — eine Koordinator-Session, die Arbeit abgrenzt und an "ein Team von verwalteten Devins delegiert, die parallel arbeiten," jeder auf seiner eigenen isolierten VM (docs.devin.ai/release-notes/2026).

Der gemeinsame Faden: isolierte Umgebung, asynchroner Handoff, PR am Ende. Die Unterschiede liegen darin, wie viel Spielraum du bekommst und wie das Review auf dich zurückfällt.

Wofür sie wirklich gut sind

Sei konkret, wo das Früchte trägt, denn der Hype glättet es ein.

Background Agents sind gut bei begrenzter, gut spezifizierter, verifizierbarer Arbeit. Der Sweet Spot ist eine Aufgabe, bei der (a) du "fertig" in einem Satz beschreiben kannst, (b) ein Test oder Type-Checker das beweisen kann und (c) kein Gespür gefragt ist. Dependency Bumps mit einer bestandenen Suite. Ein Feld durch einen bekannten Stack hinzufügen. Die offensichtlichen Unit Tests schreiben. Mechanische Refactors über viele Dateien — genau die Art von Arbeit, für die Claude Codes /batch-Skill gebaut wurde, der "eine große Änderung in 5 bis 30 Worktree-isolierte Subagents aufteilt, von denen jeder einen Pull Request öffnet" (code.claude.com/docs/en/agents).

Sie sind gut bei paralleler Breite. Cursors /best-of-n führt dieselbe Aufgabe über mehrere Modelle aus, "jedes in seinem eigenen isolierten Worktree, und vergleicht dann die Ergebnisse" (cursor.com/changelog/3-0). Bei einem verzwickten Bug, bei dem du wirklich nicht weißt, welcher Ansatz richtig ist, ist es ein echter Nutzen, drei Versuche zu starten und den besten zu behalten — eben weil du Dinge laufen lassen kannst, die du nicht beobachtest.

Und sie sind gut darin, einer Person zu ermöglichen, mehr als eine Sache zu tun. Als Solo-Builder war die Einschränkung nie Ideen — es ist, dass ich nur in einer Datei gleichzeitig sein kann. Den langweiligen Teil zu delegieren, während ich den interessanten Teil erledige, ist der eigentliche Gewinn. Nicht "die KI baut meine App" — das ist noch immer Fantasie. "Die KI räumt meinen Rückstau kleiner offensichtlicher Dinge weg, während ich nachdenke" ist heute auslieferbar.

Wofür sie schlecht sind, ehrlich gesagt

Die Fehlermodi sind nicht exotisch. Sie sind langweilig und wiederholen sich.

Kontext-Verhungern. Ein Background Agent weiß nur, was er vor dem Start gesammelt hat. Er kann dich mitten im Lauf keine Rückfrage stellen — oder wenn er es kann, bist du beim Mittagessen. Also rät er. Mein Vorfall mit dem gelöschten Feature Flag war reines Kontext-Verhungern: der Agent hat über die Dateien, die er hatte, korrekt geschlussfolgert und ein falsches Ergebnis erreicht, weil die relevante Tatsache irgendwo lag, wo er nicht hingeschaut hatte. Die Lösung liegt vorne: besseres Task Framing, eine AGENTS.md, die erklärt, wo Dinge liegen, Links zum Issue. Müll rein, selbstbewusster Müll raus.

Stille Drift. Das beängstigende Versagen ist nicht der PR, der offensichtlich kaputt ist — den wirst du erwischen. Es ist derjenige, der 90 % richtig und subtil falsch ist, mit einer sauberen Zusammenfassung, die das korrekte Verhalten beschreibt, während der Diff etwas anderes tut. Die Zusammenfassung wird aus der Absicht generiert, nicht aus dem, was der Code tut. Vertraue dem Diff, nicht der Beschreibung.

Merge-Konflikte und gegenseitiges Übertreten. Starte sechs Agents gegen ein Repo und sie werden kollidieren. Die Antwort der gesamten Branche ist Worktree-Isolation — jeder Agent bekommt seinen eigenen Git-Checkout, damit parallele Sessions "niemals dieselben Dateien bearbeiten" (code.claude.com/docs/en/agents). Das löst das Kämpfen der Agents während des Laufs. Es tut nichts gegen sechs Branches, die alle dienstagnachmittag auf main landen, jeder leicht veraltet. Der Konflikt verlagert sich nur auf die Merge-Zeit, was bedeutet: er verlagert sich auf dich. Devin hat im Februar Merge-Conflict-Erkennung im Review eingeführt, genau weil das der Punkt ist, an dem der parallele Traum auf die Realität trifft (docs.devin.ai/release-notes/2026).

Außer Kontrolle geratende Kosten. Async bedeutet, niemand schaut auf den Zähler. Background Agents stützen sich auf die teuersten Modelle, und ein ehrlicher Vergleich hat einen "einfachen PR" auf Cursors Background Agent während der Preview auf etwa $4,63 gemessen (aitechfy.com). Das ist fair für ein echtes Ticket und absurd für einen Tippfehler. Kosten "werden bei neuartiger Arbeit unvorhersehbar," und die Ausgaben pro Aufgabe bleiben "undurchsichtig, solange du das Usage-Dashboard nicht überprüfst" (techsy.io). Anthropics eigene Docs sagen es klar: mehrere Agents gleichzeitig zu starten "vervielfacht den Token-Verbrauch" (code.claude.com/docs/en/agents). Setze Ausgabenlimits, bevor du fire-and-forget machst, nicht nach der Rechnung.

Der eigentliche Engpass ist das Review, und er gehört jetzt dir

Hier ist der Teil, den Demos überspringen. Als Generierung der langsame Schritt war, war Review kostenlos — du hast gesehen, wie Code Zeile für Zeile erscheint, und hast ihn genehmigt, während er kam. Background Agents haben das gebrochen. Der Code erscheint, während du weg bist. Jetzt bist du Reviewer von Arbeit, die du nicht beobachtet hast, im Volumen von so vielen Agents, wie du dispatched hast.

Die Anbieter wissen das offensichtlich, denn das interessanteste Shipping im Jahr 2026 war nicht in der Generierung — es war im Review. Devin hat im Januar ein ganzes Review-Produkt eingeführt, das verwandte Änderungen gruppiert, "kopierten Code, Bugs und Sicherheitsprobleme erkennt," und bis April Auto-Merge und einen "Auto-fix with Devin"-Button hinzugefügt (docs.devin.ai/release-notes/2026). Das sagt dir, wo der Schmerz liegt.

Aber sei vorsichtig, was du dir wünschst. Derselbe Vergleich, der diese Tools bepreist hat, stellt auch fest, dass "jedes Team, das wir kennen, vor dem Merge ein menschliches Review verlangt," und nennt Auto-Merge "eine Schusswaffe, mit der man sich selbst in den Fuß schießt" (techsy.io). Ich stimme zu. Der Punkt, an dem ein Agent die Arbeit eines anderen Agents reviewed, ist die Triage deiner Warteschlange — die drei PRs zu markieren, die deine Augen brauchen, und die langweiligen zwei abzustempeln —, nicht dich zu entfernen. Der Tag, an dem du einen Agent erlaubst, die Arbeit eines anderen Agents unbeaufsichtigt in main zu genehmigen, ist der Tag, an dem du die Produktion subtiler Bugs automatisiert hast.

Die Fähigkeit, die 2026 wirklich zählt, ist also nicht Prompting. Es ist das Durchführen einer Review-Warteschlange, ohne zu ertrinken. Konkret:

• Triage vor dem Lesen. Erst das günstige, mechanische Signal: Hat der Test bestanden, hat der Type-Checker bestanden, ist der Diff klein? Ein PR, der seine eigene Überprüfung nicht besteht, verdient noch keine Aufmerksamkeit.
• Lies den Diff, nie die Zusammenfassung. Die Zusammenfassung ist die Absicht des Agents. Der Diff ist das, was passiert. Sie divergieren lautlos.
• Mache "fertig" beweisbar. Wenn du keinen Check schreiben kannst, der die Aufgabe bestätigt, hast du keine Background-Agent-Aufgabe — du hast etwas, das du sowieso babysittten wirst. Schieb die Verifikation in den Agentenlauf, damit er sich selbst testet; Cursors Cloud-Agents "iterieren, bis sie ihre Ausgaben validiert haben" (cursor.com/cloud), und dieses Gate ist mehr wert als jede Prompt-Optimierung.
• Begrenze die Warteschlangentiefe. Mehr Agents ist nicht mehr Output, sobald du mehr reviewst, als du bewältigen kannst. Wenn PRs schneller eintreffen, als du sie abarbeitest, hast du einen Backlog-Generator gebaut, keinen Force Multiplier.

Ein Tagesablauf, der wirklich funktioniert

Hier ist die Schleife, die ich als Solo-Builder fahre. Sie ist absichtlich unspektakulär.

Morgens: Ich triage meine eigene Issue-Liste in zwei Eimer — agent-geformt (begrenzt, testbar, langweilig) und ich-geformt (Urteil, Architektur, alles, was Geld oder Auth berührt). Ich dispatche drei oder vier agent-geformte Tickets, jedes in seinen eigenen Worktree oder Cloud-Sandbox, mit einer echten Beschreibung und einem Link zum Issue. Dann schließe ich dieses Fenster und arbeite selbst an einem ich-geformten Problem, im Vordergrund, auf die alte Art.

Ich sitze nicht und schaue zu. Der ganze Punkt ist das Async. Einem Background Agent zuzuschauen ist einfach ein synchroner Agent mit extra Schritten und schlechterer Sicht.

Gegen Vormittag beginnen PRs zu landen. Ich mache den Triage-Durchlauf: zuerst Gate-Status, dann kleine Diffs vor großen. Die zwei, die sauber bestanden haben und zehn Zeilen berühren, lese und merge ich in je fünf Minuten. Den einen, der "erfolgreich" war, aber mehr umgeschrieben hat als erwartet, lese ich sorgfältig — da versteckt sich Drift. Den einen, der seine eigenen Tests nicht bestanden hat, formuliere ich entweder neu und dispatche ihn mit dem neuen Kontext erneut, oder ich ziehe ihn lokal und beende ihn von Hand. Ein Agent, der vierzig Minuten mit einer kaputten Testumgebung verbrennt, sagt mir nur, dass mein Setup das Problem ist; ich behebe es einmal und der nächste Run ist sauber.

Ich merge Agent-Branches einen nach dem anderen, rebase dabei, nicht als Stapel am Ende des Tages — so vermeidet man den Dienstagnachmittags-Konflikt-Aufstau. Und ich halte eine harte Regel: Nichts mit Auth, Billing oder Migration verlässt einen Background-Run, ohne dass ich jede Zeile gelesen habe. Das ist nicht ich-geformt, weil es schwer ist. Es ist ich-geformt, weil der Blast Radius groß ist und der Agent die Konsequenz nicht spürt.

Netto für den Tag: vielleicht sechs geschlossene Tickets, wo ich zwei gemacht hätte. Nicht weil die Agents clever sind — einige dieser PRs waren Nacharbeit —, sondern weil der langweilige Teil parallel abgearbeitet wurde, während ich meine eigentliche Aufmerksamkeit auf die Hälfte verwendet habe, die einen Menschen braucht.

Die nüchterne Einschätzung

Background Agents sind real, sie können ausgeliefert werden, und die Parallel-Cloud-VM-zu-PR-Schleife funktioniert gut genug, um den Tagesablauf eines Solo-Builders zu verändern. Das ist kein Hype. Was Hype ist, ist das implizierte "und dann musst du nichts mehr tun." Du musst. Die Arbeit hat nur die Form gewechselt — von Code tippen zu Spezifizieren, Absichern und Reviewen.

Behandle sie wie ein schnelles Juniors-Team, das arbeitet, während du schläfst, und bis zum Morgen einen Stapel PRs produziert: einige ausgezeichnet, einige leise falsch, alle selbstbewusst. Die Auszahlung ist real, wenn du den Review-Muskel aufbaust, der der Generierung entspricht. Wenn du das überspringst, hast du dir kein Team gekauft. Du hast dir eine Warteschlange gekauft.

Fang mit einem Agent, einem begrenzten Ticket, einer beweisbaren Definition von "fertig" an. Bringe die Triage-Schleife auf Tiefe eins zum Laufen, bevor du auf vier auffächerst. Die Generierung war nie der schwierige Teil.