Reconozco que empezar a escribir este artículo me ha costado más de lo que pensaba después de casi un año sin escribir, pero reconozco que el tema lo merece. Este es el primero de una serie de artículos en los que iré compartiendo mis aventuras con IA generativa, y hoy empezaremos con un repaso de mi experiencia hasta ahora específicamente en el contexto de trabajo con código.

¿Por qué escribir sobre IA ahora?

Esta va a ser una serie sobre mi propia experiencia con las herramientas, y donde intentaré convencerte, querido lector, de que es un paradigma que no nos podemos permitir ignorar especialmente aquellos que trabajamos en la industria del software, porque el trabajo y las expectativas van a cambiar, si no lo están haciendo ya.

Arrancada en falso y primeros experimentos

Dejando de lado pequeñas pruebas con ChatGPT, DeepSeek y Bing, mi primera experiencia significativa fue intentar usar Claude para explorar APIs de Windows a bajo nivel como WinUI y WinRT, en el contexto de unas pruebas de concepto con React Native para Windows.

Esta experiencia fue bastante decepcionante porque tuve la mala suerte de que Microsoft estaba migrando APIs entre dos arquitecturas, Paper y Fabric, y aunque buscaba información de la segunda, la información disponible era sobre todo de la primera. Esto causaba alucinaciones muy fuertes y que el chatbot produjera código que hacía referencia a funciones que no existían. En general el código muy específico y con ambigüedad le cuesta a la IA, especialmente en lenguajes como C++.

Mi segunda experiencia significativa fue mejor, aunque hubo un par de diferencias importantes. Fue en el contexto de un hackathon interno (que ganamos) y lo usé para generar y modificar rápidamente una UI en React Native. El hecho de que estaba usando React, JavaScript, y estaba produciendo algo simple cambió bastante la experiencia. Además, llevo trabajando con React muchos años, y para mí era relativamente sencillo corregir los bugs que venían del código que generaba el bot. Teniendo experiencia con el ecosistema y el stack, la generación de código con IA es un acelerante importante.

Q, el agente en tu terminal

En la saga de James Bond, Q es el genio que produce los gadgets futuristas con los que el espía más famoso del mundo logra sus objetivos, así que es curioso que AWS haya decidido llamar así a su agente.

En mi caso, mi primer encuentro con Q Developer me hizo darme cuenta de la capacidad que tenía para responder a mis preguntas con un contexto local.

El contexto: tenía un contenedor de docker que no acababa de arrancar, y mi workflow para ese tipo de problemas es relativamente sencillo, entra en el contenedor, busca un fichero de logs e intenta entender por qué falla. Decidí darle una oportunidad a Q, y le pedí que intentara explicar por qué fallaba, le dije cómo se llamaba el contenedor, el path para los ficheros de logs, y p’alante.

La respuesta fue reveladora e incluso intimidante, entró sin problemas en el contenedor, buscó los ficheros, detectó e interpretó el error, lo procesó y me dio varias posibles explicaciones. Eso para mí marcó un antes y un después porque significa que los agentes pueden trabajar localmente con tus ficheros y tu código, y vivir en tu línea de comandos.

Desde entonces he usado Q en línea de comandos para diferentes actividades como liberar espacio en el disco duro encontrando los repositorios más pesados (sin tener que aprenderme de memoria los parámetros de df y du de linux), o explorar repositorios para tener un primer vistazo de lo que hacen, hasta tal punto que ahora vive permanentemente en un terminal en mi escritorio. También he usado Q como extensión de navegador para resumir documentos largos y generar feedback sobre contenido web.

Agentes e IDEs: Descubriendo Cline, delegando a la IA

La siguiente fase de interacción era con los IDEs, y me recomendaron repetidamente que probara Cline con Visual Studio Code. Tras muchos años usando IntelliJ con Java no tenía demasiado interés en cambiar de herramienta pero desde hace un par de semanas le he estado dando una oportunidad a Cline y como mismo me pasó con Q, puedo confirmar que tiene algo.

