Hoy una IA te construye una web en veinte minutos. Estructura limpia, diseño correcto, textos aprovechables. Ya no es una promesa, funciona de verdad. Quien cuente otra cosa no lo ha probado en más de un año.
Y sabe hacer más que construir. Bien conectada, también publica la página, configura la dirección y aplica los cambios. Eso tampoco es ciencia ficción.
Entonces dice: terminado.
Ese es el momento del que trata este artículo. “Terminado” dice, de entrada, que se ha trabajado en el encargo. Que el resultado funcione requiere una comprobación. Con acceso al navegador y las herramientas adecuadas, una IA puede revisar la web publicada y probar formularios. Si solo revisa su propio código, le falta lo que realmente recibe tu cliente.
Un modelo más caro no sustituye ese acceso. Hemos hecho revisar páginas varias veces por una IA, a fondo, con el encargo de encontrar fallos. Después pasó por encima un programa sencillo que no hace más que mirar la página terminada tal y como la recibe un visitante. Encontró a la primera fallos que habían superado todas las rondas de revisión anteriores. No porque sea más listo. Porque está en otro sitio.
Esa es toda la diferencia. No quién construye. Quién mira después, y desde dónde.
Cuando llevas tiempo con esto, ves que los problemas repiten siempre la misma forma. Cuatro de ellas.
Fallos que no avisan#
Estamos acostumbrados a que los ordenadores enciendan algo en rojo cuando se rompe. Con una web eso casi nunca ocurre.
El ejemplo más habitual: alguien rellena tu formulario de contacto. En pantalla aparece "Gracias, nos pondremos en contacto." El mensaje no te llega nunca. Nadie se entera. Tú no, porque sencillamente no llega nada. El interesado tampoco, porque él vio la confirmación. Espera dos días y se va al siguiente.
Lo traicionero no es el fallo. Lo traicionero es que un formulario que pierde consultas se ve exactamente igual que un formulario que nadie está usando. Una semana tranquila y una línea rota se sienten idénticas. Y nadie llama para decirte que no ha podido contactar contigo.
Fallos así no se encuentran esperando a que se noten. Se encuentran porque alguien va a mirar aunque nada indique que algo va mal.
Fallos que llegan más tarde#
En una web hay cosas con fecha de caducidad. Se renuevan solas, y normalmente eso funciona.
Cuando uno de esos automatismos se descuadra, no se lo dice a nadie. Sigue intentándolo, día tras día, sin éxito, y todo parece normal. Hasta que llega el día en que el plazo vence de verdad. Entonces la página deja de abrirse para los visitantes. No despacio, no con un aviso. No se abre.
Entre el momento en que aparece el fallo y el momento en que te das cuenta pueden pasar meses. Quien comprueba el día del lanzamiento, comprueba justo el único día en que todo sigue funcionando.
Y aquí hay una trampa de razonamiento que rara vez se le ocurre a uno solo: que algo sea válido hoy no demuestra que la renovación funcione. Solo demuestra que funcionó la última vez. Quien controla el estado en lugar del proceso, controla lo que no es.
Suposiciones que parecen hechos#
Al construir se está suponiendo continuamente. Es normal y casi siempre inofensivo: estas fotos son todas del mismo tamaño; esta página se llama como su titular; a la gente le irá más o menos como me va a mí.
El problema es que una suposición terminada se ve igual que un hecho comprobado. Por el resultado no se distingue si alguien midió o si alguien supuso.
Una vez medimos un conjunto entero de fotos para las que había un único tamaño registrado, porque es de esas cosas que uno da por hechas. Una parte tenía otras medidas, varias estaban en vertical en lugar de en horizontal. No se veía en ninguna parte. Salió a la luz solo cuando alguien abrió los archivos en vez de creerse la etiqueta que había al lado.
La variante desagradable: también el control puede consagrar una suposición. Teníamos una prueba que verificaba obedientemente si un dato era correcto, comparándolo con un valor que alguien había supuesto antes. Pasaba en verde, siempre. No encontró el fallo, lo confirmó.
Preguntas que nadie hace#
El último punto es el más silencioso y probablemente el más caro.
Una IA puede responder preguntas y también hacer preguntas de seguimiento. Eso no equivale a una revisión completa. Si no sabes que existe un registro, una mención obligatoria o un directorio relevante, quizá no lo incluyas en el encargo. Sin criterios de revisión adecuados y acceso a fuentes actuales, la IA también puede pasarlo por alto. Queda entonces una pregunta importante sin resolver aunque el borrador parezca terminado.
Por eso una web hecha por uno mismo suele fallar por una ausencia, no por un error. No hay nada roto. Falta algo que nadie sabía que faltaba.
Una herramienta puede ayudarte con esa revisión. Alguien tiene que definir su alcance, comprobar las pruebas y decidir qué puntos pendientes deben aclararse antes del lanzamiento.
Qué se deduce de esto#
Nada de esto va contra la IA, nosotros trabajamos con ella todo el día. Ha hecho la parte que se le puede encargar, y la ha hecho bien.
Pero los cuatro patrones tienen algo en común: el fallo no se ve en el resultado terminado y no se anuncia solo. Se vuelve visible cuando alguien mira, alguien que sabe dónde mirar y cuándo. Eso no es cuestión de cuidado al construir. Es otra actividad, en otro momento, desde otra dirección.
Por eso la frase "una IA puede construir una web" es cierta y engañosa a la vez. Puede construir la web. Si funciona es otra pregunta, y esa no la responde ninguna afirmación, sino una comprobación.
En la próxima parte hablamos de dónde sale esto más caro: la página funciona, se ve bien, está hecha con criterio, y aun así no la encuentra nadie.
