Democratización de la IA en Ingeniería: Lecciones del Viaje de Typeform

Así que, hola a todos. Bienvenidos a mi charla sobre la democratización de la IA en ingeniería, que es una especie de resumen de algunos de los aprendizajes que hemos tenido de nuestro viaje en Typeform este año. Pensé que comenzaría con algunas presentaciones. Así que, mi nombre es Andy. Soy un ingeniero de planta en Typeform. En caso de que no hayas oído hablar de Typeform, Typeform es un creador de formularios en línea, un poco como Google Forms. Puedes registrarte y puedes crear un formulario para mucha información que quieras recibir. Puedes enviar ese formulario a tus clientes y ellos pueden completarlo y puedes analizar tus resultados y enviarlos a integraciones de terceros y cosas así. ¿Hay algún usuario de Typeform aquí? ¿Alguien ha usado Typeform o ha oído hablar de Typeform? Bien, bien. Bien, algunas caras amigables, bien, eso es bueno saberlo. Bien, otra cosa que deben saber sobre mí es que soy fan de Star Trek. ¿Hay algún fan de Star Trek aquí? Bien, algunas personas. Bien, de acuerdo, larga vida y prosperidad. Hay algunos memes de Star Trek, así que probablemente los encuentren graciosos. Eso espero de todos modos. Si no eres fan de Star Trek, que es la gran mayoría de ustedes, cuando vean un meme de Star Trek, solo rían. Eso es solo una especie de señal para reír. Otra cosa que deben saber sobre mí es que soy usuario de Emacs, gran fan de Emacs, gracias por la introducción. Escribí la presentación en Emacs. De hecho, estoy presentando en Emacs. Aquellos de ustedes en el frente verán mi línea de modo, lo cual es muy emocionante. ¿Hay algún usuario de Emacs aquí? Bien, hay uno. Bien, es una experiencia bastante familiar para mí ser el único usuario de Emacs en la sala. Tal vez no en una sala con tanta gente, pero bien, está bien. No se preocupen, simplemente olvidaremos todo el asunto de Emacs.

Bien, ¿de qué voy a hablar hoy? Voy a hablar sobre el viaje en el que hemos estado este año en Typeform para proporcionar a nuestros ingenieros acceso a la IA, y principalmente voy a hablar sobre eso dentro de nuestra organización de ingeniería. Voy a dedicar un poco de tiempo a eso. También voy a compartir algunas anécdotas sobre el impacto que la IA ha tenido fuera de nuestra organización de ingeniería, y voy a cerrar con algunos aprendizajes o lecciones de ese viaje. Ahora, antes de hablar sobre nuestro viaje dentro de la ingeniería, pensé que enmarcaría esta conversación con una ilustración. Ahora, esto, solo quiero...

No se usaron datos reales. De hecho, le pedí a un LLM que generara este diagrama, y aquellos en el frente, podrían obtener puntos extra por detectar algunas pistas de que este diagrama fue generado por IA. Así que, una completa fabricación. Pero creo que ilustra el punto que quiero hacer. Que es que este año, ha habido una enorme cantidad de bombo sobre la IA. Una cantidad exponencial de bombo. La línea verde es una cantidad exponencial de bombo este año sobre herramientas de codificación de IA. Y el tipo de herramientas de codificación de las que estoy hablando son herramientas de codificación agenticas como Claude Code, Cursor, Klein, ese tipo de cosas. Mi presentación trata sobre el viaje que hemos tenido en Typeform, pero creo que probablemente sea una experiencia familiar para muchas personas en muchas organizaciones. Y la otra línea que sigue detrás de la línea de bombo es la adopción. Básicamente, estoy tratando de ilustrar que aunque creo que ha habido mucho bombo en la industria, creo que en realidad la adopción de las personas ha sido algo más lenta de lo que ese bombo podría indicar. Especialmente, y eso podría ser especialmente cierto en organizaciones más grandes, ya sabes, porque para que un equipo de ingeniería realmente adopte herramientas de IA, no es solo un caso de individuos recogiéndolo. Sabes, la empresa necesita comprar licencias, pagar por el acceso a LLM, elegir herramientas, considerar la seguridad, todo este tipo de cosas, lo que ralentiza esa curva de adopción. Entonces, cuando hablo de la adopción de herramientas de IA, es esa curva de adopción que sigue detrás del bombo. Esa es la curva de la que estoy hablando, la adopción de herramientas en equipos de ingeniería.

