El factor humano del hackatón: lo que la industria, la academia y las instituciones enseñan en 72 horas

Tres días. Ocho desafíos. Cerca de doscientos desconocidos en un campus universitario. Y, al final, un sobre con un segundo lugar adentro.

Sobre ese sobre ya escribimos tres crónicas —el Día 1, el Día 2 y el Día 3—. Este artículo es otra cosa. Es el que me quedé debiendo, porque hay una parte del hackatón que no cabe en una bitácora técnica y que, sin embargo, es la que más me cambió la forma de trabajar.

En AWS Breaking Barriers Chile 2026 había un recurso que no se podía descargar de ningún repositorio. No era cómputo —AWS regaló tokens ilimitados de prácticamente todo su catálogo frontier, así que el techo técnico era el mismo para todos—. No era el modelo, que también era de todos. El recurso escaso era la gente: quién estaba dispuesto a sentarse quince minutos a explicarte lo que tú no sabías que no sabías.

Y eso es lo que quiero contar acá. Con nombres, con apellidos y con lo que cada uno nos dejó, porque este blog tiene una regla: si no puedo señalar a la persona, no lo escribo.

El aviso de rigor, que acá importa más que nunca: esto es mi testimonio, no la versión oficial del evento. Las conversaciones que cito las tuve yo, y las resumo como las entendí —no hablo por Pablo, Daniel, Claudio, Aiden ni por el equipo de Integra—. Los roles y credenciales que menciono son públicos y verificables. Y donde la memoria podría estar inflando algo, lo digo explícitamente.

1. El ranking es la parte menos interesante del hackatón

Los números del evento, para dimensionarlo: del 14 al 16 de octubre de 2026, en el campus Beauchef de la Facultad de Ciencias Físicas y Matemáticas de la Universidad de Chile (Beauchef 851), con el auditorio d'Etigny y la explanada como base de operaciones. Cerca de 200 desarrolladores, startups y estudiantes, trabajando sobre ocho desafíos reales de organizaciones sin fines de lucro y del sector público, en cuatro frentes: Educación, Salud, Ciudadanía digital y Sustentabilidad.

Era la primera edición latinoamericana de Breaking Barriers —la hackatón insignia de IA generativa de AWS para impacto social, que sumaba más de 3.000 desarrolladores en el mundo— y llegó en el marco de un acuerdo entre la U. de Chile y AWS. En la práctica: los prototipos ganadores no se quedan en un cajón. Se entregan a la institución para su despliegue.

Ahora, la parte incómoda. Ese formato —el que mide, el que premia, el que aparece en las fotos— solo captura una de las cosas que pasaron en la sala. Miren lo que se mide y lo que se llevó cada uno:

El trofeo se queda en la oficina y se llena de polvo. Las otras tres cosas, no. Y sin embargo casi todo el contenido sobre hackatones habla de la primera columna. Vamos a la segunda.

2. La industria: aprender en el pasillo, no en el tutorial

Hay una idea romanticista de que en un hackatón se aprende "haciendo". Es media verdad. Se aprende haciendo y —sobre todo— preguntándole a alguien que ya se equivocó antes que tú en lo mismo.

Nuestro grupo tuvo la suerte de tener como mentor a Pablo Badilla Torrealba, Tech Lead en IA y Ciencia de Datos de la Iniciativa de Datos e Inteligencia Artificial (IDIA) de la FCFM de la Universidad de Chile. Ingeniero Civil en Computación y Magíster en Ciencias de la Computación por la misma universidad, docente del Magíster en Ciencia de Datos, y con trayectoria real en banca, retail, startups y transferencia tecnológica —MLOps, arquitecturas de IA generativa, sistemas escalables en la nube—.

Y ese cóctel es justo el que un equipo técnico necesita y casi nunca encuentra junto: alguien que sabe lo suficiente de teoría para no creer en magia, y lo suficiente de producción para no enamorarse de su propia demo.

Lo que nos dio Pablo no fue una respuesta. Fue algo más útil y más incómodo: nos quitó certezas falsas. La conversación, una y otra vez, caía en el mismo lugar: "¿y esto cómo lo mides?", "¿y cuando llegue el caso raro?", "¿esto es un prototipo o es un sistema?". En un hackatón, donde la tentación es mostrar el camino feliz, tener a alguien que te pregunta por el infeliz es un lujo.

Al lado nuestro había otro perfil que me dejó pensando, aunque no fuera nuestro mentor formal: Claudio Fasola, que construye desde Fasola Labs y se formó en la Universidad Autónoma de Chile. Lo digo sin adorno: su juventud, su claridad técnica y sus ganas de comerse el mundo fueron de las cosas que más me impresionaron del evento. No por lo simpático del dato, sino por lo que implica: hay una generación que ya no pide permiso para construir sistemas serios. Cuando alguien así te pregunta cómo resolver tu problema en vez de contarte el suyo, entendés que la conversación sobre "quiénes van a construir la IA de Chile" ya está resuelta, y no por los que suelen aparecer en los paneles.

