Cómo construí tardigradoviajero sin programar, sin plantilla y sin mentor

2026-09-30

No sabía programar, no quería una plantilla y no tenía a nadie que me guiara. Tenía tres opciones sobre la mesa: pagar a alguien para que hiciera la web por mí, sin saber muy bien qué estaba pagando; utilizar una plantilla y acabar con algo parecido a muchas otras webs; o aprender a dirigir el proceso yo mismo, sin saber programar, utilizando la IA como herramienta. Elegí la tercera, no porque fuera la más fácil, sino porque era la única que me obligaba a entender de verdad qué estaba construyendo.

Antes de escribir una sola línea ya había varias cosas decididas. El logotipo principal partió de una imagen real de un tardígrado. Hicieron falta varias versiones, pruebas y renderizaciones hasta que sentí que aquello empezaba a ser mío y no simplemente otra imagen generada por una IA.

Fotografía real de un tardígrado sobre fondo blanco
El punto de partida, la imagen real de un tardígrado.
Pieza de copywriting con la imagen del tardígrado y el mensaje del proyecto
La misma idea, ya acompañada del mensaje que acabaría dando forma al proyecto.

El logotipo secundario salió casi a la primera, uno de esos aciertos que no tienen mucha explicación. La paleta de colores venía de un proyecto anterior mío de hostelería, no de una propuesta de la IA.

Logotipo secundario de tardigradoviajero con una brújula y la dirección tardigradoviajero.es
El logotipo secundario salió casi a la primera.

Y había otra condición desde el principio: la web tenía que ser accesible, no convertir la accesibilidad en un parche añadido al final. Soy maestro de Educación Especial de formación. No es un dato puesto aquí como curiosidad. Probablemente explica bastante bien por qué, si se mira esta web con atención, casi todo está pensado para ayudar, facilitar y hacer las cosas comprensibles.

Con el diseño responsive ocurrió algo parecido. Para quien no tenga ni idea de programación, responsive significa que una misma página se adapta para verse correctamente en un ordenador, una tableta o un móvil, sin necesidad de construir una web distinta para cada dispositivo. Yo utilizo muchísimo el móvil, también para revisar mis propios proyectos, así que para mí no tenía sentido hacer primero una web para ordenador y preocuparme después por cómo se veía en una pantalla pequeña.

El problema no era que la IA programara

Lo más farragoso del proceso fue enseñarle cuál era exactamente su papel. Hicieron falta muchas correcciones para establecer algo aparentemente sencillo: la IA podía asesorar, proponer, comprobar y ejecutar, pero no decidir por mí. La decisión final tenía que seguir siendo humana.

Y todavía fue más difícil conseguir otra cosa, que la calidad del proceso tuviera prioridad sobre terminar rápidamente una tarea. Una IA intenta resolver lo que le pides. El problema aparece cuando dar algo por terminado empieza a sustituir a comprobar si realmente ha entendido la instrucción, si está trabajando sobre el archivo correcto o si está respetando decisiones ya tomadas.

Ahí llegaron bastantes discusiones, y algunas instrucciones acabaron siendo bastante claras: «No tienes que parchearlo, tienes que rehacerlo». «ARCHIVO ORIGINAL → aplicar cambios solicitados → optimizar → comprobar → entregar archivo completo». «Dame el archivo correcto». «Pues arréglalo, coño». Y una que terminó convirtiéndose casi en una norma de trabajo: «Sigue trabajando. No necesitas un ok, ni un vale».

También hubo momentos algo más creativos: «Muchas cosas pendientes para haberme dado un ZIP chequeado. Voy a echar un euro en un bote por cada error y me vas a hacer rico». Detrás del enfado había casi siempre el mismo problema: una instrucción ya dada, una decisión ya tomada o información disponible que no se había comprobado antes de actuar. Y eso terminó cambiando también mi forma de trabajar con la IA.

Consola de desarrollador verificando una petición de red de Metricool en tardigradoviajero.es
Comprobando en real, no de oídas, qué estaba haciendo la web en producción.

De HTML a PHP

La web tampoco nació como se ve ahora. Empezó siendo prácticamente estática, construida con HTML y CSS. El cambio importante llegó después de hacer un curso gratuito muy básico. He realizado varios durante este proceso, pero ese me hizo comprender algo que ahora parece evidente: si la cabecera aparece en veinte páginas, no tiene sentido mantener veinte copias de la misma cabecera y modificarlas una por una cada vez que cambia algo. Ahí empecé a entender para qué podía servirme PHP. No me convertí en programador, empecé a comprender mejor la arquitectura de lo que estaba construyendo.

Página de aviso en construcción de tardigradoviajero en su primera versión en HTML estático
Así era tardigradoviajero antes de que existiera una sola línea de PHP.

A partir de ahí llegaron cabeceras y pies comunes, contenidos dinámicos, una galería gestionada mediante datos, artículos reutilizando una misma estructura y bastantes otras cosas que al comienzo ni siquiera sabía que necesitaba.

