Von der Werbung zum Engineering: Technische Lektionen aus dem Aufbau von DIALØGUE

*Dies ist der technische Deep-Dive als Begleitung zu meiner DIALØGUE-Einführung. Wenn du noch nicht gelesen hast, was DIALØGUE ist und warum ich es gebaut habe, fang dort an!*

Die Reise: Vom Werbefachmann zum Full-Stack-Engineer

Ok, lass uns das Offensichtliche ansprechen – ja, ich komme aus der Werbung. Ja, Mediapläne und Creative Briefs, keine Datenstrukturen und Algorithmen. Aber hier ist das Lustige: Zu verstehen, wie Systeme funktionieren – sei es ein Marketing-Funnel oder eine verteilte Architektur – erfordert dieselbe analytische Denkweise. Der Unterschied? Im Engineering, wenn du einen Fehler machst, sagt dir der Computer es sofort. Kein Warten auf Kampagnenergebnisse haha.

DIALØGUE zu bauen war… intensiv. Es geht nicht nur darum, Code zu schreiben (obwohl es davon reichlich gab). Es geht darum, ein komplexes System zu entwerfen, das irgendwie mehrere KI-Dienste orchestrieren, asynchrone Workflows handhaben und nicht auseinanderfallen muss, wenn Nutzer unerwartete Dinge tun. Lass mich teilen, was diese Reise mich tatsächlich gelehrt hat – das Gute, das Frustrierende und die „Warum hat mir das niemand gesagt?"-Momente.

Architekturentscheidungen: Warum Komplexität der Feind ist

Hier ist etwas, das niemand sagt, wenn du anfängst: Komplexität ist nicht dein Freund. Das habe ich auf die harte Tour gelernt. Wie wirklich hart. Stell dir vor, ich ertrinke in CloudWatch-Logs und versuche herauszufinden, warum mein wunderschön architektiertes System… nun ja, nicht funktioniert. T.T

Anfangsarchitektur (Übermäßig komplex)

Ich begann also mit LangGraph für die Orchestrierung. Warum? Weil der graphbasierte Ansatz so elegant erschien! Er würde mir Flexibilität geben! Er würde wunderschön skalieren!

Realitätscheck: Es war schmerzhaft langsam. Sogar lokal. Sogar mit ihrer Cloud-Bereitstellung. All diese schöne Abstraktion war einfach… Overhead. Jede Menge Overhead.

Endarchitektur (Pragmatisch einfach)

Nach viel Seelenerforschung (und Debugging) ist hier, was tatsächlich funktioniert:

```
Frontend (Next.js) → API Gateway → Cloud Run Services → Cloud Workflows → Cloud Storage
                ↓
            Supabase (Auth + Real-time + PostgreSQL + Edge Functions)
```

Hinweis: Wir haben von AWS Lambda/Step Functions zu GCP Cloud Run/Workflows im Juli 2025 migriert und dabei 92% Kostenreduzierung und 10-fache Leistungsverbesserung erzielt.

Die große Erkenntnis: Als ich zu direkten Supabase-Abfragen wechselte, anstatt alles in APIs zu verpacken, erzielte ich eine 10-fache Leistungsverbesserung (450ms → 45ms). All diese „richtige" API-Schichtung? Sie verlangsamte alles nur. Diese datenbankzentrierte Architektur wurde zum Fundament unserer GCP-Migration.

KI-Modellauswahl: Jenseits des Hypes

Die Realität der Modelllandschaft

Ok, lass uns über KI-Modelle reden. Ich habe sie alle ausprobiert. Wirklich ausprobiert – nicht nur einen Nachmittag damit gespielt. Nach monatelangem Testen (und dem Verbrennen von mehr API-Credits als ich zugeben möchte) ist hier, was tatsächlich funktioniert, wenn du etwas Reales baust:

Mein aktueller Go-To-Stack:

- Claude (über Claude Code) & Gemini 2.5 Pro (über Gemini CLI): Mein Kern-Entwicklungs-Duo. Diese zwei Modelle sind so leistungsfähig geworden, dass sie in meinem Workflow im Wesentlichen alles andere ersetzt haben.

- Claude Sonnet 4 API: Treibt DIALØGUEs Skriptgenerierung mit Temperature 0 für JSON-Zuverlässigkeit an

Was mein Stack früher beinhaltete:

DeepSeek: Ich verlasse mich früher auf dieses Tool für das Debugging schwieriger Bugs, besonders bei Troubleshooting-Sitzungen spät in der Nacht. Aber sobald Claude 4 und Gemini 2.5 Pro ankamen? Sie handhaben diese Grenzfälle genauso gut, wenn nicht besser. Die Entwicklung der Modellkapazität machte spezialisierte Debugging-Modelle für meinen Workflow überflüssig.