Y había una tercera capa de industria, anterior al hackatón: los tres talleres de preparación de AWS —Servicios Core, Kiro y AI-DLC— que transcribimos completos para no perder nada: 5.210 segmentos, 11,8 horas de grabación. Ahí aprendimos cosas que no venían en la documentación, del tipo que solo dice alguien que está en el día a día: que la región de AWS en Chile venía en camino, que la IA dentro del ciclo de desarrollo no reemplaza al ingeniero sino que lo corre a otro lugar, y un consejo que se volvió regla interna: "no le confíen al primer intento del agente; háganlo suyo".

3. La academia, o el contrapeso que te salva de la solución elegante

Si la industria te empuja a construir, la academia te obliga a justificar. Y en un hackatón —donde todo el mundo optimiza para que la demo no se caiga— ese contrapeso es exactamente lo que evita que construyas algo insostenible con buena pinta.

Tuve la oportunidad de conversar bastante con Daniel Zanelli, ingeniero y desarrollador en la Comisión Chilena de Energía Nuclear (CCHEN), con formación en Aalto University, en Finlandia. Su mirada es la de alguien formado en el rigor de un laboratorio nacional de investigación: para él, una afirmación sin evidencia no es una opinión, es un pendiente.

Lo que esa conversación nos dejó se puede resumir en una pregunta que se nos pegó: "¿cómo lo sabés?". No "¿funciona?" —funcionar puede significar que tuviste suerte una vez—. Sino ¿cómo lo sabés?: ¿con cuántos casos?, ¿contra qué referencia?, ¿qué asumiste?, ¿qué pasa en el borde? Esa pregunta, hecha desde un perfil académico, cambió por completo la forma en que presentamos nuestros números: pasamos de decir un número a decir de dónde salía y qué no cubría.

Y después está la conversación más improbable del fin de semana, y la que más me sigue dando vueltas.

En la facultad me encontré con Aiden Hogan, director del Departamento de Ciencias de la Computación de la U. de Chile, profesor titular e investigador del Instituto Milenio Fundamentos de los Datos (IMFD), y parte del equipo que creó MillenniumDB —esa base de datos de grafos que nosotros usamos, literalmente, como capa de memoria de nuestro agente—.

Le planteé una idea que nos importa como empresa. MillenniumDB está publicada bajo licencia GPL-2.0, y eso —dicho rápido y sin abogados— implica que si construyes un producto sobre ella y lo distribuyes, el copyleft te empuja a liberar en los mismos términos. Para investigación es perfecto. Para una startup que quiere embeber ese motor dentro de su producto como capa de memoria agéntica, es una conversación legal que nadie quiere tener a las once de la noche.

Así que le dije lo que pienso: que con una licencia permisiva —Apache 2.0 o MIT— MillenniumDB podría volverse una alternativa mucho más adoptada frente a otros motores, sobre todo en la ola de sistemas agénticos que necesitan memoria con forma de grafo. Que el límite de adopción no era técnico: era de licencia.

Le gustó la idea, y quedó en proponerlo. Lo dejo escrito con toda la honestidad del caso: fue una conversación, no un compromiso, y no sé si prospere. Pero eso es exactamente el punto de este artículo: esa conversación no existía en ningún otro lugar del mundo ese fin de semana. No se consigue por mail, no se compra, no se descarga. Existe porque el creador de un motor de bases de datos estaba físicamente a diez metros de alguien que lo usa todos los días y que tenía un argumento concreto sobre su adopción.

4. Los problemas nacionales, de primera mano

Esto es lo que ninguna tesis, ningún dataset y ningún benchmark te puede dar: la persona que vive el problema, sentada frente a ti, explicándotelo con lógica de negocio y humana a la vez.

Las ocho problemáticas venían de instituciones reales. Nosotros trabajamos una —la de Fundación Integra, sobre cómo documentar el desarrollo de cada niño sin robarle tiempo a la educadora—, pero el día de la inauguración escuchamos a todas exponer las suyas, y ese rato valió el viaje entero.

De Fundación Integra tuvimos además la suerte de tener del otro lado a Lissete Saavedra y María Paz Oyarzún, las personas con las que efectivamente hablamos durante los tres días. Y quiero ser preciso en esto, porque es la diferencia entre un desafío y un caso de estudio: no nos dieron un documento de requerimientos. Nos dieron su problema.

El número que hoy sostiene todo nuestro pitch —cerca de cuatro horas semanales de documentación por educadora, que en una red de 1.200 jardines son más de 11.000 horas a la semana que no están con los niños— no salió de nuestra imaginación ni de un paper. Salió de ellas, explicándonos cómo es un martes cualquiera en un jardín.

