Einleitung

Über Artificial Intelligence hat heute jeder seinen Hot Take, und die meisten davon sind textbook Dunning-Kruger: maximale Confidence bei minimaler Coverage. Solange das Cocktailparty-Geplauder bleibt, ist es harmlos; kritisch wird es, sobald aus opinion-driven Pseudo-Expertise handfeste Entscheidungen werden, im Zweifel als HiPPO durchgedrückt, Highest Paid Person’s Opinion.

Aus derselben shaky Baseline ziehen zwei Camps gegensätzliche Schlüsse, und beide liegen daneben. Die einen bannen die KI aus reiner Technophobie und FUD, die anderen sliden ins andere Extrem, Automation Bias in Reinform, und hoffen, das Modell werde das Mitdenken schon end-to-end übernehmen. Beide produzieren Schaden: Die Laggards verschenken ein mächtiges Asset, die Over-Reliance-Fraktion deployt es ausgerechnet dort, wo es maximalen Damage anrichtet.

Der eigentliche Plot-Twist, der diesen Artikel trägt: Gerade die gut gemeinten Denkverbote sind ein Paradebeispiel für den Cobra-Effekt, sie schaden, statt zu schützen, und treiben die Leute geradewegs in die Shadow AI. Dass sich KI nicht nur mit mehr Velocity, sondern auch sicherer und sustainable einsetzen lässt, ist kein Wishful Thinking, sondern zeigbar. Und das nicht nur im Coding.

Alles konvergiert auf ein einziges Ziel: ein Framework, das gerade beim Programmieren das gefährliche Halluzinieren sauber ge-guardrailt bekommt, ohne der KI die Fähigkeit zu nehmen, die sie überhaupt erst nützlich macht. Wie diese Hallucination Mitigation gelingt, ohne die Kreativität zu killen, klingt zunächst widersprüchlich und ist der eigentliche Core dieses Textes.

Vorher aber muss ein Mental Model weichen, das fast jeden misleadet. Es klingt absurd und ist doch der Key zu allem Weiteren: Eine KI muss halluzinieren dürfen.

Eine KI muss halluzinieren dürfen

Das alte Science-Fiction-Promise, ein Computer erre nie, ist legit, nur referenziert es den Algorithmus, nicht die KI. Ein Algorithmus ist deterministisch, im Grunde eine pure function: same Input, same Output, hundertprozentig reproduzierbar, und wenn er failt, dann nur, weil jemand ihn falsch implementiert hat.

Die KI verdankt ihren Value dem genauen Gegenteil. Ihre Kernkompetenz ist Generalisierung, neudeutsch Transfer Learning: Sie überträgt Erfahrung auf ein Problem, das sie so nie im Trainingsset gesehen hat. Ein Algorithmus kann das nicht, weil ich jeden neuen Case erst vordenken und hard-coden müsste, womit er nicht mehr neu wäre.

Übertragen kann aber nur, wer fuzzy erinnert, statt stur zu lookup-en. Eine KI zieht nicht den einen exakten Record, sie interpoliert im Vektorraum aus vielen ähnlichen Embeddings etwas Passendes zusammen, sodass der Kern stimmt, während die Details verschwimmen.

Genau dieses Verschwimmen, die kleine Deviation vom exakt Gespeicherten, nennen wir Halluzinieren, eigentlich treffender Konfabulation, und kaum ein Term ist schlechter beleumundet. Dabei ist es nur der Nebeneffekt davon, sich nicht hundertprozentig erinnern zu können, eine Frage der Temperature sozusagen, und wer ihn einkalkuliert, für den ist er harmlos. Verteufelt wird er trotzdem, als wäre er der Geburtsfehler der ganzen Technik, obwohl er die Precondition dafür ist, dass eine KI überhaupt Neues lösen kann. Nehmen wir ihr das Halluzinieren, nehmen wir ihr das Denken.

Man kann eine KI durchaus auf Temperature 0 zwingen, sodass sie nur noch exakt Memorisiertes ausgibt und nie mehr deviated. Dann hat man aber keine KI mehr, sondern eine glorified Lookup-Table, teuer und langsam obendrein, die genau das verloren hat, was sie von einer gewöhnlichen Datenbank unterschied: die Fähigkeit, ein neues Problem zu lösen. Nichts als Memorization.

Bleibt die Kehrseite, an die jeder sofort denkt, die fabrizierte Quelle, das Urteil, das es nie gab, der Call einer Funktion, die nicht existiert, im Coding mittlerweile als API- oder Package-Halluzination berüchtigt. Auch das ist Konfabulation, dasselbe Phänomen, nur am falschen Spot. Der Fehler liegt nicht darin, dass die KI halluziniert, sondern darin, dass wir exakte Fakten von ihr verlangen, ohne ihr Function Calling fürs Grounding zu geben. Wie sich das verhindern lässt, ohne die Kreativität zu killen, ist die eigentliche Story dieses Textes, und sie beginnt mit einer Einsicht, die so banal ist, dass man sie permanent skippt.

Eine KI ist keine Datenbank.

Fit for Purpose: Eine KI ist keine Datenbank

Eine KI ist keine Datenbank. Klingt nach einer Binsenweisheit, und doch wird gegen kaum ein Prinzip so oft verstoßen: Man feuert eine Query, deren Antwort exakt und nachprüfbar sein muss, bekommt etwas plausibel Klingendes, aber faktisch Falsches, confidently incorrect, und schimpft auf die KI, obwohl man schlicht das falsche Instrument gegriffen hat. Fit for purpose, right tool for the job, darum geht es.

Das bekannteste Counter-Example hat es bis in die Tagespresse geschafft, der Anwalt, der einen AI-generierten Schriftsatz einreichte und dessen schön formulierte Präzedenzfälle sich samt Aktenzeichen als komplett fabricated herausstellten. Nur war das kein Failure der KI, sondern ein klassisches Layer-8-Problem: Er hat von einer probabilistischen Engine deterministische Fakten verlangt. Fairerweise stammt der Case aus einer Ära, in der die Modelle noch kein eigenes Retrieval konnten; er hätte die Fundstellen mit der KI gemeinsam gegen eine echte Datenbank verifizieren müssen, Human-in-the-loop, statt sich auf ihre Erinnerung zu verlassen.

Denn so sieht die saubere Separation of Concerns aus: Die Datenbank liefert die exakten Fakten, Aktenzeichen, Paragraph, die genaue API. Die KI liefert das Intent Recognition, sie versteht, was man eigentlich sucht, übersetzt eine vage Frage per NL2SQL in die richtige Query und das Ergebnis zurück in eine Antwort. Eine KI ist keine Datenbank, aber sie kann eine per Tool Use ansteuern, und erst dieses RAG-Pattern macht aus zwei Komponenten ein gutes.