Así que, déjame contarte un poco sobre nuestro viaje en Typeform. Entonces, este año, creo que probablemente podría resumir toda la experiencia que hemos tenido con esta única frase. Adoptar IA en nuestra organización de ingeniería ha sido todo sobre democratizar el acceso a la IA y federar el uso de la IA. Y voy a desglosar lo que quiero decir con esos dos términos un poco. Pero eso realmente ha sido el principio rector durante todo el año, democratizar el acceso y federar el uso. Así que, comencemos con democratizar. ¿Qué quiero decir con democratizar? Así que le pedí a un LLM que escribiera un resumen de la palabra democratizar, y no tanto escribió un resumen como un ensayo. Así que dije, está bien, esto es demasiado largo, resume tu resumen. Y luego escribió este párrafo, que pensé que era bastante bueno, así que lo mantuve. Entonces, ¿qué quiero decir con la palabra democratizar? Democratizar se trata de hacer algo accesible para la gente común, todos, no solo un grupo específico o un conjunto de élites, hacer algo accesible para todos eliminando las barreras de entrada, simplificando cómo pueden usarlo, y distribuyendo ese uso lo más ampliamente posible. En última instancia, para que esté disponible para todos y no solo para un pequeño grupo. Entonces, cuando digo democratizar el acceso a la IA, estoy hablando de hacer que el acceso a la IA esté disponible para todos en tu equipo, reduciendo las barreras de entrada para todos, para que sea lo más fácil posible para las personas usarlo, y distribuyendo ese acceso lo más ampliamente posible, para que todos en tu equipo tengan acceso a la IA. Entonces, podrías estar pensando, eso suena genial. ¿Cómo lo hiciste? Este es el primer meme de Star Trek, así que es... Capitán Picard.

Entonces, podrías pensar, eso suena genial. ¿Cómo lo hiciste? Bueno, no te preocupes, de eso trata la presentación, así que te lo voy a contar. Entonces, una de las principales tecnologías habilitadoras que hemos utilizado este año es AWS Bedrock. Algunos de ustedes pueden no estar familiarizados con AWS Bedrock, así que les contaré un poco al respecto. Esto no es generado por IA. De hecho, copié esto de la Guía del Desarrollador de AWS, así que no está fabricado. Entonces, AWS Bedrock es un servicio gestionado en AWS que te da acceso a LLMs de una amplia gama de proveedores.

Así que, por ejemplo, encontrarías modelos de Anthropic allí, Claude Sonic, Claude Opus. Hay algunos modelos de Amazon, hay modelos de Meta, hay modelos de todo tipo de proveedores. Y accedes a esos modelos a través de una única, API unificada. Así que, usas la API de Bedrock para hacer solicitudes de inferencia, sin importar qué modelo estés usando. Y controlas el acceso a esos modelos usando primitivas familiares de AWS, como roles y políticas de IAM y ese tipo de cosas. Y pagas por tu uso a través de tu cuenta de Amazon.

Así que, básicamente, es una forma de acceder a LLMs sin salir del entorno de AWS. Así que, eso funciona bastante bien para aplicaciones. Entonces, si estás construyendo una aplicación que usa Bedrock para LLMs, es bastante simple. Despliegas tu aplicación, tu aplicación hace solicitudes de inferencia a Bedrock, y probablemente se autentica con su rol de IAM o algo así. Y bajo el capó, es capaz de usar estos modelos base. Así que, como Claude Sonic u Opus o lo que sea. Así que, eso es bastante sencillo. Pero estoy hablando de democratizar el acceso a la IA para ingenieros, para personas, para miembros de nuestros equipos.

Así que, estos no son aplicaciones ejecutándose en AWS, son personas en teclados. Y eso es un poco más complicado. Un usuario necesitaría autenticarse con AWS de alguna manera, tal vez tengan una clave de acceso o algo así. Podría haber algunos requisitos de seguridad especiales que tendrían que seguir. Así que, por ejemplo, necesitaríamos que nuestros ingenieros se conectaran a una VPN para poder acceder a Bedrock de esta manera. Y solo entonces pueden usar Bedrock para hacer solicitudes de inferencia.

