Wie weit kann man mit Vibe Coding bei der Entwicklung kommen?

Dies ist ein Rückblick auf Eindrücke von der Technik- und Implementierungsseite, nicht so sehr auf das Produkt selbst.

Das sind vollständig persönliche Gedanken.

Bitte berücksichtigt, dass es sich um ein Projekt handelt, das ich im 4. Studienjahr während des Semesters lernend entwickelt habe!

Warum ich dieses Projekt gestartet habe

• Produktentwicklung mit der Mentalität, ein Startup zu gründen, aus PM-/PO-Perspektive
• Prüfen, ob mit Claude Code wirklich die Entwicklung eines Full-Stack-MVP möglich ist
• Das Problem der Aktienauswahl bei Investitionen lösen
• Kommerzielle Produkte aktiv einführen und dabei Erkenntnisse aus dem Prozess gewinnen

Projektzeitplan und zusätzliche Informationen

• Planung + Entwicklung: 1 Monat
• Deployment: 1 Woche
• Betrieb: 2 Monate
• Investitionssumme
  • Claude Code: 100 USD
  • Apple-Entwicklerkonto: 100 USD
  • AWS: ca. 220 USD
  • Managed DB: ca. 300 USD
  • Free Tier: Datadog, Langfuse, Posthog
  • Werbung: 40.000 KRW
  • Gesamt: ca. 1.000.000 KRW (mein eigenes Geld..)

Entwicklungsprozess

Frontend

• Definition von Design Tokens
• Umsetzung von drei Kernseiten in Figma
• Design Tokens in Expo angewendet und mit Figma MCP umgesetzt
• Ich habe versucht, Expo MCP zu verwenden, aber da es nicht stabil war, habe ich direkt am Ergebnis debuggt
• Mit einem Prompt wie „Verwende Design Tokens und übernimm das Designkonzept anderer Seiten …“ neue Seiten ohne Figma-Wireframe erstellt

Backend

• Gebeten, auf Basis der Anforderungen APIs zu entwickeln
• Gebeten, auf Basis der Frontend-Anforderungen auch die benötigten Endpunkte mit zu erstellen
• Mit einem allgemeinen Stack wie Django war die eigentliche Implementierung ohne Engpass mit Claude Code möglich

AI

• Gebeten, eine Multi-Agent-Architektur zu definieren und auf dieser Basis zu implementieren
• Zur Berücksichtigung aktueller LangChain- und LLMOps-Spezifikationen Weblinks angehängt
• Prompts für den LLM-Service durch ein LLM erzeugen und verwenden lassen

Observability

• Aufbau auf ClickStack-Basis und anschließend Migration zu Datadog
• Logging und Analytics nach der Entwicklung des Gesamtsystems angewendet

Infra

• Ich wollte anfangs Pulumi verwenden, aber da Claude Code darin nicht gut war, habe ich Deployment-Dateien über AWS-CLI-basierte Skripte erstellt
• Aus Kostengründen weder CI/CD noch Dev Server aufgebaut

Liste der eingesetzten Technologien

• Service: Abonnement/Zahlung, Social Login, Dark Mode
• Daten: API-basierte Datenerfassung, CDC, ETL
• AI: Multi-Agenten, Text-to-SQL, Agentic RAG, SSE-Streaming, Session-Management, Retry, Rate Limit
• LLMOps: A/B-Test, Cloud Based Prompt Management (OTA Update), Synthetic Dataset, Evaluation

Erkenntnisse

Implementierung

