Programación con agentes: Mesa redonda con líderes de la industria

Hola.

Esta semana, o en estos últimos dos días, escuchaste a muchos Googlers de Android.

Por eso, pensamos que sería genial cerrar la conferencia escuchando a algunas personas de afuera, de la comunidad, de la comunidad de desarrolladores de Android.

Hablaremos sobre la programación con agentes y su impacto en el mundo real.

Comenzaremos por presentarnos.

Mi nombre es Ben, de Relaciones con Desarrolladores de Android.

Ya me escucharon una vez en esta conferencia, pero sigamos con el panel.

Hola.

Me llamo Vinay y apoyo las iniciativas de herramientas de IA en Databricks.

Me alegra mucho estar aquí.

Hola, soy Luis Artola.

Trabajo para Google Maps.

Dirijo equipos que usan la IA para crear experiencias de agentes y mejorar el ciclo de desarrollo de software.

Hola, soy Annyce Davis.

Trabajo en Ford.

Dirijo algunos equipos de ingeniería que desarrollan nuestros productos de suscripciones y lealtad.

Hola.

Soy Ty Smith.

Trabajo en Uber brindando asistencia a nuestros desarrolladores.

Esa es una tendencia que se observa en los dispositivos móviles desde hace mucho tiempo.

En los últimos años, nos enfocamos mucho en este nuevo y emocionante momento en el que nos encontramos con las herramientas de IA.

Hola.

Soy Kaushik Gopal.

Trabajo como ingeniero principal en Instacart y, por casualidad, comencé este podcast sobre el desarrollo de Android llamado Fragmented.

En estos días, como dijo Ty, cambiamos un poco las estrategias y, como saben, hablamos sobre el desarrollo de la IA.

Bien.

Tenemos 30 minutos.

Creo que el tiempo pasará volando, así que iremos directo a las preguntas difíciles.

En Android DevRel, siempre dijimos que queríamos que fuera más rápido y fácil compilar apps.

Ahora que llegó la IA, nos escuchaste decir: "De hecho, lo es.

Creemos que es más rápido y fácil compilar apps".

Pero quiero plantear lo siguiente: ¿realmente estamos lanzando apps más rápido o solo estamos generando un montón de código que no lleva a ninguna parte?

Vamos, Vinay.

Bien.

Sí, todos nos miramos entre nosotros.

Fantástico.

Entonces, si solo miramos los números puros, definitivamente vemos que el resultado en términos de PR, en términos de líneas de código, hemos visto una aceleración masiva y, como resultado, también estamos enfrentando desafíos de escalamiento cuando se trata de cosas como dónde almacenamos nuestro código, ¿verdad?

Por lo tanto, esa aceleración es muy real.

Lo que no es obvio es cómo afecta los resultados, y creo que toda la industria está tratando de descubrir cuál es la métrica correcta en torno a los resultados, cómo saber cómo afecta el resultado final.

Pero definitivamente lo veo en acción.

Creo que enviamos más código en los últimos seis meses que en el período anterior, y, de nuevo, mantendré esto ambiguo, pero como un período muy largo.

Y, como resultado, creo que nuestra estrategia cambió en cuanto a cómo medir la productividad, ¿verdad?

Porque hay varias formas de pensarlo.

Estamos tratando de averiguar cómo aumentar la mediana, ¿verdad?

Porque cuando observas los valores atípicos y la mediana, hay una diferencia de 5 a 10 veces entre esas dos categorías de personas, y nuestro enfoque es elevar el piso, elevar la mediana y hacer que esas personas sean tan productivas como sus pares que vemos que son tan productivos.

Vemos una combinación de roles.

Algunas personas se mueven mucho más rápido.

Hay personas que tienen cien PR al día y que están haciendo un trabajo increíble.

Pero ese es un tipo de espacio en el que operan.

Tal vez sea más nuevo o estén más familiarizados con las herramientas.

También vemos personas que están mucho más, ya sabes, en el trabajo de brownfield o de plataforma, y están apoyando un tipo de trabajo diferente que tal vez no sea tan acelerado porque tienen que pasar más tiempo con un juicio humano y asegurarse de que las cosas no se rompan.

