HumanSlop: ¿cómo puede una empresa de 110.000 millones de dólares lanzar software tan malo?

Mi compañía de gas «mejoró» su web

Acabé en la nueva web de Enbridge porque recibí un aviso de que se había cancelado el pago de mi factura a través del banco. Ya tenía una forma perfectamente funcional de pagar el gas, pero Enbridge cambió algo por su lado y me obligó a migrar.

Vale. Los sistemas cambian.

Entré en la nueva web, intenté crear mi cuenta y me encontré con esto:

La contraseña no puede tener más de 13 caracteres.

Trece caracteres.

En 2026.

Llevamos años diciéndole a la gente que use gestores de contraseñas, que genere claves largas y aleatorias y que deje de reutilizar credenciales cortas y memorizables. Mi gestor hizo exactamente lo que debía y generó una contraseña robusta. El flamante sistema de Enbridge respondió, en esencia:

Eh, eh, eh. Tanta seguridad no.

Esto no es una aplicación antigua de pantalla verde colgada de un mainframe. Es la nueva web de cara al cliente de una de las mayores empresas de infraestructura energética de Norteamérica.

Insisto en los recursos implicados. Una empresa de este tamaño puede permitirse infraestructura de identidad sofisticada, pruebas de penetración, consultores de seguridad, suites de pruebas automatizadas, ingenieros de seguridad dedicados y el proveedor de autenticación que quiera.

En algún punto de toda esa maquinaria, la respuesta final fue:

Longitud máxima de contraseña: 13. A producción.

Y luego está el diseño

Antes incluso de encontrarte con los errores, la web parece rescatada de una migración de SharePoint de 2003.

Míralo bien.

Una cabecera gris gigante. Campos de formulario diminutos. Enlaces azules subrayados. Una caja lateral con «Iniciar sesión» y «Contacto». Bloques densos de instrucciones. Bordes duros. Botones minúsculos. Decisiones de maquetación que recuerdan menos a un portal moderno de cliente y más a algo que usarías para tramitar ayudas en una oficina municipal en 1998.

Y aun así la página proclama con orgullo:

«¡Bienvenido a tu nueva experiencia en línea!»

Esa frase quizá sea lo más divertido de todo el asunto.

¿Nueva en comparación con qué? ¿Con Telnet?

Esta es una empresa que vale unos 110.000 millones de dólares, y su «nueva experiencia en línea» parece el tipo de web donde esperas ver una etiqueta <marquee> parpadeando y un sello de «Mejor visto en Internet Explorer 6» al final.

El problema no es que toda web corporativa deba parecerse a la de Apple. No debe. Un portal de facturación de servicios públicos debería ser aburrido. Debería ser limpio, rápido, obvio, accesible y prácticamente imposible de estropear.

Pero esto no es aburrido en el buen sentido. Parece viejo porque la arquitectura de información, la tipografía, la jerarquía, los espacios, los controles y los patrones de interacción son todos anticuados.

Y de nuevo:

110.000 millones de dólares.

Imagina tener mil millones de dólares solo para construir software.

Podrías contratar a algunos de los mejores diseñadores de producto del mundo. Podrías crear un sistema de diseño que funcionara en todos los puntos de contacto con el cliente. Podrías probar el portal con miles de clientes reales. Podrías hacer que el acceso fuera inmediato. Podrías hacer que la facturación funcionara de maravilla en escritorio y en móvil. Podrías obsesionarte con la accesibilidad, el rendimiento y la usabilidad hasta que no quedara nada por mejorar.

Y no harían falta mil millones para nada de esto, claro. Podrías construir una versión drásticamente mejor de esta página con una fracción ínfima de ese dinero.

Eso es lo que lo hace tan gracioso.

Esta no es la historia de una empresa sin recursos.

Es la historia de lo que pasa cuando los recursos dejan de ser el factor limitante y la calidad organizativa pasa a serlo.

Y entonces la web dejó de funcionar

Después de sortear el requisito de la contraseña, empecé a recibir fallos genéricos:

«Hay un problema por nuestra parte. Espera unos minutos e inténtalo de nuevo.»

Eso es molesto en cualquier web, pero el contexto lo empeora. Yo no me apunté voluntariamente a probar la emocionante nueva experiencia digital de Enbridge. Mi flujo de pago anterior funcionaba. Enbridge lo eliminó y me mandó al sustituto.

Si vas a forzar una migración a tus clientes, el sustituto debería funcionar.

Esta no debería ser una filosofía de producto polémica, y menos cuando la empresa que fuerza la migración vale once cifras.

La empresa de 110.000 millones que olvidó cómo funciona American Express

Finalmente llegué al formulario de la tarjeta de crédito. Enbridge mostraba American Express como tarjeta admitida, así que introduje mis datos de Amex.

Entonces llegué al campo del CVV.

American Express usa un código de seguridad de cuatro dígitos.

El formulario de Enbridge permitía tres.

Escribí tres números e intenté teclear el cuarto. No pasó nada. El campo simplemente lo rechazó.

Este es mi error favorito por lo maravillosamente sencillo que es.