Was tatsächlich funktioniert:

Hier wird es interessant: Jedes Modell ist bereits unglaublich leistungsstark für sich. Claude ist brilliant im architektonischen Denken und komplexem Reasoning. Gemini 2.5 Pro? Absolut phänomenal bei der Implementierung und dem Aufrechterhalten des Kontexts über riesige Codebasen. Der Sprung von Gemini 2.0 zu 2.5 war verrückt – ich konnte den Unterschied buchstäblich spüren. Schnellere Antworten, 1M-Token-Kontextfenster (ja, wirklich) und es versteht tatsächlich, was ich bauen möchte.

Aber hier passiert die echte Magie: wenn man sie dazu bringt, die Arbeit des anderen zu kritisieren. Ich lasse Claude einen Ansatz entwerfen und bitte dann Gemini, ihn zu überprüfen und Verbesserungen vorzuschlagen. Oder Gemini generiert eine Lösung und ich lasse Claude sie auf Grenzfälle oder architektonische Bedenken analysieren. Dieses Hin und Her, dieser kollaborative Kritikprozess – das ist, wo man die Durchbruchlösungen findet, die keiner alleine erreicht hätte.

Was nicht funktioniert hat (trotz des Hypes):

• OpenAI o1/o3: Alle reden darüber, aber für die tatsächliche Entwicklung? Zu langsam, zu teuer und ehrlich gesagt nicht viel besser für meine Anwendungsfälle.
• GitHub Copilot Workspace: Gute Idee, aber diese Token-Limits… Ich stieß immer wieder an die Decke, wenn ich etwas Substanzielles tun wollte

Die eigentliche Erkenntnis: Weißt du, was einem niemand sagt? Verschiedene Modelle scheitern auf unterschiedliche Weise. Frühes Gemini geriet bei bestimmten Fehlern in seltsame Schleifen – konnte das Problem einfach nicht sehen. Claude erkannte es sofort. Aber dann übernahm Claude bei einfachen Implementierungen, die Gemini in Sekunden löste. Der Trick ist nicht, das „beste" Modell zu finden – sondern zu wissen, wann man wechseln muss.

Full-Stack-Entwicklung: Mehrere Rollen tragen

Die Terminal-Strategie

Hier ist etwas Praktisches, das meinen Verstand tatsächlich gerettet hat: Separate Terminal-Fenster für verschiedene Kontexte. Klingt einfach? Es ist bahnbrechend.

```bash
# Terminal 1: Frontend Developer Ich
cd podcast_generator_frontend_v2
npm run dev
# Hier denke ich über React-Komponenten und Nutzererfahrung nach

# Terminal 2: Backend Developer Ich
cd gcp_services
./deploy/deploy-service.sh [service-name]
# Hier leben Cloud Run Services (viel glücklicher als Lambda!)

# Terminal 3: Database Ich
supabase start --workdir supabase
# Lokales Supabase zum Testen, Produktion für echte Arbeit
```

Ich weiß, es klingt lächerlich, aber das physische Wechseln zwischen Terminals hilft meinem Gehirn, den Kontext zu wechseln. Frontend-Ich und Backend-Ich sind verschiedene Menschen und brauchen ihre eigenen Räume.

Cross-Stack-Kommunikation

Solo an Full-Stack zu arbeiten ist seltsam. Du führst im Grunde Gespräche mit dir selbst. Also fing ich an, Notizen zu hinterlassen:

```
// Notiz von Frontend-Ich an Backend-Ich
/**
 * BACKEND TODO:
 * - Brauche Endpoint GET /api/podcasts/:id/segments
 * - Sollte zurückgeben: { segments: Array<{id, title, status, content}> }
 * - Muss handhaben: 404 (nicht gefunden), 403 (nicht autorisiert)
 * - Echtzeit-Updates über Supabase-Subscription wären ideal
 * - Zukünftiges Ich wird dir für die Fehlerbehandlung danken!
 */
```

```
## Backend Developer Summary für Frontend-Integration
Aktueller Zustand:
- Implementierte Endpoints: POST /podcasts, GET /podcasts/:id
- Authentifizierung: Bearer Token über Supabase JWT
- Echtzeit: Supabase-Kanal "podcast-updates"

Nächste Frontend-Aufgaben:
1. Podcast-Erstellungsformular implementieren
2. Echtzeit-Updates abonnieren
3. Fehlerzustände handhaben (401, 403, 404, 500)
```

Diese kleinen Notizen? Absolute Lebensretter, wenn ich nach einer Woche zum Code zurückkomme und keine Ahnung habe, was mein vergangenes Ich dachte.

Wichtige technische Erkenntnisse

