由Advertising到Engineering：Build DIALØGUE嘅技術Lessons

*呢篇係我DIALØGUE介紹嘅技術deep-dive companion。如果你仲未睇過DIALØGUE係咩同埋點解我build佢，由嗰邊開始！*

旅程：由Advertising Professional到Full-Stack Engineer

好喇，講吓個大象——係嘅，我嚟自advertising。係嘅，media plans同creative briefs，唔係data structures同algorithms。但有趣嘅係：理解系統點運作，無論係marketing funnel定distributed architecture，都需要同樣嘅analytical mindset。分別？喺engineering入面，當你搞砸咗，電腦即刻話你知。唔使等campaign results哈哈。

Build DIALØGUE真係...好intense。唔淨止係寫code（雖然寫咗好多）。係要architect一個複雜嘅系統，需要orchestrate多個AI services、handle asynchronous workflows、同埋喺用戶做unexpected嘢嘅時候唔會散晒。等我分享吓呢個旅程真正教識我啲乜——好嘅、令人frustrating嘅、同「點解冇人早啲話我知？」嘅時刻。

Architecture Decisions：點解Complexity係敵人

有樣嘢喺你啱開始嘅時候冇人話你知：complexity唔係你嘅朋友。我係用hard way學到嘅。好hard。想像吓我溺喺CloudWatch logs入面，試圖搞清楚我設計得好靚嘅系統點解...唔work。T.T

初始Architecture（過度複雜）

我由LangGraph開始做orchestration。點解？因為graph-based approach睇落好elegant！佢會俾我flexibility！佢會scale得好靚！

Reality check：佢慢到痛。即使locally run。即使用佢哋嘅cloud deployment。所有靚嘅abstraction只係...overhead。好多好多overhead。

最終Architecture（務實地簡單）

經過好多soul-searching（同debugging），以下先係真正work嘅：

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

Note：我哋由AWS Lambda/Step Functions migrate到GCP Cloud Run/Workflows，達到92%成本減少同10倍performance改善。

大發現：當我轉用直接Supabase queries而唔係wrap所有嘢喺API入面，我得到10倍performance改善（450ms → 45ms）。所有嗰啲「proper」API layering？只係拖慢所有嘢。呢個database-first architecture成為咗我哋GCP migration嘅基礎。

AI Model選擇：超越Hype

Model Landscape嘅現實

好喇，講吓AI models。我全部都試過。真正試過——唔係淨係玩咗一個下晝。經過幾個月嘅測試（同burn through比我想承認嘅更多API credits），以下先係當你build真嘢嘅時候actually work嘅：

我而家嘅Go-To Stack：

- Claude（透過Claude code）& Gemini 2.5 Pro（透過Gemini CLI）：我嘅核心development二人組。呢兩個model已經變得咁capable，基本上取代咗我workflow入面嘅其他所有嘢。

- Claude Sonnet 4 API：Power住DIALØGUE嘅script generation，temperature設為0確保JSON reliability

我嘅Stack以前包括咩：

DeepSeek：我以前靠佢debug tricky bugs，尤其係夜晚troubleshooting sessions。但當Claude 4同Gemini 2.5 Pro出咗之後？佢哋handle嗰啲edge cases一樣好，甚至更好。Model capability嘅evolution令specialized debugging models對我嘅workflow嚟講變得redundant。

真正Work嘅係咩：

有趣嘅地方嚟喇：每個model本身已經incredibly powerful。Claude brilliant at architectural thinking同complex reasoning。Gemini 2.5 Pro？喺implementation同maintain context across massive codebases方面absolutely phenomenal。由Gemini 2.0到2.5嘅jump係insane——我literally可以_feel_到分別。更快嘅回應、1M token context window（係嘅，真嘅），而且佢actually理解我想build咩。

但真正嘅magic喺邊度：當你叫佢哋互相critique對方嘅work。我會叫Claude design一個approach，然後叫Gemini review同suggest improvements。或者Gemini會generate一個solution，然後我叫Claude分析佢嘅edge cases或architectural concerns。嗰種back-and-forth、collaborative critique process——嗰度先係你搵到突破性solution嘅地方，兩個單獨都唔會得到嘅。

冇Work嘅（Despite嗰啲Hype）：

OpenAI o1/o3：人人都講緊呢啲，但for actual development？太慢、太貴，而且老實講對我嘅use cases唔見得好好多。
GitHub Copilot Workspace：Good idea，但嗰啲token limits...每次我想做substantive嘢都撞到ceiling

