Todo lo que un agente necesita saber

# Contexto completo — Erivan Valois · Entrevista Smartly

> **Qué es este documento.** El contexto íntegro para que un agente (de texto o de voz) pueda
> entrevistar, corregir o preparar a Erivan sin haber estado en la conversación original.
> Incluye su perfil con **números verificados contra los repositorios**, la empresa, el proceso
> conocido, los sistemas publicados con sus URLs, el marco técnico que usa, respuestas modelo y
> las reglas de honestidad.
>
> **Cómo usarlo.** Para un agente de texto: súbelo como contexto o pégalo entero. Para un agente
> de voz: usa solo la sección 8 (Brief corto), porque corta el contexto largo.
>
> **Convención de honestidad.** Lo marcado como **[verificado]** lo medí ejecutando comandos sobre
> los repositorios. **[declarado]** viene de su CV o su dossier y no lo pude comprobar.
> **[inferido]** es interpretación mía. No mezclar las tres.

---

## Índice

1. [La persona](#1-la-persona)
2. [Cronología](#2-cronología)
3. [La empresa: Smartly](#3-la-empresa-smartly)
4. [El puesto y el proceso](#4-el-puesto-y-el-proceso)
5. [Los sistemas publicados](#5-los-sistemas-publicados)
6. [El portafolio, con números verificados](#6-el-portafolio-con-números-verificados)
7. [El marco técnico que usa](#7-el-marco-técnico-que-usa)
8. [Brief corto para un agente de voz](#8-brief-corto-para-un-agente-de-voz)
9. [Respuestas modelo](#9-respuestas-modelo)
10. [Huecos y reglas de honestidad](#10-huecos-y-reglas-de-honestidad)
11. [Preguntas que él debe hacer](#11-preguntas-que-él-debe-hacer)
12. [Qué no hacer](#12-qué-no-hacer)
13. [Glosario del dominio](#13-glosario-del-dominio)

---

## 1. La persona

**Erivan Eder Valois Espinosa.** Ciudad de México. `edervalois88@gmail.com` · `+52 56 3355 1085` ·
`github.com/edervalois88` (18 repos públicos, cuenta desde 2018).

Ingeniero de frontend con perfil poco común: **quince años en tecnología, diez de ellos en frontend,
y ocho dirigiendo tecnología como CTO o director** antes de volver a un rol técnico hands-on.

Su posicionamiento en una frase: *"construyo herramientas operativas donde lo difícil no es el diseño
visual, es el estado"*.

Lo que lo distingue, en orden de fuerza para esta entrevista:

1. **Lidera el frontend de una plataforma empresarial real** con más de mil componentes y treinta y
   siete contribuyentes, y sigue escribiendo código a diario.
2. **Convierte convenciones en máquinas**: en lugar de documentar reglas, escribe linters y reglas de
   CI que fallan el build. Lo hizo en su trabajo y en sus proyectos personales.
3. **Construye y publica**: en una semana produjo y desplegó cuatro artefactos web funcionando, más
   un orquestador de agentes de IA en producción interna.
4. **Sabe de negocio**: fue CTO y redujo costo de TI un 68 %; entiende el trade-off de coste y riesgo,
   no solo de arquitectura.

Idiomas: español nativo, **inglés avanzado** (reuniones técnicas, documentación, colaboración global),
francés básico. Disponibilidad: híbrido un día por semana en CDMX.

---

## 2. Cronología

Memorizarla: sostiene todo lo demás.

| Periodo | Rol | Organización |
|---|---|---|
| 2008 – 2017 | Jefe de Depto. de Capacitación y Desarrollo; antes desarrollador y DBA | INBA (sector público) |
| 2017 – 2020 | Director de Tecnología y Desarrollo | Grupo Filoa SAPI (retail) |
| 2020 – 2025 | **Chief Technology Officer** | Escala Inc (23 sedes en México y Europa) |
| Mar – Nov 2025 | Subdirector de Tecnologías de la Información | TOBB (CAT de CONADE) |
| **Nov 2025 – hoy** | **Tech Lead / Arquitecto de Software** | **Rubidex** (plataforma BMS) |

**IA generativa en producción, cuatro despliegues** (2,5 años, no más):

| Fecha | Proyecto | Industria | Marco |
|---|---|---|---|
| Ene 2024 | Robot Bar RK | Hospitalidad | Empleo (Escala) |
| Mar 2025 | LMS de la ENED (video generativo + tutor RAG) | Sector público | Empleo (TOBB) |
| Mar–Abr 2025 | Matrix Gemma | Minería | **Pro bono**, no empleo |
| Nov 2025 – hoy | BMS Intel | Edificios inteligentes | Empleo (Rubidex) |

> Si preguntan "¿cuántos años en IA?": **dos y medio en IA generativa productiva, quince en
> tecnología.** No estirar el número.

---

## 3. La empresa: Smartly

**Confirmado:** el cliente es **Smartly** (`smartly.io`). La reclutadora, Corina Arellano, escribe
desde `@smartly.io` y los correos se titulan *"Interview with Smartly"*. La vacante de CodersLink
describe *"a U.S.-based advertising technology company"* con *"creative automation at massive scale"*.

**Qué es.** Empresa finlandesa (Helsinki) de publicidad con IA. Se define a sí misma como
*"not a media platform, not a creative studio"*: vende la capa donde **creativo y medios** trabajan
juntos. Tres suites — **Creative**, **Media**, **Intelligence** — más **Synapse**, su capa de agentes
de IA. [Fuente: smartly.io/creative-suite]

**La Creative Suite, en detalle** (es donde caería su rol):

- **Template Editors** de imagen, video, audio y **HTML5**; importan plantillas desde **After Effects,
  Photoshop, Figma y Google Web Designer**.
- **DCO** (*dynamic creative optimization*): *"one concept, thousands of variants"*, localizadas en
  tiempo real por **región, idioma y demografía**.
- **Brand governance** dentro del flujo, no al final.
- **Pre-flight insights** con IA: heatmaps, *attention scores*, *decay curves* — predecir rendimiento
  antes de publicar.
- **Canales:** social, *conversational commerce*, **CTV** (200+ servicios de streaming), open web
  (DSPs) y video.
- **Equipos usuarios:** agencias, performance, marca, creativos, B2B.

**Por qué eso define el problema de frontend.** Cuatro problemas, los cuatro de interfaz:

1. **Un editor**: plantillas de HTML5/video/audio; lienzo, selección, capas, undo/redo, zoom.
2. **Un preview aislado**: una plantilla HTML5 es **código de terceros** que debe renderizarse sin
   tocar la sesión del usuario → `iframe` con origen opaco + `postMessage` validado.
3. **Volumen**: miles de variantes por concepto, mercado y formato → listas virtualizadas, previews
   con memoria acotada, renders por lotes.
4. **Gobierno y flujo**: aprobaciones, permisos por equipo y cliente, estados con reglas.

**Contexto de investigación.** Su CV y su dossier mencionan entrevistas previas con Smartly en octubre.
El proceso es largo: contactos desde el 5 de octubre, invitaciones el 6 y el 20, y entrevista el 26.

---

## 4. El puesto y el proceso

**Vacante (CodersLink):** Senior Front End Engineer · *"$106,500 MXN/mes brutos"* · Híbrido CDMX ·
Full time · 4–6 años de experiencia (los *must-haves* dicen 6+).

**Must-haves del posting:** React y TypeScript, manejo de estado y optimización de rendimiento,
aplicaciones web escalables, arquitectura de componentes, **REST APIs y flujos asíncronos**.
**Nice-to-haves:** Vite/Webpack, Jest/RTL, **exposición a funciones con IA o aplicaciones con muchos
datos**, equipos de producto transversales.

**Proceso de CodersLink (confirmado en su guía y FAQs):**

| Etapa | Quién | Idioma | Qué evalúa |
|---|---|---|---|
| Aplicación | portal | — | CV |
| Evaluación | reclutador mexicano | español | salario, reubicación, carrera |
| Evaluación | **vídeo asíncrono** | inglés | fluidez; nivel B2–C1 |
| Matching | interno | — | encaje |
| **Entrevista con la empresa** | **Smartly** | **100 % inglés** | ~2 rondas de 30–40 min |
| Oferta | CodersLink | — | respuesta en 2 días hábiles |

**Las siete preguntas publicadas de su vídeo en inglés:**

1. What's your first name?
2. What's your role / area of expertise?
3. Which tech skills do you have the most experience with?
4. **Why should a company hire you over other professionals?**
5. **Explain the project you are most proud of and your contribution.**
6. **What's the biggest failure you've had and how did you solve it?**
7. **What elements are necessary for a successful team, and why?**

**Formato técnico observado en adtech (reportes públicos de candidatos):**

- **The Trade Desk:** HR → **escribir un event emitter en vivo, 60 min** → take-home.
- **The Trade Desk (Lead):** system design + 2 problem-solving + **sesión de debugging/refactoring**.
- **StackAdapt:** live coding + system design (RTB con latencia de ms), CSS box model, estado en React.
- **Smartly:** *"Technical interview limited to front-end: how would you design a webapp? how would
  you organize this project? how would you reuse React components? how would you organize a webapp
  project if you had 100 engineers?"* — **sin preguntas de algoritmos**.

> **La pregunta que hay que tener lista: "¿cómo organizarías un proyecto con 100 ingenieros?"**

---

## 5. Los sistemas publicados

Todo está en línea, con HTTPS, y se puede abrir desde cualquier dispositivo.

| URL | Qué es | Estado |
|---|---|---|
| `https://ened.online` | Hub de todo el material | ✅ |
| `https://curso.ened.online` | **Curso de escalabilidad**: 14 lecciones, 40 diagramas animados, 59 preguntas con explicación de cada opción, modo oscuro | ✅ |
| `https://lab.ened.online` | **Laboratorio**: 6 módulos con medición real en el navegador (listas, filtrado, cascadas, ingesta, re-render, dashboards) | ✅ |
| `https://creativo.ened.online` | **Demo de automatización creativa**: brief → generación → revisión → entrega, ES/EN, oscuro, DCO por mercado, brand kit, preview aislado | ✅ |
| `https://pruebas.ened.online` | **Simulador de pruebas técnicas**: 32 predicciones, 12 retos ejecutables en Worker, 8 cazas de bugs, componentes, sistemas, simulacro de 45 min | ✅ |
| `https://voz.ened.online` | **Ensayo en voz alta**: transcribe, cronometra, cuenta muletillas y lee modelos en inglés | ✅ |
| `https://pitch.ened.online` | Pitch verificado + prompt para agente de voz | ✅ |
| `https://brief.ened.online` | Brief corto para pegar al inicio de una sesión de voz | ✅ |
| `https://plan.ened.online` | Plan de acción con cuenta atrás y casillas | ✅ |
| `https://ened.online/descargas/material-smartly.tar.gz` | Paquete con dossier, curso y código fuente | ✅ |

**El demo, en una frase:** *"la versión más pequeña y honesta de su flujo, con los tres problemas
técnicos que de verdad tiene: miles de variantes, HTML5 renderizado como código no confiable, y
generación por lotes que falla parcialmente."*

**Lo que el demo demuestra técnicamente:**

- Galería **virtualizada**: 5.000 variantes, ~35–40 tarjetas en el DOM.
- Preview en `iframe` con `sandbox="allow-scripts"` **sin** `allow-same-origin` → origen opaco.
- `postMessage` validado en **tres puertas**: `event.origin === 'null'`, `event.source ===
  iframe.contentWindow`, y esquema zod `.strict()`.
- Job con estados como **unión discriminada** (`queued | running | failed | done`) y ~4 % de fallos
  deterministas, con reintento solo de los fallidos.
- Persistencia local versionada de aprobaciones; dos niveles (revisor / cliente).
- 214 pruebas en verde; [declarado] 19 archivos de prueba.

---

## 6. El portafolio, con números verificados

### 6.1 BMS Intel — su trabajo actual (Rubidex, `Rubidex/bms-client`)

**[verificado]** medido sobre el repositorio el 25 de octubre de 2026, clonando `bms-client`:

| Métrica | Valor |
|---|---|
| Líneas TypeScript/TSX | **≈ 305.000** |
| Archivos TS/TSX | **2.363** (1.269 `.ts` + 1.094 `.tsx`) |
| Componentes | **1.033** (`src/components`) |
| Rutas de la app | **212** (`src/app`) |
| Hooks propios | **391** (`src/hooks`) |
| Commits totales | **10.224** |
| Contribuyentes | **37** |
| Commits desde nov 2025 | **3.474** |
| Commits de Erivan en ese periodo | **1.365 = 39 %** |
| Siguiente contribuyente | **510** (Marcos Rosiles) |
| Archivos de pruebas E2E | **26** (`tests/e2e`) |
| Workflows de CI | **5** |
| Código generado | solo 1.425 líneas → **no infla la cifra** |

**[declarado]** 17 módulos de negocio (edificios, activos, órdenes de trabajo, alertas, reservaciones,
commissioning, paquetería, analítica, facturación, documentación, newsletter, usuarios, organización,
configuración, tablero, análisis, operaciones) y 23 comprobadores de calidad propios, entre ellos un
**validador de contratos DTO** entre frontend y backend.

**Matiz importante:** hay una segunda versión del cliente (`bms-client-v2`) con ~62.000 líneas TS/TSX,
1.012 archivos y 5 workflows. Es una reescritura, no el total.

**Su versión declarada:** tomó el liderazgo técnico en **noviembre de 2025** sobre un producto **ya en
operación**, no lo construyó desde cero.

### 6.2 HeyDuck — su proyecto más profundo (privado)

**[verificado]**

| Métrica | Valor |
|---|---|
| Líneas TS/TSX | **73.689** (77.827 contando CSS y SQL) |
| Archivos | 1.121 (818 TS/TSX) |
| Commits | 493 en un mes |
| Reglas de arquitectura propias | **20** (más 15 de dependency-cruiser) |
| Workflows de CI | 4 |
| Pruebas | 202 archivos unitarios + 65 spec (15 E2E, 50 de API), ~2.000 casos |

Un linter propio con 20 reglas: `tenant-rls`, `no-raw-sql`, `hr-privacy`,
`no-tokens-in-web-storage`, `design-tokens-only`, `brand-fonts-only`, `file-size`,
`validated-request-bodies`, `admin-routes-require-capability`… **Es su mejor historia técnica.**

### 6.3 Otros proyectos

| Proyecto | Líneas TS/TSX | Qué demuestra |
|---|---|---|
| Valeria Rangel (privado) | 41.747 | 46 rutas, 40 tablas, 21 migraciones, borrado garantizado de datos personales, checkout idempotente con Stripe |
| PlexusMD (público) | 25.587 | Salud, multi-tenant, RBAC, auditoría |
| Frigate Console (privado) | 23.445 | Muro de video en vivo (HLS + MQTT), auth en middleware de borde que falla cerrado |
| Matrix RH | — | RAG local con Qdrant + Ollama, instalable en Windows |

### 6.4 El piloto de agentes (privado, operación interna)

Un orquestador que convierte issues de GitHub en **PRs revisados por un humano**:

- workspace aislado por tarea (`git worktree`), concurrencia y turnos limitados, presupuesto por run;
- **clasificador de fallos** que distingue *modelo* de *entorno* antes de escalar de modelo;
- credenciales del tracker **fuera** del entorno del agente;
- métricas reales: **259 ejecuciones, 46,89 USD, ~0,32 USD por run**, tres semanas;
- el merge exige etiqueta humana **y** todos los checks verdes.

**La métrica que él mismo admite que no mide todavía:** la tasa de **falso-terminado** (cuántas veces
el agente dice "listo" y no lo está). Decirlo antes de que lo pregunten es una señal de seniority.

---

## 7. El marco técnico que usa

### 7.1 Escalar no es optimizar

- **Optimizar** = hacer lo mismo más rápido. **Escalar** = cambiar lo que se rompe.
- La pregunta correcta: **"¿qué se rompe primero cuando esto crece 10x?"**
- Y la prueba de que escalaste: **la curva deja de ser una recta.** Si al duplicar usuarios se duplica
  el coste, optimizaste.

### 7.2 Los cuatro ejes

| Eje | Se rompe | Palanca |
|---|---|---|
| **Datos** (10x filas) | DOM, memoria, hilo principal | virtualizar, workers, agregar en servidor |
| **Usuarios** (10x tráfico) | primer pintado, servidor | SSR/RSC, caché, CDN, split por ruta |
| **Código/equipo** (10x ingenieros) | la coherencia | fronteras, contratos tipados, **guardarraíles en CI** |
| **Dominio** (10x formatos) | el `if` que crece | configuración tipada, uniones discriminadas |

### 7.3 El método de cinco pasos

1. **Cuello de botella** — qué se rompe primero.
2. **Medición** — con qué número lo sé.
3. **Palanca** — cuál de los cuatro ejes, y qué cuesta.
4. **Lo que no haría** — y por qué.
5. **El siguiente límite** — qué se rompe después.

El paso 5 es el que casi nadie da y el que más impresiona.

### 7.4 Cuando no sabe

> *"I haven't done it at that scale. What I do know is which resource would run out first, so let me
> reason from there."*

En un navegador solo se agotan **cuatro** cosas: nodos del DOM, tiempo del hilo principal, memoria y
red. En un servidor: conexiones, escrituras por segundo, tamaño de cola y coste de consulta.

### 7.5 El tema de adtech que separa senior de mid

**`iframe sandbox` + `postMessage`.** Lo que hay que saber decir:

- Un creativo HTML es código de terceros: no puede correr en el origen propio.
- `sandbox="allow-scripts"` **sin** `allow-same-origin` → **origen opaco**, reportado como `"null"`.
- **Los dos permisos juntos anulan el sandbox**: el frame puede quitarse el atributo a sí mismo.
- `postMessage` se valida con **tres puertas**: origen, `event.source` (porque todos los frames opacos
  comparten `"null"`), y esquema estricto.
- `targetOrigin: '*'` **es válido al enviar** a un marco opaco —no puede conocer el origen del padre—
  pero **no es validación**: la seguridad está en recibir.

---

## 8. Brief corto para un agente de voz

Texto listo para pegar antes de activar el modo de voz (~1.400 caracteres):

```
I'm interviewing tomorrow for Senior Frontend Engineer at Smartly
(AI advertising / creative automation: DCO, brand governance, HTML5
templates rendered as untrusted code).

Your job: be the hiring manager. One question at a time, in English.
Interrupt me past 90 seconds. Never give hints. After each answer ask
the hardest follow-up: why not the alternative, what breaks at 10x,
what would you do differently. If I give a number, ask how I measured
it. No praise. At the end, score 1-4 on structure, depth, evidence,
honesty, communication, and name my single worst habit.

My facts:
- I lead the frontend of an enterprise platform: 17 modules,
  1,033 components, 212 routes, ~305k lines of TypeScript, 37
  contributors, 10,224 commits.
- I joined in Nov 2025 and wrote 1,365 of the 3,474 commits since
  (39%), more than double the next contributor. Still hands-on daily.
- 5 CI workflows and 23 custom quality checks that fail the build when
  a DTO contract drifts or a translation is incomplete.
- Side project: 78k lines, 20 custom architecture rules enforced by a
  linter. Also built an AI orchestrator: issue to reviewed PR, with a
  human gate before merge.
- I published a demo of the creative-automation flow: brief,
  generation, review, delivery, with per-market localization.

Start with: "Tell me about yourself and walk me through your most
complex project."
```

---

## 9. Respuestas modelo

### 9.1 Pitch de 90 segundos (inglés)

> "I'm a frontend engineer who builds operational tools — the kind where the hard part isn't the
> visual design, it's the state.
>
> Right now I lead the frontend of an enterprise platform for smart buildings: seventeen business
> modules, a thousand components, two hundred routes, about three hundred thousand lines of
> TypeScript. I joined in November and I've contributed thirty-nine percent of the commits since then
> — more than double anyone else on the team — and I'm still writing code every day.
>
> What I'm proudest of isn't the size. It's that the architecture is enforced by a machine: five CI
> workflows and twenty-three custom checks that fail the build when a contract drifts, a translation
> is incomplete, or someone hardcodes a color instead of using a design token.
>
> And lately I've been building AI tooling — an orchestrator that turns issues into reviewed pull
> requests, with a human gate before merge. I'm looking for a team where the frontend is genuinely
> complex and owning the architecture is part of the job."

### 9.2 Los cien ingenieros (la pregunta de Smartly)

> "At a hundred engineers the bottleneck isn't code — it's coherence. With three people it lives in
> someone's head. With a hundred it has to live in the build.
>
> I'd do three things. First, explicit module boundaries with the dependency direction enforced by
> tooling, so the web layer cannot import the database. Second, typed contracts generated from the
> API schema, so frontend and backend cannot drift. Third, automated guardrails instead of a
> conventions document nobody reads.
>
> I wrote twenty such rules for a project with one author, because I didn't want to be the memory of
> the system. The cost is real: writing a rule takes longer than saying it in a meeting. But a rule
> in CI survives people being in a hurry, and a rule in a document does not."

### 9.3 La apertura del demo

> "You do DCO and brand governance at scale. I built the smallest honest version of that flow —
> brief, generation, review, delivery — with the three technical problems it actually has.
> Thousands of variants, so the gallery is virtualised: five thousand variants, about forty cards in
> the DOM. HTML5 rendered as untrusted code, so the preview runs in a sandboxed iframe with an opaque
> origin and every message validated in three gates. And batch generation that fails partially,
> because in the real world some variants fail and the user needs to retry only those."

### 9.4 Smartly en 60 segundos

> "Smartly is an AI advertising platform. They're explicit that they're not a media platform and not
> a creative studio. They sell the layer where creative and media work together: a Creative suite
> that produces and personalises variants, a Media suite for activation, and Intelligence for
> measurement. The core idea is dynamic creative optimisation — one concept, thousands of variants,
> localised by region, language and demographic — with brand governance built into the workflow
> instead of bolted on at the end."

### 9.5 Por qué esta empresa

> "What I want is the version of this problem with real scale. Creative automation looks like a
> marketing problem and it's actually a frontend problem: an editor, a rendering pipeline and a data
> console, where the hard parts are state, isolation and volume. That's what I've been building. Here
> those problems come with millions of creatives instead of thousands, and that's the interesting
> part."

---

## 10. Huecos y reglas de honestidad

**Una sola exageración detectada tira todo lo demás, y lo demás es muy bueno.**

| No decir | Decir |
|---|---|
| "Aporto el triple que el siguiente" | **"More than double"** — son 1.365 contra 510, dos coma siete veces |
| "El frontend son 175.000 líneas" sin matiz | "Eran 175.000 cuando lo medí; hoy son más de 300.000" |
| "Construí BMS desde cero" | "Tomé el liderazgo técnico en noviembre de 2025 sobre un producto ya en operación" |
| "Soy CTO" | Fue CTO cuatro años; ahora es Tech Lead hands-on. Una línea, no una identidad |
| "Dominio QLoRA, DPO, instruction tuning" | "LoRA sí, sobre un cross-encoder; QLoRA y alineación por preferencias no los he usado" |
| "Opero Kubernetes" | "El backend que coordino despliega en Kubernetes; yo no lo he operado hands-on. Docker sí" |
| "Uso Pinecone / pgvector / Elasticsearch" | "Qdrant y ChromaDB" |
| "Los evals con LLM están probados" | Están implementados y **no ejecutados** por falta de credencial |
| "Conozco CNBV o Banxico" | No. Lo cercano: NOM-035, ISO 27001, integración fiscal ante el SAT |

**Cómo se dice un hueco sin perder la entrevista:** nombrar el hueco, decir lo más cercano que sí
tiene, y cerrar con cómo lo cerraría.

**Huecos reales frente a esta vacante:**

- No ha trabajado en un equipo de frontend de 20+ personas *como IC*; ha liderado. No esconderlo:
  convertirlo en "sé cómo se ve desde arriba y sigo escribiendo código".
- No ha operado un editor gráfico colaborativo (CRDT/OT). Su experiencia más cercana es el estado
  complejo y el aislamiento de contenido.
- No tiene React Query en sus proyectos propios (usa capas propias); sí lo conoce conceptualmente y
  lo declara como conocimiento, no como experiencia profunda.

---

## 11. Preguntas que él debe hacer

Elegir tres. Todas de dominio, ninguna de beneficios:

1. *"Where does the bottleneck hurt more today — producing the variants, or getting them approved and
   trafficked?"*
2. *"How do you render HTML5 templates safely — client-side in a sandbox, or server-side?"*
   ← **la mejor**: es su problema técnico real y demuestra que entiende el producto.
3. *"How does the frontend split ownership between the editor, the review flow and the data side?"*
4. *"How do you decide when a creative is good enough to ship — is there a pre-flight gate or does the
   reviewer own that judgement?"*
5. *"What's the biggest source of friction between frontend and backend right now?"*

---

## 12. Qué no hacer

- **No decir "está listo para producción"** sobre el demo. Es una demo: decirlo lo debilita todo.
- **No afirmar que el iframe es "100 % seguro".** Es "aislado tanto como el navegador permite".
- **No decir "son 5.000 tarjetas renderizadas".** Son ~40 montadas. El logro es no renderizarlas.
- **No fingir que conoce Smartly de años.** Sabe su producto y su categoría; eso basta.
- **No hablar 6 minutos seguidos.** El entrevistador tiene 40 y tres preguntas más.
- **No inventar métricas de negocio** (CTR, conversión) que no pueda medir.

---

## 13. Glosario del dominio

| Término | Significado |
|---|---|
| **Creative automation** | Producir cientos o miles de piezas publicitarias desde plantillas y datos, sin diseño manual |
| **DCO** | *Dynamic creative optimization*: un concepto, muchas variantes, personalizadas por audiencia, región e idioma |
| **Brand governance** | Reglas de marca (logo, color, tipografía, tono) verificadas dentro del flujo de producción |
| **Pre-flight** | Validación antes de publicar: el creativo cumple especificaciones y políticas |
| **Trafficking** | Publicar y distribuir las piezas en los canales (Meta, Google, TikTok, CTV…) |
| **Safe area** | Margen que ningún elemento importante debe invadir en un formato de anuncio |
| **Template editor** | Herramienta donde se diseña la plantilla que genera las variantes |
| **DSP** | Plataforma de compra programática de medios |
| **CTV** | *Connected TV*: anuncios en televisores conectados y streaming |
| **Viewability** | Que el anuncio se haya visto de verdad: medido por tiempo visible y superficie |
| **Impression** | Una visualización registrada del anuncio |
| **CTA** | *Call to action*: la llamada a la acción del anuncio |

---

## Cierre

Lo que este documento describe es una persona con **quince años de oficio, ocho dirigiendo y dos y
medio en IA productiva**, que hoy lidera técnicamente una plataforma de mil componentes sin dejar de
escribir código, y que en la última semana construyó y publicó cuatro sistemas web para preparar esta
entrevista.

La conversación que hay que tener no es "¿sabes React?". Es: **"¿entiendes por qué automatizar
creatividad a escala es un problema de estado, aislamiento y volumen — y sabes construirlo?"**