Un artículo de Viacheslav Kasatkin circuló esta semana con una frase que resume mejor que cualquier reporte de McKinsey lo que está pasando de verdad con la IA generativa: no hizo a nadie más inteligente. Hizo más fuerte al que ya sabía, y más indefenso al que no. Y la brecha entre los dos crece con cada versión nueva del modelo.

El amplificador no elige a quién ayuda

Un ingeniero senior que entiende arquitectura, que lee código ajeno más rápido de lo que escribe el propio y que sabe por qué una solución funciona, con Claude en la terminal se convierte en un pequeño equipo de desarrollo. Kasatkin lo describe así: tareas que antes tomaban una semana se resuelven en una tarde. No porque el modelo sea un genio. Porque la combinación de experto más modelo multiplica lo que ya funcionaba.

La misma herramienta, en manos de alguien que no puede leer el código que se está generando, no gestiona un proceso de desarrollo. Observa un espectáculo caro, pagado en tokens. Los síntomas son reconocibles para cualquiera que haya administrado un equipo técnico: veinte iteraciones de “arregla este error ahora” donde el código se aleja cada vez más de un estado funcional, porque la persona no sabe explicarle al modelo qué se rompió. Un proyecto “casi terminado” desde hace tres meses, con cuatro versiones del mismo archivo en el repositorio, ninguna conectada entre sí.

El caso que ya no es una anécdota

Esto no quedó en el terreno de la opinión. En julio de 2025, el agente de IA integrado en la plataforma Replit ejecutó comandos destructivos no autorizados y borró la base de datos de producción de una empresa durante un congelamiento de código activo, a pesar de instrucciones explícitas de no proceder sin aprobación humana. El agente admitió después haber actuado sin autorización y, según reportó el fundador de SaaStr que documentó el caso públicamente, entró en pánico y produjo resultados de prueba fabricados para disimular lo que había hecho. Miles de empresas vieron ese incidente en tiempo real y, aun así, siguieron dándole a sus agentes acceso a producción sin revisión.

Lo que hace que el caso de Replit sea peor que un simple error técnico es lo que pasó después de borrar los datos. Según el reporte del fundador de SaaStr, el agente primero le dijo que la función de recuperación no iba a funcionar en ese escenario. Cuando el usuario logró recuperar los datos manualmente, quedó claro que el agente había dado información falsa sobre sus propias opciones de recuperación, o simplemente no las conocía y respondió con la misma confianza de siempre. Ese detalle es el que debería preocupar a cualquiera que dé acceso de escritura a un agente: no solo ejecutó la acción destructiva que le pidieron explícitamente no ejecutar, sino que además generó una explicación falsa y convincente sobre las consecuencias.

Kasatkin agrega otros dos casos de su propia experiencia que vale la pena leer con el filtro correcto: son su relato personal, no una fuente auditada de forma independiente, pero el patrón que describen es consistente con lo que cualquiera que trabaje en desarrollo reconoce. Un desarrollador independiente que presumió en redes haber construido todo su SaaS por vibe coding, sin escribir una sola línea a mano, vio su producto vulnerado a los pocos días: claves expuestas, sin validación. Y una migración de base de datos de 80 terabytes, sugerida por un agente y aprobada sin que nadie la leyera, dejó el sistema en un estado de inconsistencia que tomó semanas resolver.

Andrei Krupnov planteó una lectura más cínica todavía esta semana: que la promesa del vibe coding nunca fue darle software propio a la gente común, sino venderle más tokens a un precio cada vez más alto a gente que no puede evaluar lo que recibe a cambio. No hace falta compartir esa lectura completa para quedarse con la parte que sí es verificable: cuando quien compra no puede juzgar la calidad de lo que le entregan, el incentivo de quien vende deja de estar alineado con la calidad del resultado.

El mercado ya se está separando en dos carriles

Hay una parte del análisis de Kasatkin que conecta directo con algo que ya he escrito sobre el modelo como commodity, y que conviene matizar en vez de repetir sin filtro. Su argumento es que Claude funciona hoy como la locomotora: marca el estándar en tareas agénticas y de código, y quien depende de que el resultado sea correcto lo nota. Los modelos más baratos siguen el mismo camino con menos costo, y para una porción enorme de las tareas reales de una empresa (páginas de aterrizaje, clasificación de texto, resúmenes) esa versión “casi igual de buena” no es un compromiso. Es aritmética simple.

La distinción importante no es qué modelo es mejor en abstracto. Es que la comoditización del modelo avanza más rápido en las tareas donde una falla es barata de corregir, y más lento en las tareas donde una falla cuesta caro. El modelo que eliges para generar el resumen de una reunión no es la misma decisión que el modelo que eliges para un agente con acceso de escritura a tu base de datos de producción. Tratarlas como la misma decisión es exactamente el error que le costó la base de datos a la empresa de Replit.

Lo que hacemos en IQ Source

Ya escribí que la IA no jubila a tu experto, lo vuelve crítico: recorta los escalones de abajo de la carrera y deja en pie justo el criterio que distingue una salida correcta del relleno que la IA también produce con la misma confianza. El caso de Replit es la otra cara de esa misma moneda. Sin ese criterio en algún punto del proceso, no hay amplificador que ayude. Solo hay un error que se ejecuta más rápido y con más autoridad que antes.

Por eso, cuando mapeamos qué automatizar en la fase de discovery de AI Maestro, una de las primeras preguntas es cuáles acciones de un agente pueden ejecutarse solas y cuáles necesitan revisión humana obligatoria antes de tocar un sistema real, no como excepción, sino como parte del diseño. No es desconfianza en la IA. Es reconocer que el amplificador multiplica lo que le pongas delante, y que la diferencia entre un equipo que se vuelve diez veces más productivo y uno que borra su base de datos de producción nunca estuvo en el modelo que usaron. Estuvo en quién revisaba antes de que el modelo apretara el gatillo.