Wir befinden uns weiterhin mitten in der KI-Transformation. Viele Firmen haben erste Experimente mit KI in der Softwareentwicklung durchgeführt, und die Ergebnisse fallen durchwachsen aus: Auf enthusiastische Berichte über enorme Produktivitätsgewinne folgen ebenso glaubwürdige Stimmen, die von Enttäuschung oder offenen Problemen sprechen. Diese Spannbreite wirkt zunächst widersprüchlich – sie wird verständlicher, wenn man sich ansieht, worauf die Werkzeuge tatsächlich aufsetzen.
KI als Verstärker
Eine häufig zitierte Beobachtung besagt, dass KI-Einsatz das verstärkt, was bereits vorhanden ist – im Guten wie im Schlechten. Entscheidend ist dabei weniger der Code selbst als die Arbeitsweise des Teams, das mit ihm arbeitet. KI-Werkzeuge sind ein Verstärker, und was sie verstärken, ist in erster Linie die gelebte Praxis: die Art, wie Anforderungen geklärt, Änderungen geprüft und Ergebnisse überprüft werden.
Wo diese Praktiken fest verankert sind, wirken KI-Werkzeuge als Hebel. Ein Team, das Reviews ernst nimmt, Anforderungen vor der Umsetzung klärt und generierten Code konsequent gegen Tests und fachliche Erwartungen prüft, fängt die Fehler der KI ab und übersetzt ihre Geschwindigkeit in echten Fortschritt. Wo dieselbe Disziplin fehlt, wirkt der Hebel ebenso – nur in die andere Richtung: Ungeprüfte Annahmen, unscharfe Anforderungen und übersehene Sonderfälle setzen sich fort, und zwar in dem Tempo, das die KI vorgibt, statt in dem, das ein einzelner Entwickler halten könnte.
Damit klärt sich auch das durchwachsene Gesamtbild. Die widersprüchlichen Erfahrungsberichte spiegeln weniger unterschiedliche Werkzeuge als unterschiedliche Voraussetzungen. Denn wer KI in größerem Stil einsetzen will, muss ihren Spielraum für Fehler aktiv eng halten: Je enger das Korsett aus belastbaren Tests, geklärten Anforderungen und nachvollziehbaren Zusammenhängen, desto kleiner der Raum, in dem die KI unbemerkt etwas Falsches tun kann. Genau dieses Korsett liefern die etablierten Best Practices – sie sind hier kein Beiwerk, sondern die eigentliche Voraussetzung. Solche Strukturen lassen sich allerdings mit der Zeit, unter Lieferdruck und in gewachsenen Systemen schwerer durchhalten, weshalb sie nicht überall gleich selbstverständlich vorausgesetzt werden können. Was es konkret braucht, damit dieses Korsett trägt, lohnt einen genaueren Blick – und beginnt bei der Frage, wie KI-Werkzeuge überhaupt arbeiten.
Wie arbeiten KI-Tools?
Aktuelle KI-Tools sind in der Lage, sich eine fremde Codebasis selbstständig zu erschließen. Aufgaben wie „Erweitere den Logindialog um eine Dropdownbox zur Nutzerauswahl“ können sie weitgehend eigenständig lösen. Allerdings haben diese Werkzeuge konzeptbedingt einen codezentrierten Blick auf das Projekt. Damit fehlt der KI die Historie, die einem Entwickler zur Verfügung steht, der schon seit Jahren mit dem Code arbeitet. Sie kann sich nicht erschließen, warum der Code so ist, wie er ist, und wird ihn deshalb so anpassen, dass er zu ihren Anweisungen passt – auch wenn dabei andere Funktionen unter Umständen beschädigt werden.
Wenn keine Tests existieren, die das bestehende Verhalten absichern, wird die KI ähnlich wahrscheinlich Fehler machen wie ein neuer Entwickler, der die Zusammenhänge noch nicht kennt. Eine Umgebung, die diesen Umstand nicht berücksichtigt, kann mit KI-Unterstützung keine guten Ergebnisse erzielen. Die Informationen, die einem menschlichen Entwickler für seine Arbeit zur Verfügung stehen, sind um ein Vielfaches reicher als das, womit eine naiv eingesetzte KI arbeiten kann:
- Code
- Requirements
- Issuetracker – aktuelles Ticket
- Issuetracker – verwandte Tickets
- SCM-Historie
- Wissen über die Produktstrategie (also: Welche Features müssen wir wohl in Zukunft implementieren?)
- Eigene Erfahrungen: Wie wird das Produkt üblicherweise eingesetzt? Welche anderen Funktionen hat es, die mit einer neuen Anforderung kollidieren könnten?
Eine KI hat im schlimmsten Fall nur den Code, um zu verstehen, was zu tun ist. Einfache Deployments können zusätzlich die SCM-Historie verfügbar machen. Alle weiteren Informationsquellen sind jedoch nur zugänglich, wenn zusätzliche Anstrengungen unternommen werden, um diese zu erschließen. Grundvoraussetzung ist dabei, dass die Informationen überhaupt in einer Form vorliegen, mit der die KI effizient arbeiten kann – und gerade daran scheitern gewachsene Umgebungen am wahrscheinlichsten.
Moderne Agenten-Setups können diese Lücke teilweise schließen: Über standardisierte Schnittstellen lassen sich Issuetracker, Dokumentenablagen oder die SCM-Historie anbinden, sodass die KI sie selbstständig heranzieht. Das ändert aber nichts am Grundproblem, es verschiebt es nur. Erstens muss jemand diese Anbindungen bewusst herstellen und entscheiden, welche Quelle bei welcher Aufgabe relevant ist – wahllos angereicherter Kontext verschlechtert die Ergebnisse eher, als sie zu verbessern. Zweitens, und das wiegt schwerer, erschließt eine Anbindung nur, was tatsächlich vorhanden ist: Ein Zugriff auf den Issuetracker liefert die Tickets so, wie sie geschrieben wurden. Sind sie unverknüpft, unpräzise und ohne Bezug zum Code, fördert auch die beste Schnittstelle nur unbrauchbares Material zutage. Das Werkzeug überwindet die Zugänglichkeit, nicht die fehlende Qualität und Struktur der Information.
Genau hier liegt der Kern: Ein naives Deployment – jedem eine Lizenz, das Tool auf das Repository loslassen – greift zu kurz. Erfolgreicher KI-Einsatz beginnt mit der bewussten Entscheidung, über welche Wege welche Informationen in welcher Form zugänglich gemacht werden – und welche aus guten Gründen nicht.
Insbesondere Requirements stechen hervor: Neben informellen Strukturen („es liegen Textdateien oder Word-Dateien irgendwo in p:/share/Konzepte“) werden Anforderungen oft von Autoren verfasst, die zwar Domänenwissen haben, aber kein Softwarewissen. Ein erfahrener Entwickler kann die daraus entstehenden Lücken füllen, da er den Kontext der Anforderung und das Produkt kennt. Beides sind Informationen, die einem KI-System nicht ohne Weiteres zur Verfügung stehen.
Was braucht gute KI-gestützte Entwicklung?
Wie herausgearbeitet, hängt der erfolgreiche KI-Einsatz im Wesentlichen von zwei Faktoren ab: von Güte und Detailgrad der Informationen, die der KI zur Verfügung gestellt werden, sowie von einer Umgebung, in der die KI ihre eigene Arbeit kontrollieren und ungewünschtes Systemverhalten erkennen kann. Eine Baseline besteht daher zumindest aus folgenden Komponenten:
- Statische Codeanalyse, die lokal ausführbar ist
- Unit-Tests mit hoher Coverage
- Integrationstests, die zumindest die wichtigsten Use Cases im Happy Path abdecken
Diese drei Punkte bilden eine Grundlage, die Regressionen verhindert und Fehler für die KI erkennbar macht. Einen entsprechenden Systemprompt vorausgesetzt, kann die KI die Tests während der Featureentwicklung ausführen und Probleme direkt beheben, wenn Tests „rot“ werden. Sie kann beim Nutzer auch Rückfragen stellen, wenn der entsprechende Test ein Verhalten prüft, das mit der aktuellen Aufgabe kollidiert.
Geht man gedanklich an den Anfang dieses Artikels zurück, wird man feststellen, dass bereits diese Grundlagen bei gewachsenen, alten Codebasen oft nicht gegeben sind. Jeglicher KI-Einsatz ist aus Risikosicht damit gleichzusetzen mit „ein neuer Mitarbeiter setzt Feature X um“. Ein menschliches Review der Änderungen ist in dieser Situation Pflicht, woraus direkt ein erheblicher Flaschenhals entsteht: Reviews dauern vergleichsweise lange. Gleichzeitig ist die menschliche Aufmerksamkeit begrenzt, sodass bei zunehmender Menge des zu reviewenden Codes Probleme mit großer Wahrscheinlichkeit übersehen werden. Am Ende bleibt der KI-Einsatz im beschriebenen Szenario ein Risiko, das sich nur mitigieren lässt, indem die genannten Grundlagen geschaffen werden.
Diese Maßnahmen adressieren jedoch nur einen Teil des Problems. Tests und statische Analyse fangen eine bestimmte Klasse von Fehlern ab: Regressionen – Code, der etwas beschädigt, das vorher funktioniert hat. Diese Fehler sind technischer Natur und damit maschinell erkennbar.
Daneben existiert eine zweite, gefährlichere Klasse: Implementierungen, die technisch einwandfrei sind – sie laufen durch, brechen keinen bestehenden Test – und trotzdem das Falsche tun. Die KI hat die Aufgabe sauber umgesetzt, nur eben nicht die Aufgabe, die gemeint war. Das Tückische dabei: Anders als bei einer mehrdeutigen Anforderung, bei der ein gutes Modell die offene Frage erkennt und nachhakt, gibt es hier aus Sicht der KI nichts zu fragen. Die Anforderung wirkt vollständig, der Code ist konsistent, alle Tests sind grün.
Ein Beispiel: In der Codebasis werden Entfernungen nach einer ungeschriebenen Konvention durchgängig in Kilometern geführt. Die KI soll eine Berechnung ergänzen und stößt dabei auf ein schlicht benanntes Feld distance, dessen Wert sie als Meilen interpretiert – eine plausible, in sich konsistente und problemlos testbare Annahme. Nur ist sie falsch, und am Wert selbst gibt es keinen sicheren Hinweis darauf: Die Zahl allein verrät die Einheit nicht. Die Konvention ist nirgends ausgeschrieben, weil sie als selbstverständlich gilt. Genau das ist das Wesen impliziten Wissens – es ist überall vorausgesetzt und nirgends dokumentiert. Keine noch so hohe Modellqualität rekonstruiert Information, die im Input schlicht nicht vorhanden ist. Solche Fehler sind kein technisches, sondern ein Kontextproblem, und ihre Vermeidung beginnt nicht im Code, sondern bei den Anforderungen.
Requirements bilden neben dem vorhandenen Code den wichtigsten Eingabeparameter für die Planungsphase eines KI-Systems. Sie liefern den Kontext, der benötigt wird, um neue Funktionalität sinnvoll in das Gesamtsystem zu integrieren. Wie weiter oben angedeutet, können erfahrene Entwickler Lücken in unpräzisen Anforderungen aus Produktkenntnis und Erfahrung schließen – ein KI-System kann das nicht. Was beim Menschen implizites Kontextwissen ist, muss für die KI explizit vorliegen.
Eine für den KI-Einsatz geeignete Umgebung stellt Anforderungen daher in einer Form bereit, die maschinell erschließbar ist und Zusammenhänge sichtbar macht: Anforderungen sind untereinander verknüpft, mit konkreten Tickets und idealerweise auch mit den betroffenen Codebereichen verbunden. Architekturentscheidungen und ihre Begründungen sollten dokumentiert sein, damit die KI das „Warum“ hinter dem Code nachvollziehen kann. Informelle Strukturen – Konzeptdokumente in geteilten Verzeichnissen, mündlich tradiertes Wissen – scheiden für diesen Zweck aus.
Liegen diese Strukturen nicht vor, lässt sich die Lücke nur durch manuelle Kontextaufbereitung schließen: Ein Entwickler muss vor der Bearbeitung jedes Tickets die relevanten Informationen zusammentragen und der KI in geeigneter Form bereitstellen. Damit hängt der KI-Einsatz an einem menschlichen Engpass, der mit der Menge der Tickets skaliert und das erreichbare Produktivitätsniveau begrenzt. Verschärft wird er dadurch, dass die Aufbereitung Produktwissen voraussetzt, das in undokumentierten Umgebungen nur erfahrene Entwickler liefern können. Der KI-Einsatz hängt damit ausgerechnet an der Ressource, die ohnehin am knappsten ist.
Bemerkenswert ist, dass dieser Engpass am Eingang denselben Charakter hat wie der Review-Engpass am Ausgang. An beiden Enden steht ein Mensch, dessen Kapazität nicht mit der KI skaliert: vorne, um den nötigen Kontext bereitzustellen, hinten, um die Ergebnisse zu prüfen. Die KI selbst arbeitet beliebig schnell – aber genau deshalb verlagert sich der limitierende Faktor an die Ränder des Prozesses, und beide Ränder beanspruchen dieselbe knappe Ressource: erfahrene Entwickler. Wer den Durchsatz erhöhen will, muss daher nicht das Modell beschleunigen, sondern diese beiden menschlichen Engpässe entlasten – und beide lassen sich nur durch dieselbe Investition entlasten, die schon die Fehlervermeidung verlangt: explizit gemachter Kontext und belastbare Absicherung.
Zusammenfassung
KI-gestützte Entwicklung ist mehr, als jedem Entwickler eine Copilot-Lizenz zu geben. Ein erfolgreiches Deployment erfordert eine Umgebung, die den systemimmanenten Einschränkungen von KI-Werkzeugen Rechnung trägt – sowohl bei der technischen Absicherung der Ergebnisse als auch bei der Bereitstellung des fachlichen Kontexts, mit dem die KI arbeiten soll.
Damit bestätigt sich die eingangs zitierte Beobachtung: KI ist ein Verstärker dessen, was bereits vorhanden ist. Wo Engineering-Grundlagen tragfähig sind, hebelt sie die Produktivität spürbar; wo sie fehlen, macht sie die Schwächen schneller und sichtbarer wirksam. Die gute Nachricht ist, dass die nötigen Investitionen – Testabdeckung, statische Analyse, strukturierte und verknüpfte Anforderungen, dokumentierte Architekturentscheidungen – ohnehin lohnenswert sind. Sie zahlen sich auch ohne KI aus, indem sie das Onboarding beschleunigen, Regressionen reduzieren und Wissen aus den Köpfen Einzelner in das System verlagern. KI ist in dieser Hinsicht weniger ein neuer Treiber als ein zusätzlicher, sehr deutlicher Grund, diese Investitionen jetzt anzugehen.
Eine letzte Konsequenz läuft allerdings der landläufigen Erwartung zuwider. Man begegnet KI in der Entwicklung oft mit der Hoffnung, Personal einsparen zu können. Tatsächlich zeigt die Analyse das Gegenteil: KI übernimmt vor allem die Codeproduktion selbst. Was sie nicht übernimmt, ist das, was davor und danach kommt: den fachlichen Kontext bereitzustellen, in dem die KI arbeiten soll, und zu beurteilen, ob das Ergebnis nicht nur lauffähig, sondern auch richtig ist. Beides setzt Entwickler voraus – und beides wird mit dem Einsatz von KI nicht seltener gebraucht, sondern häufiger.
KI hebt damit den Bedarf an Entwicklern nicht auf, sie steigert ihn. Der knappste Faktor wird durch sie nicht ersetzt, sondern wertvoller. Struktur und gute Anforderungen sind notwendig – aber sie ersetzen die Entwickler nicht, sie sind das, was deren Wissen für die KI nutzbar macht.
Vielleicht liegt darin sogar die eigentliche Chance. Sauber durchdachte Anforderungen waren nie unwichtig – sie waren nur das Erste, was unter Implementierungsdruck geopfert wurde. Wenn die KI diesen Druck an der Umsetzung verringert, entsteht Raum für genau die Sorgfalt, die vorher dem Tempo zum Opfer fiel. So gesehen erkauft uns KI nicht in erster Linie schnelleren Code, sondern die Freiheit, das Vordenken endlich so ernst zu nehmen, wie es immer hätte sein sollen.