En una experiencia anterior pedí a Claude una página de presentación moderna, minimalista y responsive para una aplicación móvil. La especificación describía una estética limpia, una paleta de azules, navegación fija y una llamada visible a descargar la aplicación. También pedía transmitir confianza. Recupero este trabajo histórico por las decisiones de implementación y por una intervención posterior que añadió una condición práctica: poder abrir la página desde la red local.

Un diseño convertido en un archivo

Claude decidió construir un HTML autocontenido, con estilos y comportamiento incluidos en el mismo archivo. Esa elección apareció desde su primera respuesta y después en el resumen de entrega. La IA reportó haber incorporado navegación adaptable, tarjetas de beneficios, preguntas frecuentes y llamadas a la descarga. Para las vistas del teléfono eligió dibujos hechos con CSS, en lugar de fotografías o capturas de una aplicación real.

La decisión tuvo una consecuencia directa: el resultado podía servirse como una carpeta estática. La entrega no describía una aplicación con backend ni un proceso de compilación. Sí mencionaba una dependencia externa para las fuentes y alternativas tipográficas del sistema. Llamarlo autocontenido, por tanto, describía cómo se agrupaban el HTML, los estilos y el JavaScript; no acreditaba que todos sus recursos funcionaran sin conexión.

Confianza sin ampliar las promesas

En el resumen, Claude explicó que había usado textos generales de seguridad y evitado afirmar mecanismos concretos como cifrado, biometría o certificaciones. Ese límite es relevante porque la petición de transmitir confianza era una condición de comunicación. El historial no aporta una auditoría del producto que permita tratar esas prestaciones como comprobadas.

Un HTML pasa por la selección de puerto libre hasta una prueba local, con acceso remoto aún por comprobar.
Diagrama conceptual propio de las decisiones documentadas; no es una captura del trabajo real.

Claude también reportó que las etiquetas estaban balanceadas y que había revisado vistas de escritorio y móvil mediante una captura. La muestra autorizada conserva su descripción, pero no los resultados completos de esas comprobaciones. Puedo contar qué revisión anunció la IA; no afirmar que yo validé personalmente todos los tamaños de pantalla. Además, la entrega dejó pendientes los destinos definitivos de los botones de las tiendas.

Mi nueva condición: verla en la red

Después pedí levantar la página en un puerto de una familia concreta y hacerla accesible en la red. Esa intervención desplazó la tarea desde la composición visual hacia la ejecución. Claude eligió un servidor estático de Python y anunció que escucharía en las interfaces de red. Al intentar usar los primeros puertos encontró que estaban ocupados y reportó haber utilizado el siguiente disponible.

La elección inicial del HTML facilitó este paso: no hubo que introducir otro sistema para servir la página. En cambio, la condición de red añadió cuestiones que el diseño no resolvía por sí mismo, como la disponibilidad del puerto y un posible bloqueo del firewall. Claude indicó cómo acceder y cómo detener el proceso, pero el historial no contiene una prueba realizada desde otro dispositivo.

El resultado documentado es una página que Claude declaró terminada y un servidor que reportó como activo y respondiendo. Quedaban los enlaces definitivos de descarga y la comprobación externa del acceso. No hay una aprobación humana final que permita cerrar esas cuestiones como resueltas.

Este episodio muestra cómo una condición añadida después de la entrega puede revelar nuevas decisiones. La IA eligió tanto la forma del archivo como la manera de servirlo; mi petición posterior hizo visibles sus consecuencias. Una página revisada localmente y una página accesible desde otro equipo corresponden a comprobaciones distintas, y el relato debe conservar hasta dónde llegó cada una.