Dejé de escribir código y empecé a escribir pruebas: la nueva regla de trabajar con IA

El video abre con una confesión honesta: el narrador dice que casi no ha escrito código a mano en seis meses y que su forma de trabajar ha cambiado fundamentalmente — y calibra las expectativas del espectador en consecuencia. No es una jactancia de productividad sino el anuncio de un cambio de rol; el trabajo del desarrollador ha pasado de pulsar teclas a decidir qué se construye.

Empezó un trabajo nuevo hace cuatro meses donde el equipo usa Angular, y tras años trabajando con React, primero se preguntó cómo cerraría esa brecha. La brecha se cerró rápido: con IA generativa se familiarizó con el nuevo framework y llegó a un punto de entregar sin una sola línea escrita a mano. La afirmación aquí es que la IA reduce el umbral de aprendizaje; mi lectura es que donde el umbral baja, la necesidad de supervisión sube.

Su flujo diario funciona así: una suscripción a Claude de límite alto proporcionada por su empleador —según su propio relato, una cuota que no pueden agotar— más el plan Max sobre la mesa. Cada ticket entrante se divide primero en partes, se analiza mediante preguntas y respuestas con Claude, y solo entonces se resuelve. La parte de generación termina en unos 45 a 50 minutos; el video dice que el problema real empieza después.

El punto de quiebre es la sensación de pertenencia: en un trabajo nuevo tiene que responder por lo que produce y explicar por qué las cosas se construyeron como se construyeron. Generar sin pensar no da alegría ni gana el salario, y el equipo lo nota. Ahí es donde el video plantea su tesis: en la era de la IA, la importancia de escribir pruebas se ha multiplicado.

La tesis no queda en el aire; llega con el respaldo de su pasado. El narrador trabajó anteriormente en software de tractores y realizaba pruebas que incorporaban el hardware al bucle — pruebas unitarias, de regresión y de extremo a extremo ejecutadas en un banco que se parecía mucho a la máquina real. Donde probar cada pequeño cambio en el campo es imposible, las pruebas eran la única base de confianza. La producción de la IA de hoy ocupa la misma posición: no se puede inspeccionar cada línea a simple vista, así que uno se apoya en las pruebas.

El ejemplo concreto pasa por un ticket de seguimiento de trabajo: la funcionalidad solicitada y los enfoques sugeridos están bien redactados, y Claude lo toma y lo resuelve en menos de una hora. Pero la pregunta sigue en pie: ¿cómo sé que esta solución realmente funciona? Su respuesta es una habilidad basada en pruebas que construyó dentro de Claude: divide cada frase del ticket en piezas comprobables, le hace escribir pruebas unitarias limpias para todo lo que el usuario debería ver al pulsar un botón, y añade pruebas que reproducen el problema reportado por el usuario. Un solo ticket produce seis o siete pruebas entendidas tanto por él como por el modelo.

Luego el bucle se invierte: con una instrucción de «escribe el código hasta que estas pruebas pasen» el modelo se suelta, y sale una solución que satisface las pruebas. Dice que puede explicar esta solución al cien por ciento, y que el modelo también entiende el tema. Dos directrices prácticas llegan como bonus: pedir una solución mínima y hacer que elimine las líneas de comentarios innecesarias. Sin storytelling — resuelto es resuelto.

El marco conceptual del video es el problema de satisfacción de restricciones: las pruebas son las constantes, y el trabajo del modelo es encontrar código que satisfaga esas constantes antes de que se agote el presupuesto de tokens. Dice que ha aplicado esta disciplina intensamente durante cuatro meses, escribiendo de 150 a 200 pruebas unitarias por adelantado para las aplicaciones nuevas, y las pruebas lo detectan cada vez que el modelo alucina. Cierra preguntando a los espectadores cómo usan la IA y cómo ha cambiado sus vidas. Su propia respuesta es nítida — es feliz, porque puede demostrar los resultados.