Zum Inhalt springen

KI im Team.
Per Zuruf.
Mit Beweis.

Sagt kanman, was ihr braucht, in der App, in Slack oder in Microsoft Teams. kanman entwirft die Stories, liefert sie über Claude Code oder Codex nach euren Regeln, beweist jede Änderung gegen eure Akzeptanzkriterien und sagt euch, wie es lief. Gehostet in der EU oder auf euren eigenen Servern.
Eine Anforderung der Buchhaltung wird ins Gespräch getippt. kanman entwirft drei Stories mit Akzeptanzkriterien, die freigegeben und in den Tracker geschrieben werden. kanman bittet um die Freigabe des Plans der ersten Story, der Plan wird im Gespräch freigegeben, und der Run besteht jede Prüfung auf einem frischen Checkout. Der Pull Request wird gemerged, und der Wochenbericht fasst die Woche zusammen.

Die Lücke

Alle in eurem Team haben ein KI-Coding-Tool. Niemand hat ein KI-Teammitglied.

Lizenzen für Copilot und Claude Code machen einzelne Entwickler schneller. Sie entscheiden nicht, was gebaut wird, was der Agent anfassen darf oder ob das Ergebnis funktioniert.

  • Niemand macht die Aufnahme.

    Jemand muss Anfragen immer noch in Arbeit übersetzen, die ein Agent zu Ende bringen kann. Vage Tickets rein, vager Code raus.

  • Niemand setzt die Regeln.

    Niemand hat festgelegt, was der Agent anfassen, ausgeben oder mergen darf. Also kann er entweder wenig oder zu viel.

  • Niemand beweist das Ergebnis.

    'Tests sind grün' heißt nicht 'es funktioniert'. Jemand muss prüfen, und im Moment ist das euer bester Reviewer.

So funktioniert's

Vom Gespräch zum geprüften Pull Request

Ihr redet, kanman erledigt den Rest in fünf Stufen. Euer Tracker, eure CI und eure Review-Regeln bleiben, wo sie sind.

  1. 1. kanman Bescheid sagen

    Beschreibt die Arbeit in der App, in Slack oder in Microsoft Teams. kanman fragt nach, was unklar ist, und entwirft Stories mit Akzeptanzkriterien und einem Weg, jedes davon vorzuführen.

  2. 2. Regeln

    Eure Richtlinie legt fest, was kanman anfassen, ausgeben und mergen darf. Große Entscheidungen kommen mit Empfehlung zu euch.

  3. 3. Arbeit

    Claude Code oder Codex schreibt den Code in einer Sandbox. kanman wählt das Modell nach Komplexität, damit kleine Fixes günstig bleiben.

  4. 4. Beweis

    Bevor etwas ins Review geht, läuft eine Akzeptanzspezifikation gegen eine frische Umgebung. Keine Spec, kein Bereit. Kein grüner Durchlauf, kein Review.

  5. 5. Rückmeldung

    kanman sagt euch, dass der Pull Request bereit ist, mit angehängten Nachweisen. Eure Leute reviewen und mergen, oder eure Richtlinie tut es.

Ein komplettes Beispiel ansehen

kanman meldet sich

Es sagt euch, was passiert ist. Und fragt nur, wenn es euch braucht.

Kein Dashboard, das ihr prüfen müsst, kein Status, dem ihr hinterherlauft. kanman schreibt euch in der App, in Slack oder in Microsoft Teams, mit einer Stimme und in wenigen Sätzen.

  • Updates, wenn etwas passiert ist

    Ein Run ist fertig, ein Fehler ist behoben, eine Konvention ist gelernt. Jedes Update verlinkt den Run oder das Nachweispaket. Ist nichts passiert, bleibt es still.

  • Entscheidungen dort, wo ihr lest

    Wenn eure Richtlinie sagt, dass eine Entscheidung zu euch gehört, stellt kanman eine Frage, mit Empfehlung und Optionen. Ihr antwortet direkt dort, in der App oder in eurem Channel.

  • Ein Wochenbericht zum Weiterleiten

    Gemergte Stories, Nacharbeit und Zeit bis zum Review, mit dem Grund hinter jeder Veränderung. Rückfragen stellt ihr in derselben Unterhaltung.

Meldet sich in

  • kanman-App
  • Slack
  • Microsoft Teams
Das Gespräch mit kanman: Updates zu Runs mit Stufe und Kosten, der Nachweis eines fertigen Runs und eine Entscheidung mit kanmans Empfehlung und den Optionen

Beweis

Agents sagen "fertig". kanman zeigt es euch.

