La clave no es demonizar la IA ni abrazarla sin criterio, sino saber cuándo delegar y cuándo pensar. El ajuste fino que mencionáis es un buen ejemplo: requiere entender el dominio y los datos, eso no lo hace la máquina por ti. Pero ojo, que la dependencia se cuela por otros lados: cuando dejas de leer documentación porque el asistente te la resume, o cuando aceptas un refactor sin revisar las implicaciones de diseño.
Mi estrategia es usar la IA como un compañero de pair programming: le pido alternativas, le cuestiono las decisiones y, sobre todo, le exijo que me explique las ventajas e inconvenientes de cada opción. Eso convierte la generación de código en un ejercicio de análisis, no de copiar y pegar. Si solo pides 'código que haga X', estás externalizando el razonamiento; si pides 'código que haga X pero compárame con Y y dime cuándo usarías cada uno', estás aprendiendo.
Otra cosa: los tests manuales son un buen antídoto, pero también hay que escribir tests de propiedad o invariantes que la IA no suele generar por defecto. Y para no perder la base, nada mejor que leer papers o fuentes primarias de vez en cuando, aunque tarden más. La IA acelera la ejecución, no la comprensión.
