Reconstruimos todo el sitio, marca incluida, en aproximadamente una semana de junio. Fueron cerca de cuatro días de trabajo real, con días de descanso en medio, no una semana seguida. Y aun en esos días, gran parte del trabajo consistía en dejar correr las herramientas mientras mirábamos y corregíamos, no en estar nosotros al teclado. Esa experiencia, la de mirar y corregir, es de lo que trata este artículo.
Este proceso tiene dos partes. Primero construimos la marca y los lineamientos del sitio. Luego creamos el diseño y construimos el sitio en Drupal, usando nuestro propio pipeline de dev-guides y recetas agénticas. El sitio es adrupalcouple.us, y el pipeline que usamos es nuestro. Desarrollamos estas herramientas en Palcera, donde hemos escrito más sobre cómo usamos la IA en proyectos para clientes. Las aplicamos a nuestro propio sitio, así que esto no es una reseña neutral. Es un relato de lo que las herramientas hicieron bien, dónde se equivocaron con total confianza, y dónde tuvo que intervenir una persona. Mucha gente escribe sobre construir con IA y se salta esa parte. Esa parte es donde pasamos la mayor parte del tiempo.
Traemos dos perspectivas distintas, y desde la primera conversación hasta la última pasamos mucho tiempo diciéndole a la IA qué queríamos y cómo decirlo. Lo que encontramos una y otra vez es que estas herramientas te entregan algo que parece terminado. Si es realmente bueno, o solo tiene buena apariencia, es otra pregunta, y en esta construcción las dos cosas se separaron más de una vez. Mantenerlas juntas es la parte que todavía tiene que hacer una persona.
Empezó con lo que queríamos decir
La construcción no empezó en código. Empezó con lo que queríamos expresar como pareja. Somos parte de la comunidad de Drupal y de tecnología, nos gusta hacer mentoría, y no nos faltan opiniones. Los dos llegamos al trabajo desde distintos trasfondos, diseño e ingeniería de computación. De ahí vino la marca, luego el sistema de diseño, luego la voz, luego una plantilla de referencia, y solo entonces un sitio completo en Drupal.
La metodología importó más que el modelo. Definimos quiénes somos y en qué creemos antes de que algo se acercara a un layout, en ese orden, porque esas decisiones son costosas de corregir después. Todo lo que vino después tuvo que responder a ese alineamiento. Ahí es donde realmente empieza la identidad de marca, y por eso la mayoría de lo que parece una decisión de diseño empezó como una decisión de marca.
Luego vino el sistema de diseño, y la primera señal de que no se puede simplemente dejar las herramientas sueltas. Definimos la paleta desde temprano, verde azulado profundo y ciruela apagada sobre un fondo gris cálido, con una regla que nos impusimos nosotros mismos: nunca rojo, amarillo ni café. La herramienta respetó ese veto en los colores de marca y luego dejó que un amarillo se colara en el fondo neutro, el único lugar donde había decidido que la regla no aplicaba. El gris quedó beige, exactamente la familia que habíamos prohibido. Lo vimos. Carlos rastreó el porqué, re-derivó el fondo a partir del ciruela, verificó el contraste a mano y registró el problema en nuestra propia herramienta.
La tipografía que usamos es una decisión de valores, no de estilo. Fraunces para display, Atkinson Hyperlegible para el cuerpo, IBM Plex Mono para código. Atkinson Hyperlegible existe para ser legible para personas con baja visión, y la accesibilidad es un compromiso real para nosotros, así que la tipografía del cuerpo tenía que merecerlo. Esa parte quedó bien desde el principio, una vez que la IA tuvo los inputs correctos.
En qué es genuinamente buena la IA, y en qué no
Esta es la parte en la que queremos ser precisos, porque es fácil malinterpretarla. Gran parte del branding y el diseño, y honestamente también gran parte de la arquitectura de aplicaciones, es teoría. Es estrategia, técnica establecida, convenciones que alguien ya escribió. La IA es genuinamente buena en esa parte. Puede leerla y aplicarla, y puedes confiar en que lo haga. Esa parte es quizás el setenta u ochenta por ciento del trabajo, y en nuestra construcción la IA lo hizo bien. Lo que salió fue cercano a lo que produciría una buena persona de diseño o de marca. Cercano, no mejor, y solo tan cercano porque los dos lo estábamos conduciendo. Dale las mismas herramientas a alguien sin ese criterio de diseño y marca, y no obtienes algo casi correcto, obtienes algo que parece correcto y no lo es.
La parte que falta, el otro veinte o treinta por ciento, es el factor humano. Es la creatividad y la experiencia que no están escritas en ninguna guía, y es la parte que decide si el trabajo es realmente bueno. La IA no puede alcanzarla. Por eso el presupuesto que antes se gastaba en una persona de diseño o de marca no desaparece. Todavía necesitas a esa persona para la parte que más importa, la cereza del pastel.
El desacuerdo real
Hace unas semanas Carlos vio surgir esto en una conversación. Alguien le había dado a una IA el conector de Figma y las habilidades para convertir un diseño en un tema de Drupal, y el resultado, en sus palabras, fue malo. Él ofreció algunos consejos: qué tema de Drupal usar como punto de partida y unas reglas para darle al agente. Otro desarrollador respondió con una postura más simple: solo pide paridad visual y llegará ahí. Los dos estamos en desacuerdo con eso, al menos si lo que buscas son resultados realmente buenos.
El agente va a lograr paridad visual, esa parte genuinamente funciona. Nuestro footer coincidió con la referencia y pasó todas las verificaciones visuales que corrimos la primera vez. También estaba construido de forma completamente incorrecta. El convertidor había generado un módulo personalizado entero, con un block plugin en PHP, solo para hardcodear los menús del footer y el texto del tagline. En Drupal, cargar un menú es lo más nativo que hace la plataforma. No había ninguna razón para código personalizado, y como el texto del editor estaba en una llamada a $this->t() en PHP, nadie podía cambiarlo sin un desarrollador. Los píxeles estaban bien. La construcción por debajo habría sido un problema para cada editor de contenido que lo tocara después. La paridad visual no es lo mismo que construir bien. Algo puede pasar todas las verificaciones visuales y seguir siendo la forma incorrecta de construirlo.
Encontramos un problema similar con Composer. Dejada sola, la IA tomó el control y removió un módulo de Composer antes de desinstalarlo, el orden incorrecto, y un desastre para arreglar. Carlos lo detectó, pero detectarlo no es la respuesta real. La respuesta real es configurar las herramientas para que busquen la forma correcta y actual de hacer algo, en lugar de actuar con lo que ya recuerdan, que a veces está desactualizado y no tiene criterios propios. Para eso sirven los dev-guides y las recetas agénticas que Carlos ha escrito. Son nuestras opiniones sobre cómo construir bien, escritas donde las herramientas pueden encontrarlas, y ya hemos escrito antes sobre por qué nos apoyamos en ellas. En esta construcción eso significó anclar las herramientas en guías actuales y verificadas en lugar de en el starter kit o en la memoria del modelo, hasta el punto de manejar las imágenes responsivas desde una receta publicada que se verifica a sí misma al final, en lugar de dejar que la IA adivinara. Cuando las herramientas están diseñadas para encontrar primero la información correcta, hay mucho menos que una persona tenga que detectar. Siempre hay algo, pero mucho menos.
Cómo se vio el human-in-the-loop
Human-in-the-loop no es una frase que inventamos nosotros. El mundo de Drupal la usa desde hace un tiempo, y mucha gente dentro y fuera de nuestra comunidad la usa para trabajar con IA. Es exactamente lo que hicimos aquí, y mientras más pueden hacer estas herramientas, más importa, no menos. En la práctica significó que nosotros teníamos el criterio, diseñamos las verificaciones y detectamos los errores confiados mientras la máquina hacía el volumen. Tres momentos muestran cómo fue.
Incluso con un pipeline claro, la IA inventó cosas que no eran reales, y lo hizo con suficiente calidad para ser peligrosa. Fabricó un componente "failure report" con una prolija estructura de cinco etapas. Construyó un formulario de suscripción a un newsletter con doce mil suscriptores, para un newsletter que nunca ha existido. Intentó poner un byline de dos autores en cada artículo y colocar un badge que decía "the technical provocateur" en la interfaz pública. Nada de eso fue solicitado. La prueba que mató a cada uno fue simple. ¿Es esto algo real y recurrente con un camino de autoría real en Drupal, o es una postura de voz que alguien convirtió en un widget? Tuvimos que aplicar esa prueba unas seis veces, con más dificultad en el byline, porque la herramienta optimiza para una distinción plausible y la verdad es menos ordenada. Nuestro byline es de un solo autor por defecto. Solo un puñado de piezas son genuinamente de coautoría, esta entre ellas. La pareja es quiénes somos a nivel del sitio, no un sello en cada publicación.
La siguiente detección vino de una máquina, no de nosotros. Una de nuestras construcciones de tokens pasó las verificaciones automáticas, pasó la revisión de código y pasó un crítico de corrección cuyo trabajo era confirmar que el código hacía lo que decía. Tres verificaciones, todas en verde. Luego un segundo crítico, uno adversarial, miró el mismo trabajo con una sola pregunta. ¿Esto realmente cumple los criterios de aceptación? Siguió la cadena de archivos del tema y encontró un tema base sobrante que todavía se cargaba en cada página. Detuvo el merge. Enmendamos la orden de trabajo y lo reconstruimos limpio. La lección no es "usa un revisor más inteligente." Es que habíamos diseñado el desacuerdo dentro del loop a propósito, y luego Carlos tomó la decisión de parar y arreglar. La disidencia fue estructurada, y una persona fue dueña del veredicto.
Y los agentes de comparación visual, los que supuestamente verifican la paridad, exageraban constantemente. Reportaron un footer como oscuro cuando era claro en ambos lugares. Reportaron tres columnas donde había dos. Marcaron una página como tres o cuatro veces más larga cuando en realidad era más corta que la referencia, 2458 píxeles contra 3139. Así que dejamos de confiar en ellos para algo más que encontrar posibles problemas. Cada afirmación importante fue reverificada por una persona a nivel de recorte antes de que condujera a un solo arreglo. Rápido y confiadamente equivocado es el modo de falla sobre el que seguimos escribiendo en la programación con IA, y atrapamos a nuestras propias herramientas haciéndolo.
Las partes más silenciosas
La mayor parte de la construcción fue más silenciosa que los fallos, consistió principalmente en elegir la forma nativa de Drupal sobre el código personalizado, la misma regla que el footer había roto. La parte que vamos a destacar es la accesibilidad, porque empezó mal. La plantilla de referencia sacó una D en su primera auditoría automática, y no la publicamos así. Corregimos el texto de bajo contraste, añadimos soporte para la configuración propia de contraste y movimiento del lector, y escribimos una declaración de accesibilidad que no promete más de lo que hemos verificado.
Las imágenes de los artículos son generadas con IA, lo cual no nos parece un problema. Las fotos nuestras son reales, sin caras generadas por IA en ningún lugar, porque usar IA para hacer una ilustración es una cosa y falsificar a tus propias personas es otra.
Por qué esto importa más allá de nuestro propio sitio
Abrimos con la economía porque es la razón por la que esto importa más allá de nuestro propio rincón. Una marca real y un sitio bien construido solían requerir un presupuesto que solo las empresas grandes tienen, un equipo de diseño, una persona de marca, y los meses que vienen con ellos. Hacer el mismo trabajo en aproximadamente una semana de tiempo supervisado baja esa barrera. En eso estamos trabajando en Palcera, el mismo enfoque para empresas que nunca pudieron pagar un equipo de branding. La supervisión es la parte que hace que funcione, no un detalle secundario.
Así fue como resultó. Lo que hicimos es bueno, y lograrlo tomó cerca de una semana de atención a tiempo parcial en lugar de meses de un equipo. Eso vale la pena celebrarlo, y lo celebramos. Pero es bueno porque una persona se mantuvo en el loop,