Ihre Bestandssoftware ist nicht KI-bereit, nur weil Sie ein Coding-Tool kaufen

Die Diskussion über KI-Coding wird realistischer.

Die frühe Erzählung war einfach: Man gibt Claude Code, Cursor, Devin, Replit Agent, Lovable oder einem anderen Coding-Agenten eine Aufgabe, und das Tool erzeugt Software schneller, als ein menschliches Team es allein könnte.

Ganz falsch ist das nicht. KI-unterstützte Softwareentwicklung kann echten Nutzen schaffen. Sie kann bei Prototypen, Tests, Refactorings, Dokumentation, Migrationen, internen Tools und repetitiver Implementierungsarbeit helfen.

Aber die spannendere Diskussion auf X dreht sich gerade um ein schwierigeres Problem:

Warum sehen KI-Coding-Agenten in Greenfield-Projekten oft beeindruckend aus, werden aber in echten, älteren Codebasen deutlich weniger zuverlässig?

Diese Frage ist für ernsthafte Unternehmen relevant.

Wertvolle Software ist meistens kein leeres Repository. Sie ist ein Produkt mit Kunden, Sonderfällen, Geschäftsregeln, Integrationen, Berechtigungen, alten Migrationen, betrieblichen Gewohnheiten und jahrelangen Entscheidungen, die nie vollständig dokumentiert wurden.

Wenn ein Team ein KI-Coding-Tool kauft und es in dieses Umfeld setzt, landet das Tool nicht in einem sauberen Engineering-Labor. Es landet in einem lebenden System.

Und lebende Systeme brauchen Kontext.

Das Problem ist nicht nur das Modell

Ein aktueller Thread rund um Claude Code formulierte den Punkt ziemlich direkt: Das Problem ist oft nicht Claude, sondern die Architektur um die Arbeit herum.

Das ist der richtige Blickwinkel.

Wenn ein KI-Agent in einem bestehenden Produkt scheitert, ist die naheliegende Reaktion: Das Tool ist schuld. Manchmal stimmt das. Modelle machen Fehler. Sie übersehen Details, orientieren sich zu stark an den nächstliegenden Dateien, erfinden Muster, entfernen wichtige Sonderfälle und ändern selbstbewusst Dinge, die sie nicht verstanden haben.

Aber in vielen echten Codebasen haben Menschen aus denselben Gründen Schwierigkeiten.

Die Architektur ist unklar. Die Fachsprache ist uneinheitlich. Die Setup-Anleitung ist veraltet. Tests decken den Happy Path ab, aber nicht das geschäftliche Risiko. Wichtiges Verhalten steckt in einem Service, den niemand anfassen möchte. Eine Senior-Entwicklerin weiss, warum eine merkwürdige Bedingung existiert, aber diese Erklärung steht weder im Code noch in Tests, Dokumentation oder Tickets.

Ein KI-Agent kann Wissen nicht zuverlässig respektieren, wenn die Organisation dieses Wissen nie explizit gemacht hat.

Deshalb ist “KI-bereit” kein reines Tool-Label. Es ist eine Eigenschaft des Softwaresystems.

Eine Codebase wird KI-bereit, wenn ein kompetenter Agent unter menschlicher Aufsicht die Aufgabenbegrenzung verstehen, den relevanten Kontext prüfen, die richtigen Checks ausführen und eine Änderung vorschlagen kann, die Reviewer ohne Archäologie bewerten können.

Das ist keine Magie.

Das ist Wartbarkeit.

Greenfield-Demos verstecken die echte Schwierigkeit

KI-Coding-Tools glänzen in Greenfield-Demos, weil Greenfield-Projekte verzeihend sind.

Es gibt kein bestehendes Kundendatenmodell, das erhalten bleiben muss. Keine alte Integration mit einem Lieferantenportal. Keine versteckte Berechtigungsregel für einen wichtigen Account-Typ. Keine jahrelange uneinheitliche Benennung. Keinen Deployment-Prozess, der von einem manuellen Schritt abhängt. Kein Sales-Versprechen, das erklärt, warum das scheinbar falsche Verhalten absichtlich existiert.

In einer sauberen Demo kann das Tool die Architektur beim Bauen gleich miterfinden.

In einem echten Produkt ist die Architektur bereits da, auch wenn sie niemand besonders mag.

