KI-gestützte Typmodellierung

KI-gestützte Typmodellierung

0:00 Zum Abschluss des ersten Tages verlassen wir für ein Modul das Typsystem und schauen auf das Werkzeug, mit dem heute die meisten Typen entstehen: einen Coding Assistant. Das funktioniert erstaunlich gut — und genau das ist der Grund, warum wir hinschauen müssen. Denn ein generierter Typ sieht fast immer plausibel aus. Er ist sauber formatiert, die Namen sind sinnvoll, nichts stört das Auge. Ob er die Fachlichkeit trifft, sieht man ihm dagegen nicht an.

0:26 Dieses Modul gibt Ihnen die Fragen an die Hand, mit denen Sie das herausfinden.

KI-gestützte Typmodellierung

0:31 Dieses Modul knüpft an alle drei vorigen an. Die Typlöschung aus Modul 1 erklärt, warum ein generierter Typ zur Laufzeit nichts absichert. Der Unterschied zwischen optional und leer aus Modul 2 ist der am häufigsten verwechselte Punkt in generierten Modellen. Und die Zustandsmodelle aus Modul 3 sind genau das, was ein Assistent von allein selten vorschlägt.

0:51 Wir gehen den Weg von der Anforderung über den generierten Vorschlag bis zu einem Prüfgang, den Sie danach auf jedes Modell anwenden können.

Anforderungen strukturieren lassen

0:59 Fangen wir dort an, wo der Gewinn wirklich liegt: ganz am Anfang, beim unsortierten Fachtext. Dort ist ein Assistent stark. Die Überschrift des Kapitels bringt es auf den Punkt — Rohmaterial in Minuten, Modell trotzdem in Stunden. Eine unsortierte fachliche Beschreibung — ein Protokoll, eine E-Mail, ein Gesprächsmitschrieb — lässt sich zuverlässig in Begriffe, Beziehungen und Regeln zerlegen.

1:24 Das geht schnell und ist ehrliche Arbeitserleichterung. Aber seien wir genau, was dabei herauskommt: Rohmaterial. Eine Liste von Kandidaten, aus der ein Modell werden kann. Es ist noch keine Modellierung, weil darin keine einzige Entscheidung steckt. Ein Bild: Der Assistent räumt Ihnen die Werkstatt auf und legt alle Teile sortiert hin.

1:44 Welches Teil in die Maschine gehört, entscheidet weiterhin, wer die Maschine kennt. Der rote Faden dieser fünf Schritte ist: unsortiert hinein, entschieden heraus. Übergeben Sie den Fachtext unverändert — und ja, das ist gegen den Instinkt. Lassen Sie Begriffe, Beziehungen und Regeln getrennt auflisten und fragen Sie gezielt nach Regeln, die im Text nur mitgemeint sind.

2:07 Dann kommt der Schritt, den ich Ihnen besonders ans Herz lege, und die Fußzeile sagt warum: Lassen Sie Widersprüche und Lücken benennen, aber nicht auflösen. Ein Assistent findet Widersprüche im Text zuverlässiger, als er sie auflösen kann. Und die Entscheidung im letzten Schritt bleibt bei Ihnen. Der erste Punkt ist verbreitet und gut gemeint: den Text vorab glätten, damit der Assistent es leichter hat.

2:31 Dabei löschen Sie genau die Unklarheiten, die zählen — und bekommen eine glatte Antwort auf eine geglättete Frage. Der zweite: das Ergebnis als Modell übernehmen statt als Kandidatenliste; damit überspringen Sie die eigentliche Arbeit. Und der dritte ist eine Frage des Zeitpunkts: nach der Lösung fragen, bevor die Frage überhaupt scharf ist.

2:51 Ein Assistent wird Ihnen dann eine Lösung liefern — nur eben für ein Problem, das so noch niemand hat.

Aus Beispieldaten Typmodelle erzeugen

2:57 Jetzt zum beliebtesten Anwendungsfall überhaupt: Man wirft ein paar echte Datensätze hinein und bekommt in Sekunden ein Typmodell. Das ist beeindruckend und praktisch — und es hat einen strukturellen Haken, den man einmal verstanden haben muss. Das Modell beschreibt die Beispiele, nicht die Regel. Aus einer Handvoll echter Datensätze entsteht in Sekunden ein Typvorschlag.

