Mula Advertising Hanggang Engineering: Mga Technical Lessons Mula sa Pagbuo ng DIALØGUE

*Ito ang technical deep-dive companion sa aking introduction ng DIALØGUE. Kung hindi mo pa nababasa kung ano ang DIALØGUE at bakit ko ito ginawa, magsimula doon!*

Ang Journey: Mula Advertising Professional Hanggang Full-Stack Engineer

Okay, pag-usapan natin ang elephant in the room — oo, galing ako sa advertising. Oo, media plans at creative briefs, hindi data structures at algorithms. Pero nakakatawa lang: ang pag-intindi kung paano gumagana ang mga systems, ito man ay marketing funnel o distributed architecture, ay nangangailangan ng parehong analytical mindset. Ang pagkakaiba? Sa engineering, kapag nagkamali ka, sinasabi agad sa iyo ng computer. Walang paghihintay para sa campaign results haha.

Ang pagbuo ng DIALØGUE ay... intense. Hindi lang ito pagsulat ng code (kahit marami naman talaga). Ito ay pag-architect ng isang complex system na kahit papaano ay kailangang mag-orchestrate ng maraming AI services, mag-handle ng asynchronous workflows, at hindi mabuwag kapag gumawa ang mga users ng mga hindi inaasahang bagay. Hayaan mong ibahagi ko ang talagang natutunan ko sa journey na ito — ang maganda, ang nakakafrustrate, at ang "bakit walang nagsabi sa akin nito?" moments.

Mga Architecture Decisions: Bakit Kaaway ang Complexity

Narito ang isang bagay na walang nagsasabi sa iyo kapag nagsisimula ka: hindi mo kaibigan ang complexity. Natutuhan ko ito nang mahirap. Talagang mahirap. Isipin mo akong nalulunod sa CloudWatch logs, sinusubukang alamin kung bakit ang magandang in-architect kong system ay... well, hindi gumagana. T.T

Unang Architecture (Sobrang Complex)

Kaya nagsimula ako sa LangGraph para sa orchestration. Bakit? Dahil ang graph-based approach ay mukhang napaka-elegant! Magbibigay ito sa akin ng flexibility! Mag-i-scale ito nang maganda!

Reality check: Sobrang bagal. Kahit lokal na pinapatakbo. Kahit sa cloud deployment nila. Lahat ng magandang abstraction ay puro... overhead. Napakarami at napakaraming overhead.

Final Architecture (Pragmatically Simple)

Pagkatapos ng maraming soul-searching (at debugging), ito ang talagang gumagana:

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

Note: Lumipat kami mula AWS Lambda/Step Functions sa GCP Cloud Run/Workflows noong July 2025, nakamit ang 92% cost reduction at 10x performance improvement.

Ang Malaking Rebelasyon: Nang lumipat ako sa direct Supabase queries sa halip na i-wrap ang lahat sa APIs, nakakuha ako ng 10x performance improvement (450ms → 45ms). Lahat ng "maayos" na API layering? Pinapabagal lang ang lahat. Ang database-first architecture na ito ang naging pundasyon ng aming GCP migration.

AI Model Selection: Lagpas sa Hype

Ang Realidad ng Model Landscape

Okay, pag-usapan natin ang AI models. Nasubukan ko silang lahat. Talagang nasubukan — hindi lang naglaro-laro nang isang hapon. Pagkatapos ng ilang buwan ng testing (at pag-burn ng mas maraming API credits kaysa sa gusto kong aminin), eto ang talagang gumagana kapag gumagawa ka ng totoong bagay:

Ang Kasalukuyang Go-To Stack Ko:

- Claude (sa pamamagitan ng Claude code) & Gemini 2.5 Pro (sa pamamagitan ng Gemini CLI): Ang core development duo ko. Naging sobrang capable na ng dalawang models na ito na halos pinalitan na nila ang lahat ng iba sa workflow ko.

- Claude Sonnet 4 API: Nagpapatakbo ng DIALØGUE's script generation na may temperature 0 para sa JSON reliability

Ano Ang Dati sa Stack Ko:

DeepSeek: Dati akong umaasa dito para sa debugging ng tricky bugs, lalo na sa late-night troubleshooting sessions. Pero nang dumating ang Claude 4 at Gemini 2.5 Pro? Kaya nilang hawakan ang mga edge cases na iyon nang parehas o mas magaling pa. Ang ebolusyon sa model capability ay gumawa na walang kwenta ang specialized debugging models para sa workflow ko.

