El patrón de 3 herramientas open-source que se usan en orden: una te entrevista y arma el blueprint de la app, otra audita seguridad en paralelo con sub-agentes, la tercera detecta tu stack y deploya. Para construir apps sin saltarte ningún paso crítico.
Tres dolores reales de cualquier proyecto que querés publicar:
La "trifecta" es 3 herramientas que se encadenan en ese orden exacto. No son una sola herramienta inteligente — son 3 pasos disciplinados que la mayoría se saltea.
La analogía: vas a construir una casa. Necesitás un arquitecto que haga el plano, alguien que revise las cerraduras antes de mudarte, y un camión de mudanza que te traslade sin romper nada.
Te entrevista en 4 fases antes de escribir una línea de código:
El output final es un archivo markdown de ~16 secciones que cubre:
Es como un PRD + tech spec consolidado.
Lo bueno no es la herramienta — es forzar el flujo. Cuando le pedís a Claude "armá la app X" directo, salta a codear con todo asumido. Cuando lo metés en una entrevista de 4 fases, vos te das cuenta de las decisiones que no habías tomado.
Esto se relaciona con el patrón de spec-driven development — la diferencia es que The Architect es conversacional (te entrevista) en lugar de pedirte que escribas la spec.
✅ Proyecto nuevo, partís de cero ✅ Sabés QUÉ querés pero no cómo estructurarlo ✅ No es un script de 1 archivo — es una app real
❌ Edits/refactors sobre un proyecto existente ❌ Spike rápido para validar una idea ❌ Cuando ya tenés blueprint y solo necesitás implementar
Antes de deployar, audita seguridad lanzando 5 sub-agentes en paralelo:
Cada sub-agente tira su reporte; un coordinator los consolida.
Una sola pasada secuencial chequeando todo es más lenta y se confunde — cada chequeo requiere mentalidad distinta. Sub-agentes especializados:
Este es el patrón de memory palace / agentes especializados aplicado a auditoría.
🔴 BLOQUEANTES (no deployar)
- AWS access key en .env.example (línea 4)
- Endpoint /api/admin sin auth check
- Dep `[email protected]` con CVE-2020-8203
🟡 ALTOS (fix recomendado)
- CORS abierto a *
- Pasword reset endpoint sin rate limiting
🟢 MEDIOS (mejorables)
- 12 deps con minor versions desactualizadas
- Logs incluyen body de requests con datos sensibles
⚪ INFO
- 3 sub-deps de baja confianza (repos con <50 stars, mantenedor único)Saltearse este paso porque "es solo MVP". Los MVPs leakean secretos igual que los productos maduros. La auditoría dura 2-5 minutos. Hacela siempre.
Detecta tu stack automáticamente (Next.js, Astro, FastAPI, Rails, etc.), elige el hosting que mejor le queda y deploya:
Después de detectar:
vercel.json, Dockerfile, etc.)Errores de config no aparecen en local. Vercel/Railway pueden interpretar tu app distinto a tu npm run dev. El preview deploy es el verdadero test de configuración.
Promover a producción es 1 comando una vez que el preview funciona.
✅ Stacks comunes y bien soportados ✅ Apps que no requieren infra muy custom ✅ Cuando querés deployar rápido sin aprender la consola de cada provider
❌ Apps con requisitos específicos (GPU para inference, geo-replicación custom) ❌ Setups híbridos (parte en AWS, parte en Vercel) ❌ Compliance regulatorio que requiere control granular
La trifecta se llama así porque los 3 se usan en orden. Saltarse el orden anula el valor:
Sin blueprint, no sabés qué endpoints existen → la auditoría se pierde cosas.
Deployás sin saber qué secretos quedaron expuestos. Una vez deployado, los secretos están en logs, caches, y posiblemente en commits. Es muy difícil revertir totalmente.
Cae bien para spikes/prototipos. Pero no para nada que mire un usuario real.
Tres casos:
Si construís algo que va a vivir 2 días y solo lo vas a ver vos, los 3 pasos son overkill. Codeá y deployá directo.
Si ya tenés tu pipeline de CI/CD, agregar esta trifecta es duplicar trabajo. Los principios (blueprint + audit + deploy controlado) ya están en tu pipeline.
La trifecta te da drafts del 80%. Si vas a aplicar todo sin revisar, no la uses — vas a romper algo y no entender qué.
Más allá de estas 3 herramientas específicas, el patrón es:
Para tareas críticas, encadená herramientas especializadas en orden disciplinado en lugar de una herramienta genérica que "hace todo".
Mismo principio en otras combinaciones:
La trifecta es ejemplo concreto del meta-patrón.
Si querés replicar el patrón con tus herramientas:
CLAUDE.md del proyecto para que el equipo lo sigaEjemplo aplicado a un equipo backend:
1. PRD-bot → genera spec a partir del brief del PM
2. Schema-bot → propone migración de DB + valida contra schema actual
3. Test-bot → genera tests del endpoint con happy path + edge cases
4. Deploy-bot → corre tests + lint + audit + deploy a stagingCada uno una skill / slash command separado, encadenados.