Cualquier modelo de lenguaje puede escribir código genérico, pero casi todos naufragan cuando intentan asesorar en arquitectura de software: inventan conceptos que suenan convincentes, recomiendan «menús de opciones» tibios donde todo vale y mezclan definiciones formales con opiniones vagas. Dexter es la respuesta a ese vicio: un agente experto con grounding canónico obligatorio, protocolo dual de consulta y una separación quirúrgica entre la evidencia del sistema y el juicio ingenieril.
El dilema del agente suelto: por qué los LLMs no sirven como consultores de sistemas sin un arnés
Cuando conectas un modelo de lenguaje comercial a un chat corporativo y le preguntas «¿cómo deberíamos estructurar nuestro monorepo?», el modelo recurre a su memoria paramétrica promedio. El resultado es casi siempre el mismo:
- Una lista de cinco alternativas posibles sin comprometerse con ninguna.
- Afirmaciones técnicas sin fuente verificable dentro de la base de código.
- Términos inventados sobre la marcha que contaminan el vocabulario del equipo.
En Spec-Driven Development no hay espacio para la vaguedad. Si el contexto del sistema es la fuente canónica de verdad (el blueprint que manda sobre el código), el agente que lo representa no puede ser un opinador libre. Debe ser un operador ontológico estricto.
Dexter se diseñó para resolver esto encarnando dos oficios muy concretos, de los cuales solo uno puede estar activo a la vez:
- Developer experto en construir con agentes de IA: comprende cómo se descompone, especifica y verifica un desarrollo mediante contratos, criterios de aceptación auditables y análisis de diffs.
- Consultor de implementación de IA en equipos de producto: diagnostica madurez, evalúa la tolerancia al riesgo del equipo y determina qué hacer primero y —crucialmente— qué NO hacer todavía.
Protocolo de Lookup en Cascada (Grounded Tools)
DEXTER nunca responde desde memoria paramétrica libre. Toda afirmación proviene de herramientas ordenadas por rigor semántico.
query_glosario()¿Existe el término formal? Su definición es la verdad base.
get_termino()Hiperónimos, hipónimos y términos estrechamente relacionados.
query_graph()Navega relaciones transversales en graphify-out/ si no hay match directo.
get_node()Lee las 5 capas de especificación de Context/*.md.
search_content()Ejemplos prácticos en blog, reviews y casos de estudio.
1. Grounding en Grafo y Glosario: «Sin fuente no hay afirmación»
La primera regla de oro en las instrucciones de sistema de Dexter es tajante: nunca responde de memoria sobre el sistema; consulta primero sus herramientas y cita la fuente en cada afirmación. Si la base de conocimiento no cubre el tema, Dexter no rellena la laguna con conjeturas: admite abiertamente que no está en su base y sugiere la sección más cercana mediante el grafo.
Para lograr esto sin incurrir en latencias exorbitantes ni saturar el contexto, Dexter opera con un protocolo de lookup en cascada a través de seis herramientas especializadas:
query_glosario: Busca en el archivo canónicoglosario.json. Si el término existe formalmente, su definición textual es el ancla inmutable.get_termino: Extrae la taxonomía formal del concepto (sus hiperónimos, hipónimos y términos relacionados).query_graph: Si no hay coincidencia directa en el glosario, recorre el grafo unificado de relaciones (graphify-out/) buscando comunidades y vecinos semánticos.get_node: Lee los contratos arquitectónicos de 5 capas enContext/*.md(identidad, estructura, reglas, verificación e implementación).search_content: Recupera artículos del blog, lecciones aprendidas y casos de estudio reales.list_secciones: Proporciona orientación macro sobre el mapa del sitio.
«Un agente de arquitectura sin grounding es un generador aleatorio de deuda técnica. Un agente con grounding canónico es un auditor incorruptible.»
2. El Flujo del Prompt: Protocolo Lookup vs. Protocolo Consultoría
Uno de los errores más comunes en ingeniería de prompts es pretender que una sola plantilla atienda tanto una consulta enciclopédica como un dilema estratégico. Dexter bifurca el flujo inmediatamente al clasificar la intención del usuario.
Modo A: Protocolo Lookup (Definición Canónica)
Se activa ante preguntas del tipo «¿Qué es un blueprint?», «Define Context Driven Development» o «¿En qué se diferencia una spec de un issue?».
- Comportamiento: Respuesta directa de una a tres frases concisas.
- Enlace estricto: Cita únicamente rutas internas auditadas (
/wiki/<slug>). - Restricción: Prohibido agregar reflexiones subjetivas o interpretaciones personales.
Modo B: Protocolo Consultoría (Decisión Estratégica)
Se activa ante interrogantes complejas como «¿Cómo implemento esto en un equipo de 4 personas?», «¿Por dónde empiezo si mi base de código no tiene tests?» o «¿Es buena idea usar un agente autónomo para refactorizar el backend?».
Aquí Dexter sigue un algoritmo mental de seis pasos inquebrantables:
Las 6 Reglas Inquebrantables de Dexter
Filtro determinista para resolver dudas complejas sin ambigüedades ni respuestas infladas.
Fundamentar en la base previa
Inspecciona el Contexto y las herramientas antes de emitir cualquier sugerencia.
Prohibido especular en el vacío. Si la respuesta está en un nodo de Context/, se cita directamente.
[Tool call: context_lookup("02-Sistema/Arquitectura.es.md")]
→ Nodo cargado: 12 rutas-código, 5 capas de gobernanza verificadas.El punto 4 y el punto 5 son los más transformadores:
- Separación de evidencia vs. juicio: Dexter redacta con marcas claras: «Según la especificación del Contrato en Context Driven Development, cada nodo requiere cinco capas. A criterio de consultoría para tu stack actual, te sugiero omitir la capa de simulación temporal hasta contar con 50 nodos activos.» El usuario siempre sabe qué es dogma del sistema y qué es consejo contextual.
- Criterio «Done when:»: Ninguna recomendación queda flotando en el aire. Si Dexter aconseja crear una spec inicial, remata con: «Done when: el script de validación termine en código de salida 0 sin advertencias de huérfanos.»
3. División del Trabajo: La Máquina Determinista vs. El Agente Semántico
El mayor desperdicio de cómputo en sistemas agénticos modernos consiste en pedirle a un LLM que cuente enlaces, verifique si un archivo existe en el disco o calcule rutas relativas de TypeScript. Los modelos de lenguaje son pésimas calculadoras de strings y propensos a alucinaciones de conteo.
En el ecosistema de Dexter, la máquina hace lo verificable y el agente emite el juicio semántico. Esta tríada se articula en tres herramientas de línea de comandos:
A) audit.ts (pnpm audit:node <nodo>)
Este script escanea los archivos markdown del Context contra el repositorio físico:
- Comprueba que cada ruta de archivo declarada en la sección
rutas-codigoexista físicamente. - Verifica si los componentes
ds:*del Design System están registrados. - Inspecciona si los comandos de terminal citados son válidos.
- El dossier: La máquina genera un informe compacto de hechos duros. Luego, Dexter lee ese dossier y determina el veredicto:
code-complies(el código cumple la spec),code-diverges(el código derivó y contradice la spec) ocriterion-ambiguous(el criterio de aceptación no es medible).
B) interlink.ts (pnpm interlink)
Para mantener el blog y la wiki interconectados sin trabajo manual agotador, interlink.ts realiza un barrido por Abstract Syntax Tree (AST) sobre los artículos en Markdown/MDX:
- Identifica la primera mención de cada término canónico del glosario que aún no esté enlazada.
- Respeta guardas estrictas: no toca títulos (
#,##), no altera bloques de código (pre,code), no interrumpe componentes JSX ni reemplaza texto dentro de enlaces existentes. - El agente revisa las sugerencias para descartar falsos positivos semánticos (por ejemplo, evitar que la palabra común «plano» se enlace erróneamente al término técnico «blueprint»).
C) radar.ts (pnpm radar)
Un radar pasivo de salud ontológica que audita tres métricas vitales:
- Huérfanos de taxonomía: Términos de la base de conocimiento que no tienen hiperónimos, hipónimos ni conceptos relacionados (islas de información).
- Menciones sin enlace en el blog: Detección de conceptos clave que se mencionan en la narrativa pero no ofrecen al lector una vía de profundización hacia la Wiki.
- Distribución comunitaria: Agrupación y densidad de relaciones entre dominios del conocimiento.
Conclusión: Los Agentes no Reemplazan la Ingeniería, la Exigen
La lección detrás de Dexter es que un modelo fundacional de IA no se convierte en «experto» mediante adjetivos pomposos en su prompt («eres el mejor arquitecto del mundo»). Se convierte en experto cuando se le impone una disciplina de sistemas:
- Memoria arraigada en un grafo canónico verificable.
- Protocolos de respuesta bifurcados según la naturaleza de la consulta.
- Fronteras estrictas entre datos empíricos y criterio profesional.
- Scripts deterministas que descargan al modelo de tareas mecánicas.
Ese es el verdadero poder de combinar agentes de IA con Spec-Driven Development: convertir la documentación viva en un interlocutor activo, veraz y auditable.
