No, la IA no programa. Y los que te dicen lo contrario te están vendiendo humo

Source: Dev.to

Hace unas semanas, tras ver el enésimo video de un “experto” afirmando que “Gemini 3 Pro revoluciona la automatización” y que “los agentes de IA ya construyen aplicaciones completas”, sentí una mezcla de incredulidad y rabia.
Rabia por ver cómo la falta de experiencia en proyectos reales se disfraza de autoridad para envenenar el criterio de quienes están empezando.

1. La prueba real

Decidí hacer lo que ninguno de ellos hace: una prueba real. No con un repositorio de juguete de 10 archivos ni con una API simple, sino con un problema de integración concreto:

• Objetivo: conectar un servidor MCP a jdt‑ls usando LSP4J.
• Enfoque inicial: generar una clase Java autocontenida, de menos de 500 líneas, sin integrar nada más.
• Resultado: ni siquiera superé esta prueba mínima.

Modelos evaluados

Resultado global: 8 modelos, 0 éxitos. Ninguno generó código funcional; varios entraron en bucles corrigiendo errores de compilación y tuve que indicarles yo mismo las correcciones para que pudieran compilar algo.

2. La realidad del contexto

Los videos siguen prometiendo “¡Procesa repositorios de un millón de tokens!”. Suena impresionante… hasta que abres un proyecto real.

Un solo módulo de una aplicación profesional ya excede en un 150 % la capacidad del contexto más avanzado del mercado. Cuando te prometen que la IA “entiende tu repositorio”, te están mintiendo: solo entiende un subconjunto ínfimo, una foto borrosa y recortada de la realidad de tu sistema.

3. Demos vs. programación real

He visto las demos típicas:

• “Crea una app de TODOs en React”.
• “Haz un dashboard con gráficos”.

Son el equivalente digital de ensamblar un mueble de IKEA: todas las piezas están ahí con un manual claro, pero al final terminas con algo que parece un mueble… y no funciona como esperas.

La programación real no es ensamblaje de piezas prefabricadas. Es:

• Saber por qué elegimos una estructura sobre otra.
• Garantizar que el sistema no colapse bajo su propio peso, ya sea en meses o años de producción.

Cuando a un LLM le das un problema real (integrar un protocolo como LSP, manejar estado asíncrono y lidiar con configuraciones específicas de jdt‑ls), se desmorona. No tiene un modelo mental del sistema, solo estadísticas de tokens.

“Eso no es programar. Es generar texto que se parece a código Java”.

Lo que la IA no puede hacer

• Detectar código que huele mal.
• Anticipar consecuencias a meses o años vista.
• Discutir sacrificios con tu equipo.
• Mantener compatibilidad con otros sistemas.

4. Consecuencias del hype

El daño más grave no es la sobreventa técnica, sino el sabotaje intelectual que sufren los programadores que hoy intentan entrar en la industria.

• Un junior ve a los “evangelistas” decir:

  “No pierdas el tiempo aprendiendo el lenguaje, aprende a pedírselo a la máquina de la forma correcta”.

  Con promesas de LLMs con “capacidad de razonamiento doctoral”, “Vibe Coding que entiende tu intención”…

• El junior se pregunta ¿para qué aprender algoritmos o arquitectura si la máquina “ya lo hace”?

• Se está ocultando que, sin criterio, están delegando tareas críticas en una caja probabilística que ni siquiera cabe en su propia memoria.

5. ¿A quién va dirigido este llamado?

Creadores de contenido

• Dejen de vender humo. Si quieren enseñar IA, enseñen sus límites.
• Muestren que funciona para tareas mecánicas o código repetitivo, para refactorizar, pero nunca sustituye la comprensión del problema.

Juniors

• Aprendan fundamentos. La IA es una herramienta poderosa en manos de un artesano experto.
• En manos de un novato, es un martillo neumático que puede destrozar todo lo que toca.

Yo

• Seguiré escribiendo artículos como este, mostrando con código (cuando pueda) y errores reales la brecha entre el hype y la realidad.

6. Anécdota adicional

Una duda me perseguía: ¿y si el problema no era Java, sino la complejidad misma?

Días después, recordé algo que nos pasó a finales de noviembre…

Contexto: Un compañero y yo tuvimos que meter mano en la aplicación web de la empresa. Cuenta con un frontend de más de 50 000 líneas de JavaScript y TypeScript.
Nuestro perfil: Arquitectos Java; de React solo sabíamos el nombre.
Promesa de la IA: Usar Gemini CLI para que explicara qué cambiar y generara el código.
Resultado: La explicación fue coherente y el código sintácticamente perfecto… pero falló en silencio.

7. Conclusión

La IA no programa.
Los programadores programan.
Los demás hacen demos.

Si un “gurú” vuelve a decir que la IA programa, le enviaré mis pruebas con los ocho intentos fallidos. A ver si tiene el valor de intentar arreglarlo.

Este artículo estaba listo para publicar hace unos días. Pero la reflexión sigue: la verdadera prueba de una herramienta es su desempeño en problemas complejos y reales, no en demos pulidas.

Lección aprendida (stale closure)

Gemini había olvidado declarar una dependencia en un useCallback. Escribió una función que no veía los cambios en el estado. No supimos arreglarlo, así que le pedimos a la IA que nos resumiera la filosofía de React, los hooks y las closures. Lo leímos, lo entendimos y le señalamos el fallo. La IA lo corrigió, pero cometió un error de junior y tuvimos que corregirle.

La realidad

• No es que no sepan Java.
• Cuando la complejidad es real —estado asíncrono, ciclos de vida complejos o integración con sistemas vivos—, sin importar el lenguaje, falla.
• La IA no tiene modelo mental; solo tiene probabilidad.
• En un proyecto de verdad, eso se paga con horas de debug.