De la publicidad a la ingeniería: lecciones técnicas de construir DIALØGUE

*Esta es la inmersión técnica complementaria a mi introducción de DIALØGUE. Si no has leído sobre qué es DIALØGUE y por qué lo construí, ¡empieza por ahí!*

El camino: de profesional de la publicidad a ingeniero full-stack

Bien, abordemos el elefante en la habitación — sí, vengo de la publicidad. Sí, planes de medios y briefs creativos, no estructuras de datos y algoritmos. Pero aquí está lo curioso: entender cómo funcionan los sistemas, ya sea un funnel de marketing o una arquitectura distribuida, requiere la misma mentalidad analítica. ¿La diferencia? En ingeniería, cuando la cagas, el ordenador te lo dice de inmediato. Sin esperar los resultados de la campaña, jaja.

Construir DIALØGUE ha sido… intenso. No es solo escribir código (aunque ha habido mucho de eso). Es arquitectar un sistema complejo que de alguna manera necesita orquestar múltiples servicios de IA, manejar flujos de trabajo asíncronos y no derrumbarse cuando los usuarios hacen cosas inesperadas. Permíteme compartir lo que este viaje me ha enseñado de verdad — lo bueno, lo frustrante y los momentos de "¿por qué nadie me dijo esto antes?".

Decisiones de arquitectura: por qué la complejidad es el enemigo

Aquí hay algo que nadie te dice cuando estás empezando: la complejidad no es tu amiga. Lo aprendí de la manera difícil. Muy difícil. Imagíname ahogado en logs de CloudWatch, intentando entender por qué mi sistema bellamente arquitectado… bueno, no funcionaba. T.T

Arquitectura inicial (excesivamente compleja)

Así que empecé con LangGraph para la orquestación. ¿Por qué? ¡Porque el enfoque basado en grafos parecía tan elegante! ¡Me daría flexibilidad! ¡Escalaría beautifully!

Choque con la realidad: era dolorosamente lento. Incluso corriendo localmente. Incluso con su despliegue en la nube. Toda esa hermosa abstracción era simplemente… sobrecarga. Mucha, mucha sobrecarga.

Arquitectura final (pragmáticamente simple)

Después de mucho reflexionar (y depurar), esto es lo 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 a GCP Cloud Run/Workflows en julio de 2025, logrando una reducción de costes del 92% y una mejora de rendimiento 10x.

La gran revelación: Cuando cambié a consultas directas de Supabase en lugar de envolver todo en APIs, obtuve una mejora de rendimiento 10x (450ms → 45ms). ¿Toda esa capa de API "correcta"? Solo estaba frenando todo. Esta arquitectura database-first se convirtió en la base de nuestra migración a GCP.

Selección de modelos de IA: más allá del hype

La realidad del panorama de modelos

Bien, hablemos de modelos de IA. Los he probado todos. De verdad — no solo jugado con ellos una tarde. Después de meses de pruebas (y quemando más créditos de API de los que me gustaría admitir), esto es lo que realmente funciona cuando estás construyendo algo real:

Mi stack actual:

- Claude (via Claude code) & Gemini 2.5 Pro (via Gemini CLI): Mi dúo de desarrollo principal. Estos dos modelos se han vuelto tan capaces que han reemplazado esencialmente todo lo demás en mi flujo de trabajo.

- Claude Sonnet 4 API: Impulsa la generación de guiones de DIALØGUE con temperatura 0 para fiabilidad JSON

Lo que incluía mi stack antes:

DeepSeek: Solía apoyarme en este para depurar errores complicados, especialmente en sesiones de resolución de problemas nocturnas. Pero una vez que llegaron Claude 4 y Gemini 2.5 Pro, ¿manejan esos casos extremos igual de bien, si no mejor. La evolución en la capacidad de los modelos hizo que los modelos de depuración especializados fueran redundantes para mi flujo de trabajo.

Lo que realmente funciona:

Aquí es donde las cosas se ponen interesantes: cada modelo es ya increíblemente potente por sí solo. Claude es brillante en el pensamiento arquitectónico y el razonamiento complejo. ¿Gemini 2.5 Pro? Absolutamente fenomenal en la implementación y el mantenimiento del contexto a lo largo de codebases masivos. El salto de Gemini 2.0 a 2.5 fue una locura — literalmente podía sentir la diferencia. Respuestas más rápidas, ventana de contexto de 1M tokens (sí, de verdad), y realmente entiende lo que estoy intentando construir.

Pero aquí es donde ocurre la magia real: cuando los haces criticar el trabajo del otro. Haré que Claude diseñe un enfoque y luego le pediré a Gemini que lo revise y sugiera mejoras. O Gemini generará una solución y le pediré a Claude que la analice en busca de casos extremos o preocupaciones arquitectónicas. Ese ir y venir, ese proceso de crítica colaborativa — ahí es donde encuentras las soluciones revolucionarias que ninguno habría alcanzado por sí solo.

Lo que no funcionó (a pesar del hype):

• OpenAI o1/o3: Todo el mundo habla de estos, pero ¿para el desarrollo real? Demasiado lentos, demasiado caros y, honestamente, no son tan superiores para mis casos de uso.
• GitHub Copilot Workspace: Gran idea, pero esos límites de tokens… me seguía topando con el techo cada vez que intentaba hacer algo sustancial

La revelación real: ¿Sabes qué nadie te dice? Los distintos modelos fallan de manera diferente. El Gemini antiguo se atascaba en estos bucles extraños con ciertos errores — simplemente no podía ver el problema. Claude lo identificaba de inmediato. Pero luego Claude sobreanalizaba implementaciones simples que Gemini resolvía en segundos. El truco no es encontrar el modelo "mejor" — es saber cuándo cambiar.

Desarrollo full-stack: llevando múltiples sombreros

La estrategia de terminales

Aquí hay algo práctico que realmente me salvó la cordura: ventanas de terminal separadas para diferentes contextos. ¿Suena simple? Es un cambio de juego.

```bash
# Terminal 1: El yo desarrollador frontend
cd podcast_generator_frontend_v2
npm run dev
# Aquí es donde pienso en componentes React y experiencia de usuario

# Terminal 2: El yo desarrollador backend
cd gcp_services
./deploy/deploy-service.sh [service-name]
# Aquí viven los servicios Cloud Run (¡mucho más felices que Lambda!)

# Terminal 3: El yo de base de datos
supabase start --workdir supabase
# Supabase local para pruebas, producción para el trabajo real
```

Sé que suena ridículo, pero cambiar físicamente entre terminales ayuda a mi cerebro a cambiar de contexto. El yo frontend y el yo backend son personas diferentes, y necesitan sus propios espacios.

Comunicación entre stacks

Trabajar en solitario en full-stack es extraño. Básicamente estás teniendo conversaciones contigo mismo. Así que empecé a dejar notas:

```
// Nota del yo frontend para el yo backend
/**
 * BACKEND TODO:
 * - Necesito endpoint GET /api/podcasts/:id/segments
 * - Debe devolver: { segments: Array<{id, title, status, content}> }
 * - Debe manejar: 404 (no encontrado), 403 (no autorizado)
 * - Las actualizaciones en tiempo real via suscripción Supabase serían ideales
 * - ¡El yo futuro te agradecerá el manejo de errores!
 */
```

```
## Resumen del desarrollador backend para integración frontend
Estado actual:
- Endpoints implementados: POST /podcasts, GET /podcasts/:id
- Autenticación: Bearer token via Supabase JWT
- Tiempo real: canal Supabase "podcast-updates"

Próximas tareas frontend:
1. Implementar formulario de creación de podcasts
2. Suscribirse a actualizaciones en tiempo real
3. Manejar estados de error (401, 403, 404, 500)
```

¿Estas pequeñas notas? Salvavidas absolutos cuando vuelvo al código después de una semana y no tengo ni idea de qué estaba pensando el yo del pasado.

Conclusiones técnicas clave

1. El pensamiento en sistemas trasciende los dominios

Mi formación en publicidad me enseñó a pensar en sistemas — recorridos de usuario, embudos de conversión, modelos de atribución. Estos modelos mentales se traducen directamente en:

• Diseño de sistemas distribuidos
• Flujos de experiencia de usuario
• Optimización del rendimiento
• Estrategias de manejo de errores

2. Mentalidad production-first

# Lo que aprendí a priorizar

if works_in_production and meets_user_needs:

ship_it()

else:

fix_only_blockers()

# Lo perfecto es enemigo de lo bueno

3. La competencia full-stack es real

Construir DIALØGUE requirió:

• Frontend: React 19, Next.js 15, TypeScript, suscripciones en tiempo real, gestión de WebSocket (¡fugas de memoria corregidas!)
• Backend: Python 3.12, Cloud Run (14 microservicios), Cloud Workflows, PostgreSQL (via Supabase)
• Infraestructura: GCP (migrado desde AWS), API Gateway, Cloud Storage, Vercel para frontend
• AI/ML: Claude 4.0, Perplexity API, OpenAI TTS, optimización de temperatura (0 para JSON)
• DevOps: Contenedores Docker, Cloud Build, monitoreo, seguridad JWT (migración P-256)
• Base de datos: PostgreSQL con RLS, Edge Functions, operaciones atómicas para prevención de condiciones de carrera

4. La importancia de la formación clásica

Tener formación formal en ingeniería de software (diseño de sistemas, estructuras de datos, algoritmos) resultó invaluable. No se trata solo de conseguir que la IA escriba código — se trata de saber qué pedir y cómo arquitectarlo.

Reflexiones finales

Aquí es donde he llegado después de todo esto: construir DIALØGUE ha cambiado completamente cómo me veo a mí mismo profesionalmente. Antes era el tipo que gestionaba equipos técnicos. ¿Ahora? Puedo construir junto a ellos. Y honestamente, eso se siente bastante increíble. :D Esa evolución continuó cuando empecé a construir una app nativa iOS sin saber Swift — resulta que las habilidades de publicidad (el gusto, la dirección creativa, saber qué significa "bueno") importan más que las habilidades de programación.

El camino de la publicidad a la ingeniería no es solo aprender sintaxis o frameworks. Es reprogramar tu cerebro para pensar en sistemas, para depurar metódicamente, y para aceptar que a veces pasarás 3 horas con un punto y coma que falta (bueno, TypeScript los detecta, pero ya entiendes la idea).

¿Sabes qué es gracioso? El pensamiento analítico de la publicidad — entender los recorridos de usuario, optimizar los embudos de conversión, todo eso — se traduce directamente a la ingeniería. La diferencia es que en el código, cuando algo no funciona, el ordenador te lo dice de inmediato. Sin esperar los informes de campaña. Solo retroalimentación inmediata y brutal.

El "producto" está en vivo en podcast.chandlernguyen.com. Funciona. No es perfecto, pero es mío. Y cada corrección de errores, cada adición de funcionalidad, cada momento "¡ajá!" — todos son parte de este viaje continuo.

¿Alguna vez has hecho un gran cambio profesional como este — de un dominio a algo completamente diferente? Me encantaría escuchar qué te sorprendió más de la transición. ¡Cuéntame!

Un abrazo,

Chandler

P.D.: Hablando de aprender las cosas a las malas — ¿quieres saber cómo un pequeño cambio en un parámetro de IA me costó $54/mes? Mira Un cambio en un parámetro de IA me costó $54/mes. Es una historia con moraleja sobre lo que pasa cuando confías en asistentes de IA con código de producción sin ser explícito sobre las restricciones de producción. Spoiler: "hazlo funcionar" y "hazlo listo para producción" son peticiones muy diferentes.

P.P.D.: Todavía estoy descubriendo todo este tema de la ingeniería, un bug a la vez. Actualmente construyendo aplicaciones con IA e intentando no romper la producción. Vuelve a este blog para más tarde.