En mi día a día como desarrollador web, he incorporado Claude Code como una herramienta que ha cambiado la forma en la que trabajo (en especial con código legacy). Pero donde muchos hablan de «vibe coding» a mi me gusta el código reflexivo.
No lo trato como un copiloto automático ni como un generador de soluciones “plug and play”. De hecho, lo uso casi en el extremo opuesto: como si fuera un desarrollador junior al que hay que guiar, cuestionar y supervisar constantemente.
Trabajo siempre con la opción de “Aprobar las ediciones” activada. Esto no es un detalle menor, es el núcleo del proceso. Cada cambio pasa por mi filtro. Cada línea se revisa. Cada decisión técnica se somete a juicio. No porque desconfíe, sino porque quiero entender exactamente qué está ocurriendo.
Esta forma de trabajar tiene un objetivo claro: evitar la ilusión de productividad. Es fácil caer en la trampa de aceptar cambios que “parecen correctos”, especialmente cuando la herramienta genera código limpio, estructurado y aparentemente alineado con buenas prácticas (se supone que tiene un modelo entrenado con mucho buen código). Pero apariencia no es garantía. Por eso, en lugar de aceptar soluciones, las analizo.
Cuando Claude propone una refactorización, no me limito a comprobar si funciona. Me pregunto: ¿Qué problema está resolviendo realmente? ¿Está simplificando o solo reorganizando complejidad? ¿Este patrón tiene sentido en este contexto concreto? ¿Ha tenido en cuenta todo el proyecto? (a veces hay cosas que no encuentra).
Por eso mi enfoque de “tratarlo como un junior” cobra sentido. No porque la herramienta sea limitada, sino porque ese marco mental me obliga a mantener una actitud activa. Le doy dirección, le pido que justifique decisiones, reflexiono y le hago iterar en sus soluciones, afinándolas juntos.
Sin embargo, este enfoque tiene un punto ciego: un junior humano puede detectar inconsistencias en requisitos o incluso cuestionar decisiones del senior desde su desconocimiento del proyecto (lo cual se agradece mucho). Pero con Claude, si no lo empujas explícitamente, tenderá a complacer y a construir sobre tus propias suposiciones, incluso si son erróneas. Por eso una de mis directrices muchas veces con los agente de IA es que pongan en duda mis planteamientos. Aún así la responsabilidad del pensamiento crítico recae completamente en mi.
En el contexto de refactorización de código legacy, esta dinámica es especialmente útil. Claude suele destacar en identificar patrones repetidos, proponer separaciones de responsabilidades (y realizarlas sin romper nada por el camino), aplicar convenciones modernas y buenas prácticas, sugerir mejoras de legibilidad y a favor de un código más fácilmente mantenible.
Pero también puede fallar en aspectos más profundos que hay que controlar como entender reglas de negocio implícitas, detectar dependencias ocultas (que no estén explicitamente declaradas).
Por eso, más que delegar, lo utilizo como amplificador de mi propio proceso de pensamiento. No le pido soluciones finales. Le pido propuestas. Y a partir de ahí, construyo, corrijo o descarto. Suele ser habitual tareas grandes pedir primero un plan de trabajo, que matizar o corregir, ampliando la información que tiene o tomando yo mismo decisiones.
Este enfoque tiene el coste de un desarrollo más lento que aceptar cambios sin cuestionarlos. Sin embargo mi copiloto ya ha conseguido aumentar mi velocidad de desarrollo. Y, a cambio, evita deuda técnica invisible y, sobre todo, mantiene el control intelectual del código. Y como añadido, voy aprendiendo mejores prácticas o voy reflexionando sobre como obtener un proyecto más sostenible. Porque el verdadero riesgo no es que la IA se equivoque. Es que dejemos de pensar.
No responses yet