Der zweite Key: Eine KI kann heute selbst nachschlagen und ihre Sources prüfen. Sie macht es, wie ein erfahrener Arzt, der das Pattern meist on sight erkennt und trotzdem weiß, wann er die Differentialdiagnose im Buch nachschlägt, nur dann, wenn sie es für nötig hält und der Overhead vertretbar bleibt. Genau dort, wo es gefährlich wird, lässt sich das Halluzinieren also entschärfen, sobald wir ihr das Retrieval einfach und low-latency machen. Wie das geht, kommt später; zuerst schauen wir uns an, wo eine KI angeblich überhaupt nichts zu suchen hat.

KI im kritischen Umfeld: nur lesen, nicht eingreifen

Es gibt einen Spot, an dem fast jeder sofort abwinkt, hier habe eine KI nichts verloren. Ein Server, egal welcher, auf dem viel zusammenläuft, zahllose Interfaces nach außen, attached Devices, komplexe Wechselwirkungen, hat gerade einen Incident, dessen Root Cause niemand kennt. Eine aktuelle Doku existiert natürlich nicht, das Wissen ist reines Tribal Knowledge, es ist die Maschine eines Kunden, und der Fehler muss schnell weg, das SLA tickt.

Wer jetzt vorschlägt, eine KI darauf anzusetzen, erntet entsetzte Blicke, gerade von non-technical Decision-Makern, und in vielen Häusern ist es schlicht per Policy verboten. Die Bedenken sind legit: Auf einem Mission-Critical-Production-System kann eine KI echten Damage anrichten, Daten zerstören, den Betrieb lahmlegen, und dann ist da noch die Liability-Frage; hinterher fehlt jeder Audit Trail, niemand weiß, was sie geändert hat; und sensible Daten könnten als Data Exfiltration nach außen leaken. Jeder dieser Punkte ist berechtigt.

Nur lohnt ein kurzes Reframing der Conclusion. Die drei Punkte sagen, dass die KI nichts verändern darf und nichts hinausfließen darf. Sie sagen nicht, dass sie den Incident nicht analysieren darf.

Damit ist die Sache fast gelöst. Wir setzen die KI nicht zum Reparieren ein, sondern für reine Observability: Sie liest, wertet aus und sucht, strikt read-only und non-intrusive. Die ersten beiden Bedenken sind damit erledigt, weil ohne Write Access nichts kaputtgeht und kein Chaos zurückbleibt, und weil am Ende ein Mensch entscheidet und das Deployment selbst durchführt, bleibt die Accountability sauber bei ihm, Human-in-the-loop by design.

Praktisch braucht die KI dafür nur Access zu den richtigen Logs. Um tiefer zu graben, nutze ich ein kleines, selbstgeschriebenes Utility, dem ich vertraue, weil ich genau weiß, was es tut und vor allem was es nicht tut, im Grunde ein read-only MCP-Server: Es liefert on demand die passenden Logs zu einem bestimmten Zeitfenster, kompakt und ausschließlich lesend, und reicht sie der KI. Die macht dann erstaunlich schnell die Triage, etwa wenn eine Dependency auf eine neue Version gebumpt wurde und die Gegenstelle ihre API geändert hat, ein klassischer Breaking Change ohne sauberes Semantic Versioning, während der Server nicht nachgezogen wurde. Wir kicken ein paar Tests an, lassen die Results bewerten und nähern uns Schritt für Schritt der Root Cause. Manuell ginge das auch, nur säßen wir erst Stunden im Onboarding.

Ernster ist der dritte Einwand, die Data Exfiltration. Was auf keinen Fall nach außen darf, sind Credentials, Geschäftsgeheimnisse, PII, und die Lösung ist trivialer, als viele denken: ein kleines, self-hosted Modell on premise, sodass die Logs im Haus bleiben, die Data Residency gewahrt ist und nichts zu einem fremden Vendor oder in dessen Training wandert.

Damit fällt auch der Reflex, man müsse stets das größte Frontier-Modell nehmen. Fürs Durchforsten von Logs nach Anomalien, die man vorher gar nicht kennt, klassische Anomaly Detection, ist das nicht nur unnötig, sondern hinderlich, weil die SOTA-Modelle teuer und latenzschwach sind. Ob ich auf zwanzig, dreißig Logs zehn Minuten oder zwanzig Sekunden warte, macht einen Unterschied für die Konzentration, nicht nur für die Geduld, am Ende ein reines Latency-Game. Dass self-hosted Small Language Models nichts taugten, ist genau so ein Bias wie die anderen.

Und das Halluzinieren, vor dem die ganze Welt warnt, ist hier ein Non-Issue, weil wir jede Hypothese gegen die Ground Truth verifizieren können, gegen die Logs, gegen einen Test, ein sauberer Closed Loop. Die KI darf ruhig mal danebenliegen, low-stakes und fail-safe, es kostet uns nichts.

Aus dem vermeintlichen Totalverbot ist so ein geradezu idealer Use Case geworden, der Sweet Spot schlechthin: Kein berechtigtes Bedenken wurde übergangen, alles compliant by design, und trotzdem liefert die KI genau dort Augmentation, wo ein Mensch unter Zeitdruck am ehesten etwas übersieht. Wieder nur fit for purpose, das richtige Instrument für die richtige Aufgabe.

Bisher haben wir die KI strikt read-only gehalten. Wagen wir den nächsten Schritt und geben ihr Write Access, lassen sie an einer echten Mutation mitwirken.

Ein Schritt weiter: die KI darf verändern

Im vorigen Kapitel war die KI strikt read-only. Jetzt gehen wir einen Schritt weiter, zum Herzstück jeder größeren Infrastruktur, ihrer Konfiguration, und diesmal soll die KI nicht nur observen, sondern mit-deployen. Damit nähern wir uns dem eigentlichen Ziel dieses Textes, dem Coding, denn unter der Haube ist es dasselbe Configuration Management.

Infrastructure as Code, kurz IaC, nimmt einem die Fleißarbeit ab, tausende Maschinen deklarativ über Config-Files statt von Hand zu provisionieren, die Frameworks dafür heißen Terraform oder Ansible. Die Entscheidung, was wohin gehört, nehmen sie einem aber nicht ab. Man beschreibt den desired state, eine Firewall-Rule gilt für eine ganze Gruppe, Exceptions schreibt man nachvollziehbar an einer Stelle in den Code, und man kann testen, gestaffelt ausrollen und automatisch validieren lassen. Das ist Control, mit einer Kehrseite: Wo früher hundert Leute hundert Rechner betreuten, macht das heute ein Zehntel, die Leverage ist enorm, und ein einziger misconfigurierter Parameter legt nicht einen Host still, sondern hat einen Blast Radius über die ganze Fleet.

Und damit sind wir beim Menschen unter Zeitdruck. Den gibt es im besten Setup, irgendwann muss eine Änderung schnell raus, und genau dann passiert der Human Error, gegen den der Zuruf „konzentrier dich doch mal“ exakt nichts ausrichtet. Was also spricht gegen ein Verfahren, das den Menschen nicht nur supported, sondern seine Error Rate echt senkt, Poka Yoke für Operations sozusagen?

