Kleinere Projekte, gleiche Struktur: Was sich bei Anthropic wirklich verändert
icon
password
LinkedIn-Post erstellen
LinkedIn Post
type
Post
status
Published
date
Aug 19, 2026
slug
kleinere-projekte-gleiche-struktur-was-sich
summary
Bei Anthropic arbeiten an einzelnen Projekten oft höchstens zwei Engineers, eingebettet in funktionsübergreifende Teams mit Product Management sowie Sicherheits- und Qualitätsfunktionen.
tags
Kompetenzen
Führung
Coding
category
human-ai
Seiten-URL
https://ai.growhuman.io/article/kleinere-projekte-gleiche-struktur-was-sich
Bild-URL
file://%7B%22source%22%3A%22attachment%3A55ded64d-d7e7-4916-b79d-518cb8a74897%3Agenerated-image-1787121738690.jpeg%22%2C%22permissionRecord%22%3A%7B%22id%22%3A%223c113e6e-6069-80c2-b3f0-00a91fccfd7e%22%2C%22table%22%3A%22thread%22%2C%22spaceId%22%3A%223817e2be-234e-4402-a2dd-f340947cf65f%22%7D%7D
Persistente Bild-URL
🖼️ Bilder erstellen
Source-URL
created_at
LinkedIn Post 1
Bild-Prompt
AI summary
Bild-Idee
Bei Anthropic arbeiten an einzelnen Entwicklungsprojekten häufig höchstens zwei Engineers eng zusammen. Katelyn Lesse, Head of Engineering für Claude Platform, beschreibt das am Beispiel von Claude Managed Agents, einer Infrastruktur, mit der Kunden eigene Agentensysteme in der Cloud betreiben können. Das Projekt ging in rund sechs Monaten von der Umsetzung bis zum Launch; Ideen und Vorschläge dazu lagen laut Lesse teils schon bis zu zwei Jahre vor. Ein vergleichbares Vorhaben hätte vor dem Einsatz von KI-Werkzeugen nach ihrer Schätzung eher zwei Jahre Entwicklungszeit gebraucht.
Auf den ersten Blick liest sich das wie die Auflösung klassischer Teamstrukturen.
Ein genauerer Blick zeigt ein anderes Bild: Der Rahmen um dieses kleine Projektteam ist derselbe geblieben. Kleiner geworden ist die Einheit, die innerhalb dieses Rahmens ein einzelnes Projekt stemmt.
Der Rahmen bleibt: Teams, Product Manager, Freigabeprozesse
Anthropic organisiert seine Entwicklung weiterhin in klassischen, funktionsübergreifenden Teams nach dem Zwei-Pizza-Prinzip: fünf bis acht Ingenieur*innen, ein Engineering Manager, ein Product Manager, eine designverantwortliche Person. Diese Struktur hat sich durch den Einsatz von KI nicht aufgelöst. Lesse sagt sogar das Gegenteil: Weil Engineering-Teams mit KI-Unterstützung deutlich schneller bauen und ausliefern können, verschiebt sich der Flaschenhals von der Umsetzung zur Entscheidung. Product Manager werden dadurch wichtiger, nicht überflüssiger.
Auch Funktionen rund um Freigabe und Qualität bleiben sichtbar. Eine Stellenausschreibung für Product Management in der Entwicklerproduktivität formulierte das Ziel explizit: Während Claude einen wachsenden Teil der eigentlichen Programmierarbeit übernimmt, soll der „äußere Kreislauf“ aus Review, Validierung und Deployment gezielt gestärkt werden, damit er nicht zum neuen Engpass wird. Eine offizielle Ausschreibung beschreibt zudem ein Safe-Change-Team für Continuous Deployment und Feature Flags, das häufige Produktionsänderungen sicher und zuverlässig machen soll. Eine weitere, inzwischen archivierte Ausschreibung suchte eine Person für die Qualitätssicherung von Drittanbieter-Integrationen wie Plugins, Agent Skills und MCP-Servern.
Kleiner wird das Projekt, nicht das Team darum
Was sich tatsächlich verändert hat, zeigt sich innerhalb dieses stabilen Rahmens: einzelne Entwicklungsprojekte werden in sich geschlossener und benötigen weniger Personal, um von Anfang bis Ende durchgezogen zu werden. Jarred Sumner, der bei Anthropic am Laufzeitprojekt Bun arbeitet, hat das an einem konkreten Beispiel durchgerechnet. Die Portierung von über 500.000 Zeilen Code von Zig nach Rust, die er mit parallel arbeitenden Agenten in elf Tagen abschloss, hätte von Hand nach seiner Einschätzung drei Ingenieur*innen ein Jahr gekostet. Bemerkenswert ist die Verteilung der Arbeit innerhalb des Projekts: Nur rund 15 Prozent der Zeit gingen in die eigentliche Implementierung, die übrigen 85 Prozent in das Beheben von Fehlern, das Anpassen von Tests und die Verifikation.
Diese Verifikation verschwindet damit nicht, sie verändert ihre Verteilung. KI-gestützte Code-Reviews und automatisierte Tests gewinnen an Gewicht; die Quellen belegen jedoch keine einheitliche Freigabekette aus Sicherheits-Scan, Fuzzing und menschlicher Endfreigabe für alle Projekte. Weniger Personal pro Projekt bedeutet also nicht weniger Qualitätsarbeit, sondern eine andere Verteilung dieser Arbeit zwischen Menschen und KI-Agentensystemen.
Innerhalb eines Projekts wechseln Rollen mit der Aufgabe, nicht mit dem Titel
Für den Claude-Code-Kontext beschreibt Boris Cherny fünf klar unterscheidbare Arbeitsweisen. Sie sind keine Jobtitel, sondern folgen dem jeweiligen Projektstand:
- Prototyper: entwickelt viele Ideen schnell, im Wissen, dass die meisten verworfen werden.
- Builder: bringt einen überlebenden Prototyp in Produktionsqualität.
- Sweeper: entfernt Funktionen, die kein Gewicht mehr tragen.
- Grower: schließt die Lücke zwischen dem, was gebaut wurde, und dem, was Nutzende brauchen.
- Maintainer: hält ein gewachsenes System zuverlässig, sobald andere sich darauf verlassen.
Dieselben Personen können, abhängig vom Projektstand, zwischen diesen Arbeitsweisen wechseln. Diese Flexibilität betrifft die Arbeit innerhalb eines Projekts. Sie ersetzt nicht Product Management, das Prioritäten und Richtung klärt, oder die Funktionen, die Qualität und einen sicheren Betrieb absichern.
Zwei Ebenen, zwei Geschwindigkeiten
Was bei Anthropic kleiner wird, ist die Einheit, die ein einzelnes Entwicklungsprojekt stemmt; nicht die Organisation, die dieses Projekt umgibt. Product Management, Engineering Management, Deployment-Sicherheit und Qualitätssicherung bleiben relevante Funktionen. Lesse beobachtet, dass sich der Flaschenhals mit höherer Umsetzungsgeschwindigkeit von der Implementierung zur Entscheidung verschiebt. Innerhalb dieses Rahmens können an einem konkreten Projekt heute oft höchstens zwei Engineers arbeiten, die zwischen den Arbeitsweisen von Prototyper, Builder, Sweeper, Grower und Maintainer wechseln, je nachdem, was die Aufgabe verlangt.
Quellen:
Loading...