Archiv für den Monat März 2026

Die Organisation als Kontext-System

Veröffentlicht am von
Antwort

Warum KI nicht an Daten scheitert, sondern an impliziten Annahmen

KI ist inzwischen in vielen Unternehmen angekommen.

Und doch bleibt ein Muster:

Die Ergebnisse sind oft nicht falsch —
aber nicht ausgerichtet.

Warum?

Unternehmen scheitern selten an fehlenden Daten —
sie scheitern an nicht expliziten Annahmen.

Eine Beobachtung

In der Softwareentwicklung zeigt sich:

Sobald ein System guten Kontext hat,
arbeitet KI deutlich präziser.

Nicht weil sie „besser programmiert“.
Sondern weil sie besser versteht.

Der Schritt nach oben

Was im Code funktioniert, lässt sich übertragen.

Nicht auf Tools.
Auf die Organisation.

Eine Organisation kann als System expliziter Kontext-Dokumente verstanden werden.

Drei Ebenen

1. Contracts

Was gilt.

  • Positionierung
  • Prioritäten
  • Grenzen

Keine Meinungen.
Invarianten.

2. Onboarding

Wie funktioniert dieses System?

  • Wie treffen wir Entscheidungen?
  • Was ist wichtig?
  • Was ist nicht verhandelbar?

Für Menschen und KI lesbar.

3. Boundary

Wie wird entschieden?

  • strategisch → stabil
  • taktisch → anpassbar
  • experimentell → offen

Der Unterschied

Heute:

  • Kontext ist verteilt
  • Annahmen sind implizit
  • Entscheidungen schwer nachvollziehbar

Dann:

  • Kontext ist explizit
  • Regeln sind sichtbar
  • Entscheidungen werden anschlussfähig

Der Loop

Kontext → Entscheidungen → Ergebnisse → besserer Kontext

Der Effekt

Der Engpass verschiebt sich:

  • weniger Diskussion über Symptome
  • mehr Klarheit über Bedingungen

Eine Konsequenz

Diese Dokumente sind nicht Beiwerk.

Sie sind:

  • Teil der Organisation
  • Teil der Governance
  • Teil der Entscheidungslogik

Und das Wichtigste

Du musst nicht perfekt starten.

Ein erstes Dokument darf:

  • unvollständig sein
  • Fragen enthalten
  • unscharf sein

Wichtig ist nur:

Es existiert.
Und wird benutzt.

Fazit

Eine AI-first Organisation ist keine Organisation mit besseren Tools.

Sondern eine Organisation, die:

  • ihre Annahmen sichtbar macht
  • ihre Regeln explizit formuliert
  • ihren Kontext systematisch entwickelt

Satz zum Mitnehmen

Du entwickelst nicht nur Organisationen —
du entwickelst die Bedingungen, unter denen Entscheidungen entstehen.

… und spirituell / philosophisch


Entscheidungen haben kein isoliertes, immanentes „richtig“.
Sie sind immer richtig — oder falsch — im gegebenen Kontext.

Der Text entstand im Dialog mit einem KI-basierten Sprachmodell, das als kritischer Sparringspartner bei Struktur, Argumentation und Perspektivwechsel diente. Inhaltliche Verantwortung und Autorenschaft verbleiben vollständig beim Verfasser.

Du entwickelst nicht nur Software

Veröffentlicht am von
Antwort

Ein praktischer Effekt von KI-Onboarding

KI verändert den Entwicklungsprozess.
Das ist inzwischen Konsens.

Weniger klar ist:
wo genau die Produktivitätsgewinne entstehen.

Eine Beobachtung aus der Praxis:

Du entwickelst nicht nur Software —
du entwickelst die Bedingungen, unter denen Software richtig verstanden wird.

Was passiert ist

Ausgangspunkt war kein perfekter Plan,
sondern ein pragmatischer Versuch.

Zuerst wurde OpenAI Codex auf die bestehende Codebasis angesetzt —
mit einer sehr einfachen Aufgabe:

👉 „Erzeuge ein Dokument, das Orientierung gibt.“

Dieses Dokument wurde anschließend iterativ verbessert:

  • Fragen von Codex wurden aufgenommen
  • Unklare Stellen wurden präzisiert
  • implizite Architektur wurde explizit gemacht

Danach kam der Praxistest:

👉 Einsatz mit GitHub Copilot (Claude Sonnet 4.6)

Und genau dort wurde es interessant.

Der Effekt

Nach Einführung des Onboarding-Dokuments:

  1. Copilot „sieht“ die Struktur deutlich klarer
  2. Vorschläge sind zielgerichteter
  3. Refactorings greifen an den richtigen Stellen
  4. Tests und DB-Zugriffe wurden direkt verbessert
  5. Das Onboarding-Dokument selbst wurde anschließend präziser

Ein Zyklus entsteht:

Onboarding → besseres Verständnis → besserer Code → besseres Onboarding

Der Engpass verschiebt sich weiter:

  • weniger Implementierung
  • mehr Präzisierung der Bedingungen

Ein wichtiger Punkt (und vielleicht der wichtigste)

Das Dokument war am Anfang nicht gut.

Und das ist entscheidend.

Es war:

  • unvollständig
  • teilweise unklar
  • eher Skizze als System

Und trotzdem hat es sofort geholfen.

Warum?

Weil es einen Unterschied gibt zwischen:

gar keinen expliziten Annahmen

und

unvollständigen, aber sichtbaren Annahmen

Der eigentliche Trick

Der Einstieg war ein sehr einfacher Prompt:

Du analysierst eine bestehende Codebasis und erstellst 
Kontext-Dokumentation für zukünftige KI-Sessions.
Deine Aufgabe ist nicht vollständige Dokumentation — 
sondern Orientierung.
Ziel:
Ein Dokument, das in 5 Minuten vermittelt:
- wo man ist
- warum es so gebaut wurde
- was nicht ohne Rückfrage geändert werden sollte
Struktur:
1. Zweck
2. Architektur-Entscheidungen
3. Abhängigkeiten
4. Constraints
5. Offene Fragen

Mehr war es nicht.

Kein perfektes Modell.
Kein vollständiges Design.

Was sich verändert hat

Vorher:

  • KI generiert Code
  • Entwickler bewertet

Jetzt:

  • Entwickler definiert Bedingungen
  • KI arbeitet innerhalb dieser Bedingungen

Das System wird stabiler, weil:

  • Invarianten explizit sind
  • Architektur sichtbar ist
  • Fehlinterpretationen reduziert werden

Der eigentliche Shift

Der Fokus verschiebt sich:

Von:

Wie implementiere ich das?

Zu:

Unter welchen Bedingungen darf es implementiert werden?

Konsequenz

Ein gutes Onboarding-Dokument ist kein Nebenprodukt mehr.

Es ist:

Teil des Systems
Teil der Architektur
Teil des Entwicklungsprozesses

Und vielleicht noch das Wichtigste

Du musst nicht mit einem perfekten Dokument starten.

Im Gegenteil.

Ein unvollständiges Dokument, das:

  • Fragen sichtbar macht
  • Annahmen explizit macht
  • Grenzen andeutet

ist bereits genug, um:

  • bessere Antworten zu bekommen
  • bessere Fragen zu stellen
  • und das System Schritt für Schritt zu klären

Nächster Schritt

Diese Dokumente lassen sich weiter strukturieren:

  • Contracts (was gilt)
  • Onboarding (wie man sich darin bewegt)
  • Boundary (wie man entscheidet)

Das Ziel ist ein System, das nicht nur funktioniert,
sondern auch korrekt verstanden wird — von Menschen und Maschinen.

Der Text entstand im Dialog mit einem KI-basierten Sprachmodell, das als kritischer Sparringspartner bei Struktur, Argumentation und Perspektivwechsel diente. Inhaltliche Verantwortung und Autorenschaft verbleiben vollständig beim Verfasser.

KI-getriebener Entwicklungsprozess

Veröffentlicht am von
Antwort

AUSGANGSPUNKT

KI verschiebt den Engpass.
Nicht mehr Produktion ist knapp — sondern Urteilsvermögen.

Agile war eine Antwort auf Unsicherheit unter begrenzter menschlicher Kapazität.
KI verändert beide Parameter gleichzeitig:

  • Produktion ≈ kostenlos
  • Komplexität ↑ schneller als Verständnis

Konsequenz:
Der Prozess muss Verständnis aktiv erzeugen.

01 · RHYTHMUS

Sprint → Entkopplung

Sprints verlieren ihre Funktion als zentrale Taktung.

Produktion und Reflexion laufen in unterschiedlichen Geschwindigkeiten:

  • Produktion: kontinuierlich
  • Reflexion: bewusst verlangsamt

Leitfrage:
Verstehen wir noch, was entstanden ist?

Risiko:
Reflexion wird verdrängt → System wächst schneller als Verständnis

02 · REVIEW

Sampling → Exhaustiv

Klassisches Review ist selektiv.
KI-Review ist vollständig.

Kein Gradunterschied — ein Kategorienwechsel.

  • Deskriptive Referenz: aus Code extrahiert
  • Normative Referenz: menschlich gepflegt (Intention, Constraints)
  • KI erkennt Drift, aber keine Bedeutung

Entscheidung bleibt menschlich:
Fehler oder Evolution?

03 · OWNERSHIP

Implizit → Explizit

Nicht dokumentierter Kontext existiert nicht.

KI hat perfektes Lesevermögen — aber kein Gedächtnis.

Konsequenz:

  • Kontext als Markdown neben Code
  • Teil der Definition of Done
  • KI schlägt Updates vor
  • Mensch kuratiert

