El cuello de botella que nadie cuenta sobre los agentes de IA en el código
Quien sigue de cerca el universo del desarrollo de software ya sabe que los agentes de IA capaces de escribir código a una velocidad absurda dejaron de ser una promesa hace rato. Lo que poca gente discute abiertamente es lo que pasa después de que ese código se genera. En la mayoría de las empresas, el resultado simplemente no sobrevive al contacto con la realidad: rompe estándares de ingeniería internos, falla en verificaciones de compliance, ignora convenciones de arquitectura y, al final del día, genera más retrabajo que ahorro real. Es como tener un becario extremadamente rápido que entrega todo fuera de estándar — terminas gastando más tiempo revisando que si lo hubieras hecho desde cero.
Stephen Newman, líder global de ingeniería de tecnología para clientes de EY, resumió bien el problema. Según él, es posible generar toneladas de código, pero eso no significa gran cosa si el resultado no es integrable, no cumple con compliance y termina creando más trabajo en la retaguardia solo porque el proceso de generación se aceleró en la punta. Este es el tipo de trampa que toma a muchas empresas por sorpresa: la ilusión de velocidad que, en la práctica, solo empuja el cuello de botella hacia otra etapa del flujo.
EY, una de las mayores consultoras del planeta, decidió enfrentar este problema de frente. Y lo que el equipo liderado por Newman logró entregar merece la atención de cualquier organización que trabaja con tecnología a escala. Al realizar la integración de los agentes de código directamente a los repositorios, frameworks de compliance y estándares de ingeniería ya existentes en la empresa, los equipos responsables de construir plataformas de auditoría, impuestos y finanzas alcanzaron ganancias de productividad de entre 4x y 5x. No estamos hablando de métricas de laboratorio o pruebas de concepto aisladas — son resultados medidos en equipos reales, trabajando en productos reales, entregando para clientes reales.
Pero es importante dejar claro desde ya: nada de esto ocurrió de la noche a la mañana. El camino hasta esos números involucró entre 18 y 24 meses de construcción que fue tanto cultural como técnica. Pasó por la adopción orgánica de herramientas asistivas, la elección cuidadosa de plataforma y, quizás lo más importante, una transformación genuina en el rol de los desarrolladores dentro de la organización.
De la asistencia a la orquestación: cómo EY construyó el camino
El primer paso del viaje de EY no fue salir implementando agentes de IA autónomos en todos los proyectos. En realidad, fue casi lo opuesto. La empresa comenzó con herramientas al estilo GitHub Copilot, dejando que los ingenieros se acostumbraran al prompt engineering y al uso de IA asistiva en el día a día. Esa fase inicial fue fundamental para crear familiaridad con la tecnología y, principalmente, para que la adopción ocurriera de forma orgánica.
Newman fue enfático en este punto: el aprendizaje más valioso fue entender que llevar las capacidades de IA como una adopción de abajo hacia arriba funciona mucho mejor que imponer herramientas de arriba hacia abajo. Cuando los desarrolladores sienten que están eligiendo usar la tecnología — en vez de ser forzados —, el compromiso y la calidad del uso aumentan drásticamente.
Durante ese período, el equipo de ingeniería mapeó qué actividades consumían más tiempo, qué tipos de error eran más recurrentes y dónde la intervención humana realmente agregaba valor versus dónde era solo burocracia operacional. Ese diagnóstico práctico, hecho con datos reales del día a día, fue lo que permitió dar el salto siguiente con seguridad. Los desarrolladores querían ir más allá de la simple generación de código — querían avanzar hacia la construcción, deployment y operacionalización. Pero las ganancias de productividad alcanzaron una meseta sin una integración más profunda.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
El punto de inflexión llegó cuando Newman se dio cuenta de que los agentes necesitaban acceso a lo que él llama universo de contexto: los repositorios de código de la empresa, los estándares de ingeniería y los catálogos de recursos internos. Sin ese contexto, los agentes producían outputs genéricos que exigían retrabajo extensivo. La integración no fue superficial. Los agentes pasaron a consultar automáticamente las bibliotecas internas aprobadas, respetar las convenciones de nomenclatura, aplicar las reglas de seguridad exigidas por el sector e incluso considerar requisitos regulatorios específicos de cada jurisdicción. En la práctica, el código generado ya nacía dentro del estándar, eliminando ese ciclo interminable de review, corrección y re-review que consumía semanas enteras de trabajo.
La elección de la plataforma: sin imposición, con datos
La elección de la plataforma tampoco fue trivial. EY evaluó múltiples opciones de agentes: Lovable, Replit y los Droids basados en IDE de Factory. En vez de que el equipo de liderazgo eligiera una herramienta e impusiera la decisión, Newman y su equipo midieron adopción, uso y productividad en las tres plataformas simultáneamente.
Newman explicó que no quería ser demasiado prescriptivo como liderazgo, eligiendo una herramienta y simplificando la decisión. El objetivo era dejar que los propios desarrolladores señalaran dónde estaban encontrando valor real. Y fue exactamente eso lo que pasó. Los ingenieros gravitaron naturalmente hacia Factory, lo que se convirtió en la señal clara de que esa plataforma entregaba resultados concretos.
Cuando Factory fue elevada de evaluación a piloto, la adopción, en palabras de Newman, se expandió como fuego. EY necesitó incluso limitar el tráfico hacia Factory y hacia los Droids, restringiendo qué repositorios podían conectarse antes de obtener la aprobación completa de compliance y seguridad. Ese tipo de entusiasmo descontrolado, que normalmente se vería como positivo, en realidad encendió una alerta importante: la empresa necesitaba disciplina sobre qué cargas de trabajo delegar a los agentes.
El framework de clasificación de cargas de trabajo
Con los desarrolladores entusiasmados y la adopción creciendo rápido, quedó claro que EY necesitaba criterios claros para definir qué podían hacer los agentes solos y qué todavía necesitaba supervisión humana. El equipo de Newman creó un framework que separaba las tareas en dos categorías bien definidas:
Tareas de alta autonomía — donde los agentes brillan
- Revisión de código — los agentes hacen escaneos rápidos y consistentes, identificando problemas de estándar y posibles bugs
- Documentación — generación y actualización de documentación técnica a partir del código existente
- Corrección de defectos — identificación y resolución de bugs conocidos con alta tasa de acierto
- Funcionalidades greenfield — desarrollo de recursos nuevos que no dependen de código legado complejo
Tareas complejas — donde el humano sigue siendo esencial
- Refactorizaciones a gran escala — cambios estructurales que impactan múltiples sistemas simultáneamente
- Decisiones de arquitectura — elecciones de diseño que definen la dirección técnica a largo plazo
- Integraciones entre sistemas — conexiones que involucran múltiples APIs, bases de datos y dependencias cruzadas
Esta clasificación puede parecer simple a primera vista, pero en la práctica resuelve un problema que muchas empresas enfrentan al adoptar agentes de IA: la tentación de delegar todo y después lidiar con las consecuencias. Con categorías claras, cada miembro del equipo sabe exactamente cuándo puede confiar en el agente y cuándo necesita tomar el control. Esto evita tanto el uso excesivo como la subutilización de la tecnología.
El nuevo rol del desarrollador: de ejecutor a orquestador
Quizás el cambio más profundo que EY promovió no fue tecnológico, sino de mentalidad. La empresa también redefinió los roles de los desarrolladores. En vez de escribir todo el código ellos mismos, los ingenieros pasaron a actuar como orquestadores, dirigiendo a los agentes hacia las bases de datos y repositorios correctos para cada tarea.
Esta transición exigió entrenamiento, acompañamiento y mucha paciencia organizacional. Los ingenieros que se adaptaron más rápido fueron justamente aquellos que ya tenían una visión más sistémica del desarrollo de software — profesionales que entendían el por qué detrás de cada estándar de ingeniería, no solo el cómo. Para estos profesionales, los agentes se convirtieron en multiplicadores absurdos de capacidad, permitiendo que un solo desarrollador orquestara trabajo equivalente al de cuatro o cinco personas.
Newman describió ese momento como un salto hacia lo que él llama modelo de desarrollo horizon. En ese modelo, la empresa opera con ejecución semi-autónoma de agentes a escala, un equipo de orquestadores en vez de ejecutores e integraciones completas con el universo de contexto. Es un cambio fundamental en la forma en que los equipos de ingeniería se organizan y entregan valor.
Los resultados concretos y lo que realmente significan
Con las protecciones de seguridad implementadas y la integración con los repositorios de código concluida, EY midió ganancias de eficiencia que variaron del 15% al 60% en diferentes perfiles de profesionales durante la fase inicial de adopción. Las ganancias mayores, de 4x a 5x, llegaron con la maduración del proceso a lo largo de los meses siguientes.
Newman se encargó de reconocer que es difícil atribuir esas ganancias de productividad exclusivamente a los agentes de código. Las mejoras vinieron de una combinación de prueba y error junto con cambios culturales y comportamentales en los equipos de desarrollo. Esa honestidad es importante porque evita la narrativa simplista de que basta con conectar una herramienta de IA y la productividad mágicamente se multiplica. En la realidad, la herramienta es solo una pieza del rompecabezas.
Los resultados de productividad son impresionantes justamente porque no dependen de condiciones artificiales. Fueron observados en contextos de producción real, con todos los requisitos de calidad, seguridad y compliance que las operaciones de auditoría y finanzas exigen. Cuando el agente ya conoce las reglas del juego antes de escribir una sola línea de código, el resultado sale aprovechable a la primera en la mayoría de las veces. Esto elimina el retrabajo, acelera los ciclos de entrega y libera a los ingenieros más senior para enfocarse en decisiones de arquitectura e innovación en vez de quedarse atrapados en code review de rutina.
Lecciones para quien quiere seguir el mismo camino
La experiencia de EY deja algunas lecciones claras para organizaciones que están pensando en adoptar agentes de IA en el desarrollo de software a escala:
Herramientas que usamos a diario
Primero, invierte en estándares antes de invertir en herramientas. Los agentes sin contexto son solo generadores de código genérico. Tener repositorios bien organizados, documentación de estándares actualizada y reglas de compliance bien definidas es prerrequisito para que cualquier agente de IA genere código realmente aprovechable. Sin eso, solo estás automatizando la producción de retrabajo.
Segundo, trata la adopción como un viaje cultural. Los 18 a 24 meses que EY invirtió antes de alcanzar los resultados más expresivos no fueron tiempo perdido — fueron la base que hizo todo posible. Comenzar con herramientas asistivas, dejar que los desarrolladores se acostumbren a su propio ritmo y usar datos de adopción para guiar decisiones son prácticas que reducen resistencia y aumentan la calidad del uso.
Tercero, clasifica tus cargas de trabajo. No toda tarea de desarrollo es igual, y no toda tarea debería ser delegada a un agente. Tener un framework claro que defina dónde la autonomía funciona y dónde la supervisión humana es necesaria evita desastres y construye confianza gradual en la tecnología.
Cuarto, mide la adopción con datos, no con opiniones. La decisión de EY de evaluar tres plataformas simultáneamente y dejar que los propios desarrolladores señalaran su preferencia es un ejemplo de cómo las decisiones de herramientas pueden tomarse de forma pragmática en vez de política.
El futuro del desarrollo de software a escala corporativa no se trata de reemplazar desarrolladores por IA. Se trata de crear un entorno donde humanos y agentes de IA trabajen juntos de forma inteligente, cada uno haciendo lo que mejor sabe hacer. EY demostró que esto es posible — pero también demostró que el camino exige paciencia, estrategia y mucho más que simplemente encender una herramienta. 🚀
