KI-gestützte Entwicklungswerkzeuge versprechen erhebliche Produktivitätsgewinne. Die Marketing-Aussagen reichen von „Code schreibt sich von selbst“ bis „Jeder kann jetzt Software entwickeln.“ Um diese Versprechen gegen die Realität zu prüfen, habe ich zwei Wochen lang Claude Code mit echten Aufgaben aus dem Arbeitsalltag getestet. Keine Demo-Projekte, keine vorbereiteten Beispiele. Vier Use Cases, aufsteigend in der Komplexität.

Ausgangssituation und Setup

Das Setup war bewusst minimalistisch. Claude Code ohne IDE-Integration, ohne Plugins, nur Terminal und KI. Die Idee dahinter war einfach. Wenn das Tool unter diesen Bedingungen brauchbare Ergebnisse liefert, kann es mit besserer Integration nur besser werden.

Meine Ausgangshaltung war skeptisch. KI-Tools in der Softwareentwicklung gibt es seit einigen Jahren, und bisherige Erfahrungen mit Code-Generierung waren ernüchternd. Gleichzeitig war klar, dass sich in den letzten Monaten technisch viel bewegt hat. Ein ehrlicher Test war überfällig.

Use Case 1: Python-Skript ohne Vorgaben

Die erste Aufgabe war bewusst einfach gewählt: ein Automatisierungsskript für eine interne Aufräumaufgabe. Unsere Software-Repositories waren über die Jahre angewachsen, die vorhandenen Bereinigungswerkzeuge reichten nicht aus und manuelles Aufräumen war zeitaufwändig.

Die Aufgabe an die KI: Ein Skript entwickeln, das den Bestand analysiert und eine kontrollierte Bereinigung ermöglicht. Ohne technische Vorlage, ohne detaillierte Vorgaben.

Das Ergebnis war überzeugend. Die KI hat die relevante Dokumentation eigenständig berücksichtigt, ein strukturiertes Skript geschrieben und Sonderfälle behandelt, die nicht explizit spezifiziert waren. Für diese Aufgabe hätte ein Mitarbeiter ohne Spezialkenntnisse mehrere Tage gebraucht. Die KI hat einen funktionierenden ersten Entwurf in unter einer Stunde geliefert.

Einschränkung: Das Ergebnis war funktional, aber nicht nach unseren internen Standards strukturiert. Qualitätssicherung und Anpassung an die Projektkonventionen mussten nachgearbeitet werden. Das ist erwartbar, wenn die KI den Unternehmenskontext nicht kennt.

Use Case 2: Landingpage mit Design und Text

Der zweite Test ging bewusst aus dem Technik-Bereich heraus. Für ein internes Produkt brauchten wir eine Landingpage. Der Content existierte verstreut in Word-Dokumenten, PowerPoint-Folien und Textdateien. Die technische Vorgabe: Die Seite muss sich in die bestehende WordPress-Website einfügen.

Als Softwareentwickler denken wir in Workflows, Daten und Algorithmen. Visuelles Design und Marketing-Texte sind eine andere Disziplin. Genau das machte die Aufgabe interessant.

Claude hat aus dem Rohmaterial eine funktionsfähige HTML/CSS-Seite gebaut. Das responsive Layout war sauber, die Struktur logisch. Der generierte Marketing-Text war inhaltlich korrekt und als Ausgangsbasis brauchbar, allerdings stilistisch generisch, erkennbar maschinell formuliert. Das visuelle Ergebnis war ein solider erster Entwurf, den ein Designer in wenigen Stunden zu einem professionellen Ergebnis hätte verfeinern können.

Die Erkenntnis aus diesem Test ist klar. KI kann interdisziplinäre Aufgaben überbrücken, aber nicht ersetzen. Der generierte Output ist ein Startpunkt, kein Endprodukt.

Use Case 3: Change Request in bestehendem Projekt

Der dritte Test war der eigentlich relevante: ein typischer Change Request in einem bestehenden, komplexen Softwareprojekt. Ein Dashboard sollte um ein weiteres Chart ergänzt werden. Keine besonders anspruchsvolle Aufgabe, aber eingebettet in eine gewachsene Codebasis mit projektspezifischen Konventionen, Bibliotheken und Architekturmustern.

