Manual to Magical: AI in Developer Tooling

Hola a todos y muchas gracias por decidir escuchar mi charla. Mi nombre es Toby y soy líder técnico en RedwoodJS.

RedwoodJS es el framework de JavaScript TypeScript más productivo para proyectos de una sola persona o proyectos en empresas más pequeñas. Es perfecto para cuando quieres comenzar y ejecutar una aplicación full stack lo más rápido posible. En Redwood, nos encantan los code mods. Los usamos para ayudar a nuestros usuarios a actualizar de una versión de Redwood a la siguiente. Me importa mucho la DX en Redwood y hemos encontrado que los code mods son la forma más amigable de ayudar a nuestros usuarios a actualizar.

No solo damos a nuestros usuarios una plantilla de inicio y luego los dejamos a su suerte para mantenerla actualizada. Ayudamos a nuestros usuarios a actualizar para siempre porque creemos que es importante que nuestros usuarios puedan aprovechar las últimas características en sus versiones de Redwood y también obtener todas las actualizaciones de seguridad y parches de las bibliotecas de las que dependemos. Cuando un usuario configura por primera vez Redwood, sabemos exactamente cómo se ve su código. Pero con el tiempo, a medida que el usuario desarrolla su aplicación, lo más probable es que haga cambios en el código. Así que cuando llega el momento de ejecutar el code mod, fácilmente pueden haber pasado dos, tres o incluso cuatro años desde que configuraron su aplicación por primera vez. Y lo más probable es que haya pasado por muchos cambios desde entonces. Así que nuestros code mods, nunca saben cómo se verá realmente el código que tendrán que modificar. Así que tenemos que diseñarlos para que funcionen en una amplia variedad de diferentes entradas y al mismo tiempo. Y también para hacer los code mods tan robustos como nos gustaría, pasamos mucho tiempo escribiendo pruebas unitarias para los code mods. Todo esto consume mucho tiempo.

Quería idear una manera de hacerlo más rápido y fácil, más rápido para escribir code mods. Y dado el título de la charla, estoy seguro de que han deducido cuál fue mi enfoque. Y eso fue pedirle a una IA que ayudara a generar los code mods. Tengo experiencia previa usando directamente la API de OpenAI con llamadas fetch. Pero para este proyecto, quería usar un framework o SDK de IA real. Así que, por supuesto, miré dos grandes, LangChain y Llama Index. Desafortunadamente, encontré que sus raíces en Python eran un poco demasiado pronunciadas y que el soporte de TypeScript se sentía de segunda clase. Así que fui en busca de otros frameworks y SDKs de IA con prioridad en TypeScript. Una elección obvia aquí sería Vercel con su SDK de IA. Para mí, decidí ir con OpenAI porque creo que su documentación era absolutamente la mejor. Y OpenAI con su SDK también fue la herramienta que me permitió moverme más rápido, lo cual es importante para una herramienta interna como esta. Así que decidí escribir el CLI y lo nombré Codemodder. Probablemente no sea el mejor nombre.

Debería haberle pedido a una IA que me ayudara a encontrar un nombre mucho mejor, ¿no? Pero Codemodder es el que tenemos. Con eso vamos a trabajar aquí.

Así que mi primer enfoque ingenuo fue intentar hacerlo de una sola vez. Simplemente pedirle a la IA que por favor me ayudara a escribir un code mod que cambie las importaciones del router a importar desde rego.js.v.router. Pero, por supuesto, eso no funcionó muy bien.

Así que solo usando la interfaz web estándar de chatttypt.com, lo iteré por un tiempo. Pero rápidamente pasé a usar el OpenAI playground en su lugar. Es mucho más potente. Te permite elegir diferentes modelos. También puedes ajustar algunos de los parámetros del modelo, de los cuales hablaremos más adelante.

Así que pasé por mis iteraciones y experimentaciones en el playground. Se me ocurrió un mensaje del sistema que creo que era muy bueno. Era claro, detallado y tenía pasos para que la IA los siguiera. Después de ese mensaje del sistema, tenía los mensajes del usuario con los detalles sobre el modelo de código específico que quería. Pero aun así, dado esto, la IA a veces tenía dificultades para recordar o simplemente elegía ignorar algunas de las instrucciones que había dado en el mensaje del sistema.

Así que una técnica que utilicé aquí que funcionó muy bien para mí fue el refuerzo. Así que al final, después del mensaje del sistema y después de los mensajes del usuario, tomo una o dos de las instrucciones que la IA tuvo dificultades para seguir y las reitero al final, solo para reforzar un poco más esas reglas. Y eso hizo toda la diferencia.