Y la combinación de estos dos, ya sabes, es significativamente más rápida que antes, pero creo que el tema realmente interesante para nosotros es que, aunque estamos enviando más, ¿la empresa realmente está enviando más a los usuarios finales?

Esa es un área en la que invertimos durante el último año para comprender realmente si estamos lanzando funciones más rápido, no solo código.

Los primeros indicios dicen que sí, pero el panorama es muy diferente al de las relaciones públicas puras.

Creo que lo que ha sucedido es que, claramente, las personas están enviando mucho más, ya sabes, el número de PRs, los recuentos han aumentado.

Pero creo que, incluso en este momento, gran parte del pensamiento es: "¿Cómo tomamos la IA y este tipo de herramienta que tenemos y potenciamos los procesos existentes?".

¿Cierto?

Por ejemplo, gran parte de cómo solíamos enviar código antes se siente como si siempre hubiéramos pensado en un humano como alguien que guiaría todo esto hasta la producción.

Pero creo que lo que estamos viendo ahora es que, sí, eso funciona.

Estamos enviando más.

Pero nos encontramos con todos los cuellos de botella que, de otro modo, no habríamos visto en un mundo anterior, ¿verdad?

Porque nunca antes tuvimos esos problemas, pero ahora, estamos acelerando una parte de, ya sabes, un ciclo de varios pasos, y creo que ahí es donde se pone interesante, que es como, "Está bien.

Estamos entregando más, pero ahora es como una manguera de efectos".

Por lo tanto, nos encontramos con otros desafíos.

Ese es un punto muy interesante, ¿verdad?, porque, cuando lo piensas, hay muchos pasos diferentes, pero, desde una perspectiva de alto nivel, puedes agruparlos en tres etapas, ¿verdad?

Está la programación, que claramente se está acelerando.

La preparación para publicar en producción incluye varios aspectos, como los legales y de privacidad, y otros que te permiten lanzar un producto. Luego, viene el lanzamiento, ¿verdad?

Y, luego, el envío realmente significa cosas diferentes según dónde te encuentres, ¿verdad?

Si eres como un producto completamente del lado del servidor, probablemente el envío signifique un proceso más optimizado, mientras que cuando envías algo que va al consumidor, ¿verdad?, como ponerlo en experimentación, es como la mitad de un recorrido, ¿verdad?

Aún tienes que experimentar y medir mucho, y ahí es donde se relaciona con lo que decías: se siente como si estuvieras en un área metropolitana, en una autopista, y tienes un punto crítico, y luego comienzas a acelerar y dices: "Sí, genial.

Voy muy rápido", pero ahora llegas al siguiente punto crítico.

Y lo que la IA está haciendo muy evidente es que se ven los puntos de fricción con más claridad, y algunos de ellos no tienen nada que ver con la programación o la tecnología.

Tiene que ver con los procesos y las personas, y cómo se optimiza eso con la IA.

Ese es un desafío muy interesante sobre cómo optimizar de extremo a extremo.

Una forma interesante en la que estamos pensando un poco en el espacio es cuánta autonomía tiene la persona o el equipo para enviarlo por completo.

Si miramos hacia adentro, hay muchos equipos que tal vez están creando herramientas internas o cosas que no se envían al cliente.

Están enviando mucho más rápido, ¿verdad?

Tienen total libertad para hacer llegar esa información a sus clientes de inmediato.

Si tienes un producto externo que aún debe pasar por la experimentación con un usuario o, ya sabes, los tiempos de lanzamiento en la tienda de aplicaciones o, ya sabes, trabajar con el diseño y el producto, todos estos otros cuellos de botella se van sumando, y las personas que escriben el código tienen mucha menos capacidad para avanzar rápido en eso.

Por lo tanto, solo están llegando al resto de los cuellos de botella del sistema.

Por lo tanto, creo que dividir esos procesos en dos áreas diferentes realmente destaca dónde se podrían mejorar los procesos de tu empresa.

Sí, estoy de acuerdo y, sinceramente, creo que la ingeniería nunca fue el cuello de botella.

Llevo años diciendo esto.

La ingeniería tiene una forma muy estructurada de hacer las cosas, y siempre se trataba de la empresa: "¿Cuál es el problema?"

Obtendrás 10 respuestas diferentes.

Y luego, "Bien.

Ahora, traduzcamos eso a algunas soluciones con el producto.

