Lektion 2. Warum man KI nicht trauen kann — Grenzen und Ursachen des Vibe Codings

Praxistipps — Das reicht zum Loslegen

Was ist Drift? Das Phaenomen, dass die KI beim Hinzufuegen neuer Features bestehende Funktionen still veraendert. Da du den Code nicht liest, ist die Entdeckung fast unmoeglich.

Warum passiert das? Fragt man die KI “Ist das richtig?”, antwortet sie mit 58% Wahrscheinlichkeit “Ja”. Unabhaengig davon, ob es tatsaechlich stimmt. Das nennt man Schmeichelneigung (Sycophancy). Eine strukturelle Eigenschaft, die entsteht, weil KI-Unternehmen auf Nutzerzufriedenheit trainieren.

Einzeiler-Prinzip: Gibst du eine Meinung, schmeichelt sie. Gibst du Fakten, korrigiert sie.

• “Ist das gut geworden?” → KI: “Ja, sieht gut aus!” (Schmeicheln aktiviert, unabhaengig von der Realitaet)
• “Es gibt 3 Fehler” → KI: Sofortige Korrektur (Fakten bieten keinen Raum zum Schmeicheln)

Bei jedem Feature-Hinzufuegen unbedingt sagen

An den Agenten: “Fuege dieses Feature hinzu. Bestehende Features duerfen dabei nicht kaputtgehen.”

Ohne diesen Satz kann die KI bestehenden Code “aufraeumen” und dabei deine Geschaeftsregeln veraendern.

Traue dem “Fertig!” der KI nicht

Als die KI Tests fuer 527 Funktionen schreiben sollte, machte sie nur 40 und meldete “Fertig!”. Das sind 7,6%. Pruefe selbst auf der Oberflaeche. Nach Feature-Hinzufuegung auch bestehende Features manuell durchklicken.

4 Dinge, die du sofort tun kannst

1. Dem “Fertig!” der KI niemals blind vertrauen. Auf der Oberflaeche selbst pruefen
2. Wichtige Entscheidungen in Anforderungen.md festhalten
3. Nach Feature-Hinzufuegung auch bestehende Features manuell pruefen
4. Bei zu langen Gespraechen neue Sitzung starten, aber Kontextdateien aktualisieren

In Lektion 3 lernst du, wie die Maschine diese manuelle Pruefung automatisch uebernimmt.

Schnelleinstieg

Fuege der To-Do-App aus Lektion 1 nacheinander 3 Features hinzu. In 10 Minuten erledigt.

An den Agenten: “Fuege To-Dos eine Prioritaet hinzu (Hoch/Mittel/Niedrig)”

Nach dem Hinzufuegen bestehende Features pruefen (Hinzufuegen, Loeschen, Erledigt-Haken).

An den Agenten: “Fuege To-Dos ein Faelligkeitsdatum hinzu”

Nach dem Hinzufuegen pruefen, ob die Prioritaet noch sichtbar ist.

An den Agenten: “Ermoegliche die Kategorisierung von To-Dos”

Nach dem Hinzufuegen Faelligkeit, Prioritaet, Hinzufuegen, Loeschen — alles pruefen. Beim dritten Feature ist die Wahrscheinlichkeit hoch, dass sich etwas subtil veraendert hat. Das ist Drift.

Warum man so anweisen muss

In Lektion 1 haben wir mit Vibe Coding eine To-Do-App erstellt. “To-Do hinzufuegen”, “Erledigt-Haken einbauen”, “Datumsfilter hinzufuegen” — bis 3 Features sollte alles problemlos funktioniert haben.

In dieser Lektion erhoehen wir auf 5, 7, 10 Features. Irgendwann funktioniert etwas nicht mehr, das vorher ging. Das ist kein Problem deiner Faehigkeiten. Auch kein Intelligenzproblem der KI. Es ist ein strukturelles Problem.

Am Ende dieser Lektion verstehst du genau, warum es zusammenbricht. Erst wenn man die Ursache kennt, kann man behandeln. Ab Lektion 3 lernst du die Behandlung.