Hier zeigte sich der entscheidende Unterschied zu den ersten beiden Tests. Ein einfacher Prompt reichte nicht mehr aus. Die KI brauchte umfangreichen Kontext zur Projektstruktur, zu den bestehenden Architekturmustern und zu den internen Qualitätsstandards. Je präziser das Briefing, desto besser das Ergebnis.

Die Arbeit wurde zu einem iterativen Prozess. Beschreiben, Ergebnis prüfen, nachsteuern, erneut prüfen. Kein „Wunsch rein, Lösung raus“, sondern ein Sparring, bei dem die KI den Code-Entwurf liefert und der Entwickler die fachliche und architektonische Bewertung übernimmt.

Das Ergebnis war nach drei Iterationen produktionsreif. Der Zeitgewinn gegenüber der manuellen Entwicklung war vorhanden, aber geringer als bei den ersten beiden Use Cases. Der Aufwand verschiebt sich: weniger Tippen, mehr Prüfen und Steuern.

Use Case 4: Vom Anforderungsdokument zur Anwendung

Der ambitionierteste Test: Claude erhielt ein vollständiges Anforderungsdokument, wie wir es als Basis für ein mehrmonatiges Kundenprojekt verwenden würden.

Der erste Schritt war beeindruckend. Claude analysierte das Dokument und stellte Rückfragen, die fachlich präzise und relevant waren. Abhängigkeiten zwischen Anforderungen wurden erkannt, implizite Annahmen hinterfragt. Als Vorbereitung einer Analysephase war das ein echtes Produktivitätswerkzeug.

Bei der anschließenden Implementierung wurde es realistisch. Die generierte Anwendung war funktional im Sinne von „die Grundfunktionen laufen“. Aber es fehlten Aspekte, die eine produktionsreife Anwendung ausmachen: Sicherheitskonzepte, Belastbarkeit unter realen Nutzerzahlen und Architekturentscheidungen, die langfristige Wartbarkeit sicherstellen. Die KI hat das umgesetzt, was explizit im Dokument stand. Die impliziten Anforderungen, die ein erfahrener Entwickler aus dem Kontext ableitet, fehlten.

Das bestätigt die grundsätzliche Einschätzung: KI kann Code produzieren. Aber Code ist nicht Software. Software entsteht durch die Verbindung von Code mit Architekturwissen, Sicherheitsbewusstsein, Betriebserfahrung und Kundenverständnis.

Einordnung nach zwei Wochen

Die zwei Wochen haben ein differenziertes Bild ergeben.

Wo KI-Werkzeuge echten Mehrwert liefern: Bei klar abgegrenzten Aufgaben mit geringem Kontextbedarf wie Skripten, Utilities und Prototypen. Beim Überbrücken von Wissenslücken in angrenzenden Disziplinen wie Design und Textarbeit. Bei der Analyse und dem Verständnis von Anforderungsdokumenten. Bei der Code-Generierung als Startpunkt für erfahrene Entwickler, die den Output bewerten und verfeinern können.

Wo die Grenzen liegen: Bei komplexen Änderungen in bestehenden Systemen ohne umfangreichen Kontext. Bei Architekturentscheidungen mit langfristigen Auswirkungen. Bei allem, was implizites Wissen über den Kunden, das Geschäft oder die Betriebsumgebung erfordert. Und bei der Frage, ob eine Lösung nicht nur funktioniert, sondern auch die richtige Lösung für das Problem ist.

Was sich für die tägliche Arbeit ändert: Weniger Zeit für syntaktische Arbeit, mehr Zeit für Architektur, Review und Kommunikation. Die Rolle des Entwicklers verschiebt sich vom Code-Schreiber zum Code-Steuerer. Das erfordert nicht weniger Erfahrung, sondern mehr. Wer den KI-Output nicht beurteilen kann, erzeugt technische Schulden, ohne es zu merken.

Fazit

KI-gestützte Entwicklung ist ein reales Produktivitätswerkzeug für erfahrene Entwickler. Für Einsteiger ohne Beurteilungskompetenz ist sie ein Risiko. Die Versprechen der Tool-Anbieter sind übertrieben, die tatsächliche Wirkung ist trotzdem erheblich. Entscheidend ist nicht das Werkzeug, sondern die Erfahrung des Menschen, der es einsetzt.