Stille Post kennt jeder aus der Kindheit. Eine Person flüstert der nächsten ein Wort ins Ohr, die wiederum der nächsten, und am Ende des Kreises kommt etwas anderes heraus als am Anfang reingegangen ist. Niemand hat gelogen. Jeder hat ehrlich weitergegeben, was er gehört hat. Trotzdem stimmt das Endergebnis nicht.

Genau dieses Spiel passiert gerade in vielen Codebases, die mit KI-Werkzeugen weiterentwickelt werden. Nur dass am Ende kein Lacher steht, sondern ein Login, das nicht mehr funktioniert. Oder ein Bezahlvorgang, der für eine bestimmte Kundengruppe still im Hintergrund abbricht.

Für dieses Phänomen gibt es bisher keinen etablierten Begriff. Ich nenne es Type-Drift.

Daten in einer Software haben eine Form. Eine Telefonnummer ist eine Zeichenfolge. Ein Alter ist eine Zahl. Ein Bestellstatus ist entweder „offen", „bezahlt" oder „storniert". Diese Form heißt im Fachjargon Datentyp.

Wenn ein KI-Werkzeug an einer Stelle der Software etwas verändert, kann es vorkommen, dass die Form eines Datenfelds leicht angepasst wird. Aus einer Telefonnummer wird eine optionale Telefonnummer, die auch leer sein darf. Aus einer Zahl wird ein Text, der die Zahl enthält. Aus drei festen Zuständen werden vier.

Jede einzelne dieser Änderungen ist im Moment nachvollziehbar. Es gibt einen Grund für jede Anpassung, und niemand käme auf die Idee, sie zu hinterfragen.

Das Problem entsteht erst über die Zeit. Über mehrere Sprints, mehrere Pull Requests, mehrere KI-Sitzungen verschiebt sich die Form von Daten leise. Bis irgendwo im Code eine Stelle auf eine Form zugreift, die so nicht mehr existiert.

Stell dir eine Tabelle vor, in der ein Team über Monate hinweg Stundenberichte erfasst. In Spalte D stehen die Arbeitsstunden — eine Zahl. Beispielsweise 7,5.

Eines Tages stellt ein Kollege fest, dass manche Mitarbeitende halbe Stunden gerne als „7:30" schreiben. Er passt die Spalte an, sodass auch dieses Format akzeptiert wird. Sinnvoll.

Drei Wochen später taucht ein Eintrag mit „ca. 7,5" auf, weil jemand sich nicht festlegen konnte. Kollegin Nummer zwei erweitert das Format, sodass auch ein „ca." am Anfang erlaubt ist. Sinnvoll.

Sechs Wochen später erscheint „—" für einen Tag ohne Eintrag. Kollege Nummer drei lässt das Feld leer als gültigen Wert zu. Sinnvoll.

Niemand hat etwas falsch gemacht. Drei einzelne, gut begründete Anpassungen.

Am Quartalsende läuft die alte Auswertungsformel — die irgendwann jemand gebaut hat, der davon ausging, dass dort eine Zahl steht — gegen die Wand. Die Quartalsabrechnung stimmt nicht mehr. Niemand kann erklären, warum.

Das ist Type-Drift, übersetzt aus der Welt des Codes in die Welt einer Tabelle.

Der GitHub Octoverse Report 2025 hat eine Zahl veröffentlicht, die nachdenklich macht: 94 Prozent aller Kompilier-Fehler in KI-generiertem Code sind Typ-Fehler.

Das ist die sichtbare Spitze des Phänomens. Wenn der Compiler abbricht, ist klar: hier passt etwas nicht. Type-Drift ist die unsichtbare Variante derselben Familie — die Fälle, in denen der Compiler nichts merkt, die Tests grün sind, der Code in Produktion läuft, und der Bruch erst Wochen später auftaucht, an einer ganz anderen Stelle.

Wer aus der Welt des maschinellen Lernens kommt, kennt drei verwandte Begriffe: Data Drift, Model Drift und Concept Drift. Sie alle beschreiben, dass sich etwas in der Welt verändert hat und das Modell oder die Daten dem hinterherhinken.

