El hackathon que cambió la forma en que veo el desarrollo de software
Todo comenzó como una conversación cualquiera con mis amigos. Estábamos reunidos hablando de temas habituales cuando, por casualidad, terminamos hablando sobre hackatones. Ya era una pequeña tradición para nosotros participar en varios durante cada semestre. La idea siempre era intentar ganar alguno, aunque en la mayoría de ocasiones el verdadero premio terminaba siendo todo lo que aprendíamos durante el proceso.
Uno de mis amigos propuso participar en un hackathon relacionado con tecnología y playa. Como no vivimos cerca del mar, la idea nos pareció aún más emocionante y decidimos enviar nuestra propuesta.
La primera fase consistía en crear un proyecto sobre cualquier tema y presentarlo ante un grupo de evaluadores. Después de explicar nuestra idea, respondimos varias preguntas sobre la solución y la arquitectura que habíamos planteado. Unos días después recibimos la noticia de que habíamos sido seleccionados como finalistas.
La reacción fue una mezcla de emoción y felicidad absoluta. Celebramos como si hubiéramos ganado, saltando y festejando juntos. Obviamente estábamos orgullosos de que nuestro proyecto hubiera avanzado, pero también nos emocionaba muchísimo la posibilidad de vivir esa experiencia con amigos en un lugar diferente.
Cuando llegó el día del evento, viajamos con la intención de disfrutar al máximo. Y puedo decir que lo conseguimos. Pero la parte más interesante de la historia empezó realmente cuando recibimos el reto que debíamos resolver.
Un par de días antes habíamos decidido trabajar en el área de Internet de las Cosas. Queríamos construir algo relacionado con sensores, datos industriales y automatización.
El problema que nos plantearon estaba relacionado con el mantenimiento de maquinaria. Las industrias generan enormes cantidades de información proveniente de sensores, pero muchos sistemas de mantenimiento actuales simplemente lanzan alertas sin explicar cómo llegaron a esa conclusión. Para los ingenieros resulta difícil confiar en una predicción si no pueden entender el motivo detrás de ella.
Nuestra idea fue crear un sistema de mantenimiento predictivo explicable. No queríamos construir una herramienta que solo dijera qué estaba fallando, sino una solución capaz de mostrar por qué había llegado a esa conclusión.
Así nació TraceMaint.
La idea central del proyecto era bastante simple: los sistemas de inteligencia artificial utilizados en entornos industriales no deberían funcionar como cajas negras. Si una máquina indica que una bomba está a punto de fallar, el técnico necesita saber qué señales provocaron esa predicción, qué reglas fueron activadas y qué evidencia existe detrás de la decisión.
Creamos el concepto de “traza primero”. La explicación no debía agregarse después como un complemento, sino formar parte del diseño desde el inicio. Muchos sistemas predicen primero y buscan una explicación después, lo que puede generar justificaciones poco fiables. Nosotros queríamos que cada alerta tuviera un historial completo y verificable del proceso que llevó a esa decisión.
La arquitectura del proyecto estaba dividida en tres partes principales, cada una con una responsabilidad concreta.
La primera capa era la recopilación y preparación de datos. Como no teníamos acceso a una fábrica real durante el evento, simulamos diferentes equipos industriales como bombas, compresores y sistemas transportadores. Creamos generadores de datos capaces de producir lecturas similares a las que entregarían sensores reales.
Después, esos datos pasaban por una etapa de procesamiento donde las señales originales se transformaban en métricas más útiles, como tendencias, cambios entre mediciones y valores estadísticos. Básicamente, esta parte funcionaba como los sentidos del sistema: observaba el estado de las máquinas y convertía sus señales en información que pudiera analizarse.
La segunda capa era el núcleo del proyecto: el motor de trazabilidad.
En lugar de utilizar un modelo complejo imposible de inspeccionar, construimos un sistema de inferencia basado en reglas. Definimos condiciones específicas sobre los datos de los sensores y, cuando alguna regla se activaba, el sistema no solo generaba una alerta, sino que guardaba todo el camino de razonamiento.
Cada decisión quedaba registrada en una estructura de datos que funcionaba como un historial detallado. Allí se almacenaban las reglas activadas, el orden en que ocurrieron y cómo cada una contribuyó al nivel final de confianza.
También desarrollamos una interfaz visual donde podíamos observar las alertas en tiempo real y revisar las explicaciones generadas por el sistema. Ver todo funcionando después de tantas horas programando durante el hackathon fue una de esas experiencias que hacen que todo el esfuerzo valga la pena.
La tercera parte era la capa de interpretación inteligente.
Una vez que el motor de trazabilidad generaba una alerta con su explicación, necesitábamos convertir esa información técnica en una recomendación útil para una persona. Para conseguirlo, utilizamos un enfoque donde el sistema primero recuperaba información relevante de documentación técnica y después generaba una respuesta basada en esos datos.
La inteligencia artificial no debía inventar una solución desde cero. Primero debía consultar información relacionada con el problema específico y luego transformar esos datos en instrucciones claras para el técnico encargado del mantenimiento.
Como estábamos desarrollando todo dentro de un evento limitado en tiempo, simulamos algunos servicios necesarios para demostrar el flujo completo del sistema.
Imaginemos a un ingeniero de mantenimiento trabajando en una planta industrial durante la madrugada. Recibe una alerta indicando que la vibración de un motor ha aumentado constantemente durante varias horas y que existe una alta probabilidad de fallo en poco tiempo.
Un sistema tradicional simplemente mostraría algo como: “posible fallo del componente”.
Nuestro sistema ofrecía mucho más contexto.
Indicaba qué regla se había activado porque la vibración había superado un límite determinado. Después mostraba que otra condición también se había cumplido porque el cambio entre mediciones recientes había aumentado demasiado. Finalmente combinaba ambas señales y explicaba cómo se alcanzó el nivel de confianza necesario para generar la alerta.
A partir de esa información, el sistema podía recomendar acciones concretas: revisar la lubricación, inspeccionar posibles daños iniciales y programar una intervención antes de que ocurriera una parada inesperada.
Aunque no ganamos el hackathon, el resultado terminó siendo mucho más valioso. Construimos una solución completa, enfrentamos problemas reales de diseño y aprendimos algo que ningún tutorial podía enseñar: cómo convertir una idea en un producto funcional bajo presión.
La mayor lección fue entender que una buena aplicación de inteligencia artificial no depende únicamente de hacer predicciones precisas. En muchos escenarios, la confianza, la transparencia y la capacidad de explicar una decisión son igual de importantes.
Ese proyecto cambió nuestra forma de pensar sobre el software. No se trata solo de crear sistemas que funcionen, sino de construir herramientas que las personas puedan comprender y en las que puedan confiar.