Ich nutze KI-Agenten beim Entwickeln fast täglich. Sie nehmen mir das monotone Runterschreiben von Boilerplate ab, beschleunigen die Suche in sperrigen APIs und taugen als Sparringspartner, um Entwürfe gegen die Wand zu werfen. Coding-Agenten sind nützliche Werkzeuge. Wer ihren Einsatz pauschal als Betrug oder Verfall der Handwerkskunst abkanzelt, ignoriert schlicht die Realität.
Prompts statt Programmverständnis
Das Problem liegt selten im Werkzeug selbst. Es beginnt dort, wo Code generieren mit Code verstehen verwechselt wird.
Unter dem Begriff Vibe Coding hat sich eine Haltung breitgemacht, die genau diese Grenze für überflüssig erklärt: Ein paar Prompts reinwerfen, die KI Fehlermeldungen iterativ abarbeiten lassen, bis das Fenster aufgeht – und das Ergebnis als fertige Software betrachten. Das bringt schnelle Erfolgserlebnisse. Man sieht nach zwei Stunden etwas auf dem Schirm, für das man früher Tage gebraucht hätte. Nur beweist eine funktionierende Oberfläche nicht, dass man weiß, was das Programm im Speicher, auf der Platte oder im Netzwerk eigentlich anstellt. Wer Software nur nach Gefühl zusammenpromptet, bleibt für Architektur, Randfälle und Sicherheitsrisiken blind.
Zweitausend Zeilen Main.qml
Eine funktionierende Benutzeroberfläche ist der denkbar schlechteste Maßstab für Codequalität. Code kann modularer Sondermüll sein und trotzdem ohne Murren kompilieren. Wenn ich einer KI sage: „Bau mir eine Anwendung mit Player, Lautstärkeregler und Senderliste“, spuckt sie genau das aus. Entscheidend ist aber, wie das Ergebnis zustande kommt, wenn niemand die Leitplanken setzt.
Oft landen Geschäftslogik, Netzwerkaufrufe, State-Management und Styling in einer einzigen Datei. Man sieht das regelmäßig bei deklarativen UIs: zweitausend Zeilen in einer einzigen Main.qml. Da hängen Signal-Handler direkt an UI-Elementen, HTTP-Requests werden mitten im Klick-Event eines Buttons abgefeuert, und der Anwendungszustand existiert irgendwo implizit zwischen drei verschachtelten Komponenten. Coding-Agenten erkennen solche Probleme ohne explizite Vorgaben selten von allein; das Risiko ist hoch, dass sie bestehende schlechte Strukturen unkritisch fortschreiben. Jedes neue Feature wird an den bestehenden Monolithen angeflanscht, statt Schichten sauber zu trennen.
Solange das Fenster aufgeht, fällt das nicht auf. Der Vibe stimmt.
Spannend wird es, wenn die Realität dazwischenfunkt: ein Speicherleck, eine Race Condition beim asynchronen Nachladen oder der Versuch, ein neues Feature einzubauen, ohne dass an drei anderen Ecken alles umkippt. Wer nicht versteht, wie das Konstrukt im Kern tickt, kann nicht gezielt debuggen. Die typische Reaktion ist der nächste Prompt: „Hier ist ein Fehler, reparier das.“ Die KI klebt ein Pflaster über das Symptom, erzeugt zwei neue Seiteneffekte, und die Codebasis verwandelt sich Schicht für Schicht in ein Dickicht aus Workarounds.
Schnelle Repositories, verwaiste Baustellen
Das bleibt selten auf der lokalen Platte, sondern landet meistens ungeprüft auf GitHub.
Weil das Generieren kaum noch Reibung erzeugt, entsteht eine Flut von Projekten über Nacht. Ein Wochenende, dreißig Prompts, ein poliertes README mit bunten Badges und Demo-GIF – und ab ins öffentliche Repository. Der Kick liegt im schnellen Vorzeigen.
Was danach kommt, passt nur selten in einen Prompt.
Software altert ab dem Moment, in dem sie veröffentlicht wird. APIs ändern sich, Sicherheitslücken in Abhängigkeiten tauchen auf, ein Versionssprung im System bricht die Pipeline. Hier liegt der Unterschied zwischen einem Projekt, das schlicht fertig ist und keine neuen Features braucht, und einem Projekt, das ungepflegt vor sich hin rottet.
Wenn das erste echte Issue aufschlägt – ein Absturz unter einer bestimmten Umgebung oder ein Berechtigungsfehler –, zeigt sich der Unterschied zwischen Softwareentwicklung und reinem Prompting. Wer die Zusammenhänge im eigenen Projekt nicht begriffen hat, kann es nicht sinnvoll pflegen. Das Debuggen macht keinen Spaß, weil man komplexe Fehler nicht mit einem Drei-Wort-Prompt erschlagen kann. Nach ein paar Wochen gibt es keine Commits mehr, Issues laufen ins Leere, und das nächste Projekt wird im nächsten Chatfenster gestartet.
Niemand schuldet der Welt lebenslangen Support für ein Freizeitprojekt. Aber ein ehrlicher Satz im README – „Proof of Concept, wird nicht aktiv gepflegt“ – spart anderen Leuten schlicht Lebenszeit.
Leitplanken statt Autopilot
Man kann das anders aufziehen: als schnellen Assistenten, dem man präzise auf die Finger schaut.
Das fängt vor der ersten Zeile an. Wer Software baut, muss zuerst das System durchdenken:
- Wo liegen die Daten? Wer kommuniziert mit wem?
- Wo verläuft die Grenze zwischen Kernlogik, State und Oberfläche?
Steht diese Architektur, lässt sich die Arbeit in beherrschbare Stücke zerlegen. Statt einer Pauschalforderung wie „Bau mir die Anwendung“ bekommt das Modell eine konkrete Schnittstelle, den Auftrag für einen isolierten Parser und die passenden Unit-Tests für Randfälle und ungültige Payloads. Je klarer Kontext und Modulgrenzen abgesteckt sind, desto weniger Raum bleibt für generierten Wildwuchs.
Danach kommt das Review.
Man muss nicht jede Zeile Standardcode im Schlaf aufsagen können. Aber man muss das Gesamtbild verstehen und den generierten Code fachlich prüfen können:
- Warum wählt das Modell diesen konkreten Weg?
- Was passiert bei einem Verbindungsabbruch mit offenen Sockets oder Filedeskriptoren?
Wenn ich eine Konstruktion nicht nachvollziehen kann, bleibt sie nicht im Projekt stehen – völlig egal, ob sie im ersten Testlauf zufällig funktioniert.
Verantwortung vor dem Terminal
Am Ende wirkt ein Coding-Agent wie ein Hebel: Er verstärkt sauberes Handwerk genauso wie schlampiges Halbwissen. Die Verantwortung für die Architektur, die Commits und die Sicherheitsrisiken bleibt ausnahmslos beim Menschen vor der Tastatur.
Niemand muss als fertiger Architekt anfangen. Wer mit Sprachmodellen experimentiert, um überhaupt einen Einstieg in die Softwareentwicklung zu finden, soll das tun. Es gibt derzeit kaum ein schnelleres Werkzeug, um sich Zusammenhänge, Protokolle oder fremde APIs erklären zu lassen – vorausgesetzt, man nutzt es zum Begreifen, statt das Denken wegzudelegieren. Auch flüssig formulierte Erklärungen können schlicht falsch sein; die Gegenprobe an der offiziellen Dokumentation und am echten Systemverhalten bleibt Pflicht.
Softwareentwicklung war noch nie das bloße Heruntertippen von Syntax. Das war schon immer nur der ausführende Teil. Der eigentliche Kern ist das Durchdringen von Systemen, das Abwägen technischer Kompromisse und das Finden von Fehlern, an die beim Formulieren des Prompts niemand gedacht hat.
Der Vibe hält genau so lange, wie die Bedingungen gutmütig sind. Er verfliegt beim ersten Deadlock oder beim ersten handfesten Sicherheitsproblem im Produktivbetrieb. Was danach zählt, ist kein Gefühl und kein Prompt, sondern die Fähigkeit, das eigene System bis auf den Grund zu verstehen und zu reparieren.