SHIFT to AI Blog

Wenn KI die Silos in deinem Team auflöst

2026-04-13T00:00:00Z

In Workshops fällt mir auf, dass es spannend wird, wenn es nicht mehr um Produktivität, nicht um Lines of Code, nicht um Prompt-Tricks geht, sondern darum, welche Fragen Entwickler beginnen zu stellen. Wenn Menschen sich öffnen und wachsen.

Ein Backend-Entwickler, der seit Jahren in seinem Bereich arbeitet, fängt auf einmal zögerlich an, über den Business-Impact einer API-Entscheidung nachzudenken, weil die KI ihm Kontext liefert, den er vorher nicht auf dem Schirm hatte. Eine Frontend-Entwicklerin beginnt, Fragen zur Datenmodellierung zu stellen, weil sie bei der KI-gestützten Arbeit sieht, wie die Teile zusammenhängen.

Das ist keine Kleinigkeit! In vielen Teams sind diese Grenzen über Jahre gewachsen. Backend redet mit Backend. Frontend mit Frontend. Product mit Product. Jeder kennt seinen Bereich, niemand guckt drüber. Nicht aus Desinteresse, sondern weil der Alltag es nicht hergibt.

Diese ganz nette Anekdote hat jetzt eine Studie mit Daten unterfüttert, die mir Hoffnung gibt.

Was bei Procter & Gamble passiert ist

Das Team von Dell‘Acqua et al., 2025, von Harvard Business School und Wharton hat bei Procter & Gamble ein Feldexperiment durchgeführt, das dieses Phänomen direkt untersucht. Die Studie ist ein „NBER Working Paper“, also kein Peer-Reviewed Journal, aber methodisch ganz solide aufgestellt: 776 Professionals, randomisierte Zuweisung, verblindete Evaluatoren, pre-registriertes Design. Das Setup: Profis aus R&D und Commercial arbeiteten einen Tag an Produktinnovations-Aufgaben, entweder allein oder als Zweier-Team, jeweils mit und ohne KI-Zugang. Die Qualität wurde von Fachleuten bewertet, die nicht wussten, wer unter welchen Bedingungen gearbeitet hatte.

Drei Befunde sind für uns relevant.

Ohne KI produzierten R&D-Leute eher technische Lösungen und Commercial-Leute eher marktnahe. Klare funktionale Silos, wie man es erwarten würde. Mit KI verschwand dieser Unterschied weitgehend. Beide Gruppen generierten ausbalanciertere Lösungen, die sowohl technische als auch kommerzielle Aspekte abdeckten.
Eine Einzelperson mit KI erreichte ein Qualitätsniveau, das dem eines Zweier-Teams ohne KI entsprach (+0,37 SD vs. +0,24 SD über der Baseline). Das heißt nicht, dass Teams überflüssig werden — dazu gleich mehr. Aber es zeigt, dass KI den Output einer Person auf ein Niveau heben kann, das vorher Zusammenarbeit erforderte.
Zweier-Teams mit KI produzierten die meisten Top-10%-Lösungen — dreimal so häufig wie die Kontrollgruppe. Die Kombination Mensch + Mensch + KI schlug alle anderen Konfigurationen bei Spitzenleistungen.

Das war nur ein eintägiger Ideation-Workshop bei einem einzelnen Unternehmen und keine Langzeitstudie über Software-Engineering-Alltag. Man kann daraus nichts handfestes ableiten, dafür braucht man ein anderes Test-Setup, aber man kann das als Datenpunkt und Inspiration mitnehmen.

Was das für Software-Teams bedeutet

Die Studie untersucht zwar keine Softwareentwickler, sondern R&D- und Commercial-Profis, aber das Grundmuster finden wir bei uns auch: funktionale Silos gibt es auch bei uns, und die lassen sich durch KI vielleicht auflösen, oder zumindest öffnen.

Hier ein paar Ideen; nichts davon geschieht magisch oder automatisch. Man muss sich beim Prompten schon noch die Mühe geben, nicht bloß nach einem Fix für 10 Zeilen Code zu fragen. Aber in der Teamkultur ließe sich so etwas dergestalt etablieren, dass man persönliche blinde Flecken immer wieder mal aufgedeckt bekommt:

Backend denkt Frontend mit

Wenn ein Backend-Entwickler mit KI an einem Feature arbeitet, schlägt die KI Kontexte vor, die über den eigenen Scope hinausgehen; Vorschläge, die Frontend-Implikationen berücksichtigen, API-Design-Entscheidungen anders rahmen, oder Teststrategien vorschlagen, die er allein nicht in Betracht gezogen hätte.

Der Entwickler entscheidet weiterhin, was davon relevant ist. Aber sein Blickfeld hat sich erweitert.

Dev denkt Business-Impact mit

Das ist für mich der spannendste Transfer aus der Studie. Wenn ein Backend-Entwickler durch die KI dazu kommt, auch den Long-Term-Value einer technischen Entscheidung mitzudenken — eine Frage, die ihm persönlich vielleicht nicht liegt — dann hat das ganze Team gewonnen. Die KI ersetzt nicht die Product-Perspektive. Aber sie macht den Entwickler zu einem besseren Gesprächspartner für Product und Business. Welche Auswirkungen auf die Serverlast und Kostenstruktur hat die neue API? Was könnte man anders gestalten, um heute schon effizienter zu fahren und Kunden attraktivere Angebote machen zu können?

Ein Entwickler, der im Sprint Planning nicht nur die technische Machbarkeit beurteilt, sondern auch eine informierte Meinung zum Business-Kontext einbringt, verändert die Qualität der Diskussion. Das ist kein Alleinstellungsmerkmal von KI-Tools. Gute Teamkultur bewirken das gleiche. Aber KI senkt die Schwelle, weil der Kontext verfügbar wird, ohne dass man ihn sich vorher aneignen muss.

Entwicklern wird leichter gemacht, zwischendurch auch mal aus dem Kaninchenbau herauszugucken. Das Tagesgeschäft und technische Detailwissen liegt im Fokus, aber zwischendurch schaut man sich um, bevor man sich wieder vergräbt.

Die Regisseur-These

Wer den ganzen Stack überblickt (von der Planung über die Architektur bis zur Implementierung) hat mit KI den größten Hebel. Das ist meine Beobachtung aus der Arbeit mit Entwicklern, die als Selbstständige oder Tech Leads den gesamten Produktionsprozess verantworten. Das sehe ich in kleinen Teams, in denen ich mitarbeite, und in meiner eigenen Arbeit als unabhängiger Entwickler jeden Tag.

Wenn Code zunehmend selbst zum Kompilat wird — generiert aus Specs und Kontext statt Zeile für Zeile getippt — dann verschiebt sich die wertvolle Arbeit weg von der Implementierung, hin zu den Entscheidungen davor: Was bauen wir? Warum? Welche Constraints gelten? Das sind Fragen, die über Abteilungsgrenzen hinausgehen.

KI macht aus Spezialisten keine Generalisten. Aber sie erweitert den Kontext, in dem Spezialisten denken und entscheiden.

Was das für Teamstruktur bedeutet — und was nicht

Die naheliegende Reaktion auf „Einzelperson + KI = Team-Qualität“ wäre: Dann brauchen wir keine Teams. Das wäre eine Fehlinterpretation.

Die Studie zeigt auch: Teams mit KI liefern die besten Spitzenleistungen. Die Kombination aus menschlicher Zusammenarbeit und KI-Unterstützung schlägt alle anderen Konfigurationen, wenn es um die besten Ergebnisse geht — nicht nur um den Durchschnitt. Das heißt: KI ersetzt Teamarbeit nicht.

Die interessantere Frage ist nicht „Wie viele Leute brauchen wir?“, sondern „Wie teilen wir die Arbeit zwischen Mensch und KI auf — und was bedeutet das für die Zusammenarbeit im Team?“

Kent Beck erwähnte im Pragmatic Summit 2026, dass langsame LLMs prima für Pair Programming sind: Man hat genug Zeit, sich über nächste Schritte zu unterhalten. Wenn Antworten zu schnell kommen, muss man die Pausen selber machen. Wie alle Vorteile vom Pair Programming der letzten Jahrzehnte ist auch hier der Mehrwert in der menschlichen Abstimmung, wenn zwei Köpfe mit eigenen Geschmäckern, Ideen, Erfahrungen aufeinandertreffen und sich arrangieren und fördern. Dann kommt dazu noch ein Arbeitswerkzeug, um das Gespräch am Laufen zu halten und das Ausprobieren im Code abzugeben.

Wenn funktionale Silos durchlässiger werden, weil jeder mit KI-Unterstützung einen breiteren Kontext hat, dann verändert sich, worüber man im Team reden muss. Weniger „Erklär mir, was dein Teil macht“ und mehr „Lass uns zusammen entscheiden, was die richtige Lösung ist.“ Das erfordert aber auch, dass das Team darauf vorbereitet ist.

Von Skeptiker zu Anwender: Warum KI-Tools im Team scheitern, und was hilft

2026-04-08T00:00:00Z

Die Tools, die wir haben, sind gut genug, um produktiv zu arbeiten: bei Claude Code, Codex, und Cursor sind die aktuellen Modelle in der Lage, produktionsreifen Code zu generieren, Tests zu schreiben, und Refactorings durchzuführen. Trotzdem nutzen in vielen Engineering-Teams, mit denen ich spreche, nur ein oder zwei Leute die Tools regelmäßig und nicht bloß sporadisch. Der Rest hat es probiert und wieder gelassen, gar nicht erst angefangen, oder denkt alle paar Wochen einmal daran, einen Prompt auszuprobieren.

Das Muster ist immer dasselbe, und es liegt fast nie an der Technik.

Wenn ihr KI-Tools im Team einführen wollt und dabei auf Widerstand stoßt, ist das kein Zeichen dafür, dass euer Team das Thema nicht versteht. Es ist ein Zeichen dafür, dass die Einführung anders laufen muss.

Warum Entwickler skeptisch gegenüber KI-Tools sind

Skepsis gegenüber KI-Coding-Tools ist kein Defizit. In den meisten Fällen ist sie gut begründet, aber veraltet oder auf das falsche Problem gerichtet. Drei Muster sehe ich regelmäßig:

Veraltete Erfahrungen

Jemand im Team hat vor einem Jahr GPT-4 getestet. Der generierte Code war fehlerhaft, die Vorschläge passten nicht zum Stack, das Ergebnis war enttäuschend. Seitdem ist das Thema abgehakt.

Das Problem: Die Modelle von heute sind nicht ein bisschen besser — sie sind fundamental anders. Was vor zwölf Monaten nicht funktioniert hat, funktioniert jetzt. Aber diese Erkenntnis kommt nicht durch Lesen von Release Notes. Sie kommt durch Ausprobieren auf echtem Code. Und genau dafür fehlt den meisten Teams der Rahmen.

Die Identitätsfrage

Wer seit 15 Jahren hochqualifiziert Software entwickelt, will sich nicht sagen lassen, dass eine Maschine das jetzt besser kann. Die Reaktion ist menschlich und nachvollziehbar.

Der Fehler liegt in der Rahmung: KI-gestützte Entwicklung bedeutet nicht, dass die KI den Entwickler ersetzt. Es bedeutet, dass der Entwickler ein mächtiges Werkzeug dazubekommt, das er steuern und dessen Ergebnisse er beurteilen muss.

Es ist ein Hebel — zum Guten wie zum Schlechten. Das erfordert Erfahrung und Urteilsvermögen. Genau die Qualitäten, die erfahrene Entwickler mitbringen.

Deswegen zeige ich in Workshops nicht, was die KI kann. Ich zeige, was der Entwickler mit der KI kann. Das ist ein entscheidender Unterschied.

Qualitätsangst: Das Vibe-Coding-Problem

Die dritte Sorge ist berechtigt und konkret: Wenn jemand blind generieren lässt, ohne den Output zu lesen und zu testen, kommt Müll in die Codebase. Slop. Code, den niemand versteht, den niemand warten kann, der die Reviews nicht besteht.