Y recuerdas que uno de los principios detrás de la democratización era bajar la barrera de entrada. Esta es una barrera de entrada bastante alta. Es bastante complejo configurar todo esto. Y comenzamos aquí a principios de año. Pero el punto es que era bastante engorroso. Le decíamos a la gente, si quieres usar IA para codificar, solo sigue este enorme trozo de documentación y eso te configurará. Ahora, afortunadamente, AWS lanzó una nueva función para Bedrock a principios de año llamada Bedrock API keys, que simplifica enormemente este proceso.

Así que, con las Bedrock API keys, puedes generar una única clave API, que es efectivamente una especie de credencial para acceder a Bedrock. Tiene permisos muy limitados, por lo que puedes usarla solo para hacer solicitudes de inferencia. Y no necesitas ninguna de las otras cosas. Así que, no necesitas autenticarte con AWS, no necesariamente necesitas estar conectado a una VPN o algo así. Y solo con tu Bedrock API key, puedes entonces hacer solicitudes de inferencia. Así que, esto es lo que estamos usando. Estamos dando a todos nuestros ingenieros una Bedrock API key. Y luego están facultados para usar esa Bedrock API key como quieran con las herramientas que prefieran para hacer solicitudes de inferencia a LLMs.

Y podrías preguntarte cómo hicimos eso, y así es como lo hicimos. Tenemos una herramienta interna de línea de comandos llamada TF, que significa Typeform. Y todos nuestros ingenieros tienen acceso a esa herramienta de línea de comandos. Es como una navaja suiza, con muchas utilidades para que nuestros ingenieros las usen. Y escribimos un nuevo comando llamado generateBedrockToken. Y cuando ejecutas ese comando, genera un token de Bedrock. Todos nuestros ingenieros pueden usar eso, y eso les otorga acceso a LLMs.

Hay un poco de infraestructura detrás de escena, pero básicamente este es el modelo de distribución. Ahora, mencioné anteriormente que puedes usar modelos de muchos proveedores en Bedrock, y la mayoría de nuestros ingenieros están usando modelos de Anthropic como Claude Sonnet. Y podrías preguntarte por qué pasamos por todo este proceso de usar Bedrock cuando podríamos haber usado simplemente Anthropic. Segundo meme de Star Trek. De acuerdo. De todos modos, ¿por qué pasamos por todo este proceso cuando podríamos haber usado simplemente Anthropic? Podríamos haber simplemente registrado una cuenta de Anthropic, generado una clave API de Anthropic para nuestros ingenieros, y ellos no habrían tenido que usar Bedrock en absoluto.

O podríamos haber hecho lo mismo con OpenAI o algo así. Y de hecho, también intentamos eso. Probamos muchos enfoques diferentes. Y aunque técnicamente funciona, es mucho menos conveniente porque usamos AWS para alojar nuestra plataforma, por lo que ya son un proveedor existente para nosotros. Anthropic sería un nuevo proveedor para nosotros. Necesitamos registrarnos para un acuerdo. Necesitamos pagar una factura. Necesitaríamos generar claves API para todos. Necesitamos distribuir esas claves API a las personas. Cuando un nuevo ingeniero se une, necesitamos recordar, oh, generar una clave API para esa persona. Cuando alguien se va, tenemos que recordar, oh, desactivar esa clave API.

Así que hay una gran cantidad de administración que tendríamos que hacer de esta manera. Mientras que todos nuestros ingenieros ya tienen una cuenta de AWS. Cuando un ingeniero se une, simplemente obtiene una cuenta de AWS por defecto. Cuando se van, tenemos un proceso para desactivar esa cuenta. Y ahora también tienen acceso a LLMs porque pueden generar una clave API de Bedrock. Y ya tenemos una gran factura con AWS para nuestra plataforma. Entonces, ¿qué son unas pocas claves API de Bedrock? Simplemente pagamos por nuestro uso de LLM para ingenieros a través de ese proceso de facturación existente. Así que podríamos haber hecho lo que sugirió data. Podríamos haber usado Anthropic, pero resulta que es mucho más conveniente para nosotros usar un proveedor existente como AWS.

Y en última instancia, lo que esto significa es que cada ingeniero en nuestra organización tiene acceso ilimitado a LLMs para el desarrollo de software. Y eso podría ser a través de usar una herramienta como Claude Code o Klein. Podría ser para escribir scripts. Quiero decir, como quieran usarlo. Simplemente usan su clave API de Bedrock y tienen acceso ilimitado y no necesitan preocuparse de que nuestra cuenta de Anthropic se quede sin créditos o algo así. Bien, esa es la primera parte de esta gran idea, democratizar el acceso. Idear una forma con una barrera de entrada muy baja y distribuirla ampliamente para que todos en nuestro equipo puedan acceder a la IA.

