Qué significa de verdad un desarrollador «preparado para IA»: una definición técnica
Hoy todas las empresas de nearshore, agencias de talento y plataformas de selección afirman ofrecer desarrolladores «preparados para IA». El término se ha vaciado de significado: una etiqueta de marketing que se cuelga a cualquiera que haya oído hablar de ChatGPT.
Y eso es un problema, porque la preparación para la IA es una competencia real y evaluable, la que separa a los ingenieros que convierten la IA en velocidad de entrega de los que la convierten en una fábrica de errores más rápida. Tratarla como una palabra de moda perjudica a las empresas que necesitan contratar ingenieros capaces de usar de verdad las herramientas de IA en producción.
Así que esto es lo que quiero decir cuando hablo de «preparado para IA» a nivel de ingeniería: no un eslogan, sino el conjunto de habilidades verificables, con criterios de evaluación concretos, que comprobamos en cada ingeniero que entra en la red de Conectia.
Las seis competencias
1. Soltura con las herramientas de IA
Qué significa: La capacidad de usar asistentes de programación con IA — Copilot, Cursor, Claude, Cody y similares — como parte natural del flujo de trabajo de desarrollo. No de vez en cuando. No a modo de experimento. Como procedimiento operativo estándar.
Cómo se traduce en la práctica:
Un ingeniero con soltura en IA usa estas herramientas para generar código repetitivo, escribir tests, documentar, refactorizar, explicar código y depurar. Conoce las fortalezas y limitaciones de cada herramienta. Cambia de una a otra según la tarea: Copilot para autocompletado en línea, Claude para razonamiento complejo y discusión de arquitectura, Cursor para refactorizaciones que abarcan todo el código base.
Cómo evaluarlo:
Dale al ingeniero una tarea real de refactorización y observa su flujo de trabajo. ¿Recurre a las herramientas de IA con naturalidad? ¿Aporta contexto eficaz (referencias a archivos, restricciones, ejemplos) para obtener resultados útiles? ¿Itera sobre los resultados en lugar de aceptar la primera respuesta?
El mínimo exigible: Un ingeniero senior en 2025 que no usa de forma habitual herramientas de programación con IA está dejando escapar una parte seria de su productividad. No es una cuestión de preferencias: es capacidad profesional.
2. Ingeniería de prompts
Qué significa: La capacidad de escribir prompts que obtengan de los LLM resultados útiles, precisos y adecuados al contexto. Es una habilidad distinta de escribir código: exige entender cómo procesan instrucciones los modelos de lenguaje, qué contexto necesitan y cómo estructurar las peticiones para obtener resultados fiables.
Cómo se traduce en la práctica:
Un ingeniero que domina el prompting aporta contexto del sistema, especifica el formato de salida, incluye restricciones y casos límite, y usa ejemplos cuando hace falta. Descompone las tareas complejas en pasos en lugar de escribir prompts monolíticos. Sabe cuándo conviene un prompt de cadena de razonamiento y cuándo una instrucción directa.
Para la generación de código en concreto, incluye: el lenguaje y framework de destino, el contexto de código relevante, las convenciones de nomenclatura, las expectativas de manejo de errores y los requisitos específicos que el código generado debe cumplir.
Cómo evaluarlo:
Pide al ingeniero que use una herramienta de IA para generar una pieza de código de complejidad media — una clase de servicio, un endpoint de API con validación, un pipeline de procesamiento de datos. Evalúa los prompts que escribe, no solo el resultado. ¿Aportó contexto suficiente? ¿Acotó la salida como tocaba? ¿Iteró cuando el primer resultado no era el correcto?
El mínimo exigible: Un ingeniero que pega «escríbeme una función que haga X» y acepta lo que salga no domina el prompting. La habilidad está en la especificidad y en la iteración.
3. Criterio crítico (la competencia más importante)
Qué significa: La capacidad de evaluar lo que genera la IA con el mismo rigor que aplicarías al pull request de un desarrollador junior — porque ese es el nivel de confianza apropiado.
Cómo se traduce en la práctica:
Un ingeniero con buen criterio revisa cada línea de código generado por IA antes de hacer commit. Comprueba:
- Corrección lógica — ¿el código hace de verdad lo que se pidió, casos límite incluidos?
- Implicaciones de seguridad — ¿la IA ha introducido una vulnerabilidad (inyección SQL, validación de entrada deficiente, credenciales expuestas)?
- Encaje arquitectónico — ¿el código generado sigue los patrones del proyecto o ha introducido una inconsistencia?
- Cobertura de tests — ¿los tests generados por IA prueban comportamiento significativo o solo detalles de implementación?
- Higiene de dependencias — ¿la IA ha sugerido importar una librería que introduce un riesgo de cadena de suministro o un conflicto de licencia?
Cómo evaluarlo:
Presenta al ingeniero código generado por IA con errores sutiles — un off-by-one en la lógica de paginación, una condición de carrera en un handler asíncrono, una consulta SQL vulnerable a inyección en un caso límite. ¿Encuentra los problemas? ¿Cómo de rápido? ¿Sabe dónde mirar?
El mínimo exigible: Esta es la competencia que separa la ingeniería asistida por IA productiva de la peligrosa. Un ingeniero que se fía de la salida de la IA sin revisarla pone errores en producción más rápido que uno que lo escribe todo a mano.
4. Sentido arquitectónico en un contexto de IA
Qué significa: Entender cómo deben influir las capacidades y limitaciones de la IA en las decisiones de diseño de un sistema.
Cómo se traduce en la práctica:
Un ingeniero preparado para IA con nivel de arquitecto sabe razonar sobre:
- Dónde la integración de un LLM aporta valor genuino y dónde solo añade complejidad sin un beneficio proporcional
- Las implicaciones operativas de los sistemas que dependen de un LLM: latencia, coste, fiabilidad y los modos de fallo propios de los componentes de IA
- Cuándo usar un modelo preentrenado, cuándo fine-tuning, cuándo RAG (generación aumentada por recuperación) y cuándo lógica tradicional basada en reglas
- Cómo diseñar sistemas que se degraden de forma controlada cuando los componentes de IA fallan o producen salidas inesperadas
- La arquitectura de costes de los sistemas con IA integrada: consumo de tokens, almacenamiento de embeddings, infraestructura de inferencia
Esta competencia no se le exige a todos los ingenieros de un equipo — pero al menos un ingeniero senior o líder técnico debería tenerla.
Cómo evaluarlo:
Plantea un escenario de producto que podría resolverse integrando IA y pide al ingeniero que diseñe el enfoque técnico. Evalúa si considera alternativas a las soluciones basadas en LLM, si aborda los modos de fallo y si piensa en costes operativos y fiabilidad.
5. Conciencia de seguridad en el desarrollo asistido por IA
Qué significa: Entender los riesgos de seguridad específicos que las herramientas de IA introducen en el proceso de desarrollo.
Cómo se traduce en la práctica:
Un ingeniero preparado para IA y consciente de la seguridad entiende:
- Los riesgos de inyección de prompts en funcionalidades de IA expuestas al usuario — y diseña en consecuencia la validación de entrada y la sanitización de salida.
- La fuga de datos a través de herramientas de IA — no pegar código propietario ni datos de clientes en servicios de IA públicos.
- Los riesgos de las dependencias generadas — las herramientas de IA sugieren con frecuencia importar paquetes desactualizados, abandonados o con vulnerabilidades conocidas. El ingeniero verifica las dependencias antes de añadirlas.
- La exposición de credenciales — las herramientas de IA que operan sobre el código base pueden sacar a la luz, sin querer, patrones con secretos hardcodeados, o sugerirlos. El ingeniero mantiene hábitos disciplinados de gestión de credenciales.
- Los límites de cumplimiento normativo — saber qué código o datos pueden procesarse con herramientas de IA y cuáles no, sobre todo en sectores regulados (salud, finanzas, administración pública).
Cómo evaluarlo:
Pide al ingeniero que describa sus prácticas de uso de herramientas de IA en un contexto sensible en seguridad. ¿Tiene límites claros? ¿Sabe articular los riesgos de flujos de trabajo concretos asistidos por IA?
6. Comunicación de las decisiones asistidas por IA
Qué significa: La capacidad de comunicar con transparencia cuándo y cómo se usaron herramientas de IA en el trabajo de desarrollo.
Cómo se traduce en la práctica:
Un ingeniero con esta competencia documenta el uso de herramientas de IA donde es relevante. En las descripciones de los pull requests, indica cuándo partes significativas del código fueron generadas o asistidas por IA, y describe la revisión y modificación humanas que aplicó. En los registros de decisiones de arquitectura, deja constancia de cuándo las herramientas de IA influyeron en el diseño.
Esto no va de confesarse: va de trazabilidad. Cuando aparece un error en producción, saber si una sección de código la escribió una persona, la generó una IA o la generó una IA y luego se modificó cambia el enfoque de la depuración.
Cómo evaluarlo:
Revisa las descripciones de PR y los hábitos de documentación del ingeniero. ¿Comunica con claridad su proceso de desarrollo? ¿Distingue entre el trabajo que escribió desde cero y el que desarrolló con asistencia de IA?
La matriz de evaluación
Para cada competencia, evaluamos en una escala de tres niveles:
| Nivel | Descripción | Implicación |
|---|---|---|
| Operativo | Usa herramientas de IA en su flujo de trabajo diario con criterio y eficacia demostrados | Listo para desarrollo asistido por IA en producción |
| En desarrollo | Usa herramientas de IA con cierta eficacia, pero con criterio inconsistente o un abanico limitado de herramientas | Necesita mentoría; aún no es fiable para trabajo autónomo asistido por IA |
| Ausente | No usa herramientas de IA de forma habitual, o las usa sin revisión crítica | Brecha de productividad significativa frente a sus pares con soltura en IA |
Un ingeniero validado por Conectia puntúa «Operativo» en las seis competencias. Ese es el listón que hay detrás de nuestra tasa de aceptación del 4%.
Por qué importa esta definición
La brecha entre un equipo con soltura en IA y uno sin ella se ensancha cada trimestre. A medida que las herramientas mejoran, los ingenieros que las usan con eficacia entregarán más rápido, producirán código de más calidad y costarán menos por funcionalidad entregada.
Las empresas que contratan ingenieros «preparados para IA» fiándose de una palabra de moda obtendrán resultados inconsistentes. Las que contratan sobre una competencia en IA verificable y multidimensional construirán equipos cuya ventaja se acumula con el tiempo.
Las seis competencias definidas aquí no son teóricas: son lo que evaluamos en cada ingeniero que entra en la red de Conectia. Son medibles, son entrenables, y marcan la diferencia entre la IA como multiplicador de productividad y la IA como fuente de errores sutiles y caros.
¿Quieres ver cómo se miden tus candidatos de ingeniería frente a estas seis competencias? Habla con un CTO para acceder a ingenieros preparados para IA, ya validados, que han superado esta evaluación.