Diese Angst ist kein Widerstand gegen KI. Sie ist gesunder Qualitätsanspruch. Die Antwort darauf ist nicht „hab weniger Angst“, „stell dich nicht so an“, sondern ein Prozess: geschlossene Feedback-Loops, in denen der Agent generiert, testet, reviewt und korrigiert und der Entwickler steuert und entscheidet. Das ist eine Kompetenz, die man lernen muss. Und die man lernen kann.

Warum die üblichen Einführungsansätze nicht funktionieren

Wenn ich mit Engineering-Leads über KI-Adoption spreche, höre ich ähnliche Strategien. Keine davon funktioniert zuverlässig.

Strategie 1: Rundmail mit Tool-Link

Die IT stellt Copilot-Lizenzen oder Claude API Keys bereit. Eine Mail geht raus, zum Beispiel: „Ab sofort steht euch GitHub Copilot zur Verfügung. Probiert es aus.“ Was dann passiert: Zwei Leute aktivieren es. Einer davon nutzt es nach zwei Wochen noch. Der Rest hat die Mail gelesen und weitergearbeitet wie bisher.

Warum: Ohne konkreten Anlass, ohne Anleitung und ohne Erwartung an das Ergebnis gibt es keinen Grund, den eigenen Workflow zu ändern. Verfügbarkeit ist nicht Adoption.

Strategie 2: Stunden freistellen

Der gut gemeinte Ansatz: „Nehmt euch freitags eine Stunde und experimentiert mit den Tools.“ Das Ergebnis ist selten besser. Wenn ich nicht weiß, was ich in der Stunde tun soll — welche Aufgabe, welches Tool, welcher Workflow — dann mache ich das, was ich eh machen muss. Die Stunde verschwindet im Tagesgeschäft.

Was fehlt, ist Struktur. Nicht Zeit, sondern ein Rahmen: konkrete Aufgabe, konkretes Tool, konkretes Ergebnis.

Strategie 3: Pilotprojekt ohne Begleitung

Manchmal wird ein kleines Team als Pilotgruppe ausgewählt. Anfangs gibt es Enthusiasmus, erste Erfolge, interessante Entdeckungen. Nach drei bis vier Wochen flacht die Nutzung ab. Der anfängliche Schwung trägt nicht, weil niemand die Erfahrungen systematisiert, die Workflows dokumentiert oder die Stolperstellen aus dem Weg räumt.

Die Pilotgruppe fällt auf alte Muster zurück. Die Ergebnisse gehen weit auseinander: von der weitgehenden Automatisierung eines Backend-Prozesses über PMs, die ihre Tickets halbautomatisch in eine Pipeline bekommen, bis zu kaum Nutzung im Frontend. Der Rest des Teams hat nie angefangen.

Was stattdessen funktioniert, um KI-Tools im Team einzuführen

Aus meiner Erfahrung gibt es vier Elemente, die den Unterschied machen zwischen „wir haben es probiert“ und „wir arbeiten jetzt so“.

Gemeinsames Arbeiten an echten Aufgaben

Kein Sandbox-Projekt und keine Spielwiese. Das Team arbeitet mit den KI-Tools an Aufgaben, die es sowieso erledigen muss: Bugfixes, Refactorings, Feature-Implementierungen, Test-Erweiterungen. Auf der eigenen Codebase, im eigenen Stack.

Der Effekt: Jeder sieht sofort, ob das Ergebnis für den Fall brauchbar ist. Kein hypothetisches „das könnte nützlich sein“, sondern ein konkretes „dieser Pull Request ist damit entstanden, und er besteht die Review“. Das ist überzeugender als jede Demo.

Den Entwickler in den Mittelpunkt stellen

Der häufigste Fehler in KI-Einführungen: Es wird gezeigt, was das Tool kann.

Die richtige Frage ist: Was kann dieser Entwickler mit diesem Tool? Welche seiner wiederkehrenden Aufgaben werden schneller, gründlicher oder weniger monoton?

Wenn ein erfahrener Backend-Entwickler sieht, dass er mit einem strukturierten Prompt in zehn Minuten einen vollständigen Testfall schreiben kann, für den er sonst dreißig Minuten braucht — und das Ergebnis seine eigenen Qualitätsstandards erfüllt — dann braucht er keine Überzeugungsarbeit mehr. Er hat es selbst erlebt.

Geschlossene Feedback-Loops

Generieren allein ist wertlos. Der Wert entsteht im Loop: generieren, testen, reviewen, korrigieren. Jeder Schritt hat klare Kriterien. Das Team einigt sich auf Regeln: Welche Prüfungen muss KI-generierter Code bestehen? Wie sieht eine Review-Checkliste aus? Wann wird manuell nachgebessert?

Diese Regeln machen den Unterschied zwischen kontrollierter Nutzung und dem Vibe-Coding, vor dem sich erfahrene Entwickler zu Recht fürchten. Sie geben Sicherheit, ohne die Produktivität zu bremsen.

Klare Regeln statt „Probiert mal aus“

Teams brauchen Vereinbarungen: Welche Aufgaben eignen sich für KI-Unterstützung? Welche nicht? Wie sieht der Workflow aus — vom Prompt über die Generierung bis zur fertigen Review? Welche Regeln gelten?

Ein Team-Playbook, das diese Fragen beantwortet, gibt Orientierung. Nicht als Vorschrift von oben, sondern als gemeinsame Übereinkunft. Der Unterschied: „Probiert mal aus“ erzeugt Unsicherheit. „So arbeiten wir damit“ erzeugt Routine.

Der Unterschied zwischen Einführung und Nutzung

Tool installiert ist nicht Tool genutzt. Tool genutzt ist nicht Workflow verändert. Diese drei Stufen werden regelmäßig verwechselt.

Viele Teams bleiben auf Stufe eins stehen: Die Lizenz ist da, das Plugin ist installiert, technisch funktioniert alles. Aber im Arbeitsalltag ändert sich nichts, weil niemand den Schritt vom installierten Tool zum integrierten Workflow gemacht hat.

Die Frage, die ich Engineering-Leads stelle: „Nutzt dein Team den vereinbarten KI-Workflow diese Woche?“ Nicht: „Haben alle Zugang?“ Nicht: „Hat jemand es schon ausprobiert?“ Sondern: Gibt es einen Workflow, auf den sich das Team geeinigt hat? Und wird er tatsächlich genutzt?

