Metodología de trabajo ARCIS

IA como herramienta
de ingeniería No como un asistente. Como un equipo.

Roles especializados, contexto controlado, economía de tokens. Así construyo productos reales con mi metodología ARCIS: seguridad y sin deuda técnica.

Roles IA especializados Contexto estructurado Economía de tokens Prompts versionados
Proyecto más grande ~1.3M tokens
Ventana operativa 50K tokens/sesión
Roles IA activos 3 contextos
Contexto de entrada ~20K · 11 docs
Pipeline de modelos Claude · Gemini · Groq · GPT-4o
Stack técnico REST API · PWA · Headless · PHP · Node
01

El error más común al usar IA es tratarla como un asistente genérico. La IA es tan buena como el sistema que la rodea. ARCIS construye ese sistema: documentación estructurada, roles especializados y economía de contexto antes de escribir una sola línea de código. El resultado no es código que parece correcto: Es código que encaja con el proyecto real.

ARCIS Architecture · Roles · Context · Intelligence · Sessions
02
01
Fase 1 Documentación de arquitectura

Antes de abrir Claude, todo el proyecto existe en documentos. Esquema de base de datos, endpoints, flujos de usuario, convenciones de código. La IA no inventa la arquitectura — la implementa.

SCHEMA.sql API_SPEC.md CONVENTIONS.md TIMING.md Estructura de carpetas definida
PROYECTO NUEVO FAVORITOS 📋 Documentos 🖥 Escritorio ⬇ Downloads PROYECTOS 📁 PROYECTO NUEVO 📁 Prompt versioning 📁 repo 📁 Tokens estimations ETIQUETAS Verda Vermella Violeta Nombre Modificado Tipo 1.PROMPT_INICIAL.txt Hoy, 9:15 Texto 2.backup.json Hoy, 9:12 JSON 3.CLAUDE.md Ayer, 22:47 Markdown 4.ROADMAP.md Ayer, 22:44 Markdown claude Carpeta agents AGENT_AUDITOR.md ★ CLAVE AGENT_DEVELOPER.md ★ CLAVE AGENT_QA_TESTER.md ★ CLAVE docs ARCHITECTURE.md DATABASE.md MODULES.md PROMPT-ARTICULOS.md UI_DESIGN.md UPDATES.md · UPDATES-ads.md rules SETTINGS.md · SKILL.md · SPEC.md WORKFLOW-AGENTS.jpg JPEG 18 elementos · Documentación completa antes de ejecutar ESTRUCTURA REAL 11 docs · ~20K tokens de contexto inicial
02
Fase 2 Prompt inicial · activación de agentes

Cada sesión arranca con un prompt estructurado que carga el contexto correcto. Los 3 agentes se activan con sus roles, restricciones y outputs esperados. Una sesión = una tarea concreta. Sin mezclar.

AGENT_AUDITOR.md AGENT_DEVELOPER.md AGENT_QA_TESTER.md Prompt inicial estandarizado Carga de docs relevantes por tarea
03
Fase 3 Ejecución con control de calidad

El Auditor valida antes de que el Developer ejecute. Cada output pasa por un checklist de seguridad, consistencia de DB y lógica de IA. Los errores se detectan en fase de revisión, no en producción.

Revisión DB · FK, índices, tipos Revisión SEC · XSS, SQLi, sanitización Revisión IA · failover, costes Informe de BLOQUEOS y DISCREPANCIAS
04
Fase 4 Iteración y economía de recursos

Prueba antes de continuar. Si hay un bug en el Router y construyes 10 archivos encima sin saberlo, lo tienes que rehacer todo. El TIMING.md dicta cuándo cerrar sesión, cuándo abrir una nueva y con qué contexto.

Test en navegador tras cada bloque Sesión nueva = contexto fresco Archivos completos, no fragmentos Estimación real de tokens por tarea
03

Cada proyecto sigue este ciclo iterativo — las sesiones se abren y cierran por tarea concreta. El contexto se carga, se consume y se renueva: nunca se mezcla ni se contamina entre fases.

FASE 01 DOCUMENTACIÓN Schema · Specs Convenciones FASE 02 ACTIVAR SESIÓN Prompt estructurado Contexto mínimo FASES 03 · 04 01 AUDITOR Valida antes del build 02 DEVELOPER Ejecuta tras validación 03 QA TESTER Verifica el output OUTPUT PRODUCCIÓN Deploy · Revisión ✓ Test pasado NUEVA SESIÓN LEYENDA Flujo principal Iteración · nueva sesión si hay contaminación de contexto
04