3:19 Der Haken ist strukturell, nicht ein Fehler des Werkzeugs — und diese Unterscheidung ist mir wichtig, weil sie bestimmt, wie man damit umgeht. Der Vorschlag beschreibt genau die vorgelegten Beispiele. Was in allen fünf Beispielen gefüllt war, erscheint als verpflichtend. Auch dann, wenn es fachlich fehlen darf und nur zufällig in dieser Stichprobe immer da war.

3:39 Das ist der klassische Rückschluss von der Stichprobe auf die Gesamtheit — und der geht schief, wenn die Stichprobe einen Fall nicht enthält. Vier Felder, und drei davon tragen eine Annahme, die niemand geprüft hat. Die Teilenummer war immer gefüllt, also gilt sie als Pflicht — das stimmt hier sogar. Der Lagerort war ebenfalls immer gefüllt, aber bei Streckenware gibt es keinen; das Modell weiß davon nichts, weil kein solcher Datensatz dabei war.

4:06 Der Preis war in den Beispielen ganzzahlig, was noch nichts über die Einheit sagt. Und das Nachfolgeteil gibt es nur bei bestimmten Teilen. Der Kern steht in der Fußzeile: Der Typ übersetzt anstandslos, weil ihn nichts mit echten Daten konfrontiert. Der Fehler wartet. Es lohnt sich, das nüchtern einzuordnen — auch weil die Debatte über KI-Code sonst schnell moralisch wird.

4:29 Aus fünf Beispielen lässt sich Optionalität nicht ableiten, nur beobachten. Das Modell kann nicht wissen, welcher Fall in der Stichprobe fehlt; niemand kann das. Und es gibt keinen Hinweis im Vorschlag, welche Felder geraten sind — dieselbe glatte Oberfläche für Gewusstes und Vermutetes. Deshalb der letzte Satz: Der Vorschlag ist ein Anfang und kein Ergebnis. Wer ihn so behandelt, gewinnt echte Zeit. Wer ihn als Ergebnis nimmt, verschiebt Arbeit in den Betrieb.

4:58 Der erste Punkt ist die häufigste Ursache und zugleich der einfachste Gegenzug: Beispieldaten nur aus dem Erfolgspfad vorlegen. Nehmen Sie die Sonderfälle mit hinein, dann sieht das Modell sie auch. Der zweite ist subtiler: Zahlen aus Beispielen ungeprüft übernehmen, wo eine Einheit fehlt — sind das Cent, Euro, Stück? Der Typ sagt „Zahl" und schweigt dazu.

5:19 Und der dritte fasst das Kapitel zusammen: den generierten Typ übernehmen, ohne den Sonderfall selbst zu suchen. Diese Suche kann Ihnen niemand abnehmen, denn sie setzt voraus, dass man das Geschäft kennt.

Fachliche Invarianten in Typen überführen

5:32 Jetzt zu einer Frage, die in jeder Modellierung auftaucht und selten bewusst entschieden wird: Wo gehört eine fachliche Regel eigentlich hin? Manche passen in einen Typ. Andere gehören in die Prüfung. Und eine dritte Gruppe braucht beides. Eine Invariante ist eine Regel, die immer gilt: Ein Betrag ist nie negativ, ein Zeitraum endet nie vor seinem Beginn, eine Freigabe kommt nie vor der Diagnose.

5:56 Ein Teil davon lässt sich in Typen ausdrücken — vor allem alles, was mit Reihenfolge und mit der Existenz von Feldern zu tun hat. Der Rest gehört sichtbar in die Validierung. Und jetzt das Entscheidende, das im Alltag am häufigsten schiefgeht: Er gehört nicht in einen Kommentar. Eine Regel im Kommentar ist eine Regel, die niemand prüft — freundlich formulierte Hoffnung.

6:19 Achten Sie auf das Ordnungsprinzip, dann brauchen Sie die Tabelle nicht auswendig. Alles, was mit der Existenz eines Feldes oder mit der Reihenfolge von Zuständen zu tun hat, gehört in den Typ — das kann der Compiler prüfen, und zwar vollständig. Alles, was einen Wertebereich betrifft oder zwei Werte zueinander in Beziehung setzt, gehört in die Validierung; davon weiß der Typ nichts.

