Habr: Los agentes de IA cambian el delivery, y los equipos deben reconstruir todo el ciclo de desarrollo

En Habr, se publicó un análisis sobre por qué con la llegada de los agentes de IA, los equipos de ingeniería se encuentran con un cuello de botella no en la velocidad de escritura de código, sino en el costo de revisión y transferencia de contexto. El autor hace referencia a DORA 2025, donde el 90% de los especialistas en tecnología utilizan IA en el trabajo, y más del 80% la vinculan con el crecimiento de la productividad. Pero cuanto más rápido se crean código, ADR y documentación, mayor se hace la carga en revisión y control de estabilidad.

Por lo tanto, se propone considerar la IA no como otra herramienta dentro del proceso antiguo, sino como una razón para rearmar todo el ciclo de entrega de cambios. El artículo distingue tres modos de operación. El primero es desarrollo asistido por IA, donde el modelo ayuda a recopilar requisitos más rápidamente, escribir borradores de ADR, casos de prueba o documentación, pero el proceso en sí permanece igual.

El segundo es entrega agéntica, donde el agente ya lee el repositorio, prepara cambios, ejecuta verificaciones y abre PRs, mientras que los humanos se involucran en escaladas. El autor menciona el lanzamiento de GitHub Copilot coding agent a disponibilidad general como ejemplo de este cambio. El tercer modo es SDLC nativo de IA: aquí el LLM deja de ser un "chat al lado" y se convierte en una interfaz al ciclo de trabajo, a través del cual el equipo mueve una tarea desde la idea hasta el lanzamiento.

La tesis principal del texto es que la economía de tal transición se construye no alrededor del código, sino alrededor de la comunicación. En la entrega real, lo que es caro no es solo los cambios en sí, sino también la transferencia de trabajo entre análisis, desarrollo, pruebas y operaciones, la reconstrucción de conocimiento y aclaraciones constantes. Cuando la generación se acelera, el cuello de botella se desplaza hacia acuerdos, validación y control de riesgos.

Por lo tanto, los equipos necesitan un contexto externo, legible por máquinas y disponible para personas y agentes: objetivos, restricciones, riesgos, criterios de preparación, ADRs, contratos de API, reglas de seguridad, equipos de validación local y notas de rollout. Si el conocimiento crítico sigue viviendo en chats, llamadas y en la memoria de desarrolladores individuales, el agente simplemente trabaja con una imagen incompleta. Esto lleva a un nuevo enfoque en harness—el entorno de ejecución de agentes.

Ya no se trata de un gran prompt del sistema, sino de un conjunto de reglas y restricciones integradas en el proceso. El repositorio debe tener instrucciones explícitas para agentes, equipos de compilación y pruebas, criterios de preparación, restricciones arquitectónicas y de seguridad. Se propone que los escenarios repetibles se formen como skills, playbooks y reglas de repositorio, en lugar de explicarlos de nuevo en cada chat.

Además, las restricciones no deben ser solo textuales: el sistema debe poder detener acciones riesgosas, prohibir merges sin confirmaciones y encaminar pasos controvertidos a humanos. El autor discute por separado la capa de control. La revisión no debe recibir solo un diff, sino un evidence pack: qué exactamente cambió, qué escenarios están cubiertos, qué verificaciones se ejecutaron, qué riesgos permanecen y cómo revertir el cambio.

Encima de esto, se necesitan quality gates—límites en el tamaño de cambios, comandos validate obligatorios, verificación de restricciones arquitectónicas y actualización síncrona de documentación. Otra capa son evals para tareas repetidas. Permiten fijar explícitamente el comportamiento esperado del agente y verificar si el flujo de trabajo permanece estable después de cada cambio, en lugar de deslizarse hacia una versión cara de vibe coding con un flujo de PRs ruidosos.

Después del lanzamiento, según el autor, se debe monitorear no solo el producto sino también el propio proceso de entrega. El equipo debe analizar dónde al agente le faltó contexto, qué reglas resultaron débiles, qué tareas eran demasiado grandes para delegación segura, y dónde la revisión se ahogó en ruido. Esto afecta directamente la organización: crece el valor de los ingenieros de perfil amplo, se fortalece el papel de la ingeniería de plataforma y herramientas internas, y la incorporación de juniors deja de ser un efecto secundario natural del trabajo.

Si no se hace, el equipo corre el riesgo de criar 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 la entrega sea madura. Solo amplifican las fortalezas y debilidades del sistema de ingeniería existente.

Por lo tanto, el siguiente paso para los equipos no es solo generar código y documentos más rápidamente, sino construir un proceso en el que el contexto esté expuesto, el entorno de ejecución esté restringido, las verificaciones estén formalizadas, y cada fallo mejore no solo el producto sino también la forma en que se entrega.