# El panorama de la programación con agentes

Stack agéntico · Builders · Grok Build · módulo 00
Lectura: ~13 min

> Empiezas donde empieza todo agente de terminal: un bucle que lee tus archivos, planifica, actúa y comprueba el resultado. Este módulo presenta los cinco arneses que enseña el curso y para qué sirve cada uno; después te entrega una tabla de evaluación de cinco líneas para elegir la opción que instalarás y la segunda que mantendrás preparada para el módulo de orquestación.

> Diagrama: Todo el módulo en una imagen: cinco opciones de arnés alimentan un bucle de cuatro pasos, las cuatro cosas que cada arnés añade alrededor del bucle y la tabla de evaluación que te llevas.

## lo que vas a poder hacer

entregable :: lo que produces

❯ Una tabla de evaluación de una página. Te evalúas en cinco líneas y la hoja te dirige al arnés que instalarás en el módulo 1, a una segunda opción que mantendrás preparada para el módulo de orquestación y al comando que ejecutarás para comprobar el trabajo del agente en vez de confiar en su resumen.

Puedes instalar estas cinco herramientas en una tarde y seguir sin saber si alguna hizo bien el trabajo. Elegir la adecuada no lo resuelve. Lo que sí lo resuelve: entender el bucle común a las cinco, saber qué paso declara el éxito sin haberlo demostrado y decidir de antemano qué aceptarías como prueba.

Por eso este módulo no instala nada. El bucle, las cinco opciones y una forma de elegir entre ellas seguirán teniendo sentido dentro de seis meses, cuando todas las listas de funciones hayan cambiado.

Un agente de programación de terminal lee tus archivos, propone cambios, ejecuta comandos y comprueba su trabajo, todo dentro de la ventana de texto en la que ya ejecutas `git`, donde escribes comandos en vez de hacer clic. Escribes una petición en lenguaje natural. Trabaja en tu repositorio real, la carpeta con tu proyecto y su historial, y te muestra lo que cambió.

Si quitas las marcas, todos ejecutan el mismo bucle:

> leer los archivos pertinentes hacer un plan editar código o ejecutar un comando observar qué ocurrió repetir hasta terminar la tarea o necesitarte

Ese bucle es todo el trabajo. Lo que cambia entre los cinco es el modelo que lleva dentro, cómo lo delimitas y qué añades a su alrededor. Aprende el bucle una vez y todas estas herramientas serán variaciones de algo que ya entiendes.

Los términos que verás a lo largo del curso, cada uno con su propio módulo más adelante. Un **arnés (harness)** es uno de los cinco agentes de terminal: el bucle más sus controles. Una **sesión** es una conversación en curso con un agente dentro de un repositorio. Un **modelo** es el modelo de lenguaje que piensa dentro del bucle. El **entorno aislado** es el muro que decide qué puede tocar el agente. **MCP** es el estándar compartido para conectar herramientas externas a un agente, de modo que una herramienta que conectas una vez funciona en más de un arnés.

## La idea que deja de encajar

La mayoría llega pensando que un agente de programación escribe código por ti. Escribes la petición, recibes el código, revisas el código.

Eso funciona para una edición pequeña, por eso dura lo suficiente para hacer daño. Centra toda tu atención en el resultado y ninguna en el bucle; cuando una ejecución sale mal, buscas un modelo o un prompt mejor, aunque lo que falló fue un paso intermedio que nadie comprobó.

Esta es la idea que sí se sostiene:

> Un agente de programación es un bucle cuyos límites controlas tú, y el código es lo que sale cuando esos límites son correctos.

> Diagrama: Dos modelos mentales en paralelo: entra prompt y sale código como una línea recta, frente al bucle de cuatro pasos con tus dos puntos de control marcados.

Todo lo que sigue parte de esa frase. Los permisos del [módulo 2](/stack/builders/grok-build/module-02.md), el archivo de instrucciones del [módulo 3](/stack/builders/grok-build/module-03.md), los hooks del [módulo 6] (próximamente) que se activan solos, las compuertas de comprobación del [módulo 14] (próximamente) que deciden si una ejecución sin supervisión puede darse por terminada. Nada de eso pertenece a una sola herramienta. Son los puntos en los que puedes decir que no de antemano, y los cinco arneses los presentan de formas ligeramente distintas.

## Los cuatro pasos y cuál miente

Cada paso falla a su manera y los fallos no se parecen. Por eso los nombras por separado antes de encontrarte con ellos.

