¿Por qué el código de IA está agotando a los ingenieros de software?

La inteligencia artificial prometió liberar a los programadores del tedio. Menos tareas repetitivas, más velocidad, prototipos en minutos, ese pequeño paraíso de productividad con café de cápsula y gráficos ascendentes. Pero en muchas empresas el milagro viene con letra pequeña: más código generado, sí; también más código que alguien tiene que revisar, entender, arreglar y mantener cuando la demo deja de sonreír.

La noticia no va de una revuelta romántica contra las máquinas. Va de algo más pedestre y, por eso mismo, más grave: equipos de software donde los perfiles menos expertos producen cambios con asistentes de IA a gran velocidad, mientras los ingenieros veteranos quedan convertidos en inspectores de averías. Deedy Das, socio de Menlo Ventures, ha descrito esa fractura como una división entre quienes hacen “vibe coding” sin demasiada comprensión y quienes cargan con la limpieza posterior, una crisis de identidad que roza la depresión profesional para parte del sector.

El problema no es que la IA programe, sino quién responde por el código

El vibe coding tiene un nombre casi simpático, como de aplicación para organizar recetas. En realidad describe una práctica muy concreta: pedir a una IA que escriba o modifique software, aceptar lo que escupe la pantalla y avanzar guiado por la sensación de que aquello “más o menos funciona”. Para una prueba rápida puede ser útil. Para una infraestructura que mueve dinero, datos personales, citas médicas o reservas de vuelos, la cosa cambia. Ahí el código no es confeti digital; es fontanería. Y cuando una tubería revienta, no basta con decir que la soldó un chatbot.

Los asistentes de programación ya forman parte del paisaje. Stack Overflow recogió en su encuesta de 2025 que el 51% de los desarrolladores profesionales usa herramientas de IA a diario, pero el entusiasmo convive con una desconfianza muy terrenal: el 46% dice desconfiar de la precisión de esas herramientas, frente a un 33% que confía en ellas, y solo un 3% declara confiar mucho en sus resultados. No es ludismo. Es experiencia. Quien ha pasado una noche persiguiendo un bug sabe que una respuesta convincente puede ser una trampa con buena dicción.

La tensión aparece cuando la empresa mide el avance por volumen: más commits, más pull requests, más tickets cerrados, más líneas cambiadas. Todo muy bonito en el panel de control. Pero el software no se valora solo por lo que entra en el repositorio, sino por lo que sobrevive al lunes siguiente. El código generado por IA puede acelerar una tarea pequeña y, al mismo tiempo, sembrar deuda técnica: duplicaciones, soluciones aparatosas, parches que encajan como una puerta hinchada por la humedad.

La nueva división de clase dentro de los equipos técnicos

La escena que describen algunos ingenieros es incómoda porque rompe la narrativa limpia de la productividad. Unos generan deprisa. Otros revisan despacio. Y entre ambos se abre una grieta laboral con olor a fluorescente cansado: los perfiles que dominan el sistema acaban dedicando menos tiempo a diseñar arquitectura, mejorar rendimiento o resolver problemas difíciles, y más a descifrar piezas de código que nadie parece haber comprendido del todo antes de enviarlas a revisión.

Un estudio académico publicado en 2025 sobre proyectos de código abierto tras la introducción de Copilot detectó justo esa paradoja: la productividad aumentaba, sobre todo entre desarrolladores periféricos o menos experimentados, pero el código posterior requería más retrabajo; los desarrolladores centrales revisaban un 6,5% más de código y su productividad original caía un 19%. Es decir, la fábrica producía más piezas, pero el taller de control de calidad acababa hasta las cejas.

La palabra clave aquí no es “IA”. Es mantenimiento. Un programa no termina cuando compila, igual que un puente no termina cuando se inaugura con cinta y foto. Hay que corregirlo, ampliarlo, documentarlo, protegerlo de vulnerabilidades, adaptarlo a nuevos sistemas y, sobre todo, entender por qué demonios hace lo que hace. Si el autor humano no sabe explicarlo porque lo aceptó como quien acepta las cookies, el coste se desplaza hacia arriba: al sénior, al arquitecto, al equipo de seguridad, al pobre Miguel de guardia que ya no está para milagros.

Código basura con traje de productividad

La IA escribe con seguridad. Ese es parte del problema. Puede entregar una función limpia a primera vista, nombres plausibles, comentarios razonables y una solución que pasa tres pruebas sencillas. Luego llega el caso raro, la concurrencia, el dato sucio, la dependencia que cambia, el usuario que pulsa dos veces donde debía pulsar una. Crack. La porcelana era de atrezo.

GitClear, que analiza cambios en repositorios, observó en su investigación de 2025 un aumento de bloques duplicados, más código de corta vida y una caída de líneas movidas o reutilizadas, señales asociadas a peor mantenibilidad. El matiz importa: no significa que toda ayuda de IA sea mala, sino que algunas métricas de productividad pueden inflarse mientras crece el coste futuro de conservar ese software con vida.

Esto explica por qué muchos ingenieros no hablan de sustitución, sino de degradación del oficio. Programar nunca fue solo escribir instrucciones. Era leer, preguntar, elegir una abstracción, conocer el contexto, dejar una solución menos brillante pero más sólida. La IA puede asistir en todo eso, pero también puede convertir el desarrollo en una cadena de montaje de respuestas plausibles. Y lo plausible, en informática, a veces es el primo elegante de lo falso.

El espejismo de cerrar tickets más rápido