¿Qué quiero decir con esta segunda parte? ¿Federar el uso? ¿Qué quiero decir con la palabra federación? No me refiero a la Federación Unida de Planetas. Eso es otra cosa de Star Trek. No. Bien. Lo que quiero decir es que todos tienen la misma forma de acceder a LLMs a través de Bedrock. Pero cuando se trata de elegir qué herramientas usan las personas, podrían estar usando Claude Code. Podrían estar usando Klein. Podrían estar usando Emacs. Conozco a una persona que usa Emacs. Esa decisión depende completamente de ellos. La decisión sobre qué herramienta usar está federada al nivel del individuo. Así que no estamos prescribiendo qué herramientas están usando las personas. Estamos dando a las personas una especie de camino único pavimentado para acceder a LLMs, pero luego federando la decisión sobre las herramientas a los individuos. Y en última instancia, significa que todos tienen acceso, la misma forma de acceder, pero pueden usar las herramientas que les gusten.

Sabes, eso es una cuestión de preferencia personal y estamos federando esa decisión a los individuos. Bien, ese es un resumen del viaje que hemos realizado este año para democratizar el acceso a la IA dentro de nuestra organización de ingeniería. Ahora voy a compartir algunas anécdotas sobre el impacto que la IA ha tenido fuera de nuestra organización de ingeniería también.

Y una de las principales áreas en las que la IA ha tenido un impacto fuera de nuestra organización de ingeniería ha sido en la contratación. Ahora, antes de que realmente comenzáramos a adoptar la IA adecuadamente, así es como se veía nuestro proceso de contratación. Tal vez sea una experiencia familiar para algunos de ustedes, ya sea como entrevistador o como candidato. Básicamente le decimos a la gente, escuchen, necesitan codificar durante una hora y vamos a observar cómo lo hacen.

Era un poco más agradable que eso. No les pedíamos que recorrieran un árbol binario o escribieran un algoritmo en ese momento o algo así. Les dábamos una tarea práctica agradable y una especie de ejercicio de programación en pareja, así que nos emparejábamos con el entrevistado y evaluábamos sus habilidades de codificación, sus habilidades para resolver problemas, su capacidad de comunicación. Así que, era una especie de ejercicio colaborativo.

Pero, de manera crítica, dijimos a las personas que no se les permitía usar herramientas de codificación de IA porque queríamos ver qué podían hacer con sus propias manos. Pero el problema con ese enfoque es que, a medida que comenzamos a adoptar más y más la IA dentro de nuestra organización de ingeniería, estamos pidiendo a las personas que hagan una cosa en la entrevista, pero luego les pedimos que trabajen de una manera completamente diferente una vez que comienzan a trabajar con nosotros. Y además, estamos esperando que todos nuestros ingenieros, ya sabes, adopten herramientas de codificación de IA y no hemos verificado eso en el proceso de entrevista en absoluto. Así que, ahora, hemos cambiado nuestro proceso de entrevista a esto. Le decimos a la gente, en realidad, queremos que usen IA durante una hora en su lugar, y vamos a observar cómo lo hacen ahora. Y sigue siendo un enfoque amigable. Les damos una tarea diferente, una tarea mucho más grande, mucho más grande de lo que podrías hacer en una hora por ti mismo. No hay manera de que puedas completar esta tarea en una hora por ti mismo. Pero decimos, escucha, nos gustaría que uses IA para trabajar en esta tarea, y todavía vamos a evaluar tus habilidades de programación, tus habilidades para resolver problemas, tu capacidad para comunicarte. Pero ahora también estamos evaluando la competencia en IA de las personas, porque queremos que se unan al equipo con alfabetización en IA, ya sabes. Queremos que se unan al equipo y compartan sus experiencias con sus compañeros de equipo y, ya sabes, enriquezcan también el uso de IA de todos. Y eso está resultando mucho más efectivo como proceso de contratación.

