Un equipo adopta un agente de programación y abre más pull requests. El cuello de botella cambia de sitio: requisitos incompletos, diffs enormes, revisión lenta, pruebas rotas e incidentes cuyo contexto hay que reconstruir. Aumenta el código, pero no necesariamente el valor entregado.
El 6 de noviembre de 2026, GitHub presentó la ingeniería agéntica como un flujo que conecta Planificar, Construir, Verificar y Observar. Citó el fuerte crecimiento de commits y un estudio externo en el que los pull requests tardaban mucho más en revisión en equipos con alta adopción de IA. La respuesta es rediseñar el sistema de entrega, no renunciar a la velocidad.
Qué es la ingeniería agéntica
Es una disciplina para delegar partes del trabajo de ingeniería a agentes manteniendo objetivos, restricciones y responsabilidad bajo dirección humana. El agente ayuda a reunir requisitos, preparar el plan, implementar, verificar, analizar telemetría y convertir lo aprendido en producción en nuevo trabajo.
No es sinónimo de vibe coding. Su unidad de trabajo es un ciclo repetible dentro de la arquitectura, los estándares, la seguridad y las métricas del equipo.
Las cuatro etapas
1. Planificar con contexto verificable
Antes de tocar código, el agente reúne requisitos, decisiones, contratos, componentes y criterios de aceptación. Produce un plan revisable con alcance, alternativas, riesgos, dependencias, pruebas y reversión. Las decisiones relevantes se guardan en issues, ADR o especificaciones, no solo en un chat.
2. Construir en tareas aisladas
Divide el plan en cambios pequeños. Cada sesión usa una copia aislada del repositorio y conoce comandos de prueba, convenciones, límites de dependencias y archivos restringidos. El trabajo paralelo necesita un grafo: la documentación puede avanzar mientras se implementa; una migración dependiente debe esperar.
3. Verificar antes de pedir atención
El agente ejecuta lint, pruebas, seguridad y contratos antes de solicitar revisión. Otro modelo puede criticar el diff, pero no sustituye controles deterministas. El revisor recibe una modificación pequeña, explicada y acompañada por evidencias.
El pull request debe indicar motivo, pruebas, riesgos y reversión. El código generado recibe al menos el mismo rigor que el escrito manualmente.
4. Observar en producción
Tras el despliegue, conecta logs, trazas, métricas e indicadores de negocio con el cambio. El agente correlaciona error, versión y usuarios afectados, pero el rollback obedece a la política. Una conclusión útil vuelve como issue, prueba o instrucción versionada.
Arquitectura mínima
- contexto: repositorio, issues, documentación, diseño, observabilidad y políticas;
- orquestador: divide trabajo y resuelve dependencias;
- entornos aislados: separan ramas, archivos, ejecución y credenciales;
- controles: pruebas, contratos, seguridad, accesibilidad, coste y aprobación;
- traza: registra instrucciones, modelos, herramientas, commits y decisiones;
- feedback: convierte revisión y producción en mejoras.
Ejemplo: límite de crédito variable
Producto solicita un límite por perfil. El agente localiza reglas, integraciones del ERP, decisiones de riesgo y recorridos de la app. Propone separar cálculo y concesión y conservar la compatibilidad de API.
Una tarea modifica el motor, otra el panel y otra la migración. Trabajan en ramas aisladas. El pipeline valida contrato, redondeo, permisos, accesibilidad y carga. La persona revisora se concentra en la regla financiera y las excepciones.
En producción, la observabilidad compara aprobación, latencia e impago con el baseline. Ante una anomalía, el agente reúne evidencias y abre la investigación con los commits relacionados.
Métricas de resultado
Las líneas generadas miden actividad. El 5 y 6 de noviembre, GitHub amplió sus informes con uso de agentes, comentarios de revisión atendidos y pull requests fusionados sin una solicitud humana posterior de cambios. Combina estos datos con:
- lead time desde requisito hasta producción;
- tiempo en revisión y tamaño del diff;
- retrabajo, rollback y defectos escapados;
- tareas concluidas sin reapertura;
- coste de modelo y ejecución por cambio aceptado;
- tiempo de recuperación e impacto de negocio.
Errores frecuentes
- automatizar la implementación con una planificación desestructurada;
- crear pull requests enormes porque generar código es barato;
- compartir directorio o credenciales entre sesiones;
- tratar el chat como fuente de verdad;
- medir adopción en lugar de valor;
- ignorar revisión, observabilidad y producción;
- conceder autonomía sin límites de alcance y coste.
Cómo empezar
- Selecciona un cambio frecuente y dibuja su flujo completo.
- Documenta fuentes, aceptación y validaciones.
- Delega primero la planificación asistida y tareas pequeñas.
- Aísla la ejecución y establece controles obligatorios.
- Normaliza las evidencias del pull request.
- Vincula el cambio con la telemetría.
- Compara tiempo, calidad y coste con el baseline.
Velocidad con ingeniería
El beneficio aparece cuando el agente reduce esperas y reconstrucción de contexto en todo el ciclo, no solo cuando escribe más código. Planes explícitos, cambios pequeños, controles y feedback mantienen el producto evolutivo.
ProativaIA desarrolla software a medida, aplicaciones integradas y pipelines con agentes, pruebas y observabilidad. Podemos adaptar la ingeniería agéntica a tu arquitectura, equipo y riesgo.