Auf den ersten Blick klingt das easy, wir machen eine Änderung und die KI prüft im Nachgang, ob sie richtig war, aber so trivial ist es nicht. Gehen wir einen Case durch. Ein Kunde schreibt ein Ticket per Mail und beschreibt, so gut er kann, woran sein Problem liegen könnte. Wir überlegen, welche Änderung nötig ist, führen sie durch, rollen sie als Deployment auf die paar hundert Hosts aus, einige mit Overrides, und lassen am Ende per Smoke-Test prüfen, ob noch alles läuft.

Dieses Validieren läuft heute über eine CI/CD-Pipeline, doch in ihrem „alles“ steckt eine Tücke: Getestet wird genau das, woran wir vorher gedacht haben, die known knowns, während die unknown unknowns, die vielleicht gerade deshalb kaputtgehen, durch jedes Quality Gate rutschen. Genau das schreit nach einer KI.

Damit sie helfen kann, müssen wir ihr unsere Requirements geben, und das ist kein Overhead, sondern das Gegenteil. Wir haben zwei Artefakte, die Mail des Kunden und unsere eigene Vorstellung, was zu ändern ist, und beide haben fast nie denselben Scope, weil der Kunde von der Technik naturgemäß wenig versteht und uns deshalb hired hat. Also übersetzen wir seinen Wunsch in ein technisches Konzept, das Konzept in Config-Files, und die wiederum in echte, laufende Infrastruktur. Diese Abstraction Layers sind der eigentliche Knackpunkt, denn jede Stufe ist eine Source für Misunderstandings, und der teuerste Bug sitzt ganz am Anfang, im Requirements Gap zwischen Mail und Umsetzung.

Das ist der klassische Moment, in dem man mit einem Kollegen spricht, weil man schon beim Erklären merkt, ob es stimmt, reinstes Rubber-Duck-Debugging. Genau dafür eignet sich die KI als Sounding Board: Wir lassen sie validieren, ob das Aufgeschriebene zum Ticket passt, und reden mit ihr wie mit einem Sparringspartner, der uns auf eine ambige Formulierung stößt. Damit wir das nicht jedes Mal neu erklären, gießen wir es in einen Skill, ein einmal festgehaltenes, reusable Prompt-Template auf Knopfdruck. Der sagt im Kern: Schau dir das Ticket an, schau dir an, was ich aufgeschrieben habe, und prüf vor allem, ob meine Task-Datei spezifikationsscharf genug ist. Dieses „scharf genug“ skippen Menschen nur zu gern.

Nehmen wir an, wir haben die Datei geschrieben. Es ist nicht urgent, also gehen wir erst mal Mittagessen, ein bisschen Incubation, kommen mit fresh eyes zurück, lesen das Ganze noch einmal und stellen fest, dass es längst nicht so eindeutig war, wie wir dachten. Inzwischen haben wir mit Kollegen gesprochen, mit einem anderen Kunden telefoniert, und auf einmal würden wir es anders machen. Wir hätten es eben spezifischer schreiben sollen, und genau das ist hier schon erledigt: Die KI hat reviewt, mit uns geredet, und am Ende steht ein Brief, der in zwei kurzen Absätzen die Definition of Done festhält, statt der drei, vier Wörter, die wir sonst hingekritzelt hätten.

Jetzt kommt der eigentliche ROI. Im letzten Schritt lassen wir, wieder über einen Skill, reviewen: Schau dir den Diff an, führt er genau zu dem, was wir uns überlegt haben? Dafür braucht die KI nur Access auf das Geänderte, und das liegt ohnehin in Git unter Version Control, wo jeder Commit samt sämtlicher Config-Files einsehbar ist. So kann sie schon vorab prüfen, ob unsere geplante Änderung den richtigen Effekt hätte, im Nachgang, ob das Ergebnis stimmt, und zusätzlich, ob ungewollte Side Effects, sprich Regressionen, aufgetreten sind. Ein Step aber gehört dem Menschen: Vor dem Merge schaut er selbst über den Pull Request, denn die KI preppt vor, ordnet ein und warnt, doch das finale Sign-off bleibt bei uns.

Bleibt die Frage nach Cost und Benefit. Es kostet uns zwei Invocations, den ersten Skill am Anfang, den zweiten am Ende, plus ein paar Minuten, in denen wir mit der KI reden und uns zwingen, einen Gedanken tiefer zu gehen. Dafür haben wir den Auftrag spezifikationsscharf gefasst und das Ergebnis ge-reviewt, eine ganze Error Class aus Stress und Eile ist deutlich seltener geworden, und das alles, ohne die Security zu gefährden, im Gegenteil, sauberster Shift-Left. Damit dürfte allen, die meinen, eine KI habe in Production nichts verloren, ein wenig der Wind aus den Segeln genommen sein. Im nächsten Kapitel skalieren wir das Verfahren, und da wird es richtig interessant.

Das Verfahren ausbauen: Briefing, Ist-Zustand und der Task

Aus Auftrag, Review und einem menschlichen Sign-off haben wir eine erstaunlich sichere Pipeline gebaut. Jetzt skalieren wir sie, mit Building Blocks, die einzeln trivial sind und erst in Composition ihre Wirkung entfalten.

Der erste ist eine einmalige Fleißarbeit, die die KI handlet: ein gründliches System Discovery, nicht nur aus den Config-Files, sondern auch aus dem Kontext dazwischen, warum etwas so gebaut ist, welche Dependencies an welchen hängen. Ob ein Telekommunikationskonzern vor uns liegt oder eine Großbäckerei, ist ein gewaltiger Unterschied, weil für beide etwas völlig anderes business-critical ist. Das Deliverable ist eine große Knowledge Base, ich nenne sie das Briefing.

Der zweite ist eine Datei mit dem Current State. Bei einfachen Setups verzichtbar, bei komplexen, in denen wir nicht mehr full Access auf alles haben, Gold wert. Schreiben darf sie nicht die KI, sondern ein schlichter Collector, der alle relevanten Daten als Inventory einsammelt, sortiert ablegt und fortschreibt, damit man später per Diff vergleichen kann, eine saubere Baseline für die Drift Detection.

Damit beginnt der eigentliche Flow. Diesmal ruft der Kunde an, statt zu mailen, und hätte es an ein, zwei Stellen anders. Wir notieren, kicken den ersten Skill, geben ihm die Notes und reden mit der KI durch, was wirklich gemeint ist und wo es hakt, ein kurzes Refinement, bis ein präziser Brief steht, den wir dem Kunden zur Sicherheit sogar zum Sign-off schicken könnten.

Jetzt das Herzstück: Aus dem Brief wird ein Task, ein Work Item, das festhält, was zu tun ist, welche Config-Files sich wie ändern und vor allem warum, oben das Outcome, dann der Approach. Was nicht drinsteht, ist der fertige Code bis aufs letzte Zeichen, sondern das Gewollte, so spezifisch, wie besprochen, im Grunde die Acceptance Criteria.

