Einleitung

Über künstliche Intelligenz hat heute fast jeder eine Meinung, und fast jede beruht auf Halbwissen.

Ein Vorwurf ist das nicht, denn die wenigsten von uns arbeiten in diesem dem Fach

Aus derselben unsicheren Vorstellung ziehen zwei Lager genau entgegengesetzte Schlüsse, und keiner der beiden trifft es. Die einen verbieten die KI, aus Angst vor dem, was sie nicht durchschauen. Die anderen vertrauen ihr blind und hoffen, die Maschine werde das Mitdenken schon übernehmen, auch wenn sie selbst nicht recht wissen, was sie da tun.

Beide Lager schaden, nur von verschiedenen Seiten. Wer die KI verbietet, verschenkt ein mächtiges Werkzeug. Wer sie blind laufen lässt, setzt sie ausgerechnet dort ein, wo sie am meisten anrichten kann, und stiftet am Ende mehr Schaden als Nutzen.

Der überraschende Teil, der diesen Artikel trägt: Gerade die gut gemeinten Denkverbote kehren sich in ihr Gegenteil. Sie schützen nicht, sie schaden.

Dass es besser geht, dass man eine KI nicht nur schneller, sondern auch sicherer und nachhaltiger einsetzen kann, ist keine fromme Hoffnung, sondern lässt sich zeigen. Und das nicht allein beim Programmieren.

Konkret läuft alles auf ein Ziel zu: ein Verfahren, mit dem man gerade beim Programmieren das gefährliche Halluzinieren der KI verhindert, ohne ihr die Fähigkeit zu nehmen, die sie überhaupt erst nützlich macht. Wie das zusammengeht, wirkt zunächst widersprüchlich und ist der Kern dieses Textes.

Ein Wort noch zur Sprache. Dieser Text ist für IT-Profis genauso geschrieben wie für fachfremde Entscheider, und beide sollen etwas davon haben. Deshalb verzichte ich so weit wie möglich auf Fachbegriffe und erkläre die wenigen, die sich nicht vermeiden lassen, gleich an Ort und Stelle.

Vorher aber muss eine Vorstellung weichen, die fast jeder mit sich trägt und die fast jeden in die Irre führt. Sie klingt im ersten Moment absurd und ist doch der Schlüssel zu allem Weiteren: Eine KI muss halluzinieren dürfen.

Eine KI muss halluzinieren dürfen

Ein Computer irrt nie. Der Mensch ist kreativ und macht Fehler, die Maschine rechnet und behält recht. Das Bild ist uns aus Sprachgebrauch und Science-Fiction vertraut, und an ihm ist etwas dran, nur betrifft es nicht die KI, sondern den Algorithmus. Ein Algorithmus ist deterministisch, ein technisches Wort dafür, dass dieselbe Eingabe immer dasselbe Ergebnis liefert. Frage ich zweimal gleich, antwortet er zweimal gleich, und wenn er sich irrt, dann nur, weil ich ihn falsch programmiert habe.

Eine KI funktioniert anders, und genau darin liegt ihr Wert. Sie kann etwas, das wir in der Schule von jedem Kind verlangen: eine Transferleistung.¹ Man lernt eine Formel in Physik und wendet sie später auf eine Aufgabe an, die man so noch nie gesehen hat und die der ursprünglichen nur entfernt ähnelt. Ein Algorithmus kann das nicht, denn ein neues Problem müsste ich erst wieder vordenken und ausprogrammieren, womit es nicht mehr neu wäre. Ein Mensch löst Neues, weil er Erfahrung mitbringt und sie überträgt. Und genau das soll die KI auch.

Übertragen kann man aber nur, wenn man nicht stur abruft, sondern unscharf erinnert. Fragt man jemanden nach einem Buch, das er vor Jahren gelesen hat, erzählt er einem die Geschichte, aber die Kapitel sitzen nicht mehr an der richtigen Stelle, ein paar Namen stimmen nicht, vielleicht wandert eine Szene aus dem einen ins andere. Der Kern bleibt, die Details verschwimmen. So erinnert sich ein Mensch, und so muss sich auch eine KI erinnern, wenn sie wie ein Mensch denken soll. Sie ruft nicht den einen exakten Datensatz ab, sie mischt aus vielen ähnlichen Fällen etwas Passendes zusammen.²

Dieses Verschwimmen, diese kleine Abweichung vom exakt Gespeicherten, hat einen Namen, und der ist erstaunlich schlecht beleumundet: Wir nennen es Halluzinieren.³ Dabei ist es zunächst nichts weiter als der Nebeneffekt davon, sich an etwas nicht hundertprozentig erinnern zu können. Beachtet man das, ist es harmlos. Trotzdem wird es verteufelt, als wäre es der Geburtsfehler der ganzen Technik. In Wahrheit ist es die Voraussetzung dafür, dass eine KI überhaupt kreativ sein, überhaupt Neues lösen kann. Nehmen wir ihr das Halluzinieren, nehmen wir ihr das Denken.

Das lässt sich sogar erzwingen. Man kann eine KI dazu bringen, nur noch exakt Gespeichertes auszugeben, nie abzuweichen, nie zu verschwimmen.⁴ Dann hat man aber keine KI mehr, sondern eine Datenbank, und zwar eine ausgesprochen teure und langsame, die obendrein das Einzige verloren hat, was sie von einer gewöhnlichen Datenbank unterschied: die Fähigkeit, ein neues Problem zu lösen.

Die Kehrseite, an die jeder sofort denkt. Die KI, die eine Quelle erfindet, ein Urteil zitiert, das es nie gab, eine Funktion aufruft, die nicht existiert. Auch das ist Halluzinieren, dasselbe Phänomen, nur an der falschen Stelle. Der Fehler liegt aber nicht darin, dass die KI halluziniert, sondern darin, dass wir exakte Fakten von ihr verlangt haben, ohne ihr die Mittel zu geben, sie nachzuschlagen. Wie man genau das verhindert, ohne ihr die Kreativität zu nehmen, ist die Geschichte, die dieser Text erzählt. Sie beginnt mit einer Einsicht, die so schlicht ist, dass man sie ständig übergeht.

Eine KI ist keine Datenbank.

1. auch Generalisierung. ↩

2. Embeddings in einem Vektorraum. ↩

3. Genauer wäre Konfabulation; der Ausdruck „Halluzinieren“ hat sich aber eingebürgert. ↩

4. Technisch: Temperatur auf null zu setzen. ↩

Das richtige Tool: Eine KI ist keine Datenbank

Eine KI ist keine Datenbank. Das klingt nach einer Selbstverständlichkeit, und doch wird gegen kaum etwas so oft verstoßen. Man stellt einer KI eine Frage, deren Antwort exakt und nachprüfbar sein muss, bekommt eine plausible, aber falsche Auskunft, und schimpft dann auf die KI. Dabei hat man nur das verkehrte Werkzeug gegriffen. Das ist der ganze Kern, und er ist so banal, dass man ihn fast nicht auszusprechen wagt: das richtige Werkzeug für die richtige Aufgabe.

Das bekannteste Gegenbeispiel hat es bis in die Zeitungen geschafft. Ein Anwalt ließ sich von einer KI bei einem Schriftsatz helfen, reichte ihn bei Gericht ein, und dann stellte sich heraus, dass die schön formulierten Präzedenzfälle, auf die er sich berief, samt Aktenzeichen frei erfunden waren.¹ Ein gefundenes Fressen für alle, die ohnehin wussten, dass man dieser Technik nicht trauen darf.

Nur war das kein Versagen der KI, sondern ein Anwenderfehler. Der Anwalt hat von einem unscharfen Werkzeug exakte Fakten verlangt, also genau das, wofür es nicht gemacht ist. Fairerweise muss man dazusagen: Der Fall stammt aus einer Zeit, in der die Modelle noch nicht selbst nachschlagen konnten. Er hätte die Fundstellen gemeinsam mit der KI prüfen müssen, in einer echten Datenbank, statt sich auf ihre Erinnerung zu verlassen.

Denn so sind die Rollen verteilt: Die Datenbank speichert, die KI denkt. Die Datenbank liefert die exakten Fakten, das Aktenzeichen, den Paragraphen, die genaue Schnittstelle. Die KI liefert, was keine Datenbank kann: Sie versteht, was man eigentlich sucht, sie ordnet ein, sie übersetzt eine vage Frage in die richtige Abfrage² und das Suchergebnis zurück in eine Antwort. Eine KI ist keine Datenbank, aber sie kann eine benutzen, und erst so wird aus zwei Werkzeugen ein gutes.

Man kennt das von Ärzten. Der erfahrene erkennt die Diagnose fast im Vorbeigehen, weil er das Muster schon tausendmal gesehen hat. Der weniger erfahrene schlägt nach. Beides hat seinen Wert, und bei etwas Unbekanntem ist Nachschlagen nicht die schlechtere, sondern die klügere Wahl. Eine gute KI verhält sich wie der erfahrene Arzt, der trotzdem weiß, wann er ins Buch schaut.

Und genau hier liegt der zweite Schlüssel, neben dem richtigen Werkzeug. Heute kann eine KI selbst nachschlagen und ihre Quellen überprüfen. Sie tut es nur, wie ein Mensch auch dann, wenn sie es für nötig hält und es nicht zu mühsam ist. In unserem Fall hätte sie es mit Sicherheit getan. Das Halluzinieren lässt sich also dort entschärfen, wo es gefährlich wird, wenn wir ihr die Gelegenheit geben, Datenbanken einfach und schnell zu nutzen. Wie das geht, kommt später. Zuerst schauen wir uns an, wo eine KI angeblich überhaupt nichts zu suchen hat.

1. Der reale Fall: Mata v. Avianca, U.S. District Court für den Southern District of New York, 2023 — ein mit ChatGPT erstellter Schriftsatz voller erfundener Urteile. ↩

2. Eine vage Frage in eine präzise Datenbankabfrage: NL2SQL. ↩

KI im kritischen Umfeld: nur lesen, nicht eingreifen

Es gibt einen Ort, an dem so gut wie jeder sofort sagt: Hier hat eine KI nichts verloren. Stellen wir uns einen Server vor, irgendeinen, es spielt keine Rolle, was genau darauf läuft. Wichtig ist nur, dass viel zusammenkommt: zahllose Schnittstellen nach außen, angeschlossene Geräte, komplexe Wechselwirkungen. Auf diesem Rechner gibt es gerade ein Problem, und niemand hat eine Ahnung, woran es liegt. Eine ordentliche Dokumentation existiert natürlich nicht, von einer aktuellen ganz zu schweigen. Es ist die Maschine eines Kunden, und der Fehler muss schnell weg.

