Reconstruimos todo el sitio, incluyendo la marca, 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 corrida. Y aun en esos días, gran parte del trabajo consistía en dejar correr las herramientas mientras observábamos y corregíamos, no nosotros escribiendo en el teclado. Esa experiencia, la de observar y corregir, es de lo que trata este artículo.
Este proceso tiene dos partes. Primero construimos la marca y las guías del sitio. Luego creamos el diseño y construimos el sitio en Drupal, usando nuestro propio pipeline de dev-guides y agentic recipes. 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 AI en proyectos con clientes. Las aplicamos en nuestro propio sitio, así que esta no es una reseña neutral. Es un relato de lo que las herramientas hicieron bien, dónde estuvieron equivocadas con toda confianza, y dónde tuvo que intervenir un humano. Mucha gente escribe sobre construir con AI y omite esa parte. Esa parte es donde pasamos la mayor parte del tiempo.
Traemos dos perspectivas, y desde la primera conversación hasta la última pasamos mucho tiempo diciéndole a la AI lo que queríamos y cómo expresarlo. Lo que nos encontramos una y otra vez es que estas herramientas te entregan algo que parece terminado. Si realmente es bueno, o solo tiene buena apariencia, es una pregunta diferente, 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 un humano.
Empezó por lo que queríamos decir
La construcción no empezó en código. Empezó por 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 venimos al trabajo desde distintos trasfondos, diseño e ingeniería en computación. De ahí surgió 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 qué defendemos antes de que algo se acercara a un layout, en ese orden, porque equivocarse en esas decisiones después sale caro. Todo lo que vino después tenía 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 comenzó como una decisión de marca.
Luego llegó el sistema de diseño, y la primera señal de que no puedes simplemente dejar correr las herramientas sin control. Definimos la paleta desde el principio, teal profundo y ciruela apagado sobre un fondo gris cálido, con una regla que nos pusimos a nosotros mismos: nunca rojo, amarillo ni marrón. La herramienta respetó ese veto en los colores de marca y luego dejó colarse un amarillo en el fondo neutral, el único lugar donde decidió que la regla no aplicaba. El gris quedó beige, exactamente la familia que habíamos prohibido. Lo vimos. Carlos rastreó el por qué, derivó el fondo nuevamente a partir del ciruela, verificó el contraste a mano, y registró el error contra 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 ganarse ese lugar. Esa parte salió bien desde el principio, una vez que la AI tuvo los insumos correctos.
En qué es genuinamente buena la AI, y en qué no
Esta es la parte en la que queremos ser precisos, porque es fácil malinterpretarla. Mucho del trabajo de marca y diseño, y honestamente también mucha de la arquitectura de aplicaciones, es teoría. Es estrategia, técnicas establecidas, convenciones que alguien ya dejó escritas. La AI es genuinamente buena en esa parte. Puede leerla y aplicarla, y puedes confiar en que lo hará. Esa parte representa quizás el setenta u ochenta por ciento del trabajo, y en nuestra construcción la AI lo hizo bien. Lo que salió era cercano a lo que produciría un buen diseñador o alguien experto en marca. Cercano, no mejor, y solo eso de cerca porque los dos lo estábamos manejando. 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, ese 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 AI no puede alcanzarla. Por eso el presupuesto que antes gastabas en un diseñador o en un experto en 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 observó cómo esto surgió en una conversación. Alguien le había dado a una AI el conector de Figma y las instrucciones para convertir un diseño en un tema de Drupal, y el resultado, en sus palabras, fue pobre. Él ofreció algunos consejos, qué tema de Drupal usar como punto de partida y algunas reglas para darle al agente. Otro desarrollador respondió con una postura más simple, solo pídele paridad visual y llegará ahí. Los dos estamos en desacuerdo con eso, al menos si buscas resultados realmente buenos.
El agente llegará a la paridad visual, esa parte genuinamente funciona. Nuestro footer coincidió con la referencia y pasó cada verificación visual que hicimos la primera vez. También estaba construido completamente mal. 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 $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 estar bien construido. Algo puede pasar cada verificación visual y aun así ser la forma incorrecta de construirlo.
Tuvimos un problema similar con Composer. Dejada sola, la AI tomó el control y eliminó un módulo de Composer antes de desinstalarlo, el orden incorrecto, y un desastre para resolver. 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 según lo que ya recuerdan, que a veces está desactualizado y no tiene criterios propios. Para eso son los dev-guides y agentic recipes que Carlos ha escrito. Son nuestras opiniones sobre cómo construir bien, escritas donde las herramientas pueden encontrarlas, y hemos escrito antes sobre por qué dependemos de ellos. En esta construcción eso significó anclar las herramientas en guías actuales y verificadas en lugar del starter kit o la memoria del modelo, hasta el punto de manejar las imágenes responsivas desde una recipe publicada que se verifica a sí misma al final, en lugar de dejar que la AI lo adivinara. Cuando las herramientas están construidas para encontrar la información correcta primero, hay mucho menos que un humano tenga que corregir. Siempre hay algo, pero mucho menos.
Cómo se veía human-in-the-loop en la práctica
Human-in-the-loop no es una frase que inventamos. El mundo de Drupal la ha usado por un tiempo, y mucha gente dentro y fuera de nuestra comunidad la usa para trabajar con AI. 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 tomamos las decisiones, diseñamos las verificaciones, y detectamos los errores confiados mientras la máquina hacía el volumen. Tres momentos muestran la forma que tomó.
Incluso con un pipeline claro, la AI inventó cosas que no eran reales, y lo hizo lo suficientemente bien como para ser peligroso. Fabricó un componente de "informe de fallas" con una estructura prolija de cinco etapas. Construyó un formulario de suscripción al newsletter con doce mil suscriptores, para un newsletter que nunca ha existido. Intentó poner una firma 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 eliminó cada uno fue simple. ¿Es esto algo recurrente real con un camino real de autoría en Drupal, o es una postura de voz que alguien convirtió en un widget? Tuvimos que aplicar esa prueba unas seis veces, la más difícil con la firma de autores, porque la herramienta optimiza hacia la distintividad plausible y la verdad es menos ordenada. Nuestra firma es de un solo autor por defecto. Solo un puñado de artículos son genuinamente co-escritos, este entre ellos. La pareja es quiénes somos a nivel del sitio, no un sello en cada publicación.
La siguiente corrección vino de una máquina, no de nosotros. Uno de nuestros token builds pasó las verificaciones automatizadas, pasó la revisión de código, y pasó un critic 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 critic, uno adversarial, revisó 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 rezagado que se seguía cargando en cada página. Detuvo el merge. Ajustamos 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 en el loop a propósito, y luego Carlos tomó la decisión de parar y corregir. El disenso era estructurado, y un humano era dueño 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 lados. 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 cosas. Cada afirmación importante fue re-verificada por una persona a nivel de recorte antes de que impulsara una sola corrección. Rápido y equivocado con confianza es el modo de falla sobre el que seguimos escribiendo en programación con AI, y detectamos a nuestras propias herramientas haciéndolo.
Las partes más tranquilas
La mayor parte de la construcción fue más tranquila que los fallos, en su mayoría eligiendo la forma nativa de Drupal sobre el código personalizado, la misma regla que el footer había roto. La parte que vamos a señalar es la accesibilidad, porque empezó mal. La plantilla de referencia obtuvo una D en su primera auditoría automatizada, y no la publicamos así. Corregimos el texto de bajo contraste, agregamos soporte para las propias configuraciones de contraste y movimiento del lector, y escribimos una declaración de accesibilidad que no reclama más de lo que hemos verificado.
Las imágenes de los artículos son generadas por AI, lo que no nos genera ningún problema. Las fotos de nosotros son reales, sin caras de AI en ningún lado, porque usar AI para hacer una ilustración es una cosa y falsificar a tu propia gente 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 tienen las empresas más grandes, un equipo de diseño, un experto en marca, y los meses que eso conlleva. Hacer el mismo trabajo en aproximadamente una semana de tiempo supervisado baja esa barrera. Eso es en lo que 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 salió todo. Lo que hicimos es bueno, y llegar ahí tomó aproximadamente una semana de atención a tiempo parcial en lugar de meses de trabajo en equipo. Eso vale la pena celebrarlo, y lo celebramos. Pero es bueno porque una persona se mantuvo en el loop, no a pesar de ello. La AI puede