Genau hier liegt der Unterschied zum blinden YOLO-Prompting, denn dieser Task ist kein bloßer Zettel: Er entsteht so, dass er unser Outcome gut trifft und die typischen KI-Failures gar nicht erst durchschlagen. Vorerst nehmen wir es als gegeben: Steht der Task, wird er ausgeführt, ein Reviewer-Agent macht den Cross-Check, der Mensch wirft das finale Sign-off drauf, Maker-Checker by the book, dann deployen wir.

Der letzte Step ist derselbe wie zuvor, nur erweitert um eine Post-Deployment-Verification: Die KI prüft, ob die Änderung in Production greift und keine Regressionen hat, und der Collector baut den Current State neu auf, bildet den Diff zum vorigen Stand und legt ihn der KI vor, die gut beurteilt, ob zu viel verändert wurde und ob das Ergebnis zum Outcome passt.

Dieser Stand ist die Baseline fürs nächste Mal, und nebenbei haben wir eine Versionierung, die nicht nur das Was und Wann festhält, sondern auch das Warum, im Grunde ein Architecture Decision Record. Das ist mehr wert, als es klingt, denn Rationale-Kommentare sind in der Praxis rar: Fragt ein Kollege ein halbes Jahr später, warum etwas so entschieden wurde, heißt es meist „weil der Kunde es wollte“, worauf nur „dann zeig mir die Mail“ kommt, und diesmal war es ein Call. Gut, wenn dann wenigstens ein nachvollziehbarer Audit Trail bleibt.

So fügt sich jeder Eingriff nachvollziehbar in den vorigen, das System bleibt declarative und auditable, durchgängige Traceability. Wie aus dem Brief ein so verlässlicher Task wird, einer, der die typischen KI-Failures von vornherein umgeht, ist der eigentliche Kniff, dem wir das nächste Kapitel widmen.

Verschiedene Blickwinkel: der zweifach moderierte Dialog

Der Task, die in einer Datei festgehaltene Work Instruction, ist die zentrale Komponente der Pipeline. Auch eine KI macht Fehler, und der Zuruf „konzentrier dich und mach es richtig“ hilft ihr so wenig wie uns. Es gibt aber einen Move, der bei Menschen wie bei der KI funktioniert, das Problem aus einer anderen Perspektive betrachten, Cognitive Diversity statt Echokammer, und das ist der Hebel dieses Kapitels, den ich für einen der wichtigsten des Textes halte.

Ich nenne es den zweifach moderierten Dialog, ein kleines Multi-Agent-Setup, das aufwendiger klingt, als es ist. Wir setzen nicht eine KI an, sondern ein Ensemble, bewusst ungleich, gern verschiedene Modelle, jedenfalls mit unterschiedlichem Charakter, ich nenne diese künstlichen Rollen Personas, im Grunde Role-Prompting. Den Task haben wir forward geschrieben, hier ist das Problem, so lösen wir es; jetzt invertieren wir die Blickrichtung. Die erste Persona prüft, ob der Task das eigentliche Goal ganz oben löst, und muss dafür Backward Reasoning betreiben, vom Ziel her denken, statt dem Lösungsweg nur zuzunicken. Schon dieses Working Backwards fördert erstaunlich viel zutage.

Bei allem, was nicht trivial ist, findet sie fast immer etwas zu bemängeln. Diese Findings übernehmen wir nicht blind, sondern lassen eine zweite Persona mit anderem Charakter prüfen, ob die Kritik überhaupt valid ist, klassisches LLM-as-a-Judge, und gewinnen damit beiläufig einen dritten Blickwinkel: Diese zweite sucht die Issues nicht selbst, sie macht den Triage über die gefundenen und sagt, ja, ein echter Bug, oder, das müssen wir klären, oder, nein, False Positive, im Task stand es richtig.

Gerade die letzte Antwort geht zurück an die erste Persona, die ihrerseits replied. Als ich damit anfing, hat mich ehrlich überrascht, wie oft diese Multi-Agent-Debate hin und her loopt, als würde die KI mit sich selbst diskutieren. Damit es nicht ausufert, kommt der Moderator als Orchestrator: Die Personas reden nicht direkt, er reicht die Antworten weiter, committed den Konsens als geklärt und schickt Strittiges ein paar Iterationen hin und her, ehe er selbst entscheidet oder uns als Human-in-the-loop fragt. Unterm Strich arbeiten vier KIs an einer einzigen Frage.

Das mache doch ein modernes Reasoning-Modell mit seinem Chain-of-Thought längst von allein, könnte man einwenden. Tut es, aber darum geht es nicht: Entscheidend ist, dass wir die Diversity by design herstellen, statt auf sie zu hoffen. So fangen wir die Errors aus falschen Assumptions ab. Es bleibt ein zweiter, ebenso wichtiger Hebel, und er trifft das Halluzinieren unmittelbar: die KI zum Retrieval zu bringen, statt sie raten zu lassen.

Die KI zum Nachschlagen bringen: Werkzeuge und RAG

Den ersten Hebel haben wir, die Cognitive Diversity. Der zweite trifft das Halluzinieren mitten ins Herz: Wir machen der KI das Retrieval so frictionless, dass sie es auch tut, denn Halluzinieren bei Fakten ist weniger Charakterfehler als eine Frage des Thresholds. Eine KI muss halluzinieren dürfen, nur dürfen wir die Downsides nicht mitnehmen, wie beim Anwalt aus dem dritten Kapitel. Die Lösung steckt schon dort: Eine KI ist keine Datenbank, aber sie kann eine fürs Grounding nutzen, und die neueren Modelle tun das auch, nur nicht oft genug.

Der Grund: Ihr Wissen ist nie ganz aktuell, der Knowledge Cutoff lag früher mal zwei Jahre, heute ein paar Monate zurück, und bei Libraries und APIs, die im Wochentakt breaken, sind selbst Monate zu viel. Retrieval kann sie inzwischen selbst, nur läuft das oft so: „Kennst du diese Library?“ „Ja, klar, was ist dein Problem?“ Man arbeitet weiter, merkt, dass die Antworten nicht ganz passen, hakt nach, „schau bitte genauer hin“, „nein, das stimmt schon“, „dann recherchier mal“, „ach, die neue Version sieht ja anders aus“. Genau deshalb habe ich mir früh angewöhnt, nicht zu fragen „kennst du das“, sondern „prüf die aktuelle Version, und wenn du sie nicht kennst, lies erst die Release Notes“. Widerwillig befolgt, aber es half.

Inzwischen kicke ich zu Projektbeginn ein gründliches Knowledge Harvesting, wieder über einen Skill: Er nimmt sich alle Dependencies und Building Blocks vor, holt zu jedem die aktuelle Version und ingestiert die Doku, nicht nur die des Herstellers, sondern auch das Community Knowledge aus den Foren, wo die Doku falsch oder stale ist und wo es hakt. Das klingt nach gewaltigen Datenmengen, ist es aber selten, weil veraltete Doku meist dünn ist, und die Arbeit macht ohnehin die KI.

