Tres personas, cuatro analizadores, una interfaz convertida en jardín y una entrega cerrada prácticamente a las cinco de la mañana. Esta es la historia de Bob Break, el prototipo con el que participamos en la IBM TechXchange 2026 Pre-conference Dev Day Hackathon.
La idea en una frase
IBM Bob reduce la carga de trabajo. Bob Break intenta reducir la carga cognitiva que queda mientras los agentes trabajan.
La entrega de las cinco de la mañana
A las 04:45 de la madrugada del 30 de agosto, hora peninsular española, el repositorio recibió su último envío antes de la entrega. Para entonces ya no estábamos hablando de una idea escrita en una presentación. Bob Break tenía una interfaz funcional, cuatro analizadores, un sistema de eventos, pruebas y una narrativa de producto.
El proyecto fue construido por un equipo de tres personas —Tony Wang, Silvia Tormo y Sandra Tormo— para la IBM TechXchange 2026 Pre-conference Dev Day Hackathon, celebrada entre el 28 y el 30 de agosto bajo el reto Build with purpose using IBM Bob 2.0.
La propuesta de IBM invitaba a mejorar un flujo concreto del trabajo de desarrollo: depuración, pruebas, mantenimiento, revisión de código o preparación de una entrega. Nuestro equipo eligió un problema menos visible, pero cada vez más habitual: la fatiga de vigilar a los agentes de inteligencia artificial mientras ejecutan tareas en paralelo.
La madrugada forma parte del proyecto porque resume su contradicción. Estábamos construyendo una herramienta destinada a proteger la atención mientras apurábamos cada minuto para llegar a tiempo. Precisamente por eso entendimos el problema desde dentro.
Cuando la IA ahorra tiempo, pero no libera la atención
Los agentes de programación pueden analizar repositorios, ejecutar pruebas, revisar dependencias y generar documentación. Sin embargo, durante una operación larga el desarrollador sigue mirando la pantalla para resolver preguntas básicas: ¿continúa trabajando?, ¿se ha bloqueado?, ¿ha aparecido un error?, ¿puedo alejarme unos minutos sin perder una decisión importante?
El resultado es una nueva forma de espera ansiosa. Ya no escribimos cada línea de código, pero tampoco sentimos que podamos abandonar el flujo. Revisamos terminales, mensajes y barras de progreso aunque la mayoría de los eventos no requieran ninguna acción.
El cuello de botella deja de ser la velocidad a la que trabaja el agente y pasa a ser la cantidad de información que una persona puede procesar sin sentirse saturada.
Bob Break nació para separar dos cosas que las interfaces técnicas suelen mezclar: lo que está ocurriendo y lo que realmente necesita atención humana.
Qué es Bob Break
Bob Break es una capa de gestión de la atención para flujos de desarrollo con agentes. En lugar de mostrar una corriente continua de registros técnicos, traduce el trabajo en un estado visual tranquilo. El progreso ordinario se acumula silenciosamente; las preguntas, bloqueos y riesgos siguen caminos distintos.
El prototipo presentado en la hackathon convirtió ese concepto en un prototipo capaz de analizar una carpeta real elegida por el usuario. Sus cuatro analizadores se ejecutan sobre el proyecto y generan eventos con un formato común. La interfaz interpreta esos eventos y representa el avance como un jardín digital.
El jardín no pretende infantilizar el trabajo. Funciona como una compresión visual: una planta que crece comunica que el agente continúa avanzando sin exigir la lectura de veinte mensajes intermedios.
Cuatro plantas para cuatro tareas reales
El prototipo utiliza cuatro analizadores paralelos dedicados a una comprobación de preparación para lanzamiento o release readiness:
- Diff Analyst: examina cambios y registros de Git para describir la superficie real de la modificación.
- Dependency Scanner: revisa archivos como
package.jsony el fichero de bloqueo para detectar cambios de versiones y posibles incompatibilidades. - Test Runner: procesa la salida de las pruebas y diferencia ejecuciones correctas, fallos y suites pendientes.
- Documentation Writer: revisa README y CHANGELOG para señalar documentación desactualizada y preparar el resumen de la entrega.
Cada tarea tiene su propia planta. Una semilla indica que el analizador está planificado; el brote y el crecimiento representan trabajo en curso; la flor señala que la tarea ha finalizado. Si el sistema espera una decisión, el jardín se pausa. Si aparece un bloqueo, el estado cambia a ámbar. Los riesgos críticos abandonan deliberadamente la calma visual y se muestran como alertas.
No todas las interrupciones tienen el mismo valor
El núcleo del proyecto no es la animación, sino el Attention Manager. Este componente recibe cada evento y decide cómo debe llegar al usuario.
| Tipo de evento | Respuesta de Bob Break |
|---|---|
| Progreso informativo | Se agrega silenciosamente y hace crecer la planta. |
| Pregunta | Se pausa el jardín y aparece una decisión breve y estructurada. |
| Bloqueo | Se muestra un aviso calmado que identifica la tarea detenida. |
| Riesgo crítico | Se genera una alerta inmediata. |
| Finalización | La planta florece y el resultado pasa al informe final. |
Esta clasificación permite que el desarrollador deje de interpretar cada mensaje por separado. La interfaz solo reclama atención cuando responder cambia el curso del trabajo.
La arquitectura: agentes, eventos y una única puerta de entrada
Bob Break está desarrollado con React 18, TypeScript y Vite. Las pruebas utilizan Vitest y la interfaz se apoya en CSS personalizado para las transiciones, el crecimiento de las plantas y la respiración guiada.
Los cuatro analizadores producen objetos JSON con campos como el analizador de origen, la fase, el tipo y la gravedad. Todos llegan a un Event Adapter, la única pieza que necesita conocer la procedencia del evento. Después, el Attention Manager decide si el dato alimenta el jardín, abre una decisión, activa una alerta o se conserva para el informe.
Esta separación es importante. Hoy los eventos proceden de analizadores locales; mañana podrían llegar desde un flujo de subagentes de IBM Bob. En ese escenario sería necesario sustituir la entrada del adaptador, no reconstruir toda la experiencia.
Analizadores → Event Adapter → Attention Manager
├─ Jardín
├─ Decisión
├─ Alerta
└─ Informe de entregaPrivacidad local: la carpeta no se sube a ningún servidor
El usuario selecciona una carpeta mediante la File System Access API del navegador. Los archivos de texto se leen localmente y los analizadores trabajan sobre ellos sin subir el proyecto a un servicio externo.
Esta decisión encaja con el tipo de repositorios que Bob Break quiere acompañar: proyectos en los que el código, las dependencias o la lógica empresarial pueden ser sensibles. También impone una limitación actual: la selección directa de carpetas funciona principalmente en navegadores basados en Chromium, como Chrome y Edge.
Qué hizo IBM Bob 2.0 durante la hackathon
IBM Bob no fue únicamente el tema de la competición. Su modo agente y sus subagentes se utilizaron para planificar la arquitectura, separar tareas, generar componentes, preparar pruebas y documentar el proyecto.
El equipo empleó contextos aislados para que el trabajo sobre la interfaz, los analizadores y las pruebas no contaminara el resto de tareas. La comprensión de documentos permitió que Bob siguiera las especificaciones internas del proyecto, mientras que las reglas personalizadas ayudaron a mantener un estilo coherente en la categorización de cambios y la documentación.
En la fase final, cuando se agotaron los Bobcoins disponibles, el equipo recurrió también a Claude para formalizar parte del código. Lo contamos porque una crónica de una hackathon debe explicar no solo el resultado, sino también las herramientas y restricciones reales del proceso.
Lo que funciona y lo que todavía no debemos afirmar
El prototipo ejecuta cuatro analizadores sobre una carpeta real, genera eventos, los clasifica, actualiza la interfaz y construye un informe de preparación para el lanzamiento. El jardín, las decisiones, las alertas y el sistema de resumen son componentes funcionales.
Sin embargo, Bob Break todavía no se conecta directamente a un proceso activo del IDE de IBM Bob ni recibe sus eventos internos en tiempo real. Esa integración es la evolución prevista, pero no forma parte de la versión entregada. El prototipo demuestra que la capa de atención funciona y que la arquitectura dispone de un punto preparado para cambiar la fuente de eventos.
Esta distinción hace que el proyecto sea más sólido. No necesita simular una integración inexistente para demostrar su valor: el problema, el clasificador y la experiencia visual ya pueden probarse con trabajo real ejecutado en el navegador.
¿Reduce realmente el 91 % de las interrupciones?
El diseño del prototipo utiliza como referencia una ejecución de 120 eventos en la que solo 11 llegarían al desarrollador. Eso supondría mantener en segundo plano aproximadamente nueve de cada diez actualizaciones.
No es todavía un resultado científico ni una métrica obtenida con una muestra de usuarios. Es un objetivo de diseño que el propio sistema puede medir en cada ejecución: eventos producidos, eventos mostrados, decisiones solicitadas y tiempo hasta obtener un informe revisable.
La siguiente fase debería comparar esos datos con sesiones convencionales y estudiar si disminuyen las comprobaciones repetitivas, los cambios de contexto y la exposición continua a texto técnico. Bob Break no debe inventar productividad: debe instrumentarla y demostrarla.
IBM Bob más allá del autocompletado
IBM presenta Bob como un agente de desarrollo orientado al ciclo de vida completo del software. Sus casos de uso oficiales incluyen creación de funciones, pruebas, integración de API, seguridad y modernización de aplicaciones Java, IBM i y mainframe.
La diferencia frente a un asistente de autocompletado es el alcance. Bob puede trabajar con el contexto del repositorio, seguir flujos estructurados y participar en tareas que atraviesan análisis, implementación, validación y documentación.
Bob Break explora la consecuencia humana de ese cambio. Cuanto más autónomos sean los agentes, menos sentido tiene que sus interfaces obliguen a observar cada paso. La autonomía técnica necesita una nueva arquitectura de atención.
Lo que aprendimos aquella madrugada
La primera lección fue que una interfaz calmada no consiste simplemente en utilizar colores suaves. La calma procede de saber que el sistema avisará cuando ocurra algo importante. Sin esa confianza, cualquier jardín se convierte en otra pantalla que comprobar.
La segunda fue que el progreso visual debe corresponderse con trabajo real. Cada planta necesita representar una tarea, un estado y un resultado reconocibles. La metáfora funciona cuando conserva trazabilidad técnica.
La tercera fue que la transparencia fortalece el proyecto. Explicar qué es funcional, qué es un objetivo y qué pertenece a la hoja de ruta genera más confianza que presentar una demo como si fuera un producto terminado.
Y la última fue profundamente humana: detrás de los agentes capaces de trabajar en paralelo seguía existiendo un equipo de tres personas tomando decisiones, corrigiendo detalles y mirando el reloj hasta casi las cinco de la mañana.
