Just because you can, doesn't mean you should

Bei PyleHound, unserer Desktop-App für Jurist:innen, kann man im Chat mit @ eine Datei aus der eigenen Aktensammlung referenzieren, ähnlich wie ein Mention in Slack. Die Datei wird dann inline in der Antwort vom Fließtext abgegrenzt dargestellt und unter der Haube passiert noch ein bisschen magic, sodass das LLM weiß, was es damit tun soll. Vor ein paar Tagen fiel mir beim Testen des Release-Kandidaten unserer neuen Version auf, dass der Dateiname nach links aus der Chatblase und dem sichtbaren Bereich hinausläuft und damit unlesbar wird, sobald der Chat-Bereich zu schmal wird.

Ohne selbst ins Debugging einzusteigen, habe ich selbstverständlicherweise meinen KI-Coding-Agenten gestartet. Gemeinsam haben wir so erstmal 3-4 Runden gedreht: jedes Mal behauptet der Agent, er habe den Bug gelöst, ich teste in der App und sehe, der Bug tritt weiterhin auf. Leicht genervt bin ich dann zu einer anderen Strategie übergegangen. Ich habe den Coding-Agenten instruiert, sich selbst eine Feedbackschleife aufzubauen, um nachvollziehen zu können, ob der Bug wirklich gelöst ist. Dafür hat er ein kleines Skript geschrieben, um die App fernzusteuern und Screenshots erzeugen zu können, die er anschließend wiederum auswerten kann. So hat der Agent dann erstmal weitergearbeitet und ich habe mich zwischenzeitlich einer anderen Aufgabe gewidmet. Nach etwa 30 Minuten war er fertig. Ich habe die App gestartet und der Bug war gefixt. Als ich mir jedoch den Code angesehen habe, stellte ich schnell fest, dass die gewählte Lösung extrem umständlich war und ein Changeset von einigen hundert Lines of Code hatte. Also habe ich die Änderungen wieder zurückgesetzt und mich selbst einmal kurz drangesetzt — und siehe da: Nach 5 Minuten und 6 Zeilen war der Bug behoben.

Dieses Beispiel zeigt: KI-Coding-Agenten arbeiten mittlerweile bereits sehr autonom und wir können ihnen jegliche Aufgaben übergeben. Aber sollten wir das auch wirklich?

Ich bin damit nicht allein

Beim Einsatz von KI-Agenten überschätzen wir systematisch, wie sehr sie uns tatsächlich helfen. METR hat im Juli 2025 16 erfahrene Open-Source-Entwickler:innen 246 echte Issues bearbeiten lassen, teils mit, teils ohne KI-Unterstützung. Dabei wurde zunächst eine Selbsteinschätzung vorgenommen, nach der die Entwickler:innen prognostizierten, im Schnitt 24% schneller zu werden. Bei der tatsächlichen Bearbeitung der Aufgaben mit KI brauchten sie jedoch im Schnitt 19% länger! Ironischerweise glaubten sie dabei, trotz der realen Verlangsamung, nach Fertigstellung der Aufgabe, die KI habe sie etwa 20% beschleunigt. Die Autoren selbst schränken ein: Ihre Stichprobe waren erfahrene Devs an großen, komplexen Codebases. Und genau das deckt sich auch mit meinen eigenen Beobachtungen: Je größer und erwachsener eine Codebase wird, desto schwerer tut sich die KI, den Überblick zu behalten. Bei einem unserer größeren iOS-Kundenprojekte bei beansandbytes sehe ich fortlaufend, dass KI viel zu lange braucht, viel zu viele Tokens verbraucht, oft unnötig kompliziert verschachtelt und es selten schafft, einen Stil konsequent durchzuziehen, selbst wenn ich gezielt dagegen prompte.

Der Stack Overflow Developer Survey 2025 (49.000+ Befragte) zeigt in dieselbe Richtung: Der meistgenannte Einzelfrust, von 66% der Befragten: "AI solutions that are almost right, but not quite." Und 45% sagen, das Debuggen von KI-geschriebenem Code dauert länger.