Jeder Pull Request kommt mit einem Nachweispaket. Ihr reviewt die Änderung mit dem Wissen, dass sie schon tut, was die Story verlangt.

  • Die Spec entstand vor dem Code.

    kanman schreibt die Akzeptanzspezifikation bei der Aufnahme. Sie muss fehlschlagen, bevor die Story als Bereit gilt.

  • Der Agent kann sie nicht ändern.

    Der Coding-Agent hat keinen Schreibzugriff auf die Spec. Eine geänderte Spec lässt das Gate scheitern.

  • Sie lief auf einem frischen Checkout.

    Nicht auf der Maschine des Agents. Eine frische Umgebung, der Commit des Pull Requests, nichts aus dem Cache.

Nachweispaket eines fertigen Runs: 3 von 3 Akzeptanzkriterien bestanden, die Akzeptanzspezifikation lief in einer frischen Umgebung grün, 14 Tests und CI bestanden, Kosten und Dauer

Seht es an eurem eigenen Repo.

Ein Pilot läuft sechs Wochen mit einem Team und einem Repo. Die Nachweise behaltet ihr so oder so.

Pilot anfragen

Kontrolle

Ihr entscheidet, wie viel es entscheidet.

Presets von Testphase bis Autonom. Budgets mit harten Grenzen. Jede Entscheidung in einem Audit-Log, das ihr exportieren könnt.

Richtlinien-Einstellungen eines Teams: die fünf Presets von Testphase bis Härtung, mit Ausgewogen als Grundlage
kanman fragt im Gespräch, ob der Plan einer Story freigegeben wird, mit kanmans Empfehlung und den Optionen Plan freigeben, Änderungen anfordern und Ablehnen
  • Befugnisstufen

    Pro Repo und Pfad. Was kanman allein ändern darf, was ein Review braucht, was es nie anfasst.

  • Budgets mit harten Grenzen

    Pro Run, pro Tag und pro Monat. Ist ein Budget aufgebraucht, hält kanman an und fragt. Incident-Arbeit wird nie blockiert.

  • Ein Audit-Log zum Exportieren

    Wer hat was entschieden, mit wessen Freigabe, zu welchen Kosten. Bereit für das nächste Audit.

Teamgedächtnis

Es wird jede Woche besser in eurer Codebasis. Und ihr seht, was es gelernt hat.

Review-Kommentare, die sich wiederholen, werden zu Team-Konventionen. Jede davon könnt ihr lesen, ändern und ausmustern.

Herkunft, die ihr nachvollziehen könnt
Jede Konvention verweist auf die Review-Kommentare, aus denen sie entstand.
Ihr bleibt die Redaktion
Regel anpinnen, umformulieren oder ausmustern. kanman folgt der aktuellen Liste.
Die Konventionen eines Teams: die Regel aus drei Review-Befunden, mit ihren Bereichen und den Aktionen Anheften, Bearbeiten und Ausmustern

Passt zu eurem Stack

Euer Tracker bleibt. Eure CI bleibt. Eure Review-Regeln bleiben.

kanman steigt in die Tools ein, die euer Team schon nutzt. Nichts zu migrieren.

  • GitHub: Issues, Pull Requests, Checks
  • GitLab: Cloud und self-managed
  • Jira: Eure Boards, eure Spaltennamen
  • Claude Code: Headless, in einer Sandbox
  • Codex: Headless, in einer Sandbox
  • Slack: Fragen, Wünsche und Entscheidungen in euren Channels
  • Microsoft Teams: Channels, Gruppenchats und Direktnachrichten
  • Confluence und Notion: Antworten aus euren Docs, mit Quellen
  • Eure CI: GitHub Actions, GitLab CI und der Rest
  • Self-hosted Runner: Der Code läuft in eurem Netzwerk
  • kanman-Board: Noch kein Tracker? Die Stories liegen auf dem eigenen Board des Teams
  • MCP: kanman aus Claude Code oder Codex nutzen

Preise

Preis pro KI-Team. Nicht pro Platz.

Startet mit einem Pilot in einem Repo. Behaltet kanman, wenn euch die Nachweise überzeugen.

Pilot

6 Wochen, ein Team, ein Repo. Inklusive Einrichtung mit euch.

ab 5.000 €Festpreis, 6 Wochen
  • Einrichtung mit eurem Team, in eurem Tracker und eurem Repo
  • Ein Pull Request mit dem Akzeptanz-Manifest für euer Repo
  • Ein wöchentlicher Blick auf Runs, Entscheidungen und Kosten
  • Eine schriftliche Auswertung am Ende, die ihr behaltet
Pilot anfragen

Nach dem Pilot

Team

Ein kanman, das mit einem Engineering-Team arbeitet. Monatlich abgerechnet.

990 €pro KI-Team / Monat
  • Aufnahme, Outcome-Gate, Entscheidungen und Audit-Log
  • GitHub, GitLab oder Jira, dazu Slack
  • Claude Code oder Codex in einer Sandbox in Frankfurt
  • Eure eigenen Anbieterschlüssel oder Nutzung zum Selbstkostenpreis plus 15 %