Ahora, pensemos en eso por un momento.

Oh, tal vez hablemos un poco con diseño.

Patea la pelota hacia allá".

Cuando llega a ingeniería, ya sabemos más o menos lo que tenemos que hacer.

Luego, intentamos ir a Stack Overflow, copiar y pegar algunas cosas, y lanzar el producto.

Por lo tanto, con la IA, donde veo las mayores aceleraciones es en el trabajo de cumplimiento.

Esas cosas en las que siempre quisimos modernizar XYZ o siempre quisimos actualizar rápidamente la versión de Spring Boot.

Lo estamos haciendo muy rápido.

Pero en cuanto a la entrega de funciones, no puedo decir que haya visto una mejora significativa.

Todos ustedes mencionaron que tal vez el cuello de botella se haya movido y que se están encontrando con estos procesos que antes no eran realmente el cuello de botella, pero que ahora sí lo son.

Sin embargo, es probable que esos procesos se hayan originado a partir de lecciones difíciles aprendidas en el pasado, ¿verdad?

¿Sientes la presión de cambiar esos procesos? Creo que el más obvio es la revisión de código.

¿Cuál creemos que es el futuro de la revisión de código?

¿Qué estamos haciendo actualmente?

Así que me encantaría escucharte.

Esto se relaciona con el punto que mencioné antes.

Creo que muchos de estos cuellos de botella se deben a que pensamos en, por ejemplo, si tuvieras una varita mágica, por así decirlo, y pudieras reinventar la ingeniería de software, y tuvieras la IA hoy, ¿usaríamos muchas de las mismas cosas? ¿Haríamos lo mismo?

Por ejemplo, la revisión de código se hacía porque necesitábamos que un humano aprobara las cosas, ya sabes, que hiciera esa verificación final.

Creo que eso también está cambiando, como, ya sabes, la forma en que pensamos en las revisiones de código ahora es, tal vez deberíamos estar abiertos a la idea de que, ya sabes, si estás refactorizando el nombre, o estás tratando de refactorizar el código, y sabes que tienes grandes pruebas, que todo el mundo claramente tiene.

Tenemos la IA para escribirlos, no hay problema.

No, como tal vez, ya sabes, ¿vas a hacer un trabajo mucho mejor que ese agente?

No lo sé, tal vez no dediques tiempo a revisar eso.

Por otra parte, si vas a enviar un error y, ya sabes, recibes una llamada de tu director general que básicamente dice: "Oye, esto nos está costando X cantidad de dólares", tal vez identifiques áreas y sistemas en los que, "Oye, esta es un área crítica.

Esta no es un área crítica" y, luego, intenta volver a imaginar.

No creo que así sea como operamos hoy, ¿verdad?

Hoy en día, es como: "Oye, hay una solicitud de extracción.

Soy el ingeniero.

Me enfoco en esto.

Va a subir.

Le pido a Vinay que revise el código en medio de la noche, porque solo quiero que se fusione".

En cambio, tal vez deberíamos replantearnos muchas de ellas.

Estoy totalmente de acuerdo y creo que la revisión de código es un problema de verificación. Con esto me refiero a que, en un mundo en el que tengo plena confianza en mi capacidad para verificar algo, ¿seguiría revisando el código del 100% de mis PR?

Probablemente no, ¿verdad?

Por lo tanto, las revisiones de código tienen dos propósitos.

Una es, obviamente, verificar que estamos haciendo lo correcto, y la segunda es la educación, ¿verdad?

Por ejemplo, que las personas que te rodean sepan lo que estás haciendo y si están de acuerdo o no con esa decisión.

Por lo tanto, definitivamente hay una categoría de trabajo que deberíamos sentirnos cómodos acelerando y asegurándonos de que llegue al código y, incluso, a las versiones.

Ahora bien, es posible que esto no se aplique al 100% de los casos, pero creo que es un número muy alto, de dos dígitos, al que debería aplicarse.

Creo que nos estamos preparando para realizar esos cambios y, como comunidad, todos debemos asegurarnos de que nuestros sistemas estén listos para eso, porque se acerca.

No hay forma de evitarlo.

La parte superior del embudo es muy amplia y tiene varias plataformas que te permiten crear más relaciones públicas.

