Introducción
El optimismo de empezar una carrera como ingeniero de software se funda en un momento muy específico: cuando un problema se resuelve con tus manos, cuando la solución que tu cerebro ideó se plasma en algún lenguaje de programación y funciona. Ese subidón es la droga inicial. Luego ese optimismo se va desgastando, lentamente, cuando llevas 30 horas revisando algo que escribiste y que funciona — pero no hace lo que debería. Y termina de morirse cuando lo que tienes que revisar ya ni siquiera es código tuyo.
Hoy la IA se encargó de la parte que te llenaba el corazón de júbilo, y te dejó la parte horrible: revisar y corregir.
Y aun así, la industria sigue repitiendo que somos 55% más rápidos.
Contexto
El número que todos repiten — "GitHub Copilot te hace 55% más rápido" — viene de un experimento de GitHub y Accenture con 4,800 devs sobre una tarea acotada: implementar un servidor HTTP en JavaScript. Sin evaluación de calidad de salida. Sin cobertura de tests. Sin verificar si el código sobreviviría a producción. Los participantes sabían que estaban siendo cronometrados. Es un dato real, pero no es el dato que justifica licencias de ocho cifras.
Mientras tanto, en 2025 METR (Model Evaluation & Threat Research) hizo un ensayo controlado aleatorizado con desarrolladores experimentados, en sus propios repositorios, sobre tareas reales. El resultado fue contraintuitivo: los devs con IA tardaron un 19% más que sin ella. Y creyeron que habían sido un 20% más rápidos. El propio METR publicó una actualización en febrero de 2026 con un grupo más amplio: la desaceleración cayó a aproximadamente -4%, con un intervalo de confianza de -15% a +9%. Traducción honesta: el efecto es ambiguo, pero definitivamente no es el "56% más rápido" del slide del CTO. Y un paper del NBER de febrero de 2026, encuestando a casi 6,000 ejecutivos, encontró que más del 80% de las firmas reportaron que la IA no había tenido impacto medible en productividad en los tres años anteriores.
La postura: estamos pagando suscripciones para sentirnos productivos
Mi tesis es directa: las herramientas de IA para código, en tareas complejas y en contextos reales (no demos), no te hacen significativamente más rápido. Lo que hacen es generar una sensación tan convincente de velocidad que las decisiones se toman sobre esa sensación, no sobre la evidencia.
Pero quiero matizar algo, porque es donde se pone interesante. Puede que ni siquiera haya un ahorro real de tiempo para las empresas. Cuando trabajas con un agente que atiende las tareas de código, el reloj sigue corriendo — el agente tarda lo que tarda. La diferencia es que ese tiempo ya no es tu tiempo: es tu espacio para un café, unos cuantos reels, una clase, o leer este blog. La empresa no necesariamente recibe menos horas-código. Tú recibes tu vida de vuelta, en migajas asíncronas.
Eso es real. Y vale algo. Pero no es lo que están vendiendo en los pitches.
Argumentos
1. El problema del código "casi correcto". Según la Stack Overflow Developer Survey 2025, la mayor frustración de los devs es lidiar con soluciones de IA que parecen correctas pero están ligeramente mal. Casi la mitad dice que depurar ese código toma más tiempo que escribirlo desde cero. Cuando tú escribes código, construyes un modelo mental de cada variable. Cuando revisas código generado, tienes que reconstruir ese modelo desde fuera — y el costo cognitivo es brutal. Justamente la parte que te quemaba al final de la carrera, la de revisar lo que no es tuyo, es la parte que la IA acaba de multiplicar.
2. La ilusión de velocidad es estructural. En el estudio de METR, los participantes predijeron 24% de speedup antes, reportaron 20% después, y midieron 19% de slowdown en la realidad. La brecha entre percepción y medición fue de casi 40 puntos. No es anecdótico: es un sesgo cognitivo sistemático. Cuando una herramienta te da feedback instantáneo (texto que aparece), tu cerebro registra "avance", aunque luego pases media hora corrigiéndolo.
3. Las métricas celebradas miden la cosa equivocada. "88% de las sugerencias aceptadas se quedan en el commit" no significa que el código sea bueno. Significa que el dev lo aceptó. Investigaciones longitudinales sobre commits reales muestran que los heavy users de IA generan entre 4x y 10x más código no duradero — código que requiere refactor o se borra poco después. Velocidad de output no es velocidad de delivery.
4. La revisión es el cuello de botella, no la escritura. Generar código nunca fue el problema caro. El problema caro siempre fue entenderlo, mantenerlo, depurarlo. La IA optimiza el paso barato y multiplica el caro. Es como darle una pistola de pintura a alguien que tiene que pintar exactamente dentro de las líneas: vas más rápido al principio, más lento al final.
5. El prompt engineering es la línea entre odio y utilidad. Aquí está el matiz que falta en casi todos los takes "anti-IA": disminuir el esfuerzo de revisión requiere experiencia y sentido común. El prompt engineering — y, más honestamente, saber qué pedirle, qué no pedirle, y cómo acotar el contexto — es la diferencia entre odiar a la IA o tratarla como un gran dev junior. Un dev junior bueno, no genial. Que necesita supervisión. Que a veces sorprende. Que nunca debería empujar a producción sin que alguien con canas revise. Y aquí está el problema: las empresas la están tratando como si fuera senior.
Cierre
Nada de esto significa que tires Cursor a la basura. Significa que dejes de tomar decisiones organizacionales basadas en cómo se siente la herramienta. Mide tu propio tiempo. Compara, sin trampas, tareas equivalentes con y sin IA. Vas a sorprenderte — en ambas direcciones.
La IA no nos quitó el trabajo. Nos quitó la mejor parte del trabajo y nos dejó la peor, con la promesa de un speedup que no aparece en los datos macro. A cambio, nos dio pausas asíncronas para tomar café. Es un trade-off raro y no estoy seguro de que estemos hablando de él honestamente.
¿Tú has medido tu productividad real, o estás defendiendo una herramienta porque te gusta cómo te hace sentir mientras esperas su output?
Top comments (0)