KI-Assistenten in der Entwicklung: Praxisbericht

Foto des Autors
Robert Weyres
Robert Weyres

Ob Orchestrierung, Tokenverbrauch oder veraltete Trainingsdaten: Der praktische Einsatz von KI in der Entwicklung bringt neue Möglichkeiten, aber auch neue Herausforderungen.

Programmierer arbeitet konzentriert an einem Laptop mit einem KI-Assistenten in moderner, ruhiger Arbeitsumgebung; warme Lichtstimmung, unscharfer Hintergrund mit Pflanze und Tasse auf dem Tisch

KI-Assistenten wie Claude und ChatGPT sind mittlerweile im Alltag angekommen, auch in der Entwicklung mit speziellen Tools wie Claude Code oder Codex. Nun stellt sich die Frage, inwieweit uns diese Assistenten in unserem täglichen Beruf als Softwareentwickler unterstützen können – sind sie in der Lage, uns Arbeit abzunehmen oder erzeugen sie sogar zusätzliche Arbeit und geben uns nur ein Gefühl von Effizienz? Diese Frage kann man unterschiedlich beantworten, je nachdem, wie und wann man die KI verwendet.

In diesem Bericht beziehe ich mich auf meine eigenen Erfahrungen mit Claude Code von Anthropic und Claude Sonnet 4.5 von Anthropic. Zunächst eine wichtige Unterscheidung:

Claude Code ist ein „Harness“ für KI-Modelle, d. h. ich kann innerhalb der Software auswählen, mit welchen Modellen ich arbeiten möchte. Es gibt mir ebenfalls die Freiheit, externe Modelle anzubinden und im Kommandozeilentool zu verwenden.

Claude Sonnet 4.5 ist ein LLM von Anthropic, welches nativ in Claude Code benutzt werden kann.

Private Projekte und die Qualität der Anforderungen

Während ich im privaten Alltag Claude Code ausprobiere, habe ich mich im Berufsalltag mit GitHub Copilot beschäftigt, allerdings auch in diesem Tool fast immer mit Claude Sonnet 4.5 gearbeitet.

Dabei habe ich gemerkt, dass Claude Code für private Projekte meistens völlig ausreichend ist. Dabei kommt die Qualität des produzierten Codes immer auf die Qualität der Formulierung der Anforderungen an – je besser ich formuliere, was ich erwarte, desto besser das Ergebnis weil Claude nicht erraten (bzw. halluzinieren) muss, was ich möchte.

Arbeit an bestehenden Projekten

Beim Arbeiten an einem bestehenden, komplexen Projekt eignet sich die KI dann gut, wenn die Anforderungen klar definiert sind und die Änderungen nicht über die Codebase verstreut sind. Sonst kann dort durchaus schnell das Ende der Möglichkeiten erreicht sein.

Neue Projekte von Grund auf

Fängt man ein neues Projekt von Grund auf an, klappt es mit KI sehr gut, den ersten Proof of Concept bzw. das erste Minimum Viable Product zu bauen. Hierbei kann die KI durchaus sehr guten Code produzieren und diesen auch selbstständig testen. Teilweise können sogar wenige Stichpunkte ausreichen, die den Technologiestack und eine grobe Vision skizzieren, weil Webanwendungen oft ähnlich aufgebaut sind und Claude dort aufgrund des großen Trainingsdatensets bereits sehr erfahren ist.

Wenn die Anforderung nicht zu komplex ist, schafft die KI es sogar eine komplette Full-Stack Anwendung zu bauen, wie etwa eine einfache Implementierung eines Backends mit Datenbank zur Verwaltung von zeitbasierten Feature Flags.

Orchestrierung und Token-Verbrauch