• Mit dem 100-USD-Plan von Claude Code konnte ich etwa einen Monat lang allein ein Produkt dieses Umfangs bauen
• Ich habe die UI nur durch Definition der Design-Token-Spezifikation umgesetzt. Hätte ich zusätzlich ein Design-System implementiert und in Claude.md verankert, hätte ich vermutlich ein schnelleres und stabileres Frontend entwickeln können
• Die Bedeutung eines Design-Systems: Es steigert die Produktivität in der Frontend-Entwicklung enorm. Statt Figma auszuarbeiten, ist es schneller, erst zu implementieren und dann zu korrigieren. Tatsächlich gibt es Seiten, die implementiert sind, aber in Figma gar nicht existieren.
• Definition von Ausnahmefällen: Besonders wichtig in mobilen Apps und AI-Systemen. Man muss Fälle außerhalb des Happy Path planen und umsetzen, etwa systemweite Timeout-Verwaltung, Background-Richtlinien, Wiederherstellung von Streaming und einfache Fehler. Claude Code implementiert Fehlerbehandlung manchmal von selbst, löst sie aber nicht elegant integriert über Frontend und Backend hinweg. Deshalb muss man solche Punkte zusätzlich an Claude Code herantragen.
• Groß angelegtes Refactoring ist tabu. Anfangs hatte ich React- und CSS-Code in einer einzigen Frontend-Datei, wollte das später auftrennen und habe ein Refactoring versucht. Das ist letztlich gescheitert. Zwar wurde getrennt, aber die UI unterschied sich anschließend vom ursprünglichen Zustand, und am Ende musste ich sie schrittweise zerlegen. Es scheint nötig zu sein, sich schon früh Gedanken über die Code-Architektur zu machen und bei Nutzung von Komponenten entsprechende Hinweise in den Prompt aufzunehmen.
• Nutzung von Claude.md: Nach der Entwicklung einer Funktion habe ich Claude Code gebeten, Inhalte vorzuschlagen, die auf Basis dessen in Claude.md gespeichert werden sollten. Als die Datei immer größer wurde, habe ich verlangt, nur das wirklich Nötige zu behalten und den Rest zu entfernen. README und Claude.md habe ich passend eingesetzt, um den LLM-Kontext zu steuern. (Aus der Zeit vor Skills)
• Sub-Agenten habe ich nicht genutzt. Es lief auch ohne gut genug, daher habe ich sie nicht verwendet. Ich habe im Plan-Modus einfach so lange nachgefragt, bis die Entwicklungsplanung konkret genug war, und dann den Agenten autonom entwickeln lassen.
• Pakete und Technologien sollte man am besten im Voraus festlegen und mitteilen. Wenn man in Claude.md, im README oder in einer bestimmten Spezifikation genau festhält, womit gearbeitet werden soll, verhindert man redundanten Code oder die Nutzung eines anderen Stacks. (Skills?)

AI-System

• ReAct ist langsam. Die UX ist miserabel. Obwohl ich Multi-Agenten parallel ausführen ließ, war es immer noch viel zu langsam.
• UX: Um langsame Antworten abzufedern, habe ich UX für Multi-Agent-Schritte, Streaming, Animationen und dynamisches Markdown-Rendering eingeführt. Aber wenn eine Antwort eine Minute dauert, was bringt das dann noch? … (B2C-App)
• Cloud-basiertes Prompt- und Tool-Schema-Management: Der Vorteil ist, dass es in einer Online-Umgebung direkt angewendet werden kann. Ich halte das inzwischen für unverzichtbar und liebe Langfuse.
• Bei Text-to-SQL muss das Schema in den Prompt. Das frisst allerdings sehr viel Kontext. Das ließe sich vermutlich mit Fine-Tuning oder RAG lösen.
• Evaluation und Iteration: Ich habe für verschiedene User-Personas Synthetic Datasets aufgebaut und mit LLM-as-a-Judge evaluiert. Ich würde das gern automatisieren, aber allein fehlen dafür letztlich die Entwicklungsressourcen.
• Bewertungsmetriken und Rubriken: schwieriger als gedacht. Allgemeine Metriken sind aus meiner Sicht so etwas wie DAU und MAU. Daraus lassen sich aber keine echten Erkenntnisse ableiten. Man muss je nach Fall Metriken definieren, Low-Quality-Fälle unterscheiden, diese beheben und iterieren. Am Ende braucht man ein System, das dabei hilft, gute Custom Metrics zu erstellen. (Und Multi-Turn?..)
• Das OpenAI-Tier ist enger als gedacht. In niedrigen Tiers kann man gute Modelle nicht im Betrieb nutzen.

