Da Publicidade à Engenharia: Lições Técnicas de Construir o DIALØGUE

*Este é o mergulho técnico profundo complementar à minha introdução do DIALØGUE. Se você ainda não leu sobre o que o DIALØGUE é e por que o construí, comece por lá!*

A Jornada: De Profissional de Publicidade a Engenheiro Full-Stack

Ok, vamos falar logo do elefante na sala — sim, venho da publicidade. Planos de mídia e briefings criativos, não estruturas de dados e algoritmos. Mas aqui está a coisa engraçada: entender como sistemas funcionam, seja um funil de marketing ou uma arquitetura distribuída, requer a mesma mentalidade analítica. A diferença? Na engenharia, quando você erra, o computador te avisa imediatamente. Sem esperar pelos resultados da campanha, haha.

Construir o DIALØGUE foi… intenso. Não é só escrever código (embora tenha sido muito disso). É arquitetar um sistema complexo que precisa orquestrar múltiplos serviços de IA, lidar com workflows assíncronos e não desmoronar quando usuários fazem coisas inesperadas. Deixa eu compartilhar o que essa jornada realmente me ensinou — o bom, o frustrante e os momentos de "por que ninguém me disse isso?".

Decisões de Arquitetura: Por Que Complexidade é o Inimigo

Aqui está algo que ninguém te conta quando você está começando: complexidade não é sua amiga. Aprendi isso do jeito difícil. De verdade difícil. Me imagina afogado em logs do CloudWatch, tentando descobrir por que meu sistema lindamente arquitetado estava… bem, não funcionando. T.T

Arquitetura Inicial (Excessivamente Complexa)

Comecei com LangGraph para orquestração. Por quê? Porque a abordagem baseada em grafo parecia tão elegante! Me daria flexibilidade! Escalaria lindamente!

A realidade: Era dolorosamente lenta. Mesmo rodando localmente. Mesmo com o deploy na nuvem deles. Toda aquela abstração linda era apenas… overhead. Muito, muito overhead.

Arquitetura Final (Pragmaticamente Simples)

Depois de muito soul-searching (e debugging), aqui está o que realmente funciona:

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

Nota: Migramos de AWS Lambda/Step Functions para GCP Cloud Run/Workflows em julho de 2025, alcançando 92% de redução de custos e melhoria de performance 10x.

A Grande Revelação: Quando mudei para queries Supabase diretas em vez de envolver tudo em APIs, obtive uma melhoria de performance 10x (450ms → 45ms). Toda aquela camada "adequada" de API? Estava apenas desacelerando tudo. Essa arquitetura database-first se tornou a fundação da nossa migração para GCP.

Seleção de Modelo de IA: Além do Hype

A Realidade do Cenário de Modelos

Ok, vamos falar sobre modelos de IA. Já testei todos. De verdade — não apenas brinquei por uma tarde. Depois de meses de testes (e queimando mais créditos de API do que gostaria de admitir), aqui está o que realmente funciona quando você está construindo algo real:

Minha Stack Atual Favorita:

- Claude (via Claude code) & Gemini 2.5 Pro (via Gemini CLI): Minha dupla de desenvolvimento principal. Esses dois modelos se tornaram tão capazes que essencialmente substituíram tudo mais no meu workflow.

- Claude Sonnet 4 API: Alimenta a geração de scripts do DIALØGUE com temperatura 0 para confiabilidade JSON

O Que Minha Stack Costumava Incluir:

DeepSeek: Costumava depender disso para debugar bugs complicados, especialmente em sessões de troubleshooting tardias. Mas uma vez que Claude 4 e Gemini 2.5 Pro chegaram? Eles lidam com esses casos de borda tão bem, se não melhor. A evolução na capacidade dos modelos tornou os modelos especializados de debugging redundantes para o meu workflow.

O Que Realmente Funciona:

Aqui é onde as coisas ficam interessantes: cada modelo já é incrivelmente poderoso por conta própria. Claude é brilhante no pensamento arquitetural e raciocínio complexo. Gemini 2.5 Pro? Absolutamente fenomenal em implementação e manutenção de contexto em codebases massivos. O salto do Gemini 2.0 para o 2.5 foi insano — eu literalmente sentia a diferença. Respostas mais rápidas, janela de contexto de 1M tokens (sim, de verdade) e ele realmente entende o que estou tentando construir.

Mas aqui está onde a mágica real acontece: quando você os faz criticar o trabalho um do outro. Faço Claude projetar uma abordagem, então peço ao Gemini para revisar e sugerir melhorias. Ou Gemini gera uma solução, e faço Claude analisá-la em busca de casos de borda ou preocupações arquiteturais. Esse vai e vem, esse processo de crítica colaborativa — é aí que você encontra as soluções que nenhum deles teria alcançado sozinho.

O Que Não Funcionou (Apesar do Hype):

OpenAI o1/o3: Todo mundo fala sobre esses, mas para desenvolvimento real? Lentos demais, caros demais e honestamente não muito melhores para meus casos de uso.
GitHub Copilot Workspace: Boa ideia, mas esses limites de token… Ficava batendo no teto toda vez que tentava fazer algo substancial

O Real Insight: Sabe o que ninguém te conta? Modelos diferentes falham de formas diferentes. O Gemini inicial ficava preso em loops estranhos em certos erros — simplesmente não conseguia ver o problema. Claude identificava imediatamente. Mas então Claude pensava demais em implementações simples que Gemini acertava em segundos. O truque não é encontrar o modelo "melhor" — é saber quando mudar.