Wer jetzt vorschlägt, eine KI darauf anzusetzen, erntet entsetzte Blicke. Gerade Entscheider, die selbst nicht aus der Technik kommen, winken sofort ab, und in vielen Häusern ist es verboten. Aus, wie ich finde, drei sehr nachvollziehbaren Gründen:

1. Kritisches Produktivsystem. Eine KI kann hier echten Schaden anrichten, Daten zerstören, den Betrieb lahmlegen. Und wer haftet dann? (Compliance)
2. Keine Nachvollziehbarkeit. Hinterher weiß niemand, was sie verändert hat. (Audit)
3. Datenabfluss. Vertrauliches könnte nach außen gelangen. (Exfiltration)

Diese drei Einwände sind berechtigt, jeder einzelne, und niemand kann ihnen ernsthaft widersprechen.

Nur lohnt es sich, einen Schritt weiterzudenken und zu fragen, ob die Schlussfolgerung wirklich stimmt. Schauen wir genau hin, was die drei Punkte besagen. Sie sagen: Die KI darf auf diesem Server nichts verändern, und es darf nichts hinausfließen. Sie sagen nicht, dass die KI das Problem nicht analysieren darf.

Damit ist die Sache fast schon gelöst. Wir setzen die KI nicht ein, um den Server zu reparieren, wir setzen sie ein, um ihn zu verstehen. Sie liest, sie wertet aus, sie sucht, aber sie fasst nichts an. Die ersten beiden Einwände sind damit erledigt, denn wer nichts verändert, kann nichts kaputt machen und hinterlässt kein Chaos. Und weil am Ende ein Mensch entscheidet und die Änderung selbst vornimmt, bleibt auch die Haftung dort, wo sie hingehört, bei ihm.

Praktisch braucht die KI dafür nur eines: Zugang zu den richtigen Logdateien, den Protokollen, die ein Server über sich selbst führt.¹ Bei einem gut gewarteten System liegt vieles davon ohnehin offen. Um tiefer zu graben, nutze ich ein kleines, selbstgeschriebenes Werkzeug², dem ich vertraue, weil ich genau weiß, was es tut, und vor allem, was es nicht tut. Es holt auf Anforderung die passenden Protokolle zu einem bestimmten Zeitraum, kompakt und ausschließlich lesend, und reicht sie der KI. Die grenzt die Ursache dann erstaunlich schnell ein. Vielleicht stellt sich heraus, dass eine Programmbibliothek auf eine neue Version gehoben wurde und die Gegenstelle ihre Schnittstelle geändert hat, der Server aber nicht. Wir stoßen ein paar Tests an, lassen die Ergebnisse von der KI bewerten, und Schritt für Schritt kommen wir der Sache auf den Grund. Das alles könnten wir auch von Hand, ohne KI. Nur säßen wir dann erst einmal Stunden daran, uns überhaupt einzuarbeiten.

Bleibt der dritte Einwand, der Datenabfluss, und der ist ernster. Was wir auf keinen Fall nach außen geben wollen, sind Passwörter, Geschäftsgeheimnisse, vertrauliche Daten. Die Lösung ist einfacher, als viele glauben: ein kleines, lokales Modell. Die Protokolle bleiben im Haus, nichts wandert zu einem fremden Anbieter, nichts landet in irgendeinem Training.

Hier räume ich gern mit einem zweiten Reflex auf, dem Glauben, man müsse immer das größte, beste Modell nehmen.³ Für eine Routinearbeit wie das Durchforsten von Logdateien und das Aufspüren von Auffälligkeiten⁴ ist das nicht nur unnötig, sondern hinderlich. Die stärksten Modelle sind teuer und langsam. Wenn ich zwanzig, dreißig Protokolle schnell durchsehen lassen will, nicht nach etwas Bekanntem, sondern nach Anomalien, die ich vorher gar nicht kenne, dann ist ein einfaches, schnelles Modell die bessere Wahl. Ob ich zehn Minuten auf eine Antwort warte oder zwanzig Sekunden, macht einen Unterschied, und zwar nicht nur für die Geduld, sondern für die Konzentration. Dass selbstgehostete Modelle angeblich nichts taugen, ist genau so ein Vorurteil wie die anderen auch.

Und das Halluzinieren, vor dem alle Welt warnt? Spielt hier kaum eine Rolle. Schlägt die KI eine Spur vor, die in die Irre führt, sehen wir das sofort, weil wir jede Vermutung gegen die Wirklichkeit prüfen können, gegen die Protokolle, gegen einen Test. Sie darf ruhig einmal danebenliegen, wie ein Mensch auch. Es kostet uns nichts.

Aus dem vermeintlichen Totalverbot ist so ein geradezu ideales Einsatzfeld geworden. Wir haben kein einziges der berechtigten Bedenken übergangen, wir haben sie alle erfüllt, und trotzdem hilft uns die KI genau dort, wo ein Mensch in der Eile und mit müden Augen am ehesten etwas übersieht. Wieder ist es nur das richtige Werkzeug für die richtige Aufgabe.

Bisher durfte die KI ausschließlich lesen. Wagen wir nun den Schritt weiter und lassen sie an einer Veränderung mitwirken.

1. Wie viel ein System über seinen eigenen Zustand preisgibt, fasst der Begriff Observability. ↩

2. Solche Werkzeuge bindet man heute über das Model Context Protocol (MCP) an die KI an. ↩

3. Small Language Models (SLM) — im Gegensatz zu den größten, den Frontier Models. ↩

4. Das Suchen nach unbekannten Auffälligkeiten: Anomaly Detection. ↩

Ein Schritt weiter: die KI darf verändern

Im vorigen Kapitel haben wir gesehen, dass sich mit der richtigen Herangehensweise selbst verbotenes Terrain betreten lässt. Dort durfte die KI nur lesen. Jetzt gehen wir einen Schritt weiter und wenden uns dem Herzstück jeder größeren Infrastruktur zu, ihrer Konfiguration, und diesmal soll die KI nicht nur zusehen, sondern mitverändern. Damit nähern wir uns zugleich dem großen Ziel dieses Textes, dem Programmieren, denn im Kern ist es dieselbe Arbeit.

Für alle, die nicht aus der IT kommen, kurz erklärt: Eine Infrastruktur zu konfigurieren heißt, viele Rechner, Netzwerke und Router nicht mehr einzeln von Hand einzustellen, sondern über Konfigurationsdateien zu beschreiben; Fachleute nennen das Infrastructure as Code.¹ Bei zwei, drei Rechnern wäre das übertrieben, bei ein paar tausend ist es unverzichtbar, und genau deshalb sind dafür mächtige Werkzeuge entstanden. Die Entscheidung, was wohin gehört, nehmen sie einem aber nicht ab. Die muss man ihnen schon sagen.

Man beschreibt also den Zustand, den man haben will.² Eine Firewall-Regel etwa gilt dann nicht für einen einzelnen Rechner, sondern für eine ganze Gruppe. Braucht eine Maschine eine Ausnahme, schreibt man die ebenfalls in den Code, an einer Stelle, nachvollziehbar für alle. Und man kann testen, ob es funktioniert, die Änderung schrittweise ausrollen und automatisch kontrollieren lassen. Das klingt nach Kontrolle, und das ist es auch. Nur hat sie eine Kehrseite: Wo früher hundert Leute hundert Rechner betreut haben, machen das heute zehn. Die Hebelwirkung ist gewaltig. Eine einzige falsch gesetzte Einstellung, und es steht nicht ein Rechner still, sondern alle.³

Und damit sind wir bei dem, worum es hier geht: bei dem Menschen, der unter Druck steht. Den gibt es beim besten Arbeitgeber und in der besten Organisation. Irgendwann muss eine Änderung schnell raus, und genau dann passieren die Fehler. Der gut gemeinte Hinweis „konzentrier dich doch mal“ hilft in diesem Moment herzlich wenig. Was also spricht dagegen, ein Verfahren zu überlegen, bei dem der Mensch nicht nur unterstützt wird, sondern tatsächlich weniger Fehler macht?

Auf den ersten Blick wirkt das einfach: Wir machen eine Änderung, und die KI prüft hinterher, ob sie richtig war. So einfach ist es vorne und hinten nicht. Aber gehen wir einen Fall durch.

Ein Kunde schreibt uns eine E-Mail. Irgendetwas funktioniert nicht, und er beschreibt, so gut er kann, woran es seiner Meinung nach liegen könnte. Wir setzen uns hin, überlegen, welche Änderung nötig ist, führen sie durch und rollen sie auf die paar hundert Rechner aus, bei einigen mit Ausnahmen, weil dort etwas anderes gilt. Dann hoffen wir, dass es ungefähr das ist, was der Kunde wollte, und lassen am Ende nachsehen, ob noch alles läuft.

Dieses Prüfen ist heute meist automatisiert. Man nennt es eine Pipeline⁴: Schritt für Schritt wird kontrolliert, ob noch alles funktioniert. Nur steckt in diesem „alles“ eine Tücke. Geprüft wird nämlich genau das, woran wir vorher gedacht haben. Die Dinge, an die wir nicht gedacht haben und die vielleicht gerade deshalb kaputtgehen, prüft niemand. Und genau das schreit nach einer KI.

Damit sie uns helfen kann, müssen wir ihr allerdings sagen, was wir wollen. Das klingt nach Zusatzarbeit, ist aber das Gegenteil. Wir schreiben zuerst auf, was wir vorhaben. Wir haben ja zwei Dinge: die E-Mail des Kunden und unsere Vorstellung davon, was zu ändern ist. Und die beiden decken sich fast nie, weil der Kunde von der Technik naturgemäß wenig versteht. Deshalb hat er uns ja beauftragt.

Also überlegen wir uns, was er meint, und wie wir das erreichen, was er möchte. Wir übersetzen seinen Wunsch in ein technisches Konzept. Dieses Konzept übersetzen wir in Konfigurationsdateien. Und die werden wiederum übersetzt in echte, laufende Infrastruktur.

Diese Kette aus Übersetzungen ist der Punkt, auf den es ankommt. Jede Stufe ist eine Quelle für Missverständnisse, und der größte Fehler von allen lauert ganz am Anfang, zwischen der E-Mail und dem, was wir daraus machen.