Ano ang Talagang Gumagana:

Narito kung saan nagiging interesting: Bawat model ay sobrang powerful na sa sarili nila. Brillante si Claude sa architectural thinking at complex reasoning. Gemini 2.5 Pro? Absolutely phenomenal sa implementation at pagpapanatili ng context sa malalaking codebases. Ang jump mula Gemini 2.0 sa 2.5 ay insane — literal na nararamdaman ko ang pagkakaiba. Mas mabilis na responses, 1M token context window (oo, totoo), at talagang naiintindihan nito kung ano ang sinusubukan kong gawin.

Pero narito kung saan nangyayari ang tunay na magic: kapag pinag-critique mo sila sa trabaho ng isa't isa. Ipapagawa ko kay Claude ang design ng approach, tapos hihingin ko kay Gemini na i-review at mag-suggest ng improvements. O mag-ge-generate si Gemini ng solution, at ipapasuri ko kay Claude para sa edge cases o architectural concerns. Ang back-and-forth na iyon, ang collaborative critique process — doon mo mahahanap ang breakthrough solutions na hindi maabot ng kahit sino sa kanila mag-isa.

Ang Hindi Gumana (Sa Kabila ng Hype):

OpenAI o1/o3: Lahat pinag-uusapan ang mga ito, pero para sa aktwal na development? Sobrang bagal, sobrang mahal, at sa totoo lang hindi naman ganoon kabuti para sa mga use cases ko.
GitHub Copilot Workspace: Magandang idea, pero ang mga token limits na iyon... palagi akong tinatamaan ng ceiling kapag sinusubukan kong gumawa ng kahit anong substansyal

Ang Tunay na Insight: Alam mo ba ang hindi sinasabi ng kahit sino sa iyo? Iba't iba ang paraan ng pagka-fail ng mga models. Ang naunang Gemini ay nati-stuck sa mga kakaibang loops sa ilang errors — hindi talaga makita ang problema. Makikita ito agad ni Claude. Pero pinagiisipan naman ni Claude nang sobra ang mga simpleng implementations na mago-nail ni Gemini sa ilang segundo. Ang trick ay hindi ang paghahanap ng "pinakamahusay" na model — ito ay ang pag-alam kung kailan mag-switch.

Full-Stack Development: Pagsusuot ng Maraming Sombrero

Ang Terminal Strategy

Narito ang isang praktikal na bagay na talagang nag-save ng katinuan ko: magkahiwalay na terminal windows para sa iba't ibang contexts. Mukhang simple? Game-changing.

```bash
# Terminal 1: Frontend Developer Me
cd podcast_generator_frontend_v2
npm run dev
# Dito ko iniisip ang mga React components at user experience

# Terminal 2: Backend Developer Me
cd gcp_services
./deploy/deploy-service.sh [service-name]
# Dito nakatira ang Cloud Run services (mas masaya kaysa sa Lambda!)

# Terminal 3: Database Me
supabase start --workdir supabase
# Local Supabase para sa testing, production para sa tunay na trabaho
```

Alam kong mukhang katawa-tawa, pero ang pisikal na pag-switch sa pagitan ng mga terminals ay tumutulong sa utak ko na mag-switch ng contexts. Ang frontend me at backend me ay magkaibang tao, at kailangan nila ng sariling espasyo.

Cross-Stack Communication

Kakaiba ang solo na pagtatrabaho sa full-stack. Basically, nag-uusap ka sa sarili mo. Kaya nagsimula akong mag-iwan ng mga notes:

```
// Note mula sa Frontend Me papunta sa Backend Me
/**
 * BACKEND TODO:
 * - Kailangan ng endpoint GET /api/podcasts/:id/segments
 * - Dapat magreturn ng: { segments: Array<{id, title, status, content}> }
 * - Dapat mahandle: 404 (not found), 403 (unauthorized)
 * - Real-time updates sa pamamagitan ng Supabase subscription ideal
 * - Pasasalamatan ng future me ang error handling!
 */
```

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

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

Ang mga maliliit na notes na ito? Absolute lifesavers kapag bumalik ako sa code pagkatapos ng isang linggo at walang ideya kung ano ang iniisip ng past-me.

Mga Pangunahing Technical Takeaways

1. Ang Systems Thinking ay Lumalampas sa mga Domain

