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.