GraphQL: Mit KI in 25h statt 80h

Mein Praxistest mit 5 KI-Coding-Assistenten

Magier mit Coding Agenten Pferden
Einleitung

Das Thema KI-Coding-Assistenten ist längst nicht mehr nur ein Experiment für Early Adopters. Seit Anfang an nutze ich GitHub Copilot im täglichen Workflow, und die Entwicklung hat sich seitdem noch einmal massiv beschleunigt. Aus simplen Code-Vorschlägen sind mittlerweile autonome Agenten geworden, die ganze Features implementieren können.

Die Frage ist nur:
Wie gut sind Coding Agenten wirklich in der Praxis?

Für eine technische Machbarkeitsstudie hatte ich mir also 40 Stunden Zeit geblockt. Das Ziel: GraphQL Subscriptions für Multi-User-Synchronisation evaluieren, Redis als Lock-Store testen und Postgraphile als GraphQL-Backend ausprobieren. Alles Themen, bei denen man normalerweise erst einmal durch Dokumentationen wühlt, Dependency-Probleme löst und sich durch Boilerplate-Code kämpft.

Stattdessen habe ich beschlossen, das Projekt komplett KI-gestützt anzugehen. Nicht nur mit einem Tool, sondern mit fünf verschiedenen: Claude Code, Codex CLI, Gemini CLI, und GitHub Copilot in verschiedenen Varianten.

Das Ergebnis?
Die Studie war nach 25 Stunden fertig – mit 5.600 Zeilen generiertem Code.

Aber der Weg dorthin war alles andere als geradlinig. Jedes Tool hatte seine Stärken, seine blinden Flecken und seine Macken. Und während ein Tool ein Problem in 30 Minuten elegant gelöst hat, verbrannten andere dabei stundenlang ihr Nutzungskontingent ohne Erfolg.

Die zentrale Erkenntnis auch hier:
Schnell bedeutet nicht automatisch schnell produktionsreif.

Was folgt, beschreibt zunächst kurz und am Ende detailliert meine persönlichen Erfahrungen in und aus diesen zwei Wochen. Viel Spaß dabei.

Formale Ziele der Studie


  • Evaluierung von KI-Coding-Assistenten für die Projektentwicklung
  • Begrenzung von Zeit- und Kostenrisiken
  • Technischer Nachweis für GraphQL Subscriptions zur Multi-User-Synchronisation
  • Test von Redis als Lock-Handle Store
  • Prüfung von Postgraphile als GraphQL-PostgreSQL-Schnittstelle
  • Bewertung der Usability bei Multi-User-Editing mit Locks

Ergebnisse


Die Studie konnte mit KI-Unterstützung in 25 statt am Ende eingeschätzten 80 Stunden abgeschlossen werden, bei monatlichen Tool-Kosten von etwa 50€. Technisch wurden die Machbarkeitsnachweise für GraphQL Subscriptions, Redis als Lock-Store und Postgraphile erfolgreich erbracht. Dabei entstanden rund 5.600 Zeilen generierter Code durch den Einsatz von fünf verschiedenen Coding-Assistenten. Die Tools zeigten jedoch unterschiedliche Nutzungslimits und Problemlösungsfähigkeiten – insbesondere beim Lösen einer eher artfremden Benutzerbindung zwischen Frontend und Backend stießen mehrere Assistenten an ihre Grenzen.

 
Zentrale Erkenntnis:

Unter Nutzung von verschiedenen Agenten und Modellen erfüllt der erzeugte Code zwar alle Anforderungen der Studie, ist darüber hinaus aber noch nicht produktionsreif.

Eingesetzte Tools (Modelle):
  • Claude.ai (Sonnet 4.5 über Web-Interface)
  • Claude Code (Sonnet 4.5)
  • Codex CLI (GPT-5-Codex)
  • Gemini CLI (Gemini 2.5 Pro / Gemini 2.5 Flash)
  • GitHub Copilot für VSCode (GPT-5, Grok-Code-fast-1 preview)

Projektumfang:
  • Basis: ca. 500 Zeilen Projektstruktur
  • Hinzugefügt: ca. 5.600 Zeilen generierter Code
  • Komponenten: Podman-Infrastruktur (Postgres/Redis), Taskfile-Konfigurationen, Vue.js Frontend, Node.js Backend

Nutzungslimits:
  • Claude Code: 5h/Tag (Sonnet 4.5) – bei Erreichen blockierte auch claude.ai für ca. 6h
  • Codex CLI: 5h/Tag (GPT-5-Codex)
  • Gemini CLI: 102 Anfragen (Gemini 2.5 Pro), danach bis 900 mit Gemini 2.5 Flash pro Tag
  • GitHub Copilot: 2/100 Premium-Anfragen verbraucht (GPT-5), unbegrenzt (Grok-Code-fast-1 preview)