Wenn die Antwort „Nein“ oder „Weiß ich nicht“ lautet, dann fehlt nicht das Tool. Dann fehlt die Einführung.

Genau hier liegt der Kern: KI-Adoption ist kein Technologieproblem. Es ist ein Change-Problem. Die Tools sind bereit. Die Frage ist, ob dein Team es auch ist — und ob die Einführung so gestaltet ist, dass sie funktioniert.

Der nächste Schritt

Wenn du KI-Tools in deinem Team einführen willst und dabei auf die beschriebenen Muster stößt, gibt es zwei Wege:

Für dein Team: Der KI Coding Sprint Workshop ist der beste Einstieg, wenn du als Lead ein ganzes Team produktiv mit KI-Tools aktivieren willst. An einem halben Tag arbeitet dein Team an echten Aufgaben — danach habt ihr den Rahmen, die Workflows und die Regeln, die bei der Selbsteinführung fehlen. Buche einen Fit-Call, und wir klären in 20 Minuten, ob das Format zu deiner Situation passt.

Für den Anfang (als Einzelperson): Wenn du selbst erst einmal sicher werden willst, bevor du das Thema ins Team trägst, ist ein 1:1 Coaching der schnellste Einstieg. 90 Minuten auf deinem echten Code — danach weißt du, welche Workflows für dich funktionieren, und kannst dein Team danach gezielt aufbauen. Buche eine Session.

Was ein KI Coding Sprint Workshop bringt — und was nicht

2026-04-02T00:00:00Z

Sichtbare Ergebnisse in 7–14 Tagen. Das Versprechen klingt schwer einhaltbar: Wenn dein Team schon Copilot-Lizenzen hat und trotzdem kaum jemand die Tools produktiv nutzt, hast du gelernt, dass Technik allein nichts ändert. Genau deshalb funktioniert ein KI-Coding-Workshop anders, als du vielleicht erwartest: nicht als Tool-Demo, sondern als halber Tag gemeinsame Arbeit an echten Aufgaben aus eurem Projekt — mit einem klaren Plan für die Wochen danach. Sichtbar heißt dabei: konsistentere Prompt-Qualität im Team, ein gemeinsamer Review-Standard für KI-assistierte PRs und eine messbare Nutzungsrate des vereinbarten Workflows.

Dieser Artikel beschreibt transparent, was in einem Sprint Workshop passiert, was dein Team danach in der Hand hat — und wo die Grenzen liegen. Einschließlich der Situationen, in denen dieser Workshop die falsche Intervention ist.

Was vorher passiert: das Vorgespräch

Bevor der Workshop stattfindet, gibt es ein 30-minütiges Vorgespräch. Nicht als Formalität, sondern weil ein KI-Coding-Workshop nur dann funktioniert, wenn die Aufgaben passen.

In diesem Gespräch klären wir drei Dinge:

Stack und Constraints. Welche Sprachen, Frameworks und Tools setzt dein Team ein? Gibt es Einschränkungen, etwa Compliance-Anforderungen, die bestimmte Daten aus Prompts ausschließen? Arbeitet das Team mit TypeScript und React, mit Java-Backend-Services, mit Python-Datenpipelines? Die Antwort bestimmt, welche Prompt-Muster und Workflows wir im Workshop einsetzen.

Teamziele. Was soll sich nach dem Workshop konkret ändern? Weniger Reibung bei Code-Reviews? Schnellere Bearbeitung von Routineaufgaben? Ein gemeinsamer Standard, wie KI-generierter Code ins Repository kommt? Ohne ein greifbares Ziel bleibt jeder Workshop eine Veranstaltung ohne Wirkung.

Aufgabenauswahl. Wir wählen gemeinsam 3 bis 5 echte Aufgaben aus dem aktuellen Backlog — Bugfixes, Refactorings, Testergänzungen, Feature-Implementierungen. Keine Spielbeispiele. In einem typischen Team sind das z. B. ein Test-Fix, ein kleiner Refactor, ein Bug im Endpoint und eine Routine-Implementierung. Die Teilnehmer arbeiten im Workshop an Code, den sie nächste Woche ohnehin anfassen würden.

Das Vorgespräch dauert eine halbe Stunde und ist im Paketpreis enthalten. Danach wissen beide Seiten, ob der Sprint das richtige Format ist — oder ob ein anderer Einstieg sinnvoller wäre. Wenn ich im Vorgespräch merke, dass das Hauptproblem nicht fehlender Workflow ist, sondern z. B. ungeklärte Toolfreigaben oder fehlende Engineering-Disziplin, sage ich das offen.

Der Workshop-Tag: vier Stunden, drei Blöcke

Der Sprint Workshop ist ein halber Tag. Vier Stunden, vor Ort oder remote, für 5 bis 15 Teilnehmer. Kein Folienvortrag. Die Teilnehmer arbeiten vom ersten Block an mit ihrem eigenen Code. Vier Stunden reichen, um einen gemeinsamen Arbeitsmodus zu etablieren und erste Ergebnisse zu produzieren — aber nicht, um Governance-Probleme zu lösen. Dafür gibt es das SHIFT Programm.

Block 1: Prompt-to-Code-Zyklen

Jeder Teilnehmer nimmt eine der vorbereiteten Aufgaben und arbeitet sie KI-gestützt durch. Nicht „generiere mir eine Funktion“, sondern ein strukturierter Zyklus: Aufgabe definieren, Scope eingrenzen, Prompt formulieren, Output prüfen, korrigieren. Ich zeige dabei Muster, die sich in der Praxis bewährt haben — etwa wie du einen Bugfix so promptest, dass der Diff kontrollierbar bleibt:

Pattern: Django-Bugfix (begrenzter Diff)

Files in scope: warehouse/views.py, warehouse/tests/test_views.py
Out of scope: Models, Migrations, Serializer, Utility-Funktionen.

Fix: Fehlerhafte Bestandsberechnung im Endpoint — Teileingänge werden nicht korrekt abgezogen.