Das ist übrigens der klassische Moment, in dem man am besten mit einem Kollegen redet. Man erklärt ihm einfach, was man vorhat, und allein beim Erklären merkt man meistens schon, ob es stimmt oder ob man etwas übersehen hat. (Rubber-Duck-Debugging ⁵) Genau dafür bietet sich die KI an. Wir lassen sie prüfen, ob das, was wir aufgeschrieben haben, zu dem passt, was in der Mail steht, und wir reden mit ihr wie mit einem Menschen. Vielleicht weist sie uns darauf hin, dass die Formulierung des Kunden mehrdeutig war und er eigentlich etwas anderes gemeint hat.

Das hilft schon ein gutes Stück weiter. Aber wir wollen es nicht jedes Mal neu erklären, also automatisieren wir es. Dafür gibt es so etwas wie eine Programmierung für KI, die in Wahrheit harmlos ist: Man schreibt einmal auf, wie man arbeiten will, und ruft das immer wieder ab. Am einfachsten nennt man das einen Skill. Das hört sich großartig an, ist aber nichts weiter als eine Sammlung von Anweisungen, gebündelt, damit wir sie auf Knopfdruck haben.

Unser Skill sagt im Kern: Schau dir die E-Mail an, schau dir an, was ich aufgeschrieben habe, mach dir Gedanken, ob beides zusammenpasst, und prüfe vor allem, ob meine Aufgabendatei präzise genug formuliert ist. Dieses „präzise genug“ ist ein Punkt, den Menschen nur zu gern übersehen.

Nehmen wir an, wir haben diese Datei geschrieben, den Zettel, die Notiz, wie auch immer. Es ist nicht eilig, also gehen wir erst einmal Mittagessen. Wir kommen zurück, lesen das Ganze erneut und stellen fest: So eindeutig, wie wir dachten, war es gar nicht. Inzwischen haben wir mit Kollegen geredet, mit einem anderen Kunden telefoniert, und plötzlich würden wir es ein wenig anders machen. Das passiert, und zwar öfter, als einem lieb ist. Wir hätten es eben präziser aufschreiben sollen.

Hier ist genau das schon erledigt. Die KI hat sich das angeschaut, hat mit uns geredet, und wenn alles klar ist, haben wir einen Auftrag, der präzise beschreibt, was zu tun ist. Das sind nicht die drei, vier Wörter, die wir sonst hingekritzelt hätten, sondern zwei kurze Absätze, die genau festhalten, was sich ändern soll. Das kostet uns kaum Zeit, aber wir haben es schwarz auf weiß und können unsere Änderung gezielt durchführen.

Und jetzt kommt der eigentliche Gewinn. Im letzten Schritt lassen wir prüfen, wieder über den Skill, damit wir es nicht jedes Mal neu sagen müssen: Schau dir die Änderung an, die ich gemacht habe. Führt sie genau zu dem, was wir uns überlegt haben?

Dafür fehlt nur eine Kleinigkeit: Die KI braucht Zugriff auf das, was geändert wurde. Das ist in aller Regel kein Problem, denn solche Konfigurationsdateien liegen in einem Versionierungssystem, meistens Git. Jede Änderung wird gespeichert, man kann jede einzelne im Nachhinein ansehen, und man hat Zugriff auf sämtliche Konfigurationsdateien des Systems. Die KI kann also schon vorher schauen, ob unsere geplante Änderung die richtige Wirkung hätte, und hinterher, ob sie das gewünschte Ergebnis bringt. Zusätzlich lassen wir sie gegenprüfen, ob Nebenwirkungen aufgetreten sind, die wir nicht wollten.

Ein Schritt darf dabei nicht fehlen, und der gehört dem Menschen: Bevor die Änderung tatsächlich hinausgeht, schaut er selbst noch einmal darüber. Die KI bereitet vor, sie ordnet ein, sie warnt, aber die Entscheidung und der prüfende Blick bleiben bei uns.

Bleibt die Frage, was das Ganze bringt und was es kostet. Die ehrliche Antwort: Es sind zwei Aufrufe. Wir starten am Anfang den ersten Skill und am Ende den zweiten. Zum ersten gehört, dass wir mit der KI reden und uns zwingen, einen Gedanken tiefer zu gehen, mit einem Gegenüber, das uns darauf stößt, was wir übersehen haben. Das dauert ein paar Minuten. Aber gerade in diesem Umfeld lohnt sich das.

Was haben wir erreicht? Wir haben die KI genutzt, um unsere Gedanken sauber zu formulieren und den Auftrag präzise zu fassen, und wir haben sie genutzt, um am Ende zu überprüfen, was wir getan haben. Eine ganze Klasse von Fehlern, die aus Stress und Eile entstehen, ist damit nicht verschwunden, aber deutlich seltener geworden. Und das Schönste: Wir haben dabei nichts getan, was die Sicherheit des Systems gefährdet. Im Gegenteil, wir haben sie erhöht. Damit dürfte allen, die meinen, eine KI habe in produktiven Systemen nichts verloren, zumindest ein wenig der Wind aus den Segeln genommen sein. Im nächsten Kapitel bauen wir dieses Verfahren aus, und genau da fängt es an, richtig interessant zu werden.

1. Die bekanntesten Werkzeuge dafür sind Terraform und Ansible. ↩

2. Den Soll-Zustand statt einzelner Schritte: deklarativ. ↩

3. Blast Radius. ↩

4. CI/CD-Pipeline: automatische Prüf- und Ausrollkette ↩

5. Dieses Klären durchs Erklären heißt unter Entwicklern Rubber-Duck-Debugging — zur Not erklärt man es einer Gummiente. ↩

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

Im letzten Kapitel haben wir aus einem Auftrag, einer Prüfung und einem menschlichen Blick ein erstaunlich sicheres Verfahren geschaffen. Jetzt bauen wir es aus, mit ein paar Schritten, die für sich genommen alle simpel sind und erst zusammen ihre Wirkung entfalten.

Der erste Schritt ist eine einmalige Fleißarbeit, die wir nicht selbst machen, sondern die KI machen lassen. Sie stellt ein gründliches Bild des gesamten Systems zusammen, nicht nur aus den Konfigurationsdateien, sondern auch aus dem, was dazwischensteht: warum etwas so gebaut ist, welche Anwendungen laufen, was an was hängt. Es macht einen gewaltigen Unterschied, ob wir ein Telekommunikationsunternehmen vor uns haben oder eine Großbäckerei. Beide haben völlig andere Anforderungen, und für beide ist etwas anderes kritisch. Am Ende steht eine große Datei, in der das Wichtigste versammelt ist. Ich nenne sie das Briefing.

Der zweite Schritt ist eine Datei, die den aktuellen Zustand festhält, den Ist-Zustand. Bei einfachen Aufbauten kann man darüber streiten, schließlich liegen die Konfigurationsdateien ohnehin vor uns. Sobald es komplexer wird und wir nicht mehr auf alles jederzeit Zugriff haben, ist sie Gold wert. Wichtig ist, dass diese Datei nicht die KI schreibt, sondern ein schlichtes Werkzeug, das alle relevanten Daten einsammelt und sortiert ablegt, damit man sie später vergleichen kann. Einmal erzeugt, von da an fortgeschrieben.

Damit beginnt der Ablauf. Sagen wir, der Kunde ruft an, diesmal kein sauber formulierter E-Mail-Text, sondern ein Telefonat, an ein, zwei, drei Stellen hätte er es gern etwas anders. Wir notieren, so gut es geht, und starten wie gehabt den ersten Skill, also wieder eine festgehaltene Arbeitsweise, die wir per Knopfdruck aufrufen. Ihm geben wir unsere Gesprächsnotizen, erzählen, was wir verstanden haben und was wir vorhaben, und reden mit der KI durch, was wirklich gemeint ist und wo es haken könnte. Heraus kommt, wie im letzten Kapitel, ein präziser Auftrag. Den könnten wir dem Kunden zur Sicherheit sogar per Mail zur Bestätigung schicken.

Jetzt kommt der entscheidende Schritt, das Herzstück des ganzen Verfahrens: Aus dem Auftrag wird ein Task. Das ist eine Datei, die genau genug festhält, was zu tun ist, welche Konfigurationsdateien sich wie ändern sollen und vor allem warum. Oben steht das Ziel, dann der Weg dorthin. Was nicht drinsteht, ist der fertige Code bis ins letzte Zeichen. Es findet sich darin, was wir wollen, so präzise, wie wir es besprochen haben, nicht mehr und nicht weniger.

Und genau hier, im Task, steckt der eigentliche Unterschied zu blindem Drauflosarbeiten, auch wenn er leicht zu übersehen ist. Dieser Task ist kein bloßer Zettel mit Anweisungen. Er entsteht auf eine besondere Weise, die dafür sorgt, dass unser Ziel möglichst gut getroffen wird und dass die typischen Fehler, die eine KI dabei macht, gar nicht erst durchschlagen. Vorerst nehmen wir das als gegeben: Steht der Task, wird er ausgeführt, eine zweite KI prüft die Änderung, der Mensch wirft den letzten, entscheidenden Blick darauf¹, und erst dann rollen wir aus.

Der letzte Schritt ist derselbe wie im Kapitel zuvor, nur ein wenig erweitert. Die KI prüft, ob die Änderung im Betrieb tatsächlich greift und keine Nebenwirkungen hat. Zusätzlich baut jetzt das Werkzeug von vorhin den Ist-Zustand neu auf, indem es wieder alles einsammelt. Ein Werkzeug, nicht die KI, bildet die Differenz zum vorigen Stand², und die legen wir der KI vor. Sie ist gut darin zu beurteilen, ob zu viel verändert wurde, ob das Gewünschte erreicht ist, und ob das, was tatsächlich herauskam, zu dem passt, was wir wollten.

Dieser neue Stand wird die Grundlage für das nächste Mal. Nebenbei haben wir damit eine ordentliche Versionierung, in der nicht nur steht, wann und was sich geändert hat, sondern auch warum.³ Und das ist mehr wert, als es klingt. Kommentare, die das Warum festhalten, sind in der Praxis selten. Fragt einen ein Kollege ein halbes Jahr später, warum etwas damals so entschieden wurde, lautet die Antwort meist „weil der Kunde es wollte“. „Dann zeig mir die Mail.“ Nur war es diesmal ein Telefonat. Gut, wenn dann wenigstens eine nachvollziehbare Spur bleibt, mit der sich später etwas anfangen lässt.