Desenvolvimento Full-Stack: Usando Múltiplos Chapéus

A Estratégia de Terminal

Aqui está algo prático que realmente salvou minha sanidade: janelas de terminal separadas para contextos diferentes. Parece simples? É revolucionário.

```bash
# Terminal 1: Eu como Desenvolvedor Frontend
cd podcast_generator_frontend_v2
npm run dev
# É aqui que penso sobre componentes React e experiência do usuário

# Terminal 2: Eu como Desenvolvedor Backend
cd gcp_services
./deploy/deploy-service.sh [service-name]
# É aqui que os serviços Cloud Run vivem (muito mais feliz do que Lambda!)

# Terminal 3: Eu como DBA
supabase start --workdir supabase
# Supabase local para testes, produção para o trabalho real
```

Eu sei que parece ridículo, mas fisicamente alternar entre terminais ajuda meu cérebro a mudar de contexto. O eu frontend e o eu backend são pessoas diferentes, e precisam dos seus próprios espaços.

Comunicação Entre Stacks

Trabalhar solo em full-stack é estranho. Você basicamente está tendo conversas consigo mesmo. Então comecei a deixar notas:

```
// Nota do Eu Frontend para o Eu Backend
/**
 * 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!
 */
```

```
## Resumo do Desenvolvedor Backend para Integração Frontend
Estado Atual:
- Endpoints implementados: POST /podcasts, GET /podcasts/:id
- Autenticação: Bearer token via Supabase JWT
- Real-time: Supabase channel "podcast-updates"

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

Essas pequenas notas? Salva-vidas absolutos quando volto ao código depois de uma semana e não faço ideia do que o eu do passado estava pensando.

Principais Aprendizados Técnicos

1. Pensamento Sistêmico Transcende Domínios

Minha experiência em publicidade me ensinou a pensar em sistemas — jornadas do usuário, funis de conversão, modelos de atribuição. Esses modelos mentais se traduzem diretamente para:

Design de sistemas distribuídos
Fluxos de experiência do usuário
Otimização de performance
Estratégias de tratamento de erros

2. Mentalidade Production-First

# O que aprendi a priorizar

if works_in_production and meets_user_needs:

ship_it()

else:

fix_only_blockers()

# Perfeito é o inimigo do feito

3. Competência Full-Stack é Real

Construir o DIALØGUE exigiu:

Frontend: React 19, Next.js 15, TypeScript, real-time subscriptions, gerenciamento de WebSocket (vazamentos de memória corrigidos!)
Backend: Python 3.12, Cloud Run (14 microsserviços), Cloud Workflows, PostgreSQL (via Supabase)
Infraestrutura: GCP (migrado de AWS), API Gateway, Cloud Storage, Vercel para frontend
AI/ML: Claude 4.0, Perplexity API, OpenAI TTS, otimização de temperatura (0 para JSON)
DevOps: Containers Docker, Cloud Build, monitoramento, segurança JWT (migração P-256)
Banco de dados: PostgreSQL com RLS, Edge Functions, operações atômicas para prevenção de race conditions

4. A Importância do Treinamento Formal

Ter treinamento formal em engenharia de software (design de sistemas, estruturas de dados, algoritmos) provou ser inestimável. Não se trata apenas de fazer IA escrever código — é sobre saber o que pedir e como arquitetar.

Considerações Finais

Então é aqui que cheguei depois de tudo isso: Construir o DIALØGUE mudou completamente como me vejo profissionalmente. Costumava ser o cara que gerenciava equipes técnicas. Agora? Posso realmente construir ao lado delas. E honestamente, isso é uma sensação incrível. :D Essa evolução continuou quando comecei a construir um app nativo para iOS sem saber Swift — acontece que as habilidades de publicidade (gosto, direção criativa, saber como "bom" se parece) importam mais do que as habilidades de programação.

A jornada da publicidade à engenharia não é apenas sobre aprender sintaxe ou frameworks. É sobre reprogramar seu cérebro para pensar em sistemas, depurar metodicamente, e aceitar que às vezes você vai passar 3 horas em um ponto e vírgula faltando (ok, TypeScript pega esses, mas você entendeu o ponto).

Sabe o que é engraçado? O pensamento analítico da publicidade — entender jornadas do usuário, otimizar funis de conversão, todo esse bagulho — se traduz diretamente para engenharia. A diferença é que no código, quando algo não funciona, o computador te diz imediatamente. Sem esperar relatórios de campanha. Apenas feedback imediato e brutal.

O "produto" está ao vivo em podcast.chandlernguyen.com. Funciona. Não é perfeito, mas é meu. E cada bug corrigido, cada adição de funcionalidade, cada momento de "eureka!" — todos fazem parte dessa jornada contínua.

Você já fez uma grande virada de carreira assim — de um domínio para algo completamente diferente? Adoraria saber o que mais te surpreendeu na transição. Me conta!

Abraços,

Chandler

P.S: Falando em aprender do jeito difícil — quer saber como uma pequena mudança de parâmetro de IA me custou US$ 54/mês? Confira Uma Mudança de Parâmetro de IA Me Custou $54/Mês. É uma história de advertência sobre o que acontece quando você confia em assistentes de IA com código de produção sem ser explícito sobre restrições de produção. Spoiler: "fazer funcionar" e "fazer funcionar em produção" são pedidos muito diferentes.

P.P.S: Ainda estou descobrindo esse mundo de engenharia, um bug por vez. Atualmente construindo aplicações com IA e tentando não quebrar produção. Volte a este blog para mais em breve.