Los coding agents hacen barato producir un cambio plausible. El nuevo trabajo de la plataforma es hacer obligatorias las evidencias: qué especificación autorizó el trabajo, qué checks lo probaron, qué identidad lo creó y qué ruta controlada lo entregó.
El workflow de coding agent de GitHub ya refleja la nueva forma del desarrollo: un agente trabaja en su propio entorno, crea un pull request y solicita revisión. GitHub también documenta que los workflows de pull requests creados por agentes necesitan aprobación antes de ejecutarse. Esa frontera importa. El agente produce cambios rápido; automatizaciones confiables y revisores responsables deciden si merecen privilegios de ejecución y entrega.
Una plataforma AI-native, entonces, no es una IDE con chatbot. Es un control plane de entrega de software que asume que algunos autores son autónomos, rápidos, no humanos y ocasionalmente equivocados de formas convincentes. Convierte intención y evidencias en reglas de promoción aplicadas por máquina.
Los tickets escritos por humanos suelen dejar supuestos en la cabeza del autor. Los coding agents necesitan un contrato más ejecutable: comportamiento esperado, comportamiento prohibido, interfaces, ejemplos, restricciones no funcionales, migraciones y pruebas que deben existir. El pipeline debe conectar cada diff generado con la spec y rechazar cambios que no demuestren cobertura de los criterios de aceptación.
El Secure Software Development Framework de NIST enfatiza preparar la organización, proteger el software, producir software bien protegido y responder a vulnerabilidades. Los coding agents no sustituyen esas prácticas; aumentan el volumen al que la plataforma debe aplicarlas.
Un check verde es demasiado grueso cuando los cambios llegan más rápido de lo que humanos pueden leerlos. La plataforma debe preservar por qué existe cada check, qué requisito cubre, qué artefacto evaluó y si el entorno era confiable. Protected branches y rulesets exigen revisiones y status checks. Dependency review expone cambios riesgosos de paquetes. Code scanning encuentra vulnerabilidades. Artifact attestations establecen procedencia del build. SLSA define garantías progresivamente más fuertes para la supply chain.
El output útil no es “pipeline pasó”. Es un grafo de evidencias que conecta tarea, identidad, commits, dependencias, pruebas, findings, excepciones, reviews, artefactos, attestations, deploy y señales de runtime.
| Etapa | Responsabilidad del coding agent | Gate de plataforma | Responsabilidad humana |
|---|---|---|---|
| Intención | Reformular requisitos e identificar ambigüedades. | Exigir spec, owner, scope, clase de riesgo y contrato de evidencias. | Resolver tradeoffs y aprobar intención de negocio. |
| Implementación | Cambiar código, pruebas, docs, migraciones y manifests. | Entorno aislado, least privilege, identidad, presupuesto y captura del diff. | Revisar arquitectura y decisiones importantes. |
| Verificación | Ejecutar checks, diagnosticar fallas y proponer correcciones. | Runners confiables independientes ejecutan checks obligatorios. | Aprobar excepciones; nunca aceptar solo auto-attestation del agente. |
| Seguridad | Explicar findings y corregir dentro del scope. | Code scanning, dependency review, secret scanning, política y risk score. | Aceptar o rechazar riesgo residual. |
| Supply chain | Declarar archivos generados, tools y materiales usados. | Build confiable produce artefacto firmado y attestation de procedencia. | Definir nivel exigido de procedencia y política de excepciones. |
| Entrega | Proponer plan de rollout y rollback. | Protecciones de entorno, aprobaciones, canary y rollback automático. | Autorizar promoción de alto impacto y responder por el resultado. |
Los agentes son excelentes generando pruebas ausentes, explicando fallas, proponiendo diffs menores, actualizando documentación y reparando violaciones de política. Deben recibir feedback estructurado del pipeline e iterar dentro de la misma tarea limitada. No deben poder debilitar checks obligatorios, aprobar su propio workflow, descartar findings, crear credenciales de producción o hacer merge evitando protecciones.
Usa credenciales OIDC cortas para workflows confiables en lugar de secrets cloud duraderos. Separa workspaces de agentes de entornos de deploy. Exige builders confiables para crear attestations. Trata cambios en workflows, permisos, rulesets o configuración de seguridad como una clase de riesgo mayor.
Construiría un portal de plataforma donde cada tarea de coding agent nace de una spec versionada y produce un dossier de entrega. Incluiría identidad del agente, permisos de tarea, plan, diff, manifest de archivos generados, mapa de pruebas, scans, excepciones, reviews, procedencia, rollout y resultado de runtime.
El visual central sería una timeline de evidencias para cada cambio. Un revisor podría inspeccionar una prueba fallida, rastrearla hasta el requisito que protege, ver cómo respondió el agente y verificar que el artefacto final vino del commit aprobado y workflow confiable.
Cuando la generación de código se vuelve abundante, la confianza debe venir de restricciones y evidencias, no del esfuerzo de escritura. La plataforma AI-native no pregunta si humano o agente escribió el código. Pregunta si el cambio satisfizo el contrato explícito, pasó verificación independiente, preservó procedencia y entró en producción por una ruta controlada.
Artículo sobre plataformas de desarrollo AI-native y CI/CD después de coding agents, cubriendo specs ejecutables, verificación independiente, gates de seguridad, procedencia, artifact attestations, reviews y deploy controlado.