Programar con IA: cómo trabajar con agentes y qué delegar

Para quien dirige un equipo de ingeniería, el punto de partida más práctico es una tarea acotada en una rama aislada, con criterios de aceptación explícitos, comprobaciones automatizadas y una persona encargada de la revisión. Amplía la autonomía cuando ese proceso produzca cambios que puedas aceptar con confianza.

El funcionamiento de las herramientas descritas aquí se verificó en la documentación publicada por sus fabricantes el 24 de octubre de 2026. Las reglas para delegar y el ejemplo de exportación de facturas son un análisis editorial, no los resultados de una prueba de producto.

¿Qué significa programar con IA mediante agentes?

La programación agéntica consiste en encargar a un sistema de IA una secuencia de tareas de desarrollo en la que el resultado de cada paso orienta el siguiente. El sistema examina el código del proyecto, planifica un cambio, edita archivos, ejecuta comandos y pruebas, interpreta los resultados y ajusta su próxima acción. Una ejecución puede terminar porque la tarea está completa, porque alcanza un límite de permisos o porque hace falta una decisión.

Anthropic describe este ciclo como recopilar contexto, actuar y verificar. El paso decisivo es incorporar el resultado de la herramienta a la siguiente decisión: una prueba fallida aporta información para corregir el código. Sugerir un bloque de código, por sí solo, no crea ese ciclo. El ciclo de trabajo de Claude Code.

Piensa en un contratista que va a renovar una habitación. El encargo define el resultado, las llaves determinan el acceso y la inspección decide si el trabajo se acepta. Entregarle más llaves no garantiza que la obra esté bien hecha. Los agentes de programación necesitan esa misma separación entre instrucciones, acceso e inspección.

Un agente también necesita un harness: el software que rodea al modelo, le proporciona herramientas y gestiona el contexto de trabajo. El modelo propone acciones; el harness ejecuta las llamadas a herramientas que están permitidas y devuelve sus resultados. Cambiar de modelo no modifica automáticamente las reglas de acceso del entorno.

¿En qué se diferencia un agente del autocompletado y del chat?

La diferencia está en quién hace avanzar el trabajo de un paso al siguiente. El autocompletado sugiere texto mientras editas. Una conversación de chat convencional puede explicar código o proponer un parche, pero tú te encargas de copiarlo, ejecutarlo y validarlo. Un agente con acceso al repositorio y a la ejecución de comandos puede realizar esos pasos e inspeccionar lo que ocurrió.

La interfaz no define al agente: puede funcionar tanto en una ventana de chat como en una terminal. Lo que importa es qué herramientas tiene disponibles, cómo utiliza los resultados para decidir su siguiente acción y qué autoridad se ha concedido a la sesión.

Programación agéntica y vibe coding: ¿son lo mismo?

La programación agéntica describe cómo funciona la herramienta. Vibe coding suele describir una forma de trabajar en la que se guía la generación de software principalmente mediante prompts y la observación de su comportamiento, a veces sin apenas examinar la implementación. En la práctica, ambos conceptos se cruzan, pero responden a preguntas distintas.

Puedes trabajar con un agente, revisar cada cambio y mantener pruebas rigurosas. También puedes aceptar código generado casi sin examinarlo. En un prototipo desechable, esa segunda opción puede ser una concesión deliberada. Si hay datos de clientes o pagos de por medio, entender la implementación sigue siendo parte de asumir la responsabilidad por ella. La guía de herramientas de vibe coding repasa el panorama más amplio de plataformas de creación y herramientas de programación.

¿Qué pueden hacer los agentes de programación?

Las principales herramientas ofrecen un ciclo de acciones similar desde distintos entornos de trabajo. Sus funciones documentadas permiten saber qué puedes delegar; no indican cuánto trabajo sin supervisión puede tolerar tu repositorio.

Claude Code

Claude Code, el agente de programación de Anthropic, puede buscar en un proyecto, leer y editar archivos, ejecutar comandos y realizar pruebas. Su documentación describe un ciclo que cambia de rumbo según lo que aprende de cada resultado de las herramientas. Por eso, corregir un error concreto es una tarea adecuada: investigar el fallo, modificar el código correspondiente y verificar el comportamiento. Documentación de Claude Code.

