Bugs, Refactoring, Tests: Wo Chatbots beim Coden glänzen und wo sie scheitern

Die Suche nach meinem Platz in der KI-Ära

Als Softwareentwickler habe ich mich intensiv mit den neuen KI-Möglichkeiten auseinandergesetzt. Dabei drängte sich mir eine zentrale Frage auf: Wie kann mich KI im Alltag wirklich unterstützen?

Oder provokanter formuliert: Was muss ich lernen, um die KI zu steuern, statt von ihr ersetzt zu werden?

Genau darum geht es in dieser dreiteiligen Serie: Ich nehme dich mit auf meine Reise – von den ersten Chatbot-Versuchen hin zu autonomen Agenten. Im ersten Teil dieser Serie zeige ich, warum Chatbots oft exzellente Refactoring-Partner sind, als Code-Generator beim Schreiben neuer Business-Logik aber schnell an ihre Grenzen stoßen.

Wie funktioniert ein Chatbot eigentlich?

Um herauszufinden, wie uns ein Chatbot wie ChatGPT beim Coden unterstützen kann, müssen wir zunächst die grundsätzliche Funktionsweise verstehen.

Ein Large Language Model (LLM) ist im Grunde eine gigantische Wahrscheinlichkeitsmaschine. Zwar basiert es auf riesigen Textmengen aus dem Training, es besitzt aber kein echtes Verständnis von Logik oder Wahrheit.

Das Prinzip: Token für Token

Die Funktionsweise ist simpel: Das Modell sagt basierend auf dem bisherigen Text das statistisch wahrscheinlichste nächste Token (Wort oder Wortteil) voraus. So generiert es Stück für Stück eine kohärente Antwort.

Das Diagramm beschreibt den typischen Flow, der oft missverstanden wird:

1. Der User gibt einen Prompt ein (z.B. "Wie wird morgen das Wetter?")
2. Das Orchestrierungssystem (z.B. ChatGPT, Claude) verarbeitet die Eingabe
3. Das System reichert den Prompt nun massiv an:
   • Kontext:
     • Die bisherige Konversationshistorie mit Fragen & Antworten (z.B. "Ich wohne in Leipzig")
     • Zusätzliche Daten wie Web-Such-Ergebnisse oder hochgeladene Dateien
   • User-Prompt: Die eigentliche Nutzereingabe ("Wie wird morgen das Wetter?")
   • Systemeingaben:
     • Basis-Instruktionen (z.B. "Heutiges Datum ist 2026-03-09")
     • Spezifische Instruktionen (z.B. "Der Nutzer kommuniziert auf Deutsch. Antworte auf Deutsch")
4. LLM (z.B. GPT-5.2) erhält dieses riesige Textpaket und generiert daraufhin die Antwort

Wichtig zu verstehen: Das LLM selbst ist zustandslos. Es weiß nicht, was wir vor fünf Minuten geschrieben haben. Das Orchestrierungssystem muss ihm jedes Mal die komplette Historie erneut mitsenden. Es gibt technisch keine Trennung – für das Modell ist alles ein einziger langer Text.

Wie greift das LLM auf aktuelle Informationen zu?

Das Modell kennt die Wettervorhersage von morgen nicht, weil diese nicht in den Trainingsdaten steckt. Trotzdem kann ChatGPT dir das Wetter von morgen sagen.

Der Trick ist die Tool-Definition: Im System-Prompt teilt das Orchestrierungssystem dem LLM mit, welche Werkzeuge (z.B. eine Websuche) bereitstehen. Wenn das LLM merkt, dass es die Antwort nicht weiß, generiert es keinen Text für den Nutzer, sondern einen Funktionsaufruf (Function Call).

Das Orchestrierungssystem führt diesen Befehl aus (sucht also im Web nach den Wettervorhersagen für Leipzig) und übergibt das Suchergebnis in einem neuen Request an das LLM. Erst jetzt – mit den Fakten im Kontext – formuliert das Modell die finale Antwort.

Was passiert, wenn der Prompt zu groß wird?

Bei langen Chat-Historien stoßen wir an das Kontext-Limit (Context Window). Das Orchestrierungssystem muss hier Platz schaffen.

Eine gängige Methode ist das Context Compacting: Das System fasst im Hintergrund ältere Nachrichten zusammen oder entfernt weniger relevante Details. Für das LLM sieht es so aus, als hätten wir eine kurze Zusammenfassung unseres bisherigen Gesprächs geliefert, statt des kompletten Transkripts.

Chatbot-gestütztes Coden: Meine Erfahrungen

Im Kern konzentriert sich meine Arbeit mit Chatbots auf vier Use Cases:

• Bugs fixen
• Refactoring von bestehendem Code
• Tests zur Implementierung generieren
• Neuen Code generieren

Das Vorgehen ist dabei immer ähnlich: Ich kopiere ausgewählten Quellcode in den Chat und erhalte verbesserten oder neuen Code als Antwort.

1. Bugs fixen

Es fühlt sich an wie eine Weiterentwicklung von Plattformen wie Stack Overflow. Im Grunde ist der Chatbot das neue Googlen – nur effizienter.

Auf Stack Overflow musste ich mein konkretes Problem oft mühsam abstrahieren, um eine passende Antwort zu finden. Diese kognitive Last nimmt mir die KI ab: Ich poste den konkreten Fehler samt Code, und sie transferiert die Lösung direkt auf meinen Kontext.