So fügt sich jeder Eingriff nachvollziehbar in den vorigen, und das System bleibt jederzeit beschreibbar und überprüfbar. Wie aber aus unserem Auftrag ein so verlässlicher Task wird, einer, der die typischen Fehler der KI von vornherein umgeht, ist der Kniff. Ihm widmen wir das nächste Kapitel.

1. Dieses Trennen von Ausführen und Prüfen ist das Vier-Augen-Prinzip (englisch Maker-Checker). ↩

2. Das automatische Erkennen von Abweichungen zum vorigen Stand heißt Drift Detection. ↩

3. Das bewusste Festhalten des Warum hinter einer Entscheidung nennt man Architecture Decision Record (ADR). ↩

Verschiedene Blickwinkel: der zweifach moderierte Dialog

Wie schon erwähnt, ist der Task, also die in einer Datei festgehaltene Arbeitsanweisung, die zentrale Komponente unseres Verfahrens, und um sie geht es in diesem Kapitel. Auch hier gilt: Eine KI ist am Ende auch nur ein Mensch, sie macht Fehler, und der Zuruf „konzentrier dich und mach es richtig“ hilft ihr so wenig wie uns. Es gibt aber einen Trick, der bei Menschen seit jeher funktioniert und bei der KI ebenso: die Sache aus einem anderen Blickwinkel betrachten. Das ist der Hebel dieses Kapitels, und ich halte ihn für einen der wichtigsten des ganzen Textes.

Erreichen lässt sich das mit einem Verfahren, das ich den zweifach moderierten Dialog nenne. Es klingt aufwendiger, als es ist.

Wir setzen nicht eine KI an, sondern mehrere¹, und zwar bewusst ungleiche, gern sogar verschiedene Modelle, auf jeden Fall aber mit unterschiedlichem Charakter, sodass sie dasselbe Problem von mehreren Seiten ansehen. Ich nenne diese künstlichen Charaktere Personas. Unseren Task haben wir vorwärts geschrieben: Hier ist das Problem, so lösen wir es. Jetzt drehen wir die Blickrichtung um. Die erste Persona bekommt den Auftrag, sich den Task anzusehen und zu prüfen, ob er unsere wahre Aufgabe löst, die ganz oben steht. Sie muss vom Ziel her denken², statt unserem Lösungsweg nur zu folgen und ihm zuzunicken, und allein dieses Rückwärtsdenken fördert erstaunlich viel zutage.

Wie gut das wirkt, zeigt ein Beispiel, das gern durch die Medien gereicht wird, um vorzuführen, wie wenig eine KI verstehe: Soll man zu einer zweihundert Meter entfernten Waschanlage zu Fuß gehen oder mit dem Auto fahren? Reflexhaft rät das Modell zum kurzen Fußweg, es ist ja nur ein Katzensprung. Damit folgt es dem naheliegenden Lösungsweg und übersieht das Ziel: Gewaschen werden soll das Auto, und dafür muss es mit. Genau diesen Fehler fängt die erste Persona ab, weil sie nicht fragt, wie man zur Waschanlage kommt, sondern was am Ende erreicht sein soll, und sofort sieht, dass nur die Fahrt mit dem Auto die Aufgabe löst.

Weil sie zugleich genauer hinschaut, ob das Ergebnis wirklich das Gewollte ist, findet sie bei allem, was nicht trivial ist, fast immer etwas zu bemängeln. Diese Kritik übernehmen wir aber nicht einfach in den Task. Stattdessen tritt eine zweite Persona auf, mit anderem Charakter, die nur eine Aufgabe hat: zu prüfen, ob die Kritik überhaupt berechtigt ist.³

Damit haben wir, fast beiläufig, einen dritten Blickwinkel gewonnen, denn diese zweite Persona sucht die Schwachstellen nicht selbst, sie beurteilt bereits gefundene. Sie kann sagen: ja, ein echter Fehler, der muss korrigiert werden. Oder: das müssen wir erst klären. Oder: nein, das ist ein Missverständnis, im Task stand es richtig.

Gerade die letzte Antwort ist interessant, denn sie geht zurück an die erste Persona, die nun ihrerseits darauf erwidert. Als ich damit anfing, hat mich ehrlich überrascht, wie oft das hin und her geht, als würde die KI mit sich selbst diskutieren.

Damit das nicht ausufert, kommt der Moderator ins Spiel, eine dritte Instanz. Die beiden Personas reden nicht direkt miteinander, er reicht die Antworten weiter. Worin sie sich einig sind, hält er als geklärt fest und schreibt es in unsere Datei. Was strittig bleibt, schickt er ein paar Mal hin und her, je nachdem drei- oder viermal. Irgendwann entscheidet er selbst, weil er genug gehört hat, oder er fragt uns. Unterm Strich arbeiten so vier verschiedene KIs an einer einzigen Frage.

Jetzt könnte man einwenden, das täten die neueren Modelle doch von allein, dieses Nachdenken über die eigenen Gedanken, dieses Mit-sich-selbst-Reden.⁴ Das tun sie, aber darum geht es nicht. Das Entscheidende ist, dass wir die unterschiedlichen Blickwinkel herstellen, statt darauf zu hoffen. Genau das ist das A und O.

Damit fangen wir die Fehler ab, die aus falschen Annahmen entstehen. Es bleibt ein zweiter, ebenso wichtiger Hebel, und er trifft das Halluzinieren unmittelbar: die KI dazu zu bringen, nachzuschlagen, statt zu raten.

1. Mehrere bewusst verschiedene Modelle auf dieselbe Frage anzusetzen, nennt man ein Ensemble. ↩

2. Vom gewünschten Ergebnis her rückwärts zu denken, heißt Working Backwards. ↩

3. Eine KI eine andere bewerten zu lassen, läuft als LLM-as-a-Judge. ↩

4. Dass Modelle vor der Antwort sichtbar Schritt für Schritt nachdenken, heißt Chain-of-Thought (Reasoning). ↩

Die KI zum Nachschlagen bringen: Werkzeuge und RAG

Den ersten Hebel haben wir, die verschiedenen Blickwinkel. Der zweite ist im Grunde noch einfacher und trifft das Halluzinieren mitten ins Herz: Wir machen der KI das Nachschlagen so leicht, dass sie es auch tut. Denn Halluzinieren bei Fakten ist weniger ein Charakterfehler als eine Frage der Hemmschwelle.

Wir nutzen die KI für das, was sie auszeichnet, und überlassen den Rest den Werkzeugen, dem Sammeln, dem Auslesen, dem Vergleichen. Beim Halluzinieren aber wird es heikel. Eine KI muss halluzinieren dürfen, das wissen wir inzwischen, nur dürfen wir die Nachteile nicht mitnehmen, wie beim Anwalt aus dem dritten Kapitel. Die Lösung steckt schon dort: Eine KI ist keine Datenbank, aber sie kann eine benutzen. Die neueren Modelle tun das auch, nur längst nicht oft genug.

Das hat einen handfesten Grund. Eine KI kennt die Dinge nie ganz aktuell.¹ Früher hinkte ihr Wissen zwei Jahre hinterher, heute sind es vielleicht ein paar Monate. Für Allgemeinwissen ist das gleichgültig, aber bei Programmen und Schnittstellen, die sich gefühlt im Wochentakt ändern, sind selbst diese wenigen Monate zu viel.

Nachschlagen kann sie inzwischen selbst. Nur läuft das oft so: „Kennst du dieses Programm?“ „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.“ Man kennt das. Genau deshalb habe ich mir früh angewöhnt, gar nicht erst zu fragen „kennst du das“, sondern „prüfe die aktuelle Version, und wenn du sie nicht kennst, lies erst die Änderungen nach“. Widerwillig befolgt, aber es half.

Inzwischen mache ich es anders. Zu Beginn eines Projekts stoße ich eine gründliche Recherche an, wieder über einen Skill, der das einmal Festgelegte selbständig erledigt. Er nimmt sich alle Werkzeuge und Bausteine vor, die wir nutzen, holt zu jedem die aktuelle Version und lädt die Dokumentation herunter, und zwar nicht nur die des Herstellers, sondern auch das, was in Foren steht: wo die Doku falsch ist, wo sie veraltet ist, wo es hakt. Das klingt nach gewaltigen Datenmengen, ist es aber selten, denn veraltete Dokumentation ist meist dünn. Und die Arbeit macht ohnehin die KI.

Warum der Aufwand, mag man fragen, sie kann doch bei Bedarf nachschlagen? Kann sie, aber Nachschlagen ist teuer. Sie muss herausfinden, wo sie sucht, einen Link auftreiben, der funktioniert und der eine KI überhaupt hereinlässt, einschätzen, wie alt die Information ist, und das jedes Mal. Also wägt sie ab, ganz wie ein Mensch. Wer sich zu hundert Prozent sicher ist, schlägt nicht nach. Wer sich zu achtzig Prozent sicher ist, meistens auch nicht. Und wer gar nicht weiß, wo er nachschlagen soll, probiert es eben. Bei der KI heißt dieses Probieren halluzinieren.

Unser Ziel ist also, diese Hemmschwelle zu senken. „Schlag immer nach“ ist keine Lösung, dann tut sie nichts anderes mehr. Besser ist, die Information in Reichweite zu legen.

Dafür gibt es ein Werkzeug, das für viele nach Overkill aussieht, weshalb sie es scheuen und sich lieber über das Halluzinieren beklagen: ein RAG.² Dahinter steckt nichts Furchteinflößendes. Ein RAG ist im Kern eine große Datenbank, die auch dann etwas findet, wenn man nicht genau weiß, wonach man sucht. Anders als eine KI tut sie das nicht aus Erfahrung: Sie zerlegt lange Texte in kleine, zusammenhängende Stücke³ und durchsucht sie nicht nach Stichwörtern, sondern nach ihrer Bedeutung.⁴ So findet sie die richtige Stelle auch dann, wenn man ganz anders danach fragt, als sie dort formuliert ist. Man kennt das von riesigen Datenmengen, aber im Kleinen ist der Aufwand winzig.

Ich habe dafür wieder mein selbstgeschriebenes Werkzeug genommen, dem ich vertraue. Es nimmt mir zugleich die Mühe, ein RAG von Grund auf aufzusetzen. Ich werfe die gesammelten Texte hinein, das Werkzeug zerlegt und sortiert sie, und die KI greift darauf zu.

