Cuando el trabajo deja de ser una conversación lineal, la arquitectura del contexto y la delegación se convierten en parte del diseño del sistema.

De pedir código a delegar trabajo

En un asistente tradicional, el usuario formula una pregunta y recibe una respuesta. En un sistema agéntico, la unidad fundamental cambia: el usuario entrega un objetivo y el sistema organiza trabajo. Para conseguirlo necesita memoria de la tarea, herramientas, permisos y capacidad de dividir un problema en partes.
IBM Bob incorpora subagentes precisamente para realizar tareas enfocadas en contextos separados. Según su documentación, un subagente se ejecuta con su propia ventana de contexto, recibe una tarea acotada y devuelve un resumen al agente principal. Esta separación evita llenar la conversación central con grandes cantidades de información irrelevante y permite especialización.

Figura 3. Patrón conceptual de coordinación entre intención, agente principal, subagentes y herramientas. Elaboración CPS.

Agente, subagente, skill, tool y harness: no son lo mismo

La herencia watsonx dentro del harness: elegir el modelo por tarea

Una arquitectura agéntica no debería asumir que todas las tareas requieren el mismo modelo. Analizar una arquitectura, completar una edición local, clasificar un ticket o revisar una vulnerabilidad tienen perfiles diferentes de costo, latencia y razonamiento. Bob incorpora precisamente esta idea mediante orquestación multimodelo: la plataforma decide qué modelo resulta adecuado para una tarea, en lugar de obligar al desarrollador a administrar manualmente proveedores, versiones y tokens.
Para un Arquitecto de IA, esto cambia el diseño del harness. El “modelo” deja de ser el centro fijo del sistema y se vuelve un recurso intercambiable detrás de una política de enrutamiento. Lo estable deben ser la intención, las reglas, las herramientas, la evidencia y los criterios de aceptación. Bob puede recurrir a Granite, Claude, Mistral u otros modelos especializados; el proceso de ingeniería debe seguir siendo coherente aunque cambie el motor que resuelve una subtarea.
Esta es una lección especialmente útil para organizaciones que ya trabajaron con Watson o watsonx: el valor acumulado no está únicamente en un modelo concreto, sino en haber desarrollado contexto empresarial, reglas, integraciones y gobierno que pueden reutilizarse al pasar a una arquitectura más agéntica.

Por qué el aislamiento de contexto importa

En nuestros ejercicios con arquitecturas multiagente —por ejemplo, separar funciones de PMO y Contraloría— una lección aparece rápidamente: compartir todo con todos no mejora necesariamente la calidad. Aumenta el ruido, mezcla responsabilidades y consume contexto. Es preferible que el agente principal entregue a cada subagente exactamente lo necesario y reciba de regreso un artefacto o resumen que pueda integrar.
Bob documenta dos tipos de subagentes: Explore, orientado a exploración de codebase en solo lectura, y General, con acceso completo a herramientas para trabajos autónomos. Conceptualmente, la diferencia refleja un principio de mínimo privilegio: no toda investigación necesita permisos de escritura o ejecución.

Un ejemplo: implementar una nueva API

Supongamos que un equipo necesita incorporar un endpoint para registrar una operación sensible. En un enfoque agéntico, el trabajo podría organizarse así:

1. El agente principal interpreta la historia y sus criterios de aceptación.
2. Un subagente Explore localiza controladores, modelos, convenciones de validación y pruebas existentes.
3. El modo Plan propone cambios, dependencias y riesgos.
4. Tras la aprobación, Agent modifica los archivos necesarios.
5. Una skill de seguridad verifica controles mínimos: validación de entrada, gestión de secretos y logging.
6. Se ejecutan pruebas y análisis estático; los resultados regresan al agente principal.
7. El humano revisa el diff y decide si el cambio continúa hacia el pipeline.

Lo relevante no es si esta secuencia exacta ocurre siempre de forma automática. Lo importante es que el trabajo puede diseñarse como un proceso explícito, con límites, entradas y salidas verificables.

El repositorio debe contener más que código

Los agentes funcionan mejor cuando pueden encontrar decisiones y reglas cerca del trabajo. Por eso la documentación arquitectónica, los ADR, estándares de seguridad, convenciones de nombres, Definition of Done y ejemplos de referencia dejan de ser “documentación administrativa” y se vuelven contexto operativo.
Esta idea conecta con algo que hemos aplicado en otros dominios: una IA puede ser muy capaz, pero si la organización no formaliza sus reglas, el agente termina adivinándolas. La calidad de la automatización depende de la calidad del conocimiento institucional disponible.

El papel del Arquitecto de IA