Warum der Aufwand, sie kann doch on demand nachschlagen? Kann sie, aber Retrieval ist teuer: Sie muss herausfinden, wo sie sucht, einen Link finden, der lebt und eine KI überhaupt reinlässt, das Alter einschätzen, und das jedes Mal, reiner Overhead. Also macht sie das Cost-Benefit wie ein Mensch: Wer hundertprozentig sicher ist, schlägt nicht nach, wer es zu achtzig Prozent ist, meist auch nicht, eine Frage der Calibration, und wer nicht weiß, wo, der probiert es eben, was bei der KI halluzinieren heißt. Unser Ziel ist, diesen Confidence Threshold zu senken, und weil „schlag immer nach“ keine Lösung ist, machen wir Pre-Fetching und legen ihr die Information in Reichweite.

Dafür nutze ich ein RAG, das ich ohnehin verwende und selbst geschrieben habe, sodass ich ihm vertraue und es mir die Setup-Mühe abnimmt. Ich werfe die geharvesteten Texte hinein, es macht das Chunking und Indexing, die KI greift per Semantic Search darauf zu. Von da an fragt sie einfach, welche Parameter eine Funktion hat, und bekommt die Antwort sofort und in der aktuellen Fassung, schneller, als sie sie aus dem eigenen Gedächtnis hervorkramen könnte. Sie muss nicht mehr raten, nur sich erinnern, dass es die Funktion gibt, und damit das leichter fällt, geben wir ihr zum Context-Priming gleich eine knappe Summary, was im RAG steckt und wo sie bei Zweifeln nachfragen kann.

Als ich das zum ersten Mal aufgesetzt hatte, hätte ich nicht gedacht, was für ein Game-Changer das ist. Wie oft hatte ich vorher gesagt „schau halt nach, verifizier das“, oder mich geärgert „warum machst du das so kompliziert, warum nicht der idiomatische API-Call?“, und die Antwort war „daran hatte ich nicht gedacht, der ist wohl neuer”.

Den vollen Nutzen ziehen wir, indem wir das Harvesting mit dem Task verbinden, sauberes Context Engineering: Dort steht jetzt nicht nur, was zu tun ist und wie, sondern auch, welcher Context im RAG liegt, welche Teile unserer Doku zählen und wo es dazu Diskussionen gab. So hält die KI in einem kurzen, self-contained Work Item den vollständigen Auftrag, Goal und Approach, die Sources, das Nachzuschlagende, die Punkte, auf die zu achten ist, und die Spots, an denen Side Effects lauern; später trackt dieselbe Datei sogar den Progress. Zusammen mit der Cognitive Diversity nehmen wir dem Halluzinieren so den größten Teil seiner Gefahr, eine saubere Separation of Concerns: die KI fürs Reasoning, das RAG für die Facts, genau die Rollenverteilung vom Anfang. Die KI ist keine Datenbank, aber sie benutzt eine. Damit ist unser größtes Problem solved.

Was Vibe-Coding wirklich ist

Bisher haben wir die KI nur Configs ändern lassen, vorsichtig, mit Fail-safe und Rollback. Das war die eigentliche Mutprobe: an einem Production-System mutieren, ohne es zu zerlegen. Wer das beherrscht, ist ready fürs Endgame, wir lassen die KI jetzt richtig coden, full Software Engineering.

Gleich zu Beginn muss ein Misconception weg, das selbst unter Technikern hält. Coden heißt nicht, Code zu tippen, das ist das Wenigste. Die eigentliche Aufgabe ist Software-Architektur: die Components, die Infrastruktur darunter, die Auswahl von Tech-Stack und Dependencies, also der fertigen Libraries, und vor allem die Integration von alldem, neben der der Code fast zum Nebenprodukt wird. Gerade bei dieser Tech-Stack-Auswahl ist die KI kaum noch zu ersetzen, weil das Ecosystem so schnell wächst, dass ein einzelner Mensch es unmöglich überblickt. Die KI sucht nicht nur schneller, sie macht auch die Sentiment-Analyse, liest die Erfahrungsberichte und das Gemecker in den Foren mit und sagt uns, wo eine verlockende Dependency in der Praxis hakt, das spart manche Build-vs-Buy-Entscheidung.

Dieser Text bringt der KI nicht das Coden bei, dafür gibt es Tutorials genug, und die Modelle werden darin von allein besser. Er zeigt, wie man die Capabilities, die sie längst hat, so orchestriert, dass am Ende Code herauskommt, wie ich ihn selbst geschrieben hätte, denn ich bringe ein, was keine KI besitzt: dreißig Jahre Seniority mit genau dieser Arbeit, die ich jetzt nicht mehr mit einem Team aus Menschen fortführe, sondern mit einer Agentic Workforce.

Ein Wort zum Zeitpunkt, denn nichts hier veraltet schneller. Stand Anfang 2026 schreiben die besten Modelle selbstständig brauchbaren Code, auf dem Skill-Level eines Junior-Devs, der das Coden gelernt und ein paar kleinere Projekte hinter sich hat. Und sie produzieren exakt dieselben Anti-Patterns wie ein Junior aus Fleisch und Blut, nicht ähnliche, dieselben. Zum Teil liegt das an der fehlenden Erfahrung, jenen zwanzig, dreißig Jahren, aber nicht nur. Die KI hat per Imitation Learning gelernt, wie guter Code aussieht, indem sie unzählige Repos angesehen hat; was sie nie getan hat, ist, selbst zu programmieren, ein System über Jahre zu maintainen und am eigenen Leib zu erfahren, welche Entscheidung von heute sich in zwei Jahren als Technical Debt rächt. Solches Wissen fließt auch kaum ins Training zurück, ein echter Data Gap, weil kein Entwickler freiwillig committet, wo er sich jahrelang geirrt hat.

Man versucht, das mit einem immer größeren Context Window auszugleichen, nur ersetzt auch das beste Gedächtnis keine Erfahrung. Halten wir fest: Wir haben einen begabten, aber unerfahrenen Junior vor uns, mit dem sich Großes anfangen lässt, wenn man weiß, wovon man redet. Und das beginnt mit einer unbequemen Frage, was guten Code ausmacht, und die Antwort fällt provokanter aus, als man denkt: Dass ein Programm funktional korrekt ist, ist zweitrangig. Wichtiger sind die Non-functional Requirements, Code, der robust bleibt, der maintainable ist und der future-proof gebaut ist, sodass die Probleme von morgen gar nicht erst entstehen. Natürlich muss das Programm laufen, aber das ist die Eintrittskarte, kein Verdienst. Clean Code denkt voraus, schlechter funktioniert auch, bis man ihn das erste Mal anfassen muss, und genau dieses Vorausdenken beherrscht weder der Junior noch die KI. Dieses Wissen müssen wir mitbringen.