Cuando tienes que supervisar precisamente aquello que no sabes hacer

Hubo una paradoja constante durante todo el desarrollo. Utilizaba la IA porque no sabía programar, pero precisamente por no saber programar tenía que comprobar muchas veces si lo que estaba haciendo tenía sentido. Eso obliga a aprender. No necesariamente a escribir todo el código, pero sí a entender cada vez mejor qué estás pidiendo, qué archivos intervienen, qué consecuencias puede tener un cambio y qué deberías comprobar antes de dar algo por terminado.

Poco a poco dejé de aceptar una respuesta simplemente porque funcionara. Empecé a preguntar por qué funcionaba y, sobre todo, qué podía romper.

También hay decisiones que aparecen por el camino

En algún momento surgió, por ejemplo, la posibilidad de proteger el nombre comprando otros dominios relacionados con el proyecto, entre ellos .com y .org. No era algo que hubiera previsto cuando empecé. La propuesta estaba bien argumentada, tenía sentido como protección de marca y, además, el precio del primer año era muy competitivo. El segundo año ya os contaré.

Panel de IONOS con dominios tardigradoviajero registrados en varias extensiones y una conversación guiando el proceso
Protegiendo la marca, un dominio cada vez y con algún «me pierdo en el paso 3» por el camino.

Ese tipo de decisiones resume bastante bien cómo ha evolucionado el proyecto. No existía un mapa completo desde el primer día, había una dirección. Después iban apareciendo necesidades que obligaban a aprender, decidir y volver a comprobar.

Dirigir una IA cuando no sabes programar

Si tuviera que explicárselo a alguien que nunca ha trabajado así, utilizaría una comparación bastante doméstica. Es parecido a un padre que ayuda a su hijo con los deberes de una asignatura que estudió hace muchos años. Tiene que orientar, pero no recuerda todos los conceptos. Así que consulta, aprende, comprueba y, mientras intenta dirigir, también se está formando él. La diferencia es que aquí el alumno puede generar varios cientos de líneas de código en segundos. Por eso supervisar importa tanto.

De lo que más orgulloso estoy no es de haber conseguido que exista la web, es de haber mantenido el control del proceso. Y también de un método que terminé utilizando casi sin haberlo planificado: Una IA genera, yo superviso, otra IA diferente revisa o cuestiona el resultado y después vuelvo al proceso inicial.

Y esto no exige necesariamente pagar varias suscripciones. Se puede hacer perfectamente combinando cuentas y herramientas gratuitas. Tener al menos una suscripción de pago puede resultar recomendable por capacidad, límites o comodidad, pero no es obligatorio para aplicar el método.

La triangulación, además, tiene una trampa. Si le pides a otra IA que busque mejoras, casi siempre va a encontrar alguna. Eso no significa que haya que aplicarlas todas. En algún momento hay que valorar si la corrección es realmente significativa y si la mejora obtenida compensa la inversión de tiempo. También se puede estropear un proceso intentando perfeccionar indefinidamente algo que ya funciona bien. La segunda revisión no sirve para obedecerla, sirve para contrastar.

¿Lo haría otra vez?

Sí, aunque cambiaría algunas cosas. Si empezara hoy, con lo que sé ahora, probablemente dedicaría mucho menos tiempo a construir una primera versión completamente estática. Pero no eliminaría aquella etapa, también fue la que me permitió entender después por qué necesitaba cambiarla.

Y tampoco intentaría aprender programación antes de empezar. He ido aprendiendo la programación que necesitaba porque tenía algo concreto que quería construir. Y sigo sin tener ni idea de programación. Lo que sí tengo es lógica. Y creo que esa ha sido una de las claves para sacar el proyecto adelante. Lógica para detectar cuándo algo no encaja, para dividir un problema en pasos, para comprobar qué depende de qué y para saber que, si una modificación rompe tres cosas más, probablemente no está bien resuelta.

Y luego está la otra parte, la tozudez. Podría llamarla perseverancia, pero se queda corto. Cuando algo no funcionaba, seguía hasta entender por qué. Cuando una solución no me convencía, volvía a ella. Cuando una IA daba algo por terminado y yo veía que no lo estaba, tocaba otra vuelta. Lógica y tozudez. Probablemente esa combinación explica bastante mejor este proyecto que cualquier curso de programación.

tardigradoviajero sigue evolucionando y todavía quedan muchas cosas por incorporar. Pero si alguien me hubiera enseñado hace unos meses la web actual y me hubiera dicho que iba a terminar construyéndola yo, probablemente habría respondido que no tenía ni idea de cómo hacerlo. Y habría tenido razón. No tenía ni idea. La diferencia es que empecé igualmente.

Y esta web, que te recomiendo explorar, es el resultado.

En la siguiente publicación contaré algo más concreto: qué herramientas he utilizado, qué decisiones técnicas han cambiado realmente la web y cuáles fueron los errores que más tiempo me hicieron perder.

« Volver al blog