Proyecto
Web Factory
Fábrica agéntica nacida al salir de mi zona de confort en backend, que convierte un intake conversacional en sitios Astro con contratos, agentes especializados y validación.
- Codex
- Node.js
- Astro
- TypeScript
- JSON Schema
- Ajv
- Playwright
- axe-core
- Git
Contexto
De qué punto partíamos
Enfoque
Cómo lo trabajé
Diseñé un compositor estático que transforma un intake versionado y una selección aprobada en un proyecto Astro autocontenido, con agentes especializados, ownership de archivos, publicación recuperable y gates técnicos, visuales y humanos.
Decisiones
Decisiones y compromisos relevantes
- Sustituir las variaciones superficiales por un compositor estático capaz de cambiar composición y jerarquía, asumiendo el coste de mantener contratos y recetas versionados.
- Separar intake, recomendación y selección aprobada para distinguir los datos del usuario, la propuesta de la IA y la decisión que autoriza su materialización.
- Publicar cada web como un snapshot autocontenido que funciona sin el monorepo, aunque las mejoras del núcleo no se propaguen automáticamente.
- Reservar al usuario la selección visual, los recursos y la aprobación de baselines para impedir que el sistema cierre por sí solo decisiones con impacto editorial.
- Proteger creación y actualización con staging, locks, hashes, journal y rollback para conservar el trabajo local ante fallos o conflictos.
- Combinar QA rápido, validación release y un tester independiente para cubrir código, navegador, accesibilidad y regresión visual antes del cierre.
Resultado
Qué cambió
- Dos familias de sitios y seis direcciones visuales por familia, materializadas en una galería de doce especímenes.
- Proyectos Astro estáticos y autocontenidos con código, recursos, documentación y herramientas de QA propias.
- Gates reproducibles para contratos, tipos, tests, build, smoke, navegador, accesibilidad y regresión visual.
- Tres proyectos reales registrados y un portfolio pre-V1 desplegado públicamente en Cloudflare.
- Baseline V1 funcional de alcance reducido, con el ciclo formal de aceptación extremo a extremo todavía pendiente de cierre.
Aprendizaje
Con qué me quedé
- La autonomía de los agentes resulta más fiable cuando trabaja dentro de contratos, ownership y estados observables.
- Separar la recomendación de IA de la aprobación humana evita convertir una inferencia del modelo en un requisito.
- Los checks técnicos necesitan una revisión contextual de contenido, responsive y dirección visual para evaluar el producto completo.
- La generación segura requiere operaciones recuperables cuando puede afectar trabajo que ya existe.
- Cerrar el recorrido extremo a extremo aporta más valor que ampliar el catálogo antes de validar la base.
Continuidad
Sigue explorando
Navega al caso anterior o siguiente, o salta a proyectos relacionados.
Más contexto
Lo que merece ampliar
Web Factory nació al comprobar cuánto contexto se pierde al construir una web desde un prompt. Una entrega completa obliga a cerrar contenido, estructura, identidad visual, recursos, privacidad, código y criterios de aceptación. Cuando esas decisiones quedan mezcladas en una conversación, el resultado puede funcionar, pero cuesta explicar por qué existe cada pieza, reproducir el proceso o actualizarlo sin introducir regresiones.
También planteé Web Factory como una salida de mi terreno habitual. Mi experiencia se concentra en backend, sistemas distribuidos y rendimiento, mientras que este proyecto me obligó a trabajar con producto, experiencia de usuario, dirección visual, accesibilidad y entrega web. Explorar esas áreas amplía mi capacidad para colaborar y tomar decisiones alrededor de mi especialización. Es la lógica del perfil T-shaped que Tim Brown popularizó en IDEO: conservar profundidad en una disciplina y desarrollar amplitud para comprender y conectar otras. Afrontar ese reto me permitió crecer en ámbitos nuevos sin alejarme de la base técnica desde la que más aporto.
Diseñé el proyecto como una fábrica local operada desde Codex. El recorrido empieza con un intake conversacional para una de las dos familias disponibles: portfolio profesional o web de marketing. El sistema conserva las respuestas originales y crea una representación normalizada con objetivo, audiencia, evidencia, rutas, funcionalidad, recursos y decisiones pendientes. Un agente estratega propone combinaciones compatibles. El usuario acepta una opción o la sustituye de forma explícita antes de que el sistema escriba el proyecto.
Esa cadena de artefactos forma el blueprint estructurado de cada web. No existe como un documento aislado, sino como intake, recomendación, selección aprobada, manifiesto de recursos, reglas de diseño y manifiesto de generación. Cada pieza tiene un contrato y una versión. El compositor utiliza ese conjunto para resolver recetas, componentes, tokens y contenido, y después genera una instantánea Astro con código, recursos, documentación y QA propios.
Organicé el trabajo mediante seis responsabilidades: contratos, estrategia, dirección de arte, curación de recursos, implementación y testing independiente. Cada asignación declara ownership sobre archivos o árboles concretos. El orquestador puede paralelizar tareas de lectura, pero serializa escritores cuando sus rutas se solapan. Los agentes entregan su trabajo mediante artefactos persistidos y estados verificables, de modo que un handoff no depende solo de lo que quede en el contexto de la conversación.
La seguridad se concentra en los puntos donde la automatización puede alterar datos o trabajo existente. El tooling valida rutas, rechaza escapes y enlaces peligrosos, compara hashes y protege las referencias visuales. Las publicaciones y actualizaciones pasan por staging, locks, journal y rollback. La selección visual, los recursos y las baselines finales requieren aprobación humana. Estos controles reducen el riesgo operativo, aunque el proyecto depende del sandbox y de las reglas del entorno de Codex para limitar comandos, red y filesystem.
La baseline V1 produjo dos familias, seis direcciones por familia y una galería de doce especímenes. El QA combina contratos, tipos, tests, build, navegador, accesibilidad y comparación visual. También existen tres proyectos registrados y una web pre-V1 publicada. El recorrido formal de aceptación V1 y parte de la integración del actualizador siguen abiertos, así que presento el proyecto como una base funcional y experimental, no como un servicio SaaS cerrado.
El aprendizaje central ha sido definir mejor la autonomía. Un agente aporta más cuando conoce su ámbito, la evidencia que debe producir y la decisión que no puede tomar. Los contratos y los estados observables convierten esa frontera en parte de la arquitectura en lugar de dejarla escondida en el prompt.