Y eres tan rápido como el paso más lento del proceso.

Para muchos equipos, eso son las revisiones de código, y los equipos que avanzan más rápido, sinceramente, han descubierto y aceptado esta realidad.

Sí, y si somos honestos con nosotros mismos, diría que el 70% de las PR que vi me parecen bien.

Si buscáramos en todas las bases de código del mundo, los comentarios de las solicitudes de extracción serían "me parece bien", LGTM, en todos lados.

En parte, como profesionales de la ingeniería, a veces nos damos más crédito del que merecemos.

Realmente creemos que estamos allí.

"¿Usaron el patrón de comando?"

No, solo decimos: "Está bien.

Sí, me parece bien".

Entonces, ¿por qué no puedo hacer que un agente haga eso?

Creo que ese es el futuro que veremos, en el que se definirá qué es lo que se ve bien, cuáles son las características y cuáles son los comportamientos que te hicieron sentir de esa manera.

Y, luego, asegurémonos de que el agente busque lo mismo.

O, por otro lado, también intenta pensar en diferentes formas de revisar, ¿verdad?

Por ejemplo, conozco a personas que están en Twitter estos días y dicen esto, ¿verdad?

Por ejemplo, cuando verificas una solicitud de extracción, puedes pedirles a tus agentes que la visualicen de otra manera, ¿no?

Oye, muéstrame un antes.

Muéstrame un después.

Muéstrame las pruebas que escribiste en lugar de revisar el código línea por línea.

Pero sí desafía… ¿Ibas a decir algo, Luis?

No, creo que es algo que invita a la reflexión, ¿no?

De esa manera, llegaremos a un punto en el que te sientas realmente cómodo permitiendo que las CL o las PR se aprueben sin intervención humana.

Voy a hacer un poco de abogado del diablo y quiero decir que, cuando hablamos de fricción, creo que hay una tendencia a pensar que la fricción es mala, pero hay fricción buena y mala.

Y creo que las opiniones siguen estando en la categoría de fricción positiva.

Se trata de cómo podemos hacer que sea menos oneroso para los desarrolladores, ¿verdad?

Y, a veces, no se trata de cómo hacemos que esa revisión, en ese momento, sea mejor o más eficiente.

¿Cómo puedes hacer que el desarrollo sea más preciso con la IA?

Porque, según cómo uses la IA, las entradas de buena calidad producen mejores resultados, pero las de mala calidad producen resultados realmente deficientes, ¿verdad?

Por lo tanto, creo que para llegar a ese estado final atractivo, debe haber una mejora integral del proceso con la IA desde el principio, usando la IA para comprender mejor la arquitectura, para tener especificaciones realmente sólidas con menos esfuerzo de los desarrolladores, de modo que el código que produzca sea de mayor calidad.

Por lo tanto, las revisiones son menos problemáticas para los desarrolladores.

Creo que el estado final de esto, que no sería tan controversial, es que la mayoría de las personas ven que todo este código se implementará sin revisión humana en algún momento.

Creo que, mientras tanto, estamos en esta situación en evolución en la que los modelos están mejorando y nos preocupa menos que cometan un error técnico y más que cometan un error comercial o que el problema sea el juicio o la ideación que se incluyó en él.

Por lo tanto, eso también se incluye en la señal, por lo que deberías separarlo durante la etapa de revisión.

Por ejemplo, ¿deberíamos hacer una revisión línea por línea en la solicitud de extracción en lugar de revisar la intención que, ya sabes, intentan impulsar después?

Estamos pensando en esto de diferentes maneras.

Una es cómo podemos brindar información más relevante al usuario para que pueda comenzar a priorizarla.

La otra es cuáles son esas áreas más seguras en las que podemos experimentar y avanzar más rápido en este tipo de programas.

Como decía Kaushik, no todas las áreas necesitan la misma cantidad de rigor.

Podemos identificar esto y empezar a dejar que algunas cosas vayan más rápido, reducir el riesgo y, al mismo tiempo, mantener, ya sabes, las áreas que están más orientadas al cumplimiento o, ya sabes, que son muy fundamentales con la mayor fricción hasta que realmente lleguemos a ese punto de confiar no solo en los modelos, sino en las entradas que se introducen en ellos

fueron las decisiones correctas.

