Esta es la primera publicación en el blog de Bob. Está escrita por el equipo que construye Bob, para los desarrolladores que lo usan. La usaremos para explicar decisiones de ingeniería, compartir lo que hemos aprendido enviando un socio de desarrollo de IA dentro de bases de código reales, y ocasionalmente argumentar una posición. No es documentación y no es marketing — si quieres cualquiera de los dos, te enlazaremos al lugar correcto.

Para nuestra primera publicación, en lugar de recorrer todo lo que hace Bob, queremos hacer tres cosas:

Mirar algunas de las capacidades centrales de Bob.
Compartir un conjunto de consejos prácticos para configurar un repositorio para que Bob haga su mejor trabajo.
Explicar cómo abordamos la seguridad en una herramienta que tiene este tipo de acceso a tu código.

1. En qué pasan realmente su tiempo los desarrolladores

Un asistente de IA moderno puede escribir una función a partir de una descripción. Eso ha sido cierto durante un tiempo, y ya no es la pregunta interesante. La pregunta interesante es qué sucede cuando el trabajo no es "producir código nuevo" sino "modificar un sistema que ya existe" — encontrar el lugar correcto para hacer un cambio, entender las convenciones en las que se ha establecido un equipo, mantener el comportamiento consistente en archivos que han estado creciendo durante años. Así es como se ve la mayor parte del desarrollo de software profesional. Bob está construido para este tipo de trabajo, y las decisiones de diseño que describimos en el resto de esta publicación siguen de ese enfoque.

1.1. Modos: decirle a Bob qué tipo de trabajo estás haciendo

Bob no es una sola interacción de "haz algo útil". El modo en el que inicias una sesión le dice a Bob qué tipo de trabajo estás a punto de hacer, qué herramientas puede alcanzar y qué tan proactivo debe ser.

Ask — solo lectura. Perfecto para la "fase de exploración". Bob explica arquitectura y lógica sin hacer cambios. Usa esto cuando te sumerjas en un sistema heredado o realices una verificación de cordura en una pieza de lógica que no escribiste.
Plan — Bob produce un plan para un cambio que estás a punto de hacer: archivos a tocar, casos extremos a considerar, orden sugerido de trabajo. La salida es un plan, no código.
Code — para hacer cambios realmente. Bob lee, escribe y prueba dentro de tu proyecto, siguiendo las convenciones y reglas que has establecido.
Advanced — extiende el modo Code a través del Model Context Protocol (MCP), dando a Bob acceso a las herramientas y servicios específicos de tu organización: APIs internas, bases de datos, herramientas propietarias.
Orchestrator — para trabajo de múltiples pasos que cruza modos. Bob cambia entre modos por sí mismo según lo que requiera el paso actual, y es la elección correcta para piezas más grandes de trabajo que mezclan exploración, planificación y ejecución.

Elegir el modo correcto al inicio de una sesión es una de las palancas más baratas disponibles para obtener mejor salida. Un buen hábito, particularmente en una base de código que no conoces bien o para un cambio con cualquier superficie real, es comenzar en Ask o Plan y solo cambiar a Code una vez que tengas una imagen clara del trabajo. Ir directamente a Code se siente más rápido en el momento, pero ahí es donde las suposiciones tienden a colarse como cambios reales y comienzan a acumularse como deuda técnica.

1.2. Bob tips: métricas de complejidad, en tiempo real

Todos hemos estado ahí: estás profundo en la "zona", anidando un último condicional para manejar un caso extremo, y de repente una sola función ha crecido a un laberinto de treinta líneas. En un flujo de trabajo típico, ese laberinto no se desenreda hasta que un compañero de equipo lo señala en un pull request horas después. Bob Tips cambia la narrativa al ofrecer una propuesta de refactorización mientras la lógica aún está fresca en tu mente. Mientras escribes, el análisis estático continuo monitorea silenciosamente tus archivos abiertos. Cuando una función cruza la línea hacia alta complejidad ciclomática o se vuelve difícil de mantener, Bob inmediatamente la marca con un subrayado morado. Un linter tradicional solo te dice que has hecho algo mal; Bob Tips proporciona la salida. El enfoque de la herramienta está completamente en entregar propuestas de refactorización accionables:

Inteligencia Contextual: Pasar el cursor sobre el subrayado morado no solo muestra una advertencia—ofrece una estrategia específica generada por IA para desenredar la lógica justo ahí. Ejecución Fluida: Hacer clic en Fix with Bob abre instantáneamente un chat dedicado. La IA ya tiene el contexto de la función y está lista para ejecutar la limpieza junto a ti.

