Claude Impact Lab Chile
Bendita IA · Anthropic como Technical Partner
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.
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.
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.
Lo que no hicimos
Lo que sí
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.
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.
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.
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.
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.
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.
Cómo se compone el puntaje
La ponderación es un parámetro del evento, no una constante del código: se edita desde el panel de administración.
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 148 commits en cinco meses.
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.
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.
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.
Moví la configuración de evento —tracks, reglas, rúbrica, marca, fechas— a una capa de resolución por vertical. Eso permitió lanzar la segunda edición del programa sobre la misma base de código en lugar de duplicar el proyecto.
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 generador de certificados parametrizable por evento.
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.
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.
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.
El programa publicó un reporte de impacto con las cifras verificadas desde la base de datos de producción. Los números de esta página salen de ahí.