Como refactorizar un nuevo módulo de Android en la app de Uber, tal vez esté bien.

Ofrecer viajes gratis a todos los desarrolladores de Android, probablemente quieras revisar ese código.

Tendré que consultar eso con nuestro director general.

Lo siento, Kaushik.

Pero también creo que este es un problema resuelto.

Ya tenemos marcas de funciones similares.

Ya tenemos una implementación azul-verde.

Ya tenemos muchas de las piezas.

El desafío es que hemos estado demasiado ocupados para hacerlo.

Ya tenemos un seguimiento del comportamiento.

Tenemos todos estos tipos de datos, pero están en todos estos sistemas diferentes.

Ya hacemos un seguimiento de los incidentes.

Tenemos muchísimos datos, pero reunirlos todos en un seguimiento integral es la pieza que falta.

Una vez que finalmente descubramos cómo es ese tipo de servicio de contexto de ingeniería en todas estas empresas diferentes, ya no tendremos que preocuparnos porque, incluso si la solicitud de extracción se combina, es segura.

Porque sabemos que tenemos eso detrás de un indicador de función.

Tenemos la implementación azul-verde.

Tenemos toda la observabilidad implementada.

Y luego puedes sentirte con mucha confianza para decir: "Oh, ponlo en la canalización".

Si algo malo sucede, tenemos todas estas protecciones y puertas de enlace en el camino.

Creo que la velocidad para responder también es muy importante, ¿no?

Si, por ejemplo, hablemos de Android por un minuto, si estás implementando un cambio en Android y eso debe enviarse a través de Play Store y, luego, implementarse para tus consumidores, tu capacidad de aplicar un hotfix de inmediato se ve realmente inhibida en comparación con si estás haciendo algo que tiene una implementación interna con observabilidad interna y un agente que está en ella de inmediato, tienes muchas más oportunidades de avanzar más rápido allí.

Una de las preguntas que tenía para ustedes es que también existe el problema de que hay trabajo que se debe hacer en estas apps, pero luego tienes estas apps nuevas que son más fáciles, luego tienes estas apps existentes y, luego, hay un momento en el que necesitas tiempo para realizar muchas de estas verificaciones, ya sabes, para que puedas proliferar el uso de la IA.

Sé que muchos de ustedes trabajan en apps masivas, ¿verdad?

Por lo tanto, me gustaría saber qué piensas al respecto.

¿Es como, oye, CEO, dame 3 meses, déjame preparar esta app para la IA, o, ya sabes, como agregarla todos los días?

Sí.

De todos modos, nunca lo hacen.

No lo creo.

Es decir, la mayoría de las empresas nunca tendrán ese lujo.

Creo que solo tenemos que dedicarle el mismo tiempo que solíamos dedicarle a la deuda técnica, como, por ejemplo, usar el 20% de tu tiempo para esto, es como usar el 5% de eso para mejorar una instrucción.

Y, luego, incluso comprender qué hace la instrucción y mejorar el contexto.

Como ya lo mencionamos, creo que gran parte del problema es que los ingenieros aún no entienden cómo funciona.

Aún se siente como algo mágico y místico, por lo que no lo configuran ni lo ajustan de la manera en que podrían obtener un mejor valor y eficiencia.

Por lo tanto, creo que debe haber un punto en el que los líderes digan: "¿Qué debemos hacer para subir de nivel a nuestro equipo para que puedan comprender cómo funciona esto y, luego, podamos obtener más?".

También es una continuidad de ella.

Como está cambiando tan rápido, si, ya sabes, le hubiera pedido a un equipo que dedicara una semana ahora mismo a aprender lo último y lo mejor, y que lo pusiera en práctica, y luego no tuvieran tiempo para seguir aprendiendo o experimentando, y nos reuniéramos el año que viene, estarían muy atrasados con respecto a las nuevas capacidades.

Por lo tanto, es necesario que todo esto, ya sabes, es como si estuviéramos construyendo el avión mientras lo volamos, donde estamos poniendo las barreras de seguridad, y estamos aprendiendo, y nos estamos ajustando a medida que suceden las cosas, y los equipos deben estar al tanto de esto.

Y en las organizaciones grandes, hay equipos como algunos de los nuestros que intentan sintetizar parte de esa información y hacerla, ya sabes, un poco más comprensible y digerible.