Bien, y la otra cosa de la que quiero hablar fuera de nuestra organización de ingeniería es el impacto que ha tenido en el límite entre nuestra organización de ingeniería y disciplinas técnicas adyacentes como diseño y gestión de productos. Ahora, los más observadores entre ustedes pueden notar que esto no es un meme de Star Trek. Me he adentrado en un género adyacente aquí. Así que una de las principales formas en que nuestros equipos de diseño y gestión de productos interactuarían con nuestro equipo de ingeniería es a través de nuestro sistema de diseño. Así que tenemos un sistema de diseño con un montón de componentes front-end y componentes correspondientes en Figma. Así que, por ejemplo, un diseñador puede, ya sabes, crear un mock en Figma y luego entregarlo a un ingeniero front-end, y pueden recrearlo con código real, y se ve y se siente igual. Así que construimos un servidor MCP para nuestro sistema de diseño para que un ingeniero front-end pueda transformar rápidamente un mock de Figma en un prototipo funcional, una pieza de código funcional, que no es el producto terminado. Tal vez los lleve, no sé, al 60 o 70 por ciento del camino allí. Pero básicamente ha agilizado enormemente esa interfaz entre diseño e ingeniería front-end. Y también ha resultado increíblemente útil para los gestores de productos porque los gestores de productos anteriormente intentaban articular una idea tal vez armando una demostración o una especie de experiencia simulada, ya sea confiando mucho en el diseñador, o cada vez más usando herramientas de codificación de vibraciones como Lovable o Bolt. Pero el problema con esas herramientas de codificación de vibraciones es que obtienes algo que más o menos funciona, pero se ve completamente diferente de nuestro producto real. Ahora pueden conectar este servidor MCP para el sistema de diseño, y obtienen un prototipo viviente y respirante que se ve exactamente como la cosa real. Y por supuesto no es código listo para producción, pero significa que pueden iterar rápidamente y probar nuevas ideas sin que esas ideas se vean completamente diferentes del producto principal.

Bien, así que esos son solo algunos anécdotas sobre el impacto de la IA fuera de nuestra organización de ingeniería. Y lo último que pensé en compartir son solo algunos aprendizajes o principios que creemos que son poderosos, que han surgido de este viaje este año. Así que el primero es que creo que la adopción de IA en un equipo se trata de empoderamiento, pero no de prescripción. Y para mí eso se refleja en esta idea de democratizar el acceso. Se trata de empoderar a todos para acceder a la IA, sin ser demasiado prescriptivo sobre para qué la usan, o cómo la usan. Así que realmente hemos intentado empoderar a todos para acceder a la IA dándoles herramientas simples, pero no prescribir para qué las usan, o cómo las usan, diciendo escuchen, pueden ir y usar las herramientas que les gusten, siempre que puedan usar las claves API de Bedrock, están listos para comenzar. Vayan y prueben muchas herramientas.

Otra cosa que ciertamente he aprendido este año es que la habilitación de IA es realmente una cuestión de personas. Suena como algo técnico, y hay aspectos técnicos en ello, ya saben, tuvimos que hacer lo de la API de Bedrock, y escribir esa herramienta de línea de comandos y así sucesivamente. Hay un aspecto técnico en ello. Pero realmente, es una cuestión de personas. Si quieres que tu equipo adopte IA, tienes que ir y, ya sabes, hablar con los miembros de tu equipo, averiguar dónde están. Habrá algunas personas en tu equipo que son adoptadores tempranos, que son usuarios avanzados. Habrá algunas personas en tu equipo que son muy escépticas, que realmente no están interesadas en usar IA. Habrá personas que quieren involucrarse, pero necesitan más capacitación. Habrá personas con casos de uso extraños que necesitas entender, ya sabes, cómo puedes apoyarlos. Así que, realmente es una cuestión de personas. Adoptar IA se trata de hablar con las personas en tu equipo y entender dónde están.

Y lo último que diría es una especie de cosa en tono de broma, casi, ¿verdad? Así que, la adopción de IA no ha terminado hasta que ha terminado, y aún no ha terminado. No es como elegir un IDE, y, ya sabes, donde dices, oh, vamos a comprar una licencia de sitio de JetBrains, y cualquiera puede usar VS Code o Emacs. No es así en absoluto. Todavía es un panorama que cambia rápidamente. Así que, puedo estar aquí hoy y decir, oh, el viaje que hemos tenido este año es X, y hemos elegido usar las claves API de Bedrock y así sucesivamente. Pero creo que es realmente importante mantener una mente abierta para el futuro y estar listo para ajustar la forma en que estás haciendo las cosas, cambiar tu enfoque, y estar listo para moverte con la industria, porque no creo que la habilitación de IA sea un objetivo estático. Creo que es un panorama en constante cambio con el que tendrás que mantenerte al día con el tiempo.

