Habr: los agentes de IA transforman el delivery y obligan a los equipos a rediseñar todo el ciclo de desarrollo

Habr ha publicado un análisis sobre por qué, con la llegada de los agentes de IA, el cuello de botella de los equipos de ingeniería ya no es la velocidad de escritura de código, sino el coste de verificar y transmitir el contexto. El autor cita el informe DORA 2025, según el cual el 90% de los profesionales tecnológicos usa IA en el trabajo y más del 80% la asocia a un aumento de la productividad. Sin embargo, cuanto más rápido se generan código, ADR y documentación, más crece la carga de revisión y de control de la estabilidad.

Por eso, el texto propone ver la IA no como una herramienta más dentro del proceso de siempre, sino como un motivo para rediseñar todo el ciclo de entrega de cambios. El artículo distingue tres modos de trabajo. El primero es el ai-assisted development: el modelo ayuda a recopilar requisitos, redactar borradores de ADR, casos de prueba o documentación más rápido, pero el proceso sigue siendo el mismo.

El segundo es el agentic delivery: el agente ya lee el repositorio, prepara cambios, ejecuta verificaciones y abre PR, mientras que la persona interviene en las escaladas. Como ejemplo de este cambio, el autor menciona el paso de GitHub Copilot coding agent a general availability. El tercer modo es el ai-native sdlc: aquí el LLM deja de ser un «chat al margen» y se convierte en la interfaz del circuito de trabajo con el que el equipo lleva una tarea desde la idea hasta el lanzamiento.

La tesis central del texto es que la economía de esta transición no gira en torno al código, sino a la comunicación. En un delivery real no solo cuestan los cambios en sí, sino también el traspaso de trabajo entre análisis, desarrollo, testing y operaciones, la reconstrucción del conocimiento y las aclaraciones constantes. Cuando la generación se acelera, el cuello de botella se traslada a las aprobaciones, la validación y el control de riesgos.

Por eso los equipos necesitan un contexto externo y legible por máquinas, accesible tanto para personas como para agentes: objetivos, restricciones, riesgos, criterios de finalización, ADR, contratos de API, reglas de seguridad, comandos de verificación local y notas sobre el rollout. Si el conocimiento crítico sigue viviendo en chats, videollamadas y en la memoria de desarrolladores concretos, el agente simplemente trabaja con una imagen incompleta. De ahí surge también el nuevo foco en el harness, el entorno de ejecución de los agentes.

Ya no se trata de un gran prompt de sistema, sino de un conjunto de reglas y restricciones integradas en el proceso. El repositorio debe incluir instrucciones explícitas para los agentes, comandos de compilación y pruebas, criterios de finalización y restricciones de arquitectura y seguridad. Se propone formalizar los escenarios repetitivos como skills, playbooks y repo rules, en lugar de explicarlos de nuevo en cada chat.

Además, las restricciones no deben ser solo textuales: el sistema debe poder detener acciones de riesgo, impedir el merge sin confirmaciones y derivar los pasos dudosos a una persona. El autor analiza aparte la capa de control. A la revisión no debe llegar un simple diff, sino un evidence pack: qué ha cambiado exactamente, qué escenarios están cubiertos, qué verificaciones se han ejecutado, qué riesgos quedan y cómo revertir el cambio.

Por encima de esto hacen falta quality gates: límites al tamaño de los cambios, comandos validate obligatorios, comprobación de las restricciones de arquitectura y actualización sincronizada de la documentación. Otra capa son los evals para tareas repetitivas. Permiten fijar de forma explícita el comportamiento esperado del agente y comprobar si el workflow se mantiene estable tras cada cambio, o si el proceso degenera en una versión cara del vibe coding con un flujo de PR ruidosos.

Según el autor, después del lanzamiento hay que observar no solo el producto, sino también el propio proceso de entrega. El equipo debe analizar dónde le faltó contexto al agente, qué reglas resultaron débiles, qué tareas eran demasiado grandes para delegarlas con seguridad y dónde la revisión se ahogó en ruido. Esto afecta directamente a la organización: aumenta el valor de los ingenieros de perfil amplio, se refuerza el papel del platform engineering y de las herramientas internas, y el onboarding de los juniors deja de ser un efecto secundario natural del trabajo.

Si no se hace, el equipo corre el riesgo de formar no ingenieros, sino operadores de autocompletado. La conclusión práctica del texto de Habr es que los agentes de IA por sí solos no hacen que el delivery sea maduro. Solo amplifican los puntos fuertes y débiles del sistema de ingeniería existente.

Por tanto, la siguiente etapa para los equipos no consiste simplemente en generar código y documentos más rápido, sino en construir un proceso en el que el contexto esté externalizado, el entorno de ejecución esté acotado, las verificaciones estén formalizadas y cada fallo mejore no solo el producto, sino también la propia forma de entregarlo.