El límite práctico es el contexto que falta o se pierde. Anthropic documenta una ventana de contexto finita y procesos de compactación durante las sesiones largas. Deja las restricciones duraderas en las instrucciones del proyecto y mantén cada cambio bien acotado: una conversación larga no sustituye a un criterio de aceptación. Nuestra guía de buenas prácticas de Claude Code desarrolla ese flujo de trabajo.

OpenAI Codex

OpenAI Codex, el agente de programación de OpenAI, ofrece una interfaz de línea de comandos (CLI) que puede inspeccionar un repositorio, planificar un cambio, editar archivos y ejecutar comandos de desarrollo locales. También dispone de un flujo específico para revisar cambios sin confirmar, un commit o una comparación con una rama base. Documentación de Codex CLI.

El límite práctico es el entorno de ejecución. Una comprobación que depende de un servicio no disponible o de un acceso a la red bloqueado no puede aportar la evidencia prevista. Márcala como no verificada y repítela en el entorno adecuado. La comparativa de Codex y Claude Code ayuda a elegir el producto; la configuración de permisos merece una decisión aparte.

Cursor Agent

Cursor Agent, el agente de programación integrado en el editor Cursor, puede buscar en el código del proyecto, editar archivos y ejecutar comandos de terminal. Encaja en un flujo interactivo en el que orientas el cambio mientras inspeccionas el trabajo. Son acciones documentadas, no una promesa de que la funcionalidad resultante será correcta. Descripción de Cursor Agent.

Conviene conocer su límite inmediato: las ediciones habituales del espacio de trabajo se guardan en disco sin aprobación, mientras que los cambios en archivos de configuración reciben protección adicional. Cursor advierte que una aplicación con recarga automática puede ejecutar el código editado antes de que lo revises. Utiliza un entorno de desarrollo con credenciales y datos adecuados para ese comportamiento. Seguridad de Cursor Agent.

El agente de programación de GitHub Copilot

El agente de programación de GitHub Copilot, denominado Copilot cloud agent en la documentación actual, puede investigar un repositorio, planificar cambios, editar archivos y ejecutar pruebas y linters en un entorno temporal en la nube. Puede preparar ramas, commits y pull requests. Es una función distinta de recibir sugerencias dentro de un IDE o pedirle a Copilot que revise un pull request existente. Copilot en GitHub.com.

El límite práctico está en la entrega. GitHub advierte que los cambios generados pueden ser incorrectos o inseguros y requieren revisión y pruebas. Que una sesión haya terminado significa que hay trabajo que evaluar, no que se hayan cumplido los criterios de aceptación. Recomendaciones de uso responsable de GitHub.

Para consultar los planes, visita nuestras páginas de precios de Claude Code, precios de Codex, precios de Cursor y precios de GitHub Copilot.

El trabajo con agentes empieza por una especificación verificable

Una especificación útil le dice al agente qué debe mantenerse y qué debe cambiar. «Añade una exportación CSV» deja abiertas decisiones fundamentales. El agente puede crear una descarga que funcione y, al mismo tiempo, aplicar reglas de acceso equivocadas.

Imagina un producto de facturación que utilizan distintas organizaciones cliente. Quieres que un administrador de cuenta pueda exportar facturas. Un encargo útil especificaría lo siguiente:

• Resultado: un administrador autorizado puede descargar las facturas visibles con los filtros actuales.
• Regla de acceso: una organización nunca debe recibir facturas de otra, tampoco mediante una solicitud manipulada.
• Comportamiento que se conserva: los permisos y filtros existentes de las facturas siguen determinando el acceso y los resultados.
• Alcance: reutilizar las convenciones de autorización y exportación existentes; evitar refactorizaciones o dependencias ajenas a la tarea.
• Evidencia: mostrar casos permitidos y denegados, un intento de acceso a otra organización, un resultado vacío y las comprobaciones existentes que correspondan.
• Condición para detenerse: pedir una decisión si la política de acceso es ambigua o si la solución exige cambiar el comportamiento de autorización compartido.