En empresas presionadas por lanzar producto, la IA encaja como una droga legal: reduce la fricción inmediata. Un formulario, una migración sencilla, una prueba unitaria, un script interno. Perfecto. El problema empieza cuando esa comodidad se generaliza sin criterio y se confunde velocidad con calidad. Cerrar un ticket no equivale a resolver un problema; a veces solo significa haberlo empujado unos metros por el pasillo.

Los equipos más maduros están aprendiendo a distinguir usos. Autocompletar, generar esqueletos, escribir pruebas preliminares o explicar código heredado puede ahorrar tiempo. Delegar decisiones de seguridad, arquitectura o lógica de negocio sin revisión seria es otra cosa. Ahí la IA no sustituye al ingeniero: lo compromete. Lo deja firmando una obra que quizá no ha leído, como esos ministros que inauguran rotondas sin saber hacia dónde van.

El código abierto ya ha levantado la ceja

El caso de Godot, uno de los motores de videojuegos de código abierto más conocidos, ilustra el hartazgo de los mantenedores. La fundación anunció en junio de 2026 cambios en sus normas de contribución: exige que el código sea de autoría humana, limita la ayuda de IA a tareas menores como autocompletado, expresiones regulares o búsqueda y reemplazo, y prohíbe el uso de agentes autónomos o “vibe coding” para contribuir. También exige revelar el uso de IA cuando haya intervenido en la autoría del código.

La decisión tiene algo de frontera simbólica. El código abierto siempre ha sido una escuela dura pero fértil: llegabas, proponías, te corregían, aprendías, volvías mejor. Si las revisiones pasan a dirigirse a textos generados por máquinas y presentados por usuarios que no pueden defenderlos, el proceso educativo se rompe. Nadie aprende. Solo se acumula trabajo. Un mantenedor no está ahí para hacer de profesor particular de un bot con exceso de confianza.

GitHub, mientras tanto, muestra la escala del fenómeno: en su Octoverse 2025 habló de más de 180 millones de desarrolladores, 630 millones de proyectos y 43,2 millones de pull requests fusionadas al mes. La programación asistida por IA no es una moda de garaje; es una mutación industrial. Por eso el debate ya no puede limitarse a si una herramienta “ayuda” o “no ayuda”. La pregunta real es qué reglas, responsabilidades y filtros hacen falta cuando producir código se vuelve casi demasiado fácil.

El ingeniero del futuro será menos mecanógrafo y más responsable civil

Hay una lectura optimista, y no conviene tirarla al contenedor. Bien usada, la IA puede quitar óxido del trabajo diario. Puede acelerar prototipos, ayudar a navegar bases de código enormes, sugerir pruebas, traducir entre lenguajes, detectar patrones repetidos. Para un buen profesional, es una lupa y a veces una bicicleta eléctrica. El problema es venderla como piloto automático cuando todavía confunde carreteras con ríos.

El perfil que sale reforzado no es el que teclea más rápido, sino el que sabe formular problemas, revisar con mala leche constructiva, entender arquitectura, valorar riesgos, hablar con producto, discutir prioridades y decir “esto no entra” antes de que entre una bomba pequeña en producción. Kent Beck, una referencia histórica de la ingeniería de software, ha defendido precisamente que las habilidades humanas ganan peso cuando la IA automatiza parte de la escritura de código: comunicación, criterio, colaboración, responsabilidad. La broma cósmica es que el programador encerrado en su torre de lógica ahora necesita trato humano. Vaya giro de guion.

Esto no convierte a todos los ingenieros en jefes de proyecto con sudadera. Mantiene la exigencia técnica, pero cambia el centro de gravedad. Saber programar seguirá importando. Mucho. Solo que el valor ya no estará en producir líneas como churros, sino en saber cuáles no deberían existir. En una época de abundancia sintética, borrar también será una competencia.

La crisis de identidad viene de una promesa mal contada

Durante años se dijo a los desarrolladores que eran artesanos del futuro, constructores de mundos invisibles. Luego llegó la IA generativa y parte del discurso empresarial empezó a tratarlos como supervisores de una máquina que “ya programa”. Normal que algunos sientan que les han cambiado el oficio por una cinta transportadora. A nadie le gusta pasar de arquitecto a corrector de redacciones ajenas, menos aún cuando las redacciones las firma un loro estadístico con acceso a medio internet.

Pero la muerte del programador está exagerada. Lo que está muriendo, quizá, es una cierta complacencia: la idea de que escribir más código siempre es avanzar. La IA deja al descubierto algo que el sector ya sabía y a veces fingía no saber: el software malo también funciona un rato. Hasta que no. Hasta que una actualización rompe pagos, una dependencia abre un agujero, una duplicación se multiplica como moho o una decisión opaca bloquea meses de evolución.

El oficio no desaparece; se vuelve más incómodo. Más político incluso, en el sentido noble y cotidiano de la palabra: decidir quién responde, qué se acepta, qué se revisa, qué se automatiza y qué no conviene automatizar aunque se pueda. Esa conversación será menos brillante que una demo con música épica, pero bastante más importante.

Cuando la máquina escribe, alguien sigue pagando la factura

La IA no está llenando las empresas de código basura por una maldición tecnológica, sino por una mezcla muy humana de prisa, incentivos torcidos y fe en el atajo. La herramienta puede ser formidable. El uso descuidado, desastroso. Entre ambas cosas hay una diferencia que los departamentos de marketing suelen borrar con una sonrisa blanca.

La programación entra en una etapa menos inocente. Ya no bastará con celebrar que una IA genere una función en diez segundos; habrá que preguntar quién la entiende, quién la prueba, quién la mantiene y quién aparece cuando falle. Ahí, en esa zona sin focos, sigue viviendo el verdadero ingeniero de software. No el que produce más ruido en el repositorio, sino el que impide que el edificio se caiga mientras todos admiran la fachada.