Programar con IA: la ilusión de la productividad

Nota: report que hace Microsoft sobre lo mismo, aclarando que la IA es un problema en la programación Microsoft reports are exposing AI’s real cost problem: Using the tech is more expensive than paying human employees

Existe una percepción creciente en la industria del software de que la calidad de las aplicaciones, webs y sistemas operativos ha disminuido desde la popularización masiva de las herramientas de Inteligencia Artificial generativa. Si bien es fácil atribuir este fenómeno directamente a la “IA”, la realidad es más compleja.

Este ensayo sostiene que la IA no sabe programar en el sentido cognitivo del término; es un sistema estadístico de predicción de patrones. El verdadero problema radica en cómo la aplicación acrítica de estas herramientas, combinada con condiciones laborales insostenibles, está generando una “burbuja de deuda técnica” que amenaza la sostenibilidad del software a largo plazo.

El espejismo de la infraestructura y el marketing

Para comprender el contexto actual, es necesario separar la realidad de la propaganda. Dos fenómenos paralelos ilustran la burbuja especulativa actual:

La realidad de los centros de datos: Aunque la industria promete miles de millones en infraestructura (como el proyecto Stargate de OpenAI, Oracle y Softbank, anunciado por la administración Trump el 21 de enero de 2025), la ejecución enfrenta obstáculos significativos. Contrario a la narrativa de éxito inmediato, proyectos como el “Mega AI Data Center” han sufrido retrasos de un año, conflictos internos y problemas en la cadena de suministro, evidenciando que la construcción física no sigue el ritmo vertiginoso del marketing digital.

Una foto satélite del AI Data Center a fecha 26/02/2026:

Podéis leer más en Ver artículo

La compra de influencia: Existe una campaña masiva para normalizar la IA en la cultura popular. Grandes tecnológicas están pagando a influencers para promocionar sus herramientas de IA. Esta inversión no necesariamente refleja la utilidad real de los productos, sino una necesidad desesperada de las empresas por recuperar su inversión y “hacer que la IA parezca genial”. Si buscas información sobre este punto revistas de USA dirán que China paga a influencers para que hablen de su IA y otros medios dirán lo mismo de OpenAI, desde el punto de vista de este ensayo ambas son comprar influencia.

El problema del contexto: ¿qué significa realmente que la IA “no entiende”?

Para evaluar críticamente la afirmación de que “la IA no sabe programar”, hay que definir primero qué significaría saber programar. Propongo tres capacidades mínimas:

1. Mantener consistencia interna a lo largo de un código que cambia
2. Razonar sobre estados no explícitos (lo que no está escrito pero es cierto)
3. Priorizar soluciones según criterios que cambian (coste, mantenimiento, urgencia)

La IA actual (LLM) falla sistemáticamente en las tres, y los estudios empíricos lo confirman —pero no por “falta de entendimiento” en un sentido místico, sino por su arquitectura.

Lo que sí hace la IA

Un LLM genera el siguiente token más probable dada una secuencia de entrada. Si le das:

# función para calcular el factorial
def factorial(n):

La IA completa con un bucle o recursión. Esto no es entender matemáticas. Es haber visto esa secuencia millones de veces en su entrenamiento. La IA tiene éxito cuando:

• El problema es común (visto muchas veces)
• El contexto está completo en el prompt
• La solución es predecible

Lo que NO hace la IA (y por qué)

Problema 1: Estados no explícitos

Suponga un repositorio con dos ramas: main (producción, bug visible) y fix/estable (corregido, pero no desplegado). Un humano ve el bug en producción, mira git branch, y cambia a la rama correcta. La IA no ve nada de esto a menos que se lo diga explícitamente en el prompt —y si se lo dice, ya está haciendo el trabajo humano de diagnosticar.

Esto no es un “error” de la IA. Es su diseño: no tiene acceso al mundo fuera de su prompt a menos que se lo conectes (y entonces el coste y la latencia se disparan). Un estudio de 2025 demostró que los LLMs fallan en tareas que requieren integrar información distribuida en múltiples archivos, exactamente por esta razón.

Problema 2: Priorización según criterios cambiantes

Cuando un equipo está atrasado, un humano puede decidir: “hoy no optimizo, solo hago que funcione”. La IA, entrenada con código “ideal” (documentado, limpio, eficiente), tiende a generar la solución canónica —que suele ser más compleja y lenta de escribir.

Los datos de Faros AI lo confirman indirectamente: el aumento del 54% en bugs no es porque la IA escriba mal código para la tarea que le piden. Es porque la IA escribe el código que ha visto más veces, no el código que resuelve el problema específico bajo restricciones específicas.

Problema 3: Consistencia a largo plazo