Mittels Orchestrierungstools wie zum Beispiel Roo Code ist es möglich mehr Autonomie zu erreichen, indem man mehrere Agenten zur Verfügung hat – dies bedeutet aber ebenfalls höhere Kosten, da alle Agenten auf das gleiche Tokenkontingent zugreifen, das zur Verfügung steht. Somit wird das Limit hier vermutlich schneller erreicht als bei der Verwendung von Claude Code direkt. Diese Information bezieht sich auf das Abonnement-Modell von Claude Code; wenn man die API-Variante verwendet, gibt es keine Limits, daher sollte man dort noch genauer aufpassen, wie viele Kosten verursacht werden.

Edge Cases sind durchaus schwierig bis unmöglich, ohne manuelles Eingreifen. Wenn ich einen fachlichen Use Case habe, der wirklich einzigartig ist, kann die KI diesen vermutlich nur dann implementieren, wenn ich ihn nahezu perfekt beschreiben kann. Andernfalls muss in solchen Fällen manuell interveniert werden, um das gewünschte Ziel zu erreichen.

Das Problem veralteter Trainingsdaten

Ein weiterer Faktor ist die Aktualität des Codes. Da die Trainingsdaten in den meisten Fällen 1–2 Jahre alt sind, werden zum Beispiel bei der Generierung von wiederverwendbaren GitHub-Workflows Actions in Versionen vorgeschlagen, die längst veraltet sind – dort reicht es aber meistens, die Version selbst manuell anzupassen und eventuelle Breaking Changes zu berücksichtigen. Somit ist die Erstellung des Workflows und das anschließende Review mit Behebung deutlich schneller, als den gesamten Workflow selbst zu schreiben. Hierbei kann der MCP-Server Context7 Abhilfe schaffen, da dieser dem Coding-Assistant die aktuellen Dokumentationen der meisten Frameworks bzw. Bibliotheken zur Verfügung stellen kann. Meistens passiert dies automatisch wenn Claude nicht weiß, wie etwas funktioniert – teilweise muss man aber auch spezifische Anweisungen geben, Context7 zu verwenden.

Vektordatenbanken als persistentes Gedächtnis

MCP-Server implementieren das Model Context Protocol von Anthropic und ermöglichen es, dem KI-Assistenten erweiterte Funktionen zur Verfügung zu stellen. Neben dem bereits erwähnten Context7 kann eine Vektordatenbank helfen, um ein Projektgedächtnis aufzubauen. Hierbei kann die KI selbstständig Gedächtniseinträge erstellen und abrufen, um sich somit zu „erinnern“, welche Entscheidungen zuvor getroffen wurden. Man kann in den globalen Einstellungen der KI (bei Claude ist es ein globales CLAUDE.md) festlegen, wie es das Gedächtnis verwenden soll. „Wenn Du ein neues Feature implementiert hast, mache einen Eintrag im Memory“ wäre ein Beispiel dafür, aber auch „Wenn ein Experiment fehlschlägt, mache einen Eintrag im Memory“, damit man dieses Experiment in der Zukunft nicht noch einmal wiederholt.

MCP als Erweiterungsplattform

Es gibt sehr viele weitere MCP-Integrationen von Dokumentationen wie Context7 über Payment- Integrations wie Stripe bis hin zur Verwendung lokaler separater KI-Projekte wie z. B. Flux zur Generierung von Bildern. Hierbei sollte aber auch beachtet werden, dass jede Person einen MCP-Server schreiben kann – daher ist es sinnvoll davon auszugehen, dass es auch schädliche MCP-Server geben kann. Wer extrem vorsichtig ist, verwendet eine VM für den KI-Assistenten. Während das wahrscheinlich nicht immer nötig ist, sollte der Künstlichen Intelligenz niemals der uneingeschränkte Vollzugriff aufs Dateisystem gegeben werden.

Lokale KI-Modelle