• Diseñar qué información entra al contexto y qué información queda fuera.
• Definir fronteras entre agente principal y subagentes.
• Convertir prácticas repetibles en skills.
• Asignar tools y permisos bajo mínimo privilegio.
• Definir gates de aprobación y evidencia.
• Medir no sólo velocidad, sino calidad, riesgo y retrabajo.

Conclusión

Bob permite observar el desarrollo de software como una red de trabajo especializada. El IDE deja de ser sólo un editor y se acerca a un entorno de coordinación. Esa evolución abre oportunidades importantes, pero obliga a diseñar con rigor el contexto, la delegación y los permisos. La arquitectura agéntica es, en esencia, arquitectura de responsabilidades.

Diseña tu primer flujo agéntico

CPS puede tomar un caso de uso real —una API, una modernización, documentación o pruebas— y convertirlo en un flujo reproducible con roles, skills, herramientas, aprobaciones y métricas.
Solicita un workshop de diseño de agentes y subagentes para desarrollo.

La nueva frontera no es completar código más rápido, sino convertir intención, contexto y reglas de ingeniería en trabajo ejecutable y verificable.

La IA ya aprendió a escribir código. ¿Qué sigue?

Durante los primeros años de la IA generativa aplicada al desarrollo, la conversación estuvo dominada por una pregunta sencilla: ¿cuánto código puede escribir una máquina? El autocomplete inteligente fue la primera respuesta. Después llegó el chat integrado al IDE: explicar una función, generar una clase, proponer una consulta SQL o refactorizar un bloque. Esa etapa produjo valor, pero mantuvo intacto un supuesto: el desarrollador seguía siendo quien sostenía casi todo el contexto y coordinaba cada paso.

IBM Bob representa una transición diferente. IBM lo presenta como un socio de desarrollo centrado en IA para equipos empresariales, capaz de trabajar a lo largo del ciclo de vida del software: planeación, programación, pruebas, despliegue y modernización. La diferencia de lenguaje importa. Un “asistente” responde; un “socio de desarrollo” participa en un proceso.

Para CPS, ese cambio conecta con una experiencia que hemos observado en distintos dominios: cuando la IA deja de ser una ventana de chat y entra al proceso, aparecen inmediatamente preguntas de arquitectura. ¿Qué contexto recibe? ¿Qué herramientas puede usar? ¿Qué puede modificar? ¿Qué debe aprobar una persona? ¿Qué evidencia queda? La calidad del resultado depende menos de un prompt brillante y más del sistema que rodea al agente.

Figura 1. Evolución conceptual desde asistencia puntual hasta participación en el SDLC. Elaboración CPS.

De Watson a watsonx: el terreno que hizo posible a Bob

Para entender por qué Bob aparece ahora —y por qué IBM lo orienta a la empresa— conviene mirar la evolución de su propia estrategia de inteligencia artificial. En 2011, Watson demostró una capacidad que entonces era extraordinaria: interpretar preguntas en lenguaje natural, generar hipótesis, reunir evidencia y asignar confianza a posibles respuestas. Su victoria en Jeopardy! fue una demostración pública, pero el aprendizaje más importante fue empresarial: una máquina podía razonar sobre grandes volúmenes de información no estructurada y devolver una respuesta utilizable.

Watson no era un agente de desarrollo ni el antecesor directo de Bob en sentido de producto. Su contribución histórica fue establecer principios que hoy reaparecen en formas más avanzadas: interacción en lenguaje natural, uso de evidencia, confianza probabilística, integración de IA con procesos empresariales y la necesidad de gobernar decisiones automatizadas. En 2013, Watson Developer Cloud trasladó parte de esa capacidad al modelo de servicios y APIs, acercando la IA a aplicaciones de negocio.

El siguiente salto llegó con watsonx. IBM anunció la plataforma en 2023 como una plataforma de IA y datos para modelos fundacionales y generativos, con watsonx.ai, watsonx.data y watsonx.governance. Con ella cambió el centro de gravedad: de una IA especializada en responder preguntas a una plataforma capaz de construir, desplegar y gobernar múltiples modelos y soluciones empresariales. IBM Research resumía entonces una idea que hoy resulta clave para Bob: no existe “un modelo para gobernarlos a todos”; diferentes tareas requieren modelos distintos.

Ese principio aparece hoy de forma muy visible en Bob. IBM indica que Bob enruta tareas entre distintos modelos según precisión, rendimiento y costo, usando una combinación que incluye IBM Granite, Anthropic Claude, Mistral y modelos especializados. Así, la herencia de watsonx no debe entenderse como que Bob sea simplemente “watsonx dentro de un IDE”, sino como una continuidad de arquitectura: pluralidad de modelos, uso empresarial, gobierno y optimización por tarea.

Figura 2. De Watson a Bob: evolución de capacidades de IA empresarial en IBM. Elaboración CPS con base en fuentes públicas de IBM.