Dieser Unterschied ändert alles.

In einem neuen Repository kann ein Agent ein Dashboard, eine API-Route, ein Datenbankschema und Tests in einem relativ kohärenten Durchlauf erzeugen. In einem zehn Jahre alten System erfordert dieselbe Anfrage möglicherweise Verständnis für alte Daten, einen Billing-Sonderfall, ein Rollenmodell, einen Migrationspfad und den Grund, warum das vorherige Team eine einfachere Lösung vermieden hat.

Der Agent kann trotzdem Code erzeugen.

Die Frage ist, ob dieser Code in das Produkt gehört.

Für Gründer, CTOs und Product Owner ist das die praktische Trennlinie. KI ersetzt nicht die Notwendigkeit, das System zu verstehen. Sie erhöht den Wert davon, das System verständlich zu machen.

Technische Schulden blockieren KI-Adoption

Technische Schulden waren lange vor allem ein internes Engineering-Thema.

Sie verlangsamten Lieferung. Sie machten Änderungen schwieriger. Sie erhöhten Onboarding-Aufwand und Incident-Risiko. Weil Kunden sie nicht direkt sehen konnten, liessen sie sich leicht verschieben.

KI verändert diese Rechnung.

Wenn eine Codebase unordentlich ist, kann ein KI-Agent schneller mehr unordentlichen Code erzeugen. Er kann lokale Inkonsistenzen wiederholen, veraltete Patterns kopieren, unnötige Abhängigkeiten hinzufügen oder genau den Test verpassen, der das eigentliche Risiko sichtbar gemacht hätte.

Das Ergebnis ist nicht immer dramatisch. Häufig ist es subtil:

Pull Requests werden schwerer zu reviewen;
kleine Änderungen berühren zu viele Dateien;
generierter Code wirkt plausibel, ignoriert aber Fachregeln;
Reviewer verbringen mehr Zeit mit Kontext-Erklärungen als mit Lösungsbewertung;
Teams vertrauen dem Agenten nicht mehr und arbeiten wieder manuell;
die Organisation kommt zum Schluss, dass KI “bei uns nicht funktioniert”.

Manchmal passt das Tool wirklich nicht.

Aber oft ist die Codebase schlicht nicht bereit, dem Tool brauchbaren Kontext zu geben.

Diese Diagnose ist konstruktiver, weil sie einen Weg nach vorn eröffnet. Die Antwort ist nicht, auf perfekte KI zu warten. Die Antwort ist, die Software leichter bearbeitbar zu machen.

Das hilft Menschen sofort und Agenten später.

Was macht eine Codebase KI-bereit?

Eine KI-bereite Codebase ist keine perfekt moderne Codebase. Diese Messlatte ist unrealistisch und meist nicht sinnvoll.

Es ist eine Codebase, in der Änderung lesbar ist.

Das bedeutet: Ein Entwickler, ein Reviewer oder ein KI-Agent kann grundlegende Fragen beantworten, ohne zu raten:

Wo lebt diese Geschäftsregel?
Welches Modul besitzt diese Verantwortung?
Wie startet man das System lokal sicher?
Welche Tests schützen das wichtige Verhalten?
Welche Daten dürfen in Entwicklung genutzt werden?
Welche Abhängigkeiten sind erlaubt?
Was darf nie ohne Review geändert werden?
Wo werden Architekturentscheidungen festgehalten?
Wie bewegt sich eine Änderung von Branch zu Produktion?

Das sind normale Engineering-Fragen. KI-Adoption macht sie nur dringender.

Bei McDougall Digital denken wir genau so über KI-unterstützte Entwicklung für ernsthafte Produkte. Das Ziel ist nicht, ein Team von einem bestimmten Tool abhängig zu machen. Das Ziel ist eine Lieferumgebung, in der gute Tools helfen können, ohne das Produkt in eine Sammlung unreviewbarer Vermutungen zu verwandeln.

Mit Karten beginnen, nicht mit Rewrites

Viele Teams hören “Legacy-Codebase” und denken sofort an einen grossen Rewrite.

Das ist meistens der falsche Startpunkt.

Ein Rewrite kann in bestimmten Fällen nötig sein. Aber KI-Readiness sollte meistens mit Mapping beginnen, nicht mit Ersetzen.