6:40 Und die letzte Zeile zeigt den gemischten Fall: Der Typ trennt die Kennungen voneinander, die Prüfung bestätigt, dass die konkrete Kennung tatsächlich zu dieser Filiale gehört. Beides zusammen trägt. Oben der Typ: Der Betrag existiert nur im freigegebenen Zustand — das ist die Modellierung aus Modul 3, jetzt in einem konkreten Ausschnitt.

7:00 Unten die Prüfung: Der Betrag ist eine ganze, nicht negative Zahl. Beide Hälften gehören zusammen, keine ersetzt die andere. Und nun die Beobachtung aus der Praxis, die in der Fußzeile steht: Ein Assistent schlägt für beide Regeln meist nur den Typ vor. Die zweite Hälfte fehlt — und sie fehlt unauffällig, weil ja etwas dasteht, das nach Absicherung aussieht. Genau danach müssen Sie im Review suchen.

Generierte Interfaces bewerten

7:26 Kommen wir zum eigentlichen Lehrstoff dieses Moduls: einem Prüfgang, den Sie auf jeden generierten Typ anwenden können. Die Fragen funktionieren unabhängig vom Werkzeug und unabhängig vom Fachgebiet — und sie werden Sie auch dann noch tragen, wenn die heutigen Assistenten längst abgelöst sind. Fünf Fragen, und sie bauen aufeinander auf. Welche Aussage trifft dieser Typ über die Daten — was behauptet er eigentlich? Welche unmöglichen Zustände bleiben darstellbar?

7:53 Woher stammt jedes Feld: aus der Fachlichkeit oder aus den Beispielen? Was passiert, wenn die Daten dem Typ nicht entsprechen? Und schließlich: Welche absehbare Änderung macht dieses Modell teuer? Die Fußzeile weist auf Frage zwei als die schärfste hin, und das stimmt. Sie deckt genau das auf, was ein plausibel aussehender Typ verdeckt — die Lücken zwischen den Feldern, die niemand ansieht.

8:18 Diese Tabelle ist gewissermaßen die Lösung zur vorigen — was bei den fünf Fragen erfahrungsgemäß herauskommt. Ein generierter Typ trifft meist weniger Aussagen als erwartet; oft sind es nur Feldnamen mit Grundtypen. Was darstellbar bleibt, sind Kombinationen optionaler Felder, die es fachlich nicht geben darf. Die Felder stammen aus der Stichprobe.

8:38 Bei unpassenden Daten passiert nichts, weil es keine Prüfung gibt. Und teuer wird jede Änderung, die aus einem optionalen Feld ein verpflichtendes macht — dann rührt man jede Verwendungsstelle an. Der erste Punkt beschreibt, was fast alle tun: den Vorschlag lesen, statt ihn gegen die Fachlichkeit zu halten. Lesen heißt hier prüfen, ob es sinnvoll aussieht — und das tut es ja immer. Der zweite betrifft den Zeitpunkt: nach dem Modell fragen, obwohl die Anforderung noch verhandelt wird.

9:07 Dann zementieren Sie einen Zwischenstand. Und der dritte ist psychologisch und deshalb hartnäckig: Sich vom sauberen Aussehen des Vorschlags zur Zustimmung verleiten lassen. Ordentliche Formatierung ist kein fachliches Argument, wirkt aber wie eines.

Typische Fehler im generierten Typmodell

9:22 Jetzt werden wir konkret: fünf Muster, die sich in generierten Typmodellen wiederholen. Ich sage gleich dazu, was das ist und was nicht — es sind Beobachtungen aus der Praxis, keine Erhebung. Ihre Wirkung ist dagegen nachprüfbar, und genau so stelle ich sie vor. Sehen Sie sich vor allem die rechte Spalte an, denn die ist Ihr Werkzeug: Zu jedem Muster gibt es einen einfachen Handgriff, mit dem Sie es finden.

9:48 Der abschaltende Typ an Systemgrenzen — suchen Sie im Änderungssatz danach. Unnötige Behauptungen, die den Compiler übergehen — ebenfalls eine reine Suche. Optional statt leer — die Frage lautet immer: Darf das Feld fehlen, oder ist es da und leer? Ein Typ ohne Laufzeitprüfung — fragen Sie nach der Grenze. Übermodellierung erkennt man daran, dass niemand mehr die Fehlermeldungen versteht. Und die letzte Zeile hat es besonders in sich.