El puente directo: watsonx Code Assistant

Hay, sin embargo, un antecedente mucho más directo. IBM señala que Bob “consolida y extiende el legado de watsonx Code Assistant” dentro de una oferta integrada. Watsonx Code Assistant llevó modelos generativos al trabajo de programación y modernización; Bob amplía la unidad de trabajo desde la asistencia de código hacia un SDLC agéntico capaz de planear, ejecutar, validar, delegar y mantener contexto a lo largo de tareas de varios pasos.

Esta distinción ayuda a explicar el cambio de generación: Watson mostró que la IA podía comprender preguntas; watsonx convirtió los modelos fundacionales en plataforma empresarial; watsonx Code Assistant aplicó esa plataforma al trabajo de desarrollo; y Bob intenta convertir la IA en un participante operativo del ciclo de vida del software.

Bob no es únicamente un generador de código

En el modelo clásico de IA asistida, una interacción comienza y termina con una respuesta. En un entorno agéntico, una petición puede convertirse en una secuencia de trabajo: entender un repositorio, identificar dependencias, producir un plan, modificar archivos, ejecutar pruebas, detectar errores, corregirlos y solicitar aprobación. Esa secuencia es mucho más cercana a una unidad de trabajo de ingeniería que a una simple conversación.

• Comprender el workspace y localizar artefactos relevantes antes de cambiar código.
• Separar planificación de implementación mediante modos de trabajo.
• Usar herramientas para leer, editar, ejecutar y conectarse a servicios externos.
• Delegar exploraciones específicas a subagentes con contexto aislado.
• Mantener al humano dentro del circuito mediante aprobaciones y revisión.

Del prompt a la intención de ingeniería

Una de las transformaciones más relevantes es el nivel de abstracción. En lugar de pedir “escribe una función que haga X”, un equipo puede expresar una intención de mayor nivel: “agrega soporte para una nueva forma de autenticación respetando estos estándares, sin romper compatibilidad y dejando pruebas y documentación”. Resolver correctamente esa petición exige descubrir arquitectura, identificar restricciones y ordenar acciones.

Esto cambia también el papel del desarrollador. La capacidad crítica ya no es solamente producir sintaxis. Aumenta el valor de saber especificar, revisar, cuestionar decisiones, reconocer riesgos y definir criterios de aceptación. En otras palabras, el trabajo se desplaza parcialmente de la ejecución manual hacia el diseño y la supervisión.

Modes: separar pensar, preguntar y actuar

Bob incluye modos integrados como Plan, Agent y Ask. Esta separación es más importante de lo que parece porque introduce una frontera de comportamiento y permisos. Plan privilegia el diseño antes de ejecutar; Ask permite comprender y analizar sin entrar directamente a modificar; Agent habilita la implementación. Además, IBM permite personalizar modos y definir acceso a herramientas, archivos e instrucciones.

Desde arquitectura de IA, este patrón es familiar: no conviene que un mismo agente tenga siempre todas las capacidades activas. La especialización reduce ambigüedad y permite imponer restricciones. En proyectos previos hemos usado el mismo principio para separar funciones de PMO, Contraloría, seguridad o documentación. Bob lleva ese enfoque al ciclo de desarrollo.

La conversación correcta no es “¿me reemplaza?”

La pregunta productiva es otra: ¿qué parte del trabajo puede delegarse de forma segura y repetible, y qué decisiones deben permanecer bajo responsabilidad humana? La arquitectura, la propiedad del producto, la revisión, el conocimiento del negocio, la aceptación del riesgo y la responsabilidad sobre producción siguen requiriendo juicio. La IA modifica la distribución del esfuerzo; no elimina la necesidad de ingeniería.

Qué debería observar una organización

1. Si Bob comprende correctamente el contexto del repositorio y sus convenciones.
2. Si los planes producidos son revisables y trazables.
3. Si los cambios quedan asociados a pruebas, evidencia y criterios de aceptación.
4. Si los permisos de herramientas corresponden al riesgo de la tarea.
5. Si el uso reduce tiempo de ciclo sin elevar defectos, retrabajo o deuda técnica.

Conclusión

IBM Bob es interesante no porque demuestre que una IA puede programar, sino porque materializa una evolución del entorno de desarrollo hacia un sistema donde la IA puede planificar, actuar, delegar y colaborar bajo controles. Para empresas que buscan productividad sostenible, esa distinción es esencial. El objetivo no es producir más líneas de código; es convertir intención de negocio en software confiable con menos fricción.

Evalúa tu punto de partida

CPS puede ayudarte a identificar qué actividades de tu SDLC son candidatas para asistencia, automatización o delegación agéntica, y qué controles deben existir antes de escalar.
Conversemos sobre un assessment de desarrollo agéntico para tu equipo.