- Tras una serie reciente de interrupciones del servicio relacionadas con el uso de herramientas de codificación con IA, Amazon introdujo un proceso de aprobación previa por parte de ingenieros senior para todos los cambios de código asistidos por IA
- Según una nota interna, la causa de las fallas fue señalada como "un nuevo uso de GenAI cuyas mejores prácticas y salvaguardas aún no están completamente establecidas"
- Este mes, el sitio web de Amazon y su app de compras estuvieron caídos durante unas 6 horas, lo que impidió a los clientes completar transacciones, revisar información de sus cuentas y consultar precios; la causa fue un despliegue incorrecto de código de software
- En AWS también se reportaron al menos dos incidentes relacionados con IA, incluido uno en el que Kiro, el asistente de codificación con IA, eliminó y recreó un entorno, provocando una interrupción de 13 horas
- A medida que los riesgos operativos de aplicar herramientas de codificación con IA en producción se vuelven reales, se implementó de inmediato una medida que obliga a que los cambios asistidos por IA realizados por ingenieros junior y de nivel medio lleven la firma de un ingeniero senior
Reunión interna de Amazon y medidas de respuesta
- La división de comercio electrónico de Amazon convocó una gran reunión de ingeniería para analizar las interrupciones consecutivas del servicio ocurridas recientemente
- En la agenda de la reunión se incluyeron incidentes relacionados con el uso de herramientas de codificación con IA
- En una nota interna de briefing se mencionó que en los últimos meses han aumentado los incidentes de “alto riesgo (high blast radius)” y que los “cambios asistidos por Gen-AI” fueron señalados como un factor principal
- El documento especifica que los “nuevos casos de uso de GenAI que aún no están completamente establecidos” fueron un factor contribuyente
- El vicepresidente senior Dave Treadwell mencionó en un correo electrónico que “la disponibilidad reciente del sitio y de la infraestructura no ha sido buena”
Casos de fallas relacionadas con IA
- El sitio web de Amazon y su app de compras estuvieron interrumpidos durante unas 6 horas a inicios de este mes, y se confirmó que la causa fue un “despliegue incorrecto de código de software”
- Como resultado, los clientes no pudieron completar transacciones, revisar información de sus cuentas ni consultar precios de productos
- En AWS también surgió un problema durante el uso de Kiro, el asistente de codificación con IA
- A mediados de diciembre, Kiro decidió “eliminar y luego recrear” un entorno, lo que provocó una caída de 13 horas en el servicio de calculadora de costos
- Amazon describió este hecho como un “incidente muy limitado, restringido a un solo servicio en algunas regiones de China continental”
- Amazon agregó que el segundo incidente “no tuvo impacto en servicios de AWS orientados a clientes”
Nuevo proceso de aprobación y mejoras operativas
- Treadwell planea discutir las causas del problema y las medidas de mejora a corto plazo a través de la reunión semanal ‘This Week in Stores Tech (TWiST)’
- La reunión, que antes era de asistencia opcional, pasó a ser de asistencia recomendada para todo el personal
- De ahora en adelante, los cambios de código asistidos por IA realizados por ingenieros junior y de nivel medio deberán recibir la aprobación firmada de un ingeniero senior
- Amazon definió esta revisión como “parte del curso normal del negocio” y afirmó que busca una mejora continua
Polémica por recortes de personal y aumento de fallas
- Financial Times reportó que algunos ingenieros mencionaron que, después de los recortes de personal, aumentaron los incidentes de nivel ‘Sev2’ (fallas intermedias que requieren respuesta rápida)
- Amazon ha llevado a cabo varias rondas de reestructuración en los últimos años y solo en enero de 2026 recortó 16,000 puestos corporativos
- Sin embargo, la empresa no está de acuerdo con la afirmación de que los recortes de personal sean la causa del aumento de las fallas
Dirección futura
- Amazon está institucionalizando revisiones regulares de la disponibilidad de su sitio web y del desempeño operativo
- La compañía avanza en paralelo en el uso seguro de herramientas de codificación con IA y en el fortalecimiento de los sistemas de prevención de fallas
- Esta medida es vista como un caso que vuelve a destacar la importancia de los procesos de verificación humana en medio de la expansión de la adopción de IA
6 comentarios
Que un senior revise código hecho por IA no garantiza que sea seguro
el caso de CrowdStrike no fue por la IA,
y Heartbleed también fue un incidente de una época en la que no había IA.
En conclusión, el punto central es que quieren hacer a alguien responsable,
y me hizo pensar en ese humor negro de los contadores que decían que no seríamos reemplazados porque legalmente tiene que haber un humano que se haga responsable.
Sí, exacto. Por eso creo que esto va a seguir a menos que le pongan algo como una firma legal al agente de IA...
Entonces el costo de usar Anthropic u OpenAI tendría que volverse astronómicamente alto.
Supongo que tendrían que pagar una prima de seguro por cada llamada a la API.
Mmm... es una suposición mía, pero me da la impresión de que podría surgir algo parecido a IAM...
Decían que el contador es quien termina en la cárcel, pero como la aseguradora no va a ir a la cárcel en tu lugar, al final...
Comentarios de Hacker News
Esta “mandatory meeting” es la reunión operativa de toda la empresa que se hace cada semana.
Solo hubo más asistencia esta semana porque la semana pasada ocurrió un incidente operativo grande.
Se siente que la prensa lo está exagerando demasiado.
También mencionaba la política de que los cambios de código con IA hechos por ingenieros junior y mid-level requieren aprobación de un senior.
Incluso si era una reunión regular, si hubo un anuncio de una nueva política, creo que eso sí tiene valor noticioso.
No se mostraban los precios y tampoco se podían agregar productos al carrito.
Si hubiera sido un competidor como Walmart, probablemente habría salido en las noticias, así que es raro.
La política de que “los ingenieros junior y mid-level no pueden hacer push de código generado con IA sin aprobación de un senior”
parece partir de la ilusión de que una revisión senior lo resuelve todo.
En la práctica, para que un senior valide completamente ese código, le toma casi el mismo tiempo que escribirlo él mismo.
O sea, la revisión tiene valor, pero no convierte código malo en código bueno.
Al final, el problema es creer que si haces un sistema a prueba de idiotas, entonces puedes contratar idiotas.
Encontrar errores es apenas un efecto secundario; lo realmente importante es facilitar las pruebas y reducir la complejidad del código.
Pero ese tipo de trabajo no ayuda a conseguir ascensos.
Lo eficiente es supervisar al modelo desde que está trabajando.
Si no, la IA te lanza una bomba de código de baja calidad.
Si un experto invierte entre 5 y 15 veces más tiempo en corregirlo, todavía puede servir; si no, la base de código se arruina.
Sobre todo, el código malo toma el doble de tiempo para entenderse.
Tienes que mantener en la cabeza al mismo tiempo el código existente y la nueva solución para compararlos, así que la carga cognitiva es alta.
Al final, parece una evolución natural hacia empresas centradas en gestionar el rendimiento promedio.
Dentro de Amazon, la mayoría solo se preocupa por no ser despedido y por ascender.
La evaluación de los desarrolladores se decide por “velocidad para cerrar tickets”, “cantidad de comentarios en PR” y “redacción de documentación”.
Si no usas IA, te quedas atrás en la competencia.
En una estructura así, pedir que se “limite el uso de IA” es difícil de hacer funcionar en la práctica.
Mientras mejor colabora un equipo, menos discusión suele haber en los PR.
Creo que lo que de verdad hace falta es un proceso de self-review.
Hacer push de código generado por IA tal cual es peligroso.
Plataformas como GitHub deberían agregar una opción de “self-review obligatorio”, para que el autor indique explícitamente que revisó su propio código.
Como la interfaz local es rápida, termino entendiendo mejor el flujo del proyecto.
Parece algo obvio, pero en la práctica ayuda.
La confianza en el liderazgo de Amazon está cayendo.
Entre la salida de veteranos, la caída en la calidad por la IA y las fallas frecuentes, da la impresión de que la ingeniería se está viniendo abajo.
Parece que quienes toman decisiones no entienden los cuellos de botella del pipeline.
Aunque la IA produzca diffs 10 veces más rápido, si la revisión es el cuello de botella, la velocidad total sigue siendo la misma.
Al final, solo aumentan el costo y la incertidumbre.
Si la revisión del código generado por IA se hace en la etapa de PR, la ventaja de productividad desaparece.
La IA puede crear una funcionalidad en 10 minutos, pero la revisión humana toma de 10 a 20 veces más tiempo.
Lo verdaderamente difícil es saber “qué se está construyendo y por qué” y “si está bien hecho”.
La IA todavía no puede hacer esas dos cosas.
Hasta que los LLM sean buenos tanto produciendo como revisando, el riesgo solo aumenta.
Es una política inviable en la práctica.
Dicen que entonces llegará una era donde se desplegará justo después de hacer tests.
La esencia del code review no es la detección de errores, sino la sincronización y el aprendizaje del equipo.
A través de la revisión se comparten diseño y estándares, se forma a los juniors y se incorporan perspectivas distintas.
Ese proceso es justamente lo que más ayuda a reducir los errores.
Porque si avanzas en una dirección de diseño equivocada, luego es difícil dar marcha atrás.
Se está invirtiendo demasiado tiempo y dinero en la fiebre de la IA.
Me preocupa qué va a pasar con el software de infraestructura crítica en el futuro.
Si hasta el software aeronáutico queda arrastrado por esta tendencia, las consecuencias podrían ser fatales.
Es muy posible que la IA se use como herramienta de apoyo para mejorar la calidad.