Der erste sinnvolle Schritt ist, das bestehende System sichtbar zu machen:

die wichtigsten Module und ihre Verantwortlichkeiten;
die relevanten Datenflüsse;
die Integrationen mit geschäftlichem Risiko;
die Bereiche, die häufig geändert werden;
die Bereiche, die niemand gut versteht;
die manuellen Deployment- oder Support-Schritte;
die Tests, die wichtiges Verhalten schützen;
die fehlenden Tests, die Änderungen riskant machen.

Diese Karte muss kein 90-seitiges Architekturdokument sein. Im Gegenteil.

Für KI-unterstützte Lieferung ist kurz und aktuell besser als lang und zeremoniell. Einige präzise Dokumente nahe am Code sind nützlicher als ein alter Architektur-Foliensatz, den niemand liest.

Die besten Dokumente sind operativ:

“Wie Bestellungen durch das System laufen”
“Wo Berechtigungen geprüft werden”
“Wie Billing-Änderungen sicher umgesetzt werden”
“Bekannte gefährliche Bereiche”
“Test-Erwartungen für kundennahe Änderungen”
“Architekturgrenzen für Agenten und Menschen”

Solche Dokumente helfen neuen Entwicklern. Sie helfen Reviewern. Sie helfen Product Ownern, Risiko zu verstehen. Und sie geben KI-Agenten besseren Kontext.

Charakterisierungstests vor ambitionierter Agentenarbeit

Eine der sichersten Methoden, ein altes System auf KI-unterstützte Entwicklung vorzubereiten, sind Charakterisierungstests.

Ein Charakterisierungstest behauptet nicht, dass das aktuelle Verhalten schön ist. Er hält fest, was das System aktuell tut, besonders bei wichtigen Geschäftsregeln und Sonderfällen.

Das ist wichtig, weil viele Legacy-Systeme Verhalten enthalten, das seltsam aussieht, aber einen Grund hat.

Vielleicht behandelt eine Rabattberechnung einen alten Vertrag. Vielleicht akzeptiert ein Importprozess kaputte Daten, weil ein Partnersystem sie seit Jahren so sendet. Vielleicht existiert eine Berechtigungsregel wegen eines früheren Incidents. Vielleicht hängt ein manueller Support-Prozess von einem unbequemen Statuswechsel ab.

Wenn nichts davon getestet ist, kann ein KI-Agent es beim “Aufräumen” entfernen.

Der Agent kann den Code sogar lesbarer machen.

Und trotzdem das Geschäft brechen.

Gute Tests geben dem Team eine Grenze. Sie erlauben Agenten, Änderungen vorzuschlagen, und geben Reviewern ein besseres Signal darüber, was sich verändert hat. Sie machen Refactoring auch weniger politisch, weil die Diskussion von “Ich glaube, das ist wichtig” zu “Dieses Verhalten ist geschützt” wandert.

Die Aufgabe des Agenten begrenzen

KI-Coding-Agenten arbeiten besser, wenn die Aufgabe begrenzt ist.

“Verbessere unser Onboarding” ist für ein bestehendes Produkt zu breit.

“Füge ein verpflichtendes Feld für die Unternehmensgrösse ins Onboarding-Formular ein, speichere es am Account-Profil, zeige es im Admin-Bereich an und ändere die Billing-Logik nicht” ist deutlich besser.

Für echte Codebasen sollten Aufgabenbegrenzungen enthalten:

das gewünschte Produktergebnis;
die voraussichtlich betroffenen Dateien oder Module;
die ausdrücklich ausgeschlossenen Bereiche;
die Tests, die ergänzt oder angepasst werden sollen;
die Daten und Zugangsdaten, die der Agent verwenden darf;
die Review-Regeln für generierte Änderungen;
Rollback- oder Release-Überlegungen.

Das klingt langsamer, als den Agenten einfach starten zu lassen.

In der Praxis ist es schneller.

Unbegrenzte Agentenarbeit erzeugt Review-Schulden. Begrenzte Arbeit erzeugt nutzbare Ergebnisse.

Dasselbe gilt für Tool-Berechtigungen. Ein KI-Agent braucht nicht Zugriff auf alles, nur weil er Code schreiben kann. Bestehende Produkte sollten isolierte Branches, Entwicklungsdaten, Least-Privilege-Zugänge und klare Freigaberegeln für Abhängigkeiten, Migrationen, Infrastruktur und sicherheitsrelevante Änderungen nutzen.

