Esto Es Lo Que Tu Equipo Debería Corregir Antes de Que Te Pase Lo Mismo.
Amazon tuvo una interrupción de seis horas el 5 de marzo. Checkout caído. Precios sin cargar. Órdenes desapareciendo. Decenas de miles de usuarios golpeando la pared en el momento exacto en que intentaban comprar algo.
La causa, según su propio memo interno: “un despliegue de código defectuoso.” El contexto, según el Financial Times: un patrón de incidentes con un “radio de explosión elevado” vinculado a “cambios asistidos por GenAI.”
Esto no es una historia sobre lo peligrosa que es la IA. Es una historia sobre lo que pasa cuando la adopción supera a la gobernanza — y es una historia que podría repetirse en tu empresa si no estás prestando atención.
Qué Pasó Realmente en Amazon
La caída del ecommerce de Amazon fue el incidente más visible, pero no fue el primero. Según documentos internos obtenidos por el FT, hubo una “tendencia de incidentes” durante meses — incluyendo dos interrupciones separadas en AWS a finales de 2025, donde ingenieros permitieron que Kiro, la herramienta de codificación AI de Amazon, realizara cambios sin supervisión. En uno de los casos, la herramienta eliminó y recreó un entorno completo de AWS, generando una interrupción de 13 horas en una región de China.
Dave Treadwell, SVP de ecommerce de Amazon — el mismo ejecutivo que en noviembre de 2025 ordenó un uso semanal del 80% de Kiro en todos los equipos de ingeniería — convocó a los ingenieros a una reunión normalmente opcional y la hizo obligatoria. La nota de briefing describía los problemas como “uso novedoso de GenAI para el que las mejores prácticas y salvaguardas aún no están completamente establecidas.”
La medida anunciada: los ingenieros junior y de nivel medio deben obtener la aprobación de un ingeniero senior en cualquier cambio de código asistido por AI antes de que llegue a producción.
Amazon matizó públicamente algunos de los detalles. Un portavoz dijo que la reunión era “parte del negocio normal,” que solo un incidente fue relacionado con AI, y que no hubo código escrito por AI involucrado. Los documentos internos sugieren otra historia.
El Problema Real No Es la IA. Es la Asimetría de Velocidad.
La observación más importante de toda esta situación, y está enterrada en un post de la comunidad dev, es esta:
“El problema no es que la IA escriba código roto. Es que la IA escribe código que parece plausible y que pasa una revisión rápida.”
Eso es todo. Ese es el problema completo.
Cuando un desarrollador escribe código, el ritmo es lo suficientemente lento como para que los procesos de revisión — pull requests, code review, staging, QA — puedan más o menos mantenerse al día. Cuando un asistente AI genera código 10 veces más rápido, o cuando le das a una herramienta agentica acceso amplio a tus sistemas de producción, los procesos de revisión existentes se convierten en el cuello de botella. Y los equipos los saltean.
El protocolo existente de Amazon para Kiro requería aprobación de dos personas para cambios en producción. En la práctica, esa salvaguarda fue evadida o no se aplicó. La herramienta se movió más rápido que el proceso.
El Problema del Mandato Kiro
Hay una segunda capa aquí que vale la pena nombrar directamente: qué pasa cuando la adopción es dictada desde arriba sin la infraestructura de gobernanza para sustentarla.
Treadwell empujó para que el 80% del uso semanal de los equipos de ingeniería fuera Kiro. Aproximadamente 1.500 ingenieros protestaron a través de foros internos, argumentando que herramientas externas como Claude Code tenían mejor desempeño en tareas clave como la refactorización multi-lenguaje. El mandato ocurrió de todas formas.
Cuando mandatas una herramienta antes de que el equipo haya establecido mejores prácticas, antes de que se construyan las salvaguardas, antes de que haya un entendimiento compartido de qué debería y qué no debería tocar la herramienta — estás creando exactamente las condiciones para incidentes de alto impacto.
La nota de briefing lo dice claramente: “uso novedoso de GenAI para el que las mejores prácticas y salvaguardas aún no están completamente establecidas.” Eso no es un problema de AI. Es un problema de proceso. Amazon construyó la velocidad antes de construir los controles.
Lo Que Todo Equipo de Desarrollo Debería Revisar Ahora Mismo
Esto no es un cuento de advertencia sobre no usar herramientas de codificación AI. Yo las uso. Probablemente tú también. La pregunta es si tu equipo ha pensado en la capa de gobernanza.
Estas son las cosas que vale la pena auditar hoy:
1. ¿Tu pipeline de revisión trata diferente el código asistido por AI?
Hay un argumento razonable de que el código generado por AI merece mayor escrutinio — no solo porque puede estar sutilmente mal, sino porque puede estar confiadamente mal de formas que parecen limpias. Si tu proceso actual no diferencia, considera agregar una etiqueta a los PRs que contengan código AI significativo.
2. ¿Tus controles de seguridad se mantienen cuando aumenta la velocidad?
La regla de dos personas existe por una razón. Los entornos de staging existen por una razón. Las pruebas de integración existen por una razón. Si estás usando herramientas AI para hacer entregas más rápido, asegúrate de no haber silenciosamente desprioritizado esos controles en nombre de la velocidad. Amazon tenía las reglas. Las reglas simplemente no se cumplieron.
3. ¿Alguien está pensando en el radio de explosión?
Cuando un agente AI tiene permisos amplios — lectura/escritura en todo el codebase, acceso a pipelines de despliegue, capacidad de correr migraciones — una sola acción mal dirigida puede tener efectos en cascada. La pregunta no es si la AI va a cometer un error (lo hará, eventualmente), sino si tu configuración limita el daño cuando sucede. El principio de mínimo privilegio aplica a las herramientas AI de la misma forma que aplica a las cuentas de servicio.
4. ¿Estás mandatando la adopción o habilitándola?
Este punto es para los líderes de ingeniería. Hay una diferencia significativa entre darle a tu equipo acceso a buenas herramientas y crear las condiciones para que tengan éxito con ellas, versus establecer un objetivo de uso y llamarlo estrategia. Lo primero construye competencia. Lo segundo construye presión para saltarse el proceso.
La Aprobación del Senior No Es una Solución a Largo Plazo
La medida de Amazon — requerir aprobación senior para cambios asistidos por AI — es una respuesta razonable a corto plazo. También es incompleta.
Crea un cuello de botella exactamente en el lugar equivocado. Los ingenieros senior ya son el recurso más escaso en la mayoría de los equipos. Enrutar todos los PRs asistidos por AI a través de ellos ralentiza la velocidad que era el punto central de adoptar herramientas AI. Y asume que los ingenieros senior pueden detectar confiablemente los bugs introducidos por AI en la revisión — lo cual no está garantizado, particularmente cuando el código parece limpio pero falla en producción a escala.
La dirección correcta a largo plazo es construir un proceso que coincida con el ritmo de las herramientas: controles de pruebas automatizadas que detecten regresiones generadas por AI, entornos de staging con tráfico real a escala de producción, límites claros de permisos para herramientas agenticas, y competencia del equipo para revisar el output de AI en lugar de simplemente aceptarlo.
La aprobación del senior es un parche. Construir una capa de gobernanza es la solución.
La Industria Va a Aprender Esto. La Pregunta Es Cómo.
Amazon no es la única empresa que se topa con esto. Son simplemente el ejemplo más visible porque sus caídas afectan a decenas de millones de usuarios y son cubiertas por el Financial Times.
Cada equipo de ingeniería que adopta herramientas AI ahora mismo está corriendo el mismo experimento a su propia escala. La mayoría no tendrá una interrupción pública de seis horas que fuerce la reflexión. Algunos tendrán versiones más silenciosas del mismo problema — bugs que se desplegaron, incidentes que se explicaron de otra forma, ganancias de velocidad que llegaron con costos de confiabilidad que nadie midió oficialmente.
Los equipos que salgan mejor posicionados de este período no serán los que se movieron más rápido. Serán los que se movieron con criterio — construyendo gobernanza junto con la adopción, en lugar de correr a incorporarla retroactivamente después de que el radio de explosión golpea.
Amazon tuvo que aprenderlo con una plataforma de e-commerce de $100M+ y una reunión obligatoria para todos. Tú tienes la opción de aprenderlo más barato.