Los equipos de Frontier no solo utilizan inteligencia artificial para codificar más rápido. Están reinventando la forma en que se desarrolla el software. El resultado es una productividad 4,5 veces mayor, en algunos casos más de 10 veces.
Seis ingenieros. Setenta y seis días. Un proyecto para 30 desarrolladores durante 12-18 meses, entregado en un trimestre. Esto no es hipotético. Esto es lo que sucedió cuando el equipo de Amazon Bedrock dejó de tratar la IA como un atajo de codificación y comenzó a tratarla como la base de su trabajo. En cinco meses, el equipo envió más código a producción que en los diez años anteriores.
La brecha entre esos equipos 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 entregadas a producción no han cambiado. La restricción no es la capacidad del agente para generar resultados. Es el acceso del agente al conocimiento necesario para tomar buenas decisiones y la voluntad del equipo para remodelar esa realidad.
A los equipos que han descubierto esto los llamamos «equipos de frontera». No se limitan a laboratorios de élite. Existen en industrias y 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 para el desarrollo local de la IA en Amazon.
El desarrollo de software de inteligencia artificial trata a la IA como la base del desarrollo de software, con agentes cada vez más capaces guiados por expertos humanos. La forma en que los equipos se dirigen a estos agentes determina los resultados. Las principales razones de Amazon para desarrollar IA fueron reducir el tiempo que los desarrolladores dedican a tareas no relacionadas con la codificación, como documentación, coordinación y operaciones, eliminar la deuda técnica y reducir las inconsistencias de codificación en miles de pequeños equipos de desarrollo de «dos pizzas». Experimentamos con cientos de equipos de ingeniería y encontramos al menos tres caminos: una iniciativa de búsqueda de caminos con expertos resolviendo el desafío, un sprint estructurado para ejecutar un plan bien definido y un experimento in situ que divide los equipos por la mitad entre métodos existentes y flujos de trabajo habilitados por IA. Los caminos difieren en estructura pero convergen en la misma idea.
El iniciativa del buscador de caminos Fue un experimento controlado. A los seis ingenieros senior se les dio un mandato: reconstruir el motor de inferencia Bedrock de Amazon, un proyecto originalmente programado para 30 desarrolladores durante 12 a 18 meses. En lugar de agregar personal, el equipo pasó las primeras semanas rediseñando los flujos de trabajo de la IA, pasando de tareas discretas a resultados basados en objetivos, ejecutando múltiples agentes en paralelo y configurando sistemas para permitir que la IA se ejecutara de forma autónoma 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 tasa de confirmación normalizada (la cantidad de confirmaciones por desarrollador por semana, ajustada a la complejidad del repositorio y el tamaño del equipo). El número de confirmaciones se redujo de 2 por semana a 40. En cinco meses, el equipo envió más código de alta calidad que proyectos en los diez años anteriores, medido por líneas de producción.
El sprint estructurado adoptó un enfoque diferente. El equipo de Prime Video Financial Systems llevó a cabo un experimento de 10 días inspirado en el modelo Pathfinder. Seis ingenieros, una sala, cero cambios de contexto, sin esperas, sin otros proyectos, reuniones limitadas. Un ingeniero senior, con tres semanas de antelación, dividió la complejidad en tareas bien ejecutadas con requisitos detallados. El equipo utilizó desarrollo basado en especificaciones para trabajos de funciones complejas y desarrollo asistido por agentes en vivo para tareas donde los requisitos ya estaban claros. En 10 días, realizaron 556 compromisos, frente a una base de 96, y redujeron la estimación del proyecto de 90 semanas a 24 semanas. Eso significa casi 6 veces el ancho de banda y 4 veces la aceleración. Atribuyeron los beneficios de la IA a tres factores que se multiplican: acelerar el trabajo de bajo valor (1,5 veces), mayor enfoque en el trabajo de alto valor sin cambio de contexto (1,5 veces) y acceso inmediato al conocimiento del dominio derivado de agentes (1,5 veces). Elimine cualquiera de los factores y las ganancias colapsarán. El equipo ahora quiere optimizar estos tres factores en las operaciones normales, utilizando especificaciones detalladas del producto que incluyan conocimiento del dominio y agentes autónomos que liberen tiempo de concentración.
A experimento in situDe los más de 50 equipos estudiados, los 25 equipos que implementaron nuevas herramientas y nuevas prácticas superaron a aquellos que simplemente incorporaron IA en los flujos de trabajo existentes. Las tiendas Amazon realizaron pruebas estructuradas con equipos de desarrollo típicos que trabajaban contra un trabajo atrasado continuo, utilizando Kiro y herramientas de inteligencia artificial especialmente diseñadas sin condiciones especiales ni ingenieros cuidadosamente seleccionados. El aumento promedio de la productividad fue de 4,5 veces y algunos equipos lograron tasas de implementación normalizadas de más de 10 veces (funciones implementadas durante el sprint normalizadas a líneas de base históricas). Perfect Order Experience ahora ofrece funciones en una tarde en lugar de dos semanas. WW Grocery redujo el desarrollo 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 fronterizo
En los tres caminos, los equipos de alto rendimiento comparten cinco prácticas siguiendo una lógica común. Reduzca las limitaciones del contexto del agente y aumente el área de trabajo que puede realizar de forma independiente.
En esto es donde los equipos fronterizos se diferencian de los hábitos anteriores. El método histórico está optimizado para la velocidad de generación de código personalizado. Los equipos de Frontier optimizan algo más: la velocidad a la que el software correcto y listo para producción llega a los clientes. Esta diferencia impulsa cada una de las siguientes prácticas.
- Invierta en el contexto del agente. Los equipos más avanzados invierten mucho en hacer que los proyectos y la experiencia sean más fáciles de usar para los agentes, utilizando archivos de control de agentes y pautas para las convenciones del equipo, estándares de codificación, pruebas y navegación de la base de código. El equipo de infraestructura de Bedrock puso todo el código y la documentación en un monorepo y almacenó los comentarios generados por los agentes de IA 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. Las prácticas anteriores toman tiempo y requieren que los equipos sean pacientes. Todos los equipos de alto rendimiento informaron que las cosas se ralentizaron al principio a medida que aprendieron los patrones. Codificaron experiencias multifuncionales en documentos de control de agentes reutilizables, reestructuraron repositorios para que LLM pudiera razonar sobre ellos, agregaron comentarios y rediseñaron descomposiciones de códigos de consumo de IA. Los equipos que superaron la curva de aprendizaje y definieron los resultados esperados fueron los primeros en experimentar un mayor impulso. Los equipos que esperaban beneficios inmediatos sin cambiar los flujos de trabajo quedaron decepcionados. Espere sentirse más lento durante las primeras dos semanas. Espere sentirse significativamente más rápido después de unas semanas. Los equipos que quedan eliminados en la segunda semana nunca ven realmente cómo se han recuperado.
- Alimenta a los agentes en lugar de cuidarlos. Los equipos de Frontier mantienen una cantidad constante de tareas completas con resultados claramente visibles, ejecutan múltiples agentes en paralelo y ven los resultados de forma asincrónica. Los desarrolladores informan que las funciones principales se han completado en breves períodos y el trabajo continúa incluso cuando no están esperando activamente a que un agente complete una tarea. Un ingeniero líder realizó todo el cambio en solo «un par de horas seguidas» porque el agente estaba trabajando mientras el ingeniero de cambios realizaba revisiones de código, soporte operativo y reuniones.
- Antes de escribir su código, deje clara su intención. Ya sea a través de especificaciones estructuradas, documentos de requisitos detallados o desgloses de tareas bien definidos, los equipos fronterizos garantizan que los agentes tengan un contexto claro de cómo se ve «hecho» antes de comenzar a escribir código. Algunos equipos que utilizan este enfoque informan que escriben solo entre el 1 y el 2 % de su código a mano y envían significativamente más confirmaciones por persona por semana que antes.
- «Prueba de cambio a la izquierda». Los equipos de Frontier están creando herramientas para permitir a los agentes ejecutar todas las pruebas de integración en el lugar 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. La revisión del código se centró en definiciones de interfaz y decisiones arquitectónicas en lugar de estilo de código y convenciones de nomenclatura.
Qué pueden hacer los líderes tecnológicos hoy
No todos los equipos logran tales resultados. Los equipos que se saltan la fase de creación de contexto ven la IA como un sustituto o esperan beneficios inmediatos sin rediseñar sus estructuras de trabajo en curso. Los desarrolladores de toda la industria han adoptado herramientas de codificación de IA. No todos ven un aumento en la producción. No utilizan las herramientas equivocadas. Utilizan las herramientas adecuadas en los flujos de trabajo equivocados.
Las principales conclusiones son:
- Cambie su forma de trabajar para aprovechar al máximo la IA.
- Tres factores se multiplican para lograr resultados: IA realizando trabajos de bajo valor x enfoque continuo en trabajos de alto valor x acceso instantáneo a experiencia en el dominio.
- Primero el piloto y luego la báscula.
El punto de partida práctico no es un despliegue generalizado. Es un piloto intencional. Antes de escribir código de producción, comience con un equipo pequeño que quiera dedicar las primeras semanas a crear el contexto del agente (archivos de control, plantillas de especificaciones, monorepos). Capacite al equipo para rediseñar el flujo 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 han aprendido para crear un manual para el resto de la organización.
Los equipos que lograron aumentos de productividad entre 4,5 y 10 veces no solo utilizaron mejor tecnología. Descubrieron cómo trabajar con él de manera diferente. Esta solución está disponible hoy en día para todas las organizaciones de ingeniería. Por supuesto, la tasa de bits es sólo una parte de la historia. Queremos ayudar con todos los aspectos del ciclo de desarrollo de software, ya sea agilizando la gestión de lanzamientos, las operaciones y las operaciones de seguridad, o lidiando con las actualizaciones EOL y las muchas tareas indiferenciadas asociadas con la ingeniería de software. Estén atentos al próximo blog donde les contaré cómo estamos llegando allí.
Obtenga más información sobre los comandos de borde >
Únase a la Cumbre de AWS en la ciudad de Nueva York para obtener más información sobre el desarrollo de la inteligencia artificial.
Sobre el autor
Swami Sivasubramanian es vicepresidente de IA agente en Amazon Web Services (AWS). 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 a los clientes y socios la escala, la flexibilidad y el valor que necesitan para innovar utilizando agentes de IA con confianza y crear agentes que no solo sean potentes y eficientes, sino también confiables y con capacidad de respuesta. Desde 2022 en mayo hasta 2025 en mayo, Swami también se desempeñó como miembro del Comité Asesor Nacional de Inteligencia Artificial, encargado de asesorar al Presidente de los Estados Unidos y a la Oficina de Iniciativas Nacionales de IA sobre temas relacionados con la Iniciativa Nacional de IA.