Tres perfiles de contexto especializados que se activan por separado en cada sesión. Cada rol tiene su prompt, sus restricciones y su output esperado. No se mezclan.

Rol 01
Auditor
  • Valida DB antes del build
  • Detecta bloqueos críticos
  • Revisa seguridad y consistencia
  • Da el visto bueno por fase
Rol 02
Developer
  • Genera archivos completos
  • Stack adaptado al proyecto
  • Respeta convenciones del proyecto
  • Solo ejecuta tras validación
Rol 03
QA Tester
  • Verifica output generado
  • Detecta regresiones
  • Confirma antes de siguiente fase
  • Cierra el ciclo de calidad
05
★ Proyecto más grande
Proyecto completo
~1.3M
tokens estimados · ~80–120h de trabajo real
Por sesión (operativo)
50K
límite de trabajo elegido · ventana técnica real del modelo: 200K
Contexto inicial
~20K
tokens · 11 documentos de referencia
Modelos en pipeline
Claude
+ Gemini
+ Groq
Claude codifica · Gemini contexto largo · Groq solapamiento rápido
Regla práctica: Una sesión de Claude Code = una tarea concreta. No mezclar. Si la IA se confunde, cerrar y abrir sesión nueva — el contexto está contaminado.
📦 Ejemplo real — Core del CMS · Fase 1 TOTAL FASE 1 ~215K tokens · 14–18 horas TAREA ARCHIVOS TOKENS TIEMPO EST. SESIÓN 1 S1 Prompt inicial + carga de contexto 11 docs ~20K 30–45 min Auditoría rápida (Fase 2 prompt) ~5K 20–30 min Estructura de carpetas + .gitignore ~15 archivos ~8K 25–35 min Sesión 1 · ~33K tokens · 75–110 min SESIÓN 2 S2 install.sql (todas las tablas ma_*) 1 archivo denso ~12K 60–90 min setup/install.php (wizard 7 pasos) 1 archivo grande ~10K 75–90 min Bootstrap.php + Config.php 2 archivos ~6K 45–60 min Database.php (PDO singleton) 1 archivo ~5K 30–40 min Sesión 2 · ~33K tokens · 210–280 min SESIÓN 3 S3 Router.php 1 archivo ~6K 50–70 min Request.php + Response.php 2 archivos ~6K 45–60 min Session.php + Csrf.php 2 archivos ~5K 40–50 min Sanitizer.php + HtmlSanitizer.php 2 archivos ~6K 35–45 min Sesión 3 · ~23K tokens · 170–225 min SESIÓN 4 S4 Cache.php + Logger.php 2 archivos ~7K 40–55 min Auth.php + public/index.php + Login/Logout 7 archivos ~19K 90–120 min Layout CMS + Dashboard básico 7 archivos ~20K 90–120 min Sesión 4 · ~46K tokens · 220–295 min TOTAL FASE 1 ~215K tokens 14–18 horas 💡 ~135K tokens output + ~80K contexto = ~215K tokens. Tiempo incluye iteraciones, tests y correcciones reales. Incluido en Claude Pro. ▬ escala tokens relativa
06
01
Documenta antes de ejecutar
El código que escribe la IA es tan bueno como el contexto que le das. Si no existe un documento que lo especifique, no se implementa.
02
Una sesión, una tarea
El contexto de la IA se degrada con el tiempo. Cada sesión arranca con el contexto mínimo necesario para esa tarea concreta.
03
Los errores cuestan más tarde
Detectar un bug en Router.php antes de construir 10 archivos encima ahorra horas. El Auditor existe para eso.
04
Los prompts son código
Los prompts del sistema están versionados y documentados como cualquier artefacto de software: con historial de cambios, descripción del motivo y posibilidad de revertir. La IA propone, el criterio humano decide qué se consolida.
05
Cada modelo en su capa
Gemini para contexto largo y documentación. Claude para codificar con precisión. Groq para solapamiento rápido entre sesiones. El pipeline decide — no el hábito.
06
Validación humana siempre
El generador nunca publica sin confirmación humana. La IA propone, el editor decide. La automatización no sustituye el criterio.
07

Producto real, construido con esta metodología. Arquitectura documentada, roles IA definidos, economía de tokens controlada desde el día uno.