Pero es un desafío para todos en la industria en este momento.

Me gustaría cambiar un poco la dinámica.

Muchos de ustedes trabajan en infraestructura para desarrolladores.

Miles de PR, ¿tu infraestructura de pruebas, tus servidores, todo se está derritiendo?

Y me encantaría escuchar algunas historias de batalla.

¿Ty?

Sí.

Están en llamas.

Mi CI llora para s- llora mis llora me para dormir todas las noches.

En este momento, casi todos nuestros equipos de infraestructura para desarrolladores están lidiando con problemas de escalamiento en el procesamiento y problemas de eficiencia.

Hay, ya sabes, códigos rojos en curso.

Observan este enorme aumento en el volumen.

Estamos realizando cambios de arquitectura con los agentes.

Intentamos hacer cosas como expandir lo más rápido posible nuestra ejecución de compilación remota y el almacenamiento en caché con Bazel, analizando cosas como, ya sabes, cómo todo el main debe estar en verde en todo momento, o si podemos empezar a corregir con agentes en ciertas áreas, analizando el volumen que llega de los ingenieros, intentando hacer cosas como CI de autorreparación, o como ciclos de reacción más bajos, y todos los equipos están invirtiendo activamente en todo esto para intentar mantener el ritmo del crecimiento y, al mismo tiempo, mantener un cierto nivel de eficiencia.

Pero es extremadamente difícil.

Sí, estoy de acuerdo con todo lo que acaba de decir Ty, pero creo que también nos obliga a reflexionar y a preguntarnos con sinceridad si estamos listos para multiplicar por 10 nuestro crecimiento a partir de este momento.

Para la mayoría de las personas, la respuesta probablemente sea no.

Por lo tanto, cuando pensamos en el futuro, intentamos de forma intencional que nuestra ambición coincida con la escala que la infraestructura puede admitir.

Y una cosa que ha hecho la IA es que nos ha hecho a todos más ambiciosos porque ya hemos visto ese salto significativo, por lo que, sinceramente, estamos replanteando nuestros sistemas.

Correcto, pensamos en qué otro sistema se va a romper, o anticipamos que se va a romper, y qué podemos hacer para adelantarnos y que no sea una sorpresa.

En realidad, intentamos evitar sorpresas.

Correcto, mientras sintamos que tenemos el control, todos estamos contentos.

En el momento en que nos encontramos con una sorpresa, sé que son malas noticias para todos.

¿Cierto?

Por lo tanto, este es un buen momento para reflexionar, mirar hacia atrás, auditar y descubrir qué se va a romper a continuación, porque va a suceder.

Es inevitable.

Solo queremos adelantarnos a eso.

Escuché una cita interesante del director general de Inflow.

Ella describía que este es el cronograma que le tomó a Google llegar a las, no sé, miles de millones de líneas de código que tienen ahora y, ya sabes, tomó unos 20 años, y con la aceleración de esto, muchas de nuestras empresas van a estar buscando una escala similar en solo unos pocos años, según la aceleración de la IA.

No creo que todas las empresas estén listas para tener una infraestructura de desarrollo como la de Google.

Bueno, en relación con ese tema, ¿sus empresas implementan algún tipo de límite de inversión?

Por ejemplo, ¿cómo se gestiona que algunos desarrolladores consuman tokens para todo ahora, ya sabes, usando el mejor modelo posible todo el tiempo?

¿Hay alguna estrategia que hayas encontrado o es mejor dejarlos libres porque la experimentación lleva a buenos resultados?

Diría que el año pasado fue el año de la experimentación.

Haz todo lo que quieras.

Y tal vez incluso la primera mitad de este año fue solo usarlo de manera razonable.

Y ahora, desde septiembre, tenemos límites de tokens.

Por lo tanto, tenemos límites para los desarrolladores en cuanto al uso de tokens.

Y, luego, tenemos instrumentaciones para que puedan entender si están teniendo sesiones buenas y saludables.

¿Qué significa tener una sesión saludable?

¿Tienes esta cantidad de turnos por sesión?

¿Qué es un turno?

Por lo tanto, realmente intentamos usar las herramientas para educar a los desarrolladores.

Creo que ese es solo el primer paso.