Von da an kann die KI einfach fragen: Ich will diese Funktion benutzen, welche Parameter hat sie? Und sie bekommt die Antwort sofort, schneller, als sie sie aus dem eigenen Gedächtnis hervorkramen könnte, und in der aktuellen, richtigen Fassung. Sie muss nicht mehr raten⁵, sie muss sich nur erinnern, dass es diese Funktion gibt. Damit das noch leichter fällt, fassen wir die große Datei am Anfang knapp zusammen und geben sie der KI gleich zu Beginn, damit sie ungefähr weiß, was im RAG steckt und wo sie bei Zweifeln nachfragen kann.

Als ich das zum ersten Mal eingerichtet hatte, hätte ich nicht gedacht, was für ein immenser Unterschied das macht. Wie oft hatte ich vorher gesagt „schau halt nach, verifizier das“, oder mich geärgert „warum machst du das so kompliziert, warum nicht die einfachere Funktion?“, und die Antwort war „daran hatte ich nicht gedacht, die ist wohl neuer”.

Den vollen Nutzen ziehen wir, indem wir diese Recherche mit dem Task aus dem vorigen Verfahren verbinden. Wir erweitern ihn um genau diese Hinweise: Im Task steht jetzt nicht nur, was zu tun ist und wie, sondern auch, welche Zusatzinformationen die KI im RAG findet, welche Teile unserer eigenen Dokumentation eine Rolle spielen und wo es dazu Diskussionen gab. So hält die KI in einer einzigen, recht kurzen Datei einen vollständigen Arbeitsauftrag in der Hand: das Ziel und den Weg, die Unterlagen, die sie heranziehen kann, das, was sie im RAG nachschlagen sollte, die Punkte, auf die am Ende zu achten ist, und die Stellen, an denen Nebenwirkungen lauern könnten. Später hält dieselbe Datei sogar fest, wie weit die Arbeit schon gediehen ist.

Zusammen mit den verschiedenen Blickwinkeln aus dem letzten Kapitel nehmen wir dem Halluzinieren so den größten Teil seiner Gefahr. Wir nutzen die KI für ihre Erfahrung und das RAG für die Fakten, genau die Rollenverteilung, die wir ganz am Anfang gefordert haben: Die KI ist keine Datenbank, aber sie benutzt eine. Damit ist unser größtes Problem gelöst.

1. Der Zeitpunkt, bis zu dem eine KI etwas gelernt hat, heißt Knowledge Cutoff. ↩

2. Ausgeschrieben Retrieval-Augmented Generation: Die KI ergänzt ihre Antwort um nachgeschlagenes Wissen, statt allein aus dem Gedächtnis zu schöpfen. ↩

3. Das Zerlegen langer Texte in kleine, durchsuchbare Stücke heißt Chunking. ↩

4. Dieses Suchen nach Bedeutung statt nach Stichwörtern heißt semantische Suche (oder Vektorsuche). ↩

5. Antworten an nachgeschlagene Fakten zu binden, statt sie zu raten, nennt man Grounding. ↩

Was Vibe-Coding wirklich ist

Bisher haben wir die KI nur Konfigurationen ändern lassen, vorsichtig, mit Netz und doppeltem Boden. Das klingt nach kleiner Münze, war aber in Wahrheit die Mutprobe: an einem produktiven System etwas verändern, ohne es kaputtzumachen. Wer das beherrscht, ist bereit für den großen Schritt. Wir lassen die KI jetzt richtig programmieren.

Und gleich zu Beginn muss ein Missverständnis weg, das selbst unter Technikern hartnäckig hält. Programmieren heißt nicht, Code zu tippen. Das Tippen ist das Wenigste. Die eigentliche Aufgabe ist, ein ganzes System zu entwerfen¹: die einzelnen Bausteine, die Infrastruktur darunter, die Auswahl der Werkzeuge und der Bibliotheken², also der fertigen Codeteile, die andere bereits geschrieben haben, und vor allem das Zusammenspiel von alldem. Der Code selbst ist am Ende fast das Nebenprodukt.

Gerade bei dieser Auswahl ist eine KI kaum noch zu ersetzen: Die Zahl der Werkzeuge und Bausteine wächst schneller, als ein Einzelner sie überblickt. Sie sucht nicht nur schneller, sie bewertet auch: Sie liest das Gemecker in den Foren und sagt uns, wo ein Werkzeug in der Praxis hakt. Sie hier nicht zu nutzen, wäre fahrlässig.

Dieser Text bringt der KI nicht das Programmieren bei; dafür gibt es Artikel genug, und die Modelle werden darin von allein besser. Er zeigt etwas anderes: wie man die Fähigkeiten, die die KI längst hat, so einsetzt, dass am Ende Code herauskommt, wie ich ihn selbst geschrieben hätte. Dafür bringe ich ein, was keine KI besitzt: dreißig Jahre Erfahrung mit genau dieser Arbeit, die ich jetzt nicht mehr mit einem Team aus Menschen fortführe, sondern mit einem aus KIs.

Wie weit trägt das schon? Dazu ein Wort zum Zeitpunkt, denn nichts in diesem Text veraltet schneller. Stand Anfang 2026 sind die besten Modelle so weit, dass sie selbstständig brauchbaren Code schreiben, in einer Qualität, die man fairerweise mit der eines Junior-Entwicklers vergleicht: jemand, der das Programmieren gelernt und kleinere Projekte hinter sich hat. Genau das können einige KIs heute auch. Dass daraus gerade handfeste gesellschaftliche Verwerfungen entstehen, steht auf einem anderen Blatt und gehört nicht hierher; uns interessiert eine kleinere, fast kuriose Beobachtung.

Diese KIs machen nämlich exakt dieselben Fehler wie ein Junior-Entwickler aus Fleisch und Blut.³ Nicht ähnliche, dieselben. Geht man die typischen Schwächen eines Anfängers durch, eine nach der anderen, findet man sie alle bei der KI wieder. Zum Teil liegt das an der fehlenden Erfahrung, an eben jenen zwanzig, dreißig Jahren, die dem menschlichen Anfänger genauso fehlen. Aber nicht nur. Der KI fehlt etwas Grundsätzlicheres. Sie hat gelernt, wie guter Code aussieht, indem sie unzählige fertige Programme angesehen hat. Was sie nie getan hat, ist, selbst zu programmieren, ein System über Jahre zu pflegen und am eigenen Leib zu erfahren, welche Entscheidung von heute sich in zwei Jahren rächt.⁴ Diese Erfahrung macht sie nicht, und sie lernt auch nicht aus ihr, denn solches Wissen fließt aus naheliegenden Gründen kaum in ihr Training zurück: Keine Firma und kein Entwickler gibt freiwillig preis, wo er sich jahrelang geirrt hat.

Man versucht, das auszugleichen, indem man der KI ein immer größeres Gedächtnis gibt.⁵ Nur ersetzt auch der beste Speicher keine Erfahrung, und die eleganteren Wege dahin kennt die KI noch nicht. Halten wir es fest: Wir haben einen begabten, aber unerfahrenen Mitarbeiter vor uns. Mit dem lässt sich Großes anfangen, wenn man weiß, wovon man redet. Und das beginnt mit einer unbequemen Frage: Was macht guten Code aus?

Die Antwort fällt provokanter aus, als man denkt: Ein Programm zu entwickeln, das tut, was es soll, ist zweitrangig.

Wichtiger ist Code, der fehlerfrei bleibt, der nachhaltig ist und der vorausschauend gebaut ist, so, dass die Probleme von morgen gar nicht erst entstehen.

Jetzt regt sich der Widerspruch: Das Programm muss doch erst einmal laufen! Natürlich muss es das. Nur ist gerade das eine Selbstverständlichkeit, die Eintrittskarte, kein Verdienst. Die eigentliche Kunst liegt woanders: ob ich denselben Code in einem halben Jahr noch verstehe, ob ich ihn leicht warten und erweitern kann, und ob er auf die Probleme vorbereitet ist, die erst in Zukunft auftauchen. Guter Code denkt voraus. Schlechter Code funktioniert auch, bis man ihn das erste Mal anfassen muss.

Und genau dieses Vorausdenken trennt den erfahrenen Entwickler vom Anfänger. Ein einzelner Junior beherrscht es noch nicht, und eine KI, wir ahnen es bereits, eben auch noch nicht. Sie schreibt Code, der läuft; ob er in zwei Jahren noch zu retten ist, war nie Teil dessen, was sie gelernt hat. Dieses Wissen müssen wir mitbringen, und es ist genau das, was aus einem Haufen funktionierender Bausteine ein tragfähiges System macht.

Denn ein System ist mehr als die Summe seiner Teile, und je größer es wird, desto schwerer fällt etwas, das viele unterschätzen: den Überblick über das Ganze zu behalten und zugleich an einem einzelnen kleinen Baustein zu feilen. Das ist eine eigene Fähigkeit, die auch ein menschlicher Entwickler erst über Jahre lernt, fast als müsste er sein Denken dafür umbauen. Eine KI versucht es mit schierer Kapazität, mit einem immer größeren Kontextfenster, also mehr Text, den sie auf einmal fassen kann. Doch das stößt an eine Grenze: Irgendwann ist ein System zu groß für einen einzigen Kopf, ob aus Fleisch oder aus Silizium.

Was tut man bei Menschen in dieser Lage? Man verteilt die Arbeit auf viele Schultern. Genau das tun wir jetzt auch. Statt einer einzigen KI, die alles auf einmal stemmen soll, setzen wir mehrere an, jede für ihren Teil. Möglich wird das durch Agenten. Ein Agent ist nichts Geheimnisvolles, nur eine KI, die nicht bloß auf eine Frage antwortet, sondern selbstständig mehrere Schritte hintereinander geht, Werkzeuge bedient und bei Bedarf sogar weitere Agenten in Gang setzt, um ihre Aufgabe zu erledigen.