Eine Anekdote aus dem Entwicklungsprozess von meiner Firma, PyleHound: An mindestens fünf Stellen in unseren Skills, im Codestyle und in den KI-Instruktionen haben wir festgelegt, wann Code-Kommentare geschrieben werden und wie sie aussehen sollen. Bevorzugt keine Kommentare, und wenn ein Kommentar wirklich notwendig ist, dann ist es einer, der einen größeren Zusammenhang beschreibt, d.h. eine Zeile, die nicht selbsterklärend ist, bekommt einen Kommentar, "Warum" dieser Code so geschrieben wurde. Trotzdem rutschen gängige KI-Coding-Agenten immer wieder in erklärende "was passiert hier"-Kommentare zurück. Meine Theorie: Ein großer Teil der Trainingsdaten, gerade Blogartikel und Tutorials auf den gängigen Portalen, zielt auf Coding-Anfänger ab, die sich schwer damit tun, zu verstehen, was passiert, und enthält daher genau diese "Was"-Kommentare.

Wann lohnt sich Selbstschreiben eigentlich noch?

Bei einem Projekt wie PyleHound mit lokaler Dokumentenverarbeitungspipeline, lokaler Datenbank, Anbindung verschiedener Systeme und KI-Modelle entstehen häufig sehr komplexe Zusammenhänge und Abhängigkeiten, die aus dem Code nicht immer sofort ersichtlich sind. Wenn ich als Entwickler diese Zusammenhänge selbst nicht mehr kenne, weil ich blind auf die KI vertraue, kann ich auch das notwendige Hintergrundwissen nicht mehr im Prompt liefern, das hilft, eine Aufgabe schnell und effektiv zu bearbeiten. Es gibt aber keine festen Kriterien dafür, wann ich selbst Code schreibe und wann ich das an die KI delegiere. Selbst schreiben heißt natürlich, ich bin selbst tief in der Materie drin und kenne alle Zusammenhänge, bin jedoch potentiell langsamer, weil Code schreiben ja nicht nur stupides "Runterschreiben" ist. Volle Delegation an KI heißt, ich kenne selbst nur die Anforderungen und messe am Ende die Qualität der Lösung über die Erfüllung dieser Anforderungen. Das führt häufig schnell zu Lösungen und ist insbesondere spannend fürs Prototyping.

Für mich haben sich folgende Varianten bewährt:

1. Manuelles Coding mit KI-Coaching
2. Planung des Tasks auf Code-Ebene und Delegation des Ausformulierens an den Agenten.

Ein Fall aus der jüngsten Vergangenheit, in dem ich mich für selbst schreiben entschieden habe: Im iOS-Projekt eines unserer Kunden ging es darum, die Apple Watch Companion App in eine neue UI zu überführen. Da das Projekt mittlerweile watchOS 10 und aufwärts targetet, konnte ich mit diesem UI-Update nun neue SwiftUI-Features benutzen, die beim Entstehen der aktuellen Variante noch nicht enthalten waren und die ich kennenlernen wollte. Im konkreten Fall ging es um SwiftUI Grid und GridRow, eingeführt mit iOS 16 / watchOS 9. Bisher hatte die Watch App keinen echten Anwendungsfall für Grids, aber durch das Redesign hatte sich nun einer ergeben. Da ich die API selbst bisher nicht verwendet hatte, wollte ich mich hier gezielt einarbeiten und kennenlernen, was es für Möglichkeiten gibt. Also habe ich meinen KI-Agenten dazu recherchieren lassen, mir die API erklären lassen und wie ich die View-Hierarchie hierfür aufbauen muss, die Implementierung aber selbst übernommen, um einen möglichst großen Lerneffekt zu haben.

Ein anderes Beispiel zeigt, wie ich häufig bei der Umsetzung von Routine-Aufgaben vorgehe: Ich möchte ein neues Feature implementieren, von dem ich bereits selbst weiß, wie es in die App zu integrieren ist und wie die Anforderungen sind. Dafür nutze ich die Planungsfunktion meines KI-Agenten und wir arbeiten gemeinsam einen Umsetzungsplan aus. Ich prüfe den Plan mit jedem Iterationsschritt und sobald ich zufrieden mit dem gewählten Ansatz bin, schalte ich den Agenten in den Umsetzungsmodus und lasse ihn für eine Zeit ungestört arbeiten. Teil dieses Plans ist eine feste Prozessabfolge, die sicherstellt, dass der Agent kleine, einfach zu reviewende Zwischenergebnisse erstellt, die ich dann prüfe und teste und anschließend selbst committe. Damit ist eine Phase abgeschlossen und ich starte die nächste Phase, bis der ganze Plan abgearbeitet ist.