Ang advertising background ko ang nagturo sa akin na mag-isip sa mga systems — user journeys, conversion funnels, attribution models. Ang mga mental model na ito ay direktang nai-translate sa:

Distributed system design
User experience flows
Performance optimization
Error handling strategies

2. Production-First Mindset

# Ang natutunan kong unahin

if works_in_production and meets_user_needs:

ship_it()

else:

fix_only_blockers()

# Perfect is the enemy of done

3. Totoo ang Full-Stack Competency

Kinailangan ng pagbuo ng DIALØGUE:

Frontend: React 19, Next.js 15, TypeScript, real-time subscriptions, WebSocket management (na-fix ang memory leaks!)
Backend: Python 3.12, Cloud Run (14 microservices), Cloud Workflows, PostgreSQL (sa pamamagitan ng Supabase)
Infrastructure: GCP (lumipat mula AWS), API Gateway, Cloud Storage, Vercel para sa frontend
AI/ML: Claude 4.0, Perplexity API, OpenAI TTS, temperature optimization (0 para sa JSON)
DevOps: Docker containers, Cloud Build, monitoring, JWT security (P-256 migration)
Database: PostgreSQL na may RLS, Edge Functions, atomic operations para sa race condition prevention

4. Ang Kahalagahan ng Classical Training

Naging napakahalaga ang pagkakaroon ng formal software engineering training (system design, data structures, algorithms). Hindi lang ito tungkol sa pagpapawrite ng code sa AI — ito ay tungkol sa pag-alam kung ano ang itatanong at kung paano i-architect ito.

Mga Huling Saloobin

Kaya narito na ang kinalalagyan ko pagkatapos ng lahat ng ito: Ganap na binago ng pagbuo ng DIALØGUE ang pagtingin ko sa sarili ko nang propesyonal. Dati ako ang taong nagma-manage ng mga technical teams. Ngayon? Kaya ko nang talagang mag-build kasama sila. At sa totoo lang, sobrang ganda ng pakiramdam. :D Nagpatuloy ang ebolusyong iyon nang nagsimula akong gumawa ng native iOS app nang hindi alam ang Swift — lumabas na ang advertising skills (taste, creative direction, pag-alam kung ano ang "maganda") ay mas mahalaga kaysa sa coding skills.

Ang journey mula advertising sa engineering ay hindi lang tungkol sa pag-aaral ng syntax o frameworks. Ito ay tungkol sa pag-rewire ng utak mo para mag-isip sa mga systems, mag-debug nang methodical, at tanggapin na minsan magugugol ka ng 3 oras sa isang nawawalang semicolon (okay, nahuhuli iyon ng TypeScript, pero gets mo na ang punto).

Alam mo ba ang nakakatawa? Ang analytical thinking mula sa advertising — pag-intindi ng user journeys, pag-optimize ng conversion funnels, lahat ng mga bagay na iyon — ito ay direktang nai-translate sa engineering. Ang pagkakaiba ay sa code, kapag may hindi gumana, sinasabi agad sa iyo ng computer. Walang paghihintay para sa campaign reports. Agad, brutal na feedback lang.

Ang "product" ay live na sa podcast.chandlernguyen.com. Gumagana ito. Hindi perpekto, pero sa akin ito. At bawat bug fix, bawat feature addition, bawat "aha!" moment — lahat sila ay parte ng patuloy na journey na ito.

Nagkaroon ka na ba ng malaking career pivot na ganito — mula sa isang domain patungo sa isang bagay na ganap na naiiba? Gusto kong marinig kung ano ang pinakasorpresa sa iyo tungkol sa transition. Ipaalam mo sa akin!

Maraming salamat,

Chandler

P.S: Sa usapang pag-aaral nang mahirap na paraan — gusto mo bang malaman kung paano isang maliit na AI parameter change ay nagkahalaga sa akin ng $54/buwan? Tingnan ang One AI Parameter Change Cost Me $54/Month. Isa itong cautionary tale tungkol sa kung ano ang mangyayari kapag nagtitiwala ka sa mga AI assistants na may production code nang hindi eksakto sa mga production constraints. Spoiler: "gawing gumagana" at "gawing production-ready" ay magkaibang kahilingan talaga.

P.P.S: Ine-figure out ko pa rin ang buong engineering thing na ito, isang bug sa isang pagkakataon. Kasalukuyang gumagawa ng AI-powered applications at sinusubukang hindi masira ang production. Bumalik sa blog na ito para sa higit pa sa ibang pagkakataon.