Las ganancias de productividad que traen las herramientas de IA para programar son reales. Lo que esas ganancias todavía no demuestran es una mejora proporcional en la calidad del software, en el criterio de producto o en el aprendizaje organizacional. Vale la pena entender esa brecha antes de que llegue la cuenta.
Hallazgos clave:
- El CEO de Anthropic estima el impacto de las herramientas de IA para programar en la productividad en aproximadamente 15-20%, una cifra conservadora viniendo de alguien con todos los motivos para inflarla. Los propios ingenieros de Anthropic reportaron, por su cuenta, un aumento del 50%. La diferencia de 30 puntos entre ambas cifras es el punto de partida para una conversación más honesta sobre lo que realmente están haciendo estas herramientas.
- Un ensayo controlado aleatorizado encontró que desarrolladores experimentados, trabajando en bases de código complejas a las que habían contribuido durante años, eran medibles en su lentitud al usar herramientas de IA, aunque seguían creyendo que iban más rápido.
- Goldman Sachs no encuentra una relación significativa entre la adopción de IA y la productividad a nivel económico general, pese a que sí existen ganancias reales en casos de uso específicos y acotados.
- El riesgo no son las herramientas. Es la presión competitiva que hace que la adopción reflexiva parezca un lastre, y la adopción descuidada parezca audacia.
- La fricción de construir en equipo (las sesiones de grooming, los code reviews, el desarrollador que dice "estos requisitos se contradicen entre sí") producía algo más allá del software. Los agentes de IA no replican ese subproducto.
¿Qué significa "vibe coding" y por qué importa la definición?
La confusión empieza con la palabra. En febrero de 2025, Andrej Karpathy acuñó el término "vibe coding" en un tweet: la descripción casual de un flujo de trabajo de fin de semana en el que te entregas por completo a la IA, aceptas todos los diffs sin leerlos y dejas de preocuparte por entender el código. Lo limitó explícitamente a proyectos desechables.
Lo que pasó después es revelador. El propio Karpathy ha dicho desde entonces que prefiere "agentic engineering" para el trabajo serio, no porque haya retrocedido respecto a la programación asistida por IA, sino porque cree que la práctica merece supervisión, rigor y oficio. En una entrevista de marzo de 2026 en el podcast No Priors, comentó que no había escrito una línea de código desde diciembre.
Mientras tanto, Gene Kim y Steve Yegge publicaron Vibe Coding: Building Production-Grade Software (2025), donde definen una práctica profesional rigurosa bajo el mismo nombre, con prólogo de Dario Amodei. En otros contextos, el término circula como peyorativo, como insignia de orgullo, como descripción de la democratización y como casi sinónimo del desarrollo asistido por IA en general.
El caos de definiciones importa porque permite que prácticas muy distintas circulen bajo la misma etiqueta. Un equipo que usa IA con revisión disciplinada, ownership claro y verificación cuidadosa puede sonar lingüísticamente parecido a un equipo que acepta lo generado con un escrutinio mínimo. El término es resbaladizo; las decisiones de gobernanza no.
Este post no es un argumento contra el desarrollo asistido por IA. Es una pregunta sobre lo que sucede cuando la presión cultural por adoptar rápido, adoptar a lo ancho y anunciar transformación lleva a las organizaciones a creer que están haciendo lo prudente cuando en realidad están haciendo lo descuidado.
¿Qué dice la evidencia sobre la productividad al programar con IA?
Las estimaciones más creíbles son más modestas de lo que sugieren los titulares, y la brecha entre percepción y realidad es llamativa.
Dario Amodei, en el podcast Dwarkesh de febrero de 2026, dio probablemente la estimación más honesta disponible de alguien con intereses en juego. Situó el impacto de las herramientas de IA para programar en la productividad en aproximadamente 15-20%, una estimación deliberadamente conservadora viniendo de alguien que tendría todos los motivos para reclamar más.
Un estudio interno de Anthropic aparte, publicado a finales de 2025 y basado en encuestas a 132 ingenieros de la propia empresa, encontró ganancias de productividad autorreportadas cercanas al 50%. Son mediciones distintas (una es una estimación amplia de productividad, la otra son ganancias autorreportadas por ingenieros de una empresa de IA con acceso temprano privilegiado a las herramientas), pero vale la pena detenerse en la brecha entre ambas. Miden cosas diferentes, y ninguna cifra es precisa. Una diferencia de 30 puntos entre dos estimaciones aproximadas que apuntan en direcciones opuestas dice algo, especialmente cuando la mayoría de las decisiones de headcount basadas en IA se construyen sobre la productividad percibida y no sobre algo evaluado de forma independiente.
El ensayo controlado aleatorizado de METR (uno de los estudios independientes más rigurosos sobre herramientas de IA para programar realizados hasta ahora) se centró exactamente en el contexto más relevante para los líderes de Engineering: desarrolladores experimentados trabajando en bases de código grandes, complejas y maduras a las que habían contribuido durante años. En ese escenario, los desarrolladores que usaron herramientas de IA fueron un 19% más lentos que sin ellas, pese a haber predicho de antemano una aceleración del 24%. Aún más revelador: tras completar el estudio, estimaron que la IA los había hecho un 20% más rápidos, mientras los datos objetivos mostraban lo contrario.
METR aclara con cuidado que este hallazgo puede no generalizarse más allá de su contexto. Las herramientas de IA pueden comportarse distinto con desarrolladores menos experimentados, bases de código desconocidas o trabajo greenfield. Pero la brecha de percepción (esa desconexión sistemática entre lo rápido que los desarrolladores creen ir y lo rápido que realmente van) aplica de forma mucho más amplia. Es esta brecha, más que la propia ralentización, la que explica buena parte de lo que está alimentando el debate actual sobre productividad e IA.
Los economistas de Goldman Sachs, en un análisis del Q4 2025, no encontraron "ninguna relación significativa entre productividad y adopción de IA a nivel económico general". El mismo análisis encontró ganancias de productividad de aproximadamente 30% en casos de uso específicos y localizados: programación de software y atención al cliente. La historia de productividad de la IA es real en focos puntuales. Aún no es la transformación amplia que se proclama.
Lo que la evidencia actual respalda es más estrecho que el hype y que la reacción contraria. Las herramientas de IA para programar pueden producir ganancias significativas en contextos específicos. También crean una brecha de percepción recurrente, en la que la aceleración subjetiva supera a la mejora medida. Lo que la evidencia todavía no establece es que producir código más rápido se traduzca de forma confiable en ganancias proporcionales en calidad de software, criterio de producto o aprendizaje del equipo.
¿Cómo se sostiene la narrativa de los layoffs frente a la evidencia?
Algunas de las empresas que más ruido hacen al recortar headcount por la productividad de la IA son también aquellas en las que la evidencia es más débil.
Klarna es el caso más ilustrativo, reportado en detalle por Fortune. La empresa afirmó que su asistente de IA estaba haciendo el trabajo de 700 agentes de atención al cliente. En cuestión de meses, los clientes se quejaban de respuestas genéricas y de la falta de soporte humano, y la empresa retomó la contratación de personal. El CEO Sebastian Siemiatkowski fue directo sobre lo ocurrido: "Como el costo lamentablemente parece haber sido un factor de evaluación demasiado predominante… lo que terminas teniendo es menor calidad." Klarna no es prueba de que las estrategias de reemplazo con IA siempre fracasen. Es un ejemplo vívido de lo que se pierde cuando se confunde el volumen procesado con la calidad entregada.
Klarna es el caso más documentado, pero no es aislado. A lo largo de 2025 y 2026, varias empresas anunciaron reducciones de headcount impulsadas por IA mientras analistas e insiders apuntaban a la sobrecontratación de la pandemia como la explicación más simple. El mercado premió el encuadre con IA en casi todos los casos, sin importar lo demás.
Un estudio de IBM con 2.000 ejecutivos encontró que solo uno de cada cuatro proyectos de IA entrega el retorno sobre la inversión que prometió. Aun así, casi dos tercios afirman que el riesgo de quedarse atrás los empuja a invertir antes de tener una idea clara del valor.
Vale la pena detenerse en esa última estadística. El motor principal de la inversión en IA no es la evidencia de retornos: es la ansiedad por lo que ocurra si los competidores se mueven más rápido. Esa ansiedad es comprensible y, en algunos contextos, racional. Pero crea las condiciones para una forma particular de autoengaño colectivo: organizaciones que anuncian transformaciones impulsadas por IA no porque la transformación haya ocurrido, sino porque anunciarla es competitivamente necesario. La narrativa viaja más rápido que los resultados.
Y para cuando los resultados se hacen claros, la narrativa ya ha moldeado decisiones de contratación, expectativas de inversores y compromisos estratégicos difíciles de revertir.
Las herramientas son reales. La narrativa está haciendo un trabajo que las herramientas no están haciendo.
¿Por qué producir código más rápido no es lo mismo que mejor software?
Esta es la pregunta más importante, y trasciende el debate de la productividad.
Abre la app de Claude en tu iPad. Funciona. También es, si la usas con regularidad, claramente un producto sobre el que no se ha pensado a fondo desde la perspectiva de alguien que tiene un iPad en las manos y quiere que algo se sienta bien.
Esto no es, en lo principal, un problema de generación de código. Es un problema de criterio: alguien tuvo que decidir qué debía ser la app, cómo debía sentirse al usarla y qué la haría preferible al navegador. Una mejor generación de código puede acelerar la implementación, pero por sí sola no resuelve esa capa de decisiones. Resolverla requiere atención sostenida a lo que otros seres humanos realmente experimentan, y ese tipo de atención es lenta, incierta y no se puede "vibear" para que aparezca.
Cuando producir se vuelve barato y rápido, se reduce la presión económica de pensar con cuidado antes de construir. Puedes lanzar algo plausible en días e iterar. El efecto compuesto es que esta lógica desincentiva activamente la inversión en una comprensión genuina del usuario, esa que hace que valga la pena usar el software. ¿Para qué pasar semanas en investigación cuidadosa de usuarios cuando puedes lanzar y ver qué pasa? El problema es que "ver qué pasa" solo produce aprendizajes útiles si ya definiste qué buscas y por qué. Sin eso, lo que se lanza revela menos de lo que esperas, y arreglar lo que encuentras cuesta más de lo que planeaste. Para cuando eso queda claro, las decisiones ya están tomadas. Es el mismo instinto en otra forma: optimizar lo visible y rápido, postergar lo lento y difícil de medir.
Esta tendencia (optimizar la métrica emocionante mientras se descuida el mecanismo que la habilita) no es nueva. Cuando un cliente se quejó de los frenos de su Type 35 de carreras en los años 20, se dice que Ettore Bugatti le respondió: "Hago mis autos para andar, no para detenerse." La frase tiene unos 100 años. La forma de pensar que representa es, evidentemente, eterna. Los autos de Bugatti eran hermosos, potentes y con frenos notoriamente insuficientes. Iban muy rápido hasta que dejaban de hacerlo.
En 2023, Gene Kim y Steven Spear publicaron Wiring the Winning Organization, un estudio sobre organizaciones de alto desempeño que le dio nombre al antídoto: slowification. Tomarse el tiempo para planear, prepararse y construir entendimiento compartido antes de ejecutar no es lo opuesto de la velocidad: es lo que hace sostenible la velocidad. Las organizaciones que invirtieron en una preparación deliberada superaron de forma consistente a las que trataban cada momento de deliberación como un costo a eliminar. Kim luego coescribió Vibe Coding: Building Production-Grade Software, donde defiende exactamente este tipo de práctica rigurosa y deliberada. El principio que identificó en 2023 aplica directamente a cómo debe abordarse ese desarrollo.
El techo de la producción se levantó. El techo de la comprensión no se ha movido.
No es un patrón nuevo. Cada generación de mejores herramientas (lenguajes más expresivos, frameworks más ricos, infraestructura en la nube) hizo más barato y rápido construir cosas sin entenderlas. El movimiento low-code prometió democratizar la creación de software y, en gran medida, entregó software rápido de crear y frustrante de usar. Las herramientas de IA para programar son la instancia más poderosa de este patrón hasta ahora, no su invención.
La brecha entre lo que las organizaciones pueden construir y lo que genuinamente entienden se ha reproducido en cada nivel de abstracción. Hoy se está reproduciendo más rápido que nunca.
¿Qué se pierde cuando los agentes de IA reemplazan a los desarrolladores humanos?
El criterio que hace bueno al software nunca estuvo solo en manos de los product managers. Estaba distribuido a lo largo del equipo, a través de la fricción de construir juntos.
No toda fricción es valiosa. Parte es burocracia, latencia y arrastre evitable. Pero parte es donde se produce la comprensión colectiva, y la ola actual de automatización facilita eliminar ambas a la vez.
Esto no es puramente teórico. En las comunidades de Engineering ahora mismo, algo aparece de forma consistente en cómo los desarrolladores describen su propia experiencia: entregan más rápido, se sienten más productivos y, en silencio, pierden agarre sobre lo que el sistema realmente está haciendo y por qué. La investigación citada lo confirma a nivel macro. La conversación también.
Cuando un desarrollador alzaba la voz en una sesión de grooming ("no puedo construir esto porque dos de estos requisitos se contradicen directamente") la organización se veía forzada a enfrentar algo que había logrado evitar. Esa incomodidad no era un fallo del proceso de planeación. Era el proceso de planeación funcionando. El requisito había sido escrito de una manera que parecía coherente hasta que alguien intentó implementarlo. La confusión del desarrollador era el espejo de la organización.
Cuando ocurría un code review entre un ingeniero senior y uno junior, ambos salían con algo que antes no tenían. El junior aprendía a pensar sobre una clase de problema. El senior tenía que articular algo que antes solo conocía de forma tácita, y el acto de articularlo lo afilaba. La conversación era el aprendizaje. El código era su residuo.
Esta distinción importa más de lo que parece. Michael Polanyi pasó toda una carrera precisándola. "Sabemos más de lo que podemos contar", escribió en The Tacit Dimension, y el corolario es que lo que podemos contar es siempre menos de lo que en realidad sabemos.
La comprensión construida a través de la práctica es distinta en su naturaleza a la información adquirida por lectura o instrucción. No puedes leer hasta saber cómo falla un sistema complejo bajo carga, ni cómo un tipo particular de usuario tropieza con un tipo particular de confusión. Tienes que haber estado ahí: haber sostenido el modelo, haberlo visto romperse y haber construido la comprensión revisada sobre las ruinas de la anterior.
Eso es lo que la sesión de grooming y el code review estaban produciendo, como subproducto de la fricción, lo nombrara o no alguien.
Un agente de IA no produce esos subproductos. Avanza sin quejarse. El cumplimiento del agente no es evidencia de que tus requisitos eran claros. Es evidencia de que el agente no se queja.
Puedes revisar el código de un agente de IA. No puedes tener esa conversación con él. El agente no llevará la revisión adelante como comprensión. Al desarrollador junior que se habría formado durante años en esos intercambios cada vez se le contrata menos. Y la organización que reemplazó esos intercambios por código generado eliminó un mecanismo del que tal vez no sabía que dependía: uno que estaba haciendo algo bastante distinto a producir software.
La pregunta que vale la pena hacerse
La métrica relevante no es solo cuánto más rápido estás entregando. Es si las ganancias en producción se están emparejando con ganancias en claridad, criterio y aprendizaje.
Esto no es un argumento contra las herramientas de IA. Bien usadas, con la supervisión, el oficio y el criterio sobre los que insisten Karpathy, Kim y Yegge, estas herramientas son genuinamente valiosas. La pregunta es si el momento actual está creando las condiciones para ese tipo de uso. La ansiedad competitiva, la presión por entregar antes de pensar, la sensación creciente de que detenerse a entender algo es una forma de bajo desempeño: nada de eso lo producen las herramientas en sí. Es el aire cultural que hoy las rodea.
Los pilotos de carreras entienden que los frenos no son para frenar. Son para habilitar el compromiso, para hacer posible empujar más fuerte en las curvas porque confías en tu capacidad de detenerte si algo sale mal. La fricción que los equipos están eliminando hoy en nombre de la velocidad era a menudo justamente esto: no sobrecarga ni ineficiencia, sino el mecanismo que hacía posible ir rápido en primer lugar. El practicante riguroso del desarrollo asistido por IA lo sabe. La organización arrastrada por la ansiedad competitiva, muchas veces no.
Entregar más código no es lo mismo que construir mejor software, y nunca lo fue. El código siempre fue un artefacto: el residuo visible de la comprensión que lo produjo, no la comprensión misma. Lo que ha cambiado no es la confusión entre artefacto y comprensión. Es lo rápido y barato que se ha vuelto sostener esa confusión a escala.
La pregunta que vale la pena hacerse (con honestidad, con especificidad, sobre tu propio equipo) es qué tipo de adopción estás haciendo en realidad. Esa pregunta suele beneficiarse de una mirada externa: alguien que ha visto ambos tipos y sabe qué buscar.
Estas preguntas no tienen respuestas limpias, y quien afirme lo contrario probablemente no las está haciendo con la suficiente seriedad. En DoiT hemos trabajado codo a codo con cientos de líderes de Engineering y tecnología que navegan exactamente esta tensión: decidiendo qué conservar, qué cambiar y qué estaban a punto de perder sin darse cuenta. Hemos descubierto que las preguntas correctas, hechas con las personas correctas, suelen producir mejores respuestas que cualquier framework. Si estás viendo algo que nosotros no, o si estás resolviendo esto de formas que están funcionando, nos encantaría saberlo.
Preguntas frecuentes
¿Cuáles son los distintos significados de "vibe coding"? El término tiene al menos tres significados distintos en el uso actual. En su sentido original, acuñado por Andrej Karpathy en febrero de 2025, describía un flujo casual basado en la entrega total, apto para proyectos desechables. Gene Kim y Steve Yegge definieron luego una práctica profesional seria bajo el mismo nombre en su libro de 2025 Vibe Coding: Building Production-Grade Software, donde enfatizan rigor, supervisión y oficio. En el uso común también funciona como sinónimo general de desarrollo asistido por IA, y alternativamente como peyorativo para una adopción descuidada de la IA. El caos de definiciones importa: cuando el mismo término describe tanto la aceptación irreflexiva de la salida de IA como una agentic engineering disciplinada, una conversación significativa sobre lo que está haciendo un equipo concreto se vuelve muy difícil.
¿Pueden las herramientas de IA para programar mejorar la productividad sin mejorar la calidad del software? Sí. La evidencia sugiere que ya lo están haciendo a escala. Las herramientas de IA pueden aumentar de forma medible la cantidad de código y acortar los ciclos de entrega sin mejorar el criterio que determina qué se construye, la claridad de los requisitos o la profundidad del entendimiento del usuario detrás del producto. Goldman Sachs encuentra ganancias reales de productividad en programación de software como caso de uso específico. Lo que no encuentra (y lo que la evidencia más amplia tampoco muestra todavía) es que esas ganancias se traduzcan en mejoras proporcionales en calidad de software o en resultados de producto.
¿Qué encontró realmente el estudio de METR sobre código con IA? El ensayo controlado aleatorizado de METR de 2025 probó a 16 desarrolladores experimentados en 246 tareas reales sobre bases de código open-source grandes y maduras que conocían bien. Los desarrolladores que usaron herramientas de IA tardaron un 19% más en completar las tareas que sin ellas, pese a haber predicho de antemano una aceleración del 24% y a seguir creyendo después que habían sido más rápidos. METR aclara que el hallazgo es específico de este contexto y puede no generalizarse a desarrolladores menos experimentados o a bases de código desconocidas. La brecha de percepción (creer sistemáticamente que la IA está ayudando cuando los datos muestran lo contrario) es el hallazgo de aplicación más amplia.
¿Por qué hay una brecha tan grande entre la productividad autorreportada y la medida con IA? Dos datos ilustran la brecha desde ángulos distintos. En su aparición en el podcast en febrero de 2026, Dario Amodei estimó el impacto de las herramientas de IA para programar en la productividad en aproximadamente 15-20%. Un estudio interno de Anthropic aparte, de finales de 2025, encontró que los propios ingenieros de Anthropic autorreportaron un aumento de productividad del 50%: una medición distinta, pero la brecha entre ambas es ilustrativa. El estudio de METR encontró un patrón perceptual similar: los desarrolladores creían que la IA los había acelerado en un 20% mientras la medición objetiva mostraba una ralentización del 19%. El propio análisis de METR sobre la brecha apunta a varios factores: la programación asistida por IA requiere menos esfuerzo cognitivo y se siente más rápida aunque no lo sea; los desarrolladores pueden estar confundiendo facilidad con velocidad; y el tiempo dedicado a revisar, corregir y limpiar código generado por IA típicamente no se cuenta en los autorreportes.
¿Qué pasó cuando Klarna reemplazó a sus agentes de atención al cliente con IA? Klarna reemplazó aproximadamente 700 puestos de atención al cliente con un asistente de IA desarrollado con OpenAI, afirmando que la IA estaba haciendo un trabajo equivalente. En cuestión de meses, los clientes se quejaban de respuestas genéricas y de la falta de soporte humano, mientras los agentes de IA tenían dificultades con interacciones complejas, llenas de matices y emocionalmente cargadas. El CEO Sebastian Siemiatkowski reconoció el error directamente: "Como el costo lamentablemente parece haber sido un factor de evaluación demasiado predominante… lo que terminas teniendo es menor calidad." La empresa retomó la contratación de personal humano de atención al cliente en 2025. El caso es ilustrativo no solo como historia de fracaso, sino como muestra de lo que se pierde cuando la métrica es el volumen procesado en lugar de la comprensión demostrada.
¿Qué es la slowification y por qué importa para los equipos de software? La slowification es un concepto del libro de 2023 de Gene Kim y Steven Spear Wiring the Winning Organization. Describe la inversión deliberada en planeación, preparación y entendimiento compartido antes de la ejecución: ir más despacio para moverse después más rápido y de forma más confiable. Su investigación en organizaciones de alto desempeño encontró que esto era un diferenciador consistente: los equipos que se "slowificaban" superaban de forma consistente a los que trataban cada momento de deliberación como un costo. El principio aplica directamente al desarrollo de software: la sesión de grooming, la investigación cuidadosa de usuarios, el code review que parecía lento estaban haciendo a menudo justamente esto: producir el conocimiento compartido del que depende una ejecución segura.
¿Pueden las herramientas de IA aumentar la producción y al mismo tiempo reducir la comprensión? Sí, y posiblemente esta sea una pregunta más importante que la de si aumentan la productividad. La producción y la comprensión se generan por mecanismos distintos. El código se produce por ejecución; la comprensión se produce por la fricción de trabajar problemas en conjunto: el desarrollador que objeta requisitos contradictorios, el code review en el que un ingeniero senior tiene que articular algo que antes solo conocía de forma tácita, la sesión de grooming en la que un equipo descubre que lo que parecía una especificación clara no lo es. Los agentes de IA avanzan sin generar esos subproductos. No se quejan, no aclaran, no llevan la conversación adelante como aprendizaje. Una organización puede entregar más software y al mismo tiempo perder agarre sobre lo que sus sistemas están haciendo, por qué se construyeron como se construyeron y qué necesitan realmente sus usuarios. La producción sube. La comprensión que debería acompañarla no sigue el ritmo.
¿Goldman Sachs encuentra que la IA no tiene impacto en la productividad? No exactamente. Los economistas de Goldman Sachs, en el mismo análisis del Q4 2025, no encuentran una relación significativa entre adopción de IA y productividad a nivel económico general. El mismo análisis encontró ganancias de productividad de aproximadamente 30% en casos de uso específicos y localizados: programación de software y atención al cliente son los dos más citados. El cuadro es de ganancias reales en contextos específicos que aún no se han traducido en una mejora amplia de productividad económica. Esa distinción importa para la forma en que las organizaciones deberían pensar sus inversiones en IA: una adopción focalizada en contextos donde las ganancias están bien evidenciadas es distinta a tratar la IA como un multiplicador de productividad de propósito general.