Das große Thema, an dem sich die halbe KI-Welt derzeit abarbeitet, heißt Orchestrierung: Wie bringt man viele solcher Agenten dazu, geordnet zusammenzuspielen? Mir genügt etwas Bodenständigeres. Schon unter Menschen ist die Zusammenarbeit so notorisch schwierig, dass alle paar Jahre neue Verfahren dafür ersonnen werden, von festen Rollen bis zum agilen Arbeiten mit seinen kurzen, täglichen Absprachen.⁶ Mir geht es um genau diese nachvollziehbare Kommunikation zwischen einzelnen Mitarbeitern, denn ich behandle die KI-Chats wie Mitarbeiter: Ich verteile Aufgaben, ich frage nach, ich lasse sie miteinander reden. Den moderierten Dialog dafür kennen wir schon aus dem siebten Kapitel; jetzt heben wir ihn auf eine größere Ebene. Dort ließen wir denselben Task aus verschiedenen Blickwinkeln prüfen. Hier sind es mehrere Mitarbeiter, von denen jeder ein eigenes Modul baut, und um die Frage, wie diese Module sauber zusammenpassen.⁷

Diese Schnittstellen, die Berührungspunkte zwischen den Modulen⁸, legen wir am Anfang bewusst nur grob fest. Man könnte sie bis ins letzte Detail vorschreiben, aber das hat sich nie bewährt: Erst wenn man in die einzelnen Module hineingeht, zeigt sich genau, was sie voneinander brauchen und was zwischen ihnen hin und her wandern muss. Also lassen wir die Beteiligten sich zusammensetzen und die Details untereinander aushandeln. Keine stundenlange Konferenz, sondern eine, die nur wenige Minuten läuft, aber strukturiert. Verschiedene Agenten, die miteinander reden und ihre Schnittstellen selbst verhandeln, und ich darüber, wie ein Projektleiter, der moderiert, das Geklärte festhält und entscheidet, wenn sie sich nicht einig werden.

Mit diesem Wissen und diesem Team aus KIs lassen sich größere Projekte angehen, und nicht nur neue: auch das Modernisieren alter, festgefahrener Systeme, ein Fall, der so eigen ist, dass er am Ende einen gesonderten Ausblick verdient. Vorher aber müssen wir die Behauptung einlösen, die über diesem Artikel steht: schneller als Vibe-Coding, und dabei sicherer und nachhaltiger. Dazu sollten wir erst klären, was Vibe-Coding ist.

Das Wort fällt ständig, und fast jeder versteht etwas anderes darunter, vor allem, wer sich nie damit befasst hat. Lösen wir es auf, sonst vergleichen wir am Ende Äpfel mit Birnen. Vibe-Coding heißt nicht einfach, mit Hilfe einer KI zu entwickeln, das tun wir hier schließlich auch. Vibe-Coding heißt, einer KI ohne eigenen Plan und ohne vorgegebene Struktur zuzurufen: Mach mal. Man beschreibt grob, was herauskommen soll, und überlässt ihr alles Weitere, das Wie, das Womit, das Wo. Unsere Methode ist, das haben die letzten Kapitel gezeigt, genau das Gegenteil: Nicht der Code soll möglichst schnell stehen, sondern das Drumherum soll so genau durchdacht sein, wie es nur geht.

Und doch wäre es unfair, Vibe-Coding nur als Schreckgespenst zu malen, denn es hat seinen Platz. Nehmen wir ein kleines Beispiel: ein Anmeldeformular für eine Party, die wir organisieren. Wer mitmacht, trägt sich ein, wir bekommen eine E-Mail. Die übliche Routine, Eingaben prüfen, die Adresse validieren, den Text sauber übernehmen, eine Mail verschicken. So etwas zaubert Vibe-Coding in wenigen Minuten hin, und darin ist es unschlagbar.

Bauen wir es aus: Die Anmeldungen sollen nicht nur per Mail kommen, sondern in einer Liste landen, die alle Gäste sehen, wer kommt, wer was mitbringt, am besten gleich in einer geteilten Online-Tabelle, die jeder im Browser öffnet. Auch das geht erstaunlich flott, weil die KI diese ausgetretenen Pfade in- und auswendig kennt, die fertigen Schnittstellen, die immer gleichen Handgriffe. Wir müssen ihr nur die Zugänge geben. Und genau hier zeigt sich der erste feine Riss: Wir wissen am Ende gar nicht, wo und wie sie unsere Zugangsdaten ablegt, weil wir es nie gesagt haben und sie es sich selbst irgendwie zurechtlegt. Für ein Party-Tool ist das einerlei. Ein kurzer Blick in den Code, fertig, und wir haben in einer Viertelstunde, wofür man früher einen Abend gebraucht hätte.

Es gibt sogar einen zweiten guten Grund für Vibe-Coding. Manchmal weiß man selbst noch nicht genau, was man will. Dann ist es Gold wert, sich schnell etwas hinstellen zu lassen, das man ansehen, bemäkeln und wieder verwerfen kann, bis klar wird, worauf es hinauslaufen soll.

Nun verlassen wir die Spielwiese. Nehmen wir ein richtiges Projekt, nichts Riesiges, aber von der Art, an der Geld und Ruf hängen: einen kleinen Online-Shop. Mit einem Kniff allerdings, der ihn von den tausend anderen unterscheidet. Der Preis eines Produkts soll nicht feststehen, sondern mit der Nachfrage steigen und fallen, wie bei einer Versteigerung.⁹ Dazu die üblichen Zahlungsabwickler¹⁰, ein Konto für jeden Kunden, das ganze Drumherum. Sagen wir der KI auch hier nur: Mach mal. Mit einigen Rückfragen wird sie tatsächlich etwas auf die Beine stellen, das mit ein wenig Glück auf den ersten Blick sogar läuft.

Wo ist der Haken? Vibe-Coding bedeutet, der KI ein paar Brocken hinzuwerfen, nichts zu spezifizieren und trotzdem ein fertiges Produkt zu erwarten, dessen Gestalt wir selbst nicht genau kennen. Dass dabei selten das Richtige herauskommt, ist nicht die Schuld der KI. Sie ist nicht von sich aus klüger als wir, und vor allem kann sie nicht hellsehen. Shops aber hat sie zu Tausenden gesehen, also baut sie kurzerhand einen Shop, so, wie man es eben macht.¹¹ Und gerade das eine, das unseren besonders auszeichnet, der mitwandernde Preis, ist das, worüber sie am flüchtigsten hinweggeht, weil wir sie nie gezwungen haben, darüber nachzudenken. Das ist kein neues Leiden, es ist das uralte Problem mit jedem Auftraggeber: Erst muss man gemeinsam herausfinden, was er wirklich will und was davon sinnvoll machbar ist. Überspringt man das, entsteht irgendein Produkt, nur nicht das gebrauchte. Beim Vibe-Coding überspringt man es immer.

Also tun wir zuerst das, was Vibe-Coding auslässt: Wir machen uns klar, was wir wollen. Und genau da beginnt unsere Methode.

1. Dieser Entwurf des Ganzen ist die Software-Architektur. ↩

2. Solche eingebundenen Fremd-Bausteine heißen Dependencies. ↩

3. Wiederkehrende schlechte Lösungsmuster heißen Anti-Patterns (oder Code Smells). ↩

4. Solche aufgeschobenen Folgekosten heutiger Entscheidungen nennt man Technical Debt, technische Schuld. ↩

5. Dieses „Gedächtnis“ heißt Context Window (Kontextfenster) — wie viel Text die KI auf einmal fassen kann. ↩

6. Die kurzen, täglichen Absprachen sind das Herzstück agiler Methoden wie Scrum (dort Daily Stand-up). ↩

7. Ein System in eigenständige, klar getrennte Bausteine zu zerlegen, nennt man Modularität (Trennung der Zuständigkeiten, Separation of Concerns). ↩

8. Solche Berührungspunkte zwischen Modulen heißen Schnittstellen, im Software-Jargon meist APIs. ↩

9. Ein mit der Nachfrage schwankender Preis heißt Dynamic Pricing. ↩

10. Solche Zahlungsabwickler heißen Payment Service Provider (PSP) oder Payment Gateway. ↩

11. Dass die KI zum verbreiteten Durchschnitt tendiert, ist eine Art Regression zur Mitte. ↩

Schneller als Vibe-Coding

Im vorigen Kapitel haben wir gesehen, wo Vibe-Coding scheitert: an einem echten Projekt wie unserem Shop, dessen Eigenheit, der mit der Nachfrage wandernde Preis, mehr verlangt als ein hingeworfenes „Mach mal“. Was wir wollen, wissen wir nun grob. Bevor wir aber etwas bauen lassen, kommt der für mich wichtigste Schritt: eine große Sammlung mit allem Wissen, das wir brauchen oder brauchen könnten. Sie hält das Halluzinieren von vornherein klein.

Zusammengetragen wird sie nicht von mir, sondern von der KI, über einen Skill, also eine festgehaltene Arbeitsweise auf Knopfdruck, die ich bei jedem Projekt nutze: die Anfangsrecherche. Sie geht die Werkzeuge, Schnittstellen und Dienstleister durch, die wir einsetzen wollen, sucht von sich aus nach Alternativen, die wir übersehen haben könnten, und legt uns vor, was taugt und was nicht. Ist etwas Besseres darunter, halten wir kurz Rücksprache und nehmen es auf, sei es auch nur als Möglichkeit für später.

Dann holt sie, wie im achten Kapitel, zu jedem Baustein die aktuelle Dokumentation und sichert das Entscheidende daraus, samt Quelle. Das tut sie auch dann, wenn sie überzeugt ist, das Werkzeug längst aus dem Effeff zu kennen. Hier muss man sie manchmal überlisten: Ich sage ihr nicht, das Wissen sei für sie, sondern für mich, weil ich mich da nicht so gut auskenne. Schon recherchiert sie willig, statt sich auf ihr Gedächtnis zu verlassen.

Das Ergebnis sortieren wir nach Themen und geben es in das RAG, jene durchsuchbare Datenbank für die KI aus dem achten Kapitel. Damit schließt sich der Kreis von dort: Ist die KI sich nicht sicher, behauptet sie nichts mehr, sie schlägt nach. Das hilft jetzt bei der Planung und später beim Programmieren, bei jedem Funktionsaufruf, jedem Parameter, nichts muss mehr aus dem Gedächtnis geraten werden. Auch das kostet uns Zeit, die Vibe-Coding sich spart; merken wir es uns, am Ende wird abgerechnet.

Jetzt erst planen wir. Wie genau, ist Geschmackssache; bei mir male ich mir das ganze System im Kopf aus, Modul für Modul, und erzähle es, statt es aufzuschreiben, einer KI, die die Punkte festhält, damit ich mein Gedankenbild nicht verliere. Das ist meine Marotte. Entscheidend ist allein, dass wir ein grobes Gerüst entwerfen und uns die einzelnen Bausteine überlegen.

