Ein Werkzeug, kein Kollege: Wie Softwareentwickler mit KI arbeiten können

Das Nürnberg-Problem

Vor kurzem hatten wir in einem internen Projekt eine Situation, die sich am besten mit einer Autofahrt beschreiben lässt.

Das Ziel war Nürnberg. Klar definiert, bekannt, besprochen.

Irgendwann auf der Strecke, ungefähr auf Höhe von Stuttgart, tauchten erste Hindernisse auf. Die KI, die uns beim Entwickeln unterstützte, stieß auf eine bestimmte Eigenschaft im Code, die nicht zu dem passte, was sie als Ziel genannt bekommen hatte.

Sie stützte sich auf genau diese eine Eigenschaft und leitete daraus ab, dass der bisherige Weg nicht stimmen könne. Alles andere, also das, was eigentlich zum Ziel gehörte, wurde plötzlich als fehlerhaft oder irrelevant eingeordnet.

Stattdessen schlug die KI ein anderes Ziel vor: Heidelberg. Das passe besser. Zumindest zu dieser einen Beobachtung.

Die Route wurde angepasst, die Hindernisse verschwanden und kurz darauf waren wir angekommen. In Heidelberg.

Alles sah sauber aus. Die Begründung war nachvollziehbar. Das Ergebnis war in sich konsistent.

Wir hatten eine funktionierende Lösung. Leider für das falsche Problem.

Heidelberg ist schön. Kann man auch mal hinfahren.

Aber unser Ziel war Nürnberg.

Der Weg dorthin war steinig und schwierig. Vermutlich genau deshalb hatte die KI ihn als falsch eingestuft. Nicht laut, nicht offensichtlich, sondern leise und überzeugend. Mit einer sauberen Begründung, basierend auf einer einzelnen Beobachtung, die sie für wichtiger hielt als den restlichen Kontext.

Das ist das Tückische: Es war kein grober Fehler. Es war ein subtiler.

Hier braucht es Entwickler, die das erkennen. Menschen, die den Kontext kennen, das Ziel im Kopf behalten und im Zweifel sagen: Nein, wir fahren weiter nach Nürnberg, auch wenn der Weg schwieriger ist.

Was hat sich verändert?

Dass KI die Arbeit von Softwareentwicklern verändert, ist längst keine gewagte These mehr. Das passiert bereits.

Die interessantere Frage ist: Was genau verändert sich?

Code entsteht heute schneller als je zuvor. Was früher einen halben Tag gedauert hat, ist teilweise in Minuten generiert.

Das fühlt sich produktiv an. Und oft ist es das auch.

Wenn man genauer hinschaut, verschiebt sich aber vor allem, wo die Arbeit stattfindet.

Weniger tippen, mehr bewerten. Weniger schreiben, mehr lesen. Weniger selbst formulieren, dafür mehr einordnen, hinterfragen und korrigieren.

Nur prompten reicht nicht.

Das merkt man spätestens beim Review. Und reviewen muss man die Ergebnisse. Immer.

Damit das überhaupt funktioniert, müssen die Änderungen überschaubar bleiben. Kleine, nachvollziehbare Schritte sind deutlich wertvoller als eine generierte Wand aus Code, die niemand mehr sinnvoll durchdringen kann.

Das Problem kennen wir eigentlich schon.

Merge Requests, die so groß waren, dass sie entweder wochenlang liegen blieben oder irgendwann einfach durchgewunken wurden, waren schon immer schlecht.

Mit KI entsteht diese Wand nur deutlich schneller.

Warum ist KI ein fragiles Werkzeug?

KI ist beeindruckend flexibel. Man kann ihr fast jede Aufgabe geben und bekommt ein Ergebnis, das auf den ersten Blick plausibel aussieht.

Manchmal ist es sogar richtig gut.

Aber „plausibel auf den ersten Blick“ ist in der Softwareentwicklung eine gefährliche Eigenschaft.

Das Problem liegt im Kontext.

KI baut auf dem auf, was sie sieht. Jede Antwort erzeugt neuen Kontext, der in die nächste Antwort einfließt.

Das funktioniert gut, solange die Richtung stimmt.

Kommt jedoch irgendwo ein kleiner Fehler hinein, etwa eine falsche Annahme, ein missverstandenes Requirement oder ein subtiler Bug, kann sich dieser Fehler mit jeder weiteren Iteration verstärken.

Die KI merkt das nicht. Sie arbeitet konsequent weiter, nur eben in die falsche Richtung.

Der Kontext baut auf dem Fehler auf. Der neue Kontext bestätigt ihn. Am Ende entsteht etwas, das in sich konsistent aussieht und trotzdem grundlegend danebenliegt.

Genau deshalb starten Entwickler häufig eine neue Session, wenn sie merken, dass der Kontext kippt.

Nicht weil die KI kaputt ist, sondern weil sich ein vergifteter Kontext irgendwann kaum noch sinnvoll reparieren lässt.

Das ist kein Fehler des Werkzeugs. Es ist eine Eigenschaft, die man kennen und im Workflow berücksichtigen muss.

Ein Werkzeug, das überwacht werden muss, ist deshalb nicht weniger nützlich.

Aber man sollte es nicht mit einem Kollegen verwechseln, der den Gesamtkontext selbstständig mitdenkt.

Was bedeutet das für Legacy-Code?

Der Kontext formt den Output

Bei Legacy-Code wird das besonders heikel.

Wer KI auf eine gewachsene Codebasis loslässt, gibt ihr als Kontext genau das, was über Jahre entstanden ist. Mit allen Stärken, aber eben auch mit allen Altlasten.