Este encargo deja abiertas las decisiones de implementación, pero fija las condiciones que el producto debe cumplir. Si el trabajo revela una regla que falta, resuélvela y actualiza la especificación. No permitas que una decisión accidental de implementación se convierta, sin más, en la política del producto. Nuestra guía de desarrollo basado en especificaciones explica cómo mantener esa relación.

La documentación de buenas prácticas de Anthropic recomienda proporcionar al agente una forma de verificar su trabajo. En sus recomendaciones basadas en la práctica, Armin Ronacher destaca la importancia de herramientas rápidas y comprensibles y de registros útiles. La lección operativa es hacer visibles los fallos: un error de autorización claro ayuda al agente a corregir su trabajo; un comando que se queda bloqueado apenas le indica cómo continuar.

Los permisos y el aislamiento controlan límites distintos

Los permisos determinan qué acciones se permiten; el aislamiento limita su alcance; las reglas de las ramas y de revisión determinan si el cambio se acepta. Configura todos estos controles. Un prompt que diga «no toques producción» no sustituye a retirar el acceso a producción.

Una política de aprobación determina qué acciones necesitan autorización. Un sandbox impone límites de ejecución sobre recursos como los archivos que se pueden escribir o el acceso saliente a la red. Ninguno de los dos evalúa si la exportación de facturas cumple las reglas de tu negocio.

Revisa la configuración efectiva de cada herramienta

Para Claude Code, Anthropic documenta el aislamiento del sistema de archivos y de la red en los comandos ejecutados dentro del sandbox, incluidos sus subprocesos. También documenta un mecanismo para reintentar la ejecución fuera del sandbox. Antes de dar por hecho que ese límite se aplica siempre, revisa esa vía de salida, las exclusiones de comandos y qué ocurre cuando el sandbox no puede iniciarse. Restringir la escritura no implica automáticamente impedir la lectura de archivos sensibles. Aislamiento de Claude Code.

En Codex CLI, workspace-write con aprobaciones on-request permite trabajar dentro del espacio de trabajo, mientras que el acceso de los comandos a la red está desactivado por defecto, salvo que se habilite. La política de aprobación y el modo de sandbox son ajustes independientes: desactivar las solicitudes de aprobación no elimina por sí mismo el sandbox. La política de red de los comandos tampoco controla, por sí sola, la búsqueda web alojada, las aplicaciones o las conexiones MCP, que conectan al agente con herramientas y servicios externos. Revisa esas vías de acceso por separado. Aprobaciones y seguridad de Codex.

En Cursor Agent, los comandos de terminal requieren aprobación por defecto, mientras que sus modos de ejecución configurables, Run Modes, se describen como medidas de protección que intentan prevenir riesgos, no como una barrera de seguridad estricta. La diferencia importa si vas a permitir que se ejecuten comandos sin supervisión. Ten en cuenta tanto la ejecución en la terminal como la advertencia anterior sobre la recarga automática. Seguridad de Cursor Agent.

Para GitHub Copilot cloud agent, GitHub documenta permisos de ramas restringidos que impiden enviar cambios directamente a la rama predeterminada. También documenta un cortafuegos activado por defecto y la aprobación de un usuario con acceso de escritura antes de ejecutar flujos de Actions activados por los pull requests del agente. El agente no recibe los secretos generales de Actions del repositorio ni de la organización; sí recibe los que se añaden específicamente al entorno copilot. Revisa qué guardas allí. Medidas de protección documentadas por GitHub.

Ajusta los límites a la tarea

Para la exportación de facturas, el agente necesita código fuente, dependencias de desarrollo y registros de facturas sintéticos. No debería necesitar facturas reales de clientes, credenciales de la base de datos de producción ni autoridad para desplegar. Concede el acceso mínimo a recursos que le permita reproducir y verificar el comportamiento.

