Ich setze LLMs seit gut einem Jahr aktiv in meiner Arbeit als Software-Entwickler ein — nicht als Experiment, sondern als tägliches Werkzeug. Ein paar ehrliche Beobachtungen.
Die unterschätzte Stärke: Erklären und Einordnen#
Der offensichtliche Use Case ist Code generieren. Der wertvollere Use Case ist erklären lassen. “Was macht dieser Legacy-Code?”, “Welche Implikationen hat dieses Datenbankschema?”, “Erkläre mir den Unterschied zwischen diesen zwei Ansätzen.”
Besonders bei unbekannten Codebases oder Technologien ist das enorm wertvoll. Das Onboarding in ein neues Projekt hat sich für mich halbiert.
Die unterschätzte Schwäche: Aktualität#
LLMs haben einen Wissensstichtag. Für alles was sich schnell ändert — Cloud-APIs, neue Framework-Versionen, aktuelle Security-CVEs — ist ein aktueller Blick in die Dokumentation unersetzlich.
Ich nutze dafür Context7 als MCP-Server in Claude Code: aktuelle Dokumentation direkt im Kontext, ohne Browser-Wechsel.
Was mich überrascht hat#
Reasoning über Anforderungen. Wenn ich einem LLM einen Anforderungstext gebe und frage “welche Fälle sind hier nicht berücksichtigt?”, bekomme ich oft bessere Fragen zurück als nach einem kurzen internen Review. Das liegt nicht daran, dass KI klüger ist — sondern dass sie ohne Betriebsblindheit liest.
Konsistente Qualität über Müdigkeit hinweg. Freitagabend um 18 Uhr produziere ich schlechteren Code als Dienstagmorgen. Ein LLM nicht. Das ist banal, aber praktisch relevant.
Mein Fazit#
LLMs sind kein Ersatz für Nachdenken — sie sind eine Erweiterung des Werkzeugkastens. Am besten einsetzen für: Recherche, Erklärungen, Boilerplate, Code-Review als zweite Meinung. Am schlechtesten für: Security-kritischen Code ohne Review, Tests die Logik beweisen sollen, Entscheidungen die man selbst nicht versteht.