Un ingeniero francés rechaza toda interacción con IA

Un ingeniero publica un manifiesto de cero tolerancia con la IA

Ploum, ingeniero y escritor francés conocido por explorar el impacto social de la tecnología, publicó este 9 de septiembre de 2026 una declaración en su blog titulada "I Don't Want to Interact with Stochastic Parrots". En ella establece una política personal: rechaza leer textos generados por IA, mirar imágenes sintéticas, ejecutar código vibecoded o mantener conversaciones con quien cite a ChatGPT como fuente. Su argumento de fondo es que delegar cognición a un algoritmo entrenado para producir "promedio" no es productividad, es pérdida de agencia.

El texto ha circulado con fuerza en la comunidad técnica europea porque llega en un momento incómodo: la investigación reciente sobre el impacto real de la IA en el trabajo de los desarrolladores está dejando cifras que cuestionarían las promesas de las propias herramientas.

Lo que la investigación reciente está encontrando

El laboratorio METR intentó en febrero de 2026 repetir un estudio propio publicado en 2025 que medía cuánto tardaban desarrolladores open source en completar tareas con y sin IA. El primer estudio ya había dado una sorpresa: aunque los participantes percibían que la IA los hacía más rápidos, los datos mostraban que en realidad los frenaba — más tiempo corrigiendo errores, redirigiendo al modelo y esperando respuestas. La réplica de 2026 no pudo completarse: los desarrolladores se negaron a participar porque no estaban dispuestos a trabajar sin IA, ni siquiera unas pocas tareas para un experimento, según reportó TechCrunch el 29 de mayo de 2026.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

METR publicó entonces una encuesta alternativa en mayo de 2026: los desarrolladores auto-reportaron sentirse dos veces más valiosos para sus organizaciones gracias a la IA. Las pruebas objetivas, sin embargo, cuentan otra historia.

Amazon cerró su leaderboard interno de consumo de tokens Kirorank después de que los empleados lo "gamificaran" usando agentes de IA de forma excesiva, según reportó el Financial Times. El sistema demostró que el uso de IA no se traduce automáticamente en productividad.
Uber agotó su presupuesto de IA para todo 2026 en los primeros cuatro meses del año, reportó The Information. Su COO, Andrew Macdonald, reconoció públicamente que ese gasto no produjo un aumento medible de proyectos ni de productividad.
Salesforce proyecta gastar US$300M en tokens de Anthropic este año, según reportó The Next Web el 29 de mayo de 2026, y su CEO Marc Benioff pidió públicamente una "capa de enrutamiento" que asigne tokens según la complejidad de la tarea — una admisión implícita de que no todos los tokens generan valor.

La pregunta que los líderes de ingeniería están evitando es directa: si los desarrolladores se niegan a trabajar sin IA pero la IA está generando más bugs de los que previene, ¿el efecto neto puede ser negativo?

El problema del "vibe debt" que nadie sabe mantener

Ploum sostiene que en cuanto se añade código generado por un LLM a un proyecto, el proyecto entero deja de poder mantenerse por humanos. La línea argumental no es nueva, pero los datos la están reforzando.

Oleg Lola, fundador y CEO de MobiDev, escribió en Forbes el 8 de julio de 2026 que la deuda técnica ahora se acumula "a velocidad de máquina". Antes un equipo recortaba en un sprint y sentía las consecuencias tres meses después; hoy puede generar 20 veces más deuda técnica en el mismo período. Lola acuñó el término "vibe debt" para describir lo que produce el vibe coding sin disciplina de ingeniería: dependencias alucinadas, vulnerabilidades ocultas, integraciones inestables y regresiones que aparecen semanas después de un prompt que nadie recuerda haber ejecutado.

El programador y autor James Shore lo resumió en un post viral: "¿Escribes código el doble de rápido ahora? Más te vale haber reducido a la mitad tus costes de mantenimiento. Si no, estás jodido: estás cambiando un boost temporal de velocidad por una servidumbre permanente".

Las cifras que cita The Next Web dibujan el mismo cuadro:

Entelligence AI, startup de ingeniería de fiabilidad, afirma que las empresas gastan el 44% de sus tokens en arreglar bugs que su propia IA generó.
CodeRabbit, herramienta de code review, asegura que tras analizar pull requests open source la IA produce 1,7 veces más problemas que el código humano.

Ambos casos admiten un sesgo: las dos compañías venden herramientas de revisión de código. Pero hay investigación independiente que apunta en la misma dirección: la Singapore Management University publicó un informe en abril de 2026 advirtiendo de que "el código generado por IA puede introducir costes de mantenimiento a largo plazo en proyectos reales".

El propio fundador de Cognition, Scott Wu — creador del agente Devin — admitió en conversación recogida por TechCrunch que la skill de su herramienta se sitúa "entre un programador junior y uno mid-level" dependiendo de la tarea. No es un sistema listo para entregar y olvidar.

La IA como препятствие para aprender

Ploum, que enseña, cuenta que lleva años sin encontrar un solo estudiante que le haya sorprendido gratamente por su uso de un chatbot. En todos los casos, el uso de IA empeoró el rendimiento. Uno de ellos llegó a contribuir a un proyecto en GitHub sin poder explicar de qué iba. Cuando prohíbe el uso de IA en sus cursos, el desempeño mejora siempre, sin excepción, y también la autoconfianza del estudiante.

La analogía que cita — del escritor John Scalzi — es precisa: jugar a Guitar Hero es divertido, pero miles de horas de Guitar Hero no te permitirán tocar "Cumpleaños feliz" en una guitarra de verdad. Lo que la herramienta hace, dice Ploum, es robarte la capacidad esencial de aprender.

Para un founder, este punto importa más que las cifras de productividad: si tu equipo aprende menos, depende más. Y un equipo que depende más de un proveedor externo que puede cambiar su modelo, su precio o sus condiciones en cualquier momento es un equipo con un riesgo estructural que no aparece en el dashboard.

Qué significa esto para tu startup

No se trata de volver a 2019. Pero sí hay decisiones concretas que un founder puede tomar esta semana para no acabar en la trampa que Ploum describe.

Separa el código experimental del código de producto. Todo lo generado por IA en prototipos y MVPs debe marcarse como tal desde el commit. Cuando llegue el momento de escalar, sabrás qué reescribir a mano antes de que la deuda te explote. Lola recomienda explícitamente esta separación: en MobiDev han visto MVPs funcionando en dos semanas con pura generación IA que luego costaron cuatro meses de reconstrucción.
Mide coste total, no velocidad de entrega. Si tu equipo entrega el doble de rápido pero dedica un 40% más a mantenimiento, no estás siendo más productivo: estás cambiando现金流. Pide a tu equipo de ingeniería un reporte trimestral de horas dedicadas a mantener código antiguo vs. construir cosa nueva.
Protege la formación de los juniors. Si tus developers junior ya no pueden escribir a mano una función sin abrir un asistente, tienes un problema de pipeline. Reserva tiempo explícito cada semana para tareas sin IA: debugging manual, code reading de proyectos open source, pair programming sin asistente.
No confundas tokens gastados con valor producido. Lo que Amazon y Uber han demostrado en 2026 es que el consumo de IA no es una métrica de productividad. Pregunta a tu CTO qué % del trabajo entregado el último mes podría haberse hecho sin IA y, de ese porcentaje, cuánto se hizo gracias a IA y cuánto a pesar de ella.

Ploum probablemente nunca convencerá a Silicon Valley. Pero si tu startup depende de que dentro de dos años alguien entienda tu código, tu producto y tus decisiones, la pregunta que deja sobre la mesa vale más que cualquier benchmark de tokens.