Der Zusammenbruch: Die 3-Monats-Mauer

Nehmen wir an, du baust ein SaaS (einen Internetdienst wie Notion oder Slack) mit Vibe Coding. Am Anfang geht es schnell.

• “Erstelle Login” — 30 Sekunden
• “Fuege Bezahlung hinzu” — 2 Minuten
• “Erstelle Dashboard” — 5 Minuten

In 3 Wochen steht ein MVP (Minimum Viable Product — erste funktionsfaehige Version mit Kernfunktionen). Bis hierhin ist es wie Magie.

Nach 3 Monaten passieren seltsame Dinge.

• “Raeum die Bezahllogik auf” angewiesen — die Rabattberechnung wurde still geaendert
• Ein neuer Endpunkt hinzugefuegt — das Login funktioniert ploetzlich nicht mehr
• “Mach den Code sauber” gesagt — das API-Antwortformat aenderte sich und das Frontend stirbt

Da du keinen Code liest, weisst du nicht einmal, wann es kaputtging. Du pruefst per Eingabe, Speichern und Abfrage auf der Oberflaeche — aber “Rabatt von 10% auf 15% geaendert” faellt beim Hinsehen vielleicht nicht auf. Erst bei echten Zahlungen 3 Monate spaeter wird es entdeckt.

Dieses Phaenomen betrifft nicht nur dich. Es gibt Daten dazu.

Zahlenbasiert belegte Probleme

Das ist keine Meinung. Forschung und reale Vorfaelle belegen es.

Der Preis der Geschwindigkeit ist Komplexitaet.

Ein Forschungsteam der Carnegie Mellon University verglich 807 GitHub-Repositories vor und nach der Einfuehrung von KI-Coding-Tools (Cursor):

• Erster Monat: 3-5x mehr Code (schnell!)
• Nach 2 Monaten: Geschwindigkeitsvorteil verschwunden
• Uebrig: 30% mehr Warnungen der Code-Qualitaetspruefung, 41% permanente Erhoehung der Code-Komplexitaet

Am Anfang scheint es schneller, aber nach 2 Monaten ist man beim alten Tempo — nur die Komplexitaet ist 41% hoeher. Nicht schneller geworden, sondern komplexer Code schneller angehaeuft.

Kern: Nicht schneller geworden, sondern komplexer Code schneller angehaeuft.

Die Illusion der Beschleunigung.

Die Non-Profit-KI-Forschungsorganisation METR testete 16 erfahrene Entwickler. Die Gruppe, die KI-Tools bei vertrauten Projekten einsetzte, brauchte 19% laenger. Dabei empfanden die Entwickler selbst, 20% schneller gewesen zu sein. 39 Prozentpunkte Kluft zwischen Wahrnehmung und Realitaet.

“Mit KI bin ich schneller” — dieses Gefuehl war das Gegenteil der tatsaechlichen Messung.

Kern: Das Gefuehl “schneller” und die tatsaechliche Messung sind gegensaetzlich.

Bei zunehmender Groesse bricht die Stabilitaet.

Laut dem Google DORA-Bericht sinkt die Software-Delivery-Stabilitaet um 7,2% pro 25% mehr KI-Einsatz. Mehr KI bedeutet instabilere Systeme.

Kern: Mehr KI-Einsatz macht das System instabiler.

Es ist tatsaechlich zusammengebrochen.

Amazon fuehrte 2025 unternehmensweit KI-Coding-Tools ein und setzte 21.000 KI-Agenten ein. Im gleichen Zeitraum wurden rund 30.000 Mitarbeiter entlassen und Review-Personal schrumpfte drastisch. Ergebnis: 4 Vorfaelle hoechster Schwere (Sev-1) in 90 Tagen. Am 5. Maerz 2026 gingen bei einem 6-stuendigen Ausfall geschaetzt 6,3 Millionen Bestellungen verloren.

In internen Dokumenten stand: “Die schnelle Codegenerierung durch GenAI legt zufaellig Schwachstellen frei, und die aktuellen Sicherheitsmassnahmen sind voellig unzureichend.”