**Leer.** El agente incorpora las partes de tu repositorio que cree relacionadas con la petición. Falla al leer demasiado poco, normalmente porque la petición era vaga o el proyecto no tiene un archivo de instrucciones que indique dónde está cada cosa. Lo notas en una respuesta segura sobre el archivo equivocado.

**Planificar.** Decide qué va a hacer. Tu modo de permisos puede detener este paso, por eso existen los modos de solo planificación y el [módulo 2](/stack/builders/grok-build/module-02.md) les dedica tiempo. Un plan detenido es el lugar más barato para detectar un malentendido, porque aún no se ha escrito nada.

**Actuar.** Edita un archivo o ejecuta un comando. Es el único paso que puede causar daño y la razón de ser del entorno aislado. Todo lo que leas después sobre modos de permisos, listas de permitidos y flags de escritura directa trata de este paso.

**Observar.** Lee el resultado y decide si funcionó. Este es el paso que miente.

Tres formas, las tres en tu primer mes, cada una con una solución distinta.

Primero, leer en vez de ejecutar. Los agentes tienden mucho a leer un archivo, un README o una página de documentación y tratarlo como verificación. Dirige uno a un repositorio desconocido y resumirá con seguridad lo que este afirma sobre sí mismo, sin haberlo clonado ni ejecutado un comando en él. En programación, es una corrección declarada a partir del diff que acaba de escribir en vez de una prueba que acaba de pasar.

Segundo, detenerse antes de tiempo. Los agentes hacen lo mínimo que parece una respuesta: una consulta floja en lugar de la búsqueda posterior que habría encontrado lo real, y confianza fácil en el primer resultado. En un repositorio se ve como una tarea marcada como completada con solo dos de los cuatro archivos modificados.

Tercero, la que atrapa a la gente cuidadosa. Una prueba que parece correcta a primera vista puede no respaldar la afirmación que la acompaña. Cuanto más avanza una ejecución y más llamadas a herramientas acumula, más débil es el respaldo factual de lo que el agente señala como prueba, aunque todas las referencias sigan activas y relacionadas con el tema. Es un mecanismo, no una tasa: cuanto más tiempo pasa una ejecución sin comprobarse, más débil es el vínculo entre lo que el agente dice haber verificado y lo que verificó realmente.

Las tres tienen la misma solución, y no es un modelo mejor.

Decide antes de ejecutar un comando cuyo resultado aceptarás como prueba. Un conjunto de pruebas. Una compilación. Un linter. Un script que arranque el sistema y haga una petición. Después, lee tú ese resultado en vez del resumen del agente. Los módulos posteriores lo llaman tu comando de comprobación, y elegirlo es la quinta línea de tu tabla de evaluación.

> Diagrama: El bucle de cuatro pasos con las tres formas en que miente el paso de observar como ramas, las tres convergen en una solución: el comando de prueba que elegiste antes de ejecutar.

## Qué añade un arnés alrededor del bucle

Si los cinco ejecutan el mismo bucle, elegir entre ellos es elegir entre las cuatro cosas que lo rodean. Este es también el mapa del resto del curso.

**La relación con el modelo.** Si el arnés incluye su propio modelo mediante suscripción o espera que aportes una clave de API, una contraseña larga que factura por uso. Esto determina la forma de tu gasto mensual y si puedes cambiar el cerebro cuando aparezca uno mejor.

**Los muros.** Cómo te permite el arnés indicar qué puede tocar el agente y cuándo debe detenerse a preguntar. Los cinco lo hacen y ninguno igual. [Módulo 2](/stack/builders/grok-build/module-02.md).

