Qué hace valioso a un desarrollador hoy: lo que dicen los datos y el debate de este mes

Abrís un aviso de trabajo y pide “experiencia con agentes de IA”, “criterio para revisar código generado” y “visión de producto”. Del framework que estudiaste el año pasado, ni una palabra. En tu trabajo actual, el agente de código escribe la mitad de lo que antes escribías vos, y empezás a preguntarte qué es lo que te pagan por hacer.

En las últimas dos semanas aparecieron datos y discusiones que ayudan a contestar eso. Los avisos para desarrolladores vuelven a crecer, pero solo para cierto perfil; una de las empresas que más difundió las entrevistas de algoritmos pidió disculpas por ellas; y uno de los programadores más respetados del oficio abrió un debate sobre qué perdés cuando le delegás el trabajo a una IA. Abajo está lo que dicen, y seis habilidades concretas que hoy separan a un desarrollador valioso del resto, cada una con una forma de practicarla esta semana.

Lo que dice el mercado

El 11 de octubre, CNBC reunió los datos más recientes del mercado laboral (abre en una pestaña nueva) para desarrolladores en Estados Unidos, que suele marcar la tendencia:

• Los avisos subieron casi un 15 % desde fines de febrero de 2025, mientras que el total de avisos de todos los rubros bajó un 7 %, según Indeed. Ojo: siguen un 27 % por debajo de antes de la pandemia.
• La suba no es pareja. El 71 % del aumento vino de puestos para gente con experiencia, y el 37 % de puestos con “IA” en el nombre.
• Para los que empiezan, está más difícil. El empleo de desarrolladores de 22 a 25 años cayó casi un 20 %, según la Universidad de Stanford.
• Los agentes ya son parte del trabajo diario. Según GitHub, uno de cada tres pull requests (los pedidos para sumar un cambio al código principal) ya pasa por un agente de IA. Hace un año era menos de uno de cada diez.

La lectura que hace la propia nota es que la IA no está eliminando la demanda de desarrolladores, sino cambiando qué se le pide a cada uno: los avisos hablan de verificar la calidad de lo que genera la IA, corregir sus errores e integrarlo en sistemas que ya existen.

Lo que cambia en las entrevistas

El 12 de octubre, Vivek Ravisankar, cofundador y director de HackerRank, una de las plataformas que más usan las empresas para tomar exámenes técnicos, publicó una disculpa (abre en una pestaña nueva). Dijo que su empresa ayudó a normalizar un tipo de entrevista que se volvió “meses de practicar ejercicios con poca conexión con el trabajo real”: los problemas de algoritmos al estilo de LeetCode.

Lo que anunció en su lugar es más interesante que la disculpa. Las evaluaciones van a pasar a tareas sobre un repositorio real, con un agente de IA disponible, y lo que se mide ya no es solo si el código funciona, sino cómo usás la IA y si sabés darte cuenta de cuándo lo que generó está mal. En la discusión hubo bastante escepticismo, con razón: es una empresa que vende exámenes y está cambiando el producto. Pero la dirección coincide con los avisos: lo que se evalúa empieza a parecerse al trabajo de verdad.

El debate de la semana: ¿herramienta o automatización?

Un día antes, el 11 de octubre, Rich Hickey, creador del lenguaje Clojure y una de las voces más escuchadas sobre diseño de software, publicó un ensayo titulado “‘AI’ is Not a Tool” (abre en una pestaña nueva) (“La ‘IA’ no es una herramienta”). Su argumento: una herramienta es algo que manejás vos, con control y viendo el resultado mientras trabajás, como un martillo o un editor de texto. Con un modelo de IA, en cambio, pedís algo y el modelo lo hace solo. Por eso, dice, no es una herramienta con la que escribís código, sino “automatización con la que evitás escribir código”. Y lo que más le preocupa es lo que se pierde: lo que aprendés manejando una herramienta es algo sobre el mundo, y eso no pasa si el trabajo lo hizo otro.

Al día siguiente, un programador que firma como Huahai le respondió con un ensayo (abre en una pestaña nueva) que fue uno de los más discutidos de la semana entre desarrolladores, con más de quinientos comentarios en Hacker News. Acepta parte del diagnóstico, pero no la conclusión: un modelo sí se puede manejar, y manejarlo bien es una habilidad. La frase que lo resume: “las herramientas amplifican el mal criterio tanto como el bueno”.

