Dari Periklanan ke Engineering: Pelajaran Teknis dari Membangun DIALOGUE

*Ini adalah deep-dive teknis pendamping dari pengenalan DIALOGUE saya. Kalau belum membaca tentang apa itu DIALOGUE dan mengapa saya membangunnya, mulai dari sana!*

Perjalanan: Dari Profesional Periklanan ke Full-Stack Engineer

Oke, mari kita bahas gajah di ruangan — ya, saya berasal dari periklanan. Iya, media plan dan creative brief, bukan data structure dan algorithm. Tapi ini yang lucu: memahami cara kerja sistem, baik itu marketing funnel atau arsitektur terdistribusi, membutuhkan mindset analitis yang sama. Bedanya? Dalam engineering, ketika kamu melakukan kesalahan, komputer langsung memberitahu. Tidak perlu menunggu hasil kampanye haha.

Membangun DIALOGUE telah... intens. Ini bukan sekadar menulis kode (meskipun banyak juga). Ini tentang merancang sistem kompleks yang entah bagaimana perlu mengorkestrai beberapa layanan AI, menangani workflow asynchronous, dan tidak berantakan ketika pengguna melakukan hal-hal yang tidak terduga. Biarkan saya berbagi apa yang sebenarnya diajarkan perjalanan ini — yang baik, yang frustasi, dan momen "kenapa tidak ada yang memberitahu saya ini?"

Keputusan Arsitektur: Mengapa Kompleksitas Adalah Musuh

Ini sesuatu yang tidak diberitahu siapa pun saat kamu memulai: kompleksitas bukan temanmu. Saya belajar ini dengan cara yang sulit. Seperti, benar-benar sulit. Bayangkan saya tenggelam di log CloudWatch, mencoba mencari tahu mengapa sistem yang dirancang indah itu... yah, tidak berfungsi. T.T

Arsitektur Awal (Terlalu Kompleks)

Jadi saya memulai dengan LangGraph untuk orkestrasi. Mengapa? Karena pendekatan berbasis graph terlihat sangat elegan! Ia akan memberikan fleksibilitas! Ia akan scale dengan indah!

Kenyataan: Sangat lambat. Bahkan berjalan secara lokal. Bahkan dengan cloud deployment mereka. Semua abstraksi yang indah itu hanyalah... overhead. Banyak sekali overhead.

Arsitektur Akhir (Pragmatis dan Sederhana)

Setelah banyak introspeksi (dan debugging), inilah yang benar-benar berfungsi:

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

Catatan: Kami bermigrasi dari AWS Lambda/Step Functions ke GCP Cloud Run/Workflows pada Juli 2025, mencapai pengurangan biaya 92% dan peningkatan performa 10x.

Revelasi Besar: Ketika saya beralih ke query Supabase langsung alih-alih membungkus semuanya dalam API, saya mendapatkan peningkatan performa 10x (450ms menjadi 45ms). Semua layering API yang "proper" itu? Hanya memperlambat segalanya. Arsitektur database-first ini menjadi fondasi migrasi GCP kami.

Pemilihan Model AI: Melampaui Hype

Realitas Lanskap Model

Oke, mari bicara tentang model AI. Saya sudah mencoba semuanya. Seperti, benar-benar mencoba — bukan hanya bermain-main selama satu sore. Setelah berbulan-bulan pengujian (dan membakar lebih banyak kredit API daripada yang ingin saya akui), inilah yang benar-benar berfungsi ketika kamu membangun sesuatu yang nyata:

Stack Andalan Saya Saat Ini:

- Claude (via Claude code) & Gemini 2.5 Pro (via Gemini CLI): Duo pengembangan inti saya. Kedua model ini sudah begitu capable sehingga pada dasarnya menggantikan semua yang lain dalam workflow saya.

- Claude Sonnet 4 API: Menggerakkan generasi script DIALOGUE dengan temperature 0 untuk reliabilitas JSON

Apa yang Dulu Ada di Stack Saya:

DeepSeek: Saya dulu mengandalkan ini untuk debugging bug rumit, terutama sesi troubleshooting larut malam. Tapi begitu Claude 4 dan Gemini 2.5 Pro tiba? Mereka menangani edge case tersebut sama baiknya, kalau tidak lebih baik. Evolusi dalam kemampuan model membuat model debugging khusus menjadi redundan untuk workflow saya.

