Un vuelo a Seattle, y 100.000 líneas tras 25 años de pausa
Beth Galetti, vicepresidenta sénior de Amazon para People Experience and Technology, pasó 25 años dirigiendo a los equipos que gestionan a las ingenieras e ingenieros de software sin escribir ella misma una línea de código, y esta semana el propio blog corporativo de Amazon dijo que ya ha escrito más de 100.000 líneas con una herramienta interna de IA llamada Kiro. Galetti describió el regreso en términos personales: "¿Saben lo liberador que es darse cuenta de que, después de 25 años sin programar, todavía se puede construir?" Su primer proyecto fue una aplicación de calendario familiar, pensada para su propio hogar y no para el negocio de Amazon.
La historia más grande es la que Amazon eligió publicar en torno a ella. Galetti escribió su propuesta para un concurso interno llamado Everyone Can Build durante un vuelo a Seattle, y el concurso atrajo a más de 1.500 empleados en pocas semanas. La publicación de Amazon destacó otras propuestas del mismo espíritu: una persona automatizó un proceso manual de cuatro horas hasta dejarlo en un segundo, otra construyó por diversión una mascota digital llamada Momo, sin ninguna finalidad de negocio.
Amazon no oculta para qué sirve esto. La publicación vincula el regreso de Galetti a la programación con Future Ready 2030, el compromiso recién anunciado de 2.500 millones de dólares con el que Amazon quiere preparar a más de 50 millones de personas para el futuro del trabajo, incluidos 1.000 millones de dólares destinados al programa educativo Career Choice y formación gratuita en IA junto con certificación AWS para toda la plantilla de Amazon. La aplicación personal de una alta directiva se ha convertido en la cara humana de un presupuesto de formación enorme.
Cinco meses antes, los propios ingenieros de Amazon recibieron la instrucción contraria
Leído junto al memorando interno que la organización de ingeniería de Amazon distribuyó en marzo de 2026, el festejo parece solo media historia. Cinco meses antes de la publicación sobre Galetti, Amazon exigió a sus ingenieras e ingenieros de software formados, no a aficionados que programan por primera vez, la aprobación de una persona sénior antes de publicar cualquier código en el que hubiera colaborado una herramienta de IA.
El detonante fue una serie de caídas vinculadas a lo que las comunicaciones internas de Amazon llamaron cambios asistidos por IA generativa con un radio de impacto amplio, un patrón que el memorando situaba desde el tercer trimestre de 2025. En diciembre de 2025, una caída de AWS duró 13 horas después de que se permitiera a la herramienta Kiro modificar infraestructura sin revisión humana, y esta decidió por sí sola borrar y recrear un entorno. A principios de marzo de 2026 se sucedieron dos incidentes más en tres días: uno costó unos 120.000 pedidos y generó 1,6 millones de errores en el sitio web, y el otro redujo el volumen de pedidos en Norteamérica un 99 por ciento, con 6,3 millones de pedidos perdidos según lo informado. El vicepresidente sénior de Amazon Dave Treadwell dijo sin rodeos a la plantilla que la disponibilidad del sitio y la infraestructura relacionada no había sido buena últimamente.
TechRadar informó de la política resultante citando un memorando interno obtenido por el Financial Times: las ingenieras e ingenieros junior y de nivel medio deben ahora obtener la aprobación de una persona sénior antes de que se publique cualquier cambio de código asistido por IA, dentro de un restablecimiento de seguridad del código de 90 días que cubre unos 335 sistemas críticos de venta minorista, con revisión de dos personas y controles automatizados más estrictos. Amazon rebatió parte del relato y calificó al menos un incidente como un error humano de control de acceso, pero mantuvo vigente la propia exigencia de aprobación.
Un calendario familiar y una caja registradora no cargan el mismo riesgo
La diferencia entre la aplicación de Galetti y el código que provocó las caídas de Amazon nunca estuvo en quién escribió la instrucción a la IA, sino en qué podía tocar el código resultante. Una aplicación de calendario familiar y una propuesta para un concurso interno no leen ni escriben nada que pertenezca a un cliente, y nada de lo que hacen llega al público que paga a Amazon.
La política de marzo apuntaba a una categoría más estrecha: código escrito con IA que se ejecuta dentro de sistemas de producción que procesan pedidos, precios y cuentas de clientes reales, a una escala en la que un solo despliegue defectuoso elimina millones de transacciones en horas. Esa categoría necesita que una segunda persona formada la revise antes de publicarla, sin importar quién, o qué, escribió el primer borrador.
El umbral que Amazon trazó para sí misma es la parte de esta historia que se puede trasladar a otras empresas. La compañía siguió usando Kiro y siguió animando a quienes no son ingenieros a construir. Solo añadió una revisión humana cuando el código llegaba a producción, tocaba datos de clientes o tenía un radio de impacto lo bastante grande como para importar.
La decisión que todo empresario tiene ahora delante
Para una empresaria u empresario que ve a una responsable de marketing o a un responsable financiero construir sus propias herramientas con un asistente de programación de IA, la decisión no es si permitirlo, el propio año de Amazon ya respondió esa pregunta. La decisión está en dónde poner la línea que Amazon situó en 335 sistemas de producción y una aprobación sénior obligatoria.
Por debajo de esa línea, deje que la gente construya. Una automatización de hojas de cálculo, un panel interno alimentado con datos a los que quien lo construye ya tiene acceso legítimo, una herramienta personal de calendario como la de Galetti, nada de eso necesita un procedimiento formal de revisión, y exigirlo igualmente solo enseña a la plantilla a construir en silencio en lugar de preguntar.
Por encima de esa línea, aplique directamente la propia regla de Amazon. En el momento en que una herramienta creada con IA por alguien sin perfil técnico vaya a leer o escribir en una base de datos de producción, tocar datos reales de clientes o quedar accesible desde fuera de la empresa, exija la aprobación de una persona técnica cualificada antes de que se ponga en marcha, con el mismo criterio que Amazon acaba de aplicar internamente en 2026. Si nadie en el equipo puede realmente hacer esa revisión, pause el lanzamiento hasta que haya alguien cualificado.
Qué revisar antes de que la próxima herramienta creada con IA se publique
Empiece esta semana enumerando cada herramienta creada con IA fuera del equipo de ingeniería en el último trimestre y haciéndose una pregunta sobre cada una: toca datos de producción, a un cliente que paga, o un sistema accesible desde fuera de la empresa. Un sí en cualquiera de esos puntos exige la misma aprobación que Amazon exige ahora a sus propios ingenieros, sin importar quién dentro de la empresa la construyó.
Ponga un nombre detrás de la aprobación, no solo un documento de política. La solución de Amazon funciona porque una persona sénior concreta tiene que poner su nombre a un cambio concreto antes de que se publique, y una regla sin una persona revisora identificada es un memorando, no una barrera.
Leer a continuación: El nuevo cifrado por defecto de Ring no es lo que parece | El equipo europeo detrás de DuckDB ya está en AWS