Así que, sí, esos son mis aprendizajes de este año. Si estás interesado en saber más, he escrito una publicación de blog sobre este tema. Y así, muchas de las cosas de las que he hablado están en esta publicación de blog. También hay algunos ejemplos, una especie de métricas o informes sobre el impacto que ha tenido en nuestro equipo, así como algunos ejemplos de código. Así que, si estás interesado en cómo escribimos esa herramienta de línea de comandos y distribuimos claves API de Bedrock a individuos, si vas a la publicación de blog, hay algunos ejemplos de código que te mostrarán exactamente cómo lo hicimos.

Bien, y ese es el final de la presentación. Así que, gracias por escuchar. Me encantan los memes de Star Trek, por cierto. Es realmente icónico. Tenemos una avalancha de preguntas. Así que, veamos cuántas podemos responder en el tiempo que tenemos. Primera pregunta, bien. Primera pregunta, basado en el enfoque de contratación y la postura pro-Vibe coding, parece que Typeform es bastante despreocupado con el resultado final. ¿Crees que eso es bastante sostenible a largo plazo? Quiero decir, es una pregunta interesante. Pero diría que Typeform definitivamente no es despreocupado con el resultado final. Quiero decir, cuando hablas de Vibe coding un prototipo desde el punto de vista de un gerente de producto, eso es justo al comienzo del ciclo de vida del producto y diseño, justo al comienzo, ya sabes.

Y para que eso pase de un prototipo a un producto funcional en producción se requiere mucho trabajo práctico. Y en realidad, lo que realmente ha hecho es permitirnos aumentar el ancho de banda con el que podemos experimentar. Así que, en lugar de probar, ya sabes, un par de ideas al principio, podemos probar, ya sabes, 10 ideas, podemos hacer investigación, investigación de usuarios sobre muchas ideas. Así que, creo que si acaso, probablemente está mejorando la calidad de la experiencia final del usuario, porque significa que podemos probar ideas mucho antes, y probar más ideas mucho antes. Y supongo que eso también se relaciona con la definición de cada uno de Vibe coding es completamente diferente. Así que, cuando hablas de Vibe coding, ¿a qué te refieres exactamente?

Bueno, supongo que en el contexto de un gerente de producto construyendo un prototipo, creo que tal vez el término Vibe coding es apropiado, porque no son ingenieros de software. Están construyendo un producto usando una especie de lenguaje de negocios o lenguaje de producto. Pero al mismo tiempo, no están construyendo un software listo para producción, ya sabes, pieza de software. Solo están interesados en el tipo de apariencia, y sensación, y experiencia del usuario, lo cual creo que es bastante diferente de cómo un ingeniero de software podría usar, ya sabes, herramientas de codificación agentic para acelerarlos en su trabajo diario. Sí, me encanta esa definición. Así que, gracias por eso. ¿Puedes compartir tus pensamientos sobre el impacto en la autenticidad de los ingenieros y la pérdida de conocimiento técnico al usar herramientas de codificación de IA, ya que todos podemos aprender a convertirnos en gerentes de agentes?

Es muy actual, supongo. Esto surgió en una charla de panel antes, y creo que mi punto de vista personal es que si uso IA para ayudarme a generar código, escribir código, construir algo, cuando finalmente abro una pull request y pido a un colega que lo revise, realmente no digo, oh, usé IA para ayudarme a escribir este código. No anuncio el hecho de que usé IA para escribir este código. De hecho, lo presento como mi propio trabajo. Y eso es porque, ya sabes, la IA podría haberme ayudado a probar algunas ideas o acelerar mi progreso, pero en última instancia, es mi responsabilidad como ingeniero de software asegurarme de que el código sea de alta calidad y, ya sabes, haga lo que dice en la lata.

Así que, no estoy realmente seguro. Tal vez es demasiado pronto para decir si está teniendo un impacto en las habilidades de las personas a largo plazo, pero ahora mismo, creo que es esencial que los operadores de herramientas de codificación de IA comprendan completamente lo que están haciendo y sean capaces de operar las herramientas, ya sabes, con tanto conocimiento del tema como si estuvieran escribiendo el código ellos mismos. Gracias por eso, Andy. Además, tenemos aquí, ¿cuáles fueron los resultados que viste en el proceso de contratación al introducir IA en la entrevista?

