LLMs im Entwickleralltag: Werkzeug, kein Autopilot

Als ich zum ersten Mal ernsthaft mit einem Sprachmodell programmiert habe, war meine Reaktion gemischt: beeindruckt von der Geschwindigkeit, skeptisch gegenüber der Qualität. Inzwischen sind LLMs fester Bestandteil meines Alltags als Entwickler — aber meine Skepsis ist geblieben, nur gezielter geworden. Genau dieses Gleichgewicht aus Nutzen und Vorsicht will ich hier greifbar machen, statt es bei einem pauschalen "KI hilft" oder "KI kann das noch nicht" zu belassen.

Wo LLMs wirklich helfen

Am stärksten sind Sprachmodelle dort, wo es viele bekannte Muster und wenig echte Unsicherheit gibt: Boilerplate-Code für eine REST-Route, ein Formular mit Validierung, eine Typdefinition aus einem JSON-Beispiel. Auch beim Einarbeiten in fremden Code sind sie wertvoll — eine 300 Zeilen lange Funktion in einer unbekannten Codebasis lässt sich in Sekunden zusammenfassen, statt sie Zeile für Zeile zu entschlüsseln. Und wenn ich zwischen zwei oder drei Lösungsansätzen schwanke, lasse ich mir gerne alle drei grob skizzieren, bevor ich mich für einen entscheide und ihn selbst sauber ausarbeite. Das spart vor allem Zeit an der Stelle, an der man sonst am längsten sitzt: dem ersten leeren Editor-Tab.

Wo sie in die Irre führen

Das eigentliche Problem ist nicht, dass Sprachmodelle Fehler machen — das tun Menschen auch. Das Problem ist, dass sie falsche Antworten mit derselben Selbstsicherheit formulieren wie richtige. Ein Modell kennt weder die tatsächliche Architektur eines Projekts noch die stillen Annahmen, auf denen sie beruht: welche Funktion an zehn anderen Stellen aufgerufen wird, warum eine scheinbar unnötige Fallunterscheidung tatsächlich einen Produktionsbug von letztem Jahr verhindert, oder dass ein Datenbankfeld aus historischen Gründen anders benannt ist, als es der Name vermuten lässt. Ein typisches Muster, das mir immer wieder begegnet: Eine Funktion wird "verbessert", ohne dass sichtbar ist, dass sie an anderer Stelle mit einer bestimmten Annahme über die Eingabedaten aufgerufen wird — der neue Code sieht sauberer aus, bricht aber eine stille Garantie, auf die sich der Rest des Systems verlässt. Solche Fehler fallen selten sofort auf, sondern erst im Test oder schlimmer: in Produktion.

Mein Workflow damit

Ich nutze LLMs konsequent für die erste Skizze und für alles, was Reibungsverluste im Alltag verursacht — Boilerplate, Testgerüste, das Umformulieren einer Fehlermeldung in verständliches Deutsch. Bei allem, was Architekturentscheidungen betrifft, sicherheitsrelevant ist oder mit Nebenläufigkeit zu tun hat, wird ein Vorschlag maximal zum Ausgangspunkt, nie zur Übernahme ohne Prüfung. Konkret heißt das: Ich lese jede vorgeschlagene Änderung so, als hätte sie ein neuer, mir unbekannter Kollege geschrieben — mit gesundem Misstrauen gegenüber allem, was ich nicht selbst nachvollziehen kann. Tests schreibe ich mir zunehmend selbst vor, statt sie mir generieren zu lassen, weil ein Modell sonst leicht Tests schreibt, die den eigenen (fehlerhaften) Code bestätigen, statt das eigentliche Verhalten zu prüfen.

Fazit

Ein Sprachmodell beschleunigt die Arbeit erheblich, ersetzt aber nicht das Verständnis dessen, was tatsächlich gebaut wird. Die Verantwortung für sauberen Code, sinnvolle Architektur und die finale Qualitätssicherung liegt weiterhin bei mir — und genau das würde ich niemandem abnehmen wollen, selbst wenn es technisch möglich wäre.