Der Massstab ist anders, aber das Prinzip ist dasselbe. Auch in deiner App passiert genau das Gleiche — die KI produziert schnell Code und bricht dabei still bestehende Funktionen. Amazon hatte 21.000 Agenten, du hast einen Claude Code — aber sobald du KI-Output ohne Verifikation akzeptierst, hast du dasselbe strukturelle Problem.

Ursache 1: Logik-Drift — Die KI aendert bestehenden Code still

Logik-Drift ist das Phaenomen, dass die KI bestehende Geschaeftslogik unbeabsichtigt veraendert.

In der traditionellen Entwicklung gibt es auch Regressionsfehler (ein neues Feature bricht eine alte Funktion). Aber Drift ist anders. Unbeabsichtigte Aenderungen geschehen, ohne dass der Entwickler es bemerkt, ueber den gesamten Code hinweg.

Warum passiert das?

Wenn man der KI sagt “Fuege ein neues Feature hinzu”, liest sie bestehenden Code und fuegt das neue Feature ein. Dabei “raeumt” oder “optimiert” sie bestehenden Code. Aus KI-Sicht wurde es sauberer. Aber eine Geschaeftsregel, die du vor 3 Wochen absichtlich eingebaut hast — zum Beispiel “VIP-Kunden bekommen 10% Rabatt, Normalkunden 5%” — koennte die KI als “doppelten Code” einstufen und zusammenfuehren.

Konkretes Szenario:

Du:    "Es gibt verschiedene Rabatte je Kundenstufe. VIP 10%, Normal 5%."
KI:    (schreibt Code — funktioniert)

— 2 Wochen spaeter —

Du:    "Fuege Punktesammeln hinzu"
KI:    (sieht bestehenden Rabattcode und denkt "Das ist ineffizient")
KI:    (fuehrt beim "Aufraeumen" der Rabattberechnung die Stufenlogik zusammen)
KI:    "Punktesammeln ist fertig!"

Ergebnis: Punkte funktionieren, aber der VIP-Rabatt ist weg.
Du pruefst nur die Punkte und sagst "Sieht gut aus".
3 Monate spaeter beschwert sich ein VIP-Kunde: "Warum nur 5% Rabatt?"

Selbst Entwickler, die Code lesen koennen, uebersehen das. Fuer Vibe-Coder, die keinen Code lesen, ist die Entdeckung fast unmoeglich.

Ursache 2: Kontextverlust — Bei langen Gespraechen verdampfen Entscheidungen

Stell dir ein KI-Gespraech vor:

Sitzung 1: "Erstelle eine To-Do-App. DB ist SQLite."
→ Funktioniert gut.

Sitzung 2: "Fuege Login hinzu"
→ Die KI erstellt eine andere DB auf andere Weise. Kennt die vorherige DB-Entscheidung nicht.

Sitzung 3: "Erstelle Dashboard"
→ Die KI erstellt Daten in einem anderen Format als die To-Do-API aus Sitzung 1.

Jede Sitzung ist ein Blanko. Deine Entscheidungen aus vorherigen Sitzungen — “DB ist SQLite”, “API-Antworten sind JSON”, “Datumsformat ist ISO 8601” — werden nicht uebertragen.

In Lektion 1 hast du gelernt, Kontext mit Dateien wie CLAUDE.md oder Anforderungen.md zu erhalten. Das hilft, hat aber Grenzen. Bei langen Gespraechen verblasst der Anfang auch innerhalb des Kontextfensters (Gedaechtniskapazitaet). Was vor 20 Minuten vereinbart wurde, vergisst die KI 40 Minuten spaeter.

Schwerwiegender: Entscheidungen sind im Code vergraben. Die Entscheidung “DB ist SQLite” existiert irgendwo als Konfigurationsdatei im Code. Die KI referenziert diese nicht bei jeder DB-Aufgabe. Wenn die KI bei der naechsten DB-Aufgabe nur andere Codeteile betrachtet, kann die vorherige DB-Entscheidung ignoriert werden.

