Bloomberg Dice que la IA en Programación Causa Pánico por Productividad. Están Diagnosticando la Enfermedad Equivocada.
La pantalla brillando en la oscuridad, todos los demás se fueron hace horas. Navegando por tech Twitter cuando Bloomberg suelta: "Claude Code y el Gran Pánico de Productividad de 2026."
Me leí todo el artículo. Y tuve esa reacción dividida que te da cuando un médico describe tus síntomas perfectamente, y luego te receta el medicamento equivocado. Sí, el dolor es real. No, no duele por eso.
Bloomberg escribió 3,000 palabras sobre agentes de IA produciendo demasiado código demasiado rápido. Ni una sola vez mencionaron que nadie les dice a los agentes qué producir. Tres mil palabras sobre una enfermedad, y se les olvidó el patógeno.
TL;DR - El artículo del "pánico de productividad" de Bloomberg clava los síntomas pero falla en el diagnóstico. El pánico no viene de que la IA escriba demasiado rápido. Viene de la ausencia de especificaciones. Programar a base de vibes sin contratos produce código con 2.74x más vulnerabilidades de seguridad, hace que desarrolladores experimentados sean 19% más lentos (mientras creen que son 24% más rápidos), y crea una brecha del 40% entre percepción y realidad. La solución no es frenar tus agentes. Es decirles qué construir antes de que empiecen a construir.
Los síntomas son reales. La causa está en otro lado.
Manejo mis propios proyectos. Ningún VP respirándome en la nuca sobre tasas de utilización de agentes. Y aún así, durante la mayor parte de 2025, la IA me hizo más lento.
No en papel. En papel todo se veía increíble. Features enviados en horas. Commits acumulándose. El git log parecía como si tuviera un equipo de cinco. Pero estaba debuggeando más que construyendo. Estaba leyendo código que no reconocía en mis propios repos. Me pasaba los martes arreglando lo que la sesión "productiva" del lunes había roto.
Si has estado en ese bucle, ya sabes que el artículo de Bloomberg tiene razón en algo.
Un estudio de UC Berkeley siguió a una organización de 200 personas y encontró que aunque los empleados delegaban trabajo a agentes de IA, trabajaban más horas. Los investigadores lo llaman "expansión de tareas." La IA crea output, el output crea limpieza, la limpieza crea horas extra. Un VP de DocuSketch le dijo a Bloomberg que necesita "unas cuantas interacciones más de IA antes de dormir," lo que suena a adicción pero se lee como miedo si alguna vez te has preocupado por quedarte atrás en una herramienta que todos los demás parecen ya dominar.
Así que sí. El pánico es real.
Pero Bloomberg se queda en "los agentes crean presión" y nunca hace la pregunta de seguimiento: ¿por qué más output crea más trabajo?
Porque el output no tiene spec. Esa es toda la respuesta. Un agente sin restricciones es un dev junior con energía infinita y cero contexto. Va a producir. Va a producir con confianza. Y lo que produzca estará casi bien, lo cual es peor que estar mal, porque no lo vas a cachar hasta que producción lo haga.
Bloomberg nunca dice esto. Parcialmente porque Bloomberg es un medio financiero y la audiencia objetivo no es el ingeniero debuggeando a las 2 AM, es el inversionista recalibrando un portafolio. Este artículo salió seis días después de que Claude Code Security hundiera las acciones de ciberseguridad 5–9%. El timing no es periodismo. Es contexto de mercado.
Y parcialmente porque nombrar la causa real, "nadie escribe specs antes de promptear," hace un titular aburrido. "Pánico de Productividad" vende suscripciones. "Escribe Mejores Prompts" no.
Bloomberg vende el pánico. Nadie vende la solución.
Los datos con los que Bloomberg debería haber empezado
Todos se benefician de mantener vivo el pánico. Los consultores de "transformación de IA" consiguen un nuevo mercado. Los vendors de governance consiguen un nuevo segmento. Los medios financieros consiguen engagement. Los devs senior consiguen una razón para sentirse indispensables. Nadie tiene incentivo para señalar que la solución es aburrida.
Pero los datos apuntan a lo aburrido de todas formas.
METR hizo uno de los pocos estudios rigurosos sobre esto, un ensayo controlado aleatorizado con 16 desarrolladores experimentados de open-source a través de 246 tareas reales. Los desarrolladores usando herramientas de IA fueron 19% más lentos que sin ellas. Pero aquí está la parte que debería aterrorizarte: se percibían a sí mismos como 24% más rápidos. Esa es una brecha del 40% entre la realidad y lo que tu cerebro te dice.
Conozco esa brecha. He vivido dentro de ella. Aparece código en pantalla, tu cerebro registra "progreso," y te saltas la verificación porque todo se siente rápido. Te conviertes en tu propio peor departamento de QA.
Veracode probó código generado por IA a través de más de 100 LLMs en cuatro lenguajes. 45% contenía vulnerabilidades de seguridad. 2.74 veces más vulnerabilidades que código escrito por humanos. Y no porque los modelos sean estúpidos. Nadie especificó las restricciones. Un LLM va a construir felizmente un flujo de login sin rate limiting, sin sanitización de input, credenciales en texto plano. No le dijeron que no lo hiciera. Así que no lo hizo.
CodeRabbit analizó más de 10 millones de pull requests y encontró que el código de IA produce 2.25 veces más bugs de lógica de negocio. "Lógica de negocio" es literalmente lo que una especificación define, cosas como permisos de usuario, casos edge, transiciones de estado. Exactamente el territorio que el vibe coding se salta porque "la IA se va a dar cuenta."
Y el propio estudio de Anthropic de enero 2026 encontró que desarrolladores usando IA obtuvieron 17% menos puntos en quizzes post-tarea. Mayor brecha: preguntas de debugging. Entendemos menos de lo que enviamos. Dejamos de definir qué esperamos antes de presionar enter, y luego nos sorprendemos de que el resultado no coincida.
Ninguno de estos números dice "la IA es peligrosa." Cada uno dice "la IA sin spec es peligrosa."
Bloomberg confundió la herramienta con el uso. Estos estudios tienen límites, METR fue 16 desarrolladores, Veracode probó LLMs variados con quién sabe qué prompts. El propio seguimiento de METR de febrero 2026 sugiere aceleraciones conforme las herramientas evolucionan, pero sus datos también muestran que la brecha de percepción persiste, los desarrolladores aún no pueden decir qué tan rápido van realmente. Los números exactos son discutibles. La dirección no.
Cómo me volví un extraño en mi propia base de código
Aquí está mi historia real y es más tonta de lo que piensas. El tipo que escribe sobre contratos de prompt fue destrozado por no usar uno. Los hijos del zapatero, descalzos, todo el cliché.
Estaba construyendo un dashboard para una de mis apps SaaS. Cosas estándar: página de métricas, backend Convex, auth Clerk, algunas gráficas. El tipo de cosa que he hecho suficientes veces para ser peligroso. Esto fue antes de que formalizara los contratos de prompt, cuando cada sesión era puro vibe.
Abrí Claude Code en modo vibe completo. No especifiqué la arquitectura. No listé las librerías que quería. Solo "construyeme un dashboard con auth y gráficas." Veinte minutos después, página funcionando. Data fluyendo. Gráficas renderizando. Me sentí como si hubiera desbloqueado un cheat code.
Tres días después necesitaba agregar un filtro. Feature simple. Debería tomar 10 minutos.
Abrí la base de código y encontré TanStack Query por todos lados.
No uso TanStack Query. Nunca he usado TanStack Query. Apenas sabía qué era TanStack Query. Claude había decidido que mi capa de data fetching necesitaba un framework de caching y sincronización que nunca había tocado, lo conectó en cada componente, y construyó todo el manejo de estado alrededor de él.
El dashboard funcionaba. No podía explicar por qué. No podía modificarlo sin romper algo porque no entendía las abstracciones que lo mantenían unido. Agregar un filtro de fecha significaba entender los patrones de invalidación de TanStack Query, y estaba googleando conceptos básicos sobre una herramienta en mi propio proyecto como un turista leyendo un libro de frases en un país donde supuestamente vivo.
Dos días aprendiendo un framework que nunca elegí, para modificar código que supuestamente escribí, en un proyecto que supuestamente poseo. Bueno, déjame reformular eso. Dos días pagando el impuesto por una decisión que nunca tomé.
Un spec de tres líneas habría prevenido todo eso: "Usa fetch + Convex hooks para data. No librerías externas de manejo de estado. Mantenlo lo suficientemente simple para que pueda debuggearlo a la 1 AM sin documentación."
Eso no fue algo único. Durante los siguientes dos meses rastreé mis sesiones. El patrón siempre era idéntico. Lanzar agente con objetivo vago. Obtener código que compila. Deployar. Descubrir la brecha entre lo que quise decir y lo que dije. Debuggear algo que ni sabía que estaba ahí.
La peor parte no es el tiempo perdido. Es la sensación. Lo construiste pero no lo posees. Tu repo se ve como la casa de alguien más. Los datos de METR sobre desarrolladores pensando que son más rápidos de repente tienen perfecto sentido, genuinamente crees que estás enviando, hasta que necesitas cambiar algo.
El agente no era el problema. Mi prompt sí.
La solución: contratos, no conversaciones
Aquí es donde dejé de tratar a Claude Code como un chatbot y empecé a tratarlo como un contratista que absolutamente va a azulejar tu baño en mármol si no especificas cerámica.
Antes de cada sesión: qué debe producir el agente, qué no debe tocar, cómo verifico el resultado. Lo llamo un contrato de prompt. No porque sea legalmente vinculante, sino porque fuerza la misma claridad. Ambas partes conocen el alcance. Nadie despierta con un framework que no invitó.
Construí el framework completo de contratos de prompt después de suficientes de estos desastres. La versión corta: objetivo, restricciones, formato de output esperado, condiciones de falla. Cuatro campos. Noventa segundos para escribir. Ahorra horas de debugging y cero frameworks sorpresa.
No soy el único llegando a esto.
Un paper de arXiv de enero 2026 documentó un equipo de servicios financieros que cambió de prompting de IA de forma libre a workflows spec-first con contratos OpenAPI. El tiempo de ciclo de integración bajó 75%. La IA no se volvió más inteligente. Los humanos se volvieron más claros.
Kent Beck, el tipo detrás de TDD y Extreme Programming, publicó "Augmented Coding: Beyond the Vibes" donde construyó una librería B+ Tree competitiva para producción en Rust usando prompting estructurado de IA. Su enfoque: vibe coding produce código que funciona. Prompting estructurado produce código que puedes mantener. Hay una diferencia, y se nota en el mes tres.
Y eso es exactamente lo que Red Hat encontró. Los proyectos de vibe-coded consistentemente chocan con una pared alrededor de la marca de tres meses. El código funciona, luego no, y nadie puede explicar por qué porque los prompts originales se fueron y la base de código no tiene intención documentada. Solo vibes. Vibes anteriores. Vibes muertos.
Los contratos de prompt no te van a salvar en exploración. Cuando genuinamente no sabes qué estás construyendo, dale al vibe. Rápido, barato, desechable. El problema empieza cuando vibe se vuelve el default para todo, incluyendo código que va a producción y código del que otra gente depende. Eso no es exploración. Eso es negligencia con pasos extra.
Los specs no son burocracia. Son el camino más corto para enviar.
Los cuerpos que el vibe coding dejó atrás
Bloomberg cubre capital. Estas historias son sobre craft. Pánico diferente, misma causa raíz.
Daniel Stenberg mantiene cURL, la herramienta corriendo en aproximadamente 20 mil millones de dispositivos. En julio 2025 documentó que 20% de las submissions de bug bounty eran slop generado por IA. Reportes de vulnerabilidad confiados, detallados, completamente fabricados. Cada uno se comió 3–4 miembros del equipo de seguridad por horas. La tasa confirmada colapsó bajo 5%. Cerró todo el programa en enero 2026. Sus palabras: "Tiempo y energía que se desperdicia completamente mientras también obstaculiza nuestras ganas de vivir."
Los reporteros no eran maliciosos. Apuntaron una IA a cURL sin spec de qué constituye una vulnerabilidad real. El modelo generó basura plausible. Mismo patrón que mi desastre de TanStack, solo que a escala de ecosistema.
Luego está Adam Wathan, quien creó Tailwind CSS. Enero 2026: 75% de su equipo de ingeniería, despedido. Tailwind era más popular que nunca, más descargas, más proyectos, más adopción. Ingresos bajaron 80%. Tráfico de docs bajó 40%. Las herramientas de IA memorizaron Tailwind y generan clases inline, así que nadie visita los docs ya. El modelo de negocio no falló. Fue consumido por IA sin atribución, contexto, o pago. Pienso mucho en este, en realidad, porque significa que puedes ganar el juego de adopción y aún así perder 💀
Mitchell Hashimoto, co-fundador de HashiCorp (construyó Terraform y Vagrant), maneja Ghostty, un emulador de terminal. Para enero 2026 se estaba ahogando en pull requests drive-by generados por IA. Bajo esfuerzo, sin revisar, rotos. Su respuesta: bans permanentes. Su enfoque: "Esta no es una postura anti-IA. Esta es una postura anti-idiota."
Tres casos. Tres dominios. Una estructura: output generado sin definición de qué significa "bueno." Código sin contratos. Reportes sin criterios. PRs sin estándares.
La IA produjo volumen. Los humanos se ahogaron en él. Bloomberg no cubrió nada de esto porque Stenberg cerrando un bug bounty no mueve precios de acciones. Pero si construyes cosas, este es el pánico que realmente importa.
Si quieres ver estructura sobre vibes aplicada a tooling, el mismo principio aplica: define la interfaz antes de construir el feature.
Lo que Bloomberg debería haber escrito
El "pánico de productividad" no es un problema de IA. Es un problema de transición. Estamos en la fase donde todos tienen la herramienta y nadie tiene el método.
Bloomberg no nombra esto porque un artículo sobre pánico sin solución genera más engagement que uno práctico con una solución. Describe la ansiedad, vende la suscripción, sigue adelante. Ese es el modelo. Un artículo diagnóstico con cura es menos compartible que uno que deja a cada lector proyectar su propio miedo en él.
Piensa en lo que "fatiga de IA" realmente describe. El VP de DocuSketch que dice que necesita más interacciones de IA antes de dormir no es adicto. Está asustado. Si no domino esta herramienta, alguien que sí lo haga tomará mi lugar. Bloomberg enmarca esto como una preocupación de bienestar porque "trabajadores aterrorizados de la obsolescencia" es una venta más difícil para la audiencia C-suite que paga por acceso a Bloomberg Terminal.
La única respuesta real a la reemplazabilidad es competencia. No pánico. No más horas. No más prompts antes de dormir.
Competencia significa saber cómo dirigir la herramienta, no solo cómo correrla. Significa escribir un spec de tres líneas antes de lanzar un agente. Significa poseer tus decisiones de arquitectura en lugar de descubrirlas tres días después en el framework de alguien más. Significa tratar la IA como un contratista, no como un cofundador.
Esto no es complicado. Solo no es viral 🤷♂️
El pánico es real. El diagnóstico está mal. Y el artículo es el producto.
Escribo sobre lo que realmente funciona cuando construyes con agentes de IA, sin hype, sin tonterías de "10x tu productividad," solo las cosas que probé y las cosas que se rompieron. El botón de suscribirse está justo ahí si eso es lo tuyo.
*Esa imagen de portada es generada por IA porque mis habilidades de diseño llegaron a su pico centrando un div en 2019 y ha sido cuesta abajo desde entonces.
Los agentes de IA sin especificaciones son como desarrolladores junior sin dirección: producen código rápido pero peligroso. En el newsletter, compartimos cómo evitar ese caos.