En el artículo anterior, dejando de lado mis aprendizajes de profesionales que usan LLMs para crear productos, hablábamos de modos de trabajo, y de cómo, tras usar herramientas como Cline, Q y últimamente Kiro, había llegado a estos dos modos de trabajo: Exploración y ejecución.

En el artículo de hoy veremos un tercer modo, que es la práctica, un modo que requiere separarnos de nuestro día a día y dedicar tiempo a aprender a trabajar con la herramienta en un entorno controlado.

¿Por qué?

El pasado jueves un compañero nos explicaba cómo usaba Cline para diferentes escenarios, y en el turno de preguntas salió el ya famoso estudio METR que daba como titular que «Los desarrolladores experimentados son in 19% más lentos con herramientas de IA».

Mi respuesta escéptica era que tendríamos que ver cuanta experiencia tenían los desarrolladores con este tipo de herramientas. En el propio artículo se mencionaba que el tiempo de formación en Cursor (la herramienta utilizada) era de 30 a 50 horas y que «los desarrolladores, [..] típicamente tienen de decenas a cientos de horas de experiencia previa usando LLMs».

Mi lectura personal es que «cientos de horas de experiencia previa usando LLMs» no sirven de mucho cuando comparamos con herramientas como Cursor, Windsurf, Github Copilot o Kiro, en el que la IA está dentro del IDE, de hecho en mi artículo original, hablaba de que mis experiencias con LLMs antes de la llegada de los agentes me había generado poco entusiasmo. Este escepticismo lo compartía también Gergely Orosz en su blog donde ponia de manifiesto que la curva de aprendizaje de estas herramientas es contra-intuitivamente larga.

Podemos comparar 50 horas de entrenamiento con las 500 horas aproximadas (entre formación y prácticas) que hizo una compañera en su bootcamp de código, las 3.000 horas aproximadas que gasté entre 2008 y 2012 en los laboratorios de la EPS estudiando Ingeniería Informática, o las 10.000 horas que Malcom Gladwell menciona que son claves para adquirir maestría en un área como tocar el piano. Aprender las cosas lleva tiempo, y puede que no le estemos dedicando el tiempo adecuado con la calidad adecuada.

Qué estamos aprendiendo exactamente?

Una de las cosas que necesitamos tener claro es qué tipo de interacción queremos tener con estas herramientas, y Yoav Tzfati lo definía como los diferentes estadios del «vibe coding»:

1. IDE Tradicional + autocompletado con IA
2. Modo Agente – le pedimos al agente una funcionalidad, pero no damos detalles de implementación.
3. Creación de Proyectos – Generamos nuevos proyectos desde cero y luego miramos el código.
4. Herramientas Web – Generamos proyectos directamente desde el navegador (V0, Bolt.new)
5. Vibe Completo – solo lenguaje natural, despliegue de un clic (Claude Artifacts, replit)

Desde mi punto de vista, el cambio importante se produce cuando pasamos del estadio 1 al 2, y en menor medida al 3, ya que la manera de expresarnos cambia, así que, cómo aprendemos?

Coding Katas

El concepto de Katas aplicado al software no es algo nuevo, de hecho fue algo que yo personalmente descubrí hace 13 años hablé de ello en el blog y he usado frecuentemente para aprender lenguajes o tecnologías, en la práctica es partir de un problema conocido y llegar a la solución en pasos cortos.

Una de las ideas detrás del desarrollo con agentes de IA es ser explícito a la hora de pedir una tarea, y hacer tareas cortas y especializadas, casi como usar «baby steps«, un concepto compartido por las Katas y por TDD (Test-Driven development, una práctica en la cual cada ciclo empieza escribiendo un test que falle y continúa escribiendo la mínima cantidad de código para que pase ese test).

Mi objetivo se convirtió que el LLM produjera la mínima cantidad de código de test para que falle, y la mínima cantidad de código de producción para que el test pase, y mi campo de pruebas fue la Bowling Kata usando Claude Code

Para ello, fui explícito al principio de la sesión con la siguiente prompts:

"from now on we will be using TDD, so when I ask you to write a test, it might fail, and it's ok"

Luego, a la hora de implementar los diferentes pasos, fui explícito en qué quería implementar:

- "TEST ONLY: User can only throw up to 10 pins after two throws, any combination higher than 10 results in an error"

Tras varias iteraciones (30), conseguí un código que cumplía con mi interpretación de la kata, lleno de tests unitarios, y con una lista de prompts que generaban ese código.

Como curiosidad, una vez tenía la lista de prompts, las guardé en un fichero, y se las volví a pasar a Claude. El resultado fue un código bastante parecido al primero que había generado paso a paso. Posteriormente, borré el código y le pedí a claude que generara tres versiones código nuevo que fuera consistente con los test, y los resultados variaban espectacularmente

Puedes ver la lista de prompts en este Gist de GitHub

Lecciones aprendidas

Mi aprendizaje principal es que el LLMs es testarudo, y pese a mis esfuerzos, en más de una ocasión hacía un poco más de lo que yo le pedía, esto forma parte de la naturaleza probabilística de los modelos, pero es algo para lo que tenemos que estar preparados cuando trabajamos con estas herramientas.

Sin embargo, podemos reducir significativamente la incertidumbre siendo explícitos con los requisitos y las restricciones, y metodologías como TDD nos permiten codificar estas restricciones, limitando el rango de acción de los LLMs.

Siguientes pasos: Refactor

Este ejercicio ha sido muy útil para trabajar con un agente a la hora de generar código nuevo, pero en nuestro día a día una gran parte de nuestro trabajo es modificar código existente. Para ello, me he ido al estadio 3 de vibe coding y le he pedido a Claude que me genere un clon de twitter con un frontend y un backend completo.

Mi objetivo, lejos de poner este código en producción, es usarlo como campo de pruebas para aplicar lecciones de libros como Refactoring, Working Effectively with Legacy Code o Tidy First?, el nuevo libro de Kent Beck.

En el siguiente artículo veremos qué tal me ha ido aplicando algunas prácticas de refactoring a un código en el que a efectos prácticos estoy viendo por primera vez, y que es un patrón que hemos visto muchas veces en un entorno profesional. Qué aproximación hacemos a este código nuevo? Cual es el alcance de los cambios? Podremos cubrirlo con tests? Todo esto y más, en la parte 6.