KI bei bestehenden Projekten: Warum Kontext alles ist

Warum neue Projekte einfacher sind als bestehende

Wenn jemand mit KI ein komplett neues Projekt startet, beginnt alles bei null. Es gibt keinen bestehenden Code, der berücksichtigt werden muss. Keine Altlasten, keine Sonderfälle, keine historisch gewachsenen Abhängigkeiten. Die KI kann frei gestalten, und das Ergebnis muss nur mit sich selbst kompatibel sein.

Das ist der Grund, warum Vibe Coding bei neuen, einfachen Projekten oft überraschend gut funktioniert. Ein Prototyp, ein kleines Werkzeug, eine einzelne Funktion — solange der Rahmen überschaubar bleibt, liefert KI brauchbare Ergebnisse.

Bei bestehender Software ist die Ausgangslage eine völlig andere. Ihre Anwendung hat eine Geschichte. Sie wurde über Monate oder Jahre entwickelt. Verschiedene Entwickler haben daran gearbeitet, Entscheidungen getroffen, Kompromisse gemacht. Manche dieser Entscheidungen waren bewusste Architekturentscheidungen. Andere waren pragmatische Lösungen für Probleme, die es heute vielleicht nicht mehr gibt — deren Auswirkungen aber im Code weiter leben.

Stellen Sie sich vor, Sie beauftragen einen Handwerker, in einem Altbau eine Wand zu versetzen. Er muss wissen, welche Wände tragend sind, wo Leitungen verlaufen, welche Anschlüsse betroffen sind. Jemand, der nur den Grundriss sieht, aber die Bausubstanz nicht kennt, kann mit bestem Werkzeug großen Schaden anrichten. Genau das passiert, wenn KI ohne ausreichenden Kontext an bestehender Software arbeitet.

Das Kontextproblem: KI sieht nie das ganze Bild

Das Kernproblem bei KI und bestehenden Projekten lässt sich auf einen Satz reduzieren: Die KI kennt Ihr Projekt nicht. Sie hat keinen Zugang zu dem Wissen, das in den Köpfen der Menschen steckt, die die Software gebaut haben.

Wenn Sie einer KI einen Codeausschnitt zeigen und sagen „Hier ist ein Fehler, bitte beheben", sieht die KI genau diesen Ausschnitt. Sie sieht nicht, warum der Code so geschrieben wurde. Sie sieht nicht, welche anderen Teile der Software von diesem Code abhängen. Sie sieht nicht, dass eine scheinbar umständliche Lösung absichtlich so gebaut wurde, weil die elegante Alternative in einem bestimmten Szenario versagt hat.

Ein erfahrener Entwickler, der Ihr Projekt kennt, würde fragen: „Warum ist das so gelöst?" Die KI fragt nicht. Sie liefert eine Antwort auf Basis dessen, was in Millionen anderen Projekten als übliche Lösung gilt. Aber Ihr Projekt ist nicht „üblich". Jede gewachsene Software hat Eigenheiten, die aus gutem Grund existieren.

Selbst wenn Sie der KI große Teile Ihres Codes zeigen, fehlt ihr das Verständnis für die Zusammenhänge. Sie erkennt Muster und imitiert Lösungen aus ihren Trainingsdaten. Aber sie versteht nicht, was der Code tut — sie erkennt nur, wie er aussieht. Das ist ein fundamentaler Unterschied.

Wie KI sich in gewachsenen Codebasen verheddert

Gewachsene Software hat Schichten. Wie bei einem Gebäude, das über Jahrzehnte erweitert wurde, gibt es Bereiche, die eng miteinander verzahnt sind — oft auf Wegen, die nicht sofort sichtbar sind. Eine Änderung in einem Bereich kann Auswirkungen in einem ganz anderen haben.

Die KI sieht diese unsichtbaren Verbindungen nicht. Sie behandelt jede Aufgabe, als wäre sie isoliert. Wenn Sie sie bitten, eine Funktion zu ändern, ändert sie diese Funktion — ohne zu prüfen, ob andere Teile der Software darauf angewiesen sind, dass diese Funktion genau so funktioniert wie bisher.

Ein konkretes Beispiel: In einem Kundenprojekt, das wir übernommen haben, hatte jemand eine KI gebeten, die Berechnung von Rabatten zu optimieren. Die KI lieferte eine saubere, effiziente Lösung. Aber diese Lösung berücksichtigte nicht, dass die alte Berechnung absichtlich in einer bestimmten Reihenfolge ablief — weil ein nachgelagerter Prozess genau diese Reihenfolge erwartete. Das Ergebnis: Die Rabatte selbst stimmten, aber die Rechnungserstellung produzierte fehlerhafte Belege. Das fiel erst auf, als ein Kunde reklamierte.

Solche Zusammenhänge sind in jeder gewachsenen Software vorhanden. Sie sind oft nicht dokumentiert. Sie existieren im impliziten Wissen der Entwickler, die den Code geschrieben haben. Und genau dieses Wissen hat eine KI nicht.

Die KI kann auch dazu neigen, Funktionen zu verwenden, die in Ihrem Projekt gar nicht existieren. Sie hat in ihren Trainingsdaten ähnliche Projekte gesehen und schlägt Lösungen vor, die dort funktioniert hätten — aber in Ihrer konkreten Umgebung ins Leere laufen. Für jemanden ohne Programmiererfahrung ist das schwer zu erkennen, denn der Code sieht auf den ersten Blick professionell und vollständig aus.

Seiteneffekte: Wenn die KI-Lösung neue Bugs erzeugt

Der gefährlichste Aspekt von KI-generiertem Code in bestehenden Projekten sind Seiteneffekte. Also Probleme, die nicht dort auftreten, wo die Änderung gemacht wurde, sondern an einer ganz anderen Stelle.

