Ein Assistent wartet auf dich. Ein Teammitglied trägt Arbeit, die du nicht beobachtest. Genau dieser eine Unterschied erklärt den größten Teil der Verwirrung in der aktuellen Diskussion über KI am Arbeitsplatz – und er entscheidet, welche Teile deines Prozesses sich ändern müssen.
Beide Muster sind nützlich, und keines davon ist eine Entwicklungsstufe, aus der das andere von selbst herauswächst. Was sich ändert, ist, wo die Arbeit liegt, wer für sie verantwortlich ist und wie andere davon erfahren. Dieser Leitfaden zieht die Grenze zwischen einem KI-Assistenten und einem KI-Teammitglied, nennt die fünf Dinge, die sich im Wochenablauf eines Teams tatsächlich ändern, und sagt klar, wo die Teammitglied-Metapher nicht mehr weiterhilft. Sharkly gibt es wegen des zweiten Musters – deshalb werden die Grenzen unten nüchtern beschrieben statt verkauft.
TL;DR
Ein KI-Assistent arbeitet innerhalb deiner Session: Du gibst einen Prompt, er antwortet, der Wert steckt in deinem Kontext und verschwindet, sobald du das Fenster schließt. Einem KI-Teammitglied wird eine Arbeitseinheit mit einem definierten Ergebnis zugewiesen; es führt sie an einem Ort aus, den das Team einsehen kann, und meldet an einen Eintrag zurück, der die Session überdauert. Der Wechsel von einem zum anderen erfordert keine besseren Modelle. Er erfordert eine Zuweisung, eine sichtbare Ausführungsspur, einen Review-Status und eine Person, die das Ergebnis abnimmt.
Die Definitionen, die es sich zu behalten lohnt
Ein KI-Assistent ist auf den Prompt bezogen. Du bist die ganze Zeit dabei. Das Arbeitsergebnis ist ein Vorschlag, den du annimmst oder verwirfst, und die Frage nach der Verantwortung stellt sich nie, weil du nie weg warst. Autocomplete, Chat und Inline-Refactoring gehören alle hierher.
Ein KI-Agent, der als Teammitglied arbeitet, ist aufgabenbezogen. Er bekommt ein Ziel, Rahmenbedingungen und genug Kontext, um loszulegen. Er recherchiert, führt aus, testet und berichtet. Beim Mittelteil bist du nicht dabei. Genau dieses Fehlen ist der Punkt – und es ist zugleich die Quelle aller neuen Anforderungen weiter unten. Unser Definitionstext zu agentic coding geht dieselbe Leiter aus einem anderen Blickwinkel durch.
Die entscheidende Frage ist nicht Intelligenz. Sie lautet: Wenn du deinen Laptop zuklappst – läuft die Arbeit weiter, und kann ein Kollege nachvollziehen, was passiert ist?
Was sich bei der Arbeit tatsächlich ändert
1. Arbeit wird zu einem Eintrag, nicht zu einer Nachricht. Bei einem Assistenten ist die Anfrage ein Chat-Beitrag. Bei einem Teammitglied muss die Anfrage auch dann funktionieren, wenn sie jemand liest, der nicht dabei war: ein definiertes Ergebnis, was zum Umfang gehört und was nicht, relevante Dateien, Rahmenbedingungen und die Art und Weise, wie die Fertigstellung geprüft wird. Teams, die das überspringen, schreiben vage Aufgaben und geben dem Modell die Schuld.
2. Die Zuweisung teilt sich in zwei Teile. Eine Person bleibt für das Ergebnis verantwortlich. Ein Agent führt aus. Tools, die beides in einem einzigen Zuständigkeitsfeld zusammenfassen, erzeugen Boards, bei denen niemand zu irgendetwas befragt werden kann. Sharkly führt menschliche Zuständige und den ausführenden Agenten als getrennte Felder in derselben Aufgabe, sodass beide Fakten gleichzeitig festgehalten werden.
3. Sichtbarkeit ist keine Option mehr. Die Arbeit eines Assistenten ist sichtbar, weil du zugesehen hast. Die Arbeit eines Teammitglieds ist nur sichtbar, wenn die Plattform Fortschritt, Kommentare, Blocker und eine Spur zurück zu einem gemeinsamen Eintrag laufend ausgibt. Andernfalls lautet der ehrliche Status der Hälfte deiner Arbeit: „Frag Priya, sie hat damit angefangen.“
4. Review wird zu einem benannten Status. Nicht „irgendwann schaut sich das schon jemand an“, sondern ein explizites Signal „wartet auf menschliches Review“, das in einer Warteschlange landet. In Sharkly erreicht dieses Signal den Agent-Posteingang der verantwortlichen Person – zusammen mit Fehlern und direkten Fragen.
5. Können wird geteilt – oder es bleibt privat. Die Prompt-Kunst eines Entwicklers ist ein Assistenten-Trick. Gespeichert als Agent-Konfiguration mit Anweisungen, Runtime, Repositories und wiederverwendbaren Skills wird daraus etwas, das die nächste Person erbt, statt es neu zu entdecken.
| Dimension | KI-Assistent | KI-Teammitglied |
|---|---|---|
| Arbeitseinheit | Ein Prompt | Eine Aufgabe mit Abnahmekriterien |
| Deine Anwesenheit | Immer | Für Steuerung und Review |
| Wohin das Ergebnis geht | Dein Editor oder Chat | Ein gemeinsamer Eintrag mit Spur |
| Verantwortlichkeit | Implizit bei dir | Explizit bei einer benannten Person |
| Fehlerfall | Schlechter Vorschlag, verworfen | Stille Arbeit, die niemand prüft |
| Wiederverwendung | Persönliche Gewohnheit | Gespeicherte Konfiguration und Skills |
Eine Woche, die anders aussieht
Die Veränderungen zeigen sich im Kalender, bevor sie sich in den Metriken zeigen.
Das Standup ist keine Statusrunde mehr, denn das Board trägt den Status bereits. Fünf Minuten wert ist die Ausnahmeliste: Welche Runs sind fehlgeschlagen, welche Ergebnisse warten auf einen Menschen, welche Aufgabe war so schlecht geschrieben, dass der Agent geraten hat. Diese Liste ist kurz und umsetzbar – mehr, als die meisten Standups schaffen.
Auch das Planning verändert sich. Wenn eine Aufgabe präzise genug sein muss, damit ein Agent sie ausführen kann, wandert das Refinement nach vorn und wird konkreter: Abnahmekriterien sind keine Formalie mehr, denn ein vages Kriterium erzeugt einen Run, den du wegwerfen musst. Teams merken das meist daran, dass sie den Umfang früher aufschreiben und mitten im Sprint weniger Zeit verlieren.
Review wird zur knappen Ressource. Drei Agenten können an einem Vormittag mehr Änderungen produzieren, als ein Reviewer an einem Tag durchbekommt – die eigentliche Einschränkung verschiebt sich also von der Tippgeschwindigkeit zur Lesekapazität. Plane das ein, statt es zu entdecken: Begrenze, wie viel Agent-Arbeit pro Reviewer gleichzeitig unterwegs ist, und behandle eine wachsende Warteschlange ungeprüfter Ergebnisse wie einen wachsenden Stapel nicht gemergter Pull Requests.
Wo die Teammitglied-Metapher an ihre Grenzen stößt
Nimmt man die Metapher ernst, führt sie in drei Punkten in die Irre.
Ein Agent kann keine Verantwortung tragen. Man kann ihm Arbeit zuschreiben; er kann aber nicht für ein Ergebnis geradestehen, im nächsten Quartal einen Trade-off rechtfertigen oder die Konsequenzen einer schlechten Entscheidung tragen. Jede ernsthafte Plattform in diesem Bereich verankert das: Linear behält den Menschen als primären Assignee und führt den Agenten als Contributor, und Sharklys eigene Haltung ist: Agenten recherchieren, führen aus, testen und berichten, während Menschen die Richtung vorgeben, Befugnisse erteilen und das Ergebnis abnehmen.
Ein Agent hat kein fortlaufendes Gedächtnis deines Teams – es sei denn, du gibst ihm eines. Ein neuer Kollege saugt Kontext auf, indem er einfach da ist. Ein Agent bekommt genau das, was du aufgeschrieben hast. Deshalb schlägt schriftlich festgehaltener Umfang jedes Mal den impliziten.
Und der Status eines Agenten ist kein Projektstatus. Eine Aufgabe kann auf „In Progress“ stehen, während der Agent arbeitet, auf eine Antwort wartet, auf Review wartet oder einen Fehler meldet. Wenn Teams den Run-Status für den Projektstatus halten, erleben sie am Sprintende Überraschungen. Unser Leitfaden zum KI-Agenten-Projektmanagement behandelt diese Trennung ausführlich.
Was du ergänzen musst, bevor Agenten sich wie Teammitglieder verhalten
Vier Dinge, in dieser Reihenfolge. Keines davon erfordert eine Migration.
- Eine Aufgabe mit einem prüfbaren Ergebnis. Wenn du nicht sagen kannst, wie du die Arbeit prüfen würdest, kann ein Agent das auch nicht.
- Ein ausführender Assignee, getrennt vom Owner. Weise die Person und den Agenten derselben Aufgabe zu.
- Einen sichtbaren Run. Fortschritt, Kommentare und eine Spur, die an der Aufgabe hängt und für alle im Team lesbar ist.
- Einen Abnahmeschritt. Eine benannte Person setzt die Arbeit auf Erledigt, nachdem sie die Belege gelesen hat – nicht, nachdem sie gesehen hat, dass der Run durchgelaufen ist.
Führe sie zuerst für eine wiederkehrende Art von Arbeit ein: Dependency-Updates, Testabdeckung für ein stabiles Modul, Migrations-Gerüste. Erweitere das Ganze, sobald eine zweite Person das Agent-Ergebnis von jemand anderem geprüft hat, ohne dass es dafür eine mündliche Einweisung brauchte. Lade Sharkly herunter, wenn du diesen Kreislauf vorkonfiguriert haben möchtest – oder baue ihn in dem Tracker nach, den du bereits nutzt.
FAQ
Ist ein KI-Agent nur ein Assistent mit mehr Berechtigungen? Berechtigungen sind wichtig, aber der eigentliche Unterschied ist die Arbeitseinheit. Ein Assistent bearbeitet einen Prompt innerhalb deiner Session; ein Agent bearbeitet eine Aufgabe, die die Session überdauert, und meldet an einen gemeinsamen Eintrag zurück.
Sollten wir Assistenten durch Agenten ersetzen? Nein. Assistenten sind weiterhin besser für alles, was du Tastendruck für Tastendruck steuern willst. Agenten sind für Arbeit, die du spezifizieren, übergeben und prüfen kannst.
Wer prüft Agent-Arbeit in großem Umfang? Dieselben Personen, die auch menschliche Pull Requests prüfen – deshalb wird die Review-Kapazität zum eigentlichen Engpass. Miss zu Beginn, wie lange Ergebnisse warten, bis ein Mensch sie öffnet.
Brauchen Agenten eigene Konten und Berechtigungen? Sie brauchen zugeschnittene Zugriffe, und diese sollten so eng wie nötig sein. In der Praxis heißt das: bestimmte Repositories, bestimmte Maschinen und ein Rollenmodell, das festlegt, wer welchen Agenten starten darf. Unser Sharkly-Agents-Erklärstück zeigt eine Umsetzung.