Output: Plan (max 5 Punkte), View-Änderungen, Test-Updates, Risiko-Hinweis.

Reviewer-Erwartung: Sofort ablehnen, wenn Model-Layer berührt oder Migration vorgeschlagen wird.

Drei Prinzipien stecken dahinter, die unabhängig vom Stack funktionieren: Erstens, deklariere den Scope explizit — welche Dateien rein dürfen und welche nicht. Zweitens, definiere Ausschlüsse vor dem ersten Prompt, nicht erst beim Review. Drittens, formuliere die Erwartung an den Output so, dass ein Reviewer sofort entscheiden kann. Das Team kann nach dem ersten Block Diff-Grenzen explizit setzen und Review-Erwartungen vor dem ersten Prompt festhalten.

Block 2: Refactor-, Test- und Review-Workflows

Im zweiten Block geht es um die Arbeitsschritte, die nach der Codegenerierung kommen — und die in der Praxis oft fehlen. Wie prüft das Team KI-generierten Code systematisch? Wie sehen Tests aus, die echtes Verhalten beschreiben statt nur „renders correctly“? Wie entscheidet ein Reviewer, ob ein KI-assistierter PR den Standards entspricht?

Hier entstehen die ersten gemeinsamen Regeln. Nicht von mir vorgegeben, sondern vom Team erarbeitet — weil nur Regeln, die das Team selbst formuliert, im Alltag überleben. Der Wert externer Moderation liegt dabei nicht in besserem Fachwissen, sondern im Blick von außen: Ich sehe die blinden Flecken, die ein interner Staff Engineer übersieht, weil er selbst im Alltag steckt.

Block 3: Teamroutine definieren

Der dritte Block macht den Unterschied zwischen einem Workshop und einer nachhaltigen Veränderung. Das Team beantwortet gemeinsam: Welche Aufgaben sind ab sofort KI-first? Wo bleibt manuelles Arbeiten sinnvoller? Wie sieht unsere Review-Checkliste aus? Wer ist Ansprechperson, wenn etwas nicht funktioniert?

Das Ergebnis ist eine knappe Seite mit Teamregeln — mit konkreten Vereinbarungen, auf die sich alle geeinigt haben.

Was dein Team mitnimmt

Innerhalb von 48 Stunden nach dem Workshop erhält dein Team drei Dokumente. Jedes ist direkt an eine Alltagssituation gekoppelt:

Das Team-Playbook (1 Seite). Die gemeinsam definierten Regeln als Referenz, nicht als Vorschrift. Dein Team greift darauf zurück, wenn beim nächsten PR die Frage aufkommt: War das so abgemacht? Darin stehen Vereinbarungen wie diese:

Regel 4: Review-Checkliste (Pflicht)

Scope deklariert: betroffene Dateien und explizit ausgeschlossene Dateien

Keine ungewollten Refactors, Model-Rewrites oder Style-Churn

Akzeptanzkriterien im PR übernommen und erfüllt

Tests vorhanden — oder begründet, warum nicht

Risiko-Notiz: eine wahrscheinliche Regressionsquelle benannt

Das ist kein generisches Template. Die Regeln entstehen aus den Aufgaben, die dein Team im Workshop bearbeitet hat, und aus den Diskussionen, die dabei aufkamen.

Prompt-Muster. Wiederverwendbare Prompt-Templates für Bugfixes, kleine Refactors, Test-Ergänzungen und Review-Vorbereitung — zugeschnitten auf den Stack deines Teams. Keine abstrakten Beispiele, sondern Muster, die im Workshop an echtem Code funktioniert haben.

Der 30-Tage-Aktivierungsplan. Eine Checkliste mit konkreten Aktionen für die ersten vier Wochen — damit die Ergebnisse des Workshops nicht am Montag danach versanden. Woche 2 sieht zum Beispiel so aus:

Workflow auf mindestens 4 weitere Aufgaben anwenden (Mix: 2x Backend, 1x Task-Queue, 1x Datenpipeline). Erste Standards-Stichprobe auf 6 KI-assistierte PRs. Ein abgelehntes Diff-Beispiel dokumentieren und im Team teilen — warum es gescheitert ist.

Der Plan ist darauf ausgelegt, dass dein Team die Adoption selbst vorantreibt — ohne externe Begleitung für den Start. Aber er funktioniert nur, wenn jemand die Verantwortung dafür übernimmt. Wenn niemand im Team die 30 Tage aktiv einfordert, bringt der beste Plan wenig.

Was der Sprint Workshop nicht ist

Keine Zertifizierung. Es gibt kein Zertifikat und keinen Abschluss. Das Ergebnis ist ein getesteter gemeinsamer Arbeitsmodus — kein Zertifikat, sondern ein belastbarer Startpunkt.

Keine Tool-Demo. Wir schauen nicht gemeinsam zu, was ein KI-Tool kann. Dein Team arbeitet selbst damit — an echten Aufgaben, mit echtem Code.

Kein Governance-Programm. Der Sprint aktiviert dein Team. Wenn du langfristige Standards, Guardrails und regelmäßige Reviews brauchst, ist das SHIFT Programm der passende nächste Schritt. Wenn euer Hauptproblem Compliance, Freigaben oder eine zentrale Tool-Policy ist, reicht dieses Format nicht.

Kein Selbstläufer. Der Workshop gibt deinem Team die Werkzeuge und den Plan. Aber wenn niemand den 30-Tage-Plan umsetzt, bleiben die Ergebnisse auf dem Papier. Aus meiner Erfahrung funktioniert die Verankerung dann, wenn mindestens eine Person im Team die Rolle des internen Champions übernimmt — jemand, der die vereinbarten Workflows in den ersten Wochen aktiv einfordert.

Für wen der Sprint passt — und für wen nicht

Passt, wenn:

Euer Engineering-Team (5 bis 30 Entwickler) KI-Tools bisher nur ad hoc nutzt — einzelne probieren, aber es gibt keinen gemeinsamen Workflow. Die Untergrenze liegt bei 5, weil unter dieser Teamgröße ein 1:1 Coaching effizienter ist. Ab 30 Personen wird die Workshop-Dynamik zu breit für einen halben Tag.
Du als Tech Lead, Engineering Manager oder CTO messbare Ergebnisse und klare Regeln brauchst, nicht nur Begeisterung
Euer Team mit gängigen Sprachen arbeitet (TypeScript, Python, Java, Kotlin, Go, Rust)
Du schnelle Ergebnisse brauchst: erste Veränderung in 7–14 Tagen, nicht in 6 Monaten