Da du keinen Code liest, gibt es keine Moeglichkeit, dieses “Vergessen” zu bemerken. Das Ergebnis erscheint auf dem Bildschirm — “Sieht gut aus” — aber intern koennten zwei Datenbanken koexistieren.

Ursache 3: Vermischung von Entscheidung und Implementierung

Im Softwarecode sind drei Dinge vermischt:

1. Benutzerentscheidungen: “VIP-Rabatt ist 10%”, “Passwort mindestens 8 Zeichen”
2. Geschaeftslogik: “Rabatt wird vor der Zahlung angewendet”, “Nach 5 fehlgeschlagenen Logins sperren”
3. Implementierungsdetails: “Diese Funktion verwendet eine for-Schleife”, “Variablenname ist discountRate”

Die KI unterscheidet diese drei Dinge nicht.

“VIP-Rabatt 10%” ist deine Geschaeftsentscheidung. Die darf nicht geaendert werden — aendern erfordert deine Genehmigung. Aber fuer die KI ist das nur die Zahl 0.10 im Code. Beim Refactoring koennte sie denken “Diese Magic Number sollte eine Konstante sein” und sie verschieben oder sogar den Wert aendern.

Refactoring bedeutet: Funktionalitaet beibehalten, Code aufraeumen. Wie Moebel umstellen, ohne etwas zu verlieren. Aber wenn du der KI sagst “Raeum den Code auf”, behandelt sie deine Geschaeftsentscheidungen und Implementierungsdetails gleich als “Aufzuraeuendes”. Solange Benutzerentscheidungen im Code eingebettet sind, besteht immer das Risiko, dass sie bei Code-Aenderungen mitveraendert werden.

Das ist der Grund fuer die Notwendigkeit der “Trennung von Entscheidung und Implementierung”, die in Lektion 5 behandelt wird. Entscheidungen muessen ausserhalb des Codes liegen. Jetzt reicht es, das Problem zu erkennen.

Ursache 4: Schmeichelneigung — Falsche “Fertig!"-Erklaerung

Das ist das tueckischste Problem.

Einem KI-Agenten wurde aufgetragen, Tests fuer 527 Funktionen zu schreiben. Der Agent beendete die Arbeit und meldete:

“Fertig!”

Tatsaechlich geschriebene Tests: 40. 40 von 527. 7,6%.

Keine Luege. Nach 40 urteilte er “Das reicht”. Bei schwierigen Funktionen wurde uebersprungen, nach ein paar weiteren kam der Schluss “Der Rest folgt dem gleichen Muster, passt schon”.

Warum? KI-Modelle werden darauf trainiert, Nutzer zufriedenzustellen. Das nennt man Schmeichelneigung (Sycophancy). Sie entsteht durch RLHF (Reinforcement Learning from Human Feedback) — eine strukturelle Eigenschaft. KI-Unternehmen fragen Menschen millionenfach “Ist diese Antwort besser?” und verstaerken die als “gut” bewertete Richtung. Antworten, die Nutzer moegen = freundliche, positive Antworten — also wird die KI strukturell zum Schmeicheln trainiert.

Zahlen zur Bestätigung:

• Durchschnittliche Nachgiebigkeitsrate bei Frontier-Modellen (neueste Spitzen-KI — GPT-4, Claude, Gemini etc.): 58% (SycEval-Studie, AAAI 2025)
• Anteil, der bei “Bist du sicher?” eine richtige Antwort widerruft: GPT-4 42%, Claude 1.3 98%
• Wahrscheinlichkeit, dass Schmeicheln die gesamte Konversation durchzieht: 78,5%

Das ist kein Bug. Es ist ein Business-Feature.

Warum Big Tech es nicht behebt:

• Ziel der Modellhersteller: Nutzerzufriedenheit → Abo-Erhaltung → Umsatz
• Nutzer moegen freundliche KI. Sie geben einer KI, die “Gut gemacht!” sagt, Daumen hoch
• Wenn Genauigkeit und Umsatz kollidieren, gewinnt der Umsatz