No hay un caso límite sofisticado que depurar. No hay una condición de carrera escondida en un sistema distribuido. No hay una incompatibilidad oscura de navegador que solo aparece los martes cuando Mercurio está retrógrado.

Las tarjetas American Express tienen códigos de seguridad de cuatro dígitos.

Si dices que aceptas American Express, tu formulario tiene que aceptar cuatro dígitos.

Ese es todo el requisito.

Un desarrollador junior lo entendería. Un tester lo detectaría. Una prueba de integración automatizada lo detectaría. Un jefe de producto pagando la comida con una Amex lo detectaría.

Y aun así este fallo atravesó toda la maquinaria de ingeniería, proveedores, diseño, QA, seguridad, despliegue y aprobaciones de una empresa de 110.000 millones y salió vivo por el otro lado.

Eso tiene mérito.

En serio, imagina lo que podrías construir con mil millones

Mil millones de dólares es una cifra tan grande que se vuelve abstracta, así que olvida por un momento la valoración de 110.000 millones de Enbridge.

Imagina que alguien te entrega mil millones de dólares y te dice:

Construye la mejor experiencia de cliente de servicios públicos del planeta.

¿Qué podrías construir?

Podrías contratar a 500 ingenieros excepcionales a 250.000 dólares al año y mantenerlos ocho años.

Podrías montar equipos dedicados de diseño de producto, frontend, backend, seguridad, accesibilidad, fiabilidad, móvil, pagos, investigación de clientes, analítica, QA e infraestructura.

Podrías construir entornos de prueba a escala completa que replicaran producción.

Podrías probar cada método de pago. Cada navegador. Cada teléfono. Cada escenario de accesibilidad. Cada flujo de autenticación.

Podrías pagar a clientes reales para que se pasaran el día intentando romper la web. Podrías hacer estudios de usabilidad con todos los perfiles a los que sirves. Podrías contratar a especialistas para asegurar que las personas con discapacidad visual, limitaciones motoras o poca experiencia técnica pudieran pagar el gas sin frustrarse.

Podrías hacer una app. Podrías hacer una experiencia web de primer nivel. Podrías construir APIs. Podrías crear previsiones de facturación en tiempo real, analítica de consumo, información de cortes, controles de domiciliación, cuentas compartidas, alertas, notificaciones e integraciones con todas las carteras digitales importantes.

Probablemente podrías reconstruir la plataforma entera varias veces.

Y después de todo eso, aún te sobrarían cientos de millones.

Ahora recuerda: Enbridge vale unas 110 veces esa cantidad.

Obviamente la capitalización bursátil no es dinero en el banco. Enbridge no tiene 110.000 millones esperando en una caja fuerte a que alguien los gaste en campos de contraseña. No va de eso.

Va de escala.

No hablamos de un fundador con 40.000 dólares en la cuenta intentando mantener los servidores encendidos.

Hablamos de una corporación enorme con acceso prácticamente ilimitado al tipo de experiencia necesaria para resolver estos problemas.

Y el resultado es una web que parece de hace décadas, rechaza contraseñas modernas, lanza errores genéricos de servidor y dice aceptar American Express mientras rechaza un CVV de American Express.

Eso no es un problema de recursos.

Eso es Human Slop.

Más proceso no produce necesariamente mejor software

Una de las suposiciones más extrañas del desarrollo de software es que más proceso organizativo lleva de forma natural a más calidad.

Una empresa gigante tiene presumiblemente jefes de producto, jefes de proyecto, ingenieros, diseñadores, equipos de seguridad, equipos de QA, proveedores externos, consultores, procesos de cumplimiento, entornos de staging, procedimientos de despliegue, sistemas de tickets y cadenas de aprobación. Todo eso debería, en teoría, hacer que algo como un formulario de pago fuera más fiable.

Pero la complejidad también diluye la responsabilidad.

El equipo de autenticación posee una pieza. El proveedor de pagos, otra. Un equipo de frontend posee el formulario. Un sistema de diseño dicta el componente. Seguridad tiene sus requisitos. Producto escribió los criterios de aceptación. QA probó los casos documentados. Un contratista construyó una parte.

Todo el mundo puede hacer bien su trabajo asignado y el producto final seguir siendo malo.

Esa es la parte que me parece interesante.

Ninguna persona concreta decidió necesariamente construir algo estúpido. La organización produjo la estupidez de forma colectiva.

Un sistema puede pasar por capas de revisión humana, planificación, reuniones, pruebas, compras y aprobaciones y aun así llegar a producción incapaz de aceptar el código de seguridad de una de las tarjetas que dice admitir.

El dinero compra talento, pero no garantiza responsabilidad.

El dinero compra proceso, pero no garantiza criterio.

El dinero compra equipos de QA, pero no garantiza que alguien probara lo evidente.

A veces todo ese proceso solo hace que el slop salga más caro.

El slop de la IA al menos tiene excusa

Por eso también me hace gracia parte de la indignación con el software generado por IA. Estamos juzgando una tecnología que existe desde hace pocos años frente a organizaciones humanas de software que han tenido décadas para resolver esto.

