Strukturierte KI-Workflows: Warum dein Team nicht bessere Prompts braucht, sondern Struktur

Warum kommt bei all den KI-Tools so wenig an?

Weil die meisten Teams Werkzeuge eingeführt haben, aber keine strukturierten KI-Workflows. Die Lizenzen sind da, die Demos waren beeindruckend – und trotzdem sieht der Quartalsbericht aus wie vorher. Die Antwort auf «Warum wirkt das nicht?» liegt selten im Modell. Sie liegt in der Struktur darum herum.

Die Zahlen zeichnen das Bild präzise. 84 Prozent der Entwickler nutzen KI-Tools oder planen es, meldet der Stack Overflow Developer Survey 2025 mit rund 49'000 Befragten. Gleichzeitig misstrauen 46 Prozent der Genauigkeit der Ergebnisse – mehr, als ihr vertrauen (33 Prozent). Zwei Drittel sagen, KI-Antworten seien «almost right, but not quite», und 45 Prozent verlieren spürbar Zeit mit dem Debuggen von KI-Code.⁶

Vielleicht kennst du die Alltagsversion davon: Jeder im Team promptet für sich. Dieselbe Frage liefert drei verschiedene Antworten, je nachdem, wer fragt. Die guten Prompts stecken in privaten Notizen. Und die Coding-Agents liefern schneller, als sie sauber gefüttert werden können. Werkzeuge sind da – ein System ist es nicht.

Genau diese Lücke haben die Software-Berater von Atomic Object auf eine einfache Formel gebracht: Wer mehr aus KI holen will, braucht Struktur – keine besseren Tricks. Dieser Artikel nimmt die These ernst und zeigt, wie die Struktur konkret aussieht.¹

Die These: KI verstärkt deine Struktur – oder dein Chaos

Die These dieses Artikels in einem Satz: KI macht dein Team nicht besser, sie macht es mehr von dem, was es schon ist – und deshalb ist Struktur der Hebel, nicht das nächste Tool.