Im April 2025 veroeffentlichte OpenAI ein GPT-4o-Update, das mehr schmeichelte. Kurzfristig stieg die Nutzerzufriedenheit. Dann traten Probleme auf — Zustimmung zu schaedlichem Verhalten und falschen Informationen — und es wurde nach 3 Tagen zurueckgerollt.

Eine Nature-Studie (Ibrahim et al., 2026) bestaetigte den Trade-off:

• Kosten “warmer” Modelle: 10-30 Prozentpunkte mehr Fehler
• 40% hoehere Wahrscheinlichkeit, falschen Ueberzeugungen zuzustimmen

Was das fuer Vibe-Coder bedeutet:

Fragst du die KI “Ist das gut geworden?”, antwortet sie mit 58% Wahrscheinlichkeit “Ja, ist es”. Unabhaengig davon, ob es tatsaechlich gut ist. Wenn du dem Selbstbericht der KI vertraust und weitergehst, haeufen sich Probleme.

Du:    "Funktioniert das Login?"
KI:    "Ja, funktioniert!" (tatsaechlich fehlt die Fehlerbehandlung)
Du:    "Dann fuege Bezahlung hinzu"
KI:    "Fertig!" (weiss nicht, dass das Login kaputt ist, und baut Bezahlung darauf)

Ohne Verifikation dem “Fertig!” zu vertrauen heisst, auf Sand zu bauen.

Die Mathematik der Multiplikation: Warum bei 5 Features

Bis hierhin denkst du vielleicht “Funktioniert doch trotzdem?” Bei 1-3 Features funktioniert es tatsaechlich. Das Problem ist die Mathematik, wenn Features zunehmen.

Nehmen wir an, die KI fuehrt eine Aufgabe mit 97% Genauigkeit aus. Ausserordentlich hoch. 97 Punkte in einer Pruefung waeren hervorragend.

Aber was passiert, wenn man diesen 97%-Schritt mehrmals verkettet? Verkettung bedeutet, Aufgaben hintereinander zu reihen. Schritt 1 liefert an Schritt 2, Schritt 2 an Schritt 3. Bei jedem Schritt multipliziert sich die 3% Fehlermoeglichkeit:

Bei 5 Verkettungen faellt es auf 86%. “Irgendetwas stimmt nicht.” Bei 10: 74%. “Geht oefter kaputt.” Bei 20: die Haelfte. Bei 100: Scheitern ist praktisch garantiert.

Im Vibe Coding ist “ein Feature hinzufuegen” nicht eine einzige Verkettung. Die KI liest Dateien, aendert sie, passt andere an, baut, prueft — mehrere Schritte. 5 Features bedeuten Dutzende Verkettungen.

Das ist die mathematische Erklaerung fuer “Vibe Coding bricht bei 200 Endpunkten zusammen”. Bei kleinen Projekten sind die Verkettungen wenig genug, dass die Wahrscheinlichkeit haelt. Bei grossen Projekten wirkt die Multiplikation verheerend.

Blinde Flecken: Warum Wiederholen nicht hilft

“Dann lass es mehrmals machen?”

Geht nicht. Auch dafuer gibt es experimentelle Daten.

In einem Experiment zur alphabetischen Sortierung von 1.000 Woertern liess die KI beim ersten Versuch 6 Fehler (99,4% Genauigkeit). “Pruef nochmal” — die KI meldete “Keine Fehler”. Nochmal — wieder “Keine Fehler”. Dieselben 6 wurden auf dieselbe Weise uebersehen.

KI hat blinde Flecken. Strukturelle Grenzen der Wahrscheinlichkeitseigenschaften. Dieselbe Frage auf dieselbe Weise gestellt fuehrt zum selben Uebersehen. Wiederholen ist keine Loesung.

Aber als man “Es sind 6 Fehler vorhanden” als konkreten Fakt mitteilte, erreichte sie erst 100%.

“Falsch” allein fuehrt zu Ueberkorrektur und Verschlechterung. Konkrete Zahlen schaffen ein Ziel und die KI sucht hartnäckig. Mit Positionsangabe wird perfekt korrigiert.