Mit einem Pilot starten

Self-hosted

Der Runner steht in eurem Netzwerk und erledigt die Coding-Arbeit dort, mit euren Modellverträgen.

Sprecht uns an
  • Self-hosted Runner für jede Code-Ausführung
  • Eure Verträge mit Anthropic, OpenAI, Azure oder Bedrock
  • Unterstützung bei AVV und Security-Review
Sprecht uns an

Die Modellnutzung läuft über eure eigenen Schlüssel oder wird über kanman abgerechnet, zum Selbstkostenpreis plus 15 %. Keine Preise pro Platz.

FAQ

Fragen, die Engineering-Leads uns stellen

Kurze Antworten. Jede verlinkt die ausführliche Version.

Etwas fehlt? Schreibt an [email protected]
Was ist der Unterschied dazu, Issues in GitHub oder Linear an Copilot, Claude oder Codex zuzuweisen?
Diese Tools geben ein Issue an einen Agent und liefern einen Pull Request zurück. kanman ergänzt, was um den Agent herum fehlt. Es macht aus Anforderungen Stories mit Akzeptanzkriterien, hält sich an die Richtlinie, die ihr festlegt, und beweist jede Änderung gegen diese Kriterien auf einem frischen Checkout, bevor jemand reviewt. Den Code selbst schreibt weiterhin Claude Code oder Codex. In den Docs lesen (öffnet in einem neuen Tab)
Wie sieht die Arbeit mit kanman im Alltag aus?
Ihr redet mit kanman. Beschreibt die Arbeit in der App, in Slack oder in Microsoft Teams, und kanman entwirft die Stories, arbeitet sie nach den Regeln eures Teams ab und beweist das Ergebnis. Es sagt euch, wenn etwas bereit ist, fragt, wenn eine Entscheidung zu euch gehört, und schickt einen Wochenbericht. Board, Runs und Nachweispakete öffnen sich aus der Unterhaltung, wenn ihr die Details sehen wollt. In den Docs lesen (öffnet in einem neuen Tab)
Müssen wir Jira oder GitHub verlassen?
Nein. kanman arbeitet in eurem Tracker, egal ob GitHub Issues, Jira oder GitLab. Stories, Statuswechsel und Pull Requests erscheinen dort, wo euer Team ohnehin hinschaut. Noch kein Tracker? Ein Team kann seine Stories auf seinem eigenen kanman-Board führen und später einen Tracker verbinden. In den Docs lesen (öffnet in einem neuen Tab)
Welche Modelle und Agents nutzt es? Können wir eigene Verträge nutzen?
Der Code entsteht über Claude Code oder Codex. Ihr könnt eigene Schlüssel für Anthropic, OpenAI, Azure OpenAI oder AWS Bedrock mitbringen oder die Nutzung zum Selbstkostenpreis plus 15 % über kanman laufen lassen. kanman wählt das Modell nach Komplexität, damit kleine Fixes günstig bleiben. In den Docs lesen (öffnet in einem neuen Tab)
Wo wird unser Code verarbeitet und gespeichert? Was sehen die Modellanbieter?
kanman läuft in der EU. Der Code entsteht in Sandboxes in Frankfurt, und jeder Run bekommt eine frische Sandbox, die danach verworfen wird. Modellanbieter sehen die Prompts und den Code-Kontext, die ein Run braucht, unter eurem eigenen Vertrag, wenn ihr eigene Schlüssel nutzt. Mit dem Self-hosted Runner bleibt die Code-Ausführung in eurem Netzwerk. In den Docs lesen (öffnet in einem neuen Tab)
Kann es allein nach main mergen?
Nur wenn eure Richtlinie das erlaubt. Standardmäßig reviewt und merged ein Mensch. Automatische Merges könnt ihr für kleine Änderungen freigeben: alle Gates grün und der Diff unter einer Zeilengrenze, die ihr festlegt. Solange main rot ist, hält kanman sie zurück. In den Docs lesen (öffnet in einem neuen Tab)
Was passiert, wenn es nicht weiterkommt?
Es hält an und fragt. Ihr bekommt eine Entscheidung mit Empfehlung und Optionen, in der App, in Slack oder in Microsoft Teams. Ein gescheitertes Gate bekommt einen Nachbesserungsversuch. Danach kommt es zu euch zurück, statt in einer Schleife zu laufen. In den Docs lesen (öffnet in einem neuen Tab)
Kann kanman für eure Services Rufbereitschaft übernehmen?
Ja, wenn ihr das wollt. Verbindet Uptime-Checks, euer Alarmierungstool (Alertmanager, Grafana, Datadog, PagerDuty, Opsgenie, Sentry, CloudWatch und andere) und eure Logs. Wird etwas schlechter, eröffnet kanman einen Incident in eurem Slack- oder Teams-Kanal, prüft letzte Merges, Deploys und Fehler-Traces und postet, was es findet. Bei einem Fehler im Code startet es einen Fix, der den Fehler zuerst reproduzieren muss, oder schlägt einen Revert vor. Änderungen in Produktion außerhalb des Codes entscheidet immer ein Mensch. Nur beobachten ist ein Schalter. In den Docs lesen (öffnet in einem neuen Tab)
Ist kanman in unseren Slack- oder Microsoft-Teams-Unterhaltungen dabei?
Nur dort, wo ihr es hinzufügt. Es beantwortet Fragen zur Arbeit des Teams mit Links und Quellen und macht aus Wünschen Story-Entwürfe, die eine Teamleitung freigibt, bevor etwas auf das Board kommt. Standardmäßig spricht es nur, wenn ihr es erwähnt. Pro Channel könnt ihr zulassen, dass es sich von selbst meldet, mit Tageslimit, Ruhezeiten und einem Stopp-Button an jeder ungefragten Antwort. In den Docs lesen (öffnet in einem neuen Tab)
Kann es aus unseren Docs, Repos, Confluence oder Notion antworten?
Ja, sobald ein Team es einschaltet. Fügt Dateien, Webseiten, Repository-Dokumentation, Issues, Confluence-Bereiche oder Notion-Seiten hinzu, und kanman nennt in jeder Antwort seine Quellen. Wo die Quelle es verrät, nutzt es nur, was die fragende Person dort sehen darf, etwa Confluence-Seitenrechte oder Repository-Zugriff. Passt nichts, sagt es das. In den Docs lesen (öffnet in einem neuen Tab)
Was kostet der Betrieb, und wie funktionieren Budgets?
Der Team-Plan hat einen festen Preis pro KI-Team, zu finden im Preisabschnitt. Die Modellnutzung kommt dazu, über eure eigenen Schlüssel oder zum Selbstkostenpreis plus 15 %. Ihr setzt Budgets pro Run, pro Tag und pro Monat mit harten Grenzen. Incident-Arbeit wird nie durch ein Budget blockiert. In den Docs lesen (öffnet in einem neuen Tab)
Unser Repo hat keine Akzeptanztests. Können wir trotzdem starten?
Ja. Das Preset Testphase funktioniert ohne Specs und sagt das in jedem Nachweispaket klar. In der ersten Woche öffnet kanman einen Pull Request, der ein Akzeptanz-Manifest ergänzt. Ab dann bekommt jede Story eine Spec. In den Docs lesen (öffnet in einem neuen Tab)
Können wir kanman selbst hosten?
Ja. Der Self-hosted Runner führt jeglichen Code in eurem Netzwerk aus, mit euren Modellverträgen. Schaltet ihr "Alles auf unseren Runnern ausführen" ein, bleiben auch Modellaufrufe, Reviews und jede Repository-Aktion dort; in kanmans Cloud liegen dann nur Board, Entscheidungen und Audit-Log. In den Docs lesen (öffnet in einem neuen Tab)
Wie sieht ein Pilot aus?
Sechs Wochen, ein Team, ein Repo. Wir richten kanman mit euch ein, ergänzen ein Akzeptanz-Manifest, wählen ein Preset und bearbeiten echte Stories aus eurem Backlog. Am Ende bekommt ihr eine schriftliche Auswertung, was geliefert wurde, was Nacharbeit brauchte und was es gekostet hat. Der Pilot im Detail