Trata el texto del repositorio, las páginas recuperadas y el contenido de las incidencias como entradas potencialmente no confiables. La inyección de prompts ocurre cuando un contenido malicioso intenta redirigir las acciones del agente. Una instrucción oculta en un documento no debe adquirir la autoridad de tu encargo. Las recomendaciones de seguridad de los fabricantes identifican este riesgo; limitar los recursos accesibles reduce sus posibles consecuencias. Modelo de seguridad de Cursor.

Cómo revisar: examina los cambios y la evidencia

Revisa el comportamiento modificado y las comprobaciones que pretenden demostrar que es correcto. Leer el resumen del agente sirve para orientarse, pero ese resumen no es el trabajo que estás aprobando.

Empieza por los criterios de aceptación. En la exportación de facturas, sigue el recorrido de la solicitud: cómo se determina la organización, cómo se comprueba la autorización y cómo aplica ese mismo límite la consulta de exportación. Después, examina las pruebas. Una prueba que solo utiliza registros de una organización no puede demostrar que existe separación entre organizaciones.

A continuación, busca cambios que hayan debilitado la evidencia: aserciones eliminadas, pruebas que ahora se omiten, simulaciones más amplias, snapshots modificados o alteraciones en la configuración de CI. Una batería de pruebas puede pasar porque la implementación mejoró o porque las comprobaciones se volvieron menos exigentes. El diff permite distinguir qué ocurrió.

Desde una copia de trabajo del repositorio con cambios sin confirmar, estos comandos de Git permiten una inspección básica:

git status --short
git diff --stat
git diff --check
git diff
git diff --cached

git status también muestra archivos sin seguimiento, cuyo contenido debe inspeccionarse por separado. Estos comandos no ejecutan las pruebas de la aplicación. Si el trabajo del agente ya está registrado en commits, inspecciona el diff completo del pull request entre la rama base y la versión propuesta, y ejecuta las comprobaciones documentadas del repositorio en un entorno limpio.

Una entrega útil incluye los comandos exactos que se ejecutaron, sus resultados, la salida pertinente de éxito o fallo y cualquier comprobación que no haya podido realizarse. Decir «las pruebas pasan» sin identificar cuáles obliga a quien revisa a adivinar la cobertura. Si no se pudo preparar el entorno, falta evidencia; eso no demuestra que el código funcione.

En 10 lecciones sobre programación agéntica, Drew Breunig defiende las pruebas del comportamiento del producto, la intención documentada y las especificaciones que evolucionan con la implementación. Aplicado a este caso, la comprobación que debe perdurar es que un cliente no pueda exportar las facturas de otro. La función auxiliar concreta que haga cumplir esa regla puede cambiar.

Una revisión automatizada puede aportar más hallazgos, pero la persona que acepta el cambio debe entender su funcionamiento crítico. GitHub advierte expresamente que la revisión con IA puede pasar por alto problemas y producir falsos positivos. Mantén a una persona responsable de revisar el comportamiento sensible para la seguridad y la facilidad de mantenimiento. Limitaciones de la revisión según GitHub.

¿Quién puede delegar más y quién debería esperar?

Delega más cuando la tarea tenga una condición de éxito clara, los errores puedan contenerse y la revisión siga siendo manejable. Lo que sigue es una propuesta de política de ingeniería, no una garantía de capacidades de ningún proveedor.

Quienes lideran equipos de ingeniería con una CI confiable pueden empezar ya. Comienza con cambios que sigan patrones existentes. Asigna una persona responsable a cada pull request generado por un agente y reduce el tamaño de las tareas si las revisiones se vuelven difíciles de comprender. Que las comprobaciones pasen solo sirve si cubren el comportamiento que importa.

Quienes están creando el prototipo de una empresa pueden delegar gran parte de la implementación dentro de un entorno desechable. Usa datos sintéticos y asume que el código exploratorio puede reemplazarse. Antes de añadir cuentas de clientes o movimientos de dinero, recurre a alguien capaz de evaluar las reglas de acceso, el manejo de fallos y las consecuencias operativas.