Ya sabes, tienes que saber que tienes un problema antes de poder solucionarlo.

Y, por lo tanto, que al menos vean esto no es gratis.

Antes, realmente parecía que la IA era gratuita.

Y las personas simplemente lo usaban.

Me gustaría que dijera: "Cambia mi rama", ya sabes, como: "Oh, no hay problema, Annyce, cambiaré esa rama por ti, USD 5", ¿verdad?

Ahora, llegamos al punto en el que pensamos: "Bueno, podría ir a la línea de comandos y hacerlo yo, ¿no?".

Por lo tanto, creo que vamos a empezar a educar a los ingenieros sobre el costo real.

Más bien, no crearía instancias de ECS y luego me desentendería de ellas.

Tal vez cuando AWS apareció por primera vez, pensamos: "Sí, puedo gastar mi propia instancia".

Y le estábamos costando mucho dinero a la empresa.

Creo que ahora mismo está sucediendo lo mismo con los tokens.

Creo que los límites prácticos también presentan oportunidades muy interesantes, ¿verdad?

Porque, si piensas en cómo empezamos a usar los LLM, les dábamos todo, ¿verdad?

Inspeccionaban el código, descubrían cosas y hacían magia por ti, ¿verdad?

Pero eso tuvo un costo.

Y, de hecho, la industria se está dando cuenta de eso.

Y eso, en realidad, obliga a los desarrolladores y a las organizaciones a pensar en cómo optimizarlo, ¿verdad?

Por ejemplo, te daré un ejemplo concreto: si tienes un generador que produce componentes de interfaz de usuario y estos deben cumplir con una estructura específica, pruebas de unidades y cosas por el estilo, ¿por qué harías que los modelos generen eso sobre la marcha si puedes hacer que generen una herramienta determinista que pueda crear eso por ti?

Por lo tanto, hay muchas oportunidades para usar los límites de tokens y el uso a tu favor, y, de hecho, volverte más eficaz.

Sí, y en relación con esos temas, definitivamente introdujimos límites, al menos, como sabes, en Instacart.

Pero creo que el objetivo no es necesariamente limitar cuánto usas la IA, sino aportar algún tipo de higiene o, como dices, introspección, ¿verdad?

Por ejemplo, cuándo deberías usar ciertos modelos en lugar de otros.

Sabes, probablemente no necesites como Fable o Astra para que te digan la hora o cambien una rama de Git.

¿Cierto?

Probablemente puedas, ya sabes, dedicar un tiempo a escribir una secuencia de comandos y que sea gratuita para siempre.

No se desperdiciaron tokens allí.

¿Cierto?

Por lo tanto, creo que si puedes agregar algún tipo de restricción, no es necesario que limites el uso, sino que te ayude a pensar más allá de simplemente arrojarle todo.

¿Cierto?

Me gusta lo que dijiste, el año pasado se sintió como el año de la experimentación.

Este año, la pregunta es cómo usar esta tecnología de manera eficaz.

Sí.

También nos sentimos muy identificados con las historias que se cuentan aquí.

Especialmente, pasar de una mayor experimentación a, ya sabes, un conjunto equilibrado de eficiencia y responsabilidad.

Esto proviene de una variedad de inversiones.

Hay aspectos como la educación para los desarrolladores y la visibilidad.

Como mencionó Annyce, con el costo y la información de la sesión activa.

Inversiones en valores predeterminados seguros que, ya sabes, ayudan a evitar interacciones innecesarias, asegurándose de que las habilidades que usan sean eficientes para buscar regresiones y cosas por el estilo.

Y darles responsabilidad sobre el costo que están gastando.

Por lo tanto, tenemos límites de tokens.

Y cuando un desarrollador alcanza esos límites, puede, ya sabes, hacer clic en un botón y agregar una justificación, y su administrador puede aprobarla.

Por lo tanto, si se está haciendo un gran trabajo, queremos que lo revisen.

Pero, ya sabes, si tal vez están haciendo algo más derrochador o experimental, no podrían justificar ante su gerente por qué, ya sabes, por qué deberían gastar dinero en eso, entonces también les ayuda a mantener eso bajo control.

Y eso no solo implica no hacer el trabajo, sino también mirar y preguntarse si es la elección correcta del modelo.

