Identifica las competencias que ganan valor a medida que la generación de código se vuelve corriente, y equípate para cultivarlas de forma deliberada.
Abrir esta lección en KodokonCuando una capacidad se vuelve corriente, su valor de mercado cae y se desplaza hacia lo que la rodea. La traducción escrita pasó por esto, y la fotografía también. Para el desarrollo, la capacidad convertida en mercancía es clara: producir código correcto a partir de una especificación precisa. Lo que gana valor de forma mecánica son los dos extremos de la cadena que la IA no cubre. Aguas arriba: la especificación, convertir una necesidad vaga, contradictoria y política en un problema bien planteado; es la competencia que todo usuario de asistentes redescubre a las malas, ya que un prompt no es más que una especificación cuya imprecisión pagas en cada punto. Aguas abajo: la verificación, revisión, pruebas, auditoría de seguridad, la capacidad de decir "este código plausible es erróneo"; se vuelve crítica precisamente porque el volumen de código plausible se dispara. Y por encima de ambas: la arquitectura, las decisiones estructurales cuyos efectos se miden en años y que el modelo, sin memoria de tu organización y sin responsabilidad sobre su consejo, no puede sostener.
El peligro para un senior no es el reemplazo, es la atrofia no detectada. Las competencias profundas declinan sin dolor: nada señala que tu capacidad de depurar sin ayuda o de diseñar una API desde cero se haya erosionado, hasta el día en que se requiere. La respuesta es una auditoría deliberada y regular de lo que ejercitas de verdad, en oposición a lo que crees que ejercitas. Es un uso deliciosamente contraintuitivo de la IA: usar el modelo para medir lo que el modelo te hace perder.
Eres mi coach de carrera técnica, directo y sin adulación. Aquí está el registro honesto de mi semana de trabajo con asistencia de IA:
- Tareas en las que produje el trabajo yo mismo (IA como revisora): [LISTA]
- Tareas delegadas por completo a la IA: [LISTA]
- Código aceptado sin ser capaz de explicarlo en detalle: [LISTA, aunque resulte incómodo]
- Decisiones técnicas tomadas esta semana: [LISTA]
Análisis en tres partes:
1. Competencias realmente ejercitadas esta semana (las que suben) frente a competencias delegadas (las que corren riesgo de atrofia).
2. Mi deuda de comprensión: cada elemento de la tercera lista, con su riesgo concreto asociado.
3. UN ejercicio de 30 minutos para la próxima semana, dirigido a mi competencia más frágil, para hacer sin ninguna ayuda.
Formato: evaluación en 10 líneas como máximo. Prefiero una crítica justa a un ánimo vago.Seguir siendo crítico también es una competencia que hay que trabajar. La postura correcta se llama confianza calibrada: ni la desconfianza sistemática que anula la ganancia de productividad, ni la confianza ciega que instala la complacencia. Calibrar significa ajustar la intensidad de la verificación a dos variables: el coste de un error (la regex de un script desechable y una política de autorización no merecen el mismo escrutinio) y la tasa de error observada del modelo en ese tipo de tarea, que solo conocerás verificando de verdad, al principio, todo lo que produce en tu dominio. Lleva esta cuenta durante unas semanas: sabrás dónde sobresale el modelo, dónde alucina, y tu vigilancia caerá exactamente donde rinde.
A partir de ahora y durante toda esta conversación, adopta el papel de mentor en lugar de ejecutor. Reglas permanentes:
1. Cuando te pida código, empieza por pedirme que proponga mi enfoque; presenta el tuyo solo después, comparándolo explícitamente con el mío.
2. Cuando me corrijas, enuncia el principio general que hay detrás de la corrección, no solo el arreglo puntual.
3. Una vez por respuesta, hazme una pregunta que compruebe que he entendido, y espera mi respuesta antes de continuar.
4. Si simplemente te pido que "lo hagas por mí", recuérdame esta instrucción y ofréceme la versión guiada.
Confirma que has entendido reformulando estas reglas en una sola frase.La empleabilidad, en el fondo, se reduce a una pregunta que todo reclutador de los próximos años hará: ¿qué aportas tú que el modelo no aporte? La respuesta defendible cabe en tres palabras vistas a lo largo de este recorrido: especificar, verificar, decidir; más un método: seguir aprendiendo en profundidad, con la IA como un tutor exigente y no como un dispensador de soluciones. Un desarrollador que entiende lo que despliega sigue siendo escaso y, por tanto, caro. Esa era la tesis de la primera lección; también es la conclusión del recorrido.