Coding agents en empresas: el reto es la infraestructura

De autocompletar a ejecutar tareas#

Durante años, la promesa de la IA en el desarrollo de software se resumió en una imagen: un asistente que sugiere la siguiente línea mientras escribes. Útil, pero limitado.

Esa imagen quedó atrás. Los coding agents actuales reciben una tarea, exploran el repositorio, modifican archivos, ejecutan comandos en una terminal, leen los errores, corrigen y vuelven a intentar hasta cerrar un flujo que antes tomaba horas de trabajo humano.

Esto ya se mide con benchmarks públicos que simulan ingeniería real. El Coding Agent Index de Artificial Analysis, por ejemplo, combina tareas de ingeniería de software sobre repositorios, uso agéntico de una terminal y preguntas técnicas que exigen entender el comportamiento de una base de código completa, y publica además el costo y el tiempo promedio por tarea de cada agente. La composición del índice se revisa con el tiempo, así que conviene consultar la versión vigente antes de citar cifras.

Lo que esos resultados muestran es que los agentes ya operan mucho más allá de generar fragmentos aislados. Por eso la pregunta útil para una empresa ya no es cuál es el mejor coding agent, sino si su infraestructura está lista para operar uno.

Documentación: Artificial Analysis · Coding Agent Index ↗

El agente no trabaja solo: trabaja en tu infraestructura#

Un coding agent no existe en el vacío. Tiene acceso a repositorios, ejecuta comandos en un sistema, lee y escribe archivos, consume tokens en cada interacción y deja un rastro de acciones que, sin controles, nadie puede auditar ni revertir.

OWASP clasifica este problema como agencia excesiva: dar a un sistema basado en LLM más funcionalidad, permisos o autonomía de los que la tarea requiere. Cuando el agente opera sin límites claros, los riesgos son concretos:

• Seguridad: puede leer variables de entorno, archivos de configuración o secretos si los permisos no están segmentados.
• Costos: una tarea mal definida o un loop sin tope consume tokens, y dinero, sin que nadie lo note. El costo por tarea varía mucho entre agentes y modelos, así que hay que medirlo en tu propio entorno.
• Errores en producción: si puede escribir directamente en ramas críticas sin revisión, un cambio incorrecto puede terminar desplegado.
• Exposición de datos: sin políticas de acceso, puede leer información sensible del repositorio o de los sistemas con los que interactúa.
• Pérdida de trazabilidad: sin registro de qué hizo, cuándo y por qué, la auditoría es imposible.

Ninguno de estos problemas se resuelve eligiendo un modelo más capaz. Se resuelven con infraestructura.

Documentación: OWASP GenAI · LLM06:2025 Excessive Agency ↗

Platform engineering: el habilitador que casi nadie menciona#

La conversación sobre coding agents suele quedarse en modelos, benchmarks y demos. Rara vez llega al lugar donde se decide si funcionan en una empresa: el equipo de platform engineering, que construye y mantiene los entornos internos donde el software se desarrolla, prueba y despliega.

Ese equipo ahora tiene que responder preguntas nuevas:

• ¿Dónde corre el agente: en infraestructura propia o en un servicio externo?
• ¿Qué permisos tiene sobre los repositorios? ¿Escribe directo o solo propone cambios vía pull request?
• ¿Cómo se integra con el pipeline de CI/CD existente?
• ¿Qué entornos aislados existen para que pruebe código sin tocar sistemas reales?
• ¿Cómo se controla su acceso a secretos, credenciales y configuración sensible?

La CNCF define una plataforma como un conjunto integrado de capacidades presentado según las necesidades de sus usuarios, los equipos internos, y DORA la describe como un producto interno con caminos pavimentados. Un agente conectado a esa plataforma hereda sus controles; un agente suelto sobre infraestructura improvisada es un riesgo operativo.

Documentación: CNCF TAG App Delivery · Platforms white paper ↗ · DORA · Platform engineering ↗

Aísla cada ejecución en un sandbox efímero#

Cada tarea del agente debería correr en un contenedor o microVM que se crea para esa tarea y se destruye al terminar. Así un comando destructivo no afecta sistemas compartidos y cada ejecución parte de un entorno limpio y reproducible.

docker run --rm \
  --user 10001:10001 \
  --read-only --tmpfs /tmp:rw,size=512m \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --pids-limit 256 --memory 4g --cpus 2 \
  --network agent-egress \
  -v "$PWD/worktree:/workspace" -w /workspace \
  agent-runner:1.4.2 run-task --task-file .task.md

Los contenedores comparten el kernel del host. Si el agente ejecutará código no confiable, considera una capa adicional como gVisor o microVMs, y en Kubernetes aplica el perfil restricted de Pod Security Standards al namespace donde corren los agentes.

Documentación: Docker Docs · Docker Engine security ↗ · Docker Docs · docker container run ↗ · gVisor · Documentation ↗ · Kubernetes · Pod Security Standards ↗

DevSecOps: la seguridad no puede llegar después#