Así que teniendo un prompt con el que estaba contento en el playground, quería intentar implementarlo en mi CLI. Así que se me ocurrió un plan inicial. La CLI recibiría una entrada, que sería un ejemplo corto de cómo podría verse el código con el que el modelo de código tendría que trabajar, y la salida esperada del modelo de código. Y luego una breve descripción del propio modelo de código.

Así que luego le pediría a la IA que generara algunas descripciones de casos de prueba diferentes. Y finalmente, los propios casos de prueba para esas descripciones. Así que al generar las descripciones, quería que fueran creativas o quería que cubrieran una amplia variedad de diferentes entradas, porque como mencioné, realmente no sabemos qué tipo de entrada tendrá que manejar el modelo de código, dependiendo de lo que nuestros usuarios hayan hecho. Qué tipo de cambios han hecho nuestros usuarios a la plantilla inicial que les proporcionamos.

Así que tengo una plantilla, y hay un parámetro llamado temperatura, que varía de 0 a 2, que puedes ajustar con los modelos. El valor predeterminado es 1, y si subes hacia 2, la salida se vuelve más y más creativa, y si lo bajas hacia 0, la salida es más y más determinista. Así que pensé que subir la temperatura sería perfecto para obtener descripciones de casos de prueba más creativas. Así que lo que aprendí es que la temperatura realmente no controla cuán creativo será todo el resultado.

Solo controla cuán creativo será el siguiente token en el flujo de salida. Así que funciona bien para trabajos verdaderamente creativos, como una publicación de blog, o escribir poesía, o incluso generar imágenes o música. Pero para algo tan determinista como la programación, en mi experimentación encontré que siempre producía los mejores resultados simplemente dejándolo en 1. Así que te voy a ahorrar tiempo y te diré que simplemente lo dejes en 1, y no te molestes en ajustar ese parámetro, porque lo más probable es que no te ayude.

De todos modos, teniendo casos de prueba, quería pedirle a la IA que generara el code mod real y luego pensé, tomar esos casos de prueba para verificar que el code mod realmente haga lo que quiero que haga. Así que ejecutaría los casos de prueba, y si hubiera algún error, construiría un nuevo prompt, lo alimentaría de nuevo a la IA, y le pediría que generara un nuevo code mod con el caso de prueba corregido. Así que con el prompt, volvería, generaría un nuevo code mod, y luego lo ejecutaría todo de nuevo. Desafortunadamente, nunca pude lograr que la IA generara una muy buena lista de descripciones de casos de prueba, o casos de prueba correctos para esas descripciones. Así que este plan nunca funcionó para mí. Así que tuve que revisarlo, y este es el plan final que se me ocurrió y lo que he implementado.

De todos modos, el primer paso es el mismo. Dejo que el usuario proporcione la entrada, la salida esperada y una descripción. Para el segundo paso, en lugar de pedirle que genere descripciones de casos de prueba, simplemente le pedí a la IA que generara otras posibles entradas, como dado esta entrada, ¿cómo podría posiblemente verse en un proyecto real de un usuario? Así que pauso la ejecución del programa, y le pido al usuario, como yo, si estoy ejecutando la CLI, que me pida que eche un vistazo a las entradas generadas, y si es necesario, incluso modificarlas antes de dejar que el programa continúe, y esto hizo una gran diferencia. Esto es clave. Así que nuevamente, divide la ejecución y pausa, y deja que el usuario verifique que la IA está en el camino correcto.

Bien, dada la entrada inicial, la salida y la descripción, más el conjunto generado de entradas, ahora puedo pedirle a la IA que genere el code mod para todo esto. Pero luego, cuando se trata de verificar o probar el code mod, no tenemos ninguna prueba unitaria porque no pude lograr que la IA las generara para mí. Pero lo que sí tenemos es ESLint, Predur, y el compilador de TypeScript. Podemos ejecutar todas esas herramientas de análisis de código estático y observar sus salidas. Así que si obtengo algún error de ESLint o TypeScript, construiré un nuevo prompt, así que hackearé en la IA en el paso 3 allí, y generaré un nuevo code mod, y luego lo ejecutaré todo de nuevo. Y con esto, si simplemente itero entre 3 y 6 aquí, como 3 o 4 veces, muy a menudo termino con un code mod sin ningún error de ESLint o TypeScript. Es un gran punto de partida para algunos ajustes finales antes de tener un code mod que podamos realmente enviar a nuestros usuarios. A veces, sin embargo, la IA nunca logrará corregir todos los errores en el código. Así que lo que hago es que después de 5 iteraciones, simplemente me detengo. Me rindo. En ese punto, es mejor simplemente comenzar de nuevo desde el principio, así que comenzar de nuevo desde el paso 1, y ejecutarlo todo de nuevo. A veces tengo que hacer eso 2 o 3 veces, pero al final, muy a menudo termino con un muy buen code mod al que simplemente podemos hacer algunos ajustes finales antes de comenzar a escribir casos de prueba para él, y luego enviarlo a nuestros usuarios. Como mencioné, una cosa clave aquí es colaborar con la IA. Así que como dije, pausamos en el paso después de generar posibles entradas para dejar que el usuario verifique, modifique esa lista generada de entradas. También tendría una colaboración o asistencia de la IA al final donde usamos nuestras herramientas de análisis estático como ESLint y el compilador de TypeScript.