In einem Fall, den wir aufgearbeitet haben, sollte eine KI einen Fehler in der Benutzerverwaltung eines Kundenportals beheben. Der ursprüngliche Fehler war simpel: Unter bestimmten Umständen wurde der Name eines Benutzers nicht korrekt angezeigt. Die KI hat diesen Fehler behoben. Gleichzeitig hat ihre Lösung aber drei neue Probleme erzeugt:

1. Benutzer, die sich über eine ältere Schnittstelle anmeldeten, konnten ihre Einstellungen nicht mehr speichern — weil die KI die Art verändert hatte, wie Benutzerdaten intern weitergegeben werden.
2. Ein automatisierter Bericht, der nachts lief, produzierte unvollständige Daten — weil er auf ein bestimmtes Datenformat angewiesen war, das die KI-Lösung verändert hatte.
3. Die Anwendung wurde bei mehr als hundert gleichzeitigen Zugriffen merklich langsamer — weil die neue Lösung bei jeder Anfrage eine zusätzliche Datenbankabfrage erzeugte, die vorher nicht nötig war.

Keines dieser Probleme war im normalen Test sichtbar. Ein einzelner Benutzer, der sich anmeldet und seinen Namen prüft — alles in Ordnung. Erst unter realen Bedingungen, mit vielen Benutzern, verschiedenen Zugriffswegen und automatisierten Prozessen, traten die Probleme auf.

Das ist der Kern des Risikos: Typische KI-Fehler zeigen sich nicht im einfachen Test. Sie zeigen sich im Alltag, unter Last, in Randfällen. Und dann ist die Ursache schwer zu finden, weil niemand die Verbindung zwischen der kleinen Änderung an der Benutzerverwaltung und dem fehlerhaften Nachtbericht herstellt.

Wann KI-Unterstützung bei Bestandscode funktioniert

Trotz aller Risiken: KI bei bestehenden Projekten kategorisch auszuschließen wäre genauso falsch wie blindes Vertrauen. Der Unterschied liegt in der Art, wie sie eingesetzt wird.

Wir nutzen KI jeden Tag in unserer Arbeit — auch bei Bestandsprojekten. Aber nicht als autonomen Entwickler, sondern als Werkzeug. So wie ein Chirurg ein hochpräzises Instrument nutzt, aber die Entscheidung, wo geschnitten wird, selbst trifft.

Konkret hilft KI bei Bestandscode in folgenden Situationen:

• Code verstehen: Wenn ein erfahrener Entwickler eine unbekannte Codebasis übernimmt, kann KI helfen, einzelne Abschnitte schneller zu verstehen. Aber der Entwickler prüft die Erklärung gegen das, was er im Code tatsächlich sieht.
• Routineaufgaben beschleunigen: Wiederkehrende Anpassungen, einfache Ergänzungen, Dokumentation — hier spart KI Zeit, ohne großes Risiko. Vorausgesetzt, jemand kontrolliert das Ergebnis.
• Ideen und Entwürfe generieren: „Wie könnte man dieses Problem lösen?" — KI liefert Ansätze. Ein Entwickler bewertet, welcher davon zum bestehenden Projekt passt. Oder keiner.
• Tests schreiben: KI kann Testfälle vorschlagen. Ein Entwickler ergänzt die Fälle, die KI nicht kennt — die Randfälle, die speziellen Szenarien, die nur aus der Kenntnis des Projekts entstehen.

In all diesen Fällen ist KI ein Beschleuniger, kein Ersatz. Wer mehr über den sinnvollen Einsatz erfahren möchte, findet dazu unsere Übersicht zum Thema KI richtig einsetzen.

Was nicht funktioniert: Einer KI sagen „Hier ist das Projekt, mach das mal" und das Ergebnis ungeprüft übernehmen. Nicht bei neuen Projekten — aber bei bestehenden besonders nicht.

Der menschliche Faktor: Code lesen können entscheidet

Die entscheidende Fähigkeit im Umgang mit KI-generiertem Code ist nicht, Code schreiben zu können. Es ist, Code lesen zu können. Genauer: Code lesen und bewerten zu können im Kontext eines bestimmten Projekts.

Ein erfahrener Entwickler erkennt, wenn eine KI-Lösung technisch korrekt, aber im Kontext des Projekts problematisch ist. Er sieht, dass die vorgeschlagene Änderung eine Abhängigkeit übersieht. Er bemerkt, dass die Lösung unter Last nicht skalieren wird. Er weiß, dass die scheinbar veraltete Funktion, die die KI durch eine modernere ersetzen will, aus gutem Grund noch da ist.

Dieses Wissen entsteht nicht über Nacht. Es entsteht aus Jahren der Arbeit mit unterschiedlichen Projekten, aus Fehlern und deren Behebung, aus dem Verständnis, wie Software in der Praxis funktioniert — nicht nur im Labor.

Für Sie als Geschäftsführer bedeutet das: Der Wert eines erfahrenen Entwicklers liegt heute nicht mehr nur darin, Code zu schreiben. Er liegt darin, KI-generierten Code einzuordnen, zu prüfen und in den richtigen Kontext zu setzen. Gerade bei Legacy-Projekten und gewachsener Software ist dieses Urteilsvermögen unverzichtbar.

Das gilt besonders, wenn es darum geht, bestehenden Code zu verstehen und weiterzuentwickeln. KI kann dabei unterstützen. Aber die Entscheidung, was geändert werden darf und was nicht, braucht menschliche Expertise.

Genau diese Kombination bieten wir bei kommklick. Wir nutzen KI als das, was sie ist: ein leistungsfähiges Werkzeug. Aber die Verantwortung für die Qualität übernehmen Menschen, die wissen, was sie tun.