Denn ein System ist mehr als die Summe seiner Components, und je größer es wird, desto schwerer fällt das System Thinking, den Überblick übers Ganze zu behalten und zugleich an einem einzelnen Baustein zu feilen. Eine KI versucht es mit schierer Kapazität, mit einem immer größeren Context Window, doch irgendwann ist ein System zu groß für einen einzigen Kopf, ob aus Fleisch oder Silizium. Was tut man bei Menschen in dieser Lage? Man macht Divide and Conquer und verteilt die Arbeit. Genau das tun wir, statt einer einzigen KI setzen wir mehrere Agenten an, jeden für sein Modul.

Das große Thema, an dem sich die halbe KI-Welt abarbeitet, heißt Orchestrierung, das geordnete Zusammenspiel vieler Agenten. Mir genügt etwas Bodenständigeres, denn schon unter Menschen ist Collaboration so notorisch schwierig, dass man alle paar Jahre ein neues Agile-Framework dafür erfindet. Ich behandle die KI-Chats wie Team-Member, assigne Tasks, frage nach, lasse sie miteinander reden. Den moderierten Dialog aus dem siebten Kapitel heben wir dafür auf eine größere Ebene: Dort prüften mehrere Personas denselben Task, hier baut jeder Team-Member ein eigenes Modul, und es geht um die API-Contracts, wie diese Module sauber zusammenpassen. Die Interfaces dazwischen legen wir bewusst nur grob fest, weil sich erst beim Hineingehen zeigt, was die Module voneinander brauchen, lieber Loose Coupling als Premature Spec. Also lassen wir die Beteiligten die Details untereinander aushandeln, in ein paar strukturierten Minuten, fast wie ein Daily, und ich moderiere darüber wie ein Engineering Manager, der den Konsens committed und entscheidet, wenn sie sich nicht einig werden.

Mit dieser Agentic Workforce lassen sich größere Projekte angehen, auch die Legacy Modernization alter Systeme, die am Ende einen eigenen Ausblick verdient. Vorher aber lösen wir das Value Proposition über diesem Artikel ein, schneller als Vibe-Coding und dabei sicherer und sustainable, und dazu klären wir erst, was Vibe-Coding überhaupt ist. Der Term fällt ständig, und fast jeder hat eine andere Definition. Vibe-Coding heißt nicht, mit Hilfe einer KI zu entwickeln, das tun wir hier auch. Es heißt, einer KI ohne eigenen Plan und ohne vorgegebene Struktur zuzurufen: Mach mal. Prompt and Pray. Man beschreibt grob das Outcome und überlässt ihr das Wie, das Womit, das Wo. Unsere Methode ist das genaue Gegenteil, spec-driven: Nicht der Code soll schnell stehen, sondern das Drumherum soll so durchdacht sein wie möglich.

Unfair wäre es, Vibe-Coding nur zum Schreckgespenst zu machen, denn es hat seinen Use Case. Ein Anmeldeformular für eine Party, bei dem sich Gäste eintragen und wir eine Mail bekommen, die übliche CRUD-Boilerplate aus Input validieren, Adresse checken, Mail rausschicken, scaffoldet es in Minuten hin, und darin ist es unschlagbar. Sollen die Anmeldungen zusätzlich in einer geteilten Online-Tabelle landen, geht auch das flott, weil die KI diese Happy Paths auswendig kennt. Hier zeigt sich nur ein erster feiner Riss: Wir wissen am Ende nicht, wo und wie sie unsere Credentials ablegt, ein klassischer Security Smell, weil wir es nie spezifiziert haben. Für so ein Party-Gimmick ist das egal, ein kurzer Glance in den Code, fertig. Und ein zweiter guter Grund: Manchmal weiß man selbst noch nicht, was man will, dann ist ein schneller Throwaway-Prototyp Gold wert, ein Spike, den man ansehen und wieder verwerfen kann.

Nun verlassen wir die Spielwiese und nehmen ein richtiges Projekt, an dem Geld und Ruf hängen, einen kleinen Online-Shop, aber mit einem Twist: Der Preis soll nicht feststehen, sondern mit der Nachfrage steigen und fallen, Dynamic Pricing wie bei einer Auktion, dazu die üblichen Payment Provider, ein Tenant je Kunde, das ganze Drumherum. Sagen wir auch hier nur „mach mal“, scaffoldet die KI mit ein paar Rückfragen tatsächlich etwas, das mit Glück sogar läuft. Der Haken: Sie kann nicht hellsehen, Shops aber hat sie zu Tausenden im Trainingsset gesehen, also baut sie die Commodity-Lösung, den Standard-Shop, reine Regression to the Mean, und gerade das eine, das unseren besonders macht, der mitwandernde Preis, ist der Edge Case, über den sie am flüchtigsten hinweggeht, weil wir sie nie gezwungen haben, darüber nachzudenken. Das ist das uralte Problem mit jedem Stakeholder: Erst muss man per Requirements Elicitation herausfinden, was er wirklich will und was davon sinnvoll machbar ist. Beim Vibe-Coding skippt man das immer. Also tun wir zuerst, was es auslässt, wir machen uns klar, was wir eigentlich wollen, und genau da beginnt unsere Methode.

Schneller als Vibe-Coding

Im vorigen Kapitel haben wir gesehen, wo Vibe-Coding scheitert, an einem echten Projekt wie unserem Shop, dessen Dynamic Pricing mehr verlangt als ein hingeworfenes „Mach mal“. Was wir wollen, wissen wir nun grob. Bevor wir aber bauen lassen, kommt der für mich wichtigste Schritt, eine große Knowledge Base als Grounding-Corpus, die das Halluzinieren von vornherein klein hält, Hallucination Mitigation by design.

Zusammengetragen wird sie von der KI, über die Anfangsrecherche, die ich bei jedem Projekt nutze. Sie macht das Technology Evaluation über alle Libraries, APIs und Vendors, sucht von sich aus nach Alternativen, die wir übersehen haben könnten, und legt vor, was taugt; ist etwas Besseres darunter, nehmen wir es nach kurzer Rücksprache auf. Dann holt sie zu jedem Building Block die aktuelle Doku und sichert das Entscheidende samt Provenance, auch wenn sie überzeugt ist, die jeweilige Library aus dem Effeff zu kennen. Hier muss man sie per Prompt-Framing manchmal überlisten, indem man sagt, das Wissen sei nicht für sie, sondern für mich; schon recherchiert sie willig, statt sich auf ihr Gedächtnis zu verlassen.

Das Ergebnis indexieren wir nach Themen und geben es ins RAG aus dem achten Kapitel, womit sich der Kreis schließt: Ist die KI unsicher, behauptet sie nichts mehr, sie macht Retrieval, beim Planen wie später bei jedem Function Call. Auch das kostet Zeit, die Vibe-Coding sich spart; merken wir es uns, am Ende kommt die ROI-Abrechnung.

