Vor einem Jahr war “Ticket an eine KI zuweisen und einen Pull Request zurückbekommen” eine Demo, bei der sich Leute nach vorne gelehnt haben.
Heute ist es eine Checkbox.
GitHub lässt euch ein Issue an Copilot, Claude oder Codex zuweisen. Linear startet Coding-Sessions mit Claude Code und Codex direkt aus einem Issue. Jira führt Rovo und Agenten von Drittanbietern als Bearbeiter, direkt neben euren Kolleginnen und Kollegen. OpenAI hat Symphony als Open Source veröffentlicht, das aus jedem Linear-Issue einen eigenen Codex-Workspace macht.
Wenn euer Tracker das noch nicht kann, kann er es im Frühjahr. Der Kern-Loop, an dem ich lange gebaut habe, ist jetzt ein Gratis-Feature in Tools, für die euer Team ohnehin bezahlt.
Das ist in Ordnung. Es macht klar, worauf es wirklich ankommt.
Der Loop war nie das Schwierige
Schaut euch an, was passiert, wenn ein Team den Loop einschaltet.
Die erste Woche ist aufregend. Kleine Bugs verschwinden. Jemand postet einen Screenshot von einem PR, der aufging, während er beim Mittagessen war.
In der zweiten Woche fangen die Fragen an.
Wer hat dieses Ticket geschrieben? Da stand “Export fixen”, und der Agent hat einen anderen Export gefixt. Warum hat er das Billing-Modul angefasst? Wer hat das Dependency-Upgrade freigegeben, das nebenbei mit reingerutscht ist? Die Tests laufen grün - aber die Tests, die er selbst geschrieben hat, prüfen nur, dass die Funktion irgendwas zurückgibt. Wer reviewt bis Freitag vierzehn PRs? Und was hat das alles gekostet?
Nichts davon ist ein Problem der Fähigkeiten. Die Modelle sind gut. Sie schreiben ordentlichen Code. Das Problem: Niemand ist für die Arbeit rund um den Code zuständig.
Fünf Dinge, die euch niemand verkauft
Wenn ich mir Teams anschaue, die Agenten-Lizenzen haben, aber kein KI-Teammitglied, fehlen immer dieselben fünf Dinge.
Intake. Jemand muss aus “Kunden beschweren sich, dass der Export langsam ist” kleine Stories mit Akzeptanzkriterien machen, und mit einem konkreten Weg, zu zeigen, dass jede davon funktioniert. Das ist der Job eines Product Owners. Ein Agent, der ein vages Issue bekommt, liefert einen vagen PR.
Regeln. Was darf der Agent anfassen? Welche Repos, welche Pfade, wie viel darf er pro Story ausgeben, darf er selbst mergen? Heute steht die Antwort in irgendjemandes Kopf. Oder in einem Prompt, den niemand reviewt.
Prüfung. “Tests grün” heißt nicht “es funktioniert”. Wenn der Agent Code und Tests schreibt, benotet er seine eigenen Hausaufgaben. Jemand muss das Ergebnis gegen die Anforderung prüfen, nicht gegen die Meinung des Agenten über die Anforderung.
Verantwortung. Wer hat was gemacht, mit wessen Freigabe, zu welchen Kosten? Wenn die Prüferin oder euer CTO fragt, ist “die KI war’s” keine Antwort.
Passung zum Prozess. Euer Team hat einen Tracker, eine CI, Branch Protection und Review-Regeln. Ein KI-Teammitglied, das ein eigenes Board und einen eigenen Workflow braucht, ist ein Tool mehr, auf das ihr aufpassen müsst.
Modellanbieter verkaufen Fähigkeiten. Tracker-Anbieter verkaufen ihren eigenen Agenten in ihrem eigenen Tool. Niemand verkauft die Schicht dazwischen: die, die ein KI-Teammitglied unter den Regeln eures Teams betreibt, in euren Tools, und ihre Arbeit offenlegt.
Was kanman dagegen tut
Diese Schicht ist kanman jetzt.
Ihr fügt eine Anforderung ein oder taggt kanman in Slack. kanman schreibt die Stories, mit Akzeptanzkriterien und einem Weg, jede davon vorzuführen, und ihr gebt sie frei, bevor irgendetwas in eurem Jira oder GitHub landet.
Eure Policy entscheidet, was kanman anfassen, ausgeben und mergen darf. Wenn eine Entscheidung größer ist als seine Befugnis, kommt sie zu euch, mit einer Empfehlung und ein paar konkreten Optionen. Ihr antwortet in der Inbox oder in Slack.
Claude Code oder Codex schreibt den Code in einer Sandbox. kanman wählt das Modell nach Komplexität, damit ein Tippfehler-Fix nicht das Budget eines Refactorings verbrennt.
Bevor irgendetwas ins Review geht, läuft eine Akzeptanz-Spec gegen eine frische Umgebung. Die Spec wurde vor dem Code geschrieben, und der Agent kann sie nicht ändern. Keine Spec, kein Ready. Kein grüner Lauf, kein Review. Mehr dazu im nächsten Beitrag.
Dann bekommt ihr einen Pull Request mit den Belegen im Anhang. Eure Leute reviewen und mergen, oder eure Policy tut es. Jeder Schritt landet in einem Audit-Log, das ihr exportieren könnt.
Euer Tracker bleibt. Eure CI bleibt. Eure Review-Regeln bleiben.
Warum das kein Wettrennen gegen GitHub ist
Ich werde gefragt, ob GitHub oder Atlassian das nicht einfach selbst bauen. Teile davon, sicher. Aber jeder baut es für sein eigenes Tool und seinen eigenen Agenten. Ein Team mit Jira und GitLab, einem Claude-Vertrag und zwei Entwicklern, die lieber Codex nutzen, will nicht drei Meinungen von drei Anbietern darüber, was ein KI-Teammitglied ist.
Und viele Teams, mit denen ich spreche, dürfen ihren Code nicht in die Cloud schicken, die sich ihr Tracker-Anbieter ausgesucht hat. Deshalb läuft kanman in der EU, mit Coding-Sandboxes in Frankfurt, und deshalb kann der Runner in eurem eigenen Netz stehen.
Das Langweilige ist das Produkt
Niemand wird bei Intake-Vorlagen, Policy-Tabellen und Evidence Packs euphorisch. Sie sind so langweilig wie Sicherheitsgurte.
Aber sie entscheiden, ob ein KI-Teammitglied etwas ist, dem ihr echte Arbeit anvertraut, oder etwas, das ihr einmal vorführt und dann still abschaltet.
Der Loop ist Standardware. Das Betriebsmodell nicht.
Ihr wollt ein KI-Teammitglied, das in eurem Tracker arbeitet, nach euren Regeln, und jede Änderung beweist? kanman - Pilot ab 5.000 € für 6 Wochen, Team 990 € pro KI-Team und Monat.
Marco Kerwitz
Founder of kanman.ai