Risiko:
Schleichender Verlust kollektiven Verständnisses

04 · DIALOG

Werkzeug → Kollege

KI wird nicht gesteuert — sondern befragt.

Der Prompt ist Teil der Lösung.

  • Prompt-Entwurf gehört ins Ticket
  • KI gibt Feedback vor Start
  • Offene Punkte werden früh sichtbar

Prinzip:
Probleme sind im Dialog billig, im Code teuer.

DER KREISLAUF

Kontext-Docs
    ↓
Ticket + Dialog
    ↓
Inkrement (KI + Review)
    ↓
Doc-Update
    ↓
Commit (Code + Kontext synchron)

Der Loop stabilisiert nur, wenn Reflexion aktiv geschützt wird.

NEUE ROLLE

Intention Keeper

Keine technische Rolle.
Eine epistemische.

Verantwortung:

  1. Ist die ursprüngliche Intention noch erkennbar?
  2. Ist erkannter Drift Fehler oder Evolution?
  3. Beschreibt das System sich selbst — oder dient es noch?
  4. Sind Kontext-Dokumente ausreichend präzise?
  5. Wird echter Dialog gelebt — auch unter Druck?

Eigenschaft:
Knapp. Nicht beliebig skalierbar.

TICKET-ANATOMIE

1. Beschreibung
Ziel, Kontext, Abhängigkeiten, Akzeptanzkriterien

2. Prompt-Entwurf
Aufgabe an KI, relevante Kontext-Dokumente, Constraints

3. KI-Feedback (vor Start)

  • Vollständigkeit
  • Unklarheiten
  • Risiken

LEITPRINZIPIEN (GESCHÄRFT)

Code ist Ausführung
Wahrheit entsteht aus:
→ Code + Kontext + Tests

Reibung ist Methode
Widerspruch der KI ist erwünscht

Mensch entscheidet
Bedeutung entsteht nicht automatisch

FAILURE MODES

01 · Delegations-Regression

  • Prompt wird Befehl
  • KI wird Ausführer
  • Dialog verschwindet

→ Ergebnis: syntaktisch korrekt, semantisch schwach

02 · Kontext-Erosion

  • Docs veralten
  • KI arbeitet auf falscher Basis

→ Ergebnis: saubere Umsetzung falscher Annahmen

03 · Review-Illusion

  • “KI hat alles geprüft” ersetzt Denken

→ Ergebnis: falsche Sicherheit

04 · Reflexions-Kollaps

  • Produktion dominiert
  • kein langsamer Takt mehr

→ Ergebnis: System wächst, Verständnis schrumpft



MINI-CASE

Ticket:
“Leads sollen automatisch priorisiert werden”

Beschreibung (Auszug)

  • Ziel: bessere Fokussierung Sales
  • Kontext: CRM-App, Sheet-basiert
  • Kriterium: nachvollziehbare Priorisierung

Prompt-Entwurf (verkürzt)

  • Input: Leads-Tabelle
  • Output: Prioritätswert (0–100)
  • Constraints:
    • erklärbar (keine Blackbox)
    • basiert auf vorhandenen Feldern
  • Kontext-Dokument: lead_scoring.md

KI-Feedback vor Start

  • Gewichtung unklar
  • Konflikt: Einfachheit vs. Genauigkeit
  • Risiko: implizite Annahmen über “guten Lead”

Dialog-Entscheidung
→ einfache, transparente Heuristik vorziehen

Inkrement

  • Score = Funktion aus:
    • Amount
    • Last Contact
    • Status

KI-Review findet Drift

  • Neue Felder genutzt, die nicht im Kontext stehen

Intention Keeper entscheidet
→ bewusste Erweiterung
→ Kontext-Dokument aktualisieren

Commit
Code + lead_scoring.md synchron

AGILE VS. KI-PROZESS

DimensionAgileKI-Framework
TaktungSprintEntkoppelte Rhythmen
ReviewSamplingExhaustiv
WissenImplizitExplizit
SteuerungDelegationDialog
EngpassUmsetzungVerständnis

KURZFORM

KI macht Produktion billig.
Der Engpass wandert ins Verstehen.

Der Prozess reagiert mit:

  • Entkoppelten Rhythmen
  • Exhaustivem Review
  • Explizitem Kontext
  • Dialog statt Delegation

META

Dies ist kein Prozess im klassischen Sinne.
Es ist ein Betriebssystem für Arbeiten unter:

  • billiger Produktion
  • hoher Komplexität
  • unsicherer Bedeutung

Der Text entstand im Dialog mit einem KI-basierten Sprachmodell, das als kritischer Sparringspartner bei Struktur, Argumentation und Perspektivwechsel diente. Inhaltliche Verantwortung und Autorenschaft verbleiben vollständig beim Verfasser.