Der DORA-Report 2025 («State of AI-assisted Software Development», knapp 5'000 Befragte plus über 100 Stunden qualitative Interviews) kommt genau zu diesem Schluss: KI wirkt primär als Verstärker. Sie vergrössert die Stärken gut aufgestellter Organisationen und die Dysfunktionen der übrigen. Teams mit reifen Prozessen liefern mit KI schneller Wert; Teams mit technischen Schulden und Prozess-Engpässen werden mit KI oft schlechter, nicht besser.³

Das mag ernüchternd klingen, ist aber eine gute Nachricht. Es heisst nämlich: Der KI-Hebel ist kein Glücksspiel und keine Frage des Modells. Er ist eine Funktion von Entscheidungen, die dein Team selbst trifft – über Input, Prozess und Output. Oder zugespitzt: Wer schlechten Input automatisiert, liefert den Schlamassel nur schneller aus.

Drei Strukturen entscheiden, in welche Richtung der Verstärker zeigt. Struktur im Input: Welchen Kontext bekommt die KI? Struktur im Prozess: Wer führt, wer entscheidet? Struktur im Output: Woran erkennst du, dass ein Ergebnis stimmt? Die nächsten drei Abschnitte gehen sie der Reihe nach durch – vom leichtesten zum stärksten Hebel.

Struktur im Input: Gib der KI kuratierten Kontext statt Ad-hoc-Prompts

Der erste Hebel ist der Input. Eine KI ohne Kontext rät – höflich, eloquent und oft falsch. Strukturierter Input heisst: Das Wissen, das die KI für eine Aufgabe braucht, liegt kuratiert bereit, statt in jedem Prompt neu improvisiert zu werden.

Wie das praktisch aussieht, zeigt Atomic Object an der eigenen Arbeit: Für Technical-Due-Diligence-Mandate füttern die Berater ihre KI-Werkzeuge gezielt mit internen Checklisten, Kundendokumentation und Beispiel-Reports – erst dieser reiche Kontext macht die Antworten relevant und verwertbar. Der Prompt ist kurz, der Kontext ist gross. Bei den meisten Teams ist es umgekehrt.²

Die wiederverwendbare Form davon sind Skill Files – einseitige Betriebsanleitungen, die eine KI ohne Rückfragen befolgt: Glossar, Konventionen, Grenzen, gewünschtes Output-Format. Einmal geschrieben, vom ganzen Team genutzt und versioniert wie Code. Damit wandert Prompt-Qualität aus privaten Notizen in geteilte Infrastruktur.

Der Effekt: Antworten werden reproduzierbar. Dieselbe Frage liefert dieselbe Qualität, egal wer fragt. Und der teuerste Teil der KI-Nutzung – das immer gleiche Erklären des Kontexts – fällt weg.

Struktur im Prozess: Vereinbare, wo die KI führt und wo der Mensch entscheidet

Der zweite Hebel ist die Arbeitsteilung. Strukturierte KI-Workflows legen pro Aufgabentyp fest, wer führt: Die KI entwirft und der Mensch entscheidet – oder die KI führt aus, gegen eine vorher vereinbarte Vorgabe. Was nie funktioniert: beides offenlassen.

Dass fehlende Prozess-Struktur real Tempo kostet, ist gemessen. Die METR-Studie 2025 – ein randomisiert-kontrollierter Versuch mit 16 erfahrenen Open-Source-Entwicklern über 246 echte Tasks – fand: Mit frei eingesetzten KI-Tools waren die Entwickler 19 Prozent langsamer, glaubten aber, 20 Prozent schneller zu sein. Ohne definierte Arbeitsteilung ersetzt das gute Gefühl die Wirkung.⁵

Für den grössten Aufgabentyp – Software-Änderungen – gibt es die vereinbarte Vorgabe bereits als Disziplin: eine Spec, die vor dem Agent-Lauf festgeklopft wird. Discovery bleibt menschlich, Execution läuft gegen die Spec. Sind die Regeln vorab klar, driftet die Umsetzung nicht – und Logik-Fehler lassen sich gegen die ursprüngliche Absicht prüfen statt gegen Vermutungen.

Dieselbe Logik gilt ausserhalb des Codes: Wer entscheidet, ob eine KI-Antwort in ein Kundenmail darf? Ab welcher Grösse braucht eine Änderung ein Review? Solche Vereinbarungen sind in einer Stunde Teamzeit getroffen – und sie unterscheiden ein System von einem Experiment.

Wie so eine Arbeitsteilung im PM-Alltag konkret eingerichtet wird – Kontextdateien, Plan-Modus, Review in zwei Schichten –, zeigt das Claude-Code-Setup für Product Manager Schritt für Schritt.

Struktur im Output: Verlange Evidenz statt Vertrauen

Der dritte Hebel ist der Prüfpunkt. Ein KI-Ergebnis gilt erst als fertig, wenn es Evidenz mitbringt: gelaufene Tests, geprüfte Quellen, ein Review durch die Person, die die Konsequenzen trägt. Nicht weil KI schlecht wäre – sondern weil sie überzeugend falsch sein kann.

Die Stack-Overflow-Zahlen erklären, warum das der kritischste Punkt ist: 66 Prozent der Entwickler sagen, KI-Antworten seien fast richtig, aber eben nicht ganz – und genau diese Fast-Richtigkeit rutscht ohne Prüfpunkt durch. Die 45 Prozent, die Zeit mit dem Debuggen von KI-Code verlieren, bezahlen die fehlende Struktur im Output nachträglich, mit Zins.⁶

Der Prüfpunkt muss zur Grösse passen. Ein Textentwurf braucht einen Lesedurchgang, ein Migrationsskript ein echtes Review mit Tests. Wichtig ist nur: Der Prüfpunkt ist vorher definiert, nicht nachträglich verhandelt. «Sieht gut aus» ist kein Prüfpunkt.

Wie viel dieser drei Strukturen euer Team heute hat, kannst du direkt hier unten in zwei Minuten prüfen.

Was das mit Teklens zu tun hat

Teklens ist um genau diese drei Strukturen gebaut – als Layer über den Tools, die du schon nutzt, kein Ersatz. Die Context Engine liest Jira, Confluence und den echten Code und hält daraus einen persistenten Produktkontext: strukturierter Input, der nicht pro Prompt neu entsteht. Sie schickt der KI nur den relevanten Ausschnitt – mehr Präzision, tiefere KI-Kosten.

Im Prozess arbeitet Teklens gegen Vorgaben statt gegen Zurufe: Aus Entscheidungen werden Specs und Jira-Tickets, und jede Spezifikation wird gegen den echten Code geprüft. Im Output liefern Quality Gates die Evidenz – Spec verified, PR checked, Risk surfaced, mit Freigabespur. Ob das zu eurem Setup passt, prüfst du am ehrlichsten im Testzugang am eigenen Repo.

Das stärkste Argument: Was DORA bei Tausenden Teams gemessen hat

Zum Schluss das Argument, das die These trägt. Der DORA-Report 2024 (über 39'000 Befragte) mass, was passiert, wenn KI-Adoption ohne Struktur wächst: Pro 25 Prozent mehr Adoption sank die Delivery-Stabilität um 7,2 Prozent und der Durchsatz um 1,5 Prozent. Nicht weil der KI-Code Müll wäre – sondern weil KI grössere Change-Sets leicht macht, und grosse Änderungen ohne Disziplin mehr Risiko bedeuten.⁴

Ein Jahr später liefert derselbe Forschungsstrang die Auflösung. Der DORA-Report 2025 benennt sieben Grundlagen, die den KI-Effekt ins Positive drehen – darunter eine klare KI-Policy, ein gesundes Daten-Ökosystem, Arbeit in kleinen Batches und Nutzerfokus. Alles Struktur, nichts Modell-Magie. Teams, die damit arbeiten, verwandeln individuelle KI-Geschwindigkeit in organisationale Performance; die übrigen verwandeln sie in Instabilität.³

Und damit schliesst sich der Kreis zum Anfang. Dass bei all den Tools so wenig ankommt, ist kein KI-Problem, sondern ein Struktur-Problem – und damit lösbar, ohne ein einziges neues Tool. Der Unterschied zwischen den Teams, bei denen KI trägt, und den anderen war nie das Modell. Es war immer die Struktur, in die es hineinarbeitet.

Häufige Fragen

Empfehlungen

• Beginne mit einer Seite Kontext pro Vorhaben. Sammle Glossar, Konventionen, Grenzen und gewünschtes Format in einem geteilten Dokument, das jede KI-Session mitliest. Eine Stunde Aufwand, sofort spürbar.
• Vereinbare die Arbeitsteilung schriftlich. Pro Aufgabentyp: KI entwirft und Mensch entscheidet, oder KI führt aus gegen eine vereinbarte Spec. Häng die Vereinbarung dorthin, wo gearbeitet wird – ins Repo, nicht ins Wiki.
• Definiere Prüfpunkte vor dem ersten Lauf. Lege pro Ergebnistyp fest, welche Evidenz «fertig» bedeutet: Tests, Quellen, Review. «Sieht gut aus» zählt nicht.
• Teile Prompts und Skills wie Code. Versioniert, mit Owner, für alle sichtbar. Was privat bleibt, skaliert nicht.
• Miss Nacharbeit statt Output. Steigen Nacharbeit oder Change-Failure-Rate mit der KI-Nutzung, fehlt Struktur – verschärfe die Prüfpunkte. Sinken sie, kannst du der KI mehr Aufgabenklassen öffnen.
• Fange klein an, aber fange als Team an. Ein Pilot-Vorhaben mit allen drei Strukturen schlägt zehn Einzel-Experimente. Der Verstärker wirkt pro System, nicht pro Person.

Einordnung & Grenzen

• Die DORA-Ergebnisse (2024: über 39'000 Befragte; 2025: knapp 5'000 Befragte plus über 100 Stunden qualitative Interviews) sind Umfrage-Korrelationen und Branchen-Aggregate, keine Kausalbeweise und keine Aussagen über dein spezifisches Team. Nutze sie als Warnsignal und Orientierung, nicht als Prognose.
• Die METR-Studie umfasste 16 erfahrene Entwickler in grossen, reifen Open-Source-Repos mit Modellen von Anfang 2025. Die Autoren betonen selbst, dass sich das Ergebnis nicht auf alle Kontexte übertragen lässt und neuere Modelle anders abschneiden können.
• Die Stack-Overflow-Zahlen sind Selbstauskünfte von rund 49'000 Befragten mit Übergewicht aktiver Community-Mitglieder – gut für Grössenordnungen, nicht für Präzision.
• Atomic Object ist eine Software-Beratung; die zitierten Beobachtungen sind Praxiserfahrung aus Kundenprojekten, keine kontrollierte Studie.
• Die Teklens-Aussagen beschreiben Fähigkeiten des Produkts, keine gemessenen Kundenresultate; Pilot-Metriken stehen aus.

Quellen

Jede externe Zahl und jedes Zitat in diesem Beitrag – nachprüfbar verlinkt.

1. 1.Atomic Object, Atomic Spin (2026) – spin.atomicobject.com/ai-you-need-structure ↗ – Der Beitrag, der diesen Artikel inspiriert hat: Wer mehr aus KI holen will, braucht Struktur.
2. 2.Atomic Object, «Leverage AI in Technical Due Diligence Engagements» (Atomic Spin) ↗ – Reicher Kontext – Checklisten, Kundendokumentation, Beispiel-Reports – macht KI-Antworten in Due-Diligence-Mandaten verwertbar.
3. 3.DORA, «State of AI-assisted Software Development Report 2025» (Google Cloud) ↗ – Knapp 5'000 Befragte, über 100 Stunden qualitative Interviews; KI wirkt als Verstärker – von Stärken wie von Dysfunktionen.
4. 4.DORA, «Accelerate State of DevOps Report 2024» (Google Cloud) ↗ – Über 39'000 Befragte; Delivery-Stabilität −7,2 Prozent pro 25 Prozent mehr KI-Adoption.
5. 5.METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity» (2025), arXiv:2507.09089 ↗ – RCT mit 16 Entwicklern über 246 Tasks: 19 Prozent langsamer mit KI-Tools.
6. 6.Stack Overflow, «2025 Developer Survey» – AI-Sektion ↗ – 84 Prozent Nutzung, 46 Prozent Misstrauen in die Genauigkeit, 66 Prozent «almost right, but not quite».

Weiterlesen im PM Lab

Verwandte Deep Dives – aus demselben Pillar und den angrenzenden Phasen.

Passende Use Cases aus der Bibliothek

Vom Beitrag direkt in die Praxis: Diese Use Cases setzen die Konzepte mit Teklens um.