¿Es el peso correcto?

Como es evidente, el costo de estos tokens comenzó a disminuir debido a la presión competitiva.

Pero, en general, que nuestros ingenieros piensen en ello como buenos administradores del dinero que les damos es, creo, el enfoque saludable correcto en este momento.

Y, a largo plazo, poder quitarles esa decisión por completo.

¿Cierto?

Quieres un enrutamiento a modelos automático y cosas por el estilo, para que nunca tengan que pensar en eso.

Mientras tanto, este es un estado saludable.

Sí.

Creo que gran parte de nuestro enfoque se ha centrado en hacer cosas como el enrutador de modelos para que quitemos esa decisión al desarrollador y tratemos de asignarla al modelo correcto, asignar la tarea al modelo.

Pero también se trata de tener los activadores adecuados.

Por lo tanto, pensamos en los límites de tokens de varias maneras.

Nunca queremos bloquear al desarrollador.

Sin embargo, queremos asegurarnos de que haya momentos en los que podamos detenernos un segundo y asegurarnos de que se invierta en las áreas correctas y de la manera adecuada.

Por ejemplo, hay límites diarios que funcionan como un mecanismo de seguridad que un desarrollador puede desbloquear por su cuenta.

Solo tienen que ir al portal, hacer clic en un botón y decir: "Oye, no pasó nada sorprendente.

Tengo el control".

¿Cierto?

Y esa es solo una palanca simple porque todos están haciendo bucles y estos bucles pueden ejecutarse durante la noche y no queremos que esto genere un costo.

Por lo tanto, esto es muy razonable.

Por otro lado, también queremos asegurarnos de que nuestros desarrolladores tengan los mejores modelos disponibles.

Sin embargo, para esa categoría de modelos, creamos un presupuesto de frontera.

Por lo tanto, hay un presupuesto mensual establecido.

Es lo suficientemente alto.

No se te bloqueó.

Si necesitas que se te desbloquee, hay un proceso de excepción.

Se envía a tu administrador.

Es un momento en el que describes lo que estás haciendo.

Y no somos quienes toman las decisiones como equipo de plataforma, porque esas decisiones deben tomarse cerca de donde se realiza el trabajo.

En cuanto al uso del modelo de frontera, nuevamente, te brindamos flexibilidad total con un límite.

Y la razón por la que funciona es que, en última instancia, esto aporta previsibilidad al proceso.

¿Cierto?

Queremos asegurarnos de que, cuando presupuestemos nuestro gasto de tokens, y esto es un desafío para todos, hayamos tenido en cuenta lo que planeamos, y estos controles nos permiten hacerlo.

¿Sabes qué me parece fascinante de estas conversaciones?

Creo que es porque todos trabajamos en empresas.

Y, por lo tanto, las empresas.

Por lo tanto, tenemos que pagar por cada token.

¿Cierto?

Pero hay todo un sector de Internet en el que las personas usan precios de suscripción.

Por lo tanto, para ellos es un cálculo muy diferente.

¿Cierto?

Pero creo que es cuestión de tiempo antes de que todos estén en el mismo grupo en el que hay que empezar a pensar en cada token.

Y ahí es cuando, ya sabes, probablemente se produzca el otro cambio en términos de ser un poco más responsables, como tenemos que hacer ahora mismo en las empresas.

O bien, trabajas en un laboratorio de vanguardia donde tienes un presupuesto ilimitado.

Y luego, simplemente sigues operando y, ya sabes, creando muchas de estas formas de trabajar nativas de la IA que son tan emocionantes y que están por todo Twitter.

Todas nuestras empresas quieren reflejar eso, pero no creen que quieran gastar los tokens que…

Tenemos personas que trabajan en Google aquí.

Tengo mucha curiosidad.

¿Cómo funciona?

¿Cuál es el presupuesto de Google?

¿Quieres responderla, Luis?

No creo que sea la persona adecuada para hablar de la economía de este tema.

Google es una empresa muy grande con muchas organizaciones diferentes.

Pero eso nos lleva al final, porque ya se nos acabó el tiempo.

Eso fue conveniente.

Salvado por la campana.

Eso es moderación de primera, amigos.

Las personas de relaciones públicas son…

En fin, gracias a nuestro panel y gracias por venir a ADS.