Incluso si tuviera casos de prueba, también los usaría totalmente. Así que si terminas escribiendo una herramienta asistida por IA, y tienes casos de prueba pre-sistema, por favor úsalos también. Ejecuta el código a través de tus casos de prueba y retroalimenta cualquier salida a la IA, y estoy seguro de que mejorará enormemente la salida que obtienes. Y a menudo, solo hacer esto una vez no es suficiente. Tienes que iterar. Como dije, en el último paso, iteramos hasta 5 veces, y si eso no funciona, comenzamos de nuevo desde el principio. Así que en total, puede tomar 10, 15 iteraciones hasta que tengamos un modelo de código con el que estemos contentos.

Una cosa que fue un poco un desafío para mí fue cambiar mi mentalidad. Trabajar con la IA es muy, muy diferente en comparación con el código normal con el que trabajo. Estoy acostumbrado a tener—recibo un informe de error. Identifico el error, lo corrijo, y envío mi corrección de error, y ahora el código en esa parte de la aplicación es 100% correcto. Pero así no es como funciona con la IA. Probablemente nunca llegarás al 100% correcto. Tendrás que conformarte con lo suficientemente bueno, y eso puede ser un desafío.

Y también, mientras iteraba en mi prompt, tenía muchas ideas que quería probar, pero es difícil saber si realmente estás mejorando la salida o no. No solo tienes que mirar esta única entrada para saber si la salida es mejor. Tienes que mirarlas todas. Y para que eso sea viable, realmente deberías intentar automatizarlo tanto como sea posible. Tienes—entonces, tienes—la clave aquí es pensar como un científico y darse cuenta de que las reglas estándar de investigación y experimentación se aplican. Solo haz un cambio a la vez. Prueba con una multitud de diferentes entradas, y ten una forma de evaluar consistentemente la corrección o medir objetivamente qué tan bien está funcionando la IA.

Así que para mí, en esta prueba, en este caso, la forma en que mido objetivamente es simplemente contar el número de errores de ESLint y TypeScript. Si el número promedio de errores disminuye en todas las diferentes entradas, sé que el cambio que hice fue un neto positivo. Así que a veces, incluso si el ajuste que hago lo empeora para la entrada con la que estoy actualmente experimentando, en realidad podría haber mejorado el promedio en todas las entradas. Así que entonces quiero mantener ese cambio.

Así que, en resumen, los Codebots son excelentes para la experiencia del desarrollador, pero consumen mucho tiempo para escribir. Al elegir un framework de IA, encuentra uno con buena documentación y elige uno con el que puedas iterar rápidamente. Y para algunos consejos específicos sobre cómo escribir herramientas de desarrollo impulsadas por IA o simplemente prompts de IA en general, ten un prompt claro y detallado paso a paso si puedes, y usa refuerzo si es necesario. No te preocupes por la configuración de temperatura, simplemente déjala en uno. Eso probablemente será lo mejor para ti cuando trabajes con salidas relacionadas con el código. ¡No te preocupes! Dos, colabora con la IA, ya sea manualmente o automáticamente con las herramientas que tengas disponibles, avances estáticos, casos de prueba, cualquier cosa así. E itera con esta asistencia.

Así que al final, si puedes medir qué tan buena es la salida, y no es lo suficientemente buena, ajusta algo y ejecuta de nuevo. Pero tienes que conformarte con lo suficientemente bueno. Probablemente nunca será 100% correcto. Y para saber si realmente estás mejorando las cosas, necesitas encontrar una manera de medir objetivamente qué tan bien está funcionando la IA. Así que espero haberte inspirado para que escribas tus propias herramientas de desarrollo impulsadas por IA y que te haya dado algunas pistas para hacer que sea agradable y más rápido llegar a una herramienta útil para ti. Muchas gracias por escuchar mi charla. Si quieres ponerte en contacto conmigo, puedes encontrarme en tobi.dev. O soy tobi.dev en Twitter, también puedes escanear el código QR allí para encontrar todos los detalles. Gracias.