Un estudio controlado comparó desarrolladores con y sin IA en una tarea de varios días. Los que usaban IA terminaban antes cada subtarea, pero el código final requería un 43% más de cambios para integrarse con el resto del sistema. ¿Por qué? Porque la IA optimiza localmente (cada función aislada) sin visión global del proyecto.

Entonces, ¿falla la IA o fallamos nosotros?

La IA no “falla” en el sentido de cometer errores aleatorios. Hace exactamente lo que fue diseñada para hacer: predecir la siguiente palabra más probable. El problema es que eso no es suficiente para programar bien.

La verdadera pregunta, que casi nadie hace, es: ¿por qué seguimos usando una herramienta que sabemos que introduce un 54% más de bugs y aumenta la complejidad un 41%? La respuesta no es técnica —es laboral.

El costo oculto en la calidad del código: Evidencia empírica

Un estudio de la Universidad Carnegie Mellon (CMU) de 2026 analizó 806 repositorios open-source que adoptaron Cursor AI. Los resultados son concluyentes:

• Aumento temporal de velocidad: Las líneas de código añadidas aumentaron un 281% en el primer mes.
• Degradación permanente de calidad: A los dos meses, la euforia inicial desaparece, pero las advertencias de análisis estático aumentaron un 30.3% y la complejidad del código un 41.6% , sin signos de recuperación .

Este patrón se define como un ciclo de “excitación, frustración y abandono”. De manera similar, un informe de Faros AI (basado en telemetría de 22,000 desarrolladores) acuñó el término “Acceleration Whiplash” (Latigazo por Aceleración):

• La finalización de tareas aumentó un 34%, pero los bugs por desarrollador aumentaron un 54% .
• El tiempo de revisión del código se multiplicó por cinco.
• El 31.3% de los cambios (Pull Requests) se fusionan sin ninguna revisión humana lo que sugiere que los sistemas están desbordados.

La conclusión de estos estudios es que, si bien los juniors o desarrolladores periféricos producen más código, son los desarrolladores senior (core) quienes asumen la carga de revisar y corregir ese código, viendo su propia productividad original reducida en un 19% . Lejos de ahorrar tiempo, la IA está transfiriendo el esfuerzo de la escritura al mantenimiento.

VSCodium como síntoma de una solución

Esta es mi propuesta y es totalmente irrelevante sobre la cuestión de si sabe o no la IA programar.

La preferencia por herramientas como VSCodium (una versión de VS Code sin telemetría ni IA) no es una mera cuestión estética o de nostalgia. Es una respuesta racional a la sobrecarga cognitiva. Los estudios demuestran que la IA aumenta los “reinicios de trabajo” en un 13.8% y el contexto diario de trabajo en un 67% . Paradójicamente, pensar sin IA es más eficiente a largo plazo, porque permite resolver problemas con soluciones limpias y sostenibles.

Sin embargo, este acto de “pararse a pensar” es inviable en las condiciones actuales del mercado laboral en consultoras y grandes empresas, donde se prioriza la velocidad de entrega (aunque sea código basura) sobre la salud del software.

Conclusión

Si queremos un internet libre de deuda técnica, el camino no es automatizar más la escritura de código, sino automatizar menos el pensamiento. Los datos empíricos son claros: la IA aumenta la velocidad inicial a costa de una calidad estructuralmente más baja y una sobrecarga para los expertos . La solución no es prohibir la IA, sino replantear el mercado laboral, mejorar las condiciones de quienes escriben el código y exigir métricas de calidad (no solo de velocidad) en los procesos de desarrollo. Mientras tanto, herramientas como VSCodium, son un espacio de trabajo profesional para quienes priorizan la sostenibilidad del software.

Reconozco que la IA tiene valor para tareas acotadas: generar tests, documentación o código repetitivo. Sin embargo, los datos sugieren que su aplicación generalizada como sustituto del razonamiento —en lugar de como una herramienta bajo supervisión humana— tiende a ser contraproducente. Esto no implica rechazar la IA, que ha venido para quedarse, sino contextualizarla: la deuda técnica no es un fenómeno nuevo, existe desde que existe la tecnología y la IA la esta acelerando.

Referencias

• Xu, F., et al. “AI-Assisted Programming Decreases the Productivity of Experienced Developers by Increasing the Technical Debt and Maintenance Burden.” arXiv preprint, 2026. Reed more
• He, H., et al. “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects.” CMU & MSR 2026. Read more
• Faros AI. “The Acceleration Whiplash: Engineering Impact Report.” March 2026. read more
• CNBC. “Google and Microsoft offer lucrative deals to promote AI…” February 2026. Read More
• Informes y métricas de DORA (DevOps Research and Assessment): El marco metodológico oficial de Google Cloud que prioriza la estabilidad de los despliegues (Change Failure Rate y Time to Restore) por encima de la mera velocidad de escritura de código está disponible en la documentación y reportes de DORA DevOps Research Metrics.