Para desarrolladores y desarrolladoras, la IA ya no es solo una curiosidad. Ahora forma parte del trabajo diario. Genera código, sugiere dependencias, responde preguntas y cada vez realiza más tareas sola. Sin embargo, no queda tan claro qué habilidades de IA necesita un desarrollador para aprovecharla sin causarse problemas.
Y no es solo una impresión personal, me apoyo en la Stack Overflow Developer Survey 2025, con más de 49.000 respuestas, muestra que el 84% de los desarrolladores usa o piensa usar herramientas de IA. El año pasado era el 76%. Pero el dato interesante es que el otro 46% desconfía de la precisión de lo que esas herramientas le devuelven. En 2024 era el 31%. Vamos a repasar las siete habilidades que hoy marcan más la diferencia. Las definimos brevemente, para que esto sirva como guía a la que volver en
cualquier momento.
- Dar contexto: la petición es la mitad del trabajo.
- Revisar y verificar el código generado.
- Testear lo que produce la IA.
- Poder volver atrás: Git y CI/CD como red de seguridad.
- Saber cuándo hace falta RAG y cuándo no.
- Trabajar con agentes: loop, harness y herramientas conectadas.
- Seguridad del código y las dependencias generadas.
Qué vas as ver en esta entrada
Por qué la IA ha movido el cuello de botella
DORA es el equipo de investigación de Google Cloud que publica cada año el informe de referencia del sector sobre entrega de software. Su edición de 2025, elaborada a partir de cerca de 5.000 profesionales, resume el fenómeno con una idea muy útil: la IA es un amplificador. Acelera a los equipos que ya tenían buenas prácticas y magnifica los problemas de los que no las tenían. De hecho, detecta que la adopción de IA mejora el ritmo de entrega, pero mantiene elevada la inestabilidad: más fallos en los cambios, más retrabajo y más tiempo para resolver incidencias.
Traducido al día a día, el cuello de botella se ha movido. Ya no está en teclear, sino en la revisión, en las pruebas y en la coordinación entre personas. Ahí es donde se juegan de verdad las competencias que diferencian a un perfil.
Conforme adquieres más experiencia, te das cuenta que todos sabemos desarrollar, pero una cosa es desarrollar sin una lógica y un patrón claros y, otra es tener unos cimientos sólidos y saber en qué punto estás en cada momento, para así, no ser uno mismo el cuello de botella
Antes de las skills: el loop y el harness
El loop, el bucle que ejecuta un agente. No es un modelo que responde una vez y calla, sino un ciclo:
- Recibe un objetivo y el contexto disponible.
- Decide el siguiente paso y llama a una herramienta: leer un fichero, editar código, ejecutar un comando, lanzar los tests.
- Observa el resultado real de esa ejecución.
- Ajusta el plan con esa información.
- Repite hasta cumplir el objetivo o agotar el presupuesto de tiempo, intentos o tokens.
Lo importante está en el paso 3. Un modelo convencional solo escribe y trabaja a ciegas, uno se encarga de ejecutar y otro lee la salida. Por eso un agente que puede lanzar la suite de tests rinde muchísimo más que uno que únicamente propone código.
El harness, que es todo lo que rodea al modelo para que ese bucle exista, qué herramientas le expone, cómo gestiona el contexto cuando crece y hay que descartar cosas, cómo ejecuta las llamadas, qué permisos aplica, dónde corre el código y cuándo se detiene. Claude Code, Codex, Cursor en modo agente o Aider son harnesses distintos montados sobre modelos parecidos, y buena parte de la diferencia de resultados entre ellos viene del harness, no del modelo.
Las skills de IA que conviene dominar
1. Dar contexto: la petición es la mitad del trabajo
La diferencia entre una respuesta genérica y una que encaja en tu proyecto casi nunca está en el modelo, sino en el contexto que le has dado: los ficheros relevantes, las convenciones del repositorio, las restricciones reales y qué considerarías una solución correcta. La mayoría de las herramientas ya permiten fijar esas reglas en un fichero del propio proyecto, para no repetirlas en cada conversación.
2. Revisar y verificar el código generado
Dado el auge de la IA, nuestro rol como desarrolladores/as tiende cada vez más a generar el código con ayuda de un agente. Pero, y aquí hago el gran inciso, no deberíamos confiar al 100 % en todo lo que ese agente implementa. Revisar bien significa preguntarse en cada cambio qué casos no contempla, qué pasa si el dato llega vacío, si esa consulta escala o si rompe algo que ya funcionaba.
3. Testear lo que produce la IA
Cada vez desarrollamos y lanzamos productos más rápido, pero esa velocidad tiene un peaje. Cuando sube el ritmo y la cantidad de lo que se produce, en muchos casos baja la calidad. Saber escribir pruebas unitarias y de integración, entender qué merece la pena automatizar y qué no, y conocer herramientas como Playwright, Cypress, JUnit o pytest es hoy parte del trabajo de desarrollo, no un extra del equipo de QA. Si la velocidad de entrega sube y la capacidad de verificación no lo hace, el resultado es simplemente llegar antes a un fallo.
Hay además un motivo nuevo para tener buenos tests: son los ojos del agente. Si la suite se ejecuta rápido y falla de forma clara, el agente cierra el loop él solo. En el frontend esto se nota especialmente con Playwright, que a través de su servidor MCP permite que el agente abra el navegador, navegue por la aplicación, haga clic, lea los errores de consola y capture la pantalla. La diferencia entre un agente que supone que su cambio funciona y otro que lo comprueba en un navegador real es enorme.
4. Poder volver atrás: Git y CI/CD como red de seguridad
Trabajar en cambios pequeños, integrar a menudo y poder revertir sin drama es una de las prácticas que el informe DORA identifica como determinantes en entornos acelerados por IA. Dominar ramas, resolver conflictos sin miedo, entender un pipeline de CI/CD y saber hacer rollback valen tanto como conocer el último framework de moda.
Por ejemplo, hace poco tuve junto a mi equipo un problema con la base de datos y las versiones de algunos servicios en el proyecto de un cliente. Lo primero de todo, y recapitulando, era ponernos tanto mi equipo como el equipo del cliente de acuerdo en cada uno de los pasos, generando nuevas versiones, haciendo rollback de otras y para ello es importante entender qué es cada uno, en qué punto estamos y la comunicación.
5. Saber cuándo hace falta RAG y cuándo no
RAG (Retrieval-Augmented Generation) consiste en recuperar los fragmentos relevantes de tus propios datos y añadirlos a la petición, para que el modelo responda con información que no estaba en su entrenamiento. Es la solución cuando los datos son privados, cambian a menudo o necesitas poder citar la fuente.
No siempre hace falta: si la información cabe en el contexto o ya la sirve una API tuya, montar una base vectorial solo añade piezas que mantener. La skill es doble: saber decidirlo y, si lo montas, medir si la recuperación devuelve lo que debería.
6. Trabajar con agentes: loop, harness y herramientas conectadas
Sabiendo cómo funciona el loop, la skill concreta es diseñar lo que el agente puede hacer dentro de él. Ahí entra MCP (Model Context Protocol), el estándar abierto para conectar asistentes con las herramientas y los datos donde vive el trabajo real: el repositorio, el gestor de incidencias, la base de datos de desarrollo o el propio navegador.
Lo que hay que dominar no es la moda, sino los límites: qué permisos tiene el agente, dónde se ejecuta, qué puede tocar y cómo queda registrado lo que ha hecho. Un agente con acceso a producción y sin revisión es un incidente esperando su turno.
Y una regla práctica: cuanto más corto sea el bucle entre hacer y comprobar, mejor trabaja. Darle tests rápidos y un entorno donde ejecutarlos rinden más que cualquier prompt elaborado.
7. Seguridad del código y las dependencias generadas
Hay tres frentes. No filtrar secretos ni datos de cliente en las peticiones; asumir que el código generado puede traer vulnerabilidades clásicas y pasarle los mismos análisis que a cualquier otro; y vigilar las dependencias.
Este último es el menos conocido: los modelos se inventan paquetes. Un estudio presentado en USENIX Security 2025 analizó 576.000 muestras de código generadas por 16 modelos y encontró que cerca del 20 % de los paquetes sugeridos no existían. Como esas invenciones se repiten, alguien puede registrar el nombre con código malicioso y esperar a que lo instales. Comprobar que un paquete existe y quién lo mantiene antes de añadirlo ya es parte del trabajo.
Errores comunes al empezar
- Aceptar código que no sabrías explicar: Si no puedes defenderlo en una revisión, no sirve de nada la solución.
- Pedir ayuda sin dar el error real: Si no das contexto sobre el error, pruebas y datos reales, muchas veces genera datos sintéticos que no sirven para dar solución a un problema.
- Instalar lo que sugiere sin comprobarlo: Es justo el hueco por el que entra el problema de las dependencias inventadas.
Preguntas frecuentes sobre las skills de IA para desarrolladores
Saber dar contexto, revisar y verificar el código generado, testearlo, poder revertir cambios con seguridad, decidir cuándo hace falta RAG, entender cómo funcionan el loop y el harness de un agente, y controlar la seguridad del código y las dependencias.
No para integrarla y utilizarla a diario como un simple chat donde preguntas y recibes respuestas.
Entrenar modelos y usarlos son trabajos distintos, si tu objetivo es entrenar modelos y tener flujos de trabajo, al menos, conviene tener ciertas nociones para mejorar y saber cómo entrenar tus propios modelos o adaptarlos para el propósito que tengas.
Un modelo convencional genera texto, mientras que el harness es el programa que le proporciona herramientas, ejecuta sus llamadas, gestiona el contexto y decide cuándo parar. Dos harnesses del mismo modelo pueden dar resultados muy distintos.
Conclusión
Al final no se trata de centralizar todo en las herramientas de IA, sino de tener un mayor criterio a la hora de pedir a esas herramientas que hagan, teniendo nosotros mismos el conocimiento suficiente para determinar si lo que generan es correcto o no.
Por tanto, me quedaría con una frase: menos prompts mágicos y más criterio a la hora de decidir y analizar. El contexto, la verificación, las pruebas y la capacidad de volver atrás son lo que sostiene un proyecto cuando la velocidad aumenta.