Type-Drift ist anders. Hier verändert sich nicht die Welt. Hier verändert sich der Code, der die Welt abbildet — während die Welt gleich bleibt.

Kein Data Drift. Bei Data Drift verschiebt sich die Verteilung der echten Daten — die Welt verändert sich. Bei Type-Drift bleibt die Welt gleich. Was sich verändert, ist die Annahme im Code darüber, wie die Daten aussehen.

Kein Model Drift. Bei Model Drift wird ein bestehendes Modell mit der Zeit ungenauer, weil sich die Realität bewegt hat. Bei Type-Drift wird kein Modell ungenau — eine Codebasis verliert die Konsistenz mit sich selbst.

Keine Halluzination. Bei einer Halluzination erfindet das Modell etwas, das nie existiert hat — eine Datenbank-Spalte, die es im Schema gar nicht gibt, eine Programmbibliothek, die nicht existiert. Bei Type-Drift erfindet das Modell nichts. Alles, was es vorschlägt, existiert. Es passt nur in der Summe nicht mehr zusammen.

Kein Kontext-Verlust. Kontext-Verlust passiert innerhalb einer einzelnen Sitzung — das Modell vergisst während eines langen Gesprächs Anforderungen, die am Anfang formuliert wurden. Type-Drift passiert über mehrere Sitzungen hinweg, über Wochen, über mehrere Modell-Aufrufe in unterschiedlichen Pull Requests.

Type-Drift ist eigen: kumulativ, verteilt, plausibel an jedem einzelnen Punkt, problematisch nur in der Summe. Halluzination ist Erfindung. Type-Drift ist Akkumulation.

Drei Eigenschaften machen Type-Drift besonders unangenehm.

Erstens ist jede einzelne Änderung im Code-Review unauffällig. Wer einen Pull Request prüft, sieht nur die fünfzehn geänderten Zeilen. Was vor sechs Wochen an anderer Stelle in der Codebasis passiert ist, sieht der Prüfer nicht.

Zweitens gibt es keinen Moment, an dem die Drift sichtbar wird. Niemand schreibt einen Pull Request mit dem Titel „Wir ändern jetzt das Datenformat X von Zahl auf Text". Die Veränderung ist auf zehn kleine, jeweils unauffällige Änderungen verteilt.

Drittens ist die Wirkung räumlich entkoppelt von der Ursache. Der Bruch tritt am Frontend auf — verursacht wurde er aber irgendwo im Backend, vor mehreren Sprints. Wer im Frontend nach dem Fehler sucht, findet nichts.

Es gibt keine einzelne Maßnahme, die Type-Drift verhindert. Aber drei Dinge reduzieren das Risiko spürbar.

Eine geteilte Quelle der Wahrheit für Datentypen. Wenn die Form eines Datenfelds an genau einer Stelle definiert ist, und alle anderen Stellen sich von dort ableiten, fallen Inkonsistenzen schneller auf. In typisierten Sprachen bedeutet das: zentrale Schemata, abgeleitete Typen, kein Kopieren.

Migrations-Disziplin auch bei kleinen Änderungen. Eine Änderung am Datenformat — auch wenn sie minimal wirkt — bekommt einen eigenen Pull Request mit Migrations-Notiz. Nicht versteckt im Refactor.

Regelmäßiger Quervergleich. Eine wiederkehrende Aufgabe, die die wichtigsten Datenformate über die gesamte Codebasis hinweg auf Konsistenz prüft. Nicht das Ergebnis eines einzelnen Pull Requests, sondern eine Routine, die unabhängig läuft.

Stille Post ist im Spielzimmer harmlos. In einer Codebase, die täglich mit KI-Werkzeugen weiterentwickelt wird, ist sie ein wirtschaftliches Risiko, das selten auf einer Slide auftaucht. Der Aufwand für die Behebung erscheint in keinem Sprint-Plan, weil niemand vorher weiß, wann die Drift bricht.

Vielleicht ist das die ehrlichste Eigenschaft von Type-Drift: Sie passiert nicht, weil jemand schlecht arbeitet. Sie passiert, weil viele kleine, gut begründete Schritte ein Ergebnis produzieren, das niemand bewusst beschlossen hat.