**La capa de instrucciones.** Un archivo de tu repositorio que explica al agente cómo funciona el proyecto, para que no te repitas en cada sesión. El estándar es [AGENTS.md](#agents), leído entre proveedores, y es la principal razón por la que el conocimiento se transfiere entre estas herramientas. [Módulo 3](/stack/builders/grok-build/module-03.md).

**Las posibilidades de ampliación.** Comandos personalizados, hooks que se activan con eventos, herramientas externas conectadas mediante MCP y marketplaces con extensiones de otros. Aquí sí hay diferencias reales de profundidad entre los cinco, y aquí se justifica el trabajo de seguridad del [módulo 2](/stack/builders/grok-build/module-02.md), porque una extensión es código al que has invitado a entrar.

Solo la primera es cuestión de gustos. Las otras tres seguirás configurándolas dentro de un año.

## Por qué cinco arneses en vez de uno

La mayoría de los cursos enseña una herramienta y finge que las demás no existen. Eso envejece mal, porque este campo cambia en semanas y la herramienta que hoy lidera puede no hacerlo cuando termines el curso. Por eso este curso enseña la parte duradera, el bucle y sus límites, y luego la muestra en cinco arneses reales. Eliges uno y trabajas en él; como leen un archivo de instrucciones compartido y hablan protocolos comunes de herramientas, el trabajo de una opción no queda atrapado ahí cuando cambias.

Las cinco opciones:

**Claude Code, el arnés consolidado para operadores.** La primera opción de la mayoría de los profesionales en activo, con el conjunto más profundo de controles: modos, hooks, skills y plugins. Aislamiento nativo, flujo de aprobación nativo y trabajo prolongado nativo. La opción predeterminada si quieres la mayor trayectoria detrás.

**Codex, el arnés del ecosistema OpenAI.** Un agente en CLI, extensiones de IDE, aplicación de escritorio, ejecutor en la nube y modo dentro de ChatGPT, todos compartiendo un archivo de configuración. Tu opción si ya trabajas en ese ecosistema o quieres un ejecutor asíncrono en la nube que de verdad te deje cerrar el portátil.

**opencode, el arnés independiente del proveedor.** El abierto. No incluye un modelo propio: aportas tu clave y lo diriges al proveedor que quieras, desde grandes laboratorios hasta un modelo en tu propia máquina. Sus muros son reglas de permisos, no un entorno aislado del proveedor, y su trabajo prolongado se construye combinando piezas en vez de venir listo. Tu opción si importan la independencia del proveedor o los modelos locales.

**Grok Build, el aspirante de cambio rápido.** Una interfaz que evoluciona rápido, con modo de planificación, subagentes, skills, hooks, MCP y ejecuciones sin interfaz. Publica casi a diario: vuelve a comprobar los comandos disponibles antes de fijar un flujo de trabajo sobre ellos.

**Cursor CLI, el compañero del editor y la nube.** `cursor-agent` lleva el agente de Cursor a la terminal, con sesiones interactivas, automatización en modo de impresión, plugins, subagentes y trabajadores en la nube en su propia rama. Es una interfaz separada del editor: cada comparación entre editor y CLI es algo que verificar, no una suposición heredada. Su aprobación combina revisión interactiva y un flag de forzado, y ese flag da escritura directa, no un perfil de entorno aislado.

Esa última línea es el estándar que se exige este curso. Una afirmación comercial no es una prueba y, si un arnés tiene una carencia, se enseña, porque saber dónde no puede protegerte vale más que una función adicional.

> Diagrama: Cinco arneses en filas: identidad, relación con el modelo, muros y carencia real de cada uno, marcados como completo, parcial o ausente en vez de usar marcas de verificación.

## Cómo elegir de verdad

Ignora las listas de funciones. Tres preguntas deciden tu opción y ninguna trata de funciones.

**¿En qué consiste la mayor parte de tu trabajo?** Programar cada día en repositorios propios apunta a Claude Code. Trabajar en el ecosistema OpenAI o lanzar tareas y alejarte apunta a Codex. Evitar depender de un proveedor o ejecutar modelos en tu hardware apunta a opencode. Experimentos paralelos rápidos en los que aceptas cambios apuntan a Grok Build. Trabajo de terminal que aprovecha reglas de Cursor, contexto del editor o un trabajador en la nube apunta a Cursor CLI.

**¿Cuál es tu relación con el modelo?** Si estás conforme con pagar una suscripción a un proveedor y usar su modelo, encajan directamente la opción consolidada y Codex. Si quieres tu propia clave de API y libertad para cambiar de modelo cuando cambie la clasificación, opencode se diseñó para eso y los demás no.

**¿Cuál es tu tolerancia al riesgo?** Si quieres la herramienta más probada con las protecciones más profundas, elige la opción consolidada. Aceptar una interfaz de cambio rápido o un modo de escritura directa es válido, pero anota el límite exacto de aprobación antes de la primera ejecución, no después.

No hay una respuesta equivocada, solo un motivo equivocado. Elige un arnés porque es tendencia esta semana y volverás a aprenderlo todo el mes que viene. Elígelo porque encaja con tu trabajo, tu facturación y tu tolerancia a las sorpresas y el conocimiento se acumula.

## Dónde encaja tu opción

Qué hace el [módulo 1](/stack/builders/grok-build/module-01.md) con la opción que te convence.

Un script de instalación y ya estás dentro. Cambia rápido: el [módulo 1](/stack/builders/grok-build/module-01.md) señala qué volver a comprobar antes de confiar en un detalle y fecha las partes volátiles en vez de fingir que son estables.

## La compuerta que nunca eliminas con automatización

Una regla antes de elegir, porque determina cómo lees todos los módulos restantes.

Donde se han integrado agentes en trabajo real de producción aparece la misma división: el agente lee, extrae, redacta y da formato siguiendo instrucciones escritas de antemano; una persona controla la selección, el juicio y el momento de entregar, gastar o borrar. Muchos agentes sí actúan solos en ámbitos estrechos autorizados expresamente por sus responsables, así que es una pauta firme, no una ley; cuanto más difícil es revertir una acción, más se sostiene.

Equivocarse con un agente que lee tu repositorio sale barato. Equivocarse con uno que edita una rama que puedes desechar sale barato. Con uno que hace push, borra, despliega o gasta, no; ahí un punto de control deja de ser una traba y se convierte en lo único entre una mala ejecución y una mala semana.

Lo que suele entenderse mal es dónde vive ese punto de control. Una regla que pides al modelo que siga es una preferencia. Una regla que impone el arnés, mediante permisos o un hook que rechaza ejecutar el comando, es un límite. La misma frase, una garantía totalmente distinta, y solo una resiste un mal día del modelo.

> Diagrama: Las mismas cuatro reglas escritas dos veces: indicadas al modelo, donde son una preferencia, e impuestas por el arnés, donde son un límite que sobrevive a una mala ejecución.

## Construye tu tabla de evaluación

Evalúate con honestidad en cinco líneas. Este es el entregable.

1.  **Trabajo principal.** Programación habitual, ecosistema y asincronía, independencia del proveedor, experimentos rápidos o relevo entre editor y nube.
2.  **Relación con el modelo.** Una suscripción con la que estás conforme o libertad de aportar tu propia clave.
3.  **Tolerancia al riesgo.** Lo más probado con las protecciones más profundas o velocidad y precio en una interfaz cambiante.
4.  **Segunda opción.** La alternativa con puntuación más cercana. El módulo de orquestación usa un arnés como gestor y otro como trabajador con una compuerta de revisión entre ellos; conocer ya una segunda opción convierte aquello en un ejercicio de dos horas en vez de dos días.
5.  **Comando de comprobación.** El comando de tu repositorio cuyo resultado aceptarías como prueba de que el trabajo del agente es real. Pruebas, compilación, linter o un script que arranque el sistema. Si hoy no puedes nombrar uno, esa es tu primera tarea en el [módulo 1](/stack/builders/grok-build/module-01.md), antes de que el agente escriba nada.

Anota esas cinco respuestas donde vuelvas a verlas. El ganador es el arnés que instalarás en el [módulo 1](/stack/builders/grok-build/module-01.md), el segundo es el que mantendrás preparado y el comando de comprobación es la línea que usarás cada día.

> Diagrama: La ficha completada como ejemplo resuelto: cinco líneas con una respuesta plausible cada una, que conducen al arnés que instalas ahora, la segunda opción que mantienes lista y el comando que ejecutas cada día.

## Qué cambia y qué no

Algunas interfaces cambian tan rápido que un comando impreso puede quedar obsoleto antes de llegar al [módulo 4](/stack/builders/grok-build/module-04.md). El curso lo resuelve fechando las partes volátiles y separándolas de las duraderas.

Todo lo anterior es duradero y ninguna versión lo reescribe. Lo volátil: comandos de instalación de una línea, nombres de flags, formas de iniciar sesión, funciones en beta y ubicación de ajustes en los archivos de configuración. Si algo falla, conserva el patrón de tarea, el límite de aprobación y el comando de comprobación, y busca la sintaxis actual del flag.

## Qué haces después

Pasa al [módulo 1](/stack/builders/grok-build/module-01.md). Instalarás el arnés elegido por tu tabla, te autenticarás por la vía con la que quieres facturar y ejecutarás tu primera tarea real.

Trae un proyecto real. No hacemos ejemplos de hola mundo. No puedes juzgar si la respuesta de un agente es correcta en un repositorio que no conoces, y juzgar la respuesta es toda la habilidad.

## recursos y referencias

// documentación oficial, herramientas e hilos que merece la pena guardar

[Página de la especificación AGENTS.mdEl estándar de archivos de instrucciones entre proveedores que leen todos los arneses de este curso. Escribirás uno en el módulo 3.https://agents.md](https://agents.md)[openai/codex (código fuente de CLI)El arnés Codex. Dale una estrella y sigue sus versiones.https://github.com/openai/codex](https://github.com/openai/codex)[anomalyco/opencode (código fuente de CLI)El arnés independiente del proveedor. Publica cada pocos días.https://github.com/anomalyco/opencode](https://github.com/anomalyco/opencode)