Es una escena conocida en casi cualquier equipo de desarrollo: alguien necesita entender una parte del sistema y termina bloqueado, esperando a la única persona, generalmente un perfil senior, que tiene ese conocimiento tácito de la organización. El proceso suele describirse como recorrer un grafo: el developer va preguntando de persona en persona hasta llegar finalmente al experto, que casi siempre está demasiado ocupado como para responder rápido.
Ese cuello de botella no es solo una molestia puntual: equipos que trabajan en gestión de incidentes dentro de las organizaciones confirman que los problemas terminan resolviéndose siempre a través de las mismas pocas personas. No es que el resto no sepa, sino que entrar a sistemas legados de operación crítica implica una curva de aprendizaje que no se acorta fácilmente. Con el tiempo, esa dinámica termina condicionando también la velocidad con la que un equipo puede responder a cambios de negocio.
Cómo Bob democratiza el entendimiento del código
Frente a ese problema, IBM Bob apunta a que cualquier desarrollador pueda entender sistemas complejos sin depender de un compañero puntual, a través de dos funcionalidades concretas. La primera es Agent MB, un archivo de contexto que funciona de forma similar a un Readme, pero pensado para que la IA lo interprete: le permite a Bob leer la lógica de la aplicación y detectar con rapidez dónde puede estar un problema, sin que el desarrollador tenga que leer todo el proyecto de punta a punta. Esto también tiene un efecto práctico sobre el costo de uso: en lugar de compartir con Bob todo el proyecto cada vez que surge una consulta, alcanza con que la IA entienda el contexto puntual del problema para poder avanzar.
La segunda son las Rules, o reglas, que permiten definir parámetros claros de programación para evitar que la IA genere código distinto cada vez que se le pide algo similar. Esto mantiene la consistencia del sistema y ayuda a sostener la gobernanza del código a lo largo del tiempo, algo especialmente valioso cuando distintos desarrolladores tocan el mismo proyecto.
El impacto en el día a día del developer
Cuando un equipo deja de depender del “gurú” para avanzar, el impacto se nota en varios frentes: mejora el go-to-market, es decir, el tiempo que tarda una funcionalidad en llegar al mercado; se termina el backlog mucho más rápido; y los cambios de último momento se pueden encarar con mucha más confianza, sin el temor de romper algo que nadie más entiende del todo.
La interacción con Bob busca parecerse, salvando las distancias, a tomarse un café con el experto: el developer hace preguntas en lenguaje natural sobre métodos, clases o paradigmas de programación, y recibe respuestas orientadas al contexto puntual de su sistema. Una característica que vale la pena destacar es que, si Bob detecta una pregunta ambigua, no avanza a ciegas: lanza una pregunta de desambiguación para asegurarse de trabajar con una dirección clara antes de sugerir cualquier cambio.
Bob frente a otras herramientas del mercado
Vale la pena situar a Bob dentro del panorama de herramientas similares. Las comparaciones más cercanas son Kiro, de AWS, y Claude Code, de Anthropic, ya que ambas comparten con Bob una lógica agéntica: el usuario crea un agente y es la herramienta la que selecciona por detrás el modelo adecuado. La diferencia frente a Claude Code es sutil pero relevante: Anthropic ofrece un único modelo para trabajar, mientras que Bob y Kiro gestionan esa selección de forma automática según la tarea.
Esa diferencia técnica explica, en buena medida, por qué este tipo de herramientas logra ir más allá de sugerir líneas de código sueltas: al sostener contexto y reglas de forma persistente, terminan funcionando más como un compañero de equipo que entiende el sistema, que como un simple asistente que responde una pregunta a la vez. Para un equipo que antes dependía de una sola persona para avanzar, esa diferencia termina siendo, en la práctica, la que más pesa en el día a día.
Compartir nota:
