Democratización de AI 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 en nuestro viaje en Typeform este año. Pensé que comenzaría con algunas presentaciones. Así que, mi nombre es Andy. Soy 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, así que puedes registrarte y 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, algunas caras amigables, es bueno saberlo. 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 algo lindo. 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 al frente verán mi línea de modo, lo cual es muy emocionante. ¿Hay algún usuario de Emacs aquí? Bien, hay uno. 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 está bien, no hay problema. simplemente olvidaremos todo el asunto de Emacs.

Bien, ¿de qué voy a hablar hoy? Voy a hablar sobre el viaje que hemos tenido este año en Typeform para proporcionar a nuestros ingenieros acceso a la IA. 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, divulgación justa, este gráfico es completamente fabricado. No se usaron datos reales. De hecho, le pedí a un LLM que generara este diagrama, y aquellos al frente, podrían obtener puntos extra por detectar algunas pistas de que este diagrama fue generado por IA generado. Así que, una fabricación completa. Pero creo que ilustra el punto que quiero hacer, que es que este año ha habido una gran 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 las 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 va 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. Y eso podría ser especialmente cierto en organizaciones más grandes, porque para que un equipo de ingeniería realmente adopte herramientas de IA, no es solo un caso de que los individuos las adopten. 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 va 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 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 ese ha sido realmente el principio guía 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, 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.

Así que, podrías estar pensando que suena genial. ¿Cómo lo hiciste? Este es el primer meme de Star Trek, así que está bien. Es el Capitán Picard. Así que, podrías pensar que suena genial.

¿Cómo lo hiciste? Bueno, no te preocupes. De eso trata la presentación, así que te lo voy a contar.

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 Sonnet, Claude Opus. Hay algunos modelos de Amazon. Hay algunos 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 utilizando primitivas familiares de AWS, como roles IAM y políticas y ese tipo de cosas, y pagas por tu uso a través de tu cuenta de Amazon. 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 IAM o algo así, y bajo el capó, es capaz de usar estos modelos fundacionales. Así que, Claude Sonnet 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 que corren 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 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 reducir 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. Sabes, le decíamos a la gente, si quieres usar IA para codificar, solo sigue este enorme, ya sabes, el documento de instrucciones, y eso te configurará.

Ahora, afortunadamente, AWS lanzó una nueva función para Bedrock a principios de año llamada claves API de Bedrock, que simplifica enormemente este proceso. Así que, con las claves API de Bedrock, puedes generar una única clave API, que es efectivamente una especie de credencial para acceder a Bedrock. Tiene permisos muy delimitados, por lo que podrías usarla solo para hacer solicitudes de inferencia.

Así que, esto es lo que estamos usando. Estamos dando a todos nuestros ingenieros una clave API de Bedrock, y luego están facultados para usar esa clave API de Bedrock como quieran con las herramientas que deseen 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 type form. Y todos nuestros ingenieros tienen acceso a esa herramienta de línea de comandos. Es como una navaja suiza, tiene muchas utilidades para que nuestros ingenieros las usen. Y escribimos un nuevo comando llamado generate Bedrock token. 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 trabajo 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 habernos registrado para una cuenta de anthropic, generado una clave API de anthropic para nuestros ingenieros y 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. Necesitaríamos 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 necesitaríamos hacer para hacerlo 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 los datos sugirieron. 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 del uso de una herramienta como Claude Code o Cline. 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 por 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 a todos.

Así que todos en nuestro equipo pueden 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 no es una cosa de Star Trek. No, está 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 Cline. Podrían estar usando Emacs. Conozco a una persona que usa Emacs. Esa decisión es completamente suya. La decisión sobre qué herramienta usar se federó al nivel de el 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 prefieran. 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 verlos hacerlo. Eso era un poco más agradable que eso. No les pedíamos que recorrieran un árbol binario o escribieran un algoritmo 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, les decíamos a las personas, no se les permite 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 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. Les decimos a las personas, en realidad, queremos que usen IA durante una hora en su lugar y vamos a verlos hacerlo 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ían hacer en una hora por sí mismos. No hay manera de que puedan completar esta tarea en una hora por sí mismos. Pero les decimos, escuchen, nos gustaría que usen IA para trabajar en esta tarea. Y seguimos evaluando sus habilidades de programación, sus habilidades para resolver problemas, su capacidad de comunicación. 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. Queremos que se unan al equipo y compartan sus experiencias con sus compañeros de equipo y enriquezcan el uso de IA de todos también. Y eso está demostrando ser 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 una carga de componentes front-end y componentes correspondientes en Figma. Así que, por ejemplo, un diseñador puede 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 optimizado 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 intentarían 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 vibe, como Lovable o Bolt. Pero el problema con esas herramientas de codificación de vibe 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, que se ve exactamente como el producto 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, ya saben, completamente diferentes del producto principal.

Bien, así que esas son solo algunas 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 y 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.

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, cómo las usan diciendo, escuchen, pueden ir y usar las herramientas que les gusten. Mientras puedan usar las claves API de Bedrock, están listos para ir, vayan y prueben muchas herramientas. La 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 demás, 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 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 quieran involucrarse, pero necesitan más capacitación. Habrá personas con casos de uso extraños que necesitas entender 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. Lo último que diría es algo en tono de broma, casi. Entonces, la adopción de IA no termina hasta que termina, y aún no ha terminado.

JetBrains y cualquiera puede usar VS Code o Emacs. No es así en absoluto. Es todavía un paisaje que cambia muy 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 Bedrock API Keys y demás, 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 simplemente 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 paisaje en constante cambio que tendrás que seguir con el tiempo. Esas son mis lecciones de este año. Si estás interesado en saber más, he escrito una publicación de blog sobre este tema, y mucho de lo que he hablado está 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 algunas muestras de código. Así que, si estás interesado en cómo escribimos esa herramienta de línea de comandos y distribuimos Bedrock API Keys a individuos, si vas a la publicación de blog, hay algunos ejemplos de código que te mostrarán exactamente cómo hicimos eso. Bien, y ese es el final de la presentación. Así que, gracias por escuchar. Público completo. Fue una gran carrera.

Bien. Tenemos una avalancha de preguntas, así que veamos cuántas podemos responder en el tiempo que tenemos. Bien. Primera pregunta, basándonos 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 product manager, eso es justo al comienzo del ciclo de vida del producto y diseño, justo al comienzo, y para que eso pase de un prototipo a una especie de producto funcional en producción se requiere mucho de intervención.

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 un par de ideas al principio, podemos probar 10 ideas. Podemos hacer investigación de usuario 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 que la definición de Vibe coding de cada uno es completamente diferente. Entonces, cuando hablas de Vibe coding, ¿a qué te refieres exactamente?

Bueno, supongo que en el contexto de un product manager 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 una pieza de software lista para producción. 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 herramientas de codificación agentic para acelerarse en su trabajo diario.

Sí. Me encanta esa definición. Así que, gracias por eso. ¿Puedes compartir tus pensamientos e impacto sobre la autenticidad de los ingenieros y la pérdida de conocimiento técnico al usar herramientas de codificación AI, ya que todos podemos aprender a convertirnos en managers de agentes? Es una buena pregunta. Es muy actual, supongo. Esto surgió en una charla de panel antes, y creo que mi punto de vista personal es que si uso AI para ayudarme a generar código, escribir código, construir algo, cuando finalmente abro una pull request y le pido a un colega que lo revise, realmente no digo, oh, usé AI para ayudarme a escribir este código. No anuncio el hecho de que usé AI para escribir este código. De hecho, lo presento como mi propio trabajo. Y eso es porque AI 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 haga lo que dice en la lata. Así que, realmente no estoy 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 AI comprendan completamente lo que están haciendo y sean capaces de operar las herramientas con tanto conocimiento del tema como si estuvieran escribiendo el código ellos mismos. Gracias por eso, Andy.

También tenemos aquí, ¿cuáles fueron los resultados que viste en el proceso de contratación al introducir AI en la entrevista? Así que, no puedo hablar de los resultados en términos del 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 tal vez habría pasado por el proceso de contratación, que cuando se trataba de usar herramientas AI, no mostraron el nivel de alfabetización que esperaba. Una de las cosas que dije fue, ahora estamos evaluando la competencia en AI de las personas. He visto a muchas personas que parecían, hasta donde se puede decir, parecían ingenieros muy competentes y experimentados, pero simplemente no eran tan competentes como esperaba con las herramientas de codificación AI. Y creo que 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 AI. 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 AI 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 AI 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 AI, ya sabes. Así que, por ejemplo, dedicar tiempo a escribir indicaciones reflexivas, dar a la AI suficiente información 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 la salida de la AI. Así que, por ejemplo, si un candidato en una entrevista simplemente aceptaba como dado todo lo que fue generado por la AI, eso sería una señal de alerta para mí. Mientras que si alguien estaba siendo, ya sabes, reflexivo y crítico al inspeccionar la salida de la AI y asegurarse 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, sí, desde personas que usaban, incidentalmente, AI porque pensaban que era importante en la entrevista, hasta ser claro que es una parte central de la forma en que alguien trabaja. ¿Y has incluido eso en términos de guiar a las personas sobre cómo tener éxito en una entrevista? ¿Les has mostrado que es importante para ellos usar estas herramientas AI? ¿O cómo saben que pueden usarlo, básicamente? Sí, quiero decir, se les dice de antemano como parte del proceso, así que saben que están entrando en una entrevista donde se espera que usen AI. Y yo incluso les digo a las personas al principio, como te estamos dando una tarea, que va a ser demasiado grande para que la hagas manualmente. Y estoy realmente interesado en ver cómo vas a usar AI.

Y así, más allá de la entrevista, ahora estamos hablando de personas internamente, ¿cómo evalúas el impacto de AI 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 mides la productividad en ingeniería en primer lugar? No lo sé. Así que las cosas en las que me he estado enfocando, déjame retroceder un poco. Mi experiencia personal con AI ha sido que ha sido algo bueno, y 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 lo usan, cuánto lo están usando, qué proporción de nuestro equipo lo está usando regularmente, si hay 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 en métricas como esa, sin realmente preocuparme 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. Creo que eso surge cada año, como más allá de AI, ¿cómo mides la productividad de los ingenieros? ¿Alguien tiene una respuesta para 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 o nuevas herramientas o ideas, y cosas así, ¿cómo te mantienes al día y compartes ese conocimiento? Sí, quiero decir, tenemos un canal de Slack, donde hay mucha conversación activa sobre esto. Tenemos algunos lugares de documentación compartida. Así que, ya sabes, si alguien nuevo se une, o si son novatos en AI, 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 empujando 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 facilitar las cosas, y asegurarse de que sea lo más fácil posible para que las personas comiencen. Gracias. Y entonces, ¿practicas TDD con AI 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 AI para codificación es darle al agente una forma de determinar si ha hecho el trabajo o no, una forma, ya sabes, para que reciba retroalimentación. Por ejemplo, si le pides que arregle, 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, creo que TDD es esencial para asegurarse de que sepa cuándo ha cumplido con tus requisitos, porque de lo contrario es solo como, ya sabes, lanzando tokens al viento, y algunos de ellos podrían pegarse y otros no. Me gusta eso. Bien, genial.

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. Sabes, dije antes, cuando estoy usando herramientas de codificación, cuando abro una pull request, independientemente de qué modelo usé, estoy presentando los cambios como mi propio trabajo, no porque esté tratando de ocultar el hecho de que estoy usando AI, sino porque, ya sabes, estoy asumiendo la responsabilidad del hecho de que, ya sabes, estoy a cargo de hacer 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, ¿sabes? Así que si hay inconsistencias que pasan, 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. Gracias.

¿Y cómo gestionas y limitas los costos usando el enfoque de breadrock? No sé si hay muchos líderes senior de Typeform aquí. Básicamente no hacemos ninguna de las dos cosas, gestionar o limitar. Sabes, así que he hecho algunos informes, sé, como 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 $1000 por usuario, probablemente estarían sonando las alarmas. Pero ahora mismo, simplemente no, no lo estamos limitando. Estamos haciendo exactamente lo que dije en la diapositiva, que es dar a todos acceso ilimitado, ¿sabes? Si y cuando se vuelva demasiado caro, estoy seguro de que tendremos una conversación al respecto. Pero ahora mismo, creo que estamos de la mente de que solo queremos alentar a las personas a adoptar estas herramientas de la manera que se sientan cómodos.

Se nos acabó el tiempo. Muchas gracias, Andy. Un aplauso para Andy, por favor.