Ein weiteres interessantes Thema sind lokale KI-Implementierungen. Whisper (Modell zur Transkription von Audio zu Text) ist ein gutes Beispiel für ein Modell, das sogar auf der CPU läuft und keine starke GPU mit viel VRAM braucht. Wenn man aber ein LLM lokal betreiben möchte, können schnell die Grenzen der Consumer-Hardware erreicht werden – insbesondere, weil die kleineren Modelle meistens für Arbeiten wie Entwicklung unzureichend sind. Aus meiner Erfahrung sind LLM-Modelle mit weniger als 11B Parametern hier nicht sehr hilfreich.

Schnelle Generierung lokaler Tools

Der Nebeneffekt der KI-Assistenz für Entwickler ist, dass wir uns nun sehr schnell lokale Werkzeuge für spezifische Anwendungsfälle generieren können: LLMs sind am besten dafür geeignet, Text zu produzieren – sie können Texte aber auch analysieren. Somit war es sehr einfach, ein Tool zu schreiben, was meine eigenen Texte analysiert und ein abstraktes, anonymisiertes Profil daraus erstellt, welches ich wiederum verwenden kann, um per KI Texte in meinem Stil zu schreiben, ohne dass ich der KI meine tatsächlichen Textquellen zur Verfügung stellen muss. Die Analyse und Erstellung des Profils erfolgt über ein kleines, lokales Nova-LLM, wodurch keine Bedenken bezüglich Privatsphäre entstehen.

Da Claude Desktop keine Bildgenerierung wie ChatGPT über DALL-E unterstützt, habe ich mittels Claude Code einen MCP-Server für Flux entwickelt, ein Open-Source-Bildgenerierungsmodell. Nun kann ich wie bei ChatGPT direkt in Claude Desktop Bilder generieren. Claude Code kann hier sowohl den MCP- Server selbst schreiben als auch direkt in seine eigene Konfiguration einbinden, wodurch anschließend ein Neustart des Tools ausreicht, um den MCP-Server zu nutzen.

Fazit

Zusammenfassend lässt sich sagen, dass ich KI regelmäßig als Entwicklungsassistent verwende, allerdings auch noch selbst entwickle – je nachdem, wie es für den Anwendungsfall Sinn ergibt. Generierung von Boilerplate / Scaffolding ist mit KI deutlich schneller – Updates von z. B. Angular Anwendungen sind meistens noch manuell schneller erledigt, weil dort oft noch Inkompatibilitäten zwischen Peer Dependencies existieren, die man auflösen muss. Das kann die KI auch, braucht aber länger als ein erfahrener Entwickler.


Food for your brain!
Du möchtest noch mehr Beiträge rund um IT, KI und digitale Transformation lesen?
Dann melde dich zu unserem Contentletter an. Er erscheint quartalsweise, bleibt angenehm kompakt und bringt dir die wichtigsten Impulse direkt ins Postfach, ganz ohne E-Mail-Flut.

Anmeldung zu unserem Contentletter

Stay connected!
Was uns gerade bewegt, woran wir arbeiten und welche Themen relevant
werden, teilen wir auf LinkedIn.

Folg uns für mehr Einblicke

Das könnte Dich auch noch interessieren

RAG und Embeddings: Die unsichtbaren Helfer hinter intelligenten KI-Systemen – einfach erklärt

RAG und Embeddings: Die unsichtbaren Helfer hinter intelligenten KI-Sy...

RAG und Embeddings sind die unsichtbaren Helfer, die moderne KI-Systeme so leistungsfähig machen. Sie ermöglichen es, dass KI nicht nur ...
Von der Idee zum Artikel: Wie KI meine App baut und darüber schreibt (1/3)

Von der Idee zum Artikel: Wie KI meine App baut und darüber schreibt (...

Hattet ihr schon man das Gefühl, Dinge zu unterschätzen? Aber nicht genau zu wissen warum? Dies habe ich mich gefragt ...
KI am Arbeitsplatz

KI am Arbeitsplatz

"Wer keine internen Regelungen vorgibt, ob und wie generative KI im Arbeitsalltag eingesetzt werden darf, kann davon ausgehen, dass sich ...