Fijate en lo que comparten los dos. Ninguno dice que la IA sea inútil, y ninguno dice que alcance con usarla. Los dos dicen que si le delegás el trabajo sin entenderlo, perdés. Ahí está la respuesta a qué te hace valioso: no saber usar la IA, que cualquiera aprende en una tarde, sino tener el criterio para dirigirla y para darte cuenta de cuándo se equivoca.

Seis habilidades que hoy valen más

1. Leer y revisar código que no escribiste

Si un tercio del código ya pasa por un agente, alguien tiene que leerlo. Un estudio de Harvard que se discutió esta misma semana mostró que, con agentes, se escribe un 30 % más de código pero la revisión se volvió el cuello de botella. La persona que encuentra rápido el error escondido en un cambio de doscientas líneas es la que destraba al equipo.

Para practicarlo: la próxima vez que el agente te entregue un cambio, no lo aceptes hasta poder explicar cada archivo que tocó. Esta lista te dice qué mirar.

2. Explicar con claridad qué querés

Un agente hace lo que entendió, no lo que quisiste decir. Quien escribe un pedido claro (qué hay que hacer, qué no hay que tocar y cómo se sabe que está terminado) recibe un resultado que sirve en el primer intento. Es la misma habilidad que siempre hizo falta para trabajar con otras personas, pero ahora la usás veinte veces por día.

Para practicarlo: antes de tu próxima tarea con el agente, escribí cinco líneas con esas tres cosas. En este artículo hay una plantilla.

3. Verificar, no confiar

El criterio de HackerRank y el de los avisos coinciden: saber si lo que generó la IA está bien. Eso no se hace mirando el código con buena voluntad, sino con pruebas. Hace unos días, alguien hizo que un agente reescribiera el compilador de TypeScript entero sin leer el código, y funcionó porque tenía 184.749 pruebas que decían qué estaba bien.

Para practicarlo: en tu próxima tarea, escribí la prueba antes de pedirle el código al agente. Si no sabés qué prueba escribir, todavía no entendés bien qué le estás pidiendo.

4. Entender el sistema entero, no solo tu parte

Un agente escribe muy bien una función aislada. Lo que no ve es que esa función se llama dentro de un bucle y termina haciendo trescientas consultas a la base de datos por cada página. Saber cómo se conectan las piezas (la base de datos, la red, los costos, qué pasa en producción) es lo que permite detectar ese tipo de problema antes de que llegue a los usuarios.

Para practicarlo: elegí una pantalla de tu aplicación y seguí un pedido de punta a punta: qué consultas hace, qué servicios llama y cuánto tarda cada paso.

5. Conocer el negocio, no solo el código

Un agente no sabe que tu empresa factura distinto los fines de mes, ni que un cliente grande depende de un campo que parece no usarse. Esa información no está en el código; la sabés vos porque hablaste con la gente. Cuanto más fácil es escribir código, más vale saber qué código escribir.

Para practicarlo: en la próxima tarea, preguntá por qué existe antes de empezar. Muchas veces la respuesta cambia lo que hay que hacer.

6. Seguir aprendiendo, aunque la IA pueda hacerlo por vos

Este es el punto de Hickey, y es el más fácil de perder. Si el agente resuelve todo lo nuevo que te toca, en un año sabés lo mismo que hoy, y tu criterio para revisarlo no crece.

Para practicarlo: cuando tengas que usar una librería o un concepto que no conocés, escribí vos la primera versión, aunque tardes más. Después pedile la suya al agente y compará. Esa diferencia es exactamente lo que estás aprendiendo.

Si estás empezando

Los datos no esconden que la puerta de entrada se achicó. Pero lo que buscan las empresas también es más claro que antes: alguien que use la IA con criterio, no alguien que la reemplace. Un proyecto personal donde se vea cómo revisaste lo que hizo el agente (qué le corregiste, qué pruebas escribiste, por qué tomaste cada decisión) muestra eso mejor que cien ejercicios de LeetCode resueltos.

Escribir código dejó de ser lo escaso

Durante años, el valor de un desarrollador se medía en cuánto código podía escribir y qué tan rápido. Hoy eso lo hace un agente en minutos. Lo que sigue siendo escaso es saber qué hay que construir, darse cuenta de cuándo algo está mal y entender lo suficiente como para dirigir el trabajo. Esas habilidades no se vuelven viejas con la próxima versión del modelo, y por eso son las que vale la pena practicar.