Programar con LLMs ya no es una rareza. Es el default de miles de equipos. La discusión interesante, entonces, no es si estas herramientas sirven — claro que sirven — sino qué te están dando a cambio de lo que te quitan.
Ese es el centro del debate que hoy divide a la comunidad tech. De un lado están quienes ven a los modelos como una capa obvia de productividad. Del otro, quienes advierten que escribir menos código no siempre significa entender mejor el sistema que estás construyendo. Y ahí está la parte incómoda: ambos bandos tienen razón.
¿Por qué volvió con fuerza este debate?
El disparador reciente fue una entrada del desarrollador y experto en seguridad Neil Madden, publicada el 2 de marzo, donde explica por qué no usa LLMs para programar. Su argumento no es nostálgico ni anti-tecnología. Es más simple y más profundo: programar no es solo producir código; es un mecanismo para pensar, ordenar ideas y entender sistemas.
Madden apoya esa postura con citas clásicas de Douglas Adams, Gauss y Alan Perlis. La idea común es potente: el acto de programar obliga a descomponer problemas hasta que una máquina torpe pueda ejecutarlos. En ese proceso no solo construyes software; construyes criterio.
Ese punto conecta con una preocupación que viene creciendo hace meses. Namanyay Goel, en un texto que circuló fuerte entre developers, describió un patrón cada vez más común: juniors que entregan más código que nunca con Copilot, Claude o ChatGPT abiertos todo el día, pero que se quedan mudos cuando les preguntas por qué esa solución funciona, qué edge cases deja abiertos o qué otra alternativa arquitectónica existía.
El dato que volvió imposible ignorarlo
El debate dejó de ser filosófico cuando empezaron a aparecer datos más duros. En febrero, Anthropic publicó un ensayo controlado con 52 ingenieros que estaban aprendiendo una librería nueva en Python. El resultado fue incómodo: quienes usaron asistencia de IA obtuvieron puntajes 17% más bajos en la evaluación de comprensión que quienes programaron sin ayuda. La mayor brecha apareció en debugging, justo la habilidad que más necesitas cuando el código “parece” correcto pero no lo está.
Eso no significa que la IA te vuelva peor por definición. El propio estudio dice algo más matizado: los mejores resultados aparecieron cuando la gente usó la IA para preguntar, pedir explicaciones y contrastar comprensión, no cuando la usó para delegar la escritura completa del código. O sea: el problema no es la herramienta, sino el modo de uso.
En descubre.ai ya habíamos cubierto ese ángulo cuando contamos que usar IA para programar baja tu comprensión del código en un 17%. Lo nuevo ahora es que esa evidencia ya se cruzó con un debate cultural más amplio sobre cómo aprende una generación completa de desarrolladores.
Entonces, ¿hay que dejar de usar LLMs para programar?
No. Ese sería un pésimo resumen. El error está en pensar que solo hay dos posiciones posibles: “usar IA para todo” o “prohibirla”. La postura inteligente está en separar tipos de trabajo.
- Sí para acelerar tareas mecánicas: boilerplate, tests, documentación, refactors acotados, exploración de sintaxis o librerías.
- Sí para aprender mejor: pedir explicaciones, comparar enfoques, revisar supuestos, detectar huecos conceptuales.
- No como piloto automático: decisiones de arquitectura, lógica de negocio sensible, seguridad, performance crítica y debugging profundo.
- No como sustituto de criterio: si no puedes defender el código sin el modelo al lado, todavía no lo entiendes.
De hecho, el mejor argumento a favor de usar IA bien no viene de los maximalistas, sino de quienes la usan con frenos. Simon Willison lo explicó muy bien y nosotros lo resumimos en Refactoring con IA: los agentes de IA liquidan la deuda técnica que postergabas. El punto no es que los agentes reemplacen el juicio humano, sino que pueden liberar tiempo para aplicarlo donde sí importa.
El riesgo real no es productividad falsa, sino deuda invisible
El peligro más serio de este ciclo no es que los LLMs escriban código mediocre. Es que generan una ilusión de comprensión. El código compila, los tests básicos pasan, la demo funciona y el equipo siente que avanzó. Pero por debajo pueden quedar decisiones no cuestionadas, dependencias mal elegidas, supuestos frágiles y vulnerabilidades que nadie entendió de verdad.
Eso es lo que vuelve tan útil el concepto de deuda de verificación: si la IA produce código más rápido de lo que tu equipo puede revisar, explicar y mantener, no estás ganando velocidad; solo estás pateando el costo hacia adelante.
Y ese costo pega especialmente fuerte en equipos junior. Un senior puede usar un modelo como exoesqueleto y seguir pensando. Un junior, en cambio, corre más riesgo de usarlo como muleta. Si eso ocurre durante meses, el problema no es un bug puntual: es una generación entera con menos fricción formativa.
La analogía de la calculadora sirve… pero hasta cierto punto
Quienes defienden el uso masivo de LLMs suelen recurrir a la calculadora: nadie hace divisiones largas a mano todo el día y eso no destruyó las matemáticas. Hay algo de verdad ahí. La automatización desplaza tareas rutinarias y empuja a los humanos hacia niveles más altos de abstracción.
Pero la analogía se rompe en un detalle clave: la calculadora da resultados deterministas y verificables. Un LLM no. Su salida puede ser plausible, elegante y equivocada al mismo tiempo. Por eso delegar sin comprensión es más riesgoso en programación que en una suma. No estás tercerizando solo trabajo mecánico; estás externalizando parte del razonamiento.
Además, el desarrollo de software no consiste únicamente en escribir líneas. Consiste en modelar sistemas, manejar ambigüedad, anticipar fallos, decidir trade-offs y sostener productos vivos en el tiempo. Ahí los LLMs ayudan, sí, pero todavía no reemplazan el músculo mental que forma a un buen ingeniero.
Por qué importa
Este debate importa porque va a definir cómo se forman los equipos técnicos de los próximos años. Si las empresas miden solo velocidad de output, van a premiar el uso más superficial de la IA y castigar justo el trabajo lento que construye criterio. Pero si entienden que productividad sin comprensión es una trampa, pueden usar los LLMs como una palanca real: acelerar lo rutinario, elevar la discusión técnica y reservar el esfuerzo humano para donde más valor genera. El futuro no pertenece a quienes programen sin IA ni a quienes dependan ciegamente de ella. Pertenece a quienes sepan pensar mejor con ella sin dejar que piense por ellos.
