Los equipos de Frontier no sólo utilizan la IA para codificar más rápido. Están rediseñando cómo se construye el software. El resultado es un aumento de productividad 4,5 veces mayor, en algunos casos más de 10 veces.
Seis ingenieros. Setenta y seis días. Un proyecto con alcance para 30 desarrolladores durante 12 a 18 meses, entregado en un trimestre. Eso no es hipotético. Es lo que sucedió cuando un equipo de Amazon Bedrock dejó de tratar la IA como un atajo de codificación y comenzó a tratarla como la base de su funcionamiento. El equipo envió más código de producción en cinco meses que en los diez años anteriores.
La brecha entre equipos como este y todos los demás se está ampliando rápidamente. Los agentes de codificación de IA han cambiado fundamentalmente la velocidad a la que se escribe el software, pero no la velocidad a la que llega a los clientes. Los compromisos están aumentando y los canales de CI/CD están más ocupados que nunca. Sin embargo, las funciones enviadas a producción no han seguido el mismo ritmo. El cuello de botella no es la capacidad del agente para generar resultados. Es el acceso del agente al conocimiento que necesita para tomar buenas decisiones y la voluntad del equipo para reestructurar el trabajo en torno a esa realidad.
A los equipos que han descubierto esto los llamamos “equipos de frontera”. No están confinados a laboratorios de élite. Existen en todas las industrias y tamaños de empresas, y comparten una disciplina común: tratan la adopción de la IA como una inversión en ingeniería, no como una implementación de herramientas. Cualquier equipo de ingeniería puede convertirse en un equipo de vanguardia; Podemos mostrarte cómo llegar.
Tres caminos hacia el desarrollo nativo de IA en Amazon
El desarrollo de software nativo de IA trata a la IA como la base de cómo se construye el software, con agentes cada vez más capaces dirigidos por expertos humanos. La forma en que los equipos dirigen a esos agentes determina los resultados. En Amazon, los principales impulsores de la IA en el desarrollo fueron reducir el tiempo que los desarrolladores dedicaban a tareas no relacionadas con la codificación, como documentación, coordinación y operaciones, eliminar la deuda técnica y minimizar las inconsistencias de codificación en miles de pequeños equipos de desarrolladores de “dos pizzas”. Hemos estado experimentando con cientos de equipos de ingeniería y hemos identificado al menos tres caminos: una iniciativa pionera con expertos que abordan un desafío, un sprint estructurado para ejecutar en un plan bien definido y un experimento in situ que divide los equipos por la mitad entre enfoques existentes y flujos de trabajo adaptados a la IA. Los caminos difieren en estructura pero convergen en la misma idea.
La iniciativa Pathfinder fue un experimento controlado. Seis ingenieros superiores recibieron un único mandato: reconstruir el motor de inferencia de Amazon Bedrock, un proyecto originalmente estimado en 30 desarrolladores que trabajarían entre 12 y 18 meses. En lugar de agregar personal, el equipo pasó sus primeras semanas rediseñando flujos de trabajo en torno a la IA, pasando de tareas discretas a resultados basados en objetivos, ejecutando múltiples agentes en paralelo y configurando sistemas para que la IA funcione de forma independiente fuera del horario laboral. El proyecto fue entregado en 76 días. La productividad de los desarrolladores individuales aumentó aproximadamente 20 veces, medida por la velocidad de confirmación normalizada (la cantidad de confirmaciones por desarrollador por semana, ajustada a la complejidad del repositorio y el tamaño del equipo). Las confirmaciones pasaron de 2 por semana a 40. El equipo envió más código de alta calidad en cinco meses que en proyectos durante los diez años anteriores, según lo medido por las líneas implementadas en producción.
El sprint estructurado adoptó un enfoque diferente. El equipo de Prime Video Financial Systems realizó un experimento de 10 días inspirado en el modelo Pathfinder. Seis ingenieros, una sala, cero cambios de contexto, sin tareas de guardia, sin otros proyectos, reuniones limitadas. Un ingeniero senior pasó tres semanas antes dividiendo la complejidad en tareas bien delimitadas con requisitos detallados. El equipo utilizó el desarrollo basado en especificaciones para trabajos de funciones complejas y el desarrollo asistido directamente por agentes para tareas donde los requisitos ya estaban claros. Durante 10 días, produjeron 556 compromisos frente a una base de 96 y redujeron una estimación de proyecto de 90 semanas a 24 semanas. Esto se traduce en un rendimiento casi 6 veces mayor y una aceleración 4 veces mayor. Atribuyeron la ganancia habilitada por la IA a tres factores que se multiplican: aceleración del trabajo de bajo juicio (1,5 veces), mayor enfoque en el trabajo de alto juicio sin cambio de contexto (1,5 veces) y acceso instantáneo a la experiencia en el dominio capturado por el agente (1,5 veces). Elimine cualquier factor y las ganancias colapsarán. El equipo ahora busca optimizar estos tres factores en las operaciones normales utilizando especificaciones detalladas del producto que encapsulan el conocimiento del dominio y agentes autónomos que liberan tiempo de concentración.
En el experimento in situ, de los más de 50 equipos estudiados, los 25 equipos que implementaron nuevas herramientas y nuevas prácticas superaron a aquellos que simplemente agregaron IA a los flujos de trabajo existentes. Las tiendas Amazon ejecutaron pilotos estructurados con equipos de desarrollo típicos que trabajaban con sus trabajos pendientes habituales, utilizando Kiro y herramientas de inteligencia artificial especialmente diseñadas, sin condiciones especiales ni ingenieros cuidadosamente seleccionados. El aumento medio de la productividad fue de 4,5 veces, y algunos equipos alcanzaron una mejora de más de 10 veces en la velocidad de implementación normalizada (características implementadas por sprint, normalizadas con respecto a líneas de base históricas). Perfect Order Experience ahora envía funciones en una tarde en lugar de dos semanas. WW Grocery redujo la creación de documentos de diseño de cinco días a unas pocas horas.
Diferentes caminos, misma lección. El flujo de trabajo importa, no sólo la herramienta.
Cinco pasos para convertirse en un equipo de vanguardia
En los tres caminos, los equipos de mayor desempeño comparten cinco prácticas con una lógica común. Reducir las barreras contextuales para el agente y aumentar la superficie de trabajo que puede realizar de forma independiente.
Aquí es donde los equipos fronterizos se apartan de sus hábitos anteriores. El enfoque histórico optimizado para la velocidad de generación de código individual. Los equipos de Frontier optimizan para algo diferente: la velocidad a la que el software correcto y listo para producción llega a los clientes. Esa distinción impulsa todas las prácticas siguientes.
Invierta en el contexto del agente. Los equipos más avanzados invierten mucho en hacer que los proyectos y el conocimiento sean más fáciles de consumir para los agentes a través de archivos de dirección de agentes y orientación sobre convenciones de equipo, estándares de codificación, pruebas y navegación de base de código. El equipo de infraestructura de Bedrock colocó todo el código y la documentación en un monorepo y mantuvo los comentarios en línea que generaron los agentes de IA, tratándolos como memoria persistente. Los equipos que se saltan este paso se preguntan por qué sus agentes siguen cometiendo los mismos errores. Reducir la velocidad para acelerar. La práctica antes mencionada lleva tiempo y requiere que los equipos sean pacientes. Todos los equipos de alto rendimiento informaron que las cosas inicialmente se ralentizaron a medida que aprendieron los modelos. Codificaron experiencia multifuncional en documentos de dirección reutilizables para agentes, reestructuraron repositorios para que los LLM pudieran razonar sobre ellos y agregaron comentarios y rediseñaron divisiones de código para el consumo de IA. Los equipos que superaron esa curva de aprendizaje y definieron los resultados esperados experimentaron primero una aceleración compuesta. Los equipos que esperaban ganancias inmediatas sin cambiar sus flujos de trabajo quedaron decepcionados. Espere que las primeras dos semanas se sientan más lentas. Espere que las semanas siguientes se sientan dramáticamente más rápidas. Los equipos que renunciaron en la segunda semana nunca ven la combinación. Alimente a los agentes en lugar de cuidarlos. Los equipos de Frontier mantienen una acumulación constante de tareas bien definidas con resultados claros, ejecutan múltiples agentes en paralelo y revisan los resultados de forma asincrónica. Los constructores informan que terminan las funciones principales en períodos cortos, y el trabajo avanza incluso cuando no están esperando activamente a que el agente complete una tarea. Un ingeniero principal realizó un cambio completo con solo “un par de horas de tiempo continuo” porque el agente trabajaba mientras el ingeniero pasaba entre revisiones de código, soporte operativo y reuniones. Haga explícita la intención antes de escribir el código. Ya sea a través de especificaciones estructuradas, documentos de requisitos detallados o una descomposición de tareas bien delimitada, los equipos fronterizos garantizan que los agentes tengan un contexto claro sobre cómo se ve “hecho” antes de comenzar a generar código. Algunos equipos que utilizan este enfoque informan que solo escriben a mano entre el 1% y el 2% de su código, mientras realizan significativamente más confirmaciones por persona por semana que antes. “Prueba de cambio a la izquierda”. Los equipos de Frontier crean herramientas para que los agentes puedan ejecutar todas las pruebas de integración localmente y autocorregirlas antes de que el código llegue al proceso. El equipo de Prime Video invirtió en medidas de seguridad automatizadas, pruebas de componentes, pruebas de rendimiento y formateadores que detectaron los problemas a tiempo. Las revisiones de código cambiaron el enfoque hacia las definiciones de interfaz y las decisiones arquitectónicas en lugar del estilo del código y las convenciones de nomenclatura.
Qué pueden hacer los líderes tecnológicos hoy
No todos los equipos logran estos resultados. Los equipos que se saltan la fase de creación de contexto, tratan la IA como un reemplazo directo o esperan ganancias inmediatas sin reestructurar su forma de trabajar tienen un desempeño consistentemente inferior. Los desarrolladores de toda la industria han adoptado herramientas de codificación de IA. No todos están viendo aumentos de producción. No están utilizando las herramientas equivocadas. Están utilizando las herramientas adecuadas dentro de los flujos de trabajo incorrectos.
Las conclusiones clave son:
Cambie su forma de trabajar para que la IA funcione de la mejor manera. Tres factores se multiplican para ofrecer resultados: IA que maneja el trabajo de bajo juicio x enfoque ininterrumpido en el trabajo de alto juicio x acceso instantáneo a la experiencia en el dominio. Primero pilotear, luego escalar.
El punto de partida práctico no es un despliegue amplio. Es un piloto deliberado. Comience con un equipo pequeño dispuesto a pasar las primeras semanas creando el contexto del agente (archivos de dirección, plantillas de especificaciones, monorepos) antes de escribir el código de producción. Otorgue al equipo un mandato para reestructurar los flujos de trabajo. Mida la velocidad de confirmación, la frecuencia de implementación y el tiempo de resolución, junto con las puntuaciones de satisfacción de los desarrolladores. Luego utilice lo que aprendan para elaborar el manual para el resto de la organización.
Los equipos que lograron ganancias de productividad de 4,5 a más de 10 veces no solo han adoptado una mejor tecnología. Han descubierto cómo trabajar de manera diferente con él. Esa decisión está disponible para todas las organizaciones de ingeniería en la actualidad. Por supuesto, la velocidad de confirmación del código es sólo una parte de la historia. Queremos ayudar con todos los aspectos del ciclo de vida del desarrollo de software, ya sea optimizando la gestión de lanzamientos, las operaciones y las operaciones de seguridad, o abordando las actualizaciones de EOL y las innumerables tareas indiferenciadas que conlleva la ingeniería de software. Estén atentos al próximo blog, donde explicaré cómo los estamos abordando.
Obtenga más información sobre los equipos fronterizos >
Sintonice la Cumbre de AWS en la ciudad de Nueva York para obtener más información sobre el desarrollo nativo de IA.
Sobre el autor
Swami Sivasubramanian es vicepresidente de IA agente en Amazon Web Services (AWS). En AWS, Swami ha liderado el desarrollo y crecimiento de servicios de IA líderes como Amazon DynamoDB, Amazon SageMaker, Amazon Bedrock y Amazon Q. La misión de su equipo es brindar la escala, la flexibilidad y el valor que los clientes y socios necesitan para innovar usando IA agente con confianza y crear agentes que no solo sean poderosos y eficientes, sino también confiables y responsables. Swami también se desempeñó desde mayo de 2022 hasta mayo de 2025 como miembro del Comité Asesor Nacional de Inteligencia Artificial, que tenía la tarea de asesorar al Presidente de los Estados Unidos y a la Oficina de la Iniciativa Nacional de IA sobre temas relacionados con la Iniciativa Nacional de IA.