Las métricas que se ejecutan en segundo plano son solo la fontanería. La parte valiosa es que una señal de calidad de código de larga data ahora impulsa una sugerencia de IA en el momento en que el desarrollador está en el archivo, en lugar de aparecer en una revisión de código tres días después.

1.3. Modo Review: revisión de código, con el sistema leyendo junto

La revisión de código ha hecho tanto por la calidad del software como cualquier práctica en las últimas dos décadas, y también es donde los equipos pierden impulso. Bob no reemplaza la revisión humana. Hace las partes que son mecánicas, para que puedan enfocarse en arquitectura de alto nivel e intención en lugar de cazar bugs "fáciles".

Las revisiones se ejecutan desde el Panel de Revisión en la barra lateral o a través de /review en el chat. Hay dos modos:

Comparación de rama. Este modo maneja el diff "clásico". Usa /review para auditar trabajo no confirmado contra tu head actual, o /review <branch> para apuntar a un remoto específico. Es un golpe preventivo contra los "nitpicks" que usualmente obstruyen los hilos de revisión.
Cobertura de issue. /review <issue-url> --issue-coverage valida que tus cambios locales realmente aborden lo que pide un issue de GitHub. Este es el modo que los desarrolladores nos dicen que no sabían que querían hasta que lo probaron. Los hallazgos aparecen en un panel dedicado, para que puedas revisarlos y decidir arreglarlos con Bob. Es una verificación de cordura que confirma que no solo escribiste buen código, sino el código correcto.

1.4. Literate coding: intención, escrita junto al código

Cuando estás profundo en una característica compleja, referenciar múltiples archivos en una ventana de chat es una tarea pesada. Te encuentras escribiendo "Mira la interfaz en types.ts y el servicio en api.ts, luego actualiza la lógica aquí..." Bob invierte esta dinámica. Al mover la interacción directamente al archivo fuente a través de Literate Coding, el editor mismo se convierte en la interfaz. Esto no se trata solo de evitar un panel lateral; se trata de proporcionar a la IA un mapa sofisticado de múltiples archivos de tu intención.

Expresa Intención Naturalmente: Cambia el modo con Cmd+M y escribe tu lógica en lenguaje simple o pseudocódigo. Tus instrucciones aparecen en el editor en azul, viviendo exactamente donde pertenece la implementación.
Más Allá de la Línea Individual: Mientras que el chat tradicional a menudo pierde el "hilo" de un proyecto complejo, el literate coding de Bob está evolucionando para cerrar la brecha entre archivos. Los desarrolladores ahora pueden proporcionar contexto a través de múltiples módulos, asegurando que un cambio en un modelo de datos se refleje con precisión en el controlador asociado.
Verificación Inmediata: Presiona Cmd+Enter y Bob genera la implementación in-place. Debido a que el resultado se muestra como un diff en línea, puedes auditar la lógica contra el código circundante antes de comprometerte con el cambio.

El beneficio es directo: el prompt vive donde vive el código, con el archivo circundante ya sirviendo como contexto. El alcance actual es de un solo archivo; el soporte multi-archivo está en el roadmap.

1.5. Bob en el terminal

Bob Shell trae las capacidades de Bob a la línea de comandos, y hay dos formas de usarlo que encontramos particularmente valiosas.

El Terminal como Espacio de Trabajo: Trabajar con un asistente de desarrollo de IA dentro del shell ha emergido como un factor de forma popular por derecho propio — se empareja naturalmente con cómo muchos desarrolladores ya manejan Git, builds y tests, y se ha convertido en parte del flujo de trabajo diario para muchos equipos. Es la forma más confiable de llevar IA a servidores remotos o entornos donde una integración IDE nativa no está disponible: Donde sea que tengas un terminal, puedes tener Bob.
De Determinista a Automatización Adaptativa: Bob Shell brilla en sesiones no interactivas como trabajos programados y scripts de despliegue en pipelines de CI/CD. Donde sea que un script hoy delegue a una herramienta determinista, puede delegar a Bob con contexto completo del repositorio circundante — y la automatización que sale del otro lado es más adaptativa que un pipeline fijo.

Publicaremos una publicación de seguimiento sobre lo que hemos aprendido ejecutando Bob de forma no interactiva en CI: los patrones que funcionan bien en la práctica, incluyendo resúmenes de PR, marcado de riesgos e integración en automatización existente.

2. Haz tu repositorio Bob-ready

Los repositorios donde Bob produce su mejor trabajo comparten algunos rasgos en común. Ninguno de ellos es específico de IA — son las mismas cosas que hacen que un repositorio sea agradable para trabajar para cualquier desarrollador — pero cada uno de ellos le da a Bob más con qué trabajar.

Tests rápidos y confiables. Si npm test (o tu equivalente) toma cinco minutos o falla intermitentemente, el bucle de iteración se ralentiza a un arrastre y la señal de retroalimentación se degrada. Los tests bajo un minuto son un multiplicador para cualquier desarrollador; para un asistente de IA trabajando en ciclos ajustados, son esenciales.

Comandos de build y test documentados. Un Makefile, una sección de scripts de nivel superior en package.json, o un bloque README — en algún lugar Bob puede encontrar "cómo ejecuto esto". Sin eso, Bob tiene que inferir, y la inferencia es donde entran los errores.

Estilo ejecutable. Linters y formateadores que se ejecutan al guardar o en CI. Bob recoge tus convenciones de estos. Las reglas explícitas y verificables por máquina superan las convenciones implícitas cada vez.

Un agents.md en la raíz del repositorio. Estructura del proyecto, archivos clave, estándares de codificación, qué hacer y qué no hacer. Este es el archivo de mayor apalancamiento que puedes agregar para asistencia de IA. La forma correcta de pensar en él es como un CONTRIBUTING.md escrito para un LLM en lugar de para un nuevo empleado.

Documentación de arquitectura en markdown, junto al código. Incluso documentos cortos ayudan. Un docs/architecture.md que describe módulos y sus límites permite a Bob responder "¿dónde va esto?" sin re-derivar el diseño de las importaciones.

Algunas cosas que hemos aprendido en el camino:

Los archivos de reglas grandes reducen la señal. Pasadas un par de cientos de líneas, el rendimiento del modelo se degrada. Divide las reglas por área — agents.md en la raíz del repositorio, readme.md con alcance por paquete — en lugar de concentrar todo en un archivo.
Compone tu ingeniería. Cuando termines una tarea, pídele a Bob que destile los aprendizajes relevantes de vuelta al archivo de reglas o en una habilidad. El repositorio se convierte en un entorno más productivo a medida que lo usas.
Itera, no hagas one-shot. Una conversación de múltiples turnos que aterriza el cambio correcto consistentemente supera un solo prompt largo que aterriza el ochenta por ciento de él.

3. Seguridad y control

Bob tiene varias capas de protección que trabajan juntas en lugar de que cualquier guardrail único haga todo el trabajo. La versión corta, adecuada para una primera publicación:

Aprueba manualmente cada acción, o auto-aprueba por clase de herramienta (solo lectura versus escritura) una vez que confíes en el flujo de trabajo.
.bobignore mantiene a Bob fuera de archivos que no debe leer — credenciales, artefactos generados, cualquier cosa sensible.
Las reglas personalizadas hacen cumplir estándares de codificación en Bob de la misma manera que los hacen cumplir en los desarrolladores.
Los checkpoints automáticos hacen que la recuperación de un cambio no deseado sea una acción de un clic.
¡Tus prompts no se usan como datos de entrenamiento!

La auto-aprobación, en particular, vale la pena ser deliberado al respecto. Es uno de los controles principales que tienes sobre cuánto puede hacer Bob entre checkpoints contigo, y ampliarlo es una ganancia de productividad que también te pide un poco más en decidir qué cae dentro de ese sobre y qué no. Un valor predeterminado sensato para la mayoría de los desarrolladores es auto-aprobar herramientas de solo lectura, dejar acciones de escritura en aprobación manual durante al menos las primeras semanas, y ser especialmente considerado con cualquier cosa que ejecute comandos de shell o alcance sistemas más allá de tu árbol de trabajo local. Los otros controles en la lista — .bobignore, reglas personalizadas, checkpoints — están diseñados para componerse con la auto-aprobación en lugar de sustituirla.

4. Comenzar

Instala IBM Bob desde nuestro sitio web, o instala Bob Shell a través de tu terminal de elección.
Revisa nuestra guía de mejores prácticas y consulta nuestras pautas de seguridad.
Comienza con una tarea real — Aprendes mejor cuando Bob está ayudando con problemas reales.

Enlaces