Coding Agent
Un agente aplicado a ingeniería de software
Un coding agent es un agente que persigue objetivos de ingeniería de software mediante ejecución delegada, utilizando el contexto y las capacidades de su entorno para investigar, proponer o realizar cambios y reunir evidencia sobre el resultado. Es una definición de trabajo del Atlas, no una certificación de autonomía ni un estándar que todos los productos deban implementar igual.
Especializa agents: conserva su relación entre observación, selección de acciones, feedback y detención. Agrega objetivos de desarrollo, repositorios y herramientas de ingeniería cuando la tarea los necesita. No redefine el loop ni exige que cada tarea termine escribiendo código. Investigar un fallo de CI y demostrar que su causa está fuera del cambio también puede ser trabajo pertinente.
La documentación oficial muestra vocabularios distintos. Codex Cloud describe tareas delegadas y revisión de resultados; Claude Code explica un agentic assistant que reúne contexto, actúa y verifica. Son ejemplos concretos, no la definición completa de la categoría ni una promesa de capacidad para cualquier repositorio.
De asistencia a ejecución delegada
coding-assistants centra la progresión conducida por la persona. Un coding agent puede recibir un resultado buscado y elegir varios pasos para alcanzarlo dentro de límites. La diferencia está en la delegación del curso de trabajo, no simplemente en tener chat, terminal o permisos de escritura. Una conversación puede alternar ambas formas.
La siguiente comparación expresa tendencias contextuales, no requisitos binarios ni una escala de madurez:
| Dimensión | En asistencia conducida por la persona | En ejecución delegada al coding agent |
|---|---|---|
| Iniciativa | La persona suele pedir y seleccionar el siguiente aporte. | El sistema elige parte de los siguientes pasos hacia el objetivo. |
| Trabajo entre pasos | Puede haber operaciones y herramientas acotadas. | Se delega una secuencia adaptable a los resultados. |
| Autoridad de acción | Depende del entorno y del encargo. | También depende de límites explícitos; no es irrestricta. |
| Duración | Puede ser breve o sostenida en una conversación. | Puede ser breve o extenderse durante una investigación. |
| Aprobación | Puede haber aceptación de propuestas y autorización de acciones. | Puede haber checkpoints y autorizaciones durante la ejecución. |
| Segundo plano | No define la categoría por sí mismo. | Es una posibilidad operativa, no un requisito. |
| Delegación a otros | Puede no estar disponible o no ser necesaria. | Tampoco es necesaria para que exista agencia. |
En Commerce, «explicá por qué falla esta validación» solicita ayuda de análisis. «Investigá el fallo, corregilo dentro de Payments UI, ejecutá los tests relevantes y reportá evidencia» delega una porción del trabajo. La segunda solicitud no autoriza automáticamente cambiar contratos backend, instalar paquetes o desplegar. La secuencia puede decidirla el agente; el alcance no queda a su libre elección.
Agentic Coding es la práctica
El Atlas usa Agentic Coding para la práctica de encargar a coding agents porciones significativas de trabajo de desarrollo con selección y ejecución de varios pasos. Coding Agent identifica al actor o sistema; Agentic Coding describe cómo se utiliza en el proceso. No son sinónimos y aquí no se propone una metodología formal universal bajo ese nombre.
Pedir a un modelo un snippet y pegarlo manualmente no constituye necesariamente Agentic Coding. La procedencia AI del código no demuestra delegación de investigación, elección de acciones o feedback. A la inversa, una investigación agentic puede concluir sin generar código si la evidencia muestra una configuración incorrecta o una expectativa inválida.
La práctica puede aplicarse a exploración, defectos, implementación, refactor, migración, tests, revisión, documentación o upgrades. Son ejemplos de tareas, no una nueva definición de esas disciplinas. refactor-vs-rewrite conserva las distinciones de evolución; introducir un agente cambia quién ejecuta parte del trabajo y cómo se revisa, sin convertir cualquier reescritura generada en refactor.
Delimitación de la delegación
Un encargo útil precisa resultado, alcance, restricciones y evidencia de aceptación. En Commerce: corregir el rechazo de un importe admitido, conservar el contrato de Payments, limitar los cambios al cliente y comprobar casos representativos. La persona puede aclarar reglas desconocidas y decidir si un hallazgo exige ampliar el alcance; el agente no debería inventar esa autoridad.
Las dimensiones de autonomía incluyen editar archivos, ejecutar comandos, instalar dependencias, acceder a la red, crear commits, abrir una PR, delegar o desplegar. Son facultades separables. Poder leer un repositorio no implica poder modificarlo; poder preparar un diff no concede aceptación ni release. Una tarea corta puede tener más impacto que otra larga con permisos limitados.
Las aprobaciones y restricciones no eliminan la delegación entre pasos. El agent mode de Gemini Code Assist documenta un ciclo de acciones y resultados con controles sobre planes y herramientas; la página lo identifica como Preview al consultar. Es evidencia de coexistencia entre iniciativa del sistema e intervención humana, no una política universal de permisos.
Al encontrar una causa fuera de Payments UI, el resultado correcto puede ser describirla y detener el cambio hasta una nueva decisión. Continuar por «completar» a cualquier precio degrada el contrato de trabajo. Un reporte parcial con evidencia preserva mejor la capacidad de decidir que una solución amplia que introduce compromisos no discutidos.
Repositorio y entorno de ejecución
El contexto habitual incluye archivos, instrucciones de build, tests, dependencias, búsqueda de código y estado de control de versiones. context-engineering-for-software-development aborda su selección y continuidad; persistent-instructions distingue la guía reutilizable de la solicitud actual. Su disponibilidad depende del entorno. Tener acceso al repositorio no basta para definir al coding agent: también una búsqueda convencional o un assistant pueden leerlo sin conducir una tarea delegada.
Puede operar en un checkout local, worktree, container, workspace cloud o VM remota. Ninguno es requisito universal. La documentación de entornos de Codex distingue local, worktree y cloud; esos modos muestran posibilidades concretas, sin convertir ubicación o aislamiento de archivos en una definición general de agent.
La información observada sigue necesitando interpretación. Un README puede estar desactualizado, un test puede depender de datos externos y un comando puede haber fallado durante preparación. En Commerce, ver un archivo llamado payment-validator no demuestra que sea el utilizado por checkout. El agente debe contrastar rutas de ejecución y conservar incertidumbre cuando no puede observarlas.
La herramienta disponible también delimita la evidencia posible. Un entorno sin browser puede ejecutar tests de lógica sin verificar interacción visual. Uno sin acceso al proveedor real puede trabajar con una simulación sin certificar integración. Esa diferencia debe quedar en el resultado; el nombre del producto no elimina las restricciones del workspace.
Herramientas, decisiones y progreso
Clases habituales de capacidades son filesystem, shell, búsqueda, build y tests, control de versiones, browser y APIs. Permiten observar o actuar sobre distintas fronteras. No es necesario contar con todas, ni encadenar muchas llamadas para demostrar trabajo agentic. La acción debe aportar información o progreso respecto del objetivo.
En checkout, una secuencia plausible es reproducir el rechazo, localizar la conversión, contrastar la regla aceptada, modificar el área acordada y ejecutar comprobaciones. El resultado puede exigir volver sobre la hipótesis. Esa es una ilustración de feedback; no una receta de investigación que todos los bugs deban seguir ni permiso para modificar hasta que desaparezca un síntoma.
Un plan puede ayudar cuando existen pasos dependientes o incertidumbre. No es parte obligatoria de la definición del agente y no demuestra que las decisiones sean correctas. Algunas tareas se resuelven reactivamente. Si se usa un plan, debe poder cambiar ante evidencia nueva sin convertir cada desviación en incumplimiento automático del objetivo.
Como navegación del Atlas, puede pensarse comprender → delimitar → planificar cuando aporte → ejecutar y observar → verificar → revisar → integrar. No es un lifecycle estándar, un orden obligatorio ni un comando de producto. Integración y release conservan la autoridad definida por el equipo; completar la investigación no autoriza avanzar por todas las etapas.
agentic-workflow-patterns permite examinar cómo combinar secuencia, rutas, paralelismo, planificación y feedback en ese trabajo. Sus estructuras son generales; utilizarlas no exige varios coding agents ni convierte cada etapa en un agente.
Evidencia de verificación y completion
Una afirmación de completion necesita comprobaciones apropiadas a la tarea: build, tests, tipos, análisis estático, revisión del diff, observación de comportamiento y revisión humana pueden aportar evidencias distintas. No es necesario ejecutarlas todas indiscriminadamente. La selección debe responder a qué cambió, qué podría fallar y qué condiciones de aceptación se acordaron.
En Commerce, importa reproducir el caso rechazado y comprobar que los importes inválidos siguen rechazándose. Hacer desaparecer el mensaje de error no basta. También interesa examinar que el diff conserve alcance y contrato. Un test escrito por el agente puede ayudar, pero debe contrastarse con la regla buscada y no solo con la implementación recién producida.
Tests verdes son evidencia valiosa, sin probar por sí solos comprensión del requisito, ausencia de toda regresión, seguridad correcta o respeto del alcance. testability conserva la pregunta por obtener y diagnosticar evidencia. Una prueba aislada puede no cubrir la integración del cliente con el backend o las condiciones de una sesión real.
Auto-verificación y revisión independiente tienen dependencias de fallo distintas. El mismo agente puede detectar errores propios y también repetir el supuesto que originó el defecto. Una revisión adicional aporta valor cuando contrasta requisitos y evidencias con suficiente independencia; no por limitarse a pedir una segunda opinión que repita la narración inicial.
Debe distinguirse qué se ejecutó, qué resultado produjo y qué quedó pendiente. «Tests no ejecutados por falta del servicio» no equivale a tests verdes. «Terminé» no sustituye evidencia. False completion se desarrolla en coding-agent-failure-modes-and-recovery: aquí basta exigir que el reporte no oculte verificaciones ausentes ni convierta confianza expresada en garantía.
Colaboración y responsabilidad
La persona puede formular el problema, orientar, aclarar, autorizar, revisar y aceptar o rechazar. El agente puede explorar, proponer, ejecutar acciones permitidas, reunir evidencia y comunicar incertidumbre. human-agent-collaboration desarrolla esa relación durante el trabajo. La distribución cambia por tarea y equipo; no se prescribe que el humano se convierta únicamente en reviewer ni que deba conducir cada microacción.
Delegar ejecución no transfiere automáticamente accountability organizacional, responsabilidad de producto, aprobación de seguridad o decisión de release. En Commerce, el responsable del flujo debe aceptar que la corrección expresa la regla comercial adecuada. El agente puede aportar una modificación y sus comprobaciones sin adquirir autoridad para decidir esa regla por el equipo.
design-process mantiene el razonamiento sobre decisiones arquitectónicas cuando el problema lo requiere. Un agente puede ayudar a explorar opciones, pero no garantiza identificar por sí solo los drivers correctos. Agentic Coding convive con requisitos, arquitectura, diseño, testing, delivery y operación; no reemplaza esas actividades por la sola ejecución de un encargo.
Composición determinista y probabilística
La interpretación y selección de acciones pueden depender del modelo, mientras compiladores, verificaciones programadas, permisos y gates de CI aplican reglas definidas. deterministic-and-probabilistic-development-workflows desarrolla esa composición. Un workflow puede invocar un agente y validar después su salida. No todo el proceso es probabilístico por incorporar AI; tampoco una regla determinista hace correcta la intención que se le entregó.
Los tests pueden tener condiciones variables y un gate puede estar mal configurado: llamar determinista al mecanismo no promete que todo su entorno sea reproducible. En checkout interesa examinar qué observación discrimina un defecto real de un fallo de preparación. La combinación útil conserva los límites de cada evidencia en vez de convertir un resultado de pipeline en aceptación universal.
Modelo, harness y producto
Un coding agent puede integrar capacidades por MCP, interactuar con un cliente/editor por ACP y solicitar trabajo a otro sistema por A2A. Son posibilidades de interoperabilidad, sin soporte universal ni requisito de adoptar los tres para realizar trabajo delegado.
El modelo aporta inferencia; agent-harness sostiene capacidades y control de ejecución alrededor de ella. El coding agent describe al sistema que persigue la tarea de software; agent-execution-environment ubica los recursos utilizados. Distintas instrucciones, contexto, herramientas, entorno y políticas pueden producir resultados diferentes con el mismo modelo.
Codex, Claude Code, GitHub Copilot o Gemini pueden combinar modelo, runtime, UI y servicios. No equivalen únicamente a un harness ni a una categoría conceptual invariable. GitHub documenta conversación y delegación dentro de una misma superficie; la modalidad concreta importa más que deducir autonomía del nombre comercial.
Long-Horizon Development Tasks
Las tareas de desarrollo de horizonte prolongado necesitan conservar progreso útil a través de pasos dependientes, interrupciones o cambios de sesión. El horizonte no se define mediante una cantidad universal de horas o tokens: importa la distancia entre el encargo y un resultado aceptable, junto con el estado e incertidumbre que deben sostenerse. Una migración gradual puede requerir varias revisiones aunque cada edición sea pequeña.
Conviene distinguir objetivo vigente, decisiones aceptadas, trabajo completado y evidencia pendiente. planning organiza un curso previsto y su revisión; development-context-and-execution-records conserva observaciones con procedencia. Ninguno garantiza que el repositorio siga igual al retomar. La continuación debe contrastar revisión, cambios locales y condiciones del entorno antes de tratar un resultado anterior como evidencia actual.
La compaction o un resumen pueden omitir restricciones o excepciones. context-engineering-for-software-development trata esa selección y sus límites; agent-checkpoints-and-recovery distingue estado recuperable de efectos externos. Reiniciar una sesión o restaurar archivos no deshace una publicación ni demuestra que un comando interrumpido no produjo efectos. La recuperación necesita una observación del estado pertinente antes de repetir acciones.
La delegación conserva alcance, permisos y condiciones de detención a lo largo del tiempo. Pueden ser necesarios puntos de revisión cuando aparece una decisión nueva, se agota un presupuesto o cambia una dependencia. No hace falta aprobar cada microacción ni ampliar autoridad por la duración del encargo. Si continúa otra persona o agente, deben quedar claros responsabilidad operativa y límites; compartir un registro no transfiere por sí solo la conducción.
En una migración de varios consumidores, completar el primer componente no significa completar el objetivo global. Un cierre parcial puede identificar qué versión se cambió, qué contrato se comprobó y qué consumidores siguen pendientes. Ese estado explícito permite retomar o detener sin inventar completion. Mantener este subtema junto a Coding Agent evita un canonical adicional mientras sus decisiones específicas reutilizan contexto, planificación, recuperación y verificación existentes.
Límites y continuidad
El encargo puede expresarse mediante task-prompts, apoyarse en persistent-instructions y agent-skills, y utilizar una especialización de agent-profiles. lifecycle-hooks puede integrar comportamiento por eventos; development-context-and-execution-records conserva evidencia del trabajo. Son responsabilidades distintas y capacidades posibles del sistema, sin exigir que todo coding agent implemente todas.
Puede haber objetivos mal entendidos, acciones equivocadas, verificaciones insuficientes, scope drift o cambios innecesarios. Código generado no constituye deuda técnica por su procedencia: importan el costo futuro y el contexto del compromiso, tratados en technical-debt. Tampoco muchas herramientas, varias sesiones o delegación adicional garantizan mejor ingeniería.
generated-code-verification examina evidencia de un cambio concreto; coding-agent-failure-modes-and-recovery agrupa desviaciones y tácticas de recuperación; agent-evaluation estudia comportamiento entre tareas y ejecuciones. AI Security mantiene su alcance futuro. Aquí no se diseñan frameworks, estrategias de coordinación o permisos recomendados para todos; se establece qué se delega y qué puede afirmarse responsablemente sobre el resultado.
ai-assisted-implementation-and-change-maintenance desarrolla cómo participa este actor en cambios concretos; ai-assisted-code-review examina otra actividad posible sobre el diff. Un coding-agent workflow organiza trabajo de desarrollo; un agentic workflow pattern organiza control o coordinación del sistema agente. Ninguno impone el otro ni requiere varios agentes.
ai-assisted-software-engineering conecta este concepto con los otros fundamentos y los workflows disponibles. Este canonical mantiene juntos actor y práctica para distinguirlos sin fragmentar prematuramente el conocimiento. No presenta Agentic Coding como toda generación AI ni una promesa de desarrollo sin intervención humana.
Fuentes
Fuentes primarias consultadas el 2026-10-25. La definición, la tabla de tendencias, la navegación y Commerce son síntesis editorial del Atlas, no estándares atribuidos a un proveedor.
- OpenAI: Codex Cloud y Codex environments, tareas, revisión y entornos.
- Anthropic: How Claude Code works, loop y capa de ejecución.
- Google: Gemini Code Assist agent mode, ciclo con herramientas e intervención humana; Preview en la consulta.
- GitHub: Copilot on GitHub.com, convivencia de chat y delegación; nombres y disponibilidad sujetos a la documentación vigente.