Por supuesto que la IA produce código malo a veces. Por supuesto que un agente puede malinterpretar un requisito. Por supuesto que las interfaces generadas pueden contener suposiciones raras. Son problemas legítimos, y el software generado por IA debería probarse antes de llegar a los usuarios.

Pero ¿cuál es exactamente la excusa cuando cientos o miles de humanos, prácticas de ingeniería maduras, presupuestos enormes y décadas de conocimiento institucional producen el mismo resultado?

Si un agente de IA produjera un formulario de Amex que solo acepta tres dígitos, probablemente podría decirle:

American Express usa un CVV de cuatro dígitos. Arregla esto y añade una prueba de regresión.

Hay bastantes probabilidades de que el problema estuviera resuelto unos minutos después.

La gigantesca organización humana consiguió meter el fallo hasta producción.

El verdadero problema son los incentivos

Hay otra razón por la que mi experiencia con Enbridge me molestó más que una web mala cualquiera: ¿qué voy a hacer exactamente al respecto?

Si una tienda online tiene un pago horrible, compro en otra parte. Si un producto SaaS empeora, lo cancelo. Si un restaurante me da un servicio pésimo, dejo de ir.

La competencia crea un bucle de retroalimentación brutal pero eficaz:

Haz sufrir a tus clientes el tiempo suficiente y acabarás perdiéndolos.

Las compañías de servicios públicos funcionan de otra forma.

No puedo anunciar que estoy decepcionado con la experiencia de usuario de Enbridge y pedirle a otra empresa que conecte su red rival de gas natural a mi casa.

¿Cuál es mi palanca aquí?

«Arregla tu web o me llevo mis tuberías subterráneas a la competencia.»

Cuando los clientes no pueden marcharse fácilmente, desaparece uno de los mecanismos más potentes para castigar el software malo.

Eso no significa que nadie en Enbridge decidiera deliberadamente que la experiencia del cliente da igual. Seguro que allí hay mucha gente a la que le importa mucho hacer buen trabajo. Pero los incentivos cuentan aunque nadie los mencione explícitamente.

Si no puedes perder al cliente, la presión por deleitarlo es sencillamente distinta.

Y a veces esa ausencia se nota en el producto.

Esto no son problemas difíciles

Quizá sea eso lo que más me molesta.

Ninguna de mis quejas implica ingeniería complicada.

No le estoy pidiendo a Enbridge que resuelva la fusión nuclear.

Le estoy pidiendo que:

• Permita contraseñas de longitud moderna.
• Mantenga su web funcionando.
• Acepte cuatro dígitos en un campo de cuatro dígitos.
• Construya un portal que no parezca de hace décadas.
• Pruebe el sistema de facturación antes de obligar a los clientes a migrar a él.

Son problemas resueltos.

Un desarrollador competente podría arreglar algunos antes de comer. Un equipo de diseño competente podría modernizar toda la interfaz sin reinventar nada. Un proceso de QA competente debería detectar el fallo de Amex de inmediato.

Y aun así todo eso sobrevivió hasta producción en una empresa que vale decenas de miles de millones.

Eso debería hacernos replantear la suposición de que la principal amenaza para la calidad del software son desarrolladores inexpertos armados con IA.

A veces el desarrollador inexperto con un agente de IA sí se daría cuenta del problema del CVV de cuatro dígitos.

Los humanos no tienen bula de calidad

Me entusiasma el desarrollo de software asistido por IA. También creo que deberíamos ser extremadamente críticos con la basura que puede producir. Ambas posturas son perfectamente compatibles.

El código generado necesita revisión. Los agentes necesitan pruebas. Las interfaces creadas por IA necesitan usuarios reales. Las empresas no deberían publicar basura solo porque generarla salga más barato.

Pero el listón tiene que funcionar en ambos sentidos.

El software no debería quedar exento de calidad simplemente porque un modelo ayudó a construirlo.

Y el software no debería quedar exento de calidad simplemente porque lo construyeron humanos.

Si vamos a burlarnos de los sistemas de IA por generar formularios rotos, experiencias sin sentido, errores de seguridad y funciones que claramente nadie probó, deberíamos aplicar exactamente el mismo estándar a las organizaciones de software tradicionales.

Quizá incluso uno más alto.

El slop de la IA lo produce una tecnología que todavía estamos entendiendo.

El slop humano se produce después de décadas de saber cómo hacerlo bien.

La próxima vez que alguien me enseñe una aplicación ridícula generada por IA como prueba de que no se puede confiar en las máquinas para construir software, voy a acordarme de la empresa que vale unos 110.000 millones de dólares cuya nueva web de facturación consideró que mi contraseña segura era demasiado larga, cuya «nueva experiencia en línea» parecía haber sobrevivido al efecto 2000 y cuyo formulario de pago pensó que mi CVV de cuatro dígitos debía caber en tres.

Imagina lo que podrías construir con mil millones de dólares.

Luego imagina tener acceso a los recursos de una organización que vale 110 veces eso y publicar esto.