La programación agéntica cambia la velocidad, no la responsabilidad
Un LLM puede proponer código. Un agente puede además leer un repositorio, ejecutar herramientas, modificar archivos y verificar resultados. Eso comprime ciclos de trabajo, pero también aumenta la cantidad de decisiones y cambios que deben controlarse.
Un ciclo agéntico con límites verificables
- Intención humanaobjetivo · restricciones · riesgo
- Especificacióncontrato · aceptación · fuera de alcance
- Agentes aisladoscontexto mínimo · permisos acotados
- Evidenciatests · build · análisis · salidas reales
- Revisióncontexto independiente · fail-closed
- EntregaCI · despliegue · verificación
La especificación se vuelve ejecutable
Dar una instrucción vaga a un agente solo produce cambios vagamente correctos a mayor velocidad. Antes de delegar, definimos comportamiento observable, restricciones, evidencia esperada y acciones que requieren autorización humana.
- Criterios de aceptación que una prueba o inspección pueda comprobar.
- Límites sobre archivos, sistemas, datos y efectos externos.
- Fuentes de verdad explícitas; una respuesta plausible no cuenta como evidencia.
- Parada obligatoria cuando falta contexto o aparece una decisión de negocio.
TDD reduce el espacio de error
El ciclo RED–GREEN–REFACTOR le da al agente un objetivo pequeño y falsable. La prueba debe fallar antes del cambio por la razón esperada; luego la implementación mínima la hace pasar y el suite completo detecta regresiones.
- Una conducta por ciclo, no una pila de tests imaginados.
- Pruebas sobre HTML, APIs o artefactos reales cuando sea posible.
- Mutaciones adversariales para comprobar que el contrato no acepta falsos positivos.
- Refactor solo con el comportamiento en verde.
Aislamiento y permisos por capacidad
Un agente no necesita acceso universal para ser útil. Separamos ramas, contextos y herramientas; damos solo los permisos necesarios para la tarea y exigimos aprobación antes de publicar, borrar, pagar o modificar sistemas externos.
- Ramas o worktrees aislados para trabajo concurrente.
- Secretos fuera del prompt, código y logs.
- Acciones destructivas y publicación detrás de una decisión humana.
- Resultados de subagentes tratados como reportes hasta verificarlos.
La revisión debe venir de otro contexto
El agente que implementó comparte los mismos supuestos que su solución. Una revisión independiente recibe el contrato y el diff, busca errores de lógica, seguridad y procedencia, y no aprueba porque el autor parezca seguro.
- Revisor sin la narrativa del implementador.
- Hallazgos bloqueantes separados de sugerencias.
- Contenido revisado para no inventar clientes, métricas o capacidades.
- Correcciones verificadas nuevamente desde cero.
Los gates fallan de forma segura
Si una prueba no corre, la revisión no puede interpretarse o producción no se puede comprobar, el estado es no verificado. La automatización acelera el camino feliz sin convertir la incertidumbre en una aprobación automática.
- Build, tipos, seguridad, enlaces, schema y accesibilidad como gates reproducibles.
- CI verde antes de integrar y desplegar.
- Verificación HTTP, DOM y visual después de publicar.
- Rollback o detención cuando la evidencia contradice el cambio.