真正嘅Insight：你知冇人話你知咩？唔同嘅model fail得唔同。早期Gemini會喺某啲errors上面stuck喺weird loops——就係睇唔到問題。Claude會即刻spot到。但Claude會overthink啲Gemini可以幾秒內nail嘅簡單implementations。技巧唔係搵「最好」嘅model——而係知道幾時switch。

Full-Stack Development：戴多頂帽

Terminal策略

有個practical嘅嘢真係救咗我嘅sanity：為唔同context用唔同嘅terminal windows。聽落好簡單？係game-changing。

```bash
# Terminal 1: Frontend Developer Me
cd podcast_generator_frontend_v2
npm run dev
# 呢度係我諗React components同user experience嘅地方

# Terminal 2: Backend Developer Me
cd gcp_services
./deploy/deploy-service.sh [service-name]
# 呢度係Cloud Run services住嘅地方（開心過Lambda好多！）

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

我知聽落好ridiculous，但physically switch terminals幫我嘅腦switch context。Frontend me同backend me係唔同嘅人，佢哋需要自己嘅空間。

Cross-Stack Communication

Solo做full-stack好weird。你基本上係同自己對話。所以我開始留notes：

```
// 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)
```

呢啲小notes？喺我隔咗一個禮拜返嚟睇code、完全唔記得過去嘅自己喺諗咩嘅時候，真係救命㗎。

關鍵技術Takeaways

1. Systems Thinking超越Domain

我嘅advertising背景教識我用systems思考——user journeys、conversion funnels、attribution models。呢啲mental models直接translate到：

Distributed system design
User experience flows
Performance optimization
Error handling strategies

2. Production-First Mindset

# 我學到要優先做咩

if works_in_production and meets_user_needs:

ship_it()

else:

fix_only_blockers()

# Perfect is the enemy of done

3. Full-Stack Competency係Real嘅

Build DIALØGUE需要：

Frontend：React 19、Next.js 15、TypeScript、real-time subscriptions、WebSocket management（修好咗memory leaks！）
Backend：Python 3.12、Cloud Run（14 microservices）、Cloud Workflows、PostgreSQL（透過Supabase）
Infrastructure：GCP（由AWS migrate過嚟）、API Gateway、Cloud Storage、Vercel做frontend
AI/ML：Claude 4.0、Perplexity API、OpenAI TTS、temperature optimization（0用嚟做JSON）
DevOps：Docker containers、Cloud Build、monitoring、JWT security（P-256 migration）
Database：PostgreSQL配RLS、Edge Functions、atomic operations防race condition

4. Classical Training嘅重要性

有正規software engineering training（system design、data structures、algorithms）真係好有價值。唔淨止係叫AI寫code——而係知道要ask咩同點architect。

最後諗法

所以我到咗呢度：Build DIALØGUE完全改變咗我點樣睇自己嘅職業。我以前係manage技術團隊嘅人。而家？我可以actually同佢哋一齊build。老實講，呢個感覺幾amazing。:D 呢個evolution繼續咗喺我開始build一個native iOS app但唔識Swift嘅時候——原來advertising嘅skills（taste、creative direction、知道咩係「好」嘅感覺）比coding skills更重要。

由advertising到engineering嘅旅程唔淨止係學syntax或frameworks。係要rewire你嘅腦去用systems思考、methodically debug、同接受有時你會花3個鐘喺一個missing semicolon上面（好啦，TypeScript會catch到呢啲，但你明白我嘅意思）。

你知咩好funny？由advertising嚟嘅analytical thinking——理解user journeys、optimize conversion funnels、所有嗰啲嘢——直接translate到engineering。分別係喺code入面，當一啲嘢唔work，電腦即刻話你知。唔使等campaign reports。只有即時、brutal嘅feedback。

個「product」依家live喺podcast.chandlernguyen.com。佢work。唔完美，但係我嘅。而每個bug fix、每個feature addition、每個「aha！」時刻——全部都係呢個持續旅程嘅一部分。

你有冇試過做過大轉行——由一個domain轉到完全唔同嘅嘢？我好想聽吓喺呢個transition入面最令你驚訝嘅係咩。話俾我知！

祝好，

Chandler

P.S：講到hard way學嘢——想知一個tiny AI parameter改動點樣cost我$54/month？睇吓一個AI Parameter改動Cost我$54/Month。呢個係一個關於你trust AI assistants處理production code但唔explicit about production constraints會發生咩嘅cautionary tale。劇透：「make it work」同「make it production-ready」係好唔同嘅requests。

P.P.S： 我仲喺度摸索成個engineering呢回事，一個bug一個bug咁嚟。依家build緊AI-powered applications，努力唔好break production。之後返嚟呢個blog睇更多。