Passt nicht, wenn:

Du eine Einzelperson ohne Teamkontext bist — dann ist 1:1 Coaching der bessere Einstieg
Du eine vollständige Eigenentwicklung von KI-Tools suchst — der Sprint führt bestehende Tools ein, entwickelt keine neuen
Deine Branche strenge regulatorische Anforderungen hat, die über Standard-Datenschutz hinausgehen (Medizin, Finanzaufsicht)
Euer Hauptproblem fehlende Engineering-Disziplin ist, nicht fehlender KI-Workflow — dann ist ein Workshop das falsche Werkzeug

Mehr über den Change-Prozess bei KI-Adoption erfährst du in „Von Skeptiker zu Anwender“.

Der nächste Schritt

Der Einstieg ist ein Fit-Call: 20 Minuten, remote, ohne Verpflichtung. Wir klären, wo dein Team steht, was du erreichen willst und ob der Sprint Workshop das passende Format ist. Wenn nicht, sage ich dir das.

Fit-Call buchen (20 Min.)

Alternativ: Schau dir zunächst die Playbook- und Checklisten-Beispiele an — beide Dokumente zeigen, was dein Team konkret mitnimmt.

Bevor du Code schreibst: Warum ich Greenfield-Projekte mit einem Requirements Analyst starte

2026-03-31T00:00:00Z

Ich starte kein neues Projekt mehr ohne ein Gespräch mit einem Requirements Analyst.

Nicht mit einem Menschen; mit einem KI-Agenten, der als einzige Aufgabe hat, mir die Fragen zu stellen, die ich sonst überspringe, und die Antworten zu hinterfragen:

Wer nutzt das eigentlich?
Was genau erwarten die?
Was passiert im Fehlerfall?
Welche Annahmen mache ich gerade, die ich nicht ausgesprochen habe?

Klingt so lange banal, bis man merkt, dass man auf die Hälfte davon in der Praxis gar keine klare Antwort hat.

Das Problem: Direkt in den Code, direkt in die Sackgasse

Die meisten Projekte starten so: Feature-Idee, technische Architektur im Kopf, Plan klingt plausibel, und los. Mit einem Frontier-Modell geht das sogar erschreckend schnell und in einer Stunde steht ein funktionierender Prototyp.

Aber dann fängt die eigentliche Arbeit an. Jede Anforderung, die vorher nur implizit im eigenen Kopf existiert hat, kommt als Mikro-Entscheidung zurück. Der Agent fragt nach, oder schlimmer: er entscheidet still und du merkst es erst beim Review. Dann steckst du im Human-in-the-Loop-Modus fest, steuerst jeden Schritt manuell, und die anfänglichen Produktivitätsgewinne gehen in den Aufräumarbeiten wieder verloren.

Auch in Zeiten von Agentic Engineering gilt die Maxime: Zwei Wochen programmieren ersparen einem fünf Minuten Nachdenken.

Der Kern des Problems ist nicht technisch. Es ist, dass wir als Entwickler gewohnt sind, direkt in Lösungen zu denken.

Als Handwerker denken wir mit den Händen. Unser Handwerk besteht darin, mit Sorgfalt in kleinen Inkrementen eine Annäherung an die Lösung durchs Programmieren zu finden. Es ist verführerisch, das mit einem langen Hebel durchzubeschleunigen. Aber dann fehlt die persönliche Verarbeitungstiefe, die Pausen und die kleinen Fragen im Prozess, wenn wir als Hebel KI benutzen und alle kleinen Feedbackschleifen des Handwerks abgeben. Wir lernen dabei nicht und kriegen erst das Zwischenergebnis präsentiert.

Technische Architektur, Datenmodelle, API-Design — das ist unsere Komfortzone. Die Frage „Was will der Nutzer eigentlich, und woran messen wir Erfolg?“ fühlt sich dagegen nach Projektmanagement an. Also überspringen wir sie.

Die Lösung: Ein Agent, der die Nutzerperspektive vertritt

Mein Workflow hat jetzt einen Schritt davor. Bevor eine Zeile Code entsteht, führe ich ein Gespräch mit einem KI-Agenten, der als Requirements Analyst auftritt. Der Agent stellt strukturierte Fragen, arbeitet sich durch neun Phasen — von der Projektvision über Stakeholder und funktionale Anforderungen bis zu Priorisierung und Akzeptanzkriterien — und produziert am Ende ein REQUIREMENTS.md-Dokument.

Das Dokument geht dann an den nächsten Agenten: einen Solution Architect, der daraus eine technische Spezifikation baut. Erst danach wird implementiert.

Der entscheidende Punkt: Der Requirements Analyst darf keine Lösungen vorschlagen. Er definiert das Was und das Warum, nicht das Wie. Das zwingt mich, die Anforderungen sauber durchzudenken, bevor die technische Architektur sie einengt.

Wie der Agent entstanden ist

Die Idee, Agenten in Rollen aufzuteilen — Analyst, Architect, Developer, Reviewer — stammt aus Emmz Rendles Talk „How I Tamed Claude“ auf der NDC London. Ich habe den Ansatz aufgegriffen und für meinen Workflow angepasst. Das klang alles so seltsam einfach, das musste ich einmal ausprobieren. Für mich hat dieser Fund ganz andere Workflows erst freigeschaltet.

Das Überraschende dabei: Der System Prompt für den Requirements Analyst entstand aus einem einzigen Satz. Ich habe Claude folgendes geschrieben:

Create a system prompt document for a Requirements Analyst that gathers information and asks questions to produce a REQUIREMENTS.md document that a Solution Architect can use to design the solution and plan the implementation.

Daraus hat Claude einen vollständigen Agenten generiert — mit neun Discovery-Phasen, Gesprächsrichtlinien, Scope-Management und einem strukturierten Output-Template. Den Prompt habe ich danach iteriert und angepasst, aber die Grundstruktur kam aus dieser einzigen Anweisung.

