Anthropic hat die Projects-Funktion in Claude Code überarbeitet. Ein Projekt sammelt nicht mehr nur Kontext und Dateien, sondern verteilt Aufträge eigenständig auf mehrere parallel laufende Threads. Die Funktion befindet sich in der Beta-Phase und steht zunächst Nutzerinnen und Nutzern der Abos Pro und Max zur Verfügung.

Vom Kontextcontainer zum Verteiler

Projects war bislang vor allem ein Ort, an dem Arbeitsstände, Dateien und Anweisungen für ein Vorhaben zusammenlaufen. Mit dem Umbau übernimmt das Projekt zusätzlich eine koordinierende Rolle: Es nimmt einen Auftrag entgegen und sorgt dafür, dass Teilaufgaben nebeneinander abgearbeitet werden, statt sie nacheinander in einer einzigen Unterhaltung durchzugehen.

Fachlich ist das ein Schritt in Richtung agentische KI — also KI-Systeme, die nicht nur auf einzelne Eingaben antworten, sondern mehrschrittige Arbeitsabläufe selbstständig planen und ausführen. Der Orchestrator verteilt, die einzelnen Threads erledigen. Für Entwicklungsteams verschiebt sich damit die Interaktion: weniger Prompt-für-Prompt-Dialog, mehr Auftragsbeschreibung und Ergebnisprüfung.

Was Parallelität im Alltag ändert

Der praktische Gewinn liegt dort, wo Aufgaben ohnehin unabhängig voneinander sind. Typische Kandidaten in Web- und Softwareprojekten:

  • Tests für mehrere Module schreiben oder ergänzen
  • Wiederkehrende Anpassungen über viele Dateien hinweg, etwa Umbenennungen oder Signaturänderungen
  • Dokumentation nachziehen, während an anderer Stelle refaktoriert wird
  • Mehrere Lösungsvarianten für ein Problem parallel skizzieren und danach vergleichen

Wo Teilaufgaben dagegen voneinander abhängen — Datenmodell vor Schnittstelle, Schnittstelle vor Frontend —, bringt Parallelisierung wenig und erzeugt im schlechtesten Fall Konflikte, die jemand anschließend auflösen muss. Die Frage, welche Arbeit sich überhaupt sinnvoll aufteilen lässt, bleibt eine fachliche Entscheidung und wandert nicht automatisch an das Werkzeug.

Der Flaschenhals verschiebt sich zum Review

Wenn mehrere Threads gleichzeitig Code produzieren, entsteht in kürzerer Zeit mehr Material, das geprüft werden will. Die Engstelle im Prozess wandert damit von der Umsetzung zur Durchsicht. Teams, die heute schon Mühe haben, Pull Requests zeitnah zu reviewen, verstärken dieses Problem, wenn sie den Ausstoß erhöhen, ohne die Prüfkapazität mitzudenken.

Hilfreich sind in dieser Situation Mechanismen, die unabhängig vom Autor greifen: automatisierte Tests mit belastbarer Abdeckung, statische Analyse, Linting-Regeln, klare Definition-of-Done. Je stärker die Qualitätssicherung im Build verankert ist, desto eher lässt sich zusätzlicher Durchsatz überhaupt verarbeiten. Ohne diese Basis erzeugt schnellere Codeproduktion vor allem schnelleren Rückstau.

Einordnung für Projektverantwortliche

Die Ankündigung betrifft zunächst ein einzelnes Werkzeug und eine Beta-Version. Wie robust die Verteilung in größeren Codebasen arbeitet, wie gut die Ergebnisse aus verschiedenen Threads zusammenpassen und wie sich der Verbrauch an Kontingenten verhält, wird sich erst im praktischen Einsatz zeigen. Betas sind Betas: Verhalten und Funktionsumfang können sich ändern.

Bemerkenswert ist trotzdem die Richtung. Die Anbieter von Coding-Assistenten bewegen sich erkennbar weg vom Modell „ein Chat, eine Aufgabe“ hin zu Systemen, die mehrere Arbeitsstränge koordinieren. Wer heute Entwicklungsprozesse plant, sollte davon ausgehen, dass diese Betriebsart in den kommenden Zyklen normaler wird — unabhängig davon, welches Produkt sich am Ende durchsetzt.

Womit Teams jetzt anfangen können

Ein sinnvoller Einstieg braucht keine Umstellung der gesamten Toolchain:

  1. Aufgabentypen sortieren. Welche Arbeiten im eigenen Projekt sind tatsächlich unabhängig? Diese Liste ist die Grundlage für jede Parallelisierung, mit oder ohne KI.
  2. Prüfpfad härten. Testabdeckung, CI-Pipeline und Review-Regeln so aufstellen, dass sie höheren Durchsatz aushalten.
  3. Abgegrenzt erproben. Einen überschaubaren Bereich wählen, in dem Fehler früh auffallen und wenig Schaden anrichten — etwa interne Werkzeuge statt produktiver Kundenlogik.
  4. Ergebnisse messen. Nicht nur die Zeit bis zum ersten Entwurf, sondern die Zeit bis zum freigegebenen Stand inklusive Nacharbeit.

Zusätzlich lohnt ein Blick auf die organisatorische Seite: Wer verantwortet Code, den ein Agent erzeugt hat? Welche Bereiche eines Repositorys sind für automatisierte Änderungen tabu? Solche Festlegungen kosten wenig Aufwand, verhindern aber Diskussionen zu einem Zeitpunkt, an dem sie teuer werden.

Was das für Web- und Softwareprojekte bedeutet

Für Projekte in TYPO3, individueller Webentwicklung oder Schnittstellenarbeit verspricht die parallele Abarbeitung vor allem bei breit gestreuten, gleichförmigen Aufgaben Tempo — nicht bei der fachlichen Konzeption. Der entscheidende Hebel liegt deshalb weniger im Werkzeug als in einem Prozess, der zusätzlichen Output zuverlässig prüfen und integrieren kann. Wer Testbasis und Review-Kapazität vorher aufräumt, profitiert von agentischen Werkzeugen; wer es nicht tut, verlagert den Engpass lediglich um eine Station nach hinten.

Quellen