Hacer cambios ya es rápido y barato. Comprobarlos sigue costando lo mismo que antes, o más.
En el último texto quedé en contar qué pasa cuando cambiar una web sale barato. Lo cuento con lo que me pasó la semana pasada en la mía, porque es el caso que tengo más a mano y porque me sirvió para ver el problema con claridad.
Cinco cambios en UXMachine y cinco «ya está»
El 12 de octubre hice cinco cambios en uxmachine.app. Añadí trece páginas en inglés, una frase debajo de un botón, un enlace, unas redirecciones y una página nueva para los usuarios registrados. No escribí el código. Se lo pedí a agentes de programación, como hago casi siempre desde hace meses. Cada cambio llevó unos minutos. Cada uno acabó igual: el agente diciéndome que ya estaba.
Me fío bastante de esos agentes. Llevan meses ayudándome a construir y a mover cosas, y la mayoría de las veces aciertan o se acercan lo suficiente. Aun así, que me digan que han terminado no es lo mismo que saber que todo está bien. Hay una diferencia entre «el agente dice que lo ha hecho» y «yo he visto que funciona y que no ha roto nada de lo que me importa». Quise comprobarlo.
Qué comprobó realmente la herramienta (y qué no)
Para eso uso UXMachine, la herramienta que estoy construyendo. Abre la web en un navegador real, recorre unas cuantas páginas y les pasa una serie de comprobaciones: el contraste del texto, los títulos, las imágenes sin descripción y otras parecidas. Si la mides antes y después de un cambio, te dice qué ha aparecido y qué ha desaparecido. No es una auditoría completa ni pretende serlo. Es un conjunto concreto de medidas que se pueden repetir (los detalles de qué mira y qué deja fuera a propósito están en la metodología).
La pasé antes y después de los cinco cambios. No apareció nada nuevo, y estuve a punto de dar el día por cerrado. El informe no mostraba regresiones en lo que había mirado. En ese momento me sentí razonablemente tranquilo.
Por suerte miré qué páginas había revisado de verdad. De mis cinco cambios, solo dos estaban en esas páginas. Las trece páginas nuevas no las había mirado. El enlace tampoco, porque está dentro de una zona a la que la herramienta no entra. La página para usuarios registrados pide contraseña. Y las redirecciones solo funcionan si escribes la dirección con «www», cosa que la herramienta no hace.
El resultado era correcto, pero hablaba de una parte muy pequeña de lo que yo había tocado. Si no llego a mirar el detalle, me habría quedado tranquilo por algo que nadie había revisado. Las páginas nuevas podían tener problemas de contraste, títulos mal formados o imágenes sin texto alternativo y yo no lo habría visto. El enlace podía estar roto o apuntando a un sitio equivocado. La página de usuarios registrados podía tener un problema de flujo que solo aparece una vez iniciada la sesión. Las redirecciones podían fallar para la mayoría de la gente que escribe la dirección sin el www. Todo eso quedaba fuera de la medición.
Y eso con una herramienta que conozco bien porque la hago yo. Entender qué había comprobado y qué no me llevó bastante más tiempo que pedir los cinco cambios. Tuve que abrir el informe, ver las URLs que había recorrido, compararlas con la lista de cosas que había pedido y darme cuenta de los huecos. No es complicado, pero tampoco es automático. Requiere que sepas qué estabas intentando cambiar y qué condiciones tiene la herramienta.
Antes revisaba sin darme cuenta
Cuando hacía yo los cambios, revisar venía incluido. Para mover un botón tenía que abrir la página, encontrarlo, probar si el clic funcionaba, mirar cómo quedaba en móvil y en escritorio, volver a probar. Al terminar ya había visto cómo quedaba, casi sin querer. No era un paso separado. Era parte de hacer el cambio.
Además me acordaba de por qué había hecho cada cosa, porque lo había decidido línea a línea. Sabía qué problema estaba intentando resolver, qué alternativa había descartado y qué riesgo había aceptado. Hoy esa explicación se queda en una conversación con el agente que se pierde en cuanto cierro la ventana. El historial del chat no es un buen sitio para dejar las razones. Si dentro de tres meses alguien pregunta por qué una página está como está, o si yo mismo lo pregunto, puede que ni yo lo sepa. Tendría que reconstruirlo a partir del código y de lo que recuerdo, y el código no guarda el contexto de la decisión.
Con los agentes, hacer el cambio cuesta muy poco. Revisarlo sigue costando lo de siempre, y ahora además tengo que ir a buscarlo a propósito, porque ya no lo veo mientras trabajo. Antes la revisión ocurría de forma casi inevitable. Ahora es una tarea que puedo saltarme sin darme cuenta.
La sospecha: lo que empieza a faltar cuando cambiar es casi gratis
De ahí me viene una sospecha. Cuando cambiar algo sale casi gratis, lo que empieza a faltar es otra cosa: saber qué ha cambiado de verdad y por qué. No lo he medido. Tengo un caso, el mío, y por eso lo llamo sospecha. Puede que sea solo mi forma de trabajar. Puede que otros tengan sistemas mejores para dejar rastro de las decisiones. Pero en mi caso, la facilidad para producir cambios ha hecho más visible el coste de verificarlos y de recordar el motivo.
No es solo una cuestión de bugs. Es también una cuestión de sentido. Una página puede estar técnicamente correcta y aun así no reflejar la decisión que yo creía haber tomado. El agente puede haber interpretado la petición de una forma razonable pero distinta a la que yo tenía en la cabeza. Si no lo reviso con atención, esa diferencia se queda ahí, invisible hasta que alguien se tropieza con ella.
Esto ya lo describió Bainbridge en 1983
Esto ya pasó en las fábricas. En 1983, la psicóloga británica Lisanne Bainbridge escribió un artículo sobre las salas de control de las plantas industriales. Lo tituló «Ironies of Automation» y lo publicó en la revista Automatica (el texto completo está disponible en su propia página). Contaba que, al automatizar, el trabajo de las personas no desaparecía. Se convertía en vigilar las máquinas, y eso se nos da bastante mal cuando casi siempre funcionan. Cuando el sistema funciona el 99 % del tiempo, es fácil dejar de prestar atención. Además, quien deja de hacer una tarea acaba perdiendo la mano para saber si está bien hecha. Las habilidades se deterioran si no se practican, y cuando hay que intervenir de verdad, la persona puede no estar tan preparada como antes.
Una web no es una central eléctrica y no quiero forzar la comparación. Los riesgos son distintos y las consecuencias, por lo general, menos graves. Pero me reconocí en la descripción. El agente hizo la parte que yo sabía hacer (escribir el código, aplicar los cambios) y me dejó a mí la más pesada: vigilar, comprobar y decidir si lo que ha salido es aceptable. Y cuanto más rápido produce el agente, más difícil es mantener la atención y la práctica en esa vigilancia.
¿Quién paga la revisión cuando los cambios salen baratos?
Esto es lo que más me intriga, y no tengo respuesta.
Imagina a una diseñadora freelance que antes tardaba dos semanas en entregar una web y ahora, con agentes, la tiene en dos días. El cliente ve que el trabajo se ha hecho mucho más rápido. Si le paga menos porque tarda menos, ¿quién le paga el rato de comprobar que todo funciona? Esa comprobación no se ha acortado en la misma proporción. Sigue requiriendo abrir las páginas, probar flujos, mirar en diferentes dispositivos y pensar si el resultado corresponde a lo que se pidió.
A una agencia que cobra por proyecto le pasa algo parecido. Cada hora dedicada a revisar le sale de su margen. Si el proyecto se entrega antes, pero la revisión se mantiene o incluso aumenta (porque hay más cambios y menos memoria del proceso), el margen se reduce. Y quien recibe la web muchas veces no sabe qué tendría que comprobar. No tiene el contexto de qué se cambió ni por qué, y no siempre tiene la costumbre o las herramientas para hacerlo de forma sistemática.
No tengo datos de nada de esto. Son las preguntas que me haría si me ganara la vida haciendo webs para otros. Puede que el mercado se ajuste y que los clientes valoren más la revisión. Puede que aparezcan herramientas que abaraten esa parte tanto como se ha abaratado la producción. Puede que no. De momento solo veo la tensión.
Tres formas en las que podría estar equivocado
Puedo estar equivocado. Me equivocaría si resulta que no revisar no tiene consecuencias graves, y la gente acepta el «ya está» sin que pase nada importante. Muchas webs funcionan con imperfecciones y nadie se queja. También me equivocaría si revisar se abarata igual de rápido que hacer los cambios, por ejemplo porque otro agente revisa el trabajo del primero y lo hace bien, de forma consistente y con el alcance adecuado. O si los propios agentes acaban recordando lo que hicieron y por qué, sin necesidad de apuntarlo en otro sitio, y esa memoria es fiable y recuperable.
Cualquiera de las tres cosas podría pasar. Hay que tener en cuenta además desde dónde escribo: es una sola web, la mía, y la herramienta con la que la reviso también es mía, así que me conviene que revisar importe. Eso no invalida la observación, pero sí limita lo que puedo concluir.
Si quieres los detalles, con las medidas concretas y lo que no pude comprobar, están en esta nota en la web de UXMachine.