1. Systemdenken überschreitet Fachgebiete

Mein Werbehintergrund lehrte mich, in Systemen zu denken – Nutzerreisen, Konversionsfunnel, Attributionsmodelle. Diese mentalen Modelle übertragen sich direkt auf:

• Verteiltes System-Design
• Nutzererfahrungsflüsse
• Leistungsoptimierung
• Fehlerbehandlungsstrategien

2. Production-First-Mindset

# Was ich gelernt habe zu priorisieren

if works_in_production and meets_user_needs:

ship_it()

else:

fix_only_blockers()

# Perfekt ist der Feind des Fertigen

3. Full-Stack-Kompetenz ist real

DIALØGUE zu bauen erforderte:

• Frontend: React 19, Next.js 15, TypeScript, Echtzeit-Subscriptions, WebSocket-Management (Speicherlecks behoben!)
• Backend: Python 3.12, Cloud Run (14 Microservices), Cloud Workflows, PostgreSQL (über Supabase)
• Infrastruktur: GCP (von AWS migriert), API Gateway, Cloud Storage, Vercel für Frontend
• KI/ML: Claude 4.0, Perplexity API, OpenAI TTS, Temperature-Optimierung (0 für JSON)
• DevOps: Docker-Container, Cloud Build, Monitoring, JWT-Sicherheit (P-256-Migration)
• Datenbank: PostgreSQL mit RLS, Edge Functions, atomare Operationen zur Verhinderung von Race Conditions

4. Die Bedeutung klassischer Ausbildung

Formale Software-Engineering-Ausbildung (System-Design, Datenstrukturen, Algorithmen) erwies sich als unschätzbar. Es geht nicht nur darum, KI Code schreiben zu lassen – sondern darum zu wissen, was man fordert und wie man es architektonisch gestaltet.

Abschließende Gedanken

Also, hier bin ich nach allem: DIALØGUE zu bauen hat vollständig verändert, wie ich mich beruflich sehe. Früher war ich der Typ, der technische Teams managte. Jetzt? Ich kann tatsächlich an ihrer Seite bauen. Und ehrlich gesagt fühlt sich das ziemlich großartig an. :D Diese Entwicklung setzte sich fort, als ich begann, eine native iOS-App ohne Swift-Kenntnisse zu bauen – es stellte sich heraus, dass Werbefähigkeiten (Geschmack, kreative Leitung, zu wissen, wie sich „gut" anfühlt) mehr zählen als Coding-Fähigkeiten.

Die Reise von der Werbung zum Engineering dreht sich nicht nur darum, Syntax oder Frameworks zu lernen. Es geht darum, dein Gehirn umzuprogrammieren, in Systemen zu denken, methodisch zu debuggen und zu akzeptieren, dass du manchmal 3 Stunden mit einem fehlenden Semikolon verbringst (ok, TypeScript fängt diese ab, aber du verstehst das Prinzip).

Weißt du, was lustig ist? Das analytische Denken aus der Werbung – Nutzerreisen verstehen, Konversionsfunnel optimieren, all das Zeug – überträgt sich direkt auf Engineering. Der Unterschied ist, dass im Code, wenn etwas nicht funktioniert, der Computer dir sofort Bescheid sagt. Kein Warten auf Kampagnenberichte. Nur sofortiges, brutales Feedback.

Das „Produkt" ist live bei podcast.chandlernguyen.com. Es funktioniert. Es ist nicht perfekt, aber es ist meins. Und jeder Bug-Fix, jede Feature-Ergänzung, jeder „Aha!"-Moment – sie sind alle Teil dieser laufenden Reise.

Hast du jemals einen großen Karriereschwenk gemacht – von einem Bereich in etwas völlig anderes? Ich würde gerne hören, was dich am meisten bei dem Übergang überrascht hat. Lass es mich wissen!

Viele Grüße,

Chandler

P.S: Apropos Dinge auf die harte Tour lernen – willst du wissen, wie eine winzige KI-Parameteränderung mich 54 Dollar/Monat kostete? Schau dir Eine KI-Parameteränderung kostete mich 54 Dollar/Monat an. Es ist eine Warngeschichte darüber, was passiert, wenn du KI-Assistenten mit Produktionscode vertraust, ohne explizit über Produktionseinschränkungen zu sprechen. Spoiler: „Lass es funktionieren" und „Lass es produktionsbereit sein" sind sehr unterschiedliche Anfragen.

P.P.S: Ich versuche immer noch, das ganze Engineering-Ding herauszufinden, einen Bug nach dem anderen. Ich baue gerade KI-gestützte Anwendungen und versuche, die Produktion nicht zu zerstören. Komm später auf diesen Blog zurück für mehr.