Positive Erkenntnisse:
  • Entkopplung von technischen Details reduziert Ermüdung deutlich
  • Fertigstellung in 25 Stunden statt geschätzter 80 Stunden
  • Diverse Lösungsansätze und Ideen bereichern den Entwicklungsprozess

Probleme und Limitierungen:
  • Neues Paradigma (Spezifikation → Agent → Feedback) erfordert Umdenken
  • Bug-Fixing verbraucht den Großteil der Zeit und Kontingente
  • Package Version Matching konnte von Claude Code nicht gelöst werden
  • Ein einzelner Agent/CLI reicht nicht aus
  • Generierter Code ist noch nicht produktionsreif
  • 40h Aufwandsabschätzung war zu optimistisch, 80h waren eher realistisch

Entwicklungsbericht

Projektstart und Anforderungsanalyse

Die Studie begann mit einer gemeinsamen Anforderungsanalyse zusammen mit claude.ai. Aus den initialen Ideen wurde ein strukturiertes Anforderungsdokument entwickelt, das als Basis für die weitere Umsetzung diente.

Basisprojekt-Struktur

Die Grundlage bildete ein bereits existierendes Projekt, aus dem die relevante Struktur extrahiert wurde. Diese Basis wurde bewusst nur minimal an die Studienziele angepasst – fehlende Verweise, Ordner und Dateien wurden in Kauf genommen. Claude Code übernahm anschließend das Aufräumen, Fixen und die Anpassung der Struktur an die konkreten Anforderungen der Studie.

Erste Implementierung mit Claude Code

Aus dem Anforderungsdokument und der bestehenden Projektstruktur entwickelte Claude Code die erste funktionsfähige Version. Dabei hielt er sich nicht zu 100% an die Verzeichniskonventionen für Podman-basierte Infrastruktur, richtete diese aber nach Anweisung korrekt ein. Die studienspezifischen Tasks wurden entsprechend der Vorlage angelegt und kontinuierlich verfeinert. Frontend und Backend wurden generiert und um Paket-Update-Mechanismen erweitert. Allerdings traten Probleme bei der Auflösung von Paketabhängigkeiten für Apollo Client auf – diese konnte Claude Code trotz mehrfacher Versuche nicht vollständig lösen.

Das Frontend

Als Teil der Lösung entstand ein Vue.js Single-Page-Application Frontend mit Apollo Client. Die Anwendung präsentiert sich auch ohne zusätzliches CSS-Framework optisch ansprechend mit drei Tabs, die den Studienzweck verdeutlichen. Ein Tab implementiert den Multi-User-Test, bei dem selektiv auf fünf Datenbank-Zeilen zugegriffen werden kann. Die Simulation ermöglicht 2-4 Benutzer, die jeweils fünf Stammdatenfelder anzeigen und bearbeiten können.

Das zentrale Problem: Multi-User-Identifikation

Hier begann der eigentliche Härtetest für die KI-Assistenten. Claude Code scheiterte trotz stundenlanger Versuche daran, die drei im Frontend simulierten Benutzer als drei unterschiedliche Benutzer an das Backend zu übertragen. Das Problem: Der HTTP-Header x-user-id:1 blieb konstant, unabhängig vom ausgewählten Benutzer.

Auch Codex CLI konnte das Problem nicht lösen und verbrauchte dabei sein gesamtes 5-Stunden-Kontingent des Tages. Gemini CLI beeindruckte zunächst mit vortrefflichem Bug-Tracking – es erzeugte sogar gezielt Fehler, um Hypothesen zu prüfen. Doch auch hier waren die etwa 100 Anfragen für Gemini 2.5 Pro schnell aufgebraucht, ohne Erfolg. Gemini 2.5 Flash kam schließlich zu dem Schluss, dass der Fehler nicht in der vom Agenten änderbaren Codebasis liegt, und gab auf.

GitHub Copilot mit GPT-5 erhielt nur zwei Versuche, da ich nicht alle Premium-Anfragen für ein einzelnes Problem aufbrauchen wollte, auch wenn es in diesem Fall studien-entscheidend war. Dabei versuchte sich Copilot mit den gleichen erfolglosen Änderungen wie zuvor Codex und Claude Code.

 

Die überraschende Lösung

GitHub Copilot mit Grok-Code-fast-1 preview löste das Problem dann überraschend innerhalb von etwa 30 Minuten – ohne eine einzige Premium-Anfrage zu verbrauchen. Den Rest der Implementierung stellte ich mit GitHub Copilot und Grok-Code-fast-1 preview soweit fertig, dass die Studienziele in zwei Dritteln der ursprünglich veranschlagten Zeit erreicht wurden.


Anhang: Projekt Details & Links

Projektstart und Anforderungsanalyse:

Projekt Frontend:

 

Projekt Backend:

Projekt Code:

Claude Code:

 
Codex CLI:

Gemini CLI:

 

GitHub Copilot für VSCode: