Ratgeber
KI-Workflow für Start-ups: wie ein kleines Team mit KI arbeitet, ohne sich zu überschreiben
Sobald mehr als eine Person mit KI am selben Produkt arbeitet, entstehen Probleme, die es solo nicht gibt: kollidierende Stände, unsichtbare Entscheidungen, veralteter Kontext. Die Antwort ist kein neues Tool, sondern eine Teamstruktur — Rollen, Entscheidungsrechte, geteilter Kontext und Review-Verantwortung.
Wofür dieser Guide ist — und wofür nicht
Dieser Guide richtet sich an Teams von etwa zwei bis zehn Personen, die KI-Werkzeuge im Produktalltag einsetzen. Er beantwortet eine Frage: Wie organisieren mehrere Menschen ihre KI-gestützte Arbeit so, dass Stände nicht kollidieren und Entscheidungen nachvollziehbar bleiben?
Was im Team anders ist als solo
Ein Solo Founder wechselt zwischen Rollen, aber alles läuft durch einen Kopf: Er kennt jede Entscheidung, jeden Stand und jeden Chat-Verlauf. Im Team zerbricht genau diese implizite Konsistenz — an drei Stellen:
- Entscheidungen sind nicht mehr automatisch sichtbar. Was Person A gestern mit ihrem KI-Sparring entschieden hat, weiß Person B nicht — es sei denn, es steht an einem verbindlichen Ort.
- Kontext divergiert. Jede Person füttert ihre KI-Sessions mit ihrer eigenen Version des Projektstands. Ohne gemeinsame Quelle driften die Versionen auseinander, und die KI-Ergebnisse mit ihnen.
- Parallele Arbeit kollidiert. Zwei Menschen — oder ihre Coding-Agenten — ändern dieselben Dateien. Einer gewinnt, die Arbeit des anderen verschwindet still.
Alle drei Probleme sind Strukturprobleme, keine Toolprobleme. Ein weiteres KI-Werkzeug löst keines davon; klare Rollen, ein gemeinsamer Stand und Isolationsregeln lösen alle drei.
Rollen und Entscheidungsrechte
Im Solo-Workflow sind Rollen Arbeitsphasen. Im Team sind sie etwas Schärferes: Entscheidungsrechte. Es muss vorab klar sein, wer Scope festlegt, wer innerhalb des Scopes frei umsetzt, wer einen Stand abnimmt und wer den gemeinsamen Kontext fortschreibt. Vier Verantwortungen reichen für die meisten kleinen Teams — eine Person kann mehrere davon halten, nur Autor und Reviewer derselben Aufgabe sollten nie dieselbe Person sein:
Tabelle horizontal scrollen, um alle Spalten zu sehen.
| Verantwortung | Kümmert sich um | Entscheidet | KI-Einsatz |
|---|---|---|---|
| Product Owner | Scope, Prioritäten, Nicht-Ziele | Was gebaut wird und was nicht | Sparring zu Strategie und Scope; Entscheidung bleibt menschlich |
| Implementer | Umsetzung im zugewiesenen Bereich | Wie innerhalb des Scopes umgesetzt wird | Coding-Agent im isolierten Arbeitsbereich, eng eingegrenzt |
| Reviewer | Unabhängige Prüfung fremder Arbeit | Ob ein Stand die Qualitäts-Gates erfüllt | anderes Modell/andere Instanz als die Umsetzung; Mensch trägt das Urteil |
| Context Keeper | Projektstand, Entscheidungslog, Regeln | Wann der gemeinsame Stand aktualisiert wird | KI fasst zu, Mensch bestätigt — nie ungeprüft zurückschreiben |
Funktionen, keine Stellenbezeichnungen — in einem Zwei-Personen-Team hält jede Person zwei Verantwortungen.
Gemeinsamer Kontext als Single Source of Truth
Solo genügt es, den Projektkontext als Datei zu führen, damit jede KI-Session aus demselben Stand startet — das beschreibt der Guide KI-Projektkontext aufbauen. Im Team kommt eine Bedingung dazu: Es darf nur eine verbindliche Version geben, und es muss klar sein, wer sie fortschreibt.
Bewährt hat sich ein kleiner Satz gemeinsamer Dateien im Repository: ein Projektkontext (worum es geht,
aktueller Stand), ein Entscheidungslog (was wann warum entschieden wurde) und Projektregeln für die
KI-Werkzeuge selbst — gängige Coding-Agenten laden solche Regel-Dateien wie CLAUDE.md oder
AGENTS.md automatisch als Arbeitsanweisung. Weil diese Dateien im Repository liegen,
versioniert Git sie mit: Jeder sieht, was sich geändert hat, und niemand arbeitet mit einem heimlich
veralteten Stand.
Der häufigste Fehler ist nicht das Fehlen dieser Dateien, sondern Context Drift: Die Arbeit läuft weiter, die Dateien bleiben stehen. Deshalb gehört das Statusupdate als fester Schritt an das Ende jedes Task-Loops (unten) — und der Context Keeper hat das letzte Wort, wann der gemeinsame Stand als aktualisiert gilt.
Der Team-Task-Loop
Der Kern des Workflows ist ein wiederholbarer Durchlauf von der Entscheidung bis zum gemergten Stand. Jede Phase hat eine verantwortliche Rolle und ein Gate, das vor dem nächsten Schritt geprüft wird:
Tabelle horizontal scrollen, um alle Spalten zu sehen.
| Phase | Verantwortlich | Input | Output | Gate |
|---|---|---|---|---|
| Entscheidung | Product Owner | Problem, Prioritäten | Decision Record mit Begründung | Entscheidungsrecht beachtet? |
| Aufgabe zuschneiden | Product Owner + Implementer | Decision Record | Eingegrenzte Aufgabe mit erlaubtem Bereich | Scope und Schutzzonen benannt? |
| Zuweisung | Team | Aufgabe | Eine Person + ein KI-Werkzeug pro Arbeitsbereich | Kein zweiter Akteur im selben Bereich? |
| Isolierte Umsetzung | Implementer + KI | Aufgabe, gemeinsamer Kontext | Stand auf eigener Branch/Worktree | Nur erlaubte Dateien geändert? |
| Review | Reviewer (nicht der Autor) | Diff + Aufgabe | Bestätigter oder zurückgewiesener Stand | Unabhängig geprüft, Tests grün? |
| Merge + Statusupdate | Implementer + Context Keeper | Bestätigter Stand | Aktualisierter Projektstand | Gemeinsamer Stand schriftlich nachgezogen? |
Welche Phasen ein einzelnes Mensch-KI-Paar innerhalb seiner Aufgabe durchläuft, beschreibt der Solo-Founder-Workflow — dieser Loop regelt das Zusammenspiel darüber.
Parallel arbeiten ohne Überschreiben
Parallelität ist der größte Geschwindigkeitsvorteil eines Teams — und ohne Isolation seine größte Fehlerquelle. Drei Regeln verhindern das stille Überschreiben:
- Ein Akteur pro Arbeitsbereich. Pro Aufgabe arbeitet genau ein Mensch-KI-Paar in einem benannten Bereich. Zwei Aufgaben, die dieselben Dateien brauchen, laufen nacheinander — oder der Scope wird neu geschnitten.
- Isolation über Branches oder Worktrees. Jede Aufgabe bekommt ihren eigenen Arbeitsstand. Coding-Agenten arbeiten nie direkt auf dem gemeinsamen Hauptstand; zusammengeführt wird erst nach bestandenem Review.
- Schutzzonen explizit benennen. Bereiche, die eine andere Aufgabe gerade bearbeitet oder die generell heikel sind (Zahlung, Recht, Konfiguration), stehen in der Aufgabenbeschreibung als nicht berührbar — für den Menschen und für sein KI-Werkzeug.
Diese Regeln gelten unabhängig davon, wie autonom die Werkzeuge arbeiten. Wer zusätzlich Agenten mit mehr Eigensteuerung einsetzen will, braucht darüber hinaus Stop-Regeln und Berechtigungsgrenzen — das behandelt der Guide KI-Agenten für Start-ups.
Review-Verantwortung und Konfliktlösung
Wer prüft was
Die Solo-Regel „nicht dasselbe Modell schreibt und prüft" wird im Team zur Personalregel: Nicht dieselbe Person erstellt und reviewt einen Stand. Der Reviewer nutzt dabei gern KI-Unterstützung — idealerweise ein anderes Modell als das des Autors —, aber die Verantwortung für die Abnahme trägt ein Mensch. Was genau geprüft wird, steht vorher fest: die Gates aus dem Task-Loop, nicht der Geschmack des Reviewers.
Wenn zwei Stände kollidieren
Kollisionen passieren trotzdem. Dann gilt eine einfache Rangfolge: Erst entscheidet der Decision Record — welcher Stand setzt die dokumentierte Entscheidung um? Gibt es keinen passenden Record, wurde eine Entscheidung nie explizit getroffen: Sie wird jetzt vom Product Owner nachgeholt und dokumentiert, erst danach wird technisch aufgeräumt. Was nie passieren sollte: dass der zuletzt gemergte Stand „gewinnt", weil niemand hingeschaut hat.
Typische Fehler im Team-Workflow
- Jede Person pflegt ihren eigenen Projektkontext — die KI-Ergebnisse driften auseinander.
- Entscheidungen leben in privaten Chat-Verläufen statt in einem gemeinsamen Log.
- Zwei Mensch-KI-Paare arbeiten gleichzeitig im selben Dateibereich.
- Autor und Reviewer sind dieselbe Person — mit demselben Modell.
- Der gemeinsame Stand wird „später" aktualisiert und veraltet still (Context Drift).
- Konflikte entscheidet der letzte Merge statt der dokumentierten Entscheidung.
- Schutzzonen sind mündlich vereinbart, stehen aber in keiner Aufgabenbeschreibung.
Als Daumenregel für den Einstieg: Beginnt mit den Rollen und dem Entscheidungslog — das kostet eine Stunde und beseitigt die häufigsten Kollisionen. Isolation und Review-Gates folgen mit der ersten parallelen Aufgabe. Wie beim Solo-Workflow gilt: Die Struktur muss nicht vollständig stehen, bevor sie nützt.
Häufige Fragen
Ab welcher Teamgröße lohnt sich dieser Workflow?
Ab der zweiten Person, die regelmäßig mit KI am selben Produkt arbeitet. Genau dann entstehen die Probleme, die es solo nicht gibt: zwei Stände kollidieren, Entscheidungen sind nicht für alle sichtbar, niemand weiß, welcher Kontext aktuell ist. Die Struktur wächst mit — ein Zwei-Personen-Team braucht dieselben Regeln in kleinerer Form.
Worin unterscheidet sich das vom Solo-Founder-Workflow?
Der Solo-Workflow ordnet die Phasen von der Idee bis zum ersten Verkauf für eine Person, die alle Rollen nacheinander spielt. Dieser Guide behandelt die Probleme, die erst mit mehreren Menschen entstehen: Entscheidungsrechte, geteilter Kontext, Übergaben zwischen Personen, Review-Verantwortung und parallele Arbeit ohne Überschreiben.
Brauchen wir dafür KI-Agenten mit hoher Autonomie?
Nein. Der Workflow funktioniert mit gewöhnlichen Chat- und Coding-Werkzeugen. Ob ein Schritt zusätzlich autonomer laufen soll, ist eine eigene Entscheidung mit eigenen Regeln — die behandelt der Guide zu KI-Agenten für Start-ups. Erst die Teamstruktur, dann die Autonomiefrage.
Was passiert, wenn zwei Personen widersprüchliche Stände produzieren?
Dann entscheidet nicht, wer lauter ist oder zuletzt gemergt hat, sondern der Decision Record: Welcher Stand setzt die dokumentierte Entscheidung um? Fehlt ein passender Record, ist der Konflikt ein Zeichen, dass eine Entscheidung nie explizit getroffen wurde — sie wird nachgeholt, dann wird aufgeräumt. Verhindern lässt sich das meist vorher durch getrennte Arbeitsbereiche.
Muss eine Person hauptamtlich den Kontext pflegen?
Nein — Context Keeper ist eine Verantwortung, keine Vollzeitrolle. In kleinen Teams übernimmt sie oft der Product Owner mit. Wichtig ist nur, dass genau eine Person das letzte Wort darüber hat, wann der gemeinsame Stand aktualisiert wird, damit nicht mehrere Versionen der Wahrheit entstehen.