Dabei nutze ich die KI nicht bloß als Stichwortgeber, dem man sein Vorhaben zeigt und der zurückgibt, was er davon hält. Ich will eine fundierte Betrachtung aus verschiedenen Blickwinkeln und greife dafür auf den moderierten Dialog aus dem siebten Kapitel zurück: mehrere Personas, also künstliche Rollen mit eigenem Charakter, die dasselbe Vorhaben jede aus ihrer Sicht beleuchten, dazu ein Moderator, der vermittelt. Was mir an Nachhaltigkeit und Wartbarkeit wichtig ist, steckt längst mit in diesem Skill.

Ein Unterschied zum vorigen Beispiel ist dabei entscheidend. Damals lief alles auf einen Task hinaus, der eine konkrete Änderung erzeugte. Hier entsteht kein Code, nicht einmal eine fertige Schnittstelle, sondern allein die grobe Struktur. Wir arbeiten uns von oben nach unten durch und planen bewusst in die Zukunft: Was könnte später dazukommen, welche Erweiterungen sind absehbar, selbst solche, die der Kunde noch mit keinem Wort erwähnt hat?

Bei alldem halte ich die Personas an, im Zweifel lieber nachzuschlagen als zu raten und lieber einmal zu viel nachzufragen, wenn etwas nicht zusammenpasst. Mehr ist es im Kern nicht: die Stärken der KI ausreizen und ihre Schwächen abfangen. Zwei Werkzeuge runden das ab.

Das erste betrifft die Fehler, und die kennen wir. Wer ein Team führt, weiß, welcher Mitarbeiter zu welchem Schnitzer neigt, und schaut hinterher genau dort hin. Bei der KI ist es nicht anders: Sie macht, wir erinnern uns, genau die Fehler eines Anfängers. Wir müssen sie nur benennen, dann lassen wir die KI ihren eigenen Code daraufhin prüfen.

Erfinden müssen wir das nicht einmal selbst. Es gibt fertige Skills, die genau diese typischen Fehler aufspüren, auf mehreren Ebenen: ob der Code gut lesbar ist, ob er robust läuft und nicht beim ersten Sonderfall stolpert, ob er sicher gegen Angriffe ist.¹ Je nach Modell schärfe ich sie nach und lasse den fertigen Code am Ende routinemäßig durch diese Prüfungen schicken. Das allein wäre einen eigenen Artikel wert.

Das zweite Werkzeug ist das reizvolle. Noch sind wir beim Planen, noch entsteht kein fertiger Code; trotzdem hilft es ungemein, ein Modul schon so klar vor Augen zu haben, dass man es fast hinschreiben könnte. Gerade Anfänger fangen lieber gleich an zu tippen, ich früher auch. Noch besser als eine solche Skizze in Worten aber ist ein Entwurf, der wirklich läuft, und dafür kehrt ausgerechnet das eben gescholtene Vibe-Coding zurück.

Nehmen wir das Zahlungssystem. Gebaut haben wir es noch nicht, dabei muss gerade dieses Modul am Ende jede Möglichkeit abdecken, jede Bestätigung, jede Absage, jede Rückfrage. Statt es jetzt schon auszuprogrammieren, lassen wir die KI es in Minuten simulieren²: ein kleines Modul, das sich nach außen benimmt wie das echte und alle Antworten liefert, die guten wie die schlechten, von der abgelehnten Kreditkarte bis zur Bestätigung, die zu spät eintrifft. Was alles schiefgehen kann, trägt die KI gleich aus der Anfangsrecherche zusammen, die diese Liste ohnehin hergibt. So erproben wir das Zusammenspiel der Module, lange bevor eines davon richtig existiert.

Und die Attrappe darf bleiben. Das echte Zahlungssystem lässt sich von außen nicht zwingen, auf Kommando eine abgelehnte Karte zu liefern³; die Simulation tut genau das, für jeden Test, den wir fahren. Nach und nach ersetzen wir die vorgegaukelten Teile durch echte, doch was wir zum Testen brauchen, behalten wir. So war die Mühe nicht einmal doppelt, sie hat uns sogar Tempo gebracht.

Damit haben wir unser Verfahren beisammen. Jetzt halten wir es gegen das andere: Wir lassen das Vibe-Coding noch einmal von der Leine, diesmal nicht am Party-Formular, sondern am ganzen Shop, und schauen, wer am Ende schneller ist.

Also los, das Vibe-Coding baut unseren Shop. Auf den ersten Blick sieht das ordentlich aus: Die KI plant, schlägt ein paar Wege vor, setzt etwas hin, das im Großen und Ganzen funktionieren könnte, und testet sogar selbst, ob es überhaupt läuft. Dabei merkt sie, dass manches eben doch nicht so will, wie sie dachte.

Was dann passiert, kennt jeder, der je einen Anfänger begleitet hat. Es wird herumprobiert. Hauptsache, es läuft. KIs neigen haargenau wie menschliche Einsteiger dazu, den Code erst zum Laufen zu bringen und ihn danach schön zu machen⁴, und wenn der dritte Versuch auch scheitert, dann eben Hauptsache irgendwie. So entsteht ein Programm, das vielleicht tut, was es soll, aber bei der ersten größeren Änderung in sich zusammenfällt.

Das ist das Verrennen, die gefährlichste Eigenschaft von allen. Eine KI biegt sich ein Problem so lange zurecht, bis es irgendwie funktioniert, und reißt dabei den sauberen Aufbau ein, den sie vorher hatte; ist das einmal geschehen, geschieht es wieder und wieder. Beim Vibe-Coding passiert es sofort, immer, praktisch ausnahmslos. Es bei meinen Leuten zu verhindern, war stets meine Aufgabe als Chefentwickler, und genau das tue ich jetzt bei der KI. Unser Verfahren nimmt mir das größtenteils ab: Wer am Anfang vernünftig plant, aus mehreren Blickwinkeln schaut und weit in die Zukunft denkt, dem fallen die meisten dieser Sackgassen gar nicht erst zu.

Ganz verschwindet es nicht, darum bauen wir eine Sicherung ein. Verrennt sich ein Agent an einem Problem, das er nicht im ersten Anlauf löst, wird er unterbrochen und gezwungen, innezuhalten, einen Schritt zurückzutreten und die Sache von der anderen Seite anzusehen, am besten mit einem zweiten zusammen. Das ist der Moment, an dem Mensch wie Maschine sonst die meiste Zeit verlieren: Statt kurz aufzublicken, wird stur weitergebogen, bis es passt und der elegante Code dahin ist. Erstaunlicherweise nimmt einem das bislang kaum ein Werkzeug ab, also achten wir selbst darauf, von der ersten Beauftragung an und während der ganzen Arbeit.

Und dann kommen die Änderungen, denn die kommen immer. Beim vibe-codierten Shop meist dort, wo die KI raten musste, was wir nie gesagt hatten: an der Oberfläche, am Verhalten in den hundert kleinen Fällen. Sie hatte vielleicht mehrere Ideen, präsentieren konnte sie nur eine; gefällt sie uns nicht, muss großzügig umgebaut werden, und im Umbauen sind KIs ausgesprochen schlecht.

Bei uns war dieselbe Frage längst besprochen, mehrere Vorschläge, wir haben den besten gewählt. Und für alles, was wir noch nicht sicher wussten, gilt, was ich beim Hausbau auch täte: Ich lege Leerrohre.⁵ Ich halte die Schnittstellen so allgemein wie möglich und baue Unsicheres so ein, dass es sich leicht austauschen lässt. Das kostet ein paar Sekunden Nachdenken, oft für einen Fall, der nie eintritt; tritt er aber ein, bin ich um ein Vielfaches schneller, als hätte ich mir die Sekunden gespart.

Beim Vibe-Coding wird es mit jeder Änderung schlimmer. Jedes neue Teil macht das Programm wackliger⁶, und ändern müssen wir ständig, weil von vornherein nichts festgelegt wurde, das ist sein ganzer Witz und zugleich sein Verhängnis. Uns trifft das kaum, weil wir gar nicht erst dorthin geraten. Und unser einziges vibe-codiertes Stück, das Simulationsmodul, bauen wir im Zweifel nicht um, sondern schnell neu; es ist winzig, muss nicht perfekt sein und landet nie im Endprodukt. Beim reinen Vibe-Coding dagegen ist das fertige Produkt genau dieser zusammengestückelte Code.

Am bittersten zeigt sich das bei der kleinsten Bitte. Ein Kunde möchte ein Element der Oberfläche an eine andere Stelle. Vielleicht ist das mit einem Griff getan, vielleicht hängt ein halbes System daran, man weiß es nicht, und fragen kann man auch nicht, denn die KI weiß es selbst nicht mehr. Sie verrennt sich erneut, baut um, verliert den Überblick, und mit ihr verlieren wir ihn.

Hier holt unser Weg auf und zieht vorbei. Das eigentliche Ungetüm sind all die Dinge, die nie festgelegt wurden und nun im Nachhinein besprochen und eingepasst werden müssen, Stück für Stück, was die KI nicht allein kann; da muss der Mensch ran. Diese Nacharbeit kostet ein Vielfaches der anfänglichen Planung. Genau hier ist das Vibe-Coding eingeholt und überholt.

Am Ende stehen zwei Produkte, die beide tun, was wir wollten. Nur ist das eine nachhaltig gebaut, kennt die Fälle, die schiefgehen können, und lässt sich künftig mühelos ändern, während wir das andere irgendwann selbst nicht mehr verstehen, und die KI auch nicht. Unseres ist obendrein sicherer und sauberer, und wir können die entscheidenden Stellen selbst prüfen: Die zentralen Datenstrukturen, das Fundament, auf dem alles ruht, schaue ich mir bis heute von Hand an. Beim vibe-codierten Shop gibt es dieses eine Fundament gar nicht, sondern ein Dutzend halb passender, sofern ich sie überhaupt finde. Spätestens hier ist das Versprechen eingelöst, mit dem dieser Artikel überschrieben ist: Wir sind schneller als Vibe-Coding, und sicherer und nachhaltiger noch dazu.

Halten wir es nebeneinander, damit man sieht, wer wann bezahlt:

Der Wettlauf ist entschieden. Bleibt ein Fall, in dem die Startaufstellung eine ganz andere ist: wenn das System, das wir ablösen sollen, längst existiert und es niemand mehr ganz durchschaut.

1. Solche automatischen Prüfungen am ruhenden Code nennt man statische Analyse, die auf Sicherheit gezielte Variante SAST. ↩

2. So ein vorgetäuschtes Ersatzmodul heißt Mock oder Stub. ↩

3. Das gezielte Erzwingen von Fehlerfällen zum Testen heißt Fault Injection. ↩

4. Das nachträgliche Sauber- und Umstrukturieren von laufendem Code heißt Refactoring. ↩

5. Solche bewusst austauschbar gehaltenen Stellen nennt man lose Kopplung. ↩

6. Dass Software mit jeder Änderung unordentlicher wird, heißt Software-Entropie. ↩

Ausblick: Wenn das alte System weg muss

Alles, was wir bisher getan haben, lief darauf hinaus, ein System von Grund auf zu planen, bevor die erste Zeile Code steht. Genau diese Vorausschau war der größte Hebel, der uns Zeit spart. Es gibt aber einen Fall, in dem nicht zu wenig geplant wurde, sondern in dem alle Planung von einst hinfällig ist.

Stellen wir uns ein System vor, das seit zwanzig Jahren läuft.¹ Vielfach umgebaut, von vielen Händen, mit einer Dokumentation, die nichts mehr sagt und an manchen Stellen falsch ist. Das eigentliche Wissen steckt nicht in Texten, sondern im Code selbst.² So etwas ist irgendwann nicht mehr wartbar, und irgendwann nicht einmal mehr lauffähig, weil die Technik darunter wegbricht. Wer rechtzeitig dran ist, lässt es in eine moderne Sprache, ein modernes System überführen³, bevor es ganz stehenbleibt.

Das klingt nach bloßem Übersetzen, ist aber das Gegenteil, und schwieriger, als ein System neu zu bauen. Eine alte Sprache Wort für Wort in eine neue zu übertragen wäre das kleinste Problem.⁴ Die Härte liegt darin, dass das eine System ganz anders denkt als das andere: ein Bankensystem in COBOL, ein Geflecht aus PHP, wie es hinter erstaunlich vielen Webseiten steckt, lässt sich nicht einfach in etwas Modernes gießen. Und selbst eine halbwegs zeitgemäße Sprache muss nach genug Jahren und genug Händen von Grund auf neu strukturiert werden. Es geht nie um die Sprache allein.

Im Kern zerfällt das in zwei Teile. Der erste, den alten Code überhaupt zu verstehen⁵, ist eine Kunst für sich, und die KIs werden darin rasch besser. Ist er aber verstanden und liegt ein präziser Plan vor, dann geht es weiter wie bei unserem Shop: dieselbe Aufgabenstellung, dieselben Werkzeuge. Genau hier zahlt sich alles aus, was wir über die KI gelernt haben.

Eine KI mit großem Gedächtnis kann fremden Code hervorragend analysieren und mit Anleitung bis ins Detail durchstrukturieren. Nur kennt sie die alte Umgebung mit ihren längst vergessenen Schnittstellen und Treibern oft so wenig wie wir; dieses Wissen müssen wir zusammensuchen oder aus dem Code rekonstruieren und in unsere Datenbank legen. Auch hier rät und vergisst sie, sobald der Altbestand zu groß für ihr Gedächtnis wird, und auch hier gilt: nicht alles dem Sprachmodell überlassen, sondern die Spezialwerkzeuge nutzen, die ein Mensch ebenso einsetzen würde.

Mehr als irgendwo sonst zählt hier die Erfahrung des Menschen. Eine KI hat gelernt, wie fertiger Code aussieht, nicht, wie er entsteht, und eine solche Transformation hat sie so gut wie nie selbst gemacht, höchstens in Artikeln darüber gelesen. Wir führen sie also wie einen begabten Junior, der programmieren kann, aber vor einer Aufgabe steht, die er noch nie gelöst hat.

Eine Stolperfalle als Kostprobe, eine von vielen: Findet man im alten Code einen Fehler, ist die erste Eingebung, ihn zu beheben. Oft ist das falsch, denn an anderer Stelle rechnet längst etwas mit genau diesem Fehler und bricht, sobald er verschwindet.⁶ Solche Fälle muss man erst kartieren, dann korrigieren.⁷ Wie man das alles ordnet, füllt einen eigenen Artikel, und den schreibe ich als Nächstes.

1. Ein solches gewachsenes Altsystem heißt Legacy oder Brownfield. ↩

2. Wissen, das nirgends steht, sondern nur in Köpfen und im Code, nennt man Tribal Knowledge. ↩

3. Dieses Überführen in eine neue Umgebung heißt Migration oder Re-Platforming. ↩

4. Bloßes 1:1-Übertragen heißt Lift-and-Shift; das nötige Umdenken der Struktur Re-Architecting. ↩

5. Aus fertigem Code rückwärts seine Funktionsweise zu erschließen, heißt Reverse Engineering. ↩

6. Dass sich irgendein Nutzer auf jedes beobachtbare Verhalten verlässt — sogar auf einen Fehler — ist als Hyrum’s Law bekannt. ↩

7. Nichts entfernen, ehe man weiß, wozu es da war — diese Regel heißt Chesterton’s Fence. ↩

Fazit

Das war der Blick nach vorn. Für diesen Artikel aber schließt sich hier der Kreis. Am Anfang standen zwei Lager, die aus demselben Halbwissen entgegengesetzte Schlüsse zogen: die einen verboten die KI aus Angst, die anderen vertrauten ihr blind aus Hoffnung. Beide, so hieß es, richten Schaden an. Inzwischen sollte klar sein, warum, und dass es einen dritten Weg gibt.

Er beginnt mit zwei Sätzen, die sich zu widersprechen scheinen, bis man sie zusammen denkt. Der erste: Eine KI muss halluzinieren dürfen, denn ihr unscharfes Erinnern ist nicht ihr Defekt, sondern die Quelle ihrer Kreativität. Der zweite: Eine KI ist keine Datenbank, aber sie kann eine nutzen. Wer beides beherzigt, nimmt dem Halluzinieren das Gefährliche, 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 zu verschiedenen Blickwinkeln zu zwingen, statt darauf zu hoffen, und ihr das Nachschlagen so leicht zu machen, dass sie es auch tut. Mehr braucht es im Kern nicht.

So wird aus der gefürchteten Maschine ein Werkzeug, das man dort einsetzt, wo es stark ist, und dort absichert, wo es schwächelt. Nicht langsamer als das blinde Drauflos, sondern schneller, und das Bessere daran: sicherer und nachhaltiger.

Kurzfassung für Eilige

Über künstliche Intelligenz gibt es zwei verbreitete Lager, und beide ziehen aus demselben Halbwissen den falschen Schluss. Die einen verbieten sie aus Angst, die anderen vertrauen ihr blind aus Hoffnung. Beide richten Schaden an. Dieser Artikel zeigt einen dritten Weg, und der beginnt mit zwei Sätzen, die sich zu widersprechen scheinen.

Der erste: Eine KI muss halluzinieren dürfen. Das klingt absurd, meint aber nur, dass sie sich unscharf erinnert, statt wie eine Datenbank exakt abzurufen. Genau dieses Verschwimmen ist die Quelle ihrer Kreativität, ihre Fähigkeit, Erfahrung auf etwas Neues zu übertragen. Es ist kein Freibrief, Fakten zu erfinden, sondern ihr Funktionsprinzip.

Der zweite: Eine KI ist keine Datenbank, aber sie kann eine nutzen. Wer von ihr exakte Fakten verlangt, hat das falsche Werkzeug gewählt. Richtig ist die Arbeitsteilung: Die KI ordnet ein und versteht, die Datenbank liefert das Exakte, und im Zweifel schlägt die KI nach, statt zu raten.

Daraus folgt ein Vorgehen, das sich vom Ungefährlichen zum Mutigen steigert. In einem kritischen System darf die KI zunächst nur lesen und analysieren, nichts verändern; die Entscheidung bleibt beim Menschen. Dann darf sie mitverändern, sofern wir den Auftrag präzise fassen und das Ergebnis gegen die Wirklichkeit prüfen lassen. Das Herzstück ist ein Task, eine Datei, die Ziel, Weg und alle nötigen Hinweise als vollständigen Arbeitsauftrag festhält.

Zwei Hebel machen das Ganze sicher. Der erste: die KI zu verschiedenen Blickwinkeln zwingen, statt darauf zu hoffen, etwa indem mehrere künstliche Rollen dasselbe Problem jede aus ihrer Sicht prüfen. Wie gut das wirkt, zeigt ein Beispiel, das gern durch die Medien gereicht wird, um vorzuführen, wie wenig eine KI verstehe: Soll man zu einer zweihundert Meter entfernten Waschanlage zu Fuß gehen oder mit dem Auto fahren? Reflexhaft rät das Modell zum kurzen Fußweg, es ist ja nur ein Katzensprung. Damit folgt es dem naheliegenden Lösungsweg und übersieht das Ziel: Gewaschen werden soll das Auto, und dafür muss es mit. Genau diesen Fehler fängt die erste Persona ab, weil sie nicht fragt, wie man zur Waschanlage kommt, sondern was am Ende erreicht sein soll, und sofort sieht, dass nur die Fahrt mit dem Auto die Aufgabe löst. Der zweite Hebel: der KI das Nachschlagen so leicht machen, dass sie es auch tut, mit einer durchsuchbaren Wissenssammlung, statt sie raten zu lassen.

Beim Programmieren kommt eine dritte zugespitzte These hinzu: Dass ein Programm tut, was es soll, ist zweitrangig. Das ist die Pflicht, nicht die Kunst. Wichtiger ist Code, der vorausschauend gebaut ist und sich in einem halben Jahr noch ändern lässt. Genau hier versagt das Vibe-Coding, der KI ohne Plan ein „mach mal“ zuzurufen: im Kleinen unschlagbar, im echten Projekt untauglich, weil die KI sich verrennt und den sauberen Aufbau einreißt.

Setzt man die KI dort ein, wo sie stark ist, und sichert sie dort ab, wo sie schwächelt, dreht sich das Tempo um. Dieser Weg ist am Anfang langsamer, bei jeder Änderung aber schneller als das blinde Drauflos, und dabei sicherer und nachhaltiger.