Infrastruktur

• AWS ist teuer, Managed DB ist teuer. Gut ist es schon, aber ich bereue es
• ClickHouse ist sehr teuer, aber gut. Mit Managed ist es bequem, vor allem weil auch CDC direkt dabei ist. (Was bringt Geschwindigkeit, wenn das LLM langsam ist?)
• Qdrant und Redis Cloud sind auch nicht schlecht. Der Aufbau dauert nicht lange, und die Kosten sind niedrig.
• Datadog: sehr gut. Allerdings voraussichtlich teuer, deshalb habe ich nur den Free Tier genutzt. Besonders gut ist die Funktion, aufgetretene Fehler separat zu sammeln und zu melden. Ich habe den Agenten als Sidecar in ECS eingebunden.

Service

• Zahlung und Abonnement: Ich hatte überlegt, Toss Pay zu nutzen, habe es aber nicht getan. Es gibt zunächst eine Jahresgebühr, und da es keine React-Native-Dokumentation gibt, ist auch das SDK nicht besonders gut. Das war eine große Enttäuschung. Letztlich habe ich mich für NICE Payments entschieden. Es gibt keine Jahresgebühr und auch einen Entwicklungsserver, sodass die Entwicklung ganz ordentlich möglich war.
• Apple-Zahlung: Ich habe NICE Payments verwendet, aber es gibt Probleme. Apples Zahlungsrichtlinien sind heikel. Während der iOS-Entwicklung gab es Policy-Probleme mit Apple, und es brauchte verschiedene Dokumente sowie UI-seitige Lösungen. Wahrscheinlich ist es am entspanntesten, einfach Apples internes Zahlungssystem zu verwenden.
• Zahlung und Abonnement (automatische Abbuchung) sind nicht dasselbe. Um automatische Zahlungen umzusetzen, braucht man Scheduling-Infrastruktur und muss sich auch um die Sicherheit beim Speichern von Karten-Schlüsseln kümmern. Ich habe es am Ende zwar implementiert, aber es war schwieriger als gedacht. Dabei kam mir der Gedanke, Stripe ausprobieren zu wollen.
• Push-Benachrichtigungen: Lassen sich mit Expo bequem aufbauen. Letztlich braucht man ein Backoffice, um Nachrichten zu versenden, aber ich halte es für eine essenzielle Funktion.

Gedanken

• Die Bedeutung von Software-Design-Patterns und Architektur wird wohl zunehmen.
• Ich würde mir wünschen, dass mehr Menschen sich dafür interessieren, mit Coding-Agenten Ergebnisse zu schaffen, die über Toy-Projekte hinausgehen.
• Vermeiden wir Overengineering. Aber muss man für den Berufseinstieg nicht trotzdem auch Overengineering kennen? Vielleicht ist es beim nächsten Mal besser, einfach alles auf einer Instanz mit docker-compose zu beenden … (mit Supabase?)
• Das Zeitalter des Solo-Startups ist fast da. Aber Geld zu verdienen und etwas zu bauen sind aus meiner Sicht zwei verschiedene Dinge.
• Allein zu arbeiten macht keinen Spaß
• Auch Linear ist als Alternative zu Jira brauchbar. Da ich es zum ersten Mal genutzt habe, weiß ich allerdings noch nicht gut, wie man Tickets nach Hierarchie gebündelt ansieht.

Ergebnis

• Das Projekt wurde beendet, weil ich die Serverkosten nicht tragen konnte.
• Kontostand -100

Referenz

Ab Folie 4 gibt es zusätzliche Inhalte.

https://figma.com/deck/wsGLEmFYOUPUheWBl1t23K/…