El modelo de construir primero y asegurar después no funciona cuando un agente puede ejecutar comandos, modificar código y navegar repositorios. La seguridad tiene que estar desde el primer día:

• Identidad y permisos granulares: mínimo privilegio, con credenciales de corta duración limitadas a la tarea.
• Revisión obligatoria: ramas protegidas que exijan pull request y aprobación humana antes de fusionar cualquier cambio del agente.
• Escaneo de secretos: todo código generado o modificado pasa por detección de credenciales, tokens y claves antes de llegar al repositorio.
• Auditoría de acciones: cada archivo tocado, comando ejecutado y API consultada queda registrado.

En GitHub Actions, un flujo razonable deja que el agente trabaje en su propia rama, con un token de permisos mínimos y un tope de tiempo, y termina en un pull request que la protección de rama obliga a revisar.

name: agent-task
on:
  workflow_dispatch:
    inputs:
      task:
        description: "Tarea para el agente"
        required: true

# Mínimo privilegio: el token solo puede empujar la rama del agente y abrir un PR.
permissions:
  contents: write
  pull-requests: write

jobs:
  agent:
    runs-on: ubuntu-latest
    timeout-minutes: 30          # corta loops y gasto descontrolado
    steps:
      - uses: actions/checkout@v4
      - name: Ejecutar el agente en una rama propia
        env:
          TASK: ${{ inputs.task }}   # nunca interpoles inputs directo en run:
          GH_TOKEN: ${{ github.token }}
        run: |
          git switch -c "agent/${GITHUB_RUN_ID}"
          ./scripts/run-agent.sh "$TASK"      # ejecuta en contenedor efímero
          git push origin "agent/${GITHUB_RUN_ID}"
          gh pr create --fill --base main --head "agent/${GITHUB_RUN_ID}"

DevSecOps no es opcional con agentes autónomos: es la condición mínima para operar con seguridad.

Documentación: GitHub Docs · About protected branches ↗ · GitHub Docs · Automatic token authentication (GITHUB_TOKEN) ↗ · GitHub Docs · Security hardening for GitHub Actions ↗ · GitHub Docs · About secret scanning ↗

Observabilidad: si no puedes verlo, no puedes controlarlo#

Los benchmarks miden lo mismo que una empresa necesita medir en producción: tiempo por tarea, consumo de tokens, costo por operación y tasa de éxito. En un entorno real hace falta más:

• Qué hizo el agente: el log completo de acciones, no solo el resultado final.
• Cuánto costó: el costo real de cada sesión, con tokens de entrada, salida y caché.
• Qué cambió: un diff claro de cada modificación, ligado a la tarea que la motivó.
• Qué falló y por qué: en qué punto se detuvo y qué error encontró.
• Cómo revertir: un proceso de rollback simple, rápido y completo.

OpenTelemetry tiene convenciones semánticas para IA generativa que estandarizan spans y métricas de llamadas a modelos, como el uso de tokens por operación. Instrumentar el agente con ellas permite llevar esos datos al mismo backend donde ya observas el resto de tu plataforma, en lugar de depender del panel de un proveedor.

Sin esta visibilidad, el agente es una caja negra dentro de tu infraestructura, y una caja negra que puede modificar código no es un activo: es un riesgo.

Documentación: OpenTelemetry · Semantic conventions for generative AI ↗ · OpenTelemetry · GenAI metrics ↗

Los benchmarks miden capacidad; la infraestructura decide la viabilidad#

Es valioso saber qué agentes resuelven mejor tareas complejas de repositorio, cuáles son más eficientes en la terminal y cuáles tienen mejor relación costo-rendimiento. Pero ningún benchmark te dice si tu organización está lista para operar uno en producción.

Que un agente resuelva una fracción de las tareas difíciles de un benchmark no significa que vaya a reproducir ese resultado sobre tu repositorio. Tu código, tus dependencias, tus convenciones y tus controles son otros. Esa pregunta solo la responde una evaluación honesta de tu infraestructura, tus procesos de seguridad, tu observabilidad y tu madurez operativa.

El NIST AI Risk Management Framework ofrece un marco para ese ejercicio: gobernar, mapear, medir y gestionar los riesgos de un sistema de IA a lo largo de su ciclo de vida.

Documentación: Artificial Analysis · Coding Agent Index ↗ · NIST · AI Risk Management Framework ↗

Checklist antes de dar acceso a un agente#

La ventaja competitiva es la plataforma#

Las empresas que más valor obtengan de los coding agents no serán necesariamente las que usen el modelo más avanzado, sino las que hayan construido la plataforma correcta para operarlos de forma segura, medible y escalable: entornos aislados, permisos claros, revisión humana en el pipeline, observabilidad de costos y acciones, rollback rápido y equipos de plataforma y seguridad alineados.

Esa es la diferencia entre usar IA de forma oportunista, con resultados inconsistentes y riesgos no controlados, y usarla como una capacidad organizacional real. El modelo es el motor; la infraestructura es el chasis, los frenos y el volante.