Quienes mantienen un sistema heredado que conocen mal deberían mejorar primero la evidencia. Un agente puede ayudar a investigar el comportamiento y proponer pruebas, pero empezar con refactorizaciones sin supervisión es poco recomendable cuando nadie sabe distinguir el comportamiento previsto del accidental. Establece el punto de partida antes de ampliar la autonomía.

Quienes ya trabajan a gusto con el autocompletado no necesitan cambiar todas sus tareas. Una edición pequeña y evidente puede hacerse más rápido directamente. Delegar compensa el trabajo adicional cuando hay una secuencia relevante de investigación, modificación y verificación que encargar.

Dónde falla y qué expectativas son exageradas

El ciclo falla cuando la información que recibe no permite distinguir una solución correcta de una que solo parece serlo. Una comprobación aprobada puede confirmar el formato del código sin decir nada sobre el aislamiento entre clientes, es decir, la separación de sus datos. Una prueba con simulaciones puede pasar y no detectar problemas en la integración que utilizan los clientes. Un resumen convincente puede omitir un comando fallido.

El contexto impone otro límite. El agente puede ver la función pertinente y desconocer por qué existe una restricción poco habitual. Documenta las decisiones importantes cerca del trabajo, identifica la especificación que debe regirlo y pide que se hagan explícitas las incertidumbres. La documentación de Anthropic describe cómo se gestiona el contexto finito en sesiones largas; no des por hecho que una instrucción del inicio de la conversación conservará la misma relevancia durante todo un cambio extenso. Cómo funciona Claude Code.

Añadir agentes también añade trabajo de coordinación. Si varias sesiones modifican los mismos archivos, una misma interfaz o el estado de la base de datos, un resultado local correcto puede entrar en conflicto con otro cambio. Utiliza copias de trabajo separadas y asigna explícitamente la responsabilidad de integración. Empieza por paralelizar investigaciones independientes antes de hacerlo con implementaciones muy interdependientes.

El problema más amplio es aceptar una complejidad que nadie tenía intención de mantener. Una abstracción, dependencia o tarea en segundo plano nueva pasa a ser tu responsabilidad operativa, aunque generarla haya sido fácil. Evalúa si el cambio resuelve la tarea con una cantidad razonable de mecanismos nuevos.

Lo que no demuestran los benchmarks de programación agéntica

Un benchmark de programación no demuestra, por sí solo, cuánto mejorará la capacidad de entrega de tu equipo. Para aplicar un resultado publicado, tendrías que entender las tareas, el contexto del repositorio, las herramientas, la política de reintentos y la definición de éxito. El porcentaje de productividad que anuncia un proveedor no es una previsión para tu código.

En tu propia prueba piloto, registra el tiempo transcurrido hasta que se acepta un cambio, el esfuerzo de revisión, el trabajo que hubo que rehacer, los defectos detectados después de integrarlo y las ejecuciones bloqueadas. Compara tipos de tareas similares y conserva los fallos en el registro. Esta es una propuesta de medición; aquí no se afirma ningún porcentaje de mejora.

Amplía la delegación cuando resulte más fácil entregar trabajo aceptado sin un aumento inaceptable de la carga de revisión o de los defectos. Si producir parches se vuelve más rápido pero entenderlos se vuelve más difícil, reduce el alcance y mejora la evidencia.

Preguntas frecuentes

Por dónde empezar el lunes

Elige una incidencia pequeña de la lista de pendientes cuyo comportamiento se pueda reproducir y asigna a quien la revisará antes de iniciar el agente. Escribe los criterios de aceptación, proporciona un entorno de trabajo aislado y excluye las credenciales de producción. Pide un parche acompañado de la evidencia necesaria para evaluarlo.

Después de la revisión, registra qué resolvió el agente, dónde tuvo que intervenir una persona y qué comprobaciones faltaron. Usa esa evidencia para definir el alcance de la siguiente tarea. Amplía la autonomía cuando el proceso de verificación lo justifique.

Para recibir notas prácticas sobre cómo crear con IA, suscríbete al boletín.