Jetzt erst planen wir. Wie genau, ist Geschmackssache, bei mir male ich mir das System Modul für Modul im Kopf aus und erzähle es einer KI, die die Punkte als Skeleton festhält, damit ich mein Mental Model nicht verliere. Entscheidend ist nur, dass eine High-Level-Architektur entsteht. Dabei nutze ich die KI nicht als bloße Autocomplete, sondern will ein fundiertes Design Review aus verschiedenen Blickwinkeln und greife auf den moderierten Dialog aus dem siebten Kapitel zurück, mehrere Personas und einen Moderator; was mir an Maintainability und Wartbarkeit wichtig ist, steckt längst im Skill. Anders als beim Task aus dem letzten Beispiel entsteht hier kein Code, sondern allein die grobe Struktur, und wir planen bewusst future-proof, was später dazukommen könnte, selbst was der Kunde nie auf der Roadmap hatte. Die Personas halte ich an, im Zweifel lieber Retrieval als zu raten und lieber einmal zu viel zu fragen. Mehr ist es im Kern nicht, die Strengths der KI ausreizen und ihre Weaknesses abfangen, und zwei Mechaniken runden das ab.

Das erste betrifft die Fehler. Wer ein Team führt, weiß, welcher Member zu welchem Schnitzer neigt, und schaut genau dort hin; die KI produziert die Anti-Patterns eines Juniors, wir müssen sie nur benennen, dann lässt sich ihr Code per Static Analysis daraufhin prüfen. Erfinden müssen wir das nicht selbst, es gibt fertige Skills, die diese Code Smells auf mehreren Ebenen linten, ob der Code lesbar ist, ob er robust läuft und nicht beim ersten Edge Case stolpert, ob er per SAST sicher gegen Angriffe ist; je nach Modell tune ich sie nach und schicke den fertigen Code routinemäßig durch dieses Quality Gate.

Die zweite Mechanik ist die reizvollere. Noch entsteht kein fertiger Code, trotzdem hilft es, ein Modul so klar vor Augen zu haben, dass man es fast hinschreiben könnte, und noch besser als eine Skizze in Worten ist ein Prototyp, der wirklich läuft, wofür ausgerechnet das eben gescholtene Vibe-Coding zurückkehrt. Nehmen wir das Payment-Modul, das am Ende jeden Case abdecken muss, jede Bestätigung, jede Absage, jede Rückfrage. Statt es auszuprogrammieren, lassen wir die KI es in Minuten als Mock simulieren, ein kleines Stub, das sich nach außen API-kompatibel wie das Echte benimmt und alle Responses liefert, von der abgelehnten Kreditkarte bis zur Bestätigung, die zu spät eintrifft; was im Sad Path schiefgehen kann, hat die Anfangsrecherche ohnehin zusammengetragen. So machen wir Integration Testing, lange bevor ein Modul existiert, reine Service Virtualization, und die Attrappe darf bleiben: Das echte Payment-System lässt sich nicht per Fault Injection auf Kommando zu einer abgelehnten Karte zwingen, der Mock tut genau das, für jeden Test. Nach und nach ersetzen wir die Stubs durch Echtes und behalten, was wir zum Testen brauchen, sodass die Mühe nicht doppelt war, sondern Velocity gebracht hat.

Damit ist die Pipeline beisammen, und wir benchmarken sie gegen das andere: Wir lassen das Vibe-Coding noch einmal von der Leine, diesmal am ganzen Shop. Auf den ersten Blick sieht das ordentlich aus, die KI plant, schlägt Wege vor, setzt etwas hin und testet sogar selbst, wobei sie merkt, dass manches doch nicht so will. Und dann passiert, was jeder kennt, der einen Junior begleitet hat: reines Trial and Error, Hauptsache, es läuft. KIs neigen haargenau wie menschliche Einsteiger dazu, den Code erst zum Laufen zu bringen und das „make it right“ zu skippen, und scheitert auch der dritte Versuch, dann eben Brute Force, Hauptsache irgendwie. So entsteht ein Programm, das vielleicht funktional korrekt ist, aber bei der ersten größeren Änderung in sich zusammenfällt, brittle bis zum Anschlag.

Das ist das Verrennen, der gefährlichste Failure Mode von allen, im Grunde ein Rabbit Hole, das in einen Doom Loop kippt: Eine KI biegt sich ein Problem zurecht, bis es irgendwie funktioniert, reißt dabei den sauberen Aufbau ein, Architecture Erosion in Echtzeit, und ist das einmal passiert, passiert es wieder und wieder. Beim Vibe-Coding sofort und praktisch ausnahmslos. Es bei meinen Leuten zu verhindern, war stets mein Job als Lead, und genau das tue ich jetzt bei der KI; unsere Pipeline nimmt mir das größtenteils ab, denn wer vernünftig plant, aus mehreren Blickwinkeln schaut und future-proof denkt, dem fallen die meisten Sackgassen gar nicht erst zu. Ganz verschwindet es nicht, darum der Circuit Breaker: Verrennt sich ein Agent, wird er unterbrochen und gezwungen, innezuhalten, einen Step-Back zu machen und die Sache aus der anderen Perspektive anzusehen, am besten im Pair-Review mit einem zweiten. Genau hier, im Cognitive Tunneling, verlieren Mensch wie Maschine sonst die meiste Zeit, und weil das bislang kaum ein Framework abnimmt, achten wir selbst darauf.

Dann kommen die Change Requests, denn die kommen immer. Beim vibe-codierten Shop dort, wo die KI raten musste, am Frontend, am Verhalten in den hundert kleinen Edge Cases; sie hatte vielleicht mehrere Ideen, shippen konnte sie eine, und gefällt sie nicht, muss großzügig refactored werden, worin KIs ausgesprochen schlecht sind. Bei uns war dieselbe Frage längst besprochen und die beste Option gewählt, und für Unsicheres gilt, was ich beim Hausbau täte: Ich lege Leerrohre, halte die Interfaces so generisch wie möglich und baue Unsicheres als Extension Point ein, sauberste Dependency Inversion und Loose Coupling. Das kostet Sekunden Nachdenken, oft für einen Case, der nie eintritt, tritt er aber ein, bin ich um ein Vielfaches schneller.

Beim Vibe-Coding wird es mit jedem Change schlimmer, jedes Teil erhöht die Software Entropy, und ändern müssen wir ständig, weil am Anfang nichts spezifiziert wurde, sein Witz und zugleich sein Verhängnis. Uns trifft das kaum, und unser einziges vibe-codiertes Stück, das Mock-Modul, bauen wir im Zweifel neu statt um, weil es winzig ist und nie ins Produkt geht; beim reinen Vibe-Coding ist das Produkt genau dieser zusammengestückelte Code, ein Big Ball of Mud. Am bittersten beim kleinsten Request: Ein Kunde will ein UI-Element woandershin, und vielleicht ist das ein Einzeiler, vielleicht hängt per Tight Coupling ein halbes System dran, man weiß es nicht, und fragen kann man auch nicht, denn die KI hat den Kontext längst verloren. Sie verrennt sich erneut, refactored, verliert den Überblick, Ripple Effect überall, und mit ihr verlieren wir ihn.

