Claude Impact Lab
La plataforma que operó el primer Claude Impact Lab de América Latina (la edición Fintech, en el Chile Fintech Forum de mayo) y después su segunda vertical, Longevidad, sobre la misma base de código. Fui Lead Frontend del proyecto: el leaderboard en vivo, el portal de evaluadores y el motor de puntaje.
Bendita IA · Anthropic como Technical Partner
- Rol
- Lead Frontend · integración de agentes
- Alcance
- Plataforma de dos verticales
- Periodo
- Abr – Ago 2026
- Stack
- Next 14 · Supabase · Claude API
- 2
- verticales: Fintech y Longevidad
- 1.656
- postulaciones procesadas
- 100
- equipos en competencia
- 3.277
- evaluaciones registradas
- 4
- agentes Claude en producción
El problema real
Un evento nacional con 899 postulaciones, 48 equipos compitiendo y veinte evaluadores voluntarios con dos días para revisarlo todo. La aritmética no cierra.
- 01Sin automatización, no alcanza el tiempo para evaluar con seriedad
- 02Con automatización ciega, el resultado pierde legitimidad ante quien compite
- 03Los criterios cambian entre tracks y no pueden quedar congelados en el código
- 04Todo tiene que sostenerse en vivo, con público mirando la pantalla
Agentes que no deciden, pero hacen posible decidir
El agente no evalúa. Pre-evalúa.
Esa distinción es todo el proyecto. Un modelo que emite un puntaje de 1 a 10 sobre el trabajo de un equipo produce un número que nadie puede discutir ni defender. En su lugar, el asistente revisa diez sub-checks binarios y por cada uno entrega su veredicto junto con la cita textual que lo sustenta. El evaluador humano confirma o corrige con un click, y su decisión es la que cuenta.
- Pedirle al modelo un puntaje global y confiar en él
- Rúbricas escritas en el código, imposibles de ajustar durante el evento
- Un solo juez decidiendo por equipo
- Tratar la evaluación asistida como una caja negra
- Sub-checks binarios con evidencia textual obligatoria
- Rúbrica editable por evento, sin deploy
- Jueces en doble ciego con agregación robusta, no promedio simple
- Registro de cada divergencia entre humano e IA
Cuatro agentes, cuatro alcances de permiso
No es un chatbot con cuatro personalidades: son cuatro superficies distintas, cada una con su propio conjunto de herramientas, su propio nivel de autenticación y su propio modelo elegido según la tarea.
Copiloto de administración
Claude Sonnet 4.5
Asiste al equipo organizador. Las herramientas de lectura corren solas; las de escritura (aprobar equipos, cerrar evaluaciones, guardar rúbrica) quedan detrás de aprobación humana explícita.
Sonnet y no Haiku por una razón concreta: el loop de aprobar veinte equipos en una sola conversación es largo y con muchas herramientas, y ahí un modelo más liviano se pierde a mitad de camino.
Asistente de evaluación
Claude Haiku 4.5
Pre-evalúa cada entregable en diez sub-checks binarios y entrega, junto al veredicto, la evidencia textual que lo sustenta. El mentor o juez confirma o corrige con un click.
Las diez pre-evaluaciones corren en paralelo: es clasificación acotada, no razonamiento largo. Ahí Haiku es la elección correcta y la barata.
Asistente de participantes
Claude Haiku 4.5
Solo lectura. Responde sobre las bases, el progreso del equipo y los recursos disponibles, con acceso limitado a los datos del propio usuario.
El alcance de permisos es parte del diseño del agente, no una capa que se agrega después.
Asistente público
Claude Haiku 4.5
Sin login. Dos herramientas y nada más: preguntas frecuentes curadas por el equipo y búsqueda de recursos públicos. Cero acceso a datos de usuarios.
Rate limiting persistido en base de datos, no en memoria (en serverless, la memoria miente), más protección contra inyección de prompt y tope de iteraciones.
Auditoría de divergencia entre humano e IA
Cada vez que un mentor o un juez se apartó de lo que sugería el modelo, quedó registrado: qué criterio, en qué dirección y por qué. No es telemetría. Es la materia prima para saber en qué tipo de juicio el modelo se desalinea del criterio humano, y ajustar la instrucción en vez de adivinar.
Es, además, lo que permite defender el resultado ante quien no ganó: la traza existe y se puede revisar criterio por criterio.
- Fase mentor
- 40%
- Fase jueces (doble ciego, agregación robusta)
- 60%
La ponderación es un parámetro del evento, no una constante del código: se edita desde el panel de administración. En Fintech, con tres jueces por equipo, se usó la mediana; en Longevidad, con dieciséis jueces, una media truncada que descarta el voto más alto y el más bajo.
Qué construí
Trabajé como Lead Frontend en un equipo de tres, con un backend dedicado y un CAIO definiendo producto. Estas son las piezas de las que fui responsable, a lo largo de 166 commits en cinco meses.
- 01
Leaderboard en vivo y ceremonia de premiación
Construí el ranking público sobre Supabase Realtime y la ceremonia con reveal por track y podio animado, proyectada ante 250 personas. Sin recargas, sin latencia visible, y con la lógica de quién queda fuera de competencia por no entregar a tiempo resuelta en el mismo lugar donde se calcula el puntaje.
- 02
Portal de evaluadores
La interfaz donde veinte mentores y jueces revisaron 48 equipos en dos días: dossier por equipo, formulario de evaluación conectado al asistente, y una vista que le muestra al juez lo que ya había marcado el mentor en la fase anterior.
- 03
Motor de puntaje y rúbrica configurable
Después del evento cerré los vacíos de scoring que la auditoría dejó al descubierto: mediana de los tres jueces en lugar de promedio, tope real en 100, y ponderación mentor/juez editable por evento desde el panel de administración sin necesidad de un deploy. Uno de esos ajustes cambiaba el primer lugar. Esa base es la que después se extendió a media truncada cuando Longevidad llegó con dieciséis jueces.
- 04
Abstracción multi-tenant
Junto al equipo, moví la configuración de evento (tracks, reglas, rúbrica, marca, fechas) a una capa de resolución por vertical, y en agosto cerré los lugares donde Bendi y la rúbrica seguían leyendo la vertical original. Eso permitió lanzar Longevidad sobre la misma base de código en lugar de duplicar el proyecto.
- 05
Tour guiado por rol y motor de certificados
Un recorrido con spotlight diferenciado para participante, mentor y juez, porque en un evento de 48 horas nadie lee documentación. Y, al cierre, el motor de certificados de punta a punta: parametrizable por evento, con verificación pública por QR, botón para agregarlo a LinkedIn y menciones especiales.
Tres cosas que solo se descubren en producción
Un evento en vivo no perdona el estado mal guardado
El bug más caro de los dos días no estuvo en ningún agente: estuvo en el guardado automático de los entregables. Cuando el usuario y el sistema escriben sobre lo mismo, quien pierde siempre es el usuario. Lo arreglamos en caliente, y desde entonces trato el autosave como un problema de concurrencia, no de conveniencia.
La configuración por vertical se filtra por donde no la buscas
Al abrir una segunda vertical, aparecieron lugares donde el sistema seguía resolviendo la rúbrica del evento original. El aprendizaje fue estructural: la vertical activa tiene que ser una única fuente de verdad consultada en el borde, no un parámetro que cada módulo hereda por su cuenta.
La auditoría posterior vale tanto como el evento
Al revisar el cálculo de puntajes después del cierre encontramos diferencias de criterio (promedio contra mediana, topes, ponderaciones) que en un caso movían el primer lugar. Cerrarlas con tests fue más valioso que cualquier feature nueva, y es la razón por la que la segunda edición partió sobre terreno firme.
Con qué está construido
- Frontend
- Next.js 14 (App Router) · React 18 · TypeScript estricto · Tailwind CSS · next-intl
- Datos y tiempo real
- Supabase: PostgreSQL, RLS por rol, Realtime, Storage
- IA
- Claude API vía Anthropic SDK: Haiku 4.5 y Sonnet 4.5, tool use, base de conocimiento por vertical
- Calidad
- Vitest · Playwright E2E, incluyendo suites de guardrails para los agentes
- Operación
- GitHub Actions (lint → tipos → tests → build) · conventional commits · Vercel · Resend
La plataforma sigue en línea
El programa publicó un reporte de impacto de la edición Fintech y los resultados de Longevidad, con cifras verificadas desde la base de datos de producción. Los números de esta página salen de ahí.