Du entwickelst nicht nur Software

Veröffentlicht am von

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.

Hinterlasse einen Kommentar