Blog

Aus dem Blog

Alle Beiträge
ai

Vom Issue zum PR ist Standardware. Das hier nicht.

GitHub, Linear, Jira und OpenAI machen inzwischen alle aus Issues Pull Requests. Der Loop ist gratis. Was eurem Team trotzdem fehlt, ist das Betriebsmodell drumherum: wer die Arbeit schreibt, wer die Regeln setzt und wer das Ergebnis beweist.

Marco Kerwitz

Founder of kanman.ai

ai

Trau keinem Agenten, der "fertig" sagt

Coding-Agenten benoten ihre eigenen Hausaufgaben. kanman lässt sie nicht: Eine Akzeptanz-Spec wird vor dem Code geschrieben, muss vor Arbeitsbeginn fehlschlagen, ist für den Agenten tabu und muss auf einem sauberen Checkout grün sein, bevor jemand zum Review gebeten wird.

Marco Kerwitz

Founder of kanman.ai

ai

Agenten brauchen eine Policy, keinen besseren Prompt

"Bitte nicht das Billing-Modul anfassen" in einem System-Prompt ist keine Regel. Es ist ein Wunsch. kanman ersetzt Wünsche durch eine Policy: Befugnisstufen, Presets, Budgets mit hartem Stopp, Entscheidungen mit Empfehlung und ein Audit-Log, das ihr exportieren könnt.

Marco Kerwitz

Founder of kanman.ai