10:15 Diese Konfiguration bekommen Sie heute noch regelmäßig vorgeschlagen, und drei der vier Angaben sind Vergangenheit. Die alte Zielversion und die alte Modulauflösung sind seit Version 6.0 ein Fehler, nicht nur veraltet. Die Basispfad-Angabe entfällt in 7.0. Und die strenge Prüfung, die dort so gewissenhaft eingeschaltet wird, ist längst Voreinstellung — sie hinzuschreiben, ist bestenfalls überflüssig.

10:40 Das Bemerkenswerte: Diese Datei sieht aus wie eine sorgfältig gepflegte Konfiguration. Sie ist aber ein Schnappschuss aus einer Zeit, die vorbei ist. Die Erklärung ist unspektakulär und deshalb glaubwürdig. Version 6.0 kam im März 2026, Version 7.0 am 8. Juli 2026 — das ist sehr frisch. Trainingsdaten, die davor enden, kennen überwiegend die Fünfer-Ära, und die dauerte Jahre.

11:05 Dazu kommt ein menschlicher Faktor: Konfiguration wird selten geprüft, weil sie einmal geschrieben und dann vergessen wird. Die gute Nachricht steht im letzten Punkt: Der Compiler meldet das alles. Vorausgesetzt, jemand liest die Meldung — und liest sie nicht als Rauschen, das man wegkonfiguriert. Diese Tabelle ist mir wichtig, weil zu diesem Thema viele Zahlen kursieren, die niemand belegen kann.

11:32 Belegt ist: Typgebundenes Erzeugen halbiert Compilerfehler — gemessen an zwei bekannten Prüfsammlungen, für TypeScript, über Modelle verschiedener Größe und Herkunft. Nicht belegt ist die oft zitierte Behauptung, 94 Prozent der Fehler seien Typfehler. Nicht belegt sind Aussagen über gewachsene Projekte — die Prüfsammlungen bestehen aus kleinen, abgeschlossenen Aufgaben.

11:53 Und nicht belegt ist die Qualität der Typen, die im Dialog vorgeschlagen werden. Die Quelle steht in der Fußzeile.

Übung — Mensch gegen Modell

12:01 Und jetzt der direkte Vergleich. Sie modellieren, der Assistent modelliert, und dann sehen wir uns beide Ergebnisse mit denselben Fragen an. Die Überschrift setzt den Maßstab: Es geht nicht darum, wer schneller ist. Es geht darum, wessen Modell trägt. Das Lernziel ist bewusst so formuliert: ein generiertes Typmodell an fachlichen Kriterien prüfen, statt es an seiner Plausibilität zu messen.

12:25 Plausibilität ist der Maßstab, den wir alle instinktiv anlegen, und er versagt hier. Erfolgreich sind Sie, wenn Sie für beide Modelle benennen können, welche unmöglichen Zustände sie zulassen und welche absehbare Änderung sie teuer macht — für Ihr eigenes ebenso wie für das generierte. Wer früh fertig ist, legt dem Assistenten einen Datensatz mit dem Sonderfall vor und vergleicht den zweiten Vorschlag mit dem ersten. Das ist sehr aufschlussreich.

12:50 Die Reihenfolge ist wichtig: erst selbst modellieren, dann den Assistenten fragen. Andersherum ist der Vorschlag im Kopf und Sie schreiben eine Variante davon. Danach gehen Sie beide Modelle mit den fünf Prüffragen durch, notieren je Modell den darstellbar gebliebenen unmöglichen Zustand und spielen zum Schluss eine absehbare Änderung durch.

13:09 Die Fußzeile setzt den Bewertungsmaßstab und ich unterstreiche ihn: Bewertet wird nicht Eleganz, sondern was ausgeschlossen ist und was eine Änderung kostet. Beides lässt sich benennen — Eleganz nicht. Damit endet der erste Tag. Vier Sätze zum Mitnehmen: Ein Assistent liefert Rohmaterial, die fachliche Entscheidung bleibt bei Ihnen.

13:29 Aus Beispieldaten entstehen Beispieltypen, keine Regeln. Ein Teil der Invarianten gehört in den Typ, der Rest sichtbar in die Prüfung — nie in den Kommentar. Und die schärfste Prüffrage, die Sie ab jetzt bei jedem Modell stellen sollten: Welcher unmögliche Zustand bleibt darstellbar? Morgen bauen wir darauf auf und machen aus einzelnen Typen wiederverwendbare APIs.