Apa yang Benar-Benar Berfungsi:

Di sinilah hal-hal menjadi menarik: Setiap model sudah luar biasa powerful sendirian. Claude brilian dalam pemikiran arsitektural dan reasoning kompleks. Gemini 2.5 Pro? Sangat fenomenal dalam implementasi dan mempertahankan konteks di codebase yang masif. Lompatan dari Gemini 2.0 ke 2.5 itu gila — saya benar-benar merasakan perbedaannya. Respons lebih cepat, context window 1M token (ya, benar), dan benar-benar memahami apa yang saya coba bangun.

Tapi di sinilah keajaiban sesungguhnya terjadi: ketika kamu membuat mereka mengkritik pekerjaan satu sama lain. Saya akan meminta Claude merancang pendekatan, lalu meminta Gemini me-review dan menyarankan perbaikan. Atau Gemini akan menghasilkan solusi, dan saya akan meminta Claude menganalisisnya untuk edge case atau kekhawatiran arsitektural. Saling kritik itu, proses kolaboratif itu — di situlah kamu menemukan solusi breakthrough yang tidak akan dicapai keduanya sendirian.

Apa yang Tidak Berfungsi (Meski Hype-nya):

OpenAI o1/o3: Semua orang membicarakan ini, tapi untuk pengembangan nyata? Terlalu lambat, terlalu mahal, dan jujur tidak sebagus itu untuk use case saya.
GitHub Copilot Workspace: Ide bagus, tapi batas token itu... Saya terus mentok setiap mencoba melakukan sesuatu yang substansial

Insight Sebenarnya: Tahu apa yang tidak diberitahu siapa pun? Model yang berbeda gagal dengan cara yang berbeda. Gemini versi awal suka stuck di loop aneh pada error tertentu — tidak bisa melihat masalahnya. Claude langsung menemukan. Tapi kemudian Claude overthinking implementasi sederhana yang Gemini bisa selesaikan dalam hitungan detik. Triknya bukan menemukan model "terbaik" — tapi tahu kapan harus berganti.

Pengembangan Full-Stack: Memakai Banyak Topi

Strategi Terminal

Ini sesuatu yang praktis yang benar-benar menyelamatkan kewarasan saya: window terminal terpisah untuk konteks berbeda. Terdengar sederhana? Ini mengubah permainan.

```bash
# Terminal 1: Frontend Developer Me
cd podcast_generator_frontend_v2
npm run dev
# This is where I think about React components and user experience

# Terminal 2: Backend Developer Me
cd gcp_services
./deploy/deploy-service.sh [service-name]
# This is where Cloud Run services live (much happier than Lambda!)

# Terminal 3: Database Me
supabase start --workdir supabase
# Local Supabase for testing, production for real work
```

Saya tahu kedengarannya konyol, tapi secara fisik berpindah antar terminal membantu otak saya berganti konteks. Frontend-saya dan backend-saya adalah orang yang berbeda, dan mereka butuh ruang sendiri.

Komunikasi Lintas-Stack

Bekerja solo di full-stack itu aneh. Kamu pada dasarnya bercakap-cakap dengan dirimu sendiri. Jadi saya mulai meninggalkan catatan:

```
// Note from Frontend Me to Backend Me
/**
 * BACKEND TODO:
 * - Need endpoint GET /api/podcasts/:id/segments
 * - Should return: { segments: Array<{id, title, status, content}> }
 * - Must handle: 404 (not found), 403 (unauthorized)
 * - Real-time updates via Supabase subscription would be ideal
 * - Future me will thank you for error handling!
 */
```

```
## Backend Developer Summary for Frontend Integration
Current State:
- Endpoints implemented: POST /podcasts, GET /podcasts/:id
- Authentication: Bearer token via Supabase JWT
- Real-time: Supabase channel "podcast-updates"

Next Frontend Tasks:
1. Implement podcast creation form
2. Subscribe to real-time updates
3. Handle error states (401, 403, 404, 500)
```

Catatan-catatan kecil ini? Penyelamat mutlak ketika saya kembali ke kode setelah seminggu dan tidak ingat apa yang dipikirkan diri saya di masa lalu.

Takeaway Teknis Kunci