KI-Readiness ist nicht nur Dokumentation.

Sie ist operative Kontrolle.

Produkturteil bleibt entscheidend

Es gibt eine verlockende Fantasie im KI-Coding: Wenn das Modell gut genug wird, wird Produkturteil weniger wichtig.

Wahrscheinlicher ist das Gegenteil.

Wenn Implementierung günstiger wird, wird der Preis der falschen Änderung sichtbarer. Ein Team kann fünf Versionen eines Features generieren. Aber jemand muss trotzdem entscheiden, welche Version zum Produkt, zum Kunden, zur Architektur und zum Geschäft passt.

In einer Legacy-Codebase ist dieses Urteil besonders wichtig, weil das System Geschichte trägt.

Nicht jedes alte Pattern ist schlecht. Nicht jede Inkonsistenz sollte sofort bereinigt werden. Nicht jedes Modul verdient Investition. Nicht jedes KI-generierte Cleanup ist das Risiko wert.

Die nützliche Frage lautet nicht: “Kann der Agent das ändern?”

Die nützliche Frage lautet:

Sollte diese Änderung existieren, und was muss wahr sein, damit sie sicher ist?

Genau hier zählen erfahrene Produkt- und Architekturarbeit. KI kann Implementierung, Exploration und Review-Vorbereitung beschleunigen. Sie übernimmt nicht die Verantwortung für das Produkt.

Eine praktische erste Roadmap

Für ein Team mit bestehendem Produkt kann eine sinnvolle KI-Readiness-Roadmap so aussehen:

Einen begrenzten Produktbereich wählen, in dem häufig geändert wird und das Risiko überschaubar ist.
Architektur und Geschäftsregeln dieses Bereichs kartieren.
Das lokale Setup so bereinigen, dass das System zuverlässig gestartet und getestet werden kann.
Charakterisierungstests für die wichtigen Verhaltensweisen ergänzen.
Aufgabenbegrenzungen und Review-Regeln für KI-unterstützte Arbeit dokumentieren.
Agenten zuerst für kleine, beaufsichtigte Aufgaben nutzen.
Nachverfolgen, wo Review-Zeit verloren geht: fehlender Kontext, schlechte Tests, unklare Ownership, Abhängigkeitsrisiken oder Produktunklarheit.
Das System auf Basis dieser Erkenntnisse verbessern, bevor riskantere Bereiche folgen.

Das ist nicht glamourös.

Aber es funktioniert.

Es macht KI-Adoption aus einem Tool-Kauf zu einem Wartbarkeitsprogramm mit direktem Geschäftswert.

Selbst wenn das bevorzugte Coding-Tool im nächsten Quartal wechselt, zahlt sich die Arbeit aus. Bessere Tests, klarere Architektur, saubereres Setup und explizites Domänenwissen verbessern Lieferung unabhängig vom Modell.

Die eigentliche Chance

Die aktuelle X-Diskussion ist nützlich, weil sie über die oberflächliche Frage hinausgeht, ob KI Code schreiben kann.

Natürlich kann sie Code schreiben.

Die ernste Frage ist, ob Ihre Organisation KI genug Kontext, Grenzen und Review-Struktur geben kann, damit dieser Code zu verlässlicher Produktarbeit wird.

Für viele Teams, besonders im deutschen Markt, liegt die grösste Chance nicht darin, Entwickler durch Agenten zu ersetzen. Sie liegt darin, KI-Adoption als Druck zu nutzen, wichtige Software endlich verständlicher, änderbarer und betreibbarer zu machen.

Das ist eine deutlich bessere Investition, als jeder neuen Tool-Ankündigung hinterherzulaufen.

McDougall Digital hilft Teams genau dabei: realistisch zu bewerten, wo KI-unterstützte Entwicklung sicher Hebelwirkung erzeugt, die Architektur- und Lieferpfade zu verbessern, die sie blockieren, und bestehende Produkte in Systeme zu verwandeln, an denen Menschen und Agenten mit Vertrauen arbeiten können.

Die Unternehmen, die am meisten von KI-Coding profitieren, werden nicht zwingend die mit den aggressivsten Prompts sein.

Es werden die mit den klarsten Systemen sein.