Lo que la IA puede y no puede hacer hoy en el desarrollo de software
El estado real de la IA en el ciclo de vida del software
*Artículo de lectura independiente agrupado en la serie “IA en la empresa: Expectativas vs. Realidad”*
Hay dos formas de hablar de la IA en el desarrollo de software que conviene evitar: el entusiasmo sin matices (“la IA lo hace todo mejor y más rápido”) y el escepticismo paralizante (“es humo, dentro de dos años nadie se acordará”).
La realidad de hoy día es más interesante que ambas posiciones y también más práctica: la IA es extraordinariamente buena en algunas cosas concretas y bastante mala en otras. El problema es que las empresas y los medios de comunicación tienden a hablar de la IA como si fuera una sola cosa homogénea, cuando en realidad hay una diferencia enorme entre lo que una IA hace bien y lo que se le pide que haga.
Este artículo intenta ser ese mapa de capacidades reales.
Los cinco niveles de integración de la IA en el desarrollo
Para entender dónde encaja la IA en el ciclo de vida del software (también llamado SDLC, de Software Development Life Cycle), es útil pensar en niveles de profundidad de integración. No todas las empresas están en el mismo nivel, y no todas necesitan estar en el más alto.
Nivel 1: Productividad individual (The Copilot Tier)
La IA vive en el editor de código del desarrollador. El humano tiene el control total: la IA sugiere, el humano decide.
Lo que hace bien: autocompletar código, generar funciones a partir de comentarios, explicar código ajeno, crear tests unitarios básicos, escribir documentación inicial.
Este es el nivel con el mejor ratio beneficio/riesgo para empezar. El impacto es inmediato y los errores son locales y fáciles de detectar antes de que lleguen al repositorio.
Nivel 2: Colaboración en equipo (The Peer Tier)
La IA sale del ordenador del desarrollador y entra en el espacio compartido del equipo. Los pull requests (solicitudes de fusión de código) son revisados también por IA: detecta errores lógicos, resume los cambios, sugiere refactorizaciones.
Valor: reduce la carga cognitiva de las revisiones humanas y acelera el tiempo hasta que el código se aprueba y fusiona. El revisor humano puede centrarse en los aspectos de alto nivel en lugar de en los detalles mecánicos.
Riesgo: si el equipo confía excesivamente en la revisión de la IA y relaja su propia revisión, pueden pasar errores que la IA no detecta —especialmente los que requieren entender el contexto del negocio.
Nivel 3: Control de calidad en el pipeline de CI/CD (The Gatekeeper Tier)
La IA se integra como un paso del pipeline de integración y despliegue continuo (CI/CD, del inglés Continuous Integration / Continuous Deployment). Aquí decide si algo avanza al siguiente entorno o se bloquea.
Capacidades destacadas:
- Testing predictivo: en lugar de ejecutar todos los tests siempre, la IA predice qué tests tienen más probabilidad de fallar dado el cambio concreto y solo ejecuta esos. Pipelines más rápidos.
- Puertas de calidad inteligentes: análisis de resultados de performance (rendimiento) para decidir si una versión es apta para pasar a producción.
- Detección contextual de vulnerabilidades: no solo encuentra vulnerabilidades conocidas, sino que evalúa si son explotables en el contexto concreto de la aplicación.
Riesgo: este es el primer nivel donde la IA puede bloquear o aprobar código sin intervención humana directa en cada decisión. La responsabilidad de configurar bien esas puertas es completamente humana.
Nivel 4: Operaciones y observabilidad (The SRE Tier)
La IA vigila el sistema cuando ya está en producción. Es lo que se conoce como AIOps (IA aplicada a operaciones).
Capacidades:
- Detectar anomalías en el tráfico antes de que el sistema colapse.
- Self-healing (autocuración): reiniciar servicios o hacer rollback (reversión) automático si detecta una degradación después de un despliegue.
- FinOps (gestión financiera de la nube): ajustar el tamaño de los servidores automáticamente para no malgastar dinero.
Este nivel aporta valor real en entornos con alta escala. En una startup con tráfico moderado, el coste de implementarlo supera el beneficio.
Nivel 5: IA en el corazón del producto (The Engine Tier)
El equipo ya no solo usa IA como herramienta: la IA es parte del producto en sí. Esto incluye:
- RAG (Retrieval Augmented Generation, o generación aumentada por recuperación): conectar una base de datos de la empresa con un modelo de lenguaje para que pueda responder preguntas sobre información interna actualizada.
- Fine-tuning (ajuste fino): entrenar un modelo con datos propios para especializarlo en el dominio concreto.
- Orquestación de agentes: sistemas donde una IA llama a otras IAs para resolver tareas complejas de forma autónoma.
Este es el nivel más complejo, el que más recursos requiere y el que más valor diferencial puede aportar. También es el que más puede salir mal si se implementa sin el nivel de madurez técnico adecuado.
Lo que la IA hace bien hoy
Estas son las tareas donde la IA aporta valor real y medible en el desarrollo de software actual:
Generación de boilerplate y código repetitivo: estructuras estándar, configuraciones, scaffolding (andamiaje inicial de proyectos). Lo que antes tardaba horas se hace en minutos.
Tests automáticos: generación de tests unitarios y de integración a partir del código fuente. La IA es buena cubriendo los casos obvios, aunque los casos límite complejos siguen requiriendo criterio humano.
Documentación: generar documentación técnica a partir del código. Especialmente útil para código heredado (legacy code) que nadie documentó en su momento.
Architectural spikes (exploraciones arquitectónicas): experimentos rápidos y desechables para evaluar una solución técnica antes de comprometerse con ella. “¿Funciona Redis aquí mejor que DynamoDB?” La IA puede generar los dos prototipos en horas para que un humano los compare.
Modernización y migraciones: convertir código de una versión de framework a otra, actualizar dependencias, refactorizar para seguir patrones modernos.
Explicación de código ajeno: pegar un fragmento de código complejo y pedirle a la IA que explique qué hace y por qué. Especialmente útil al incorporarse a un proyecto existente.
Detección de errores conocidos en revisión de código: bugs típicos, patrones inseguros bien documentados, violaciones de convenciones de estilo.
La IA siempre aumenta la velocidad. Lo que varía es la calidad del resultado, y esa diferencia depende casi por completo de si existe supervisión humana o no:
- Línea 🟢 crece: velocidad de entrega. Siempre mejora con más integración de IA.
- Línea 🔴 decrece: calidad del output sin supervisión humana activa. Cae a medida que la IA asume más autonomía.
- Línea 🔵 estable: calidad con supervisión humana mantenida. Se sostiene en todos los niveles. El punto de cruce entre velocidad y calidad sin supervisión es exactamente donde muchos proyectos empiezan a acumular deuda técnica invisible.
Lo que la IA no puede hacer hoy (y por qué)
Este apartado es el más importante del artículo, y también el que más se ignora.
Razón 1: La IA no tiene “piel en el juego” (accountability)
Cuando un pipeline de producción falla a las 3 de la mañana y la empresa está perdiendo dinero por minuto, la IA no siente la presión. No va a ser despedida. No tiene responsabilidad legal ni profesional sobre el resultado.
El arquitecto humano, sí. Y esa diferencia no es trivial: la responsabilidad genera un tipo de juicio que no se puede replicar con probabilidades. Ante un sistema que colapsa con información incompleta y tiempo limitado, la IA ofrece sugerencias basadas en patrones estadísticos. El humano aporta juicio y asume las consecuencias.
Hoy, en términos prácticos y legales, no puedes pedirle cuentas a un algoritmo cuando tu infraestructura colapsa.
Razón 2: El problema del “promedio de internet”
La IA se entrena con lo que ya existe en internet. Es extraordinariamente buena replicando soluciones estándar. El problema es que el ciclo de desarrollo de una empresa real nunca es estándar.
Cada empresa tiene deuda técnica propia, herramientas específicas que llevan décadas en producción, integraciones peculiares y configuraciones que tomaron su forma actual por razones que a veces nadie recuerda. La IA suele proponer la solución “teóricamente perfecta” que, en la práctica, choca con la realidad heredada.
El arquitecto humano sabe dónde están “los cadáveres enterrados” en el código. La IA no. Y no puede saberlo, porque ese conocimiento no está en ningún dataset de entrenamiento: está en la memoria de quienes llevan años trabajando en ese sistema.
Razón 3: La alucinación de seguridad
En el contexto de CI/CD (integración y despliegue continuos), un error de un solo carácter en un archivo de configuración puede exponer bases de datos enteras a internet. La IA comete errores: sugiere parámetros que no existen, configuraciones que parecen lógicas pero son inseguras, o simplemente “inventa” APIs de bibliotecas que no existen con esa firma.
Un arquitecto de seguridad o un DevOps senior detecta ese tipo de error casi por instinto, acumulado en años de experiencia con sistemas reales que han fallado de formas muy concretas. La IA no tiene esa experiencia vivida: tiene texto sobre esas experiencias, que no es lo mismo.
Confiar ciegamente en la IA para diseñar la seguridad del sistema es, hoy por hoy, una apuesta de alto riesgo.
Razón 4: El efecto “teléfono escacharrado”
Para que la IA produzca una arquitectura útil, hay que darle un contexto preciso y bien articulado. Y aquí está la trampa: si alguien no domina suficientemente el tema, no sabe cómo formular el prompt (la instrucción) adecuado. El resultado es una arquitectura genérica que no resuelve el problema real.
La figura del arquitecto o desarrollador senior es necesaria precisamente para extraer requisitos complejos del negocio y traducirlos a especificaciones técnicas precisas. Esa capacidad de hacer las preguntas correctas, de entender qué necesita la empresa aunque el interlocutor no lo sepa articular, es algo que la IA no puede hacer sola.
La IA necesita que alguien ya sepa lo que está haciendo para funcionar bien.
La paradoja del junior: ¿cómo se forma la próxima generación?
Esta es probablemente la consecuencia más silenciosa y más peligrosa de la adopción masiva de IA en el desarrollo.
En la pirámide de un equipo de desarrollo tradicional, los perfiles junior aprenden haciendo las tareas más mecánicas: escribir código de soporte, resolver bugs sencillos, implementar tests. Es aburrido, pero es el proceso por el que se forja el criterio técnico que luego hace al senior.
La IA hace estas tareas un 90% más rápido y a una fracción del coste de un junior humano. La consecuencia es que las posiciones de entrada al sector están desapareciendo o transformándose. Y si no hay dónde practicar las bases, no habrá cómo llegar a ser senior.
El riesgo a largo plazo: si no hay entradas al sector donde se aprenda haciendo cosas reales, en diez años habrá una escasez de seniors que entiendan los sistemas en profundidad. Los seniors de hoy se forjaron haciendo las cosas a mano. Los de mañana, ¿dónde se van a forjar?
No es un argumento contra la IA. Es un argumento para que las empresas y el sector piensen en cómo mantener rutas de aprendizaje reales, incluso en un entorno donde la IA automatiza las tareas básicas.
La deuda técnica cognitiva: el riesgo invisible
La “deuda técnica” es un concepto conocido en el sector: código que funciona pero que está escrito de forma que será difícil de mantener, extender o entender. Se acumula cuando se prioriza la velocidad sobre la calidad.
La IA introduce una variante nueva: la deuda técnica cognitiva. No es solo que el código esté mal escrito. Es que nadie de la empresa entiende por qué hace lo que hace, porque “lo generó la IA”.
Es una deuda más peligrosa que la técnica tradicional porque:
- Es invisible: el código puede funcionar perfectamente durante meses sin que nadie detecte el problema.
- Es explosiva: cuando falla, falla de formas inesperadas y nadie tiene el contexto para arreglarlo.
- Ahuyenta el talento: los buenos profesionales no quieren trabajar en sistemas que nadie entiende. Es frustrante y da sensación de pérdida de tiempo.
El mantra clásico de “si funciona, no lo toques” ya era peligroso cuando lo decían humanos. Aplicado a código generado por IA que nadie comprende del todo, es directamente suicida.
La evidencia científica: el efecto “rana hervida” cognitivo
Lo anterior podría parecer una intuición razonable pero difícil de medir. En abril de 2026, un equipo de investigadores de Carnegie Mellon, Oxford, MIT y UCLA publicó un estudio que lo cuantifica de forma controlada.
El paper “AI Assistance Reduces Persistence and Hurts Independent Performance” (Liu et al., 2026) trabajó con 1.222 participantes en tres experimentos aleatorizados. El diseño era simple: un grupo resolvía problemas con acceso a un asistente de IA (GPT-5), el grupo de control los resolvía solo. Después, se quitaba el acceso a la IA a todos y se medía el rendimiento independiente.
Los resultados:
- Tasa de resolución: el grupo que había usado IA alcanzó el 57% frente al 73% del grupo de control. El uso de IA durante la fase de asistencia redujo el rendimiento posterior sin ella.
- Abandono de problemas: se duplicó en el grupo que había usado IA (20% vs 11%).
- El matiz importante: los participantes que usaban la IA solo para obtener pistas —no respuestas directas— mostraron un deterioro menor. El mayor daño lo provocó el uso de la IA como sustituto completo del razonamiento propio.
Los autores denominan esto el efecto “rana hervida” (boiling frog) cognitivo: la erosión es silenciosa, incremental, y ocurre en minutos. El cerebro se adapta rápidamente a la disponibilidad de asistencia externa y reduce su inversión cognitiva propia, incluso cuando esa ayuda desaparece.
Me recuerda a otro ejemplo más casero y semejante que suele hablarse entre amigos o en las comidas familiares: “Antes te sabías todos los teléfonos de memoria y desde que llegó el móvil, que los guarda en su memoria integrada, no me acuerdo de ningún número” ¿Para qué invertir esfuerzo si la herramienta (móvil, IA, martillo mecánico, etc.) que sé que existe y está a mi alcance lo hace por mí mucho mejor? ¿Es vaguería, supervivencia humana (gasto mínimo de recursos) o adaptación rápida del cerebro al medio?
Aplicado al entorno de desarrollo: un equipo que acepta habitualmente el output de la IA sin razonar sobre él no solo acumula deuda cognitiva en los sistemas que no comprende. También degrada activamente su capacidad de pensar de forma independiente cuando la IA no está disponible o cuando falla.
Los sistemas multi-agente: promesa vs. realidad actual
Los sistemas de agentes de IA son aquellos donde varios modelos de IA colaboran entre sí para resolver tareas complejas: un agente actúa como arquitecto, otro como QA (control de calidad), otro como DevOps, y se comunican y se supervisan mutuamente.
La promesa es poderosa: automatizar toda la ejecución técnica.
La realidad es más sobria:
El problema de la “cámara de eco” evolutiva: un sistema de agentes con memoria aprende de lo que hace. Si un agente comete un error sutil y los demás lo aceptan como norma, el sistema empieza a construir sobre una base defectuosa. Sin un humano que aplique sentido común externo, los agentes pueden derivar en una arquitectura que nadie fuera del sistema puede entender ni arreglar.
El punto de inflexión de la creatividad: los sistemas de agentes son excelentes optimizando lo existente, pero son muy pobres inventando paradigmas nuevos. Una fusión de empresas, un cambio legal inesperado, un pivot estratégico: la IA procesa esos cambios como datos, pero no “siente” la urgencia ni la ambigüedad que rodea esas decisiones.
La responsabilidad última: si el sistema de agentes toma una decisión de arquitectura que viola una regulación de privacidad, ¿quién asume la responsabilidad? La empresa. Y para eso necesita tener humanos que entiendan lo que el sistema decidió y por qué.
Seguridad, gobernanza y sandboxes: lo que no es opcional
Si hay algo que los artículos de marketing de herramientas de IA no mencionan suficientemente, es la seguridad en el uso de agentes capaces de ejecutar código, modificar archivos y acceder a sistemas externos.
El estándar empresarial mínimo para trabajar con agentes de IA debería incluir:
La regla fundamental: ningún agente de IA debería tener acceso directo a producción. Las mismas salvaguardas que se aplican a un desarrollador junior que acaba de entrar (revisiones de código, entornos de prueba, aprobaciones) deben aplicarse a los sistemas de IA, y con más rigor.
El coste de ignorar esto no es hipotético: los incidentes de seguridad causados por herramientas de IA mal configuradas ya están documentados en el sector.
El CI/CD probabilístico: un cambio de paradigma poco visible
El pipeline de CI/CD (integración y despliegue continuos) clásico es determinista: el test pasa o falla, el build compila o no. El resultado es binario y reproducible.
Cuando la IA entra en el pipeline —especialmente en forma de evaluaciones de calidad o tests generados automáticamente—, el sistema se vuelve probabilístico: la IA puede dar respuestas ligeramente distintas en ejecuciones sucesivas. Lo que ayer era “correcto” puede ser evaluado diferente hoy, no porque el código haya cambiado, sino porque el modelo de IA tiene variabilidad inherente.
Esto obliga a repensar cómo se valida el software. Ya no basta con “el test pasó”; hay que preguntarse “¿el test sigue siendo relevante y preciso?”. Lo que se suele aplicar es un pipeline de evaluación de la propia IA: no solo se comprueba si el código compila, sino si la IA sigue siendo precisa y coherente con lo que se le pide.
Es un problema pequeño hoy, pero crecerá a medida que la IA asuma más responsabilidades en el pipeline.
El verdadero valor competitivo
Después de todo lo anterior, la conclusión no es que la IA sea mala o que no valga la pena. Es que el verdadero valor competitivo no está en tener la IA más potente o en usarla en más partes del proceso.
La verdadera ventaja competitiva es tener el equipo más capaz de auditar, entender, cuestionar y mejorar lo que la IA propone.
Una empresa que tiene desarrolladores que entienden en profundidad lo que hace la IA, que detectan cuando está equivocada, que saben cuándo confiar en ella y cuándo no, y que mantienen el criterio técnico vivo dentro del equipo, esa empresa tiene una ventaja real y sostenible.
Una empresa que simplemente conecta todo a una IA y apaga el pensamiento crítico interno está comprando velocidad a corto plazo a cambio de fragilidad estructural.
Fuentes citadas en este artículo:
- Liu G., Christian B., Dumbalska T., Bakker M.A., Dubey R. (2026). AI Assistance Reduces Persistence and Hurts Independent Performance. arXiv:2604.04721. Enlace al paper
- Cobertura periodística del estudio: CMU — New Scientist coverage (PDF) · Time Magazine — “Are We Losing Our Minds to AI?” · Mobile Syrup
- Sandboxes de IA recomendados: Docker AI Sandboxes · Modal Sandboxes
- AI Act europeo (referencia regulatoria): EUR-Lex — Reglamento (UE) 2024/1689
Siguiente artículo: [El coste real de la IA: de la promesa democrática al modelo enterprise]
Artículo anterior: [Los intereses reales de cada actor en la adopción de la IA empresarial]
