Forma de Trabajo

Desarrollo Orquestado con Agentes IA

Cómo trabajo: un ecosistema de agentes especializados sobre OpenCode que analiza, implementa y revisa bajo reglas duras — conmigo decidiendo en cada gate. Esta página documenta la arquitectura, el ciclo y los casos reales que la respaldan.

Ver la forma de trabajar
Diagrama de orquestación multi-agente en OpenCode: dos orquestadores arriba (Plan y Build), seis especialistas por dominio al centro, y tres capas de soporte abajo: especificaciones canónicas, corpus técnico curado de 169 fuentes y 16 servidores MCP
El Problema

Un Desarrollador, Todos los Dominios, Contexto Limitado

Un desarrollador que trabaja solo cubre análisis, arquitectura, backend, frontend, datos y despliegue. El cuello de botella rara vez es escribir código: es sostener el mapa mental completo del proyecto — decisiones sin registro, documentación dispersa, y contexto que se pierde entre sesiones y archivos.

Los asistentes de IA sueltos ayudan en fragmentos, pero sin anclas derivan: repiten lecturas, olvidan decisiones y nadie audita su salida. Lo que necesitaba no era un chat más inteligente, sino un sistema de trabajo donde el conocimiento tenga estructura y cada cambio pase por verificación.

Sin orquestación

  • El contexto se pierde entre sesiones y archivos
  • Las decisiones viven en la cabeza, no en documentos
  • La revisión propia hereda el sesgo propio
  • Consultar a memoria, sin fuente versionada
  • Tareas grandes sin gates: los errores llegan tarde
La Arquitectura

Cuatro Piezas que se Verifican entre Sí

Orquestadores y especialistas

Dos orquestadores — Plan para análisis, Build para implementación — delegan a especialistas por dominio: arquitecto, backend, frontend, base de datos, DevOps/git, diseño, revisor de calidad, exploración de código e investigación web.

Skills y corpus curado

Más de 260 skills en una matriz de enrutamiento por tipo de tarea y por agente. El conocimiento se incorpora con un pipeline de 7 pasos y queda consultable en un corpus técnico curado, local y versionado.

Spec-driven

Todo proyecto arranca como spec: propuesta, diseño técnico, tareas con gates, delta specs, implementación y archivo. Las docs canónicas — PRD, arquitectura, runbooks, ADRs — son la fuente de verdad que los agentes leen.

16 servidores MCP

Los agentes se conectan al mundo por protocolo MCP: razonamiento secuencial, documentación de librerías versionada, búsqueda web, visión IA y automatización de navegador para pruebas E2E.

Reglas duras, no promesas

  • Profundidad máxima de delegación: 3 niveles
  • Máximo 5 subagentes concurrentes y límite por tarea
  • Gates de verificación por fase antes de avanzar
  • Agente revisor obligatorio antes de cerrar implementación
  • Sesiones ancladas anti-drift: anchor de proyecto, checkpoints y no releer lo ya en contexto

Los límites están en la configuración del sistema, no en la buena voluntad del modelo.

Corpus técnico curado

  • 169 fuentes curadas e incorporadas por pipeline
  • 136.000+ fragmentos indexados para consulta en análisis y revisión
  • FTS5 / BM25 búsqueda local sobre SQLite — sin dependencia de nube
  • 260+ skills enrutadas por tipo de tarea y por agente

Pipeline de incorporación en 7 pasos: fuente, extracción, creación, clasificación, asignación, registro y validación.

La spec como vehículo

  • propuesta
  • diseño técnico
  • tareas con gates
  • delta specs
  • implementación
  • archivo

Cada cambio relevante nace y muere documentado: PRD, arquitectura, runbooks y ADRs que los agentes leen como fuente de verdad — no como decoración.

Ciclo de Trabajo

Cómo se Ve un Ciclo Completo

  1. Spec

    El proyecto arranca como especificación: propuesta y alcance antes que código.

  2. Descomposición por dominios

    El orquestador parte el spec por dominios: datos, backend, frontend, despliegue.

  3. Delegación a especialistas

    Cada dominio va a su agente especialista, con contexto acotado y límites duros.

  4. Gates por fase

    Nada avanza sin verificación: build, tests, revisión de documentos.

  5. Revisor independiente

    Un agente revisor, ajeno a la implementación, audita calidad antes de cerrar.

  6. Merge y documentación

    El cambio se integra y las docs canónicas se actualizan en el mismo ciclo.

  7. Archivo del spec

    La spec cumplida se archiva; el siguiente delta parte de ahí, no de memoria.

Casos Reales

La Arquitectura Bajo Carga

Migración de capa de datos

Veritec — de hojas de cálculo a PostgreSQL

Sistema productivo B2B con lecturas de 3 a 8 segundos. El agente arquitecto trabajó contra las docs canónicas del proyecto: un análisis de 407 secciones con estado as-is/to-be, dolores D1–D6 con evidencia de código y decisiones del owner D1–D4. La solución — réplica PostgreSQL con sync horario idempotente y feature flag de cutover — se diseñó, implementó y verificó dentro del ciclo orquestado.

  • <20 ms lecturas (antes 3–8 s)
  • 407 secciones de análisis canónico
  • OWASP A01 hallazgo cerrado en la migración
  • 100% sync idempotente + feature flag
El agente diseñó contra las docs; el owner aprobó cada decisión. Así funciona el gate humano.
Ver el caso completo
Análisis documental

Laboratorio de trazas de auditoría

Para diagnosticar procesos de análisis documental construí un laboratorio sobre trazas JSON de auditoría de procesos reales — datos anonimizados. La herramienta parsea las trazas, calcula métricas de duración y detecta outliers, y filtra expedientes documentales por etapa. Está incluida en este portfolio y nació del mismo ciclo: spec, gates, revisión y archivo.

  • JSON parseo de trazas de auditoría
  • P90 / P95 percentiles y detección de outliers
  • 100% datos de procesos reales, anonimizados
  • 0 datos sensibles expuestos
El método también produce herramientas propias: este laboratorio vive en el portfolio.
Ver la herramienta

Caso fullstack documentado de punta a punta

Una plataforma completa construida con este ciclo acumula 6 releases (v0.1 a v0.6), 500+ tests automatizados, RBAC con separación de funciones y generación de documentos legales en PDF — cada fase cerrada tras gates verificables antes de avanzar a la siguiente.

Límites Honestos

Lo que este Método NO Hace

  • El humano decide los gates críticos. Los agentes proponen; las decisiones de negocio, riesgo y corte las aprueba una persona.
  • El revisor agente no reemplaza el criterio. Detecta patrones y regresiones, pero la última palabra técnica sigue siendo responsabilidad del desarrollador.
  • El corpus curado no sustituye la documentación oficial. Acelera consultas internas; la fuente de verdad sigue siendo la documentación oficial versionada.

¿Trabajamos con este método en tu proyecto?

Llevo este flujo orquestado a proyectos reales: specs verificables, gates explícitos y revisión independiente en cada entrega.

Hablemos Ver Otros Proyectos