Así que, no puedo hablar de resultados en términos de, ya sabes, el número de candidatos que hemos contratado y cosas así porque realmente no tengo visibilidad de eso. Pero puedo decirte desde el punto de vista de un entrevistador, ciertamente he visto muchos candidatos que de otro modo, ya sabes, tal vez habrían pasado por el proceso de contratación, que cuando se trataba de usar herramientas de IA, no mostraron el nivel de alfabetización que esperaba. Ya sabes, una de las cosas que dije fue, ahora estamos evaluando la competencia en IA de las personas. He visto a muchas personas que parecían, hasta donde se puede decir, ya sabes, parecían ingenieros muy competentes y experimentados, pero simplemente no eran tan competentes como esperaba con las herramientas de codificación de IA. Y creo que eso es un criterio razonable para evaluar a alguien, especialmente si se están uniendo a un equipo que ya está trabajando en su competencia en IA. Y no creo que sea un gran esfuerzo para todos nosotros como ingenieros de software, hacernos preguntas como, ya sabes, ¿dónde estoy en la curva de competencia en IA en este momento?

Y no creo que sea un gran esfuerzo para todos nosotros como ingenieros de software, hacernos preguntas como, ya sabes, ¿dónde estoy en la curva de competencia en IA en este momento? Porque no creo que estas herramientas vayan a desaparecer. Y creo que va a ser una habilidad que todos necesitamos desarrollar además del conocimiento técnico, ya sabes, la capacidad de operar IA de manera competente, creo que va a ser importante para el futuro.

Y cuando estás mirando la competencia, ¿cuáles son las cosas clave que estás buscando cuando se trata de eso? Sí, supongo que hay un par de cosas que he estado buscando. Una es la forma en que podrías instruir o usar IA, ya sabes. Así que, por ejemplo, dedicar tiempo a escribir indicaciones reflexivas, dando a la IA información suficiente de antemano, suficiente contexto, suficiente orientación, en comparación con escribir, ya sabes, como preguntas o instrucciones de una línea. Y también, ser crítico con el resultado de la IA. Así que, por ejemplo, si un candidato en una entrevista simplemente aceptara como dado todo lo que fue generado por la IA, eso sería una señal de alerta para mí.

Mientras que si alguien estaba siendo, ya sabes, reflexivo y crítico al inspeccionar el resultado de la IA y asegurándose de que estaban contentos con eso antes de avanzar, eso sería, ya sabes, algo que estaba buscando. ¿Y has visto eso en tus entrevistas? Sí, definitivamente he visto ambos. Definitivamente he visto ambos.

Y yo incluso les digo a las personas al principio, como que les estamos dando una tarea que va a ser demasiado grande para que la hagan manualmente. Y estoy realmente interesado en ver cómo van a usar la IA. Así que, ya sabes, somos muy claros con las personas sobre eso, que esperamos ver el uso de IA como parte de la entrevista.

Bien, gracias. Y entonces, más allá de la entrevista, ahora estamos hablando de personas internamente, ¿cómo evalúas el impacto de la IA en la productividad dentro de tus equipos de ingeniería? Creo que es realmente difícil evaluar el impacto en la productividad. Y de hecho, ni siquiera he intentado evaluar, quiero decir, ¿cómo, no sé, cómo se mide siquiera la productividad en ingeniería en primer lugar? No lo sé. Así que, las cosas en las que he estado, he estado enfocándome, déjame retroceder un poco. Mi experiencia personal con la IA ha sido que ha sido algo bueno, que ha mejorado mi productividad.

Así que estoy trabajando bajo la suposición de que va a tener impactos positivos en todos los demás. Así que realmente he estado mirando métricas como, ya sabes, el número de personas que la usan, cuánto la están usando, cómo, ya sabes, qué proporción de nuestro equipo la está usando de manera regular, si hay o no algunos equipos con, ya sabes, un montón de uso de tokens, pero solo un usuario, lo que me dice que hay como un usuario avanzado enterrado en el equipo. O si hay un uso moderado pero muchos usuarios en ese equipo, lo que me dice que está como integrado en la forma en que el equipo está trabajando. Me he estado enfocando solo en métricas como esa, sin preocuparme realmente por los resultados finales, porque mi sensación es que el resultado final probablemente será positivo.

