Management-Pitch · 9 Folien · ~7 Minuten
Vom Prompt zur disziplinierten KI-Fabrik
Wie wir KI schnell Code schreiben lassen — mit einer Qualitätsgarantie an der Schnittstelle.
Cong Chanh Vinzenz Nguyen · .NET-Architekt
Das Problem — nicht „kann KI coden", sondern „wann ist sie fertig?"
Moderne Teams lassen KI nicht mehr einzeln prompten, sondern in einer Schleife laufen, die sich selbst nachbessert (Boris Cherny, Claude Code: „my job is to write loops").
- Woran erkennt die Schleife „fertig"? Heute: „der Agent sagt fertig" — oder die Tests, die die KI sich selbst geschrieben hat.
- Das ist ein selbst-genehmigter Pull Request. Tausendfach schneller, aber niemand prüft unabhängig.
- Folgen: ungewisse Qualität, Blackbox (keiner versteht mehr das „Warum"), unkontrollierte Token-Kosten.
Die Idee in einem Satz
Gib der KI-Schleife ein Gate, das so streng und unabhängig ist wie eine gute CI-Pipeline —
und erst wenn dieses Gate grün ist, gilt „fertig".
Was ihr für Menschen längst macht (CI, Code-Review, Tests), machen wir mechanisch scharf genug für eine KI-Schleife.
Was wir gebaut haben: CDD
Getyptes Modell
Anforderungen als prüfbare Spezifikation (was gelten muss), nicht als Prosa im Ticket.
Fälschungssicheres Gate
Die KI, die Code schreibt, darf nicht selbst „grün" vergeben. Ein getrenntes Orakel entscheidet.
Open Source · F#/.NET · alle Belege CI-grün und reproduzierbar.
Neu: das harte Grün-Gate weist einen gefälschten grünen Test beweisbar ab — maschinell getestet.
Demo — in einer Minute, im Browser
- Ein Klick: „Open in Codespaces" → die echte Umgebung läuft im Browser, kein Setup.
- Die KI-Schleife arbeitet eine Spezifikation ab.
- Ein gefälschter Test (sieht grün aus, prüft nichts) → das Gate hält ihn auf rot.
- Erst ein echter grüner Test → der Knoten wird „fertig".
Das ist der ganze Punkt: „fertig" ist gemessen, nicht behauptet.
Der Geschäftswert
- Tempo + Qualität zugleich — KI-Geschwindigkeit, aber mit einer Garantie an der Schnittstelle statt „hoffentlich stimmt's".
- Weniger Blackbox-Risiko — die Spec ist externalisiertes, geteiltes Wissen; das „Warum" bleibt im Team, nicht in einem Kopf.
- Kostenkontrolle — ein gerichteter Loop bricht falsche Pfade früh ab, statt per Brute Force Tokens zu verbrennen (Trade-off, kein Selbstläufer).
- Review wird billiger — Menschen prüfen Konvergenz gegen die Spec, nicht jede Code-Zeile.
Ehrlich: was es nicht ist
- Kein „Coding is solved". Es funktioniert für formalisierbare Kriterien — nicht für UX, Geschmack, Architektur-Eleganz.
- Der Mensch setzt und verantwortet die tragende Anforderung. Das bleibt — bewusst.
- Heute Forschungsprototyp, zwei kleine Fallstudien. Belastbar als Mechanik-Nachweis, nicht als Großserie.
Diese Ehrlichkeit ist Absicht — sie unterscheidet uns vom Hype.
Der Ask
Ein kleiner, abgegrenzter Pilot:
- eine echte, formalisierbare Anforderung aus unserem Backlog,
- ~1–2 Wochen, ein Entwickler + ich,
- Ergebnis: gemessene Konvergenz + Token-/Zeit-Telemetrie als Entscheidungsgrundlage.
Risiko klein, Erkenntnis konkret — danach entscheiden wir mit Daten.
Selbst ansehen
Alles öffentlich, ein Klick entfernt:
koschnag.github.io/cong-driven-development
Einstieg (kein Vorwissen) · Live-Demo via Codespaces · Code & Belege · ausführlicher Essay
Danke. Fragen?