Creo que muchas empresas están atrapadas ahora mismo en una psicosis colectiva por la IA
(twitter.com/mitchellh)- Mitchell Hashimoto: "Ahora mismo, muchas empresas están atrapadas en una grave psicosis colectiva por la IA, y es imposible tener una conversación racional con ellas"
- El debate MTBF vs MTTR de la era de la automatización de infraestructura en la nube ahora se está extendiendo a toda la industria del desarrollo de software, y la fe ciega en los agentes de IA está creando una nueva forma de locura colectiva
- Se está propagando la idea absolutista del MTTR de que "como los agentes corregirán bugs rápido, está bien lanzar software con bugs", una forma de pensar que ya demostró su fracaso en la era de la infraestructura
- Los sistemas pueden parecer sanos según métricas locales y aun así degradarse hasta volverse incomprensibles en su conjunto, y que disminuyan los reportes de bugs o aumente la cobertura de pruebas no garantiza seguridad real
- Cuando se plantea directamente este problema, la conversación se bloquea con refutaciones inmediatas como "tenemos 100% de cobertura de pruebas" o "los reportes de bugs están bajando", sin ver el panorama completo
- El cambio avanza tan rápido que nadie percibe la erosión de la arquitectura subyacente, mientras se construyen máquinas automatizadas de "desastre resiliente"
Argumento central: psicosis colectiva por la IA (AI Psychosis)
- Actualmente muchas empresas están en un estado grave de psicosis colectiva por la IA, y tener una conversación racional con ellas es en sí imposible
- La razón por la que no puede mencionar personas concretas es que entre ellas hay amigos a quienes respeta profundamente a nivel personal
- Expresa una profunda preocupación por cómo podría desarrollarse esta situación
La lección de la era de infraestructura: MTBF vs MTTR
- Vuelve a surgir el debate de MTBF (tiempo medio entre fallas) vs MTTR (tiempo medio de recuperación) que se vivió durante la transición a la nube y la automatización cloud
- En ese momento estaba limitado al ámbito de infraestructura, pero ahora se ha expandido a toda la industria del desarrollo de software (e incluso al mundo entero)
- Los creyentes ciegos de la IA operan casi con una mentalidad absoluta de que "MTTR es suficiente"
- La lógica es: "como los agentes pueden corregir bugs a una velocidad y escala imposibles para los humanos, está bien lanzar software con bugs"
- La lección aprendida en la era de la infraestructura: el MTTR es excelente, pero no se puede abandonar por completo la idea de sistemas resilientes
Bloqueo de la conversación y patrones de refutación
- Cuando plantea este problema a personas que conoce personalmente, la respuesta es un desdén inmediato
- Reacciones como "no, la cobertura de pruebas es total" o "los reportes de bugs están disminuyendo"
- Estas refutaciones no muestran el panorama completo
- Ya transmitió estas preocupaciones directamente en privado, pero no fue escuchado, por lo que considera importante compartirlas en un ámbito más amplio
Máquinas automatizadas de desastre
- Una lección que ya se aprendió una vez en infraestructura: mediante automatización se pueden crear "máquinas de desastre muy resilientes"
- Puede ocurrir el fenómeno de que un sistema parezca saludable en métricas locales mientras en conjunto se vuelve incomprensible
- Disminuyen los reportes de bugs, pero los riesgos potenciales se disparan
- Aumenta la cobertura de pruebas, pero cae la comprensión semántica
- Los cambios ocurren tan rápido que nadie percibe la erosión de la arquitectura subyacente
Puntos clave en las respuestas destacadas
- @adamhjk: "Lo primero que destruye el vibe coding puro es la propia arquitectura", y para empezar debe existir una arquitectura para poder detectar su erosión
- Aclaración adicional de Mitchell Hashimoto: en infraestructura, un sistema en línea puede actualizarse para aplicar MTTR a todos los usuarios en un tiempo razonable, pero este enfoque no funciona con software que otros integran o ejecutan directamente, como bibliotecas, software de escritorio y apps móviles
- @tinygrad: hemos entrado en una era donde ya no toma 10 segundos sino 20 minutos determinar si lo que dijo la IA es información completamente errónea, y las organizaciones deben mantener contacto con la realidad
- @beyang: hoy la UX de los agentes está convirtiendo LGTM (Looks Good To Me) en el camino de menor resistencia, y la velocidad con la que los agentes generan código aparentemente plausible eleva el problema de validación en code review a una amenaza inmediata
- @beh_zod: la función de recompensa por lanzar es corta, y el tiempo que toma reconocer la deuda que la gente está acumulando supera el alcance de atención de la mayoría
- @shipwithjay: es una señal cuando el liderazgo de ingeniería no puede responder preguntas contrafactuales (¿qué tendría que ser cierto para detener esto?) y guarda silencio
- @chadfowler: está escribiendo un libro sobre este problema, y la idea central es reubicar el rigor en la arquitectura y en los marcos de evaluación; este es el momento de aplicar buenas prácticas que antes no se implementaban por falta de tiempo y dinero
Respuestas de Mitchell Hashimoto a preguntas y opiniones de la gente
- P: "¿Entonces qué deberíamos hacer?"
- R: "Pensar (usa IA, pero piensa)"
- P: Cree que pensar que "la IA está sobrevalorada" podría ser un síntoma todavía más psicótico
- R: Todas las tendencias seculares están sobrevaloradas, pero eso no es motivo para descartarlas por completo
- P: "Si tuviera que elegir entre proteger lo que tengo ahora o lanzarme al riesgo, elegiría lo segundo"
- R: Esto no es un interruptor binario
1 comentarios
Comentarios en Hacker News
Parece que la consultoría de arquitectura de IA se va a volver una gran categoría de consultoría de alto valor, como la respuesta a brechas de seguridad o los expertos en recuperación de datos
Los sistemas escritos puramente por IA pueden crecer hasta una complejidad que los humanos ya no puedan entender; la tasa de corrección de defectos baja, mientras que el consumo de tokens por defecto sube, y al final los cambios hechos por IA podrían introducir más errores de los que corrigen, volviendo todo inestable
Haría falta un procedimiento especializado para ordenar ese desastre como si fuera una clean room, extraer los principios clave de diseño y probablemente reconstruirlo desde cero, todavía usando IA
La ingeniería de software del futuro probablemente girará en torno a principios para evitar esto desde el inicio, pero así como a la ingeniería de software tradicional le tomó más de lo esperado llegar a principios de diseño estables, probablemente tomará 20 años aprenderlo
El hospital incluso le dio acceso a los servidores del departamento de IT, pero como no podía conectar Claude no tenía idea de cómo desplegarlo, así que me contactó completamente perdido, y parece que la app también tiene algunos problemas interesantes de datos/estado
Me hace pensar en alguien que recibe a su casa envíos ilimitados y gratis de productos de Amazon: en teoría es una vida abundante, pero en la práctica terminas enterrado en algo que no es prosperidad
Ya todos saben cómo terminó eso
Habían medio implementado Kubernetes dentro de miles de líneas de Github Actions y era imposible de entender
No me gusta el marketing de IA, pero sí la veo útil como herramienta para que alguien con experiencia se mueva más rápido
Eso sí, cuando la usa alguien que no es experto, la IA parece producir soluciones complejas para todo lo que intenta hacer
Parece que no está hablando tanto del uso de IA en sí, sino del fenómeno de que empresas y personas le subcontraten a la IA la toma de decisiones y el pensamiento
Escribir código con IA no es psicosis de IA ni algo malo, pero si solo metes un prompt y te crees lo que diga la IA, eso sí se acerca a una psicosis de IA
En Twitter veo seguido a gente de finanzas y VCs reemplazar pensamiento y razonamiento con screenshots de ChatGPT para cosas sobre las que podrían pensar por su cuenta aunque sea un poco
Estas herramientas son pésimas para ideas, pensamiento y consejo; solo entregan patrones que parecen patrones, así que si hablas de ideas con ellas normalmente terminan diciendo la tontería más genérica posible
En cambio, sí son bastante útiles en tareas como escribir código, donde el pattern matching realmente ayuda, pero no deberías delegarles el pensamiento ni la toma de decisiones
En general, el techo es más alto y el piso más bajo, y la descripción de arriba es muy precisa
Escribí sobre esto aquí: https://mitchellh.com/writing/my-ai-adoption-journey, https://mitchellh.com/writing/building-block-economy, https://mitchellh.com/writing/simdutf-no-libcxx
El último artículo es un cambio complejo que hice gracias a la IA, y también muestra cómo lo abordo de forma razonable
Casi siempre produce texto que parece lógicamente correcto, pero dentro de ese texto a veces vienen supuestos implícitos y decisiones equivocadas que quizá no aplican para ese caso de uso
Para construir una solución realmente correcta, la definición del problema tiene que estar bien hecha, y eso puede ser más difícil que crear la solución
O de dejárselo a cualquier consultor al azar
No sé si “la IA dijo que era una buena idea” realmente sea peor que “seguimos la tendencia de la industria”
Cuando alguien lo hace por su cuenta, sus amigos y familia suelen ponerle algún freno al señalar comportamientos o comentarios raros
Pero cuando tu empleador empieza a hacerlo desde el liderazgo, es difícil imaginar qué tan malo se puede poner
Empiezas a sentir presión para sumarte o a temer que te despidan, y las únicas personas que podrían ayudarte a regular el pensamiento son compañeros que se opongan, pero esos probablemente terminen yéndose o siendo despedidos
Si quieres conservar el trabajo, tienes que alinearte
El agente toma decisiones por ti, así que el trabajo avanza a velocidad de agente, y muchas veces decide en silencio para luego solo darte una salida final del tipo “este es el plan”
Revisarlo bien requiere entender profundamente el problema, lo que te obliga a volver a velocidad humana, así que al final terminas hojeándolo por encima y aprobándolo
La clave es decidir de forma consciente y cuidadosa qué decisiones vas a delegar
Eso implica bajar la velocidad y reduce las supuestas ganancias de 10x del vibe coding, pero a cambio te involucras más y acumulas menos deuda cognitiva
Decisiones aburridas, como cómo recorrer un arreglo o cómo encajar la salida de una llamada como entrada de otra, sí se las puedes dejar al agente
Las decisiones reales tienes que tomarlas antes y ponerlas en la especificación: definir límites, APIs, estructuras de datos centrales, sistemas y responsabilidades, manejo de errores, y restricciones fuertes de seguridad y privacidad
Si hay ambigüedad, hay que instruir al agente para que se detenga, y un buen ingeniero puede obtener una mejora de 2 a 3x sin efectos secundarios
Tal vez esto termine convirtiendo a la ingeniería de software en una disciplina de ingeniería de verdad
En este momento hay prompteros levantando toda la infraestructura de empresas
Personalmente conozco a alguien que migró la base de datos de su empresa a una versión más nueva de Postgres y, aunque al final lo logró, escucharlo explicar el proceso me hizo rechinar los dientes
Se sentía como: “Le eché gasolina al servidor y me puse a fumar, pero no te preocupes, encontré un extintor en el sótano. El medidor dice que está vacío, pero si lo sacudes todavía se oye líquido adentro”
Cuando esa persona se vaya de la empresa, van a necesitar a otro promptero todavía más confiado para mantener esa infraestructura de DB
Este texto señala que no se puede discutir con la gente que dice “está bien desplegar bugs; los agentes pueden arreglarlos a una velocidad y escala que los humanos no pueden”
Y, sin embargo, la respuesta mejor votada es justamente un ejemplo de “pero los agentes son rapidísimos”
Quizá asumen que el beneficio de duplicar el codebase y las funcionalidades supera el costo de duplicar los bugs
Al menos se verá bien en el newsletter para inversionistas de este trimestre
Podrías simplemente seguir desplegando más basura, ¿y el loop de feedback son los clientes?
La respuesta fue: “Es teoría de juegos. Alguien lo va a hacer, y tú también vas a tener que hacerlo. No puede ser tan malo”
La lógica puede ser útil, pero ignorar el riesgo es otra cosa
Es peligroso asumir que si te mueves increíblemente rápido y rompes todo, al final va a salir algo bueno
Esta ola de IA no va bien y no me gusta
No creo necesariamente que el lado con psicosis sea “el nuestro”
Trabajo en una empresa muy grande, y la nuestra siempre ha sido glacialmente lenta para modernizarse y adoptar tecnología
Pero curiosamente ahora eso podría volverse una ventaja competitiva
La vida imita al arte
Antes bromeaba con eso de que todavía usan fax, pero no imaginé que me sentiría tan afortunado de trabajar en una cultura donde no existe esta fiebre
Cuando leo HN, siento que entro en el Alice's Wonderland de los maximalistas del token y los pacientes con psicosis de IA
Aquí de verdad no conozco ni a una sola persona a la que la obliguen a trabajar así
Si te gusta esa vibra, quizá te guste la nueva herramienta CLI Burn, Baby, Burn (those tokens): https://github.com/dtnewman/burn-baby-burn/tree/main
El Show HN está aquí: https://news.ycombinator.com/item?id=48151287
Me recuerda a Simple Made Easy de Rich Hickey y al enfoque que tomó al crear Clojure
Incluso antes de que los LLM generaran programas completos, los frameworks complejos ya permitían a los desarrolladores crear una primera versión de un programa muy rápido, pero al costo de volverlo difícil de entender y por eso también difícil de depurar y modificar
Algunas personas están apostando a que, por más enredado y complejo que sea el programa que escriba la IA, la IA siempre será lo bastante inteligente como para depurarlo, mantenerlo y modificarlo
Yo no estoy tan convencido
La psicosis de IA no es una postura en contra de usar IA
Uso herramientas de codificación con IA todos los días, pero las herramientas de IA no tienen concepto de futuro
Hemos dependido de la forma egoísta de pensar del ingeniero que dice: “Si esto se rompe en producción, yo no lo voy a poder arreglar, y me van a despertar a las 3 a. m.” para construir sistemas estables
También estaba la flojera normal de no querer hacer el trabajo uno mismo y tratar de encontrar la librería perfecta en CPAN, y a veces uno tardaba más en no encontrar la librería que en escribirlo directamente
He escrito miles de líneas de código con herramientas de IA y las he puesto en producción, y en general se ha sentido natural, porque desde 2017 llevo diciéndole a la gente que no teclee todo el código a mano y que mejor lo escriba, poniendo trampas en los tests para atrapar código malo
Pero hay una cosa que la IA no hace: escribir menos código: https://xcancel.com/t3rmin4t0r/status/2019277780517781522/
Los reportes de bugs también disminuyen cuando la gente pierde la fe en que se vayan a corregir
Porque reportar bugs muchas veces requiere una inversión de tiempo considerable
Esto pasa bastante seguido cuando se rompe la confianza en algún grupo o empresa
Eso hace más probable que estén mal reportados y que parte del contenido sea incorrecto
Es como recibir ataques desde varios frentes
Y ni siquiera hemos llegado todavía a tácticas abiertamente adversariales
Si no tuvieras moral, ¿qué mejor jugada que usar agentes para inundar a tus competidores con reportes falsos de bugs?
Problema resuelto
Mucho de lo que observó Mitchell, quizá todo, podría pasar perfectamente incluso sin IA
Siento que estoy en una posición muy rara
Detesto tanto los cambios que la IA trae a la experiencia y la práctica de escribir código que me dan ganas de hacer cualquier cosa menos trabajar con computadoras, y al mismo tiempo también creo que estas herramientas son muy poderosas y siguen mejorando
El punto de Mitchell es válido: estas herramientas pueden meter cimientos podridos y quizá no se descubra hasta que toda la estructura se venga abajo
No quiero estar en una posición de responsabilidad en ese momento sin entender el codebase a profundidad como antes
Pero los humanos también llevan mucho tiempo metiendo bugs sutiles pero letales en el código
Por eso gran parte de esto todavía se siente como una pregunta empírica abierta
¿Vamos a ver muchos sistemas colapsar de formas horribles que antes no existían? Algunos probablemente sí
¿Y al mismo tiempo aprenderemos que hay que moverse más hacia especificación y verificación? No lo sé
En cualquier caso, esta forma de construir sistemas parece inevitable, aunque haya choques a medio camino
También siento que en el campo anti-IA hay su propia especie de psicosis reaccionaria
No quiero involucrarme con IA, pero tampoco puedo negar la experiencia de haber usado estas herramientas
Ojalá hubiera más espacios para discutir la IA de manera realista pero negativa
Esa también es una razón por la que Mitchell es un buen desarrollador