El desarrollo de software agéntico está cambiando a una velocidad sin precedentes, incluso para los estándares del mundo tecnológico. Los tutoriales y recursos disponibles en internet cubren en su mayoría funcionalidades individuales en escenarios sencillos desde cero.
Durante la construcción de Bob y al interactuar con innumerables profesionales del sector en una amplia variedad de industrias, emergió un conjunto de conceptos que ayudan a mejorar la efectividad y la experiencia de uso de Bob.
Estos conceptos también se aplican a proyectos complejos que utilizan tecnologías no convencionales.
Concepto 1: El ciclo — explorar, planificar, implementar, verificar
El fallo más habitual en la ingeniería de software agéntica es la ausencia de estructura. La coherencia conversacional imita a la estructura y nos tienta a condensar todos los pasos de una implementación en una sola conversación. Las sesiones parecen productivas, pero el coste solo se hace visible en la revisión.
Escribir código a mano imponía una estructura propia. La implementación era costosa, por lo que planificar antes de implementar resultaba intuitivamente razonable. La comprensión se acumulaba mientras escribías y las suposiciones erróneas tendían a aflorar durante ese proceso. Los agentes de IA eliminan esa fricción. El código es barato ahora, y eso también ha eliminado nuestra intuición para la estructura. La estructura que antes era un subproducto de la lentitud ahora debe ser deliberada.
Usar este ciclo de forma deliberada puede proporcionar esa estructura:
- Explorar produce comprensión
- Planificar produce decisiones
- Implementar produce código
- Verificar produce evidencia.
Seguir este ciclo te ayuda a mantenerte enfocado, con estructura, y a alcanzar tus objetivos de forma más rápida y consistente.
Un único recorrido por el ciclo puede durar veinte minutos o tres días. Un recorrido puede contener sub-ciclos, y cómo se distribuye el tiempo entre las fases varía mucho según la tarea.
Puedes encontrar una descripción detallada del ciclo más adelante en Análisis en profundidad: Ejecuta el ciclo.
Concepto 2: La ventana de contexto es el recurso escaso
Ser consciente de la ventana de contexto es el hábito con mayor retorno.
¿Qué es la ventana de contexto?
Los modelos son sin estado. Un chat no es una sesión activa con memoria: cada turno reenvía todos los mensajes anteriores y añade la nueva respuesta al final. La ventana de contexto es la cantidad máxima de entrada que un modelo puede aceptar en uno de esos turnos. En Bob V2 son 270k tokens (gestión de la ventana de contexto).
La ventana se llena antes del primer mensaje:
- Cargado desde el inicio: el prompt del sistema de Bob, la descripción del modo activo, el
agents.mddel repositorio y una descripción de cada herramienta del Model Context Protocol (MCP) conectada (MCP en Bob). - Añadido durante la sesión, de forma invisible: lecturas de archivos, resultados de herramientas, archivos de skills que Bob carga, salida de subagentes.
Cuando la ventana se llena, Bob compacta la conversación. Bob sustituye la conversación hasta ese momento por un resumen y el trabajo continúa. Esto mantiene la sesión activa, y es intencionalmente impreciso. Bob decide automáticamente qué detalles sobreviven, y nada señala los que no lo hacen. Una sesión que ha sido compactada dos veces funciona sobre el resumen de un resumen.
Una sola llamada a MCP puede devolver decenas de miles de tokens, y una secuencia de lecturas de archivos diluye lo que se discutió antes en la sesión. Las descripciones de modos, los archivos de reglas y los servidores MCP lo hacen de forma más lenta y menos visible. Bob desglosa la ventana por origen, y vale la pena volver a revisar ese desglose cuando la configuración crece.
Los Bobcoins se calculan principalmente por token. Por eso, el coste de una conversación crece de forma cuadrática en relación a su longitud. ¡Las conversaciones largas cuestan muchos más Bobcoins que las cortas! (documentación de Bobcoins)
Trabaja con la ventana de contexto, no en su contra
- Divide el trabajo en conversaciones separadas. Una tarea, una sesión. Es el mismo razonamiento que el principio de responsabilidad única en el código. Una conversación debe tener una única razón de existir, como "dibuja un diagrama de arquitectura del componente X" o "crea un plan de implementación para la funcionalidad Y". Todo lo que hay en la ventana de contexto influye en lo que viene después, incluidos los enfoques que no funcionaron. Una sesión atascada tiende a seguir atascada, porque los intentos fallidos siguen ahí y el modelo los lee como evidencia sobre cómo es esta tarea (context poisoning).
- Haz rollback en lugar de discutir con Bob. Cuando una conversación deriva hacia un comportamiento no deseado, haz rollback al último mensaje correcto, cambia el mensaje y continúa desde ahí. Esto también deshace todos los cambios que Bob realizó localmente, lo que mantiene la ventana de contexto pequeña y limpia (rollback).
- Guarda en un archivo todo lo que valga la pena conservar, no en el chat. Los planes, hallazgos y decisiones pertenecen a un archivo. Un compañero puede revisar un documento markdown y pasárselo a una sesión nueva; con un historial de chat no se puede hacer ninguna de las dos cosas.
- Los subagentes mantienen el trabajo pesado fuera de la ventana de contexto. Bob decide cuándo ejecutar uno, y solo vuelven los hallazgos. Pedirlo directamente también funciona cuando una tarea va a producir salida que nadie necesita leer (subagents).
- Sé consciente de lo que entra en la ventana de contexto y si aporta valor. Revisa tus guías y sensores con regularidad, como se explica en el siguiente tema, y dedica tiempo a mejorarlos.
Concepto 3: Dos tipos de bloques fundamentales — guías y sensores
A lo largo de un proyecto extenso, que la base de código mejore o empeore depende menos de Bob que de lo que orienta su trabajo y comprueba su resultado. Hay muchos bloques disponibles: reglas, skills, modos, hooks, subagentes, linters externos y agentes de revisión. Casi todos hacen uno de dos trabajos.
- Las guías orientan a Bob antes o mientras trabaja (Feedforward). Las reglas, skills y modos son todas guías.
- Los sensores informan después de que Bob ha actuado (Feedback). Los tests, linters, type checkers, la sesión interactiva del navegador y los agentes de revisión son todos sensores.
1. Guías
Todo lo que se le proporciona a Bob para orientar el trabajo es una guía. Hay tres bloques principales que te ayudan con eso, y funcionan añadiendo texto a la ventana de contexto además del prompt que escribiste. Se diferencian en cuándo llega ese texto y qué lo activa.
- Las reglas siempre están activas.
agents.mden la raíz del repositorio es la principal, y el principal consejo al respecto es mantenerla corta. Cada línea compite por atención en cada turno, así que un archivo de reglas largo hace que Bob siga peor cada regla individual (rules). - Los modos los activa el usuario. Los modos integrados son: Ask es de solo lectura. Plan trabaja a través de un proceso de planificación y entrega el resultado a Agent, que toma acción. Se pueden añadir modos personalizados fácilmente (modes, añadir un modo personalizado).
- Las skills Bob las activa cuando las considera relevantes. Solo una pequeña descripción de la skill siempre está activa. El cuerpo principal de la skill solo se carga en el contexto cuando es necesario. Eso hace que las skills sean muy eficientes en tokens (skills).
Todo lo que está en el archivo de reglas consume tokens en cada turno, lo necesite o no ese turno, así que mantenlo mínimo y deja el resto esperando hasta que aplique.
2. Sensores
Todo lo que le proporciona a Bob feedback sobre el trabajo producido es un sensor. Las señales útiles dependen de la base de código y del stack, por lo que el conjunto que vale la pena tener varía de proyecto en proyecto y requiere un trabajo real para ensamblarse. Los sensores más valiosos son ejecutables por máquina y los ejecuta Bob durante la fase de implementación. Los sensores se pueden dividir en dos categorías.
- Los sensores computacionales son deterministas: tests, linters, type checkers, compiladores. Los veredictos son exactos y repetibles, y son suficientemente baratos para que Bob los ejecute con frecuencia. La cobertura está limitada por los sistemas que un equipo ha construido y mantiene.
- Los sensores basados en IA son flexibles y no deterministas. Un agente de revisión lee con intención, buscando lo que un linter no tiene reglas para detectar. El resultado es una valoración, no una medida. Varía entre ejecuciones, y el coste y la duración limitan la frecuencia con la que se puede usar (code reviews).
Para integrarlos hay varias opciones, en orden aproximado de fricción:
- Los hooks son la opción determinista de menor fricción. Una comprobación se ejecuta en un punto fijo, siempre, independientemente de si Bob la considera relevante. Consulta la documentación de hooks.
- Las skills se usan a menudo como guías, pero una skill que ejecuta una revisión es un sensor, y es la forma de menor fricción de añadir una comprobación no determinista. Consulta la documentación de skills.
- La integración continua (CI) coloca un agente de revisión en el pipeline, en cada pull request, para todo el equipo en lugar de un único desarrollador. Consulta el agente de revisión de PR en acción.
Análisis en profundidad: Ejecuta el ciclo
Los límites entre fases son también límites de contexto, que es la razón práctica para mantenerlos distintos: la charla de exploración no tiene nada que hacer en la conversación donde se escribe el código.
1. Explorar
La exploración varía enormemente dependiendo de tu rol y la tarea en cuestión. Puede significar incorporarse a una nueva base de código o estimar el radio de impacto de una refactorización mayor. Algunos ejemplos:
- Pídele a Bob que genere un diagrama de arquitectura del sistema existente antes de modificar nada. Consulta el tutorial para generar diagramas de arquitectura, o lo mismo en vídeo.
- Pide una guía de introducción personalizada desde dos ángulos: una vez como usuario recorriendo el producto y otra como desarrollador recorriendo el código. Aportar información sobre tu experiencia y tarea ayuda a personalizar el documento (inspecting a codebase).
- En IBM Z e IBM i, usa las opciones específicas de la plataforma. El problema de exploración en esos sistemas es distinto y se beneficia enormemente de las herramientas especializadas disponibles en los paquetes premium. Consulta el Paquete Premium para Z (docs) y el Paquete Premium para IBM i (docs).
La exploración también puede incluir construir cosas que se pretende eliminar. La implementación es barata ahora, así que un prototipo estrecho es la forma más rápida de descubrir si un enfoque sobrevive al contacto con la base de código. Kent Beck llamó a esto una implementación spike hace veinticinco años, y la disciplina es la misma: constrúyela para aprender algo, quédate con el aprendizaje, desecha el código.
La implementación barata aumenta el valor de la arquitectura y la calidad del código en lugar de reducirlo. Ahora es fácil producir una gran cantidad de código que funciona y está equivocado.
2. Planificar
La fase de planificación es donde existe el mayor apalancamiento. Todo lo que el plan resuelve correctamente se paga dos veces: una en la implementación, y otra cuando el cambio sale de las manos del autor y un compañero debe revisarlo.
Lo que necesita un buen plan:
- Breve y preciso, ambas cosas. Los planes necesitan ser leídos.
- Explícito sobre el resultado esperado, incluyendo las partes inciertas. Saber qué se desconoce es la mayor parte del trabajo, y averiguarlo es el resto.
- En un archivo. Los planes no deben vivir en una sesión de chat.
Hay muchas formas de crear un plan, pero el modo Plan integrado es el lugar más fácil para empezar (como en este tutorial).
El modo Plan está diseñado para ser conciliador y tiende a rellenar los vacíos. Si bien esto permite iteraciones rápidas en muchos casos, a veces se necesita más rigor. Podría construir un plan competente alrededor de una suposición errónea sin cuestionarla.
Una skill dedicada que cuestione el plan — grill-me de Matt Pocock, por ejemplo — es la forma más barata de obtener escrutinio antes de que la suposición se convierta en código.
Sobre el desarrollo guiado por especificaciones (SDD). El término abarca mucho terreno y aún está en evolución. La gente lo trata como una decisión binaria, pero se parece más a un espectro:
- Spec-first: el plan viene antes de la implementación. Esto es casi irrenunciable.
- Spec-anchored: la especificación permanece después de la implementación, como documentación y como el estándar que las implementaciones deben cumplir.
- Spec-as-source: la especificación es el archivo fuente. La persona edita la especificación; la persona no edita el código.
El nivel adecuado depende del equipo, la criticidad/madurez de la base de código y la industria. La sobrecarga que conllevan los niveles más altos de SDD puede ser dolorosa para la iteración rápida. En automoción, donde el desarrollo guiado por especificaciones precede a la IA en décadas, el SDD encaja muy bien con las prácticas existentes.
3. Implementar
La implementación es la fase más directa, y Bob se encarga de casi todo.
Observar a Bob trabajar e interrumpir para aclarar es opcional y a menudo útil. Trata la frecuencia como una señal: interrumpir constantemente significa que el problema está en el plan, y la solución es volver atrás en lugar de seguir corrigiendo.
No dudes en descartar toda una implementación y volver al modo Plan. El código es la parte barata.
4. Verificar
La verificación se divide en dos categorías distintas: verificación automatizada y verificación manual.
La verificación automatizada está impulsada por los sensores que Bob tiene disponibles o que se aplican mediante hooks. Se ejecutan con frecuencia durante la fase de implementación sin intervención humana. Las principales categorías con algunos ejemplos comunes son:
- Validez: ¿Compila, pasa el typecheck, se parsea?
- Medido: pass/fail, cobertura de tipos
- Herramientas:
tsc,mypy,cargo check,javac
- Comportamiento: ¿Hace lo correcto?
- Medido: tasa de éxito, cobertura de ramas
- Tests unitarios, tests de integración, tests end-to-end
- Herramientas:
pytest,Jest,Playwright,Stryker
- Mantenibilidad: ¿Vale la pena conservar este código?
- Medido: complejidad, duplicación, violaciones de límites
- Herramientas: ESLint, Ruff, Lizard, ArchUnit
- Seguridad: ¿Es este código seguro?
- Medido: hallazgos por severidad, CVEs
- Herramientas: Semgrep, CodeQL, gitleaks,
npm audit
Permiten a Bob detectar sus propios errores y mejorar la calidad durante la fase de implementación. Una buena cobertura de tests es una protección esencial contra las regresiones: garantiza que Bob no ha roto nada.
En este ciclo, la verificación aparece como una fase separada al final del bucle, lo que se refiere principalmente a la verificación manual. La verificación manual comienza ejecutando el cambio y comparando el comportamiento observado con el comportamiento que especificaba el plan. Una discrepancia suele reducirse a una de dos causas:
- La implementación se desvió del plan. La corrección está en el código.
- El plan no refleja lo que pretendías construir. El plan debe refinarse. Esto es mucho más habitual.
La inspección manual, por tanto, pone a prueba el plan y la implementación al mismo tiempo.
La verificación adicional debería ocurrir en los pipelines de CI/CD. Esta es una práctica bien establecida en la ingeniería de software, pero puede mejorarse utilizando agentes de codificación headless. Un ejemplo: una revisión automatizada en cada pull request, ejecutada mediante Bob Shell, complementa a los revisores humanos en lugar de reemplazarlos. Consulta el vídeo del agente de revisión de PR en acción y la documentación para ejecutar Bob Shell de forma no interactiva.
Trabajar en equipo
Todo lo descrito en las secciones anteriores describe el bucle interno de un único desarrollador. El bucle externo comienza cuando los cambios pasan a la cola de revisión. Cada diff llega ahora más rápido y con menos razonamiento adjunto, mientras el revisor tiene más que leer y menos contexto en el que hacerlo.
La evidencia debe viajar junto con el trabajo. El por qué importa más que antes, en relación al cómo, porque el cómo ya no es la parte costosa de producir.
En la práctica, esto significa que el plan viaja con el cambio: los equipos lo adjuntan al pull request o lo añaden al issue original junto con la revisión. El mecanismo depende de las herramientas.
Lo que el bucle externo hace al proceso de un equipo es un tema en sí mismo, que abordaremos en un próximo artículo.
Algunas reflexiones sobre los prompts
En los últimos años hubo un gran énfasis en redactar prompts correctamente para los LLMs, llegando a surgir toda una categoría de empleo como "ingeniero de prompts". En este momento, gran parte del prompting está gestionado dentro del harness. La importancia de las técnicas especializadas de prompting ha disminuido en favor de un enfoque metodológico. Estas son algunas pautas:
- Iterar supera al prompting. Cuando Bob hace algo distinto a lo que pediste, haz rollback y reescribe el mensaje que lo causó. Corregir hacia adelante deja la respuesta incorrecta, la queja al respecto y el reintento, todo ello en la ventana.
- La metodología supera al prompting. Un prompt tiene alcance para una sesión. Un archivo de reglas, o una comprobación que Bob puede ejecutar por sí mismo, sigue funcionando en cada sesión posterior a la que lo produjo, que es el único tipo de inversión aquí que se acumula.
- Dale a Bob el briefing que recibiría un ingeniero senior. Un compañero competente al que se le asigna una tarea vaga preguntará qué cuenta como hecho y qué tiene permitido tocar; Bob no preguntará, así que pon ambas cosas en el mensaje.
- Di qué hacer, no qué no hacer. "No uses class components" descarta una opción y deja el resto del espacio abierto, así que Bob elige entre lo que queda, que es otra suposición. Nombrar el objetivo en su lugar — function components con hooks — lo cierra en un turno.
- Cualquier instrucción dada más de dos veces pertenece a un archivo. Para eso sirven
agents.mdy las skills. - Instrucciones de prompting más detalladas se pueden encontrar en el tutorial para escribir prompts efectivos.
Conclusiones clave
- La ausencia de estructura es el mayor problema. Seguir el ciclo Explorar → Planificar → Implementar → Verificar te ayuda a mantenerte enfocado y a alcanzar tus objetivos de forma más rápida y consistente.
- El contexto es el recurso escaso, y las fases son límites de contexto. No arrastres la charla de exploración a la implementación.
- El plan es el artefacto de revisión. Revisar un plan supera a revisar un diff, tanto para el autor como para el revisor.
- Todo lo que vale la pena conservar sale del chat. Los planes, decisiones y hallazgos pertenecen a un archivo. Puedes hacer diff, revisar, versionar y pasar un archivo a otro agente.
- La verificación debe ser ejecutable por máquina, lo que significa que hay que diseñarla durante la planificación, no descubrirla después.
Fuentes y lecturas adicionales
- Simon Willison, Agentic engineering patterns
- Birgitta Böckeler, Harness engineering
Documentación y tutoriales de IBM Bob:
- Gestión de la ventana de contexto
- Context poisoning
- Bobcoins
- Todos los tutoriales de Bob
- Iniciar un proyecto
- Inspeccionar una base de código
- Generar diagramas de arquitectura
- Crear un plan e implementar funcionalidades complejas
- Escribir prompts efectivos
- Estandarizar el comportamiento de Bob
- Añadir un modo personalizado
- Generar código seguro con un flujo de trabajo actor-critic
- Auditar código
- Generar informes de auditoría
- Crear commits y pull requests