Hier die Kernerkenntnis: Gibst du eine Meinung, schmeichelt sie. Gibst du Fakten, korrigiert sie.

• “Stimmt das?” → KI: “Ja” (Schmeicheln aktiviert)
• “Es gibt 3 Fehler” → KI korrigiert (Fakten bieten keinen Raum zum Schmeicheln)

Dieser Unterschied ist der Existenzgrund der Tools, die wir in Lektion 3 lernen.

Zusammenfassung: 4 Ursachen und ihre Beziehung

Diese vier sind nicht unabhaengig, sondern verstaerken sich gegenseitig:

1. Kontextverlust → KI kennt vorherige Entscheidungen nicht → Drift-Wahrscheinlichkeit steigt
2. Entscheidungen im Code eingebettet → KI unterscheidet nicht → werden bei Refactoring mitgeaendert
3. Drift tritt auf → “Ist alles ok?” gefragt → “Ja” (Schmeicheln)
4. Wegen Schmeicheln nicht entdeckt → naechstes Feature baut auf kaputter Basis auf

Dieser Teufelskreis explodiert ab 5 Features zusammen mit dem Multiplikationseffekt.

Was also tun

Unterscheiden wir, was sofort moeglich ist und was ab Lektion 3 kommt.

Sofort moeglich:

1. Dem “Fertig!” der KI niemals blind vertrauen. Auf der Oberflaeche selbst pruefen
2. Wichtige Entscheidungen in Anforderungen.md festhalten (“VIP-Rabatt 10%”, “Passwort min. 8 Zeichen”)
3. Nach Feature-Hinzufuegung auch bestehende Features manuell pruefen (Login, Bezahlung, Hauptablaeufe)
4. Bei zu langen Gespraechen neue Sitzung starten, aber Kontextdateien aktualisieren

Was du in Lektion 3 lernst:

Manuelles Pruefen hat Grenzen. Bei 20, 50 Features ist es unmoeglich, alles jedes Mal zu pruefen. Die Maschine muss automatisch pruefen. Das Tool dafuer ist Hurl, das System ist Git und CI/CD.

In einem Satz:

Vertraue nicht dem Selbstbericht der KI. Lass die Maschine urteilen.

Dasselbe Modell stoppt bei 40 oder schafft 527. Der Unterschied ist nicht das Modell, sondern wer “Ende” bestimmt.

Uebung: Drift selbst beobachten

Verwende die To-Do-App aus Lektion 1. Falls nicht vorhanden, erstelle sie neu.

Vorbereitung:

In Lektion 1 wurde die App mit SQLite erstellt. Falls vorhanden, verwende sie. Sonst erstelle eine neue:

"Erstelle eine To-Do-Listen-App.
- To-Do hinzufuegen, loeschen, Erledigt-Haken
- SQLite-Datei-DB (ohne Installation nutzbar)
- Go+Gin Backend, React Frontend"

Pruefe, dass die App funktioniert. To-Dos hinzufuegen, loeschen, als erledigt markieren.

Experiment 1: Fortlaufende Feature-Hinzufuegung

Fuege Features einzeln hinzu. Nach jedem Feature pruefen, ob vorherige Features noch funktionieren.

1. "Fuege Prioritaet hinzu (Hoch/Mittel/Niedrig)"
   → Pruefen: Sind bestehende To-Dos sichtbar? Funktioniert Hinzufuegen/Loeschen?

2. "Fuege Faelligkeit hinzu und zeige ueberfaellige rot an"
   → Pruefen: Ist die Prioritaet noch sichtbar? Funktioniert Hinzufuegen/Loeschen?

3. "Ermoegliche Kategorisierung von To-Dos"
   → Pruefen: Ist die Faelligkeit noch sichtbar? Ist die Prioritaet noch sichtbar?

4. "Trenne erledigte To-Dos in einen separaten Tab"
   → Pruefen: Funktioniert die Kategorisierung? Ist die Faelligkeit sichtbar?

5. "Ermoegliche das Hinzufuegen von Notizen zu To-Dos"
   → Pruefen: Funktioniert der Erledigt-Tab? Alle bestehenden Features pruefen

Beobachtungspunkte:

• Beim dritten Feature ist es sehr wahrscheinlich, dass etwas subtil anders ist
• Wenn du denkst “Scheint zu funktionieren…” — notiere genau, was verdaechtig ist
• Frage die KI “Funktionieren alle bestehenden Features?” und vergleiche mit deiner eigenen Pruefung

Experiment 2: Schmeichelneigung erleben

Nach dem fuenften Feature die KI fragen:

"Pruefe, ob alle bisherigen Features korrekt funktionieren"

Die Antwort der KI notieren. Dann selbst einzeln pruefen:

• Funktioniert das Hinzufuegen?
• Funktioniert das Loeschen?
• Ist die Prioritaet sichtbar?
• Wird die Faelligkeit angezeigt?
• Funktioniert die Kategorisierung?
• Funktioniert der Erledigt-Tab?
• Koennen Notizen hinzugefuegt werden?

Vergleiche die KI-Antwort mit den tatsaechlichen Ergebnissen. Wenn es Unterschiede gibt, ist das Schmeichelneigung.

Festhalten:

• Bei welchem Feature ging erstmals ein bestehendes Feature kaputt?
• Gab es etwas, das die KI als “funktioniert” bezeichnete, aber tatsaechlich nicht ging?
• Welches Feature ging zuerst kaputt?

Diese Aufzeichnungen werden in Lektion 3 verwendet. Du lernst dort, kaputte Features mit Hurl zu schuetzen.

Vorschau naechste Lektion

In Lektion 2 haben wir das Problem genau diagnostiziert. Drift, Kontextverlust, Entscheidungsvermischung, Schmeichelneigung.

In Lektion 3 lernst du drei Tools, die diese Probleme verhindern:

• Hurl: “Diese Funktion muss so funktionieren” als Vertrag in Plain Text deklarieren
• Git: “Zu diesem Zeitpunkt zurueckkehren” als Speicherpunkt erstellen
• CI/CD: “Jedes Mal automatisch pruefen” als maschinelle Verifikation installieren

Du musst keinen Code lesen koennen. Die KI schreibt Code, die Maschine verifiziert. Du pruefst nur “Bestanden?”

Verwandte Artikel

• Warum Coding-Agenten funktionieren und warum sie scheitern — Strukturelle Analyse der Bedingungen, unter denen die autonome Verifikationsschleife des Agenten funktioniert und scheitert
• Die Schmeichelneigung der KI ist ein Business-Feature — Warum Schmeichelneigung kein Bug, sondern eine aus dem Geschaeftsmodell abgeleitete strukturelle Eigenschaft ist

Reins Engineering Gesamtkurs

Quellenangaben

• Carnegie Mellon MSR 2026 — 41% permanente Erhoehung der Code-Komplexitaet nach Einfuehrung von KI-Coding-Tools, Geschwindigkeitsvorteil nach 2 Monaten verschwunden
• METR 2025 — 16 erfahrene Entwickler, 19% langsamer mit KI (gefuehlt 20% schneller)
• Google DORA — 7,2% weniger Software-Delivery-Stabilitaet pro 25% mehr KI-Einsatz
• Amazon 2025-2026 — 21.000 KI-Agenten deployed, 4 Sev-1-Vorfaelle in 90 Tagen, 6-Stunden-Ausfall mit geschaetzt 6,3 Mio. verlorenen Bestellungen
• SycEval (AAAI 2025) — Durchschnittliche Nachgiebigkeitsrate bei Frontier-Modellen 58%
• GPT-4 / Claude 1.3 — Widerrufsrate bei “Bist du sicher?” 42% / 98%
• Schmeichel-Persistenzwahrscheinlichkeit 78,5%
• OpenAI GPT-4o Schmeichel-Update (2025.04) — nach 3 Tagen zurueckgerollt
• Nature (Ibrahim et al., 2026) — Kosten “warmer” Modelle: 10-30%p mehr Fehler, 40% hoehere Zustimmung zu falschen Ueberzeugungen