Begrüßung. Der Vortrag dauert rund 40 Minuten, danach Zeit für Fragen.
Die zehn Tage im Untertitel setzen sich aus rund drei Tagen konzeptionellem Vorlauf bis zum initialen Repository und sieben Kalendertagen Weiterentwicklung im Git-Verlauf zusammen (Folie 31). Es sind Teilzeit-Tage: neben anderen Aufgaben, nicht zehn volle Arbeitstage. Gemeint ist ein Demonstrator, kein Produktivsystem. Er berichtet über ein Vorgehen: wie ein Grobkonzept und ein Demonstrator mit Hilfe von KI-Werkzeugen entstanden sind, am Beispiel der Lagebild-Plattform. Er richtet sich an Entwicklerinnen und Entwickler und zeigt Arbeitsweise und Belege aus dem Repository.
Teil 2 und Teil 4 haben das größte Gewicht: In Teil 2 zeigt sich, wie das Konzept entsteht, in Teil 4 der Arbeitsablauf je Auftrag an einem durchgehenden Beispiel.
Zur Entstehung: Der Foliensatz wurde wie der erste Vortrag mit KI erzeugt, mit dem Modell Claude Sonnet 5.5 von Anthropic im Werkzeug Claude Code. Die Folien sind ein Entwurf und vor einer Verwendung inhaltlich zu prüfen.
Wichtig ist die Abgrenzung. Es gibt keine Vergleichsgruppe: Wir wissen nicht, wie lange eine Erstellung ohne KI gedauert hätte. Genannte Zeiträume sind Beobachtungen aus dem Projekt, keine Aufwandsrechnung, und die Zahlen am Ende beschreiben den Umfang des Ergebnisses, nicht einen Nutzen.
Der Demonstrator selbst ist kein Produktivsystem und nicht in allen Punkten sicherheitstechnisch validiert; das steht so auch in der README.
Teil 1. Kurz: Was sollte entstehen, und in welchen Stufen ist es entstanden.
Der Demonstrator ist als Grundlage für eine Reihe von Vergaben gedacht. Deshalb ist es wichtig, dass Konzept und Umsetzung nachvollziehbar übergeben werden können, und deshalb liegt alles im Repository.
Die Frage dieses Vortrags ist eng: Er sagt nicht, dass KI Konzepte allgemein ersetzen kann, sondern zeigt, wie weit es in diesem Fall getragen hat und welche Vorkehrungen nötig waren.
Die Reihenfolge ist wichtig: erst das Konzept, dann der Code. Das Konzept ist die Eingabe für den Übergang zum codeorientierten Modell.
Der Satz auf der Folie, dass nur zählt, was in einer Datei steht, ist eine Arbeitsregel: Zwischenstände in Gesprächen sind flüchtig. Das Repository ist das Gedächtnis des Projekts.
Teil 2. Das Grobkonzept entsteht in einem Gespräch mit einem Sprachmodell. Das Ergebnis ist eine Datei.
Die Aufträge sind bewusst alltagssprachlich. Wichtig ist das Muster: Frage, Vorschlag mit Optionen, Entscheidung, Umsetzung. Das Modell macht Vorschläge, die Entscheidung trifft der Auftraggeber.
Die Aufträge im Wortlaut sind nicht im Repository abgelegt. Dokumentiert sind ihre Ergebnisse: Entscheidungen, Konfiguration, Änderungsprotokoll. Das ist eine Grenze, die ich am Ende nenne.
Die feste Gliederung ist das, was das Gespräch mit dem Modell lenkt: Jeder Abschnitt ist ein Arbeitsauftrag. Fehlt etwas, fällt es als fehlender Abschnitt oder als offener Punkt auf.
Weil das Konzept eine Textdatei ist, gelten dieselben Regeln wie für Code: Änderungen laufen über Merge Requests und sind im Verlauf nachvollziehbar.
Der Kern der Lenkung ist, dass das Modell nicht frei erzählt, sondern in einen Rahmen schreibt und Entscheidungen sichtbar macht. Offene Punkte sind kein Makel, sondern Teil des Konzepts: Sie sagen, wo noch keine Entscheidung vorliegt.
Recherche ist kein Nebeneffekt, sondern ein eigener Auftrag. Das Ergebnis steht an zwei Stellen im Konzept: als inhaltlicher Abschnitt und als Verzeichnis der Quellen.
Sprachmodelle können Quellen ungenau wiedergeben. Deshalb die Empfehlung, Quellen zu prüfen. Das ist keine Aussage darüber, dass im Projekt etwas Falsches gefunden wurde, sondern eine Vorsichtsmaßnahme.
Das ist ein Fehler, der bei der Arbeit mit einem Modell leicht entsteht, weil es bereitwillig Beispiele einfügt. Die Gegenmaßnahme war eine Entscheidung, keine Disziplinfrage: Das Konzept enthält keinen kopierten Code mehr.
Der Nachteil ist festgehalten: Das Konzept ist allein technisch weniger detailliert, für die Übergabe in Vergaben ist das Repository mitzuliefern.
ADR steht für Architecture Decision Record. Gemeint ist ein kurzes Dokument je Entscheidung: Warum stand die Frage an (Kontext), was wurde festgelegt (Entscheidung), und was folgt daraus, auch an Nachteilen (Konsequenzen). Das Format hat Michael Nygard 2011 beschrieben. Es ist klein genug, dass ein Modell es zuverlässig mitschreibt, und streng genug, dass Begründung und Nachteil nicht fehlen. Die Beispielspalte zeigt die Entscheidung 013, die ich vorher als Lehre gezeigt habe.
Für die Übergabe in Vergaben sind die Entscheidungen oft wichtiger als der Code: Sie sagen, warum etwas so ist.
Teil 3. Vom Konzept zum lauffähigen Projekt.
Der Wechsel des Werkzeugs hat einen praktischen Grund: Ein Modell, das Dateien lesen und schreiben, Befehle ausführen und Tests starten kann, arbeitet am Ergebnis statt darüber zu reden.
Die Konzeptphase lief über Mistral/Vibe, danach wurde für die code-nahe Arbeit auf Claude gewechselt. Im Repository festgehalten sind nur die Angaben in den Commits der späteren Arbeit; der Vorlauf ist als Ergebnis im ersten Commit enthalten.
Das ist der Teil des Auftrags, bei dem übliche Praktiken eine große Rolle spielen: Ein Projekt auf openCode soll aussehen und funktionieren wie ein gepflegtes Open-Source-Projekt. Das Modell kennt diese Konventionen und legt die Dateien an; ob sie inhaltlich stimmen, muss man prüfen.
Die Lizenz und die Hinweise zu Drittkomponenten sind Beispiele dafür: Sie sind rechtlich relevant und deshalb nicht nur Formsache.
Das Hosting wurde nicht manuell aufgebaut, sondern als Auftrag an das Modell: Skripte und Konfiguration, die einen Server in den beschriebenen Zustand bringen. Der Vorteil ist, dass die Anleitung ausführbar ist und nicht nur beschreibt.
Das Prinzip gilt auch für Änderungen im Betrieb: Was nicht im Repository steht, wird beim nächsten Abgleich überschrieben.
Die Struktur ist so gewählt, dass ein Modell sie schnell erfassen kann: Konfiguration, Code, Dokumentation und Betrieb liegen getrennt und haben sprechende Namen.
Die Prompt-Vorlagen unter llm/prompts gehören zu einem anderen Thema: Sie sind die optionale KI-Funktion der Plattform, nicht der Prozess, über den dieser Vortrag spricht.
Teil 4. Ein durchgehendes Beispiel: der Plattformbericht, der Quellen, Aufbereitung und Anreicherung der Plattform für Mitglieder erklärt.
Der Ablauf wiederholt sich bei jedem Auftrag. Neu in jedem Durchlauf ist die Analyse vor der Umsetzung: Das Modell macht einen Vorschlag mit Optionen, bevor es Code schreibt.
Die Dokumentation ist Teil des Auftrags, nicht ein späterer Schritt. Dadurch bleiben Konzept, Entscheidungen und Code zusammen.
Der Auftrag ist eine Frage. Das Modell liefert keine fertige Lösung, sondern Varianten mit Vor- und Nachteilen. Die Entscheidung ist kurz: Vertraulichkeit, Ausgabeformen und die Vorgabe, nur eine Liste ohne Bewertung zu liefern.
Diese Vorgabe steht später im ADR als Entscheidung 3.
Der Plattformbericht wird aus dem Betrieb erzeugt und nicht von Hand geschrieben. Das war die wichtigste Entwurfsentscheidung: Ein handgeschriebener Text würde von der Konfiguration abweichen, sobald ein Feed geändert wird.
Dass kein KI-Text verwendet wird, ist ebenfalls eine Entscheidung: Der Bericht erklärt die Plattform und soll deshalb nichts enthalten, was ein Modell frei formuliert.
Die automatischen Tests haben keinen dieser Fehler gefunden, weil sie die Umgebung auf dem Server nicht abbilden: Dateirechte, Proxy-Konfiguration, Rollen im Token. Sie sind in der Prüfung an der echten Instanz aufgefallen.
Das ist eine Grenze von Tests, nicht des Modells. Wichtig ist, dass jeder Befund wieder als Auftrag, Änderung und Eintrag im Verlauf endet.
Am Ende eines Auftrags ist die Änderung an fünf Stellen sichtbar. Wer später fragt, warum es den Plattformbericht gibt und wie er funktioniert, findet Entscheidung, Anleitung, Code und Verlauf.
Der Merge ist die Freigabe. Ohne ihn ändert sich der Hauptzweig nicht.
Die Freigabe ist die Stelle, an der ein Mensch die Verantwortung übernimmt. Das Modell schlägt vor und setzt um, der Merge erfolgt durch den Auftraggeber.
Die Zahl der Zusammenführungen zeigt nur die Häufigkeit der Freigaben im Zeitraum. Sie sagt nichts über den Aufwand der Prüfung je Merge Request.
Teil 5. Kurz: welche Prüfungen es gibt, und was sie nicht abdecken.
Die Messung vor dem Bau ist die Maßnahme gegen eine typische Schwäche: Ein Modell schlägt plausible Heuristiken vor, die in der Praxis schlechter funktionieren. Durch die Messung an echten Daten fällt das auf, bevor es im Betrieb ankommt.
Diese Folie ist die ehrliche Seite des Berichts. Der Demonstrator ist nicht für den produktiven Betrieb gedacht, und das gilt unabhängig davon, wie gut die Tests laufen.
Besonders wichtig für Nachahmer: Wer das Vorgehen übernimmt, sollte die Aufträge sichern, wenn sie später als Nachweis dienen sollen.
Teil 6. Zahlen zum Umfang. Sie beschreiben das Ergebnis, nicht den Aufwand.
Die Zahlen zeigen, wie viel Text und Code im Repository liegt. Zeilen sind ein schlechtes Maß für Qualität. Sie dienen hier dazu, den Umfang einzuschätzen: Es ist kein Beispielprojekt aus wenigen Dateien.
Der konzeptionelle Vorlauf lief über Mistral/Vibe und dauerte rund drei Tage bis zur Erstellung des initialen Repositories. Danach wurde für die code-nahe Arbeit auf Claude gewechselt. Die Dauer des Vorlaufs ist eine Angabe des Auftraggebers; die Tage sind Teilzeit-Tage, keine vollen Arbeitstage. im Git-Verlauf steht davon nur der Import im ersten Commit. Der Verlauf belegt dagegen, wie viel in welchem Zeitraum danach festgeschrieben wurde.
Nicht alle Commits tragen eine Modellangabe. Die Angabe wurde erst im Lauf des Projekts regelmäßig gesetzt; daraus folgt nicht, dass frühere Commits ohne Modell entstanden sind.
Teil 7. Regeln, die sich aus dem Vorgehen ergeben, und Fragen, die offen bleiben.
Diese Regeln sind aus Erfahrungen entstanden, nicht vorab aufgestellt. Jede hat ein Beispiel im Projekt, das ich vorher gezeigt habe.
Die letzte Regel gilt auch für diesen Vortrag: Die Zahlen auf den Folien werden beim Bau aus dem Repository gelesen. Wird etwas im Repository geändert, ändern sich die Folien mit dem nächsten Bau.
Das sind keine rhetorischen Fragen, sondern Punkte, die vor einer Übernahme des Vorgehens in andere Vorhaben zu klären sind. Ich habe dazu keine fertigen Antworten, nur die Beobachtung, dass sie im Projekt aufgetreten sind.
Zeit für Fragen. Konzept, Entscheidungen und Quelltext liegen im Repository; die Folien werden aus dem Repository gebaut und mit dem Projekt fortgeschrieben.