Vorher hatte ich keine klare Vorstellung davon, was ich bekommen würde. Erst nach den ersten Durchläufen konnte ich gezielt Anpassungen vornehmen. Gerade diese erste Version, fast nur aus dem im Modell vorhandenen Wissen erzeugt, war schon überraschend brauchbar.

Das Muster, das sich wiederholt: Du beschreibst die Rolle und die erwartete Ausgabe, und das Modell füllt die Struktur. Du musst nicht jede Phase selbst entwerfen — du musst wissen, was du brauchst. Und dann lernst du daraus und machst es beim nächsten Mal vielleicht noch genauer.

Was der Agent konkret tut

Der von Claude (Opus 4.5) generierte System Prompt und damit der Agent arbeitet sich durch neun Phasen, von breit nach tief. Ein paar Highlights, damit du ein Gefühl bekommst:

Phase 1 — Projektkontext & Vision. Bevor es um Features geht: Was bauen wir, warum, und woran messen wir Erfolg? Der Agent fragt nach Business-Motivation, bestehendem System, und Zieltermin. Das sind die Fragen, die ein erfahrener Berater in den ersten 10 Minuten stellt, und die wir als Entwickler gerne überspringen, weil wir die Antwort zu kennen glauben.

Phase 3 — Funktionale Anforderungen. Für jede Capability fragt der Agent nach Trigger, Inputs, erwarteten Outputs, Geschäftsregeln und Edge Cases. Das zwingt dich, Workflows durchzudenken, statt nur Features aufzulisten. (Beim Schreiben fällt mir auf, wie unangenehm der Mix aus deutscher Prosa mit englischen Bruchstücken wird, weil ich aus meinen englischen Artefakten zitiere — wenn du auf Deutsch denkst und arbeitest, schreib deinen System Prompt vielleicht auch direkt auf Deutsch!)

Phase 7 — Constraints & Annahmen. Der für mich wertvollste Teil: „Welche Annahmen machen wir gerade, die, wenn sie falsch sind, die Anforderungen signifikant ändern würden?“ Diese Frage allein hat mir bei meinem letzten Projekt zwei Wochen Korrekturen erspart.

Pro Phase stellt der Agent 2–4 fokussierte Fragen, paraphrasiert die Antworten zur Bestätigung, und eskaliert Widersprüche oder Lücken. Wenn ich auf eine Frage keine Antwort habe, schlägt er sinnvolle Defaults vor oder markiert den Punkt als offen.

Das klingt nach viel Aufwand. Ist es nicht. Ein typisches Gespräch dauert 15–30 Minuten. In einzelnen Fällen kann es länger dauern, wenn sehr viel Kontext zusammenkommt oder die Antworten besonders ausführlich ausfallen. Plane also lieber 30 Minuten plus etwas Puffer ein.

Danach habe ich ein Dokument, das die meisten Fragen beantwortet, die sonst während der Implementierung aufgetaucht wären — nur ohne den Kontext, sie dann noch sauber zu beantworten.

Was sich verändert hat

Seit ich diesen Schritt eingebaut habe, hat sich vor allem eins geändert: Die Arbeit lässt sich besser abgeben. Wenn die Anforderungen klar dokumentiert sind, kann der Solution Architect (auch ein Agent) eine technische Spec bauen, die ein Entwicklungs-Agent direkt umsetzen kann. Die Kette wird länger, aber jeder Schritt wird kürzer und vorhersagbarer.

Vorher war ich bei jeder Entscheidung der ad-hoc-Flaschenhals. Zum limitierenden Faktor wurde ich vor allem deshalb, weil mein Gedächtnis nicht perfekt ist und ich über Tage hinweg kein konsistentes Nudging leisten kann. Das klappt besser in klaren Intervallen: Denken — Planen — Implementieren.

Jetzt bin ich der Flaschenhals nur noch bei den Fragen, die wirklich mein Urteil brauchen — und die beantworte ich, bevor der erste Agent mit dem Code anfängt.

Den Prompt ausprobieren

Den vollständigen System Prompt als Markdown kannst du hier herunterladen: ANALYST.md

Speicher die Datei und starte den Agenten mit Claude, Codex, oder pi bspw. so:

$ claude --system-prompt-file ANALYST.md
$ codex --config developer_instructions="$(cat ANALYST.md)"
$ pi --system-prompt "$(cat ANALYST.md)"

Der Prompt enthält neben den neun Discovery-Phasen auch Gesprächsrichtlinien (wie der Agent mit Unklarheiten umgeht, wie er Scope Creep einfängt), ein Output-Template für das REQUIREMENTS.md-Dokument, und eine klare Grenzziehung: Der Agent darf keine Lösungen vorschlagen — er definiert das Problem, nicht die Architektur.

Der größere Workflow

Der Requirements Analyst ist der erste Schritt in einer längeren Kette. Der vollständige Workflow, den ich aktuell nutze:

Requirements Analyst — klärt Anforderungen, produziert REQUIREMENTS.md
Solution Architect — liest REQUIREMENTS.md, entwirft technische Spezifikation, produziert SPEC.md
Developer — implementiert nach SPEC.md, test-driven, in kleinen atomaren Commits
Reviewer — prüft Änderungen gegen SPEC.md, produziert COMMENTS.md, Loop zurück zum Developer

Jede Rolle hat einen eigenen (System) Prompt und läuft in einem eigenen Kontext. Über die einzelnen Rollen und wie sie zusammenspielen schreibe ich in den nächsten Wochen mehr. Der Requirements Analyst ist der Einstieg, weil er den größten Hebel hat: Einmal vorher konkret werden spart Tage an Korrekturen danach.

Reviewbare Diffs: Wie du den Scope in KI-Prompts kontrollierst

2026-03-25T00:00:00Z

Das größte Problem mit KI-generiertem Code ist nicht die Qualität, sondern der Scope.

Du promptest einen Bugfix und bekommst den Bugfix – plus ein Refactoring der Nachbardatei, eine geänderte Import-Struktur und einen neuen Utility-Helper, den niemand verlangt hat. Der eigentliche Fix sind drei Zeilen. Der Diff hat 180.

