Claude Opus 4.5 im Praxistest: Strava-Analytics-App aus Entwicklersicht

Kann Opus 4.5 wirklich vollständige Apps ohne Iteration erstellen? Der Hype ist groß, meine Skepsis als Developer auch. Um das zu testen, habe ich Opus 4.5 eine Webapp programmieren lassen, die meine Strava-Daten von 2025 zusammenfasst und visualisiert – nachdem Strava den Jahresrückblick hinter eine Paywall gesetzt hat. Aber das ist ein anderes Thema.

TLDR

Opus 4.5 lieferte nach einer strukturierten Planungsphase einen funktionierenden Prototypen in wenigen Stunden. Beeindruckend. Allerdings: OAuth-Flow fehlerhaft implementiert, falsches Jahr berechnet, Code-Qualität verbesserungswürdig. Das Modell brachte mich auf etwa 80% des Weges – die letzten 20% erforderten klassisches Debugging und manuelle Korrekturen. Für einfache Greenfield-Projekte ist Vibe Coding ein Produktivitäts-Boost, aber ohne erfahrene Entwickler, die den Output validieren und verfeinern, bleibt es ein Werkzeug mit Grenzen.

Coding mit LLM/AI

Seit dem großen AI-Boom nutze ich LLMs als Hilfsmittel in der Softwareentwicklung: in der IDE (VSCode + Cursor), in den Webapps (ChatGPT, Claude) und in der Kommandozeile (Claude Code CLI). Dabei habe ich stets die Entwicklungen verfolgt, MCP Server eingebunden (z.B. Context7 für Dokumentation), Agenten erstellt und System Prompts geschrieben, um kontextspezifisch Probleme zu lösen.

Meine Erfahrung: Diese Werkzeuge sind extrem hilfreich, um Ideen zu diskutieren oder Konzepte zu erarbeiten – vor allem in neuen Umgebungen oder mit unbekannten Frameworks. LLMs haben meine Arbeitsweise positiv verändert und ermöglichen mir, schneller und präziser Features zu entwickeln.

Allerdings habe ich die AI nie blind Code committen lassen. In komplexeren Projekten und Mono-Repos, wo mehrere Module ineinandergreifen, verstanden die LLMs selten sämtliche Zusammenhänge. In solchen Situationen musste ich konkreten Kontext aufbauen und genau diese Vertikale diskutieren – LLM als Rubberduck, nicht als autonomer Entwickler.

Aber vielleicht ist es an der Zeit, diese Meinung zu hinterfragen. Die Geschwindigkeit, mit der sich dieses Feld vorwärts bewegt, ist bemerkenswert. Wenn man den Stimmen in unserer Industrie glaubt, sind wir nur noch einen Steinwurf von AGI entfernt. Bei Letzterem bin ich skeptisch – aber dennoch neugierig, wie es mit der Zunft der Softwareentwickler mittelfristig weitergeht.

Das Experiment

Das Ziel: Eine Webapp erstellen, die Strava-Aktivitäten von 2025 zusammenfasst und visualisiert. Der Hintergrund: Strava hat den Jahresrückblick hinter eine Paywall gesetzt, nur Premium-Mitglieder erhalten diese Info. Auch Apple bietet keine Jahresübersicht aller Aktivitäten. Also: Problem identifiziert, Lösung gesucht.

Für die Entwicklung verwendete ich Claude Code im Terminal mit Opus 4.5 innerhalb meines Pro-Plans.

Erstelle einen Plan

Im Planungsmodus diskutierte ich mit Opus die Aufgabenstellung und die Vorgehensweise: OAuth-Autorisierung, relevante Strava-APIs, Laden der Aktivitätsdaten. Nach Autorisierung durch den Benutzer sollten dessen Aktivitäten gelesen und entscheidende Merkmale (Art, Datum, Distanz, Dauer, Höhenmeter) numerisch und graphisch präsentiert werden.

Technologisch hatte ich eine Anforderung: Frontend und Backend in TypeScript. Die Wahl der Frameworks ließ ich bewusst offen. Den Plan sollte das Modell im Markdown-Format speichern, um die Entwicklung mit dem richtigen Kontext fortführen zu können. Außerdem sollte der Plan in Phasen unterteilt werden – Schritt für Schritt implementieren, anstatt das Modell mit zu viel Freiheit loslaufen zu lassen.

Fazit: Die Planung lief erstaunlich reibungslos. Viele Entscheidungen wurden auf Anhieb korrekt eingeplant, nur manche Details benötigten weiteren Feinschliff. Auch ohne den folgenden Vibe-Coding-Schritt ein durchaus sinnvoller Einsatz von LLMs.

Vibe Coding

Nach Fertigstellung des Plans wechselte ich in den Auto-Accept-Modus von Claude Code und implementierte Schritt für Schritt alle acht Phasen mit jeweils einem Prompt: implement phase X. Da Claude Code das Projekt jederzeit kompilieren und Fehlermeldungen auslesen kann, war es möglich, alle Phasen mit minimalem Input umzusetzen.

Fazit: Auf den ersten Blick beeindruckend. Die App funktionierte im Großen und Ganzen: Benutzer autorisiert, Strava-Daten geladen, Aktivitäten zusammengefasst und visualisiert. Allerdings war durch die ausschließliche Verwendung des teuren Opus 4.5 Modells an dieser Stelle das Tageslimit meines Pro-Plans erreicht.
Hier das Ergebnis der ersten Vibe Coding Iteration:

Webapp nach der ersten Vibe-Coding-Iteration

Bug Fixing und Features

Bei näherer Betrachtung zeigten sich Probleme:

1. OAuth-Flow fehlerhaft: Die Autorisierung erfolgte bei jedem App-Start, obwohl sie nur einmalig nötig sein sollte. Der Refresh-Token wurde komplett ignoriert – trotz Strava-API-Dokumentation im Kontext. Den korrekten Flow konnte Opus nach weiteren Prompts umsetzen.

2. Strava Scope unzureichend: Mit dem 'read' Umfang der Strava Authorisierung wurden manche Aktivitäten nicht gelesen. Der richtige Scope ist 'read_all'.

3. Falsches Jahr: Das Zeitfenster wurde für 2024 statt 2025 kalkuliert, weil das Modell glaubte, wir befänden uns Anfang 2025. Dieses Phänomen hatte ich kürzlich auch mit Claude Sonnet erlebt – offenbar ein wiederkehrendes Problem mit dem Zeitbewusstsein.

4. UI-Probleme: Die Distanzanzeige zeigte exakte Kilometerwerte nur im Hover, dazu mit schlechtem Farbkontrast (dunkel auf dunkel). Die Darstellung benötigte weitere Prompts.

5. Feature-Anpassung: Radfahren ist für mich nicht relevant, also ließ ich es entfernen und stattdessen Laufen in "Straße" und "Trail" aufteilen. Mehr Prompting, und das nächste Tageslimit erreicht.

Finale Version der Webapp

Code Review

Ein Blick unter die Haube offenbarte weitere Schwächen:

Tech-Stack: React + Next.js mit Server Components + Tailwind CSS. Der klassische LLM-Default-Stack – funktional, aber nicht sonderlich kreativ.

Magic Strings: Begriffe wie "Trail" oder "Street" waren hardcoded statt in einem Dictionary wiederverwendbar abgelegt. Wartbarkeit? Fehlanzeige.

Dead Code: In der Chart-Komponente existierte Code für eine akkumulierte Darstellung von Street und Trail, die nie genutzt wurde. Ein Prop war immer true, weil der entsprechende Use-Case gar nicht existierte.

Unused Components: Das Modell hat insgesamt 5 React Komponenten erstellt, wovon 3 nicht verwendet werden.

Linting ignoriert: Obwohl ESLint installiert war und ein entsprechendes Script existierte, fanden sich ungenutzte Variablen und <a>-Tags statt Next.js' <Link/>-Component.

React-Fehler: Ein klassischer Anfängerfehler – setState wurde synchron innerhalb eines Effects aufgerufen, was zu kaskadierenden Renders führen kann.

CSS Wartbarkeit: Nahezu alles hard-coded und schwer wartbar, geschweige denn responsive.

Secrets: Die API-Credentials lagen in der .env-Datei, wie im Planning definiert. Hier hat das Modell die Sicherheitsanforderungen eingehalten.

Zusammenfassung

Opus 4.5 hat mich beeindruckt. Die Eigenständigkeit, mit der das Modell alle Phasen implementierte, war bemerkenswert. Für einen ersten Prototypen lieferte Vibe Coding eine One-Shot-Lösung, die grundsätzlich funktionierte. Das Modell brachte mich auf etwa 80% des Weges – und das in einem Bruchteil der Zeit, die ich manuell gebraucht hätte.

Aber die Details stimmten nicht. Der Plan sah vor, Daten nur dann von Strava zu laden, wenn sie nicht bereits gecacht waren (Rate Limits im Hinterkopf). In der Implementierung wurden die Daten jedoch jedes Mal neu geladen, obwohl ein Zwischenspeicher im localStorage existierte. Dazu kam: kein Refactoring nach Feature-Änderungen, mittelmäßige Code-Qualität, ignorierte Linting-Fehler.

Wichtig zu beachten: Dieses Experiment fand unter optimalen Bedingungen statt – eine einfache Greenfield-App ohne Legacy-Code oder Komplexität. Das sollte der einfachste Use-Case für LLM-Coding sein. Bei komplexen Legacy-Applikationen befürchte ich, dass Vibe Coding nicht nur wenig bringt, sondern sogar negative Auswirkungen haben könnte.

Der Claude Pro-Plan ist übrigens nur zum Antesten von Opus 4.5 geeignet. Wer ernsthaft damit arbeiten will, braucht mindestens den Max-Plan für 100$/Monat.

Fazit: AI als Werkzeug

LLM-Coding ist beeindruckend und kann Entwicklergeschwindigkeit und -präzision erheblich steigern. Aber wir können uns nicht vollständig auf Vibe Coding verlassen und darauf vertrauen, dass die Maschine alles korrekt erledigt. Senior Engineers, die alle Zusammenhänge innerhalb einer App verstehen, bleiben unverzichtbar – vor allem für komplexere Software und Architekturentscheidungen.

AI ist ein Werkzeug. Wie es eingesetzt wird, bestimmt das Ergebnis. Wie immer werden die fähigsten Entwickler an die Spitze kommen – jetzt eben mit einem mächtigen neuen Instrument im Repertoire. Die Angst vor AI ist fehl am Platz. Die bessere Strategie: Lernen, wann man sie einsetzt und wann nicht.

AI ist gekommen, um zu bleiben – mit oder ohne Bubble. Den Geist bekommen wir nicht mehr zurück in die Flasche. Also nutzen wir ihn.