Cuando escuchás eso, dejás de optimizar una métrica y empezás a optimizar una condición de trabajo. Y el diseño cambia: no construís "un clasificador con buena accuracy", construís algo que no le quite el criterio a la educadora. Esa distinción —que está en el corazón de nuestro sistema, con la humana siempre en el loop— no la tomamos nosotros. La tomamos de ellas.

5. La multidisciplina: cuatro desconocidos frente a un problema

Y está la variable que nadie pone en el debrief: la conformación del equipo. En este hackatón no elegías con quién trabajar. Te emparejaban. Reconozco que al principio lo miré con desconfianza —uno siempre cree que con su gente rinde más—. Hoy creo que fue la mejor decisión de diseño del evento, por una razón muy simple: si te juntás con quien ya trabajás, pensás como ya pensás.

Nuestro grupo terminó siendo un experimento accidental de diversidad disciplinaria: dos estudiantes —uno de Astronomía, otro de Ciencias de la Computación— y dos que veníamos del mundo privado. Tres formas de mirar el mismo problema:

La tentación en un hackatón es que gane el que teclea más rápido. Lo que pasó fue otra cosa: cada perfil evitó que los otros se equivocaran en grande. Los estudiantes nos bajaban los pies a tierra cuando nos íbamos en voladas de arquitectura; nosotros los bajábamos a ellos cuando se enamoraban de una solución elegante que ninguna educadora iba a usar. El rigor científico convertía nuestras corazonadas en hipótesis medibles; el criterio de producto convertía sus experimentos en algo que se puede poner en un jardín.

6. La honestidad como moneda de cambio

Hay una parte del evento que no es ni industria, ni academia, ni institución, pero que también es factor humano puro: el jurado. Y del jurado aprendimos algo que aplica mucho más allá de un hackatón.

En el pitch dijimos lo que faltaba. No dijimos "100% de precisión": dijimos 0,963 en nuestra prueba honesta, con la humana en el loop. No dijimos "cubrimos los diez núcleos de la rúbrica": dijimos que el marco es parametrizable y que estábamos listos para cargarlos cuando Integra los publicara. No dijimos "reemplazamos a la educadora": dijimos que le devolvemos cuatro horas para que ejerza mejor su criterio.

Y el jurado —gente que evalúa proyectos de IA todos los días y que detecta el humo a diez metros— respondió a eso. Nos preguntaron lo difícil: ¿y si se equivoca?, ¿y los datos de los menores?, ¿cuánto cuesta escalar? Y teníamos respuesta, porque nos la habíamos hecho nosotros mismos mucho antes, en las conversaciones de los pasillos.

Ahí entendí que en estos formatos la honestidad no es una postura moral: es una estrategia de credibilidad. La métrica inflada se cae en la primera pregunta. La honesta aguanta. Y en un evento donde todos quieren parecer perfectos, decir lo que falta es un acto de confianza.

7. Lo que queda cuando el código se congela

El viernes a las 10:15 se cerró el desarrollo. A las 15:00 fue el pitch. A las 16:30, el veredicto: segundo lugar entre más de 25 equipos. Y a la semana siguiente, la consecuencia que vale más que el trofeo: Fundación Integra se comunicó para llevar el proyecto a producción.

Pero lo que quiero dejar escrito es lo otro. El código se congeló a las 10:15 y, sin embargo, todo lo que este artículo cuenta siguió funcionando después. Los contactos siguen ahí. La conversación sobre la licencia de MillenniumDB sigue su curso. La pregunta de Daniel —¿cómo lo sabés?— la seguimos usando en cada revisión de números. La distinción de Lissete y María Paz sobre el criterio de la educadora está en el diseño, no en el slide. Y Pablo sigue siendo alguien a quien le podés escribir.

Por eso, si me preguntan cómo aprovechar un hackatón, mi respuesta no es técnica. Es esta:

• Optimizá las pausas, no solo las horas de código. El café, el pasillo y la espera del jurado son donde ocurre la mitad del aprendizaje.
• Tené preparada una pregunta concreta para cada persona interesante. No "¿me das un consejo?", sino "esto es lo que estoy haciendo, esto es lo que no logro, ¿qué ves?".
• Buscá deliberadamente al perfil que no se parece a ti. Si tu equipo piensa igual que tú, no tenés equipo: tenés un espejo.
• Hablá con la institución antes de escribir código. Una hora con quien sufre el problema ahorra tres días construyendo la solución equivocada.

Los hackatones no se ganan con el mejor modelo —en este, ni siquiera hacía falta el mejor modelo, y eso lo contamos en detalle en el artículo del modelo congelado—. Se ganan, y sobre todo se aprovechan, con la mejor red de personas mirando el mismo problema desde lados distintos.

El código se congela el viernes. La gente, no.