Das passiert nicht, weil das Modell schlecht ist. Es passiert, weil der Prompt keinen Scope deklariert. Ohne explizite Grenzen optimiert ein LLM auf das, was es für eine Verbesserung hält — und das schließt alles ein, was es im Kontext sieht.

Das Pattern: Scope deklarieren, Ausschlüsse definieren

In meiner täglichen Arbeit mit Claude Code hat sich ein Muster bewährt, das dieses Problem löst. Es ist einfach eine Prompt-Struktur, die du in jede Aufgabe einbauen kannst.

Vergiss nicht: Am Ende ist alles, was ein Coding-Agent bekommt, Text. Ein frischer Kontext und klare Anweisungen helfen enorm.

Das Muster besteht aus vier Teilen:

Files in scope. Benenne explizit, welche Dateien der Agent anfassen darf. Nicht „das Modul“, sondern die konkreten Pfade.
Out of scope. Benenne explizit, was nicht angefasst werden darf. Das klingt redundant — ist es nicht. Ohne Ausschlüsse interpretiert das Modell deinen Scope großzügig.
Erwarteter Output. Beschreib, was am Ende rauskommen soll: ein Plan, Code-Änderungen, Tests, eine Risiko-Notiz. Wenn du das nicht definierst, entscheidet das Modell.
Reviewer-Erwartung. Der entscheidende Teil. Formulier eine Ablehnungsregel: „Sofort ablehnen, wenn X.“ Das zwingt das Modell, den eigenen Output gegen ein Kriterium zu prüfen.

Ein konkretes Beispiel

Angenommen, dein Team arbeitet an einem Django-Backend (das ist ein fiktives Beispiel für mich, weil ich nicht mit Django arbeite). Ein Endpoint berechnet Lagerbestände falsch. Teileingänge werden nicht korrekt abgezogen. Der Prompt könnte so aussehen:

Files in scope: warehouse/views.py, warehouse/tests/test_views.py
Out of scope: Models, Migrations, Serializer, Utility-Funktionen.

Fix: Fehlerhafte Bestandsberechnung im Endpoint. 
Teileingänge werden nicht korrekt abgezogen.

Output: Plan (max 5 Punkte), View-Änderungen, Test-Updates, Risiko-Hinweis.

Reviewer-Erwartung: Sofort ablehnen, wenn Model-Layer berührt oder Migration vorgeschlagen wird.

Was passiert: Das Modell kann den Fix implementieren, aber es kann nicht in die Models ausweichen. Es kann nicht „mal eben“ den Serializer verbessern. Der Diff bleibt auf den View und die Tests beschränkt. Und wenn das Modell trotzdem eine Migration vorschlägt, hast du eine klare Ablehnungsregel, die auch im Code Review funktioniert.

Warum das funktioniert

LLMs arbeiten mit dem Kontext, den du ihnen gibst. Wenn du keinen Scope setzt, ist der gesamte sichtbare Code der implizite Scope. Alles, was das Modell sieht, wird zum Kandidaten für Änderungen. Die aktuellen Modelle unterscheiden in einem ‚explore‘ Schritt oft schon, welchen Kontext sie sich zum Lesen holen, und was angefasst werden soll, aber eben eher zufällig.

Die Reviewer-Erwartung ist dabei der wichtigste Teil. Sie gibt dem Modell eine Selbstprüfungsregel und deinem Team ein Kriterium für das Code Review. Reviewer sehen das Kriterium ebenfalls und können fast schon mechanisch ablehnen, wenn nötig. Beides löst dasselbe Problem: unkontrollierte Änderungen erkennen, bevor sie in den Main-Branch gelangen.

Die Reviewer-Erwartung funktioniert im Prompt als ‚framing‘: die Ablehnungsregel wird mitgeführt. Wer mal eine LLM beim ‚thinking‘ beobachtet hat, weiß, wie manche Vorschläge direkt wieder abgelehnt werden, weil im Kontext irgendeine Limitierung drin steckt, egal wie diffus.

Die Erwartung selbst lässt sich im Prozess auch codieren, indem du einen Reviewer-Subagenten vorbereitest. Der kann den implementierenden Agenten in Schach halten.

Was das Pattern nicht löst

Scoping hilft bei Aufgaben, deren Grenzen du kennst. Bei explorativen Aufgaben wie „Finde heraus, warum der Memory-Verbrauch steigt“ funktioniert ein enger Scope nicht, weil du die betroffenen Dateien noch nicht kennst. In solchen Fällen teile ich die Arbeit in zwei Schritte: erst eine Analyse ohne Code-Änderungen, dann einen zweiten Prompt mit dem Scope aus der Analyse. Je nachdem, welche Werkzeuge du nutzt, welchen Agent Harness, Kannst du die explorative Aufgabe zuerst ausführen und das Ergebnis in einer Markdown-Datei schreiben lassen, mit einem Überblick über all die Teile, die involviert sind. Und dann gleich nochmal einen Agenten losjagen, um kritisch dasselbe zu machen und die Arbeit zu überprüfen – und daraufhin erst einen Agenten , der den Fix implementiert. Alle mit einem frischen Kontext, um die Ehrlichkeit hochzuhalten (und die Kosten niedrig).

Ein guter Prompt ersetzt kein Code Review, aber er macht das Review leichter, weil der Diff vorhersagbar wird.

Die Entscheidung, ob die Änderung korrekt ist, liegt weiterhin beim Team.

Zum Mitnehmen

Wenn dein Team KI-Coding-Tools einsetzt und die Diffs regelmäßig zu groß oder unvorhersehbar ausfallen, probier dieses Muster bei der nächsten Aufgabe aus:

Dateien explizit benennen (in scope und out of scope)
Erwarteten Output beschreiben
Eine Ablehnungsregel formulieren

Der Aufwand pro Prompt sind 30 Sekunden. Der Effekt auf die Review-Zeit ist erheblich. Und wenn du ~~faul~~ praktisch veranlagt bist, baust du dir Prompt-Template-Werkzeuge, die es leicht machen, das Richtige zu tun.