Sind die Lösungen dabei immer richtig? Nein. Zwar bietet Stack Overflow durch die bewerteten Antworten eine gewisse Sicherheit, dass der Code zumindest bei jemandem schon einmal funktioniert hat – diese Garantie fehlt bei der KI völlig. Der entscheidende Unterschied im Alltag ist für mich aber: Ich verbringe meine Zeit nicht mehr mit der Suche und Adaption, sondern investiere sie direkt in die kritische Bewertung und das Review des maßgeschneiderten KI-Vorschlags.

2. Refactoring von bestehendem Code

Wenn ich mich tief im Detail bewege – also auf Methoden- oder Klassenebene – ist die KI ein exzellenter Sparringspartner. Das gilt für zwei Szenarien:

1. Legacy-Code verstehen: Wenn ich alten Code lese, den ich nicht (mehr) verstehe, lasse ich ihn mir erklären und im Anschluss lesbarer umschreiben. Aber Vorsicht: Da dem LLM das tiefe Verständnis für unsere Fachlichkeit fehlt, muss ich seine Erklärungen kritisch hinterfragen. Wenn ich die Business-Logik selbst nicht kenne, ist es extrem schwer, ein "ratendes" LLM vernünftig zu reviewen.
2. Neuen Code polieren: Auch bei frischem Code hilft der Chatbot, die Lesbarkeit und Wartbarkeit zu erhöhen.

Mein Tipp: Ich fordere oft explizit mehrere Lösungsvarianten an (z.B. "Mach es funktionaler" oder "Optimiere auf Performance"). Am Ende wähle ich diejenige aus, die am besten zur bestehenden Codebase passt. Hier bin ich der Reviewer, die KI der Coding-Assistent.

3. Tests zur Implementierung generieren

Das klingt nach der Wunschvorstellung vieler Entwickler: Ich schreibe die Business-Logik, der Chatbot liefert die passenden Tests.

Doch hier liegt eine Falle: Kennt die KI nur meine Implementierung, schreibt sie Tests, die diese Logik lediglich spiegeln. Echte Bugs oder Denkfehler fallen so nicht auf, da der Test denselben Fehler macht wie der Code. Das Ergebnis sind oft viele kleinteilige Tests, die zwar "grün" sind (oder auch nicht), aber keine fachliche Korrektheit garantieren.

Meine Strategie: Ich drehe den Spieß um. Das Test-Setup und den ersten, kritischen Test-Case schreibe ich selbst – das setzt den Qualitätsstandard. Die weiteren Szenarien erarbeite ich oft im Dialog mit dem Chatbot, bevor er die Fleißarbeit der Ausformulierung übernimmt. Doch Vorsicht: Das Review bleibt Pflicht. Blindes Vertrauen führt zu grünen Tests, aber fehlerhaftem Produktionscode.

4. Neuen Code generieren

Während das Polieren von Code gut funktioniert, ist das Generieren von gänzlich neuem Code oft frustrierend. Hier zeigt sich: Der KI fehlt das tiefe Verständnis für die Fachlichkeit und die Architektur meiner Anwendung.

Das Problem: Der generierte Code passt oft nicht in die bestehende Codebase. Ich muss im Prompt extrem tief ins Detail gehen, damit sich das Ergebnis zuverlässig verhält.

Ein konkretes Beispiel aus meinem Alltag: Wenn ich moderne UI-Komponenten generieren lasse, greift der Chatbot standardmäßig auf veraltete Paradigmen zurück, statt die aktuellen Standards unseres Teams zu nutzen. Zudem flutet er den Quelltext mit trivialen Kommentaren („Variable X wird gesetzt“), die den Code unnötig aufblähen.

Mein Fazit hier: Oft bin ich schneller, wenn ich den Code selbst schreibe, statt die KI-Lösung mühsam zu debuggen und zu bereinigen.

Licht und Schatten: Ein Zwischenfazit

Die Arbeit mit KI-Chatbots ist in dieser ersten Ausbaustufe noch stark von manueller Arbeit geprägt. Der Workflow besteht oft aus „Copy-Paste“, um Kontext zu liefern und die Ergebnisse dann in die IDE zurückzuführen.

Die Effizienzsteigerung findet hier vor allem im Mikrokosmos statt: Wenn ich mich innerhalb einer Methode oder Klasse bewege, ist der Support exzellent. Der Chatbot nimmt mir Tipparbeit ab und liefert Syntax-Beispiele.

Aber: Das große Ganze – die Architektur und die Fachlichkeit – liegt weiterhin zu 100 % bei mir. Der Chatbot überblickt die Zusammenhänge nicht. Ich werde (noch) nicht zum reinen Reviewer, sondern bleibe Coder, der sich für Detailfragen einen sehr schnellen Assistenten an die Seite holt. Die Hauptlast der Entwicklung und des „Zusammenfügens“ trage ich weiterhin selbst.

Ausblick

Wir haben gesehen, dass der Chatbot ein mächtiges Werkzeug ist, aber durch die Zustandslosigkeit und das ständige Kontext-Hopping auch mühsam zu bedienen sein kann.

Das wirft die Frage für den nächsten Teil auf: Lässt sich dieser manuelle „Copy-Paste-Wahnsinn“ automatisieren? Können Tools den Kontext unserer Codebase vielleicht selbstständig verstehen, ohne dass wir ihn füttern müssen?

In Teil 2: Agentic Vibecoding untersuche ich, ob ein autonomer Agent diesen manuellen Aufwand eliminieren kann – oder ob es problematisch sein kann, wenn wir uns für unseren eigenen Code nicht mehr interessieren.