La premisa de Cline es simple: es un chatbot dentro de tu IDE que, además de contestar preguntas sobre tu código, te propone mejoras. En las últimas dos semanas lo he usado para automatizar la generación de tests, hacer pequeños refactors de métodos (especialmente copiando o moviendo funcionalidad entre repositorios), y pedirle feedback de mi código antes de mandarle una pull request.

Una funcionalidad que no me esperaba es la integración con el navegador, lo que me permitió generar pequeños prototipos con TamperMonkey (accede a una web, inicia sesión con el usuario XX y la contraseña ZZ y usa TamperMonkey para agregar un nuevo botón debajo del botón Y que saque un «alert» al pulsarlo).

Los resultados no son perfectos, pero definitivamente han sido un empujón de productividad que me han hecho (y me harán) invertir más tiempo en VS Code.

Una de las revelaciones de este paradigma es que baja la resistencia a hacer tareas monótonas o aburridas como migraciones o agregar tests a bases de código existentes, y que ahora podemos delegar a los agentes siempre y cuando validemos que lo que se genera tenga sentido.

Modo voz: Una vuelta de tuerca a Rubber duck programming

Como parte de mi inmersión en el mundo de IA generativa he empezado a escuchar algunas entrevistas y podcasts sobre el tema, y la más interesante hasta la fecha es la de Kent Beck en The Pragmatic Engineer. Una de las cosas que mencionaba era el uso de modo de voz para discutir un problema y terminar pidiendole a la IA que generara un código asociado, esto me ha hecho pensar en usar el modo de voz de Claude como una versión mejorada de rubber duck programming.

El concepto de rubber duck programming es que el acto de explicar un problema (aunque sea a un pato de goma) te permite entenderlo mejor y te ayuda a encontrar mejores soluciones.

En este caso tienes un «pato» que responde que te puede ayudar a centrar la idea y te puede ayudar a encontrar soluciones alternativas o soluciones que no se te habrían ocurrido a tí (pero se le han ocurrido a alguien, recordemos que se trata de un modelo entrenado con millones de líneas de código).

MCP: Hablando con servicios, la IA se encuentra con APIs reales

Mi último descubrimiento ha sido que los agentes no solo pueden interpretar tu código y ayudarte localmente, sino que además pueden interactuar con otros servicios a través del patrón MCP (Model Context Protocol), esto simplifica mucho la interacción con otros sistemas ya que no necesita usar el navegador.

Hasta ahora mi experiencia con MCPs ha sido muy limitada, pero este es un ejemplo: Tras enviar una pull request a un compañero que está en otra zona horaria, volvió aprobada al día siguiente con muchos pequeños comentarios (a veces referidos comunmente como nitpicks o nits). Como la pull request estaba aprobada, podía hacer merge y seguir adelante, o podía parar, corregir los comentarios y mandar otra. Decidí delegar a Cline (accede a esta Pull Request, y aplica localmente los comentarios).

El resultado fue espectacular y muestra la capacidad que tienen los agentes cuando los combinamos con otras herramientas, aunque es cierto que no va a funcionar siempre ni para todos los comentarios.

Conclusiones: No lo podemos ignorar

Además de las capacidades de generación de texto que no hemos hablado en este artículo, a fecha de hoy hay un ecosistema de herramientas de IA (web, CLI e IDE) que nos permiten ser mucho más productivos y reducen la barrera de entrada para tareas más tediosas y repetitivas.

Volviendo a la entrevista de Kent Beck que mencioné anteriormente Link una reflexión que me parece bastante acertada es que el valor intrínseco del código va a tender a disminuir, porque nuestra capacidad para generar código nuevo aumenta significativamente. Eso nos abre la puerta a probar cosas nuevas, experimentar, descartar opciones buenas pero no ideales, y en definitiva, iterar más rápido, lo que nos permitirá, siguiendo las ideas de Agile y XP, construir mejores sistemas.