De asistido por IA a nativo de IA: Construyendo un equipo de desarrollo de vanguardia — Clare Liguori, AWS
AAI Engineer
컴퓨터/소프트웨어경영/리더십AI/미래기술
스크립트
00:00:00Clare Liguori: Mi nombre es Clare Liguori y soy ingeniera principal sénior en AWS.
00:00:17Trabajo principalmente en Kiro, nuestro asistente de decodificación de agentes, pero hoy quiero hablar sobre
00:00:23algunas de las prácticas que hemos estado viendo dentro de Amazon, en equipos de Amazon, donde hemos observado
00:00:28resultados realmente emocionantes de aumentos de productividad que representan mejoras de funciones escalonadas en comparación con lo
00:00:35que hemos visto con la IA hasta ahora. Llevo trabajando en IA agéntica más de tres años,
00:00:43y he podido presenciar la evolución que ha tenido nuestra industria en lo que respecta a la asistencia
00:00:48de programación con IA. Primero tuvimos el autocompletado de código en línea que nos ayudaba a escribir la siguiente línea,
00:00:55tal vez la siguiente función. Pasamos al chat, haciendo preguntas sobre nuestro código. Todo el mundo empezó a hacer
00:01:02“vibe coding” en algún momento del año pasado, pero ahora estamos empezando a ver una fase de adopción temprana de
00:01:08lo que hemos estado llamando desarrollo de frontera. Y de manera totalmente anecdótica, basándome en mi propia experiencia,
00:01:14realmente solo me he sentido quizás un 10 o 20 % más productiva con todas estas fases que han
00:01:20venido antes. Pero ahora, dentro de Amazon, hemos estado realizando pruebas piloto con diferentes equipos en toda la empresa,
00:01:27y hemos observado una mejora media de la productividad de 4.5x y, en ocasiones, de más de 10x. Así que
00:01:34algo ha cambiado realmente ahora que vemos estas mejoras escalonadas en la productividad.
00:01:40Y me gusta definir lo que hemos estado llamando desarrolladores de frontera dentro de Amazon
00:01:47mediante tres comportamientos que he estado observando. El primero es la programación sin intervención manual. Los desarrolladores de frontera escriben tal vez
00:01:54del 1 al 2 % del código que producen. El resto lo hacen los agentes. El segundo es que interactúan con sus
00:02:01agentes con poca frecuencia. Intentan que su asistente de programación funcione durante horas seguidas sin
00:02:08su intervención. Y el tercero es que minimizan el tiempo inactivo. Estos desarrolladores de frontera tienden a ejecutar
00:02:15múltiples agentes en paralelo, procesando una lista de tareas pendientes. La primera vez que vi un equipo de desarrolladores
00:02:24de frontera fue el equipo de Bedrock Mantle. Bedrock es nuestro servicio de alojamiento de modelos. Aloja modelos de lenguaje grandes (LLM) como Claude
00:02:34y GPT. Y en algún momento del año pasado sabíamos, o digo sabíamos, pero el equipo de Bedrock sabía que iban a
00:02:43necesitar construir un nuevo plano de datos de inferencia. Pero lo habían estimado en 30 personas durante 18 meses. Este es un servicio
00:02:52muy, muy grande. Y llevaría tiempo construir el nuevo, migrar a los clientes y migrar los modelos
00:02:58allí. Y decidieron dar un paso atrás. Tomaron a seis personas y lo construyeron en 76 días con Kiro.
00:03:06Así que fue un logro enorme. Esta fue la primera vez que veíamos algo así dentro de Amazon.
00:03:12Por lo tanto, este fue verdaderamente el equipo pionero que demostró que era posible obtener una mejora de hasta 20x. Ahora bien, observaron
00:03:21las confirmaciones de cambios (“commits”), y hablaré de un par de otras formas en las que estamos midiendo las mejoras de productividad. Pero
00:03:27había un problema con esta historia, y es que, sí, se construyó con seis personas. Se construyó
00:03:34con algunos de los mejores ingenieros de literalmente toda la empresa, incluidos dos ingenieros distinguidos. Así que
00:03:40no era un equipo cualquiera de seis personas. Eran expertos en sistemas distribuidos, expertos en LLM y en su
00:03:49arquitectura. Así que esta historia fue increíble y se extendió como la pólvora por todo Amazon. Pero también
00:03:57era muy inalcanzable para muchos equipos. Hubo muchas dudas sobre si esto se podía reproducir realmente
00:04:03en otro equipo. Así que otro experimento del que quiero hablar es un sprint experimental que se llevó a cabo
00:04:10en la organización de Prime Video. Hicieron un sprint de 10 días e hicieron un experimento en el que pusieron, de nuevo, a seis ingenieros
00:04:19en una habitación y los dejaron trabajar a sus anchas con Kiro. Redujeron la estimación del tiempo de entrega del proyecto de lo que
00:04:29iba a ser 90 semanas a 24, basándose en todo el progreso que habían logrado en este sprint de 10 días.
00:04:36Y examinaron su historial de confirmaciones y observaron qué solían hacer antes de este
00:04:42sprint de 10 días y cuántas confirmaciones produjeron solo en esos 10 días. Por lo tanto, este sprint demostró realmente
00:04:49que podemos lograr, una vez más, al menos algo cercano a lo que el equipo de Bedrock Mantle había conseguido
00:04:58con un conjunto diferente de ingenieros. Pero, de nuevo, había un problema con esta historia: eran seis
00:05:05ingenieros en una habitación sin turnos de guardia (“on-call”), reuniones limitadas y muy pocas distracciones, que todos
00:05:12sabemos que son habituales en la vida de un ingeniero. Y el ingeniero sénior del equipo había pasado las tres semanas
00:05:20anteriores creando tareas muy detalladas, pequeñas y bien acotadas, con requisitos precisos para que estos seis
00:05:28ingenieros simplemente se pusieran a trabajar durante esas dos semanas. Así que esto, de nuevo, no era necesariamente la vida real.
00:05:35Fue un sprint estructurado, un momento puntual en el que pudieron lograr esto. Pero, de nuevo, la
00:05:41pregunta es: ¿se puede lograr esto en equipos reales para el trabajo del día a día? Así que Amazon Stores, que abarca
00:05:51Amazon.com, todos nuestros sitios web minoristas y también nuestras tiendas físicas, realizó una prueba piloto más estructurada.
00:05:59Observaron a 50 equipos totalmente normales, con una distribución normal de personas al inicio de su carrera, profesionales de mitad de carrera
00:06:07e ingenieros sénior, y que trabajaban en sistemas existentes. Nada desde cero (“Greenfield”) como lo que el equipo de Mantle
00:06:14pudo construir desde los cimientos, sino sistemas existentes con bases de código ya creadas. Los observaron durante
00:06:21la mayor parte del año pasado y descubrieron algo súper interesante. Vieron que había una gran
00:06:28diferencia en las ganancias de productividad entre la mitad de los equipos y la otra mitad. Y en
00:06:34este caso, utilizaron como métrica de productividad la velocidad de despliegue a producción. Así que no solo las confirmaciones, cuántas
00:06:41confirmaciones producen, sino con qué rapidez hacemos llegar los cambios a los clientes. Con qué rapidez
00:06:48podemos lanzar cosas al mercado. Y vieron que la mitad de los equipos lograron un incremento inferior a 3x. Y lo que
00:06:56descubrieron que marcaba la diferencia entre ver un aumento de productividad menor a 3x y estos equipos que alcanzaron
00:07:01una media de 4.5x, y en algunos casos más de 10, era cómo utilizaban las herramientas. El 90 % de estos equipos usaban Kiro,
00:07:11además de otras herramientas internas que tenemos. Y lo que descubrieron fue que no se trataba de las herramientas, sino de la forma en que
00:07:18trabajaban. Los equipos que lograron mejoras de funciones escalonadas cambiaron intencionalmente su forma de trabajar,
00:07:26mientras que los demás simplemente aplicaron Kiro y algunas de las otras herramientas que tenemos por encima de su
00:07:31forma habitual de trabajar. Y para mí, al menos, ese fue el gran momento de revelación: entender por qué no había estado sintiendo
00:07:39potencialmente las enormes ganancias de productividad que la IA ha prometido; se trata de cambiar nuestra forma de
00:07:47trabajar. Así que, a lo largo de este proyecto piloto, entrevistaron a los equipos involucrados en él, así como a algunos de
00:07:55estos otros equipos del equipo de Bedrock Mantle y de Prime Video, y descubrieron cinco hábitos. Y uso
00:08:03la palabra hábitos muy específicamente, porque de nuevo, no se trata de hacer ese único sprint, sino de hacerlo día
00:08:09a día. Y lo que descubrieron al entrevistar a estos equipos fue que realmente eran hábitos que tenían que
00:08:15construir día a día. Cuando cambiamos nuestra forma de trabajar, es difícil crear estos hábitos y lleva tiempo desarrollarlos.
00:08:22Así que repasemos cada uno de ellos. El hábito número uno es invertir en el contexto del agente.
00:08:30Tenemos muchas cosas en la cabeza y tendemos a transferir todo eso que está en nuestra mente a otras personas
00:08:35a través de conversaciones de Slack, mediante la incorporación de mentores, revisiones de código
00:08:42y reuniones diarias de seguimiento (“stand-ups”) y planificación de sprints, y tuvieron que poner todo eso por escrito. Y el hábito que
00:08:50formaron fue que cada vez que el agente comete un error o hace algo de una manera diferente a como lo habrías hecho
00:08:55tú, te preguntas: ¿qué me falta en mis archivos de habilidades? ¿Qué me falta en mis archivos de directrices que el agente necesitaba?
00:09:01Pero como sabemos, a lo largo del año pasado vimos saltos agigantados en las capacidades y comportamientos de los modelos.
00:09:09Sonnet 3.7, a mitad del año pasado, tenía muchas peculiaridades para las que teníamos que incluir un montón de prohibiciones
00:09:16en nuestros archivos de directrices. Y ahora ya no tenemos que hacer tanto eso con Opus 4.5 desde noviembre pasado,
00:09:23y hemos tenido seis meses, más de seis meses de mejoras desde entonces, con todas las nuevas
00:09:29versiones de modelos que han salido desde ese momento. Por lo tanto, la nueva pregunta y el nuevo hábito es: ¿sigo
00:09:35necesitando esto en mis archivos de directrices? ¿O esto solo está sobrecargando el contexto? El segundo hábito es disminuir la velocidad para
00:09:41acelerar. En casi todos los equipos entrevistados, informaron que su productividad en realidad disminuyó
00:09:48al adoptar intencionalmente una nueva forma de trabajar. Eso es contrario a la intuición,
00:09:53¿verdad? Tienes que hacer un trabajo de ingeniería intencional antes de ver esa curva ascendente en forma de palo de hockey
00:09:59en la mejora de la productividad. Porque primero tenemos que hacer un trabajo real en nuestras bases de código
00:10:05para que los agentes tengan éxito en ellas, especialmente en bases de código existentes (“brownfield”). Así que tuvieron que
00:10:11desarrollar ese contexto para el agente, mejorar los mensajes de error de las herramientas existentes para que el modelo supiera
00:10:17qué estaba pasando cuando fallaba, y construyeron nuevas herramientas y nuevos servidores MCP para ayudar al modelo a lograr
00:10:24lo que necesitaba hacer. Muchos equipos terminaron reestructurando su base de código para que los agentes
00:10:29pudieran navegar por ella con mayor facilidad. E incluso he visto cambios drásticos como cambiar el lenguaje de programación
00:10:36de la base de código. A menudo he visto a equipos tener dificultades con Python o JavaScript porque son
00:10:43lenguajes sin tipado estricto. Son difíciles de probar. No hay errores de compilación. Así que el modelo adivina un poco y
00:10:50te lo devuelve. Por eso he visto a equipos pasarse a TypeScript. Rust se ha vuelto muy popular
00:10:56dentro de Amazon. El compilador ofrece excelentes mensajes de error. No tienes que hacer eso. Pero he visto a muchos
00:11:03equipos hacer esos cambios intencionales para obtener las ganancias de productividad que pueden ver.
00:11:09El tercer hábito es alimentar a los agentes, no hacer de niñera con ellos. Y para mí, este fue uno de esos momentos de revelación
00:11:16sobre por qué estamos viendo esta mejora escalonada en la productividad. Si estás haciendo “vibe coding”, si estás
00:11:23manteniendo una conversación de ida y vuelta con tu agente todo el día, por supuesto que no vas a ver
00:11:30mejoras de productividad de cuatro a cinco veces porque estás en el bucle todo el tiempo. Probablemente estés
00:11:36ahí sentado de 30 segundos a un minuto esperando a que genere código y te devuelva
00:11:42el código para revisarlo. Si te quedas sentado esperando, no puedes irte a hacer otras cosas.
00:11:48cosas. Es muy difícil ejecutar agentes en paralelo. Es muy difícil clonarte
00:11:55en múltiples agentes. Y por eso, si tus conversaciones se parecen un poco a las de la izquierda, estás
00:12:01cuidando a ese agente en lugar de hacer lo de la derecha, donde le das lo que necesita hacer y cómo
00:12:08puede autovalidarse. Y esa es realmente la clave para que los agentes puedan autocorregirse y volver a ti
00:12:14solo cuando alcancen cierto nivel de calidad, cuando realmente se ejecute, compile y pase las pruebas, cuando
00:12:20se pueda probar, cuando tenga una alta cobertura. Y por supuesto, el siguiente nivel es poner todo este
00:12:26contenido en tu archivo de directrices. Así lo hace siempre sin que tengas que pedírselo.
00:12:33El cuarto hábito es hacer explícita la intención. En Amazon, practicamos mucho el desarrollo guiado por especificaciones.
00:12:40Hemos integrado eso en el producto Kiro. Y por eso es muy natural que los ingenieros de Amazon lo adopten
00:12:46en Kiro. Lo que típicamente he visto con la codificación intuitiva en comparación con la ingeniería de vanguardia es dar
00:12:54una instrucción de muy alto nivel, dejar que el agente genere un montón de código y luego tener una conversación
00:13:02de ida y vuelta diciendo: Vaya, eso no es realmente lo que quería. No has entendido exactamente los requisitos.
00:13:10No, en realidad no quería construirlo así. Aquí hay un diseño técnico. Y encuentro que es menos productivo
00:13:17iterar con el agente sobre el código cuando la intención en sí era incorrecta. Así que a menudo los ingenieros de Amazon
00:13:26pasan por este proceso para características ambiguas y complejas de escribir la especificación.
00:13:34Y en Kiro, por supuesto, no tienes que escribir toda esta especificación, puedes hacer que el modelo la genere.
00:13:39Pero es mucho más fácil iterar con el modelo en una especie de conversación de ida y vuelta sobre un
00:13:46documento que sobre cambios de código repartidos en una base de código. El quinto hábito es desplazar las pruebas hacia la izquierda.
00:13:56Una de las claves aquí es darle al agente ese bucle de retroalimentación rápida, porque eso es lo que le permite trabajar durante horas
00:14:04seguidas y autocorregirse. El agente va a cometer errores, y eso está bien. Pero si le das las señales correctas, puede
00:14:12autocorregirse y pasar un buen rato haciéndolo. Así que he visto equipos añadiendo linters, pruebas unitarias,
00:14:20pruebas de integración, pruebas de rendimiento, pruebas de seguridad. Estas son cosas que todos sabemos que deberíamos
00:14:24haber estado haciendo todo este tiempo. Esto es buena higiene y prácticas de ingeniería. Pero ahora el retorno de inversión es, creo, finalmente
00:14:32lo suficientemente alto como para que realmente invirtamos en ello. Algo que he estado viendo hacer a muchos equipos es simular
00:14:40servicios. A menudo, con las pruebas de integración, probábamos de extremo a extremo un sistema entero, incluyendo servicios
00:14:46en vivo. Pero hemos estado invirtiendo mucho en servicios simulados que se ejecutan completamente en local con respuestas
00:14:52deterministas, porque le permite al agente hacer todo de forma local. Hacer todo en tu ordenador portátil sin
00:15:01tener que iniciar un montón de otros servicios y conectarte a servicios en la nube hace que todo sea mucho más rápido.
00:15:07Porque cuanto más pueda obtener el agente una retroalimentación rápida, significa más bucles que
00:15:14puede realizar y más productivo puede ser tu propio agente. Así que, en resumen, estos son algunos de los
00:15:21hábitos que hemos visto. Pero por supuesto, me faltaría a la verdad si te dijera que si adoptas todos estos hábitos,
00:15:28alcanzarás el nirvana, serás la organización de ingeniería más productiva que el mundo haya
00:15:35visto jamás. Las cosas siguen siendo difíciles. Todavía estamos en una fase de adopción temprana y los equipos siguen
00:15:42descubriéndolo. Así que algo que hemos estado viendo en nuestros equipos a nivel organizacional es el riesgo de
00:15:48agotamiento. No acuñé este término, olvido quién lo hizo en qué conferencia, pero el FOMAT es real. Hemos visto a
00:15:56ingenieros quedarse hasta tarde en la noche, intentando conseguir esa instrucción perfecta que hará que su
00:16:03agente funcione durante horas por la noche para despertarse por la mañana con un cambio de código listo. La carga cognitiva
00:16:09aumenta a medida que ejecutas estos múltiples agentes en paralelo, cambias constantemente entre
00:16:15pestañas de la terminal. Y luego vemos que revisar los resultados de la IA suele ser más difícil para algunos que
00:16:22escribirlo realmente, especialmente al principio de su carrera. Los ingenieros sénior ya han pasado una gran parte de su
00:16:29carrera revisando el código de otros. Pero los ingenieros al inicio de su carrera aún no tienen ese músculo. Por lo que revisar
00:16:37puede suponer mucha más carga cognitiva de a la que están acostumbrados al escribirlo realmente. El otro
00:16:44aspecto es el cambio organizacional. Así que ya es difícil cambiar la forma en que trabajamos como ingenieros. La forma en que
00:16:52pasamos todo nuestro día cambia por completo cuando somos ingenieros de vanguardia. Pero también las organizaciones tienen que
00:16:58cambiar para permitir equipos de ingeniería de vanguardia. Uno que he visto muy comúnmente es aceptar ir más despacio
00:17:07para ir más rápido. Y yo mismo he sido culpable de esto. Mis compañeros líderes han sido culpables de esto al decir,
00:17:14bueno, ahora tienes las herramientas de IA y los modelos son tan increíbles ahora. ¿Por qué no vas más rápido?
00:17:22Y eso se debe a que tienes que tomarte esos dos meses para invertir en tu base de código para averiguar las mejores
00:17:29prácticas para tu equipo, para hacer cambios de hábitos difíciles en tu equipo. Y si estás esperando constantemente
00:17:38entregar funcionalidades cada mes, porque ahora tenemos estos modelos increíbles, y estamos viendo
00:17:44a todas estas empresas en X diciendo cómo lanzan 20 solicitudes de extracción al día, tenemos que frenar para acelerar.
00:17:54El segundo es ir demasiado amplio en la organización demasiado rápido. Pienso que si hubiéramos
00:18:01esperado que todos los equipos en organizaciones masivas fueran equipos de vanguardia inmediatamente, no habríamos tenido
00:18:08los aprendizajes que obtuvimos del pionero, del experimento de sprints, de los equipos piloto
00:18:16dentro de Amazon. Y ahora el desafío para nosotros es cómo lo ampliamos. Y de eso se trata 2026.
00:18:22Para Amazon es cómo ampliamos esto a más y más equipos, a los próximos 2000 equipos en lugar de 50 equipos.
00:18:31Y por eso creo que cuando lo implementas demasiado rápido, tienes muchos equipos que no saben lo que
00:18:37están haciendo. No has tenido tiempo de encontrar las mejores prácticas para tus propias organizaciones, el contexto
00:18:43que tu organización necesita. Y el último es que vas a encontrar nuevos cuellos de botella.
00:18:49Anteriormente, escribir código manualmente era el cuello de botella. Encuentro que dentro de Amazon, hemos descubierto
00:18:58que la velocidad de toma de decisiones se convierte en un nuevo cuello de botella. Cuanto más pasas revisando la decisión de
00:19:05construir un nuevo producto realmente, más lento es construir el producto ahora, porque el código solo toma de uno a dos meses en escribirse.
00:19:12Todos los procesos de revisión asociados con el lanzamiento de un producto se convierten en el cuello de botella.
00:19:20Cuando solía tomar de nueve a doce meses construir un nuevo producto, no importaba tanto en el balance
00:19:27general de las cosas. Si tomaba dos meses tomar la decisión de construir el producto y luego dos meses en
00:19:33aprobar el lanzamiento. Pero ahora esos son los cuellos de botella. Esos son los procesos más largos. Y así encuentras que todas
00:19:40estas cosas te frenan. A menudo encuentro que los equipos de ingeniería de vanguardia pasan más tiempo
00:19:48tomando decisiones que escribiendo código. Y por eso, cuanto más puedas tomar decisiones rápidas, especialmente aquellas
00:19:54que son fáciles de revertir, mejor. Así que mi gran conclusión para todos aquí es que la ingeniería
00:20:03de vanguardia trata de cambiar intencionalmente la forma en que trabajas. Y eso es difícil. Eso toma tiempo.
00:20:10Consiste en formar nuevos hábitos y una nueva forma de trabajar. Y eso se aplica a cualquier equipo de ingeniería, así como a tu
00:20:18organización. Así que te animo a pensar en cómo estás interactuando con las herramientas de IA y cómo eso puede
00:20:27cambiar para liberarte de estar en el ciclo. Gracias. Me quedaré un poco por aquí si alguien tiene
00:20:34preguntas al fondo. Pero gracias por el tiempo de hoy.