Y creo, no sé cómo medirías el impacto en la productividad. Si alguien lo sabe, me encantaría saberlo, ya sabes. Creo que eso surge cada año, más allá de la IA, ¿cómo mides la productividad de los ingenieros? ¿Alguien tiene una respuesta a eso? Podríamos hablar de eso otro día. Pero también tengo curiosidad.

Así que estamos hablando de integrar ese aprendizaje, ¿cómo compartes realmente ese conocimiento internamente? Entonces, si alguien tiene como mejores prácticas y nuevas herramientas o ideas y cosas así, ¿cómo te mantienes actualizado y compartes ese conocimiento? Sí, quiero decir, tenemos un canal de Slack, donde hay mucha conversación activa sobre esto. Y tenemos algunos lugares de documentación compartida. Así que, ya sabes, si alguien nuevo se une, o si es un novato en IA, hay algunos recursos básicos para ayudar a ponerse al día. Así que creo que hay como una base allí y una comunidad en la que puedes involucrarte si quieres. Y más allá de eso, ya sabes, realmente no estamos impulsando la adopción. Solo estamos empoderando la adopción.

Así que solo estamos dejando que las personas adopten estas herramientas de manera orgánica. Y lo que estamos viendo es que, ya sabes, las personas están adoptando estas herramientas porque quieren. Así que para mí, se trata de eliminar esas barreras, y simplemente engrasar las ruedas, y asegurarse de que sea lo más fácil posible para que las personas comiencen. Gracias. Y entonces, ¿practicas TDD con IA en Typeform? Quiero decir, no puedo hablar por cada ingeniero en Typeform. Puedo responder por mi parte. Y lo que puedo decir es que creo que uno de los aspectos esenciales de usar IA para codificar es darle al agente una forma de determinar si ha hecho el trabajo o no, una forma de obtener retroalimentación.

darle al agente una forma de determinar si ha hecho el trabajo o no, una forma de obtener retroalimentación. Así que, por ejemplo, si le pides que solucione, ya sabes, errores de linting, necesitas decirle qué comando ejecutar, para ejecutar el linter, para que sepa cuándo ha terminado. Y entonces, cuando se trata de TDD, quiero decir, creo que TDD es esencial para asegurarse de que sepa cuándo ha cumplido con tus requisitos, porque de lo contrario, es como si estuviera, ya sabes, lanzando tokens al viento, y algunos de ellos podrían pegarse y otros podrían no hacerlo. Me gusta eso.

Bien, genial. Otro aquí. Entonces, si los desarrolladores individuales usan diferentes modelos al desarrollar en la misma base de código, ¿encuentras que eso lleva a alguna inconsistencia en el código? Quiero decir, estoy seguro de que sí. Y no tenemos formas sistemáticas de evaluar eso. Ya sabes, dije antes, cuando estoy usando herramientas de codificación, cuando abro una pull request, independientemente del modelo que usé, estoy presentando los cambios como mi propio trabajo.

No porque esté tratando de ocultar el hecho de que estoy usando IA, sino porque, ya sabes, estoy asumiendo la responsabilidad del hecho de que, ya sabes, estoy a cargo de los cambios, estoy haciendo estos cambios. Así que de la misma manera, esperaría que un revisor de código evaluara ese cambio como si hubiera venido de cualquier otra persona en el equipo, ya sabes. Así que si hay inconsistencias que surgen, ya sabes, pasaron la revisión de código, por lo que podrían haber venido de cualquier individuo teniendo diferentes tipos de, ya sabes, estándares o preferencias, ya sabes.

Así que gracias. ¿Y cómo gestionas y limitas los costos usando el enfoque de bedrock? No sé si hay muchos líderes senior de Typhoon aquí. Básicamente no hacemos ni gestionamos ni limitamos. Ya sabes, he hecho algunos informes, así que sé aproximadamente cuánto está costando. Así que puedo decirte, tenemos alrededor de 100 ingenieros, y nos está costando alrededor de $150 al mes por ingeniero en los gastos de bedrock. Y he compartido esos números con nuestros líderes senior, y ellos dicen, está bien, sí, está bien. Quiero decir, creo que si fuera como $1,000 por usuario, probablemente estarían sonando las alarmas.