KI abgestimmt in der Entwicklung aufgreifen
Deine Entwicklungsteams bestehen seit Jahren. Einige experimentieren mit KI, andere verweigern sich. Es entsteht kein abgestimmtes Vorgehen, keine gemeinsame Richtung. Kein neues Team wird gegründet – die Arbeit muss mit den Menschen passieren, die da sind.
Diese Seite schafft eine gemeinsame Sprache für abgestimmtes Vorgehen: Wo im Entwicklungsflow entstehen Feedback-Loops? Und wie reif sind sie? Auf welcher Stufe fängst du an, damit du dich nicht verzettelst?
Wie dieser Rahmen gedacht ist
Der Rahmen hilft, Entwicklung durch die Linse von Feedback-Loops zu betrachten. Nicht als neuer Prozess, den alle übernehmen müssen – sondern als gemeinsame Sprache, damit mehrere Teams abgestimmt agieren können, ohne dass ein Team der Vorturner für alle anderen wird.
- 6 Flow-Phasen – die Orte, an denen Feedback entsteht oder verarbeitet wird
- 4 Reifestufen – wie schnell und effektiv sind diese Loops?
- Patterns als konkrete Hilfen, verortet in Flow und Reife
- Kein Prozess, den alle übernehmen müssen
- Kein Template, das ein Team für alle befuellt
- Keine Standardisierung von oben – aber geteilte Koordinaten
Jedes Team verortet sich selbst, entscheidet, wo es anfängt und welche Patterns es aufgreift. Der Rahmen schafft Sichtbarkeit über Teams hinweg – ohne ein Team zum Vorturner für alle anderen zu machen.
Der Entwicklungsflow
Sechs Phasen, die jedes Entwicklungsvorhaben durchläuft – von der ersten Idee bis zur Produktivsetzung. Der Flow gibt eine gemeinsame Orientierung: Wo greifen wir KI auf und wo nicht? Jeder Touchpoint lässt sich aufklappen – für Details und Quellen.
1Orientierung
Orientierung
Umfeld verstehen, bevor gelöst wird. Welches Problem lösen wir? Wer sind die Beteiligten?
KI als Sparringspartner
Strategie-Entwürfe prüfen, Personas simulieren, Umfeld als Netzwerk erfassen – bevor eine Zeile Code geschrieben wird. KI hilft, blinde Flecken sichtbar zu machen und Alternativen durchzuspielen.
Quelle: BCG: AI in Strategy Development
Process-Redesign Gate
61% der erfolgreichen KI-Projekte hatten vorher Fehlschläge – wegen ungesunder Prozesse, nicht wegen der Technologie. Erst prüfen, ob der Prozess gesund ist, dann KI draufsetzen.
Leaders model Usage
Führung zeigt öffentlich, wie sie KI selbst nutzt – in Reviews, in der Sprint-Planung, im Daily. Das öffnet die Tür für alle anderen Teams.
2Framing
Framing
Das Vorhaben so rahmen, dass KI zielgerichtet arbeiten kann. Kontext schaffen, Grenzen definieren.
Architecture Decision Records
Grundstruktur, Tech-Stack, nicht-funktionale Anforderungen als Teil des Kontextes – nicht als extra Dokument. ADRs werden zum zentralen Steuerungsinstrument für KI-gestützte Entwicklung.
Quelle: ADR GitHub Organisation · Praxisbericht: Shopify Engineering
Platform Before Scale
Bevor breit gerollt wird: LLM-Proxy, MCP-Server, Prompt-Library, Eval-Pipeline als geteilte Infrastruktur aufbauen. Shopify und GitLab berichten, dass Plattform-Investitionen vor der Skalierung der entscheidende Beschleuniger waren.
Quelle: Shopify: Building an AI Platform · GitLab: AI Development Practices
Autonomie-Grad definieren
Was kann die KI eigenständig? Wo muss der Mensch prüfen? Keine generelle Regel, sondern Entscheidung pro Risikoprofil. Das Stanford Enterprise AI Playbook zeigt: Teams mit klaren Autonomie-Regeln sind produktiver als Teams ohne.
3Scoping
Scoping
Was bauen wir? Zwei Ebenen trennen: extern fürs Gespräch, intern für die Maschine.
Externe vs. interne Ebene
Extern: Validierbare Feature-Pakete für Kunden und Stakeholder. Dient dem Gespräch, nicht der Spezifikation. Intern: Kleinteilige Umsetzungsschritte für Agenten – in testbare Commits zerlegt, mit Smoke-Tests und Doku als Teil jedes Schritts.
Human-in-the-Loop platzieren
Security, Backend-Logik, Zahlungsdaten → Mensch prüft. Frontend, Daten-Display, unkritische Features → KI autonom. Rippling setzt dieses gestaffelte Modell erfolgreich ein.
Testbare Commits
Ein Commit pro Funktion, nicht pro drei Features. Mit Smoke-Tests und Doku-Update als Teil des Commits. So bleibt das Repo für Menschen und KI gleichermaßen verstehbar.
4Entwicklung
Entwicklung
KI übernimmt die Umsetzung, der Mensch steuert. Neue Rollen und Verantwortungen entstehen.
Escalation Not Approval
Mach, bis jemand nein sagt. PR-Review wird zum Escalation-Point, nicht zum Gate. Stanford und Shopify berichten von +41% Produktivitätsdelta gegenüber dem klassischen Genehmigungsmodell.
Quelle: Stanford HAI: Enterprise AI Playbook · Shopify Engineering
Domain Experts Build
Sales baut Prospect-Analyse, Finance baut Dashboards – Nicht-Entwickler erstellen mit KI eigene Tools auf der Plattform. Shopify und Lemkin zeigen: Domain-Experten bauen bessere Fachlösungen als reine Entwicklerteams.
Quelle: Lenny's Podcast: 50+ AI Deployments · Shopify Engineering
Commit-Disziplin
Ein Commit pro Funktion, nicht pro drei Features. Mit Smoke-Tests und Doku-Update als Teil des Commits. Hält das Repo für KI und Menschen gleichermaßen navigierbar.
5Evaluierung
Evaluierung
Stimmt, was gebaut wurde? Drei Rückmelde-Ebenen: automatisch, kontextuell, menschlich.
Smoke-Tests + autom. Validierung
Automatisierte Validierung gegen Personas, nicht-funktionale Checks und Smoke-Tests als Teil jedes Commits. Die Maschine prüft zuerst – der Mensch entscheidet nur bei Auffälligkeiten.
Measure What Breaks
Shopify misst nicht Velocity, sondern Reversion-Rate. Wenn etwas häufig zurückgenommen werden muss, stimmt was am Prozess nicht. Quality under Speed wird zur Leitmetrik.
Szenarien mit Entscheidungsalternativen
Gezielt vorbereitete Szenarien mit Entscheidungsalternativen. Feedback provozieren, nicht erbitten. Partner und Stakeholder bekommen konkrete Optionen, über die sie entscheiden können.
6Produktivsetzung
Produktivsetzung
Ausliefern, betreiben, übergeben. Das Repo muss für Menschen und KI gleichermaßen verstehbar sein.
Governance parallel aufbauen
Worker-Access wächst +50%, Governance hält nicht mit. Deloitte und McKinsey zeigen: Governance muss eigene Spur sein – nicht Checkpoint am Ende. Parallel zur Entwicklung aufbauen.
Quelle: Deloitte: AI Governance · McKinsey: State of AI 2025
Repo als übergabefähiger Kontext
Change Log, Architektur-Doku, Backlog-Historie – alles im Repo, nicht in Köpfen. KI-lesbar für nahtlose Übergabe zwischen Teams und Agenten.
Quality under Speed
Nicht-deterministische Features brauchen Production-Monitoring ab Tag 1. Qualitätsstabilität als Metrik, nicht Velocity – Shopify und Lenny's Podcast berichten übereinstimmend.
Quelle: Lenny's Podcast: 50+ AI Deployments · Shopify Engineering
Quellen: Stanford Enterprise AI Playbook, Shopify Engineering, GitLab, Duolingo, Rippling, Lemkin Sales Agents, Lenny's Podcast (50+ AI Deployments), McKinsey State of AI 2025, Deloitte State of AI 2026
Landkarte: Wo wirken welche Patterns?
Eine Karte hilft mehr als eine Beschreibung. Hier siehst du auf einen Blick: Welche Patterns wirken auf welcher Stufe in welcher Flow-Phase?Finde deine Position – und was als nächstes dran sein könnte. Jedes Pattern lässt sich aufklappen.
| Orientierung | Framing | Scoping | Entwicklung | Evaluierung | Produktivsetzung | |
|---|---|---|---|---|---|---|
| Stufe 1 Rahmen schaffendirekter Nutzen + Nebeneffekt | LLM als ReflexionspartnerRAG ist der erste Schritt: Dokumentation, Code, Entscheidungen werden erschlossen. Der eigentliche Hebel ist aber, LLMs aktiv zum Mitdenken zu nutzen – das Vorhaben hinterfragen, blinde Flecken aufzeigen, Optimierungspotential vorschlagen. Nicht nur „wo finde ich das?“ sondern „was übersehen wir?“ Konkrete Arbeitsweisen folgen. | Context Engineering aufsetzenDen Arbeitsrahmen aktiv gestalten: nichtfunktionale Anforderungen als automatisch geprüfte Checks, erste Regeln wann/welche Infos aufgegriffen werden, einfache Agenten für wiederkehrende Aufgaben. Ziel: fokussiert in die Entwicklung kommen, statt jedes Mal neu über den Rahmen nachzudenken. Konkrete Arbeitsweisen folgen. | Subziel-Pipeline aufbauenVom Gesamtvorhaben die nächsten Etappen ableiten: Was ist das nächste Subziel, auf das wir die Entwicklung ausrichten? Welches Team nimmt welches Thema mit? – eine klare Pipeline, aus der argumentierbar ist, wer woran arbeitet. Das Runterbrechen in Tasks bleibt im Sprint Planning der Teams. Konkrete Arbeitsweisen folgen. | Erste Metrik einführenEine einfache Zahl, die etwas über die Qualität der Arbeit sagt – und die das Team selbst beeinflussen kann. Reversion-Rate, Dauer im Review, was immer gerade schmerzt. Konkrete Arbeitsweisen folgen. | Automatisierte NF-EvaluierungAus dem Context Engineering ergeben sich automatische Checks: nichtfunktionale Anforderungen werden vom System geprüft, nicht von Menschen. Parallel: Ergebnisse so aufbereiten, dass sie mit Stakeholdern und Nutzern „sprechen“ – anschaulich, nachvollziehbar, entscheidbar. Konkrete Arbeitsweisen folgen. | Läuft es stabil?Die einfachste Form von Production-Readiness: Hält das, was wir bauen? Standardkriterien, die jedes Team nutzen kann. Konkrete Arbeitsweisen folgen. |
| Stufe 2 Optimieren stimulierenaktive Perturbation gegen Trägheit | Reflexionsroutine einfordernNicht dabei stehenbleiben, dass Einzelne LLMs als Reflexionspartner nutzen. Sondern einfordern: Teams sollen regelmäßig zeigen, was sie durch LLM-gestützte Reflexion über ihr Vorhaben gelernt haben. „Was hat dir die KI gezeigt, was du vorher nicht gesehen hast?“ – das schärft den Blick fürs Mögliche. Konkrete Arbeitsweisen folgen. | Rahmen gemeinsam schärfenTeams sollen selbst evaluieren: Funktioniert unser Context Engineering? Fehlen nichtfunktionale Checks? Sind die Agenten hilfreich oder störend? – und daraus ableiten, wie der Rahmen weiterentwickelt werden muss. Nicht von aussen verordnen, sondern aus der Erfahrung schärfen. Konkrete Arbeitsweisen folgen. | Priorisierung einfordernDie Teams sollen selbst begründen: Warum genau dieses Subziel als nächstes? Wie passt es ins Gesamtvorhaben? Welches Team kann es autonom umsetzen? – die Argumentation zwingt zur Einordnung und schafft Transparenz über die Ausrichtung. Konkrete Arbeitsweisen folgen. | Kontrollfragen statt KontrolleNicht selbst prüfen, ob Qualitätskriterien eingehalten werden, sondern die Frage an das Team zurückgeben: „Woran erkennst du, dass das gut genug ist?“ Die Verantwortung fürs Einordnen liegt bei denen, die bauen. Konkrete Arbeitsweisen folgen. | Evaluierungsergebnisse aufbereitenDie automatisierte NF-Evaluierung liefert Daten. Jetzt geht es darum: Teams sollen daraus „sprechende“ Ergebnisse machen – visualisiert, kontextualisiert, für Stakeholder und Nutzer verständlich. Nicht „wir haben bestanden“ sondern „das bedeutet das für die nächste Entscheidung“. Konkrete Arbeitsweisen folgen. | Übergabe gestalten lassenNicht selbst übergeben, sondern das Team die Übergabe gestalten lassen: „Was muss das nächste Team wissen, um weiterzumachen?“ Das zwingt zur Struktur und schafft geteilte Verantwortung. Konkrete Arbeitsweisen folgen. |
| Stufe 3 Konstellationen neu denkenkleinere Teams, übergreifender | Wer denkt mit?Wenn LLMs als Reflexionspartner etabliert sind: Wer gestaltet diese Systeme? Wer trainiert sie auf das relevante Wissen? Wer entscheidet, welche Perspektiven sie einbringen sollen? Neue Rollen entstehen – nicht als Admin, sondern als „Reflexionsarchitekt“, der das Mitdenken kuratiert. Konkrete Arbeitsweisen folgen. | Geteilten Kontext etablierenWenn mehrere Teams Context Engineering betreiben: Wer teilt welche Agenten? Welche nichtfunktionalen Checks gelten teamübergreifend? Welche Infos müssen alle haben? – geteilte Agenten und wiederverwendbare Context-Vorlagen entstehen, ohne dass jedes Team von vorne anfängt. Konkrete Arbeitsweisen folgen. | Themen auf Konstellationen verteilenWenn Teams kleiner und spezialisierter werden: Welche Konstellation nimmt welches Subziel? Wer hat die nötigen Fähigkeiten? Wer muss zusammenarbeiten? – die Pipeline wird zur Verteilungslogik, nicht nur zur Priorisierung. Konkrete Arbeitsweisen folgen. | Temporäre Rollen besetzenNeue Team-Konstellationen brauchen temporäre Rollen: jemand, der die Plattform kennt, jemand, der die Qualitätskriterien im Blick hat, jemand, der die Verbindung zu anderen Teams hält. Befristet, nicht fest. Konkrete Arbeitsweisen folgen. | Teamübergreifende EvaluierungWenn mehrere Konstellationen parallel arbeiten: Wer evaluiert was? Wie werden Ergebnisse vergleichbar? Welche NF-Checks gelten über Teamgrenzen hinweg? – gemeinsame Evaluierungsstandards entstehen, die nicht von oben kommen, sondern aus der Praxis der Teams. Konkrete Arbeitsweisen folgen. | Hilfskonstrukte statt neuer StrukturBevor eine neue Rolle oder Abteilung geschaffen wird: Was würde dem Team kurzfristig helfen? Temporärer Austausch, rotierende Moderation, geteiltes Pad für Patterns – reversibel, leichtgewichtig. Konkrete Arbeitsweisen folgen. |
| Stufe 4 Takt verkürzen2 Wo. → 1 Wo. → kontinuierlich | Mitdenken ist InfrastrukturReflexionssysteme sind in Stufe 4 so selbstverständlich wie die Entwicklungsumgebung. Orientierung heisst nicht mehr „Information beschaffen“ sondern „Interpretation aushandeln“. Die LLMs liefern Perspektiven, das Team entscheidet. Sprint-Rhythmen werden zum Engpass, weil die Reflexion kontinuierlich läuft, nicht zyklisch. Konkrete Arbeitsweisen folgen. | Context Engineering automatisiertDer Rahmen passt sich selbst an: Agenten erkennen, wann neue nichtfunktionale Anforderungen nötig sind, Context wird aus vergangenen Entscheidungen automatisch angereichert, Evaluierung läuft im Fluss. Framing ist keine Vorbereitungsphase mehr, sondern läuft kontinuierlich mit. Konkrete Arbeitsweisen folgen. | Subziele im Fluss justierenWenn der Takt kürzer wird, muss auch die Pipeline dynamischer werden: Subziele werden nicht mehr pro Sprint festgelegt, sondern kontinuierlich justiert. Die Frage ist nicht „was schaffen wir im nächsten Sprint?“ sondern „was ist das wertvollste nächste Ziel, das ein Team autonom verfolgen kann?“ Konkrete Arbeitsweisen folgen. | Ohne Takt arbeiten könnenDer konsequenteste Schritt: Sprints ganz auflösen in kontinuierlichen Flow. Dazu braucht es Vertrauen in autonome Entscheidungen, stabile Qualitätssicherung im Fluss und geteilte Verantwortung. Ehrliche Reflexion: Haben wir das wirklich? Oder würden wir ohne Takt in Chaos fallen? Konkrete Arbeitsweisen folgen. | Evaluierung im FlussAutomatisierte NF-Checks und sprechende Ergebnisse sind der Normalfall. Evaluierung ist kein separater Schritt mehr, sondern läuft parallel: Stakeholder haben jederzeit Zugriff auf aktuelle Ergebnisse, das System meldet Abweichungen, Teams justieren im Fluss nach. Konkrete Arbeitsweisen folgen. | Reflexion ohne TerminWenn der Sprint als Reflexions-Anker wegfällt, braucht es andere Rhythmen: tägliche kurze Einordnung, wöchentlichen Rückblick, abteilungsübergreifenden Austausch – nicht getaktet von aussen, sondern als Gewohnheit aus dem Team heraus. Konkrete Arbeitsweisen folgen. |
So liest du diese Karte: Jede Zelle zeigt Patterns, die auf einer bestimmten Stufe in einer bestimmten Flow-Phase wirken. Die Patterns in Stufe 1 sind kein lästiges Fundament – sie lösen echte Probleme und stärken als Nebeneffekt den gemeinsamen Lernrahmen. Leere Zellen bedeuten nicht „Fehler“, sondern: auf dieser Stufe liegt der Fokus dort noch nicht. Finde deine Position.
Selbstcheck: Wo steht mein Team?
Vier Fragen – eine pro Stufe. Je nachdem, wo du ja sagst, weisst du, wo du anfangen kannst.
Stufe 1: Haben wir einen Rahmen?
- Wir haben Patterns aus den besten Teammitgliedern als Agent-Training verfügbar gemacht.
- Wir messen Qualität unter Geschwindigkeit (Reversion-Rate statt Velocity).
- Wir haben abgestufte Approval-Stufen (Produktion / Prototyping / Fast-Track).
- Führungskräfte zeigen öffentlich, wie sie KI selbst nutzen.
Stufe 2: Stimulieren wir Optimierung?
- Wir prüfen vor jedem KI-Einsatz, ob der zugrundeliegende Prozess gesund ist.
- Wir haben eine gemeinsame Plattform (Proxy, Prompt-Library, Eval-Pipeline) vor dem breiten Rollout aufgebaut.
- Unser Kontrollmodus ist Eskalation statt Genehmigung.
- Unsere Definition of Done berücksichtigt non-deterministische Ergebnisse (Monitoring ab Tag 1).
Stufe 3: Denken wir Konstellationen neu?
- Wir entscheiden Autonomie nicht generell, sondern pro Risikoprofil der Funktion.
- Nicht-Entwickler haben Zugang zur Plattform und bauen eigene Tools.
- Neue Rollen (AI Ops, Quality Stewards) entstehen organisch.
- Governance ist in Team-Konstellationen integriert, nicht als externe Kontrollinstanz.
Stufe 4: Können wir den Takt erhöhen?
- Genehmigungs-Gates sind abgebaut – wir arbeiten im Eskalationsmodell.
- Unsere Qualitäts-Metrik gibt Sicherheit: Wir wissen, wann wir schneller werden können.
- Agenten könnenautonome Schritte ohne Human-Loop machen – trainiert auf unseren besten Playbooks.
- Sprints werden kürzer oder lösen sich auf – kontinuierliches Lernen ersetzt synchronisierte Zyklen.
Weiterführend
- AI Operating Model: Bausteine einer KI-Arbeitslogik – Die Frage „wohin wollen wir?“ im Detail.
- AI-native Organisation: Was ändert sich wirklich? – Wenn KI nicht nur Werkzeug, sondern Betriebssystem der Organisation wird.
Quellen dieser Seite:Session Praxisaustausch 2026-06-11 (PO in Zeiten von AI), Stanford Enterprise AI Playbook, Shopify Engineering Blog, GitLab, Duolingo, Rippling Engineering, Lemkin Sales Agents, Lenny's Podcast (50+ AI Deployments), McKinsey State of AI 2025, Deloitte State of AI 2026