1. Systems Thinking Melampaui Domain

Latar belakang periklanan saya mengajarkan saya berpikir dalam sistem — user journey, conversion funnel, attribution model. Mental model ini langsung diterjemahkan ke:

Desain sistem terdistribusi
Alur pengalaman pengguna
Optimisasi performa
Strategi error handling

2. Mindset Production-First

# What I learned to prioritize

if works_in_production and meets_user_needs:

ship_it()

else:

fix_only_blockers()

# Perfect is the enemy of done

3. Kompetensi Full-Stack Itu Nyata

Membangun DIALOGUE membutuhkan:

Frontend: React 19, Next.js 15, TypeScript, real-time subscription, manajemen WebSocket (memperbaiki memory leak!)
Backend: Python 3.12, Cloud Run (14 microservice), Cloud Workflows, PostgreSQL (via Supabase)
Infrastruktur: GCP (migrasi dari AWS), API Gateway, Cloud Storage, Vercel untuk frontend
AI/ML: Claude 4.0, Perplexity API, OpenAI TTS, optimisasi temperature (0 untuk JSON)
DevOps: Container Docker, Cloud Build, monitoring, keamanan JWT (migrasi P-256)
Database: PostgreSQL dengan RLS, Edge Functions, operasi atomik untuk pencegahan race condition

4. Pentingnya Pelatihan Klasik

Memiliki pelatihan software engineering formal (system design, data structure, algorithm) terbukti sangat berharga. Ini bukan hanya tentang membuat AI menulis kode — ini tentang mengetahui apa yang harus diminta dan bagaimana merancangnya.

Pemikiran Akhir

Jadi di sinilah saya mendarat setelah semua ini: Membangun DIALOGUE telah sepenuhnya mengubah cara saya melihat diri sendiri secara profesional. Dulu saya orang yang mengelola tim teknis. Sekarang? Saya benar-benar bisa membangun bersama mereka. Dan jujur, itu terasa cukup luar biasa. :D Evolusi itu berlanjut ketika saya mulai membangun aplikasi iOS native tanpa menguasai Swift — ternyata skill periklanan (selera, arahan kreatif, mengetahui seperti apa "bagus" itu) lebih penting daripada skill coding.

Perjalanan dari periklanan ke engineering bukan hanya tentang belajar sintaks atau framework. Ini tentang merewire otak kamu untuk berpikir dalam sistem, untuk debug secara metodis, dan untuk menerima bahwa kadang kamu akan menghabiskan 3 jam untuk semicolon yang hilang (oke, TypeScript menangkap itu, tapi kamu paham maksudnya).

Tahu yang lucu? Pemikiran analitis dari periklanan — memahami user journey, mengoptimalkan conversion funnel, semua hal itu — langsung diterjemahkan ke engineering. Bedanya di kode, ketika sesuatu tidak berfungsi, komputer langsung memberitahu. Tidak perlu menunggu laporan kampanye. Hanya feedback langsung dan brutal.

"Produk"-nya live di podcast.chandlernguyen.com. Ia berfungsi. Tidak sempurna, tapi ini milik saya. Dan setiap perbaikan bug, setiap penambahan fitur, setiap momen "aha!" — semuanya bagian dari perjalanan yang sedang berlangsung ini.

Pernahkah kamu melakukan pivot karier besar seperti ini — dari satu domain ke sesuatu yang benar-benar berbeda? Saya ingin mendengar apa yang paling mengejutkanmu tentang transisinya. Beri tahu saya!

Salam,

Chandler

P.S: Berbicara soal belajar hal-hal dengan cara yang sulit — mau tahu bagaimana satu perubahan parameter AI kecil menghabiskan saya $54/bulan? Cek Satu Perubahan Parameter AI Menghabiskan Saya $54/Bulan. Ini kisah peringatan tentang apa yang terjadi ketika kamu mempercayai asisten AI dengan kode produksi tanpa eksplisit tentang constraint produksi. Spoiler: "buat berfungsi" dan "buat siap produksi" adalah request yang sangat berbeda.

P.P.S: Saya masih mencari tahu soal engineering ini, satu bug pada satu waktu. Saat ini membangun aplikasi bertenaga AI dan berusaha tidak merusak produksi. Kembali lagi ke blog ini untuk lebih banyak nanti.