Hier holt unser Weg auf und zieht vorbei. Das eigentliche Ungetüm sind all die Dinge, die nie spezifiziert wurden und nun als Rework im Nachhinein eingepasst werden müssen, Stück für Stück, was die KI nicht allein kann, da muss der Mensch ran, und diese Nacharbeit kostet ein Vielfaches der anfänglichen Planung. Am Ende stehen zwei Produkte, die beide funktional korrekt sind, nur ist das eine maintainable gebaut, kennt die Edge Cases und lässt sich mühelos extenden, während wir das andere irgendwann selbst nicht mehr verstehen, und die KI auch nicht. Unseres ist obendrein secure und clean, und die kritischen Stellen reviewen wir selbst: Das Core Data Model, das Foundation, auf dem alles ruht, schaue ich bis heute von Hand an, während der vibe-codierte Shop kein solches Fundament hat, sondern ein Dutzend halb passender, sofern ich sie überhaupt finde. Spätestens hier ist die Value Proposition eingelöst: Wir sind schneller als Vibe-Coding, und secure und sustainable dazu.

Halten wir es als Side-by-Side nebeneinander, damit man die Cost Curve sieht, wer wann bezahlt:

Der Wettlauf ist entschieden. Bleibt ein Case, in dem die Startaufstellung eine ganz andere ist: wenn das System, das wir ablösen sollen, längst als Legacy existiert und niemand mehr den vollen Überblick hat, der Bus Factor gegen null.

Ausblick: Wenn das alte System weg muss

Alles bisher lief darauf hinaus, ein System Greenfield von Grund auf zu planen, bevor die erste Zeile Code steht, und dieses Upfront Design war der größte Hebel. Es gibt aber einen Case, in dem nicht zu wenig geplant wurde, sondern in dem alle Planung von einst hinfällig ist, willkommen im Brownfield.

Ein System läuft seit zwanzig Jahren, vielfach umgebaut, von vielen Händen, mit einer Doku, die nichts mehr sagt oder schlicht falsch ist; das eigentliche Wissen ist reines Tribal Knowledge im Code selbst, Code as Documentation. So etwas ist irgendwann nicht mehr maintainable und schließlich nicht einmal mehr lauffähig, weil der Stack darunter End-of-Life geht, und wer rechtzeitig dran ist, startet eine Migration in eine moderne Sprache, ein Re-Platforming, bevor es ganz stehenbleibt.

Das klingt nach bloßem Transpilieren, ist aber das Gegenteil und schwieriger als ein Greenfield-Neubau. Ein 1:1-Port wäre das kleinste Problem; die Härte liegt darin, dass das eine System ein ganz anderes Paradigma fährt als das andere. Ein Bankensystem in COBOL, ein Geflecht aus PHP, wie es hinter erstaunlich vielen Webseiten steckt, lässt sich nicht per Lift-and-Shift in etwas Modernes gießen, und selbst ein halbwegs zeitgemäßer Stack muss nach genug Jahren und Händen ein echtes Re-Architecting bekommen. Es geht nie um die Sprache allein.

Im Kern zerfällt das in zwei Teile. Der erste, den alten Code zu verstehen, ist Reverse Engineering, eine Kunst für sich, in der die KIs rasch besser werden. Ist er verstanden und liegt ein präziser Plan vor, geht es weiter wie beim Shop, dieselbe Aufgabe, derselbe Tech-Stack, und hier zahlt sich alles aus, was wir über die KI gelernt haben. Eine KI mit großem Context Window analysiert fremden Code hervorragend und macht mit Anleitung das Re-Architecting bis ins Detail; nur kennt sie die alte Umgebung mit ihren vergessenen Interfaces und Treibern oft so wenig wie wir, sodass wir dieses Wissen per Knowledge Extraction zusammensuchen oder aus dem Code rekonstruieren und ins RAG ingestieren müssen. Auch hier rät und vergisst sie, sobald der Altbestand das Context Window sprengt, und auch hier gilt, nicht alles dem LLM zu überlassen, sondern die spezialisierten Static Analyzer zu nutzen.

Mehr als sonst zählt hier die Seniority des Menschen, denn die KI hat gelernt, wie fertiger Code aussieht, nicht, wie er entsteht, und ein solches Re-Architecting so gut wie nie selbst gemacht. Wir führen sie wie einen begabten Junior vor einer Aufgabe, die er noch nie gelöst hat. Eine Stolperfalle als Kostprobe: Findet man im alten Code einen Bug, ist die erste Eingebung, ihn zu fixen, und oft ist das falsch, weil an anderer Stelle längst etwas mit genau diesem Bug rechnet und bricht, sobald er verschwindet, Hyrum’s Law in Reinkultur. Erst die Impact Analysis, dann der Fix, und vorher gilt Chesterton’s Fence: nichts entfernen, was man nicht verstanden hat. Wie man das alles ordnet, füllt einen eigenen Artikel, und den schreibe ich als Nächstes.

Fazit

Das war der Blick nach vorn, für diesen Artikel aber schließt sich hier der Loop. Am Anfang standen zwei Camps, die aus demselben Halbwissen entgegengesetzte Schlüsse zogen, die einen bannten die KI aus Technophobie, die anderen vertrauten ihr blind im Automation Bias, und beide produzieren Schaden. Inzwischen sollte klar sein, warum, und dass es einen Third Way gibt, jenseits von Verbot und Blindflug.

Er beginnt mit zwei Sätzen, die sich zu widersprechen scheinen, bis man sie zusammen denkt, eine productive tension. Der erste: Eine KI muss halluzinieren dürfen, denn ihr fuzzy Erinnern ist nicht ihr Defekt, sondern die Quelle ihrer Generativität. Der zweite: Eine KI ist keine Datenbank, aber sie kann eine fürs Grounding nutzen. Wer beides beherzigt, betreibt Hallucination Mitigation, ohne der KI das zu nehmen, was sie wertvoll macht.

Und er stützt sich auf zwei Hebel, die den ganzen zweiten Teil getragen haben, die KI per Cognitive Diversity zu verschiedenen Blickwinkeln zu zwingen, statt darauf zu hoffen, und ihr das Retrieval so frictionless zu machen, dass sie es auch tut. Mehr braucht es im Kern nicht. So wird aus der gefürchteten Maschine ein Instrument, reine Augmentation, das man dort einsetzt, wo es stark ist, und dort per Guardrails absichert, wo es schwächelt, nicht langsamer als das blinde Drauflos, sondern schneller, mit mehr Velocity, und das Bessere daran: sicherer und sustainable.