Alte Patterns. Alte Workarounds. Entscheidungen, die damals sinnvoll waren, die heute aber vielleicht niemand mehr genauso treffen würde.

Die KI unterscheidet das nicht.

Sie sieht den bestehenden Code und erzeugt neuen Code im gleichen Stil.

Im schlimmsten Fall entsteht frisch generierter Code, der aussieht wie aus dem Jahr 2008. Nur erkennt ihn niemand als alt, weil er gerade erst geschrieben wurde.

Alter Code hat Erfahrung. Er hat Use Cases überlebt, von denen spätere Entwickler vielleicht gar nichts wissen.

KI übernimmt aber nicht nur diese Erfahrung. Sie übernimmt auch die Gewohnheiten, und zwar unkritisch.

Alter Code hat Erfahrung. KI kennt die Geschichte nicht.

Code, der seit Jahren im Einsatz ist, hat einiges überlebt.

Vielleicht gibt es Verhalten, das aus heutiger Sicht seltsam wirkt, aber aus einem konkreten Grund entstanden ist. Vielleicht gibt es Sonderfälle, die niemand mehr dokumentiert hat. Vielleicht hängen andere Systeme an genau diesem Verhalten.

Das war schon immer ein Grund, vorsichtig mit Änderungen umzugehen.

Mit KI wird dieser Punkt noch wichtiger.

Sie sieht den Code, aber nicht automatisch die Geschichte dahinter.

Sie „verbessert“ eine Stelle, die möglicherweise aus gutem Grund so aussieht, wie sie aussieht. Und sie tut das mit einer Selbstverständlichkeit, die leicht darüber hinwegtäuscht, dass gerade etwas Wichtiges kaputtgehen könnte.

Der Workflow muss den Kontext kontrollieren

Deshalb kann man KI nicht unstrukturiert auf Legacy-Code loslassen.

Was es braucht, ist ein klarer Workflow.

Zunächst Überblick schaffen. Dann analysieren, Probleme identifizieren und klassifizieren, priorisieren und Kritikalität bewerten. Danach eine Lösung erarbeiten, Tests für bestehendes und zukünftiges Verhalten schreiben, umsetzen, validieren, reviewen, abnehmen und mergen.

Das gilt für jeden einzelnen Fix.

Vielleicht lässt sich für ähnliche Problemklassen ein gemeinsamer Rahmen schaffen. Trotzdem bleibt der Aufwand erheblich.

KI kann theoretisch in jedem dieser Schritte unterstützen.

Aber die eigentliche Arbeit war schon immer das Drumherum, nicht nur der einzelne Fix.

Und daran ändert sich durch KI zunächst wenig.

Wie baut man KI sinnvoll in den Prozess ein?

Das ist die eigentliche Frage.

Und die ehrliche Antwort lautet: Wir haben dafür noch keinen vollständig automatisierten, verlässlichen Prozess.

Aktuell nutzen wir KI experimentell in einzelnen Schritten unseres Workflows, etwa bei Analyse, Klassifizierung, Testentwurf und Umsetzung.

In all diesen Bereichen kann KI helfen.

Dafür müssen aber drei Voraussetzungen stimmen:

1. Das Ziel ist klar.
2. Die Aufgabe ist konkret formuliert.
3. Der Kontext ist ausreichend eingegrenzt.

Das klingt banal.

In der Praxis sind diese drei Bedingungen erstaunlich selten gleichzeitig erfüllt.

Der nächste Schritt wäre deshalb, einzelne KI-unterstützte Schritte zu einem zusammenhängenden Workflow zu verbinden.

Ein Workflow, bei dem am Ende weiterhin ein Review steht, aber nicht bei jedem Zwischenschritt manuell eingegriffen werden muss.

Das wäre der Übergang von KI als Denk- und Analysehilfe in einzelnen Aufgaben zu KI als Bestandteil eines Entwicklungsprozesses.

Und genau darin liegt vermutlich die eigentliche Ingenieursleistung.

Nicht im Prompten. Nicht im Generieren.

Sondern darin, einen Workflow zu bauen, der für ein konkretes Problem zuverlässig genug funktioniert.

Und anschließend bereit zu sein, diesen Workflow für das nächste Problem wieder infrage zu stellen.

Ob das gelingt, hängt wahrscheinlich weniger an den Modellen als an uns.

An unserer Fähigkeit, Kontext zu kontrollieren, Leitplanken zu setzen und die fachliche Kompetenz mitzubringen, um Ergebnisse überhaupt beurteilen zu können.

Ausblick: Der Code kommt zurück

Eine Rechnung beschäftigt mich dabei besonders.

Wenn wir mit KI deutlich mehr Code erzeugen als früher und nur ein Teil davon langfristig bestehen bleibt, steigt trotzdem die Menge an Code, die irgendwann gewartet werden muss.

Schon bisher war Wartung selten der Teil von Softwareentwicklung, für den unbegrenzt Zeit vorhanden war.

Was passiert, wenn wir die Menge an erzeugtem Code massiv erhöhen?

Vermutlich werden wir KI auch für Wartung brauchen.

Sehr wahrscheinlich sogar.

Dafür müssen wir aber zuerst verstehen, wie wir KI so in unsere Workflows integrieren, dass ihre Ergebnisse zuverlässig genug sind.

Bis dahin sollten wir sehr bewusst entscheiden, welchen Code wir heute schnell erzeugen.

Denn er wird irgendwann wieder zu uns zurückkommen.