Es gibt aber auch immer wieder Situationen, in denen der KI-Agent als Sparringspartner komplett versagt. Ein häufiger Fall bei mir sind Entscheidungen zur Ausrichtung der Codebase und Architektur. Hier findet selten ein guter Austausch statt, weil die KI einem häufig immer noch komplett nach dem Mund redet. Anthropic selbst hat 2023 in "Towards Understanding Sycophancy in Language Models" gezeigt, dass fünf verbreitete KI-Assistenten systematisch Antworten bevorzugen, die der Meinung der Nutzer:innen entsprechen, mitverursacht durch das RLHF-Training auf menschlichen Präferenzdaten.

Macht mich der KI-Einsatz dümmer?

Eine Sache, die mich zunehmend beschäftigt: Wenn die eigentlichen Erfolgsmomente beim Programmieren fehlen, weil man ein schwieriges Coding-Problem nicht mehr selbst löst, verliert man dann nicht etwas intrinsisch Motivierendes? Ein MIT-Media-Lab-Team hat 2025 mit EEG gemessen, was beim Schreiben mit ChatGPT im Gehirn passiert: Wer einen Aufsatz mit dem Modell schrieb, zeigte die schwächste neuronale Konnektivität, das geringste Gefühl von Eigentümerschaft am eigenen Text und die schlechteste Erinnerung daran, was er geschrieben hatte, verglichen mit Suchmaschinen-Nutzer:innen und Leuten, die ganz ohne Unterstützung von Tools schrieben. Interessant: Diejenigen Probanden, die zuerst selbst schrieben und erst danach zu ChatGPT wechselten, zeigten stärkere neuronale Aktivierung als diejenigen, die direkt mit dem Modell einstiegen. Das entspricht auch in etwa meinem oben beschriebenen Coaching-Ansatz. Eine zweite Studie (Gerlich, 2025, 666 Befragte) findet eine Korrelation zwischen KI-Nutzung und schwächerem kritischem Denken, vermittelt über Cognitive Offloading.

Ich versuche daher hin und wieder auch gezielt und bewusst, schwierigere Probleme von Hand zu lösen, zum einen, um die grauen Zellen fit zu halten, und zum anderen, um eben auch weiterhin genau diese Erfolgserlebnisse zu verspüren, wenn man eine komplexe Aufgabe selbst gelöst hat.

Wie sieht das strukturiert aus?

In Kürze: Ich verwende für komplexe Aufgaben niemals Zero-Shot-Prompting.

In meinen Firmen haben wir hier klare Prozesse entwickelt: Issues refinen, einen Implementierungsplan entwickeln, einen Implementierungsplan reviewen, den Code schreiben nach festen Regeln, einzelne Phasen reviewen, einen PR öffnen, Integrations- und Unit-Tests schreiben. Je nachdem umgesetzt von einem menschlichen Mitarbeitenden oder von einem KI-Agenten, manchmal auch von beiden parallel. Jeder Code, der committet wird, wird von einem Menschen und einer zweiten neutralen KI vor dem Commit nochmal reviewed. Zusätzlich gibt es einen automatisierten PR-Review-Bot, der in der CI läuft und den menschlichen Review unterstützt.

Das Ganze kratzt aber momentan noch sehr an der Oberfläche und ich arbeite derzeit daran, hier ein vollständiges System zu entwickeln, das den ganzen Prozess komplett automatisiert und an gezielten Stellen selbstständig menschliches Feedback einholt. Unser eigenes Tooling ist nie in einem fertigen Zustand, sondern auch selbst ständigen Veränderungen unterworfen.

Soll ich nun also KI einsetzen oder nicht?

Ja, natürlich solltest du KI einsetzen. Es gibt derzeit keine Branche, die sich so schnell verändert wie KI, und keine Branche, die davon so stark profitiert wie Softwareentwicklung. Die Stärken und Schwächen, die ich oben genannt habe, sind eine Momentaufnahme und nicht endgültig. Weil sich KI-Systeme so schnell weiterentwickeln, teste ich Use Cases, die vor ein paar Monaten noch schlecht funktioniert haben, in regelmäßigen Abständen erneut. Was heute umständlich ist, muss es in drei Monaten nicht mehr sein. Genau deswegen lohnt es sich, jetzt anzufangen, KI zu nutzen und in die eigenen Abläufe zu integrieren und eigene Annahmen immer wieder auf den Prüfstand zu stellen.