GraphQL: Mit KI in 25h statt 80h
Mein Praxistest mit 5 KI-Coding-Assistenten

Einleitung
Wie gut sind Coding Agenten wirklich in der Praxis?
Das Ergebnis?
Die Studie war nach 25 Stunden fertig – mit 5.600 Zeilen generiertem Code.
Schnell bedeutet nicht automatisch schnell produktionsreif.
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
- 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)
- 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
- 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)
- 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
- 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:
- Download: req-01-base-arch-test.md [854 Zeilen]
Projekt Frontend:
Projekt Backend:
Projekt Code:
Claude Code:
Gemini CLI:
GitHub Copilot für VSCode:











