Felipe Campos AI Product Engineer · Design Engineer

Vigilancia del mercado de seguros vehiculares para una corredora de seguros · 2026

Observatorio de Precios

Captura programada de fuentes públicas, detección de movimientos y un panel que dice en segundos si el mercado se movió.

Relato · La corrida

Las páginas entran, el extractor saca lecturas, el embudo las transforma y filtra, la serie las ordena por tipo y vigencia y el panel las reporta. En loop, 24/7.

Escena 3D: siete páginas flotan sobre un embudo; un haz las recorre y suelta lecturas que caen, se vuelven esferas en la puerta o se descartan, y se ordenan en una rejilla por tipo y vigencia; a la derecha un panel levanta barras; una página marcada en ámbar no responde.
  1. Páginas y APIs públicas Decenas de fuentes públicas. En cada corrida programada el extractor las recorre y saca sus lecturas.
  2. Embudo Cada lectura cruda se transforma a una estructura fija. Lo que no sirve se descarta en la puerta.
  3. Carga y orden Lo sano se carga en la serie histórica, ordenado por tipo y vigencia, y se compara con el último levantamiento.
  4. Panel de reportabilidad Dice en segundos si el mercado se movió: una barra por tipo y la señal del cambio.
  5. 24/7 con diagnóstico y alertas Una fuente sin respuesta se marca en ámbar y su última lectura sana se arrastra. La serie no se cae.
Escena estática Escena ilustrativa del flujo, no captura de producto. Mueve el puntero para empujar las lecturas.
Rol
AI Product Engineer: del diagnóstico sobre el dato al panel en operación
Año
2026
Duración
septiembre 2026 – presente
Estado
En operación real, con iteración diaria junto al usuario

Caso sanitizadoEste caso se publica en versión sanitizada: el nombre del producto, la empresa, las fuentes y las cifras de mercado se generalizan. Describe el problema, mi rol, la arquitectura, el método y los aprendizajes.

Problema

Qué fallaba y para quién

La dirección comercial de una corredora de seguros no tenía una vista que dijera en segundos si el mercado de seguros vehiculares se movió y dónde importa: había que revisar planillas o preguntar, y el cuadro de precios se cargaba a mano. Antes de diseñar se midió el mercado sobre la serie capturada: casi estático en el precio y muy disperso entre canales. Lo valioso no era el precio, era el movimiento y la dispersión. Por eso el producto vigila el mercado; no fija precio, no elige proveedor, no vende.

Relato · De dónde a dónde

  1. Planillas revisar a mano, cada vez
  2. Preguntar depender de alguien que sepa
  3. Segundos abrir el panel y ver qué se movió

Qué se hizo

Entregables concretos

  • Captura programada con puerta de sanidad: un orquestador recorre decenas de fuentes públicas varias veces por día hábil desde GitHub Actions, con disparo de respaldo por Lambda y por una máquina local; una puerta decide si la corrida es sana antes de derivar nada.
  • Modelo de dato versionado con contrato: un constructor lee solo la serie histórica y escribe el archivo que alimenta el panel, con movimientos contra el último levantamiento sano (cambios, altas, bajas, cambios de banda), fuentes caídas con arrastre e historial; cada regla tiene su guardia en pytest.
  • Panel autónomo sin dependencias: HTML y SVG a mano, tema claro y oscuro, verificado en escritorio y teléfono, con los datos embebidos; publicado en S3 detrás de una Lambda con login propio y una copia fija por levantamiento.
  • Ciclo de producto con el usuario: correo por corrida en un hilo, respuestas leídas por IMAP y convertidas en pedidos con estado, decisiones registradas con evidencia y un bloque de novedades en el primer correo de cada versión.

Cómo se hizo

Metodología por fases

  1. Diagnóstico sobre la serie

    Medir movimiento, dispersión y cobertura del mercado antes de dibujar nada, y cerrar las decisiones de alcance en una sesión de grilling.

    SalidaDecisiones firmadas y el orden del panel: primero qué se movió, después dónde hay dispersión, después dónde no hay con qué comparar.

    • Python
    • Serie histórica
    • Skill grilling

  2. Contrato del dato primero

    Firmar el esquema del archivo que alimenta el panel; escribir un constructor que solo lee la serie; cada regla con su contraejemplo visto en rojo antes de dar verde.

    SalidaConstructor de datos con guardias de contrato en pytest.

    • pytest
    • Claude Code (Opus)

  3. Panel sin dependencias

    HTML y SVG a mano elegidos sobre librerías de gráficos; tokens de la identidad del cliente; tema claro y oscuro; capturas automatizadas en escritorio y teléfono.

    SalidaPrimer panel en operación, abierto desde un archivo sin red.

    • Skills dataviz y plan-visual
    • Playwright
    • Claude Code (Opus)

  4. Ronda de conceptos con vara objetiva

    Nueve conceptos en cuatro herramientas comparados contra las reglas del dominio y el orden del bloque principal, nunca por gusto; el taller de prototipos se reconstruye solo con un hook post-commit.

    SalidaEl concepto que vive junto al dato pasa a ser el panel.

    • Penpot autoalojado
    • Stitch
    • Figma (MCP)
    • Skill prototype
    • Taller de prototipos

  5. Entrega y operación

    Del archivo adjunto al link; del chat al correo en hilo; de la máquina local a GitHub Actions varias veces al día; Lambda y S3 con cookie firmada porque la URL de función rompe la autenticación básica.

    SalidaPanel publicado con historial por levantamiento y acceso con clave.

    • GitHub Actions
    • EventBridge
    • AWS Lambda
    • S3
    • smtplib

  6. Ciclo con el usuario

    Las respuestas del usuario entran por IMAP y se vuelven pedidos con estado; cada decisión registra por qué, evidencia y qué se descartó; cada versión anuncia qué cambió.

    SalidaVersiones diarias con número, etiqueta y novedades.

    • imaplib
    • Registro de pedidos
    • CHANGELOG
    • Claude Code

  7. Jev como primitiva de juicio

    Probar un modelo que no genera texto sino que devuelve un tipo y una probabilidad: llevar el rótulo de una fuente al tipo del catálogo, y recorrer diez niveles de uso en un laboratorio propio.

    SalidaPrimera etiqueta marcada «sin verdad humana» y un hook de revisión en el repositorio; Jev no entra al dato publicado.

    • TypeSafe SDK (Jev)
    • Laboratorio de diez niveles

Stack por capa

Herramientas y con qué capa trabajan

Diseño

  • Diseño: HTML + SVG a mano
  • Diseño: Playwright
  • Diseño: Penpot · Stitch

Producto

  • Producto: Correo en hilo + novedades
  • Producto: Pedidos desde el buzón

Código

  • Código: Python
  • Código: pytest
  • Código: GitHub Actions · EventBridge
  • Código: AWS Lambda · S3

IA

  • IA: Claude Code
  • IA: Skills propias
  • IA: Jev (TypeSafe)

Método

  • Método: Decisiones firmadas por grilling
  • Método: Puerta por encargo
  • Método: SemVer con etiqueta por versión

Relato · Dos herramientas, dos maneras de pensar

Claude planifica, escribe y verifica con un modelo por tarea. Jev no genera: juzga, y devuelve un tipo con su probabilidad. Lo que pasa la barra se aplica solo; lo que no, lo revisa una persona.

Escena 3D: un cuerpo ámbar translúcido con tres satélites, que representa a Claude y sus modelos, y un cuerpo facetado azul con un punto coral, que representa a Jev, juzgando cubos con rótulos que se deslizan por una rampa.
  1. Claude planifica y escribe Un modelo por tarea: Opus, Sonnet y Haiku según lo que toca decidir, construir o revisar.
  2. Jev juzga rótulos No genera texto: devuelve una respuesta tipada con su probabilidad.
  3. Sobre la barra, se aplica solo Si la confianza supera el umbral, el rótulo entra sin pasar por nadie.
  4. Bajo la barra, lo revisa una persona Lo dudoso va a revisión: por eso Jev no está en el dato publicado.
Escena estática Personificación ilustrativa de las herramientas, sin marcas ni logotipos. Acerca el puntero para que reaccionen.

Resultados

Resultados cualitativos

  • Del dato crudo a la decisión en segundos

    El panel abre con lo que cambió desde el último levantamiento sano, dónde hay dispersión entre canales y dónde no hay con qué comparar. Los denominadores van al pie.

  • Levantamientos automáticos con puerta de sanidad

    Varias veces por día hábil, con respaldo en dos lugares. Una fuente caída no corta la corrida ni produce falsos retiros: se arrastra su última lectura sana y se marca.

  • Ciclo de producto con el usuario

    Cada respuesta por correo se vuelve un pedido con estado; cada versión anuncia qué se pidió y cómo quedó. Las decisiones quedan escritas con su evidencia.

  • Sin dependencias ni licencias

    Un HTML autónomo con los datos embebidos, publicado en S3 detrás de una Lambda con clave, con una copia fija por levantamiento.

  • Calidad verificable

    Contrato de datos con guardias que se vieron en rojo antes de verde, capturas automatizadas en escritorio y teléfono, y una etiqueta de versión por cada cambio que altera la lectura.

NotaCaso sanitizado: las cifras de mercado, de fuentes y de uso no se publican. Se describe el proceso y el valor entregado.

Relato · Lo que cambió al medir

  • Identidad de la oferta

    Antes

    Clave por banda de precio: colisiones en cada corrida.

    Después

    Clave por rótulo publicado: una oferta, una identidad.

  • Fuente sin respuesta

    Antes

    Se leía como precios retirados.

    Después

    Se arrastra la última lectura sana y se marca.

  • Entrega

    Antes

    Archivo adjunto que el chat mostraba como código.

    Después

    Link fijo por levantamiento, correo en hilo e historial.

  • Alerta

    Antes

    Abría con alzas y escondía bajas pequeñas.

    Después

    Bajó y subió por separado, ordenados por relevancia.

Evidencia

Esquema del sistema

  1. 01 Entrada
    Fuentes públicas
    • Sitios y APIs
    • HTML y JSON
  2. 02 Disparo
    Programación
    • GitHub Actions
    • EventBridge + Lambda
    • launchd de respaldo
  3. 03 Captura
    Orquestador
    • Python
    • Un extractor por fuente
  4. 04 Puerta de sanidad
    Gate
    • pytest
    • Auditoría de la corrida
  5. 05 Derivación
    Serie y movimientos
    • Serie histórica
    • Movimientos vs. último sano
    • Arrastre de fuentes caídas
    Contrato
    Guardias en pytest
    Solo si
    la corrida es sana
  6. 06 Archivo
    Corridas en git
    • xlsx por corrida
    • Marca de sanidad
  7. 07 Panel
    Panel publicado
    • S3 + Lambda
    • Cookie firmada
    • Historial por levantamiento
  8. 08 Aviso
    Correo al usuario
    • SMTP
    • Buzón IMAP → pedidos
Esquema del sistema, no captura de producto

Esquema del sistema, no captura de producto: de las fuentes públicas al panel y al correo, pasando por la puerta de sanidad.

Relato · Cómo evolucionó, versión a versión

Una etiqueta por cada cambio que altera la lectura. Los días se cuentan desde la primera versión en operación.

  1. v0.1 día 1

    Contrato de datos, franja de dispersión y primer panel enviado por mensaje directo.

  2. v0.2 día 1

    Identidad visual del cliente, pestañas por grupo de renovación, tema claro y oscuro.

  3. v0.3 día 2

    Movimientos contra el último levantamiento sano; identidad de la oferta corregida con su medida.

  4. v0.4 día 8

    Historial por levantamiento; la alerta vive en el panel, sin chat.

  5. v0.5 día 10

    Detalle por tipo, bajó y subió separados, contraste corregido en oscuro.

  6. v0.6 día 10

    Una fuente caída no corta la corrida: arrastre marcado con símbolo y palabra.

  7. v0.7 día 11

    Link fijo por levantamiento; el concepto elegido pasa a ser el panel.

  8. v0.8 – 0.10 día 11

    Fuentes consultadas a la vista, precios de convenio fuera de la comparación, novedades por versión en el correo.

Relato · Ronda de conceptos

Nueve conceptos en cuatro herramientas, comparados con la misma vara: las reglas del dominio y el orden del bloque principal. Un concepto no se corrige, se reemplaza.

  1. 01 Figma (MCP) descartado

    La cuota del plan se agotó en la primera ronda.

  2. 02 Stitch en revisión

    Explora el bloque principal con una tarjeta por tipo.

  3. 03 Figma (API) descartado

    Incompleto: la cuota cortó la sesión a mitad.

  4. 04 Penpot autoalojado superado

    Seleccionado en la primera ronda; superado por el 05 y el 06.

  5. 05 Penpot autoalojado en revisión

    Suma los precios del día por tipo al concepto 04.

  6. 06 HTML en el repositorio seleccionado

    Vive junto al dato y se verifica con el mismo guardia; pasó a ser el panel.

  7. 07 HTML (skill prototype) propuesto

    Variante maestro y detalle.

  8. 08 HTML (skill prototype) propuesto

    Variante con contadores arriba.

  9. 09 HTML desde los pedidos propuesto

    Página de novedades: lo que se pidió y cómo quedó, por versión.

Aprendizajes

Qué me llevo del caso

  1. Medir antes de diseñar

    El diagnóstico sobre la serie decidió que el panel abra con qué se movió, no con una tabla de precios.

    Método

  2. La identidad de una oferta es producto

    La clave por banda de precio colisionaba en cada corrida; la clave por rótulo publicado, no.

    Producto

  3. Fuente caída no es precio retirado

    Sin arrastre aparecían retiros falsos; con arrastre, ninguno. El dato distingue «no leí» de «no está».

    Código

  4. El canal de entrega es producto

    Del archivo en el chat al link y después al correo en hilo con historial: tres versiones.

    Producto

  5. Una vara objetiva ordena la ronda

    «No vale me gustó más»: cuatro herramientas con la misma regla, y ganó lo que vive junto al dato.

    Diseño

  6. El brief no es la especificación

    El que mezclaba colores, píxeles y filas se reemplazó por uno que apunta al sistema de diseño y al archivo.

    Diseño

  7. Jev devuelve probabilidad, no verdad

    Acierta la mayoría de los rótulos; una etiqueta «sin verdad humana» la revisa una persona. No entra al dato publicado.

    IA

  8. El versionado define «terminado»

    La 1.0.0 llega el día que el usuario use el panel sin mí al lado.

    Método

Siguiente caso

Seguir leyendo

Agente de Soporte Post-Venta Agente conversacional para soporte post-venta, del discovery al prototipo funcional. Abrir Agente de Soporte Post-Venta Volver al hub de proyectos