CÓMO USO LA IA PARA CONSTRUIR

Sergio Carballo

Product Manager end-to-end·Fintech·CDMX

Once años construyendo producto. Lo que estás viendo no es un portafolio: es un sistema que opero todos los días.

01 . TRAYECTORIA

Once años de producto,
casi todos en fintech.

  1. 2024 — 2025 OpenPass Product Owner · Regionalización Lancé el producto en México —pagos, BNPL, wallet— y abrí Guatemala con Banco Industrial.
  2. 2022 — 2023 Sr. Pago Product Manager · Hardware Dueño de las terminales de pago. Migré todo el hardware a un proveedor nuevo.
  3. 2021 — 2022 Konfío Product Owner · Payments Integré Sr. Pago con Konfío sosteniendo las dos plataformas en operación a la vez.
  4. 2019 — 2021 Sr. Pago Product Owner · MPOS & App Backlog de la app y su ecosistema de hardware.
  5. 2017 — 2019 Sr. Pago UX Manager Research con usuarios para validar antes de construir.
  6. 2015 — 2017 Sr. Pago App Manager Administración de la app y sus publicaciones en App Store y Google Play.

Antes de 2015: soporte de aplicación y administración de TI interna. Ahí empezó el contexto técnico que uso todos los días.

02 . LA PRUEBA

Cualquiera dice que construye con IA.
Estos son los números.

Dirijo dos sistemas de IA en paralelo. En Antigravity llevo un equipo de diez agentes sobre Gemini que diseñan, programan y prueban; en Claude Cowork trabaja un segundo modelo cuyo único encargo es auditar lo que produjo el primero. Comparten una memoria vectorial que corre local en mi Mac, así que ninguno arranca de cero. Las cifras de abajo no salen de una presentación — salen del sistema en cada build.

El contador de memoria se lee de la base en cada compilación. Si el sistema crece, el sitio crece solo.

03 . EL SISTEMA

Diez agentes.
Y uno que le puede decir que no al jefe.

La parte difícil de un equipo de IA no es que trabaje: es que se detenga. Por eso el sistema no es una fila de asistentes, sino una cadena de autoridad donde el que manda no siempre gana.

  1. L0 Sergio Humano. Autoridad final. Nada crítico se ejecuta sin un sí explícito.
  2. L1 Arthur · Kernel Legal y Seguridad. Pueden frenar cualquier entrega, venga de quien venga.
  3. L2 Sia Economía del producto. Bloquea lo que no se sostiene con números.
  4. L3 Cooper Product Manager y orquestador. Manda — y es el primero al que pueden vetar.

Sólo cuatro pueden detener una entrega. Los otros seis ejecutan: proponen, construyen y prueban, pero no bloquean.

ARQUITECTURA Dos modelos y una memoria compartida, corriendo en mi Mac. El que construye no es el que revisa.
Sergio L0 · autoridad final · HITL en toda acción crítica
Antigravity + Gemini Orquestación · operación diaria
  • Gemini API
  • Firebase MCP
  • Git / GitHub
  • memoria JSONL
Equipo de 10 agentes Se coordinan entre sí, no conmigo uno por uno
  • Cooper · PM
  • George · Dev
  • Ada · Data
  • Kernel · DevOps
  • Arthur · Legal
  • Chino · UX
  • Orlando · QA
  • Sia · Economics
  • Vera · Writer
  • Pia · Marketing
Veto: L0 Sergio → L1 Arthur + Kernel → L2 Sia → L3 Cooper. Legal y Seguridad frenan al PM, no al revés.
Claude Cowork Consultor senior · auditorías
  • MCP server
  • Python 3.11
  • Anthropic API
  • sólo lectura
Un solo agente Revisa con criterio independiente lo que produjo el otro
  • Arquitectura
  • Code review
  • Auditorías
  • Segunda opinión
  • HITL estricto
  • Sin escribir en prod
No comparte contexto con el equipo: si coincidieran, la auditoría no serviría de nada.
rag_pipeline.py Indexa las sesiones del equipo. Automático
rag_pipeline_claude.py Indexa las del consultor. Semimanual: se dispara cuando digo «graba»
ChromaDB · .chroma_db Una sola instancia local · embeddings con Ollama y nomic-embed-text
  • tope duro 2048 tokens
  • chunks de 3000 bytes
  • top-k 12
source: antigravityLo escribe el equipo. Sólo él lo lee.
source: claudeLo escribe el consultor, que además lee el otro.
Memoria segregada por origen: el consultor audita con el contexto completo sin contaminar el del equipo. La lectura sale por rag_query.py, con filtro por origen y por proyecto, servida a través de mcp_server.py.
Git hook · post-commit En cada repo de producto: reindexa la memoria y respalda la base. Retención de 14 días. Es una de las tres excepciones documentadas al HITL.
Observabilidad Corre en un MCP separado a propósito: si el de métricas se cae, el de memoria sigue en pie.
Polyrepo privado Seis repos en GitHub, uno por producto más el de governance, con las reglas que los agentes obedecen.

04 . PRODUCTOS

Cuatro productos en línea.
Ábrelos, no me creas.

01

SUDO

Finanzas personales: control de gastos y visualización de hacia dónde se va el dinero. Plataforma web y app nativa para iOS y Android, con inicio de sesión por Apple y Google.

Fintech · Web + app nativa · React Native sudo.xroot.me 02

Mundial

Intercambio de estampas del álbum del mundial. Marketplace de match entre lo que te sobra y lo que te falta.

Marketplace · JavaScript · Firebase mundial.xroot.me 03

Nuvika

CRM inmobiliario en operación: pipeline de captación y demanda, gestión de propiedades, cálculo de comisiones y cierre de operaciones.

PropTech · React · Firebase URL por confirmar 04

xRoot

Este ecosistema. El sitio, el equipo de agentes y la memoria compartida que los conecta a todos.

Sistema · Vite · ChromaDB xroot.me

05 . AUDITORÍAS

Lo que mi propia IA hizo mal.
Y cómo lo caché antes de que doliera.

Todos los sistemas fallan. La diferencia está en quién puede demostrar que encontró la falla. Estos tres casos son reales, salieron de mi propio ecosistema, y ninguno llegó a un usuario.

  1. CASO 01

    Comisiones infladas cien veces

    Qué encontré
    Un sistema de gestión comercial calculaba una comisión multiplicada por 100: una comisión real de $50,000 se reportaba como $5,000,000.
    Por qué pasó
    La tasa estaba guardada como fracción (0.05) y el código la volvía a dividir entre 100 como si fuera porcentaje. Dos convenciones distintas conviviendo en el mismo archivo.
    Cómo lo cacé
    Los totales del tablero no cuadraban con la suma manual de las operaciones. Nadie lo había notado porque el número se veía "grande y bonito".
  2. CASO 02

    Datos personales expuestos en la base

    Qué encontré
    Datos de contacto personales vivían en un documento de acceso público. Cualquiera sin sesión iniciada podía leerlos.
    Por qué pasó
    El esquema mezclaba el dato público con el dato personal en un mismo registro. Las reglas de seguridad protegían la colección, no el campo.
    Cómo lo cacé
    Consultando la base directamente por API, sin sesión iniciada, como lo haría un extraño. Se movió el dato a una subcolección restringida antes de salir a producción.
  3. CASO 03

    El orquestador firmaba trabajo que nadie hizo

    Qué encontré
    Cooper, el agente que coordina al equipo, reportaba entregas de diseño y QA firmadas por otros agentes. Esos agentes nunca fueron invocados.
    Por qué pasó
    Un modelo de lenguaje genera con la misma facilidad el trabajo y el relato de que el trabajo se hizo. Sin una prueba mecánica, la narrativa gana.
    Cómo lo cacé
    Auditando los registros de sesión: el 89% de los turnos no invocó a nadie. La solución no fue prohibirlo — fue exigir que toda firma incluya el identificador verificable del turno. Sin identificador, se marca como no invocado.

El patrón común de los tres: el sistema producía la narrativa de que todo estaba bien en lugar de verificar el estado real. Ese es el trabajo que no se delega.