Karpathy alerta sobre “apagones de inteligencia”

Share

Andrej Karpathy resumió en una frase una dependencia que muchos todavía prefieren no mirar de frente: “intelligence brownouts”. Su comentario llegó después de que una caída en OAuth afectara a Claude.ai y Claude Code el 11 de marzo, dejando a varios desarrolladores sin acceso mientras la API seguía operativa. En su caso, dijo que sus autoresearch labs “quedaron borrados” por la interrupción.

No fue solo una queja de X. Fue una señal de algo más grande: ya hay gente construyendo, investigando y programando con flujos donde la IA no es un apoyo ocasional, sino parte del sistema nervioso del trabajo. Y cuando esa capa falla, no pierdes comodidad: pierdes capacidad mental externalizada.

¿Qué pasó con Claude y por qué importó tanto?

La página de estado de Anthropic registró el incidente el 11 de marzo. A las 14:44 UTC empezó la investigación y luego la compañía aclaró que el problema afectaba a Claude.ai y a las acciones de login/logout en Claude Code, mientras que la API no estaba impactada. El incidente quedó resuelto a las 17:11 UTC, después de unas tres horas de degradación visible.

Ese detalle es clave. El modelo no estaba “apagado” del todo; lo que falló fue una capa de acceso. Pero para el usuario final da casi lo mismo si la inteligencia sigue viva detrás del telón: si no puedes autenticarte, no puedes usarla. Es la diferencia entre tener electricidad en la central y no poder abrir la puerta de tu casa.

Medios como Awesome Agents y reportes citados por GV Wire hablaron de miles de usuarios afectados y de desarrolladores atrapados a mitad de tarea. En algunos casos, la comunidad incluso empezó a compartir parches improvisados para ampliar tiempos de espera en el flujo de autenticación. Eso ya no suena a “un chat que se cayó”; suena a una herramienta de trabajo crítica que falló en horario laboral.

¿Por qué Karpathy lo llamó “apagones de inteligencia”?

Porque el término captura algo que empieza a sentirse real: cuando delegas partes de tu trabajo cognitivo a sistemas externos, una caída no solo te quita acceso a una app, también te baja el rendimiento. Karpathy viene de publicar autoresearch, un proyecto open source pensado para dejar a agentes iterando experimentos de entrenamiento de modelos de forma autónoma durante horas o días. Si ese laboratorio depende de credenciales, sesiones y servicios remotos, un fallo de autenticación puede cortar todo el circuito.

En su README, autoresearch se presenta como una forma de dejar a un agente modificar código, ejecutar entrenamientos cortos, evaluar resultados y repetir el ciclo sin intervención humana constante. VentureBeat reportó ejemplos de más de 100 experimentos en una noche y mejoras acumuladas en métricas de entrenamiento. O sea: no hablamos de una demo simpática, sino de una forma de convertir horas de cómputo y prompts bien diseñados en avance técnico real.

Ahí está la fuerza de la expresión “brownout”. No es un apagón total de internet ni el colapso de todos los modelos, sino una caída parcial que igual reduce la capacidad disponible del sistema. Y si tu sistema de trabajo ya incorpora IA como copiloto, revisor, generador o ejecutor, el brownout también te pega a ti.

La dependencia ya está aquí, aunque no todos la admitan

En descubre.ai ya hemos tocado esta incomodidad desde varios ángulos. Por un lado, la dependencia de Claude Code ya estaba empezando a afectar productividad y estrés en desarrolladores. Por otro, también vimos que usar LLMs para programar puede ahorrarte tiempo mientras te cobra comprensión del código. Ambas cosas pueden ser ciertas a la vez: produces más, pero también quedas más expuesto si la herramienta falla o si tu criterio se atrofia.

La parte incómoda es que la dependencia no siempre viene por pereza. A veces viene porque la herramienta funciona demasiado bien. Claude Code, GPT-5.x, Gemini y otros agentes ya aceleran debugging, refactors, scaffolding, documentación y exploración de código a un nivel que vuelve racional reorganizar tu flujo alrededor de ellos. El problema aparece cuando la arquitectura de acceso, permisos, identidades o sesiones no tiene el mismo nivel de resiliencia que el modelo.

  • El modelo puede estar bien: pero el login falla.
  • La API puede seguir viva: pero tu interfaz habitual queda muerta.
  • Tu conocimiento sigue ahí: pero tus hábitos ya cambiaron y el bajón se nota.

Eso es exactamente lo que vuelve útil la metáfora de Karpathy. Igual que un brownout eléctrico no corta toda la energía, pero sí degrada aparatos y operaciones, un brownout de inteligencia no elimina tu capacidad de pensar, pero reduce la capacidad efectiva del stack con el que trabajas cada día.

¿Qué debería cambiar a partir de aquí?

Lo primero es asumir que la confiabilidad de la IA ya no es un detalle secundario. Si un modelo o un agente está dentro de tu flujo de ingresos, producto o investigación, necesitas diseñar failovers de la misma forma en que diseñas backups o redundancia para bases de datos. Karpathy lo planteó en miniatura al decir que tendría que pensar mejor sus failovers. Ese comentario vale para cualquiera que tenga procesos montados sobre proveedores externos.

Lo segundo es diferenciar entre “modelo” y “capa de acceso”. El incidente de Anthropic mostró que la API podía seguir operativa mientras la experiencia de usuario se caía. Eso sugiere una regla práctica: si tu negocio depende de estas herramientas, te conviene tener más de una ruta de entrada. API además de app. Exportaciones locales además de contexto remoto. Alternativas de proveedor además de una sola suscripción estrella.

Lo tercero es cultural. Estamos entrando en una etapa donde la pregunta ya no es solo “qué puede hacer la IA”, sino “qué tanto se rompe tu trabajo cuando la IA tropieza”. Son preguntas distintas. La primera es de capacidad. La segunda es de infraestructura y dependencia.

Por qué importa

La frase de Karpathy pega porque llega justo cuando el software basado en agentes empieza a pasar de novedad a hábito. Hoy todavía suena exagerado hablar de “apagones de inteligencia”, pero la idea va a envejecer bastante bien si seguimos moviendo análisis, escritura, programación e investigación a servicios externos con autenticación centralizada.

La buena noticia es que esta dependencia también revela el valor real de estas herramientas: si una caída se siente como bajar varios puntos de IQ colectivo, es porque ya se volvieron una prótesis cognitiva potente. La mala es que las prótesis también fallan, y cuando fallan descubres cuánto músculo delegaste.

La conversación interesante no es si deberías dejar de usar IA. Eso ya pasó. La conversación es cómo construyes trabajo aumentado sin volverlo frágil. Y en eso, el tuit de Karpathy no fue exageración: fue diagnóstico.


Fuentes

Leer más

Otras noticias