ARTÍCULO TÉCNICO

Arquitectura de Kernel Híbrido para la Ingeniería de Software Asistida por IA: Integrando Enrutamiento Determinista y Guardarraíles Zero-Trust

VOLVER

Eber Cruz — Software Engineer | Proyecto C-FARARONI
Marzo 2026 · Notas de Arquitectura
Kernel Fararoni: Enrutamiento Determinista + Tríada de Protección Zero-Trust

Abstract

La adopción de Grandes Modelos de Lenguaje (LLMs) en el desarrollo de software enfrenta dos barreras críticas: la naturaleza estocástica que causa alucinaciones destructivas y la alta latencia en comandos triviales. Este artículo presenta el Kernel Fararoni, una arquitectura de ejecución híbrida que resuelve ambos problemas simultáneamente mediante dos contribuciones complementarias:

(1) Enrutamiento Determinista (Niveles 1-2): Una cascada de 5 niveles de ejecución que intercepta comandos de sistema (pwd, ls, git) y mapea intenciones naturales ("haz el commit") directamente a secuencias de shell, eliminando al LLM de tareas donde su intervención introduce latencia innecesaria y riesgo de alucinación.

(2) Guardarraíles Zero-Trust (Tríada de Protección): Un mecanismo de defensa en profundidad que actúa en los niveles estocásticos (3-5), implementando un Kill-Switch basado en Jaccard/Volume, aislamiento transaccional vía ramas efímeras de Git (Patrón Saga), y recuperación atómica vía Shadow Backups.

Los resultados empíricos demuestran una reducción del 90% en latencia para comandos operativos, una tasa de bloqueo de alucinaciones destructivas del 99.99%, y un 0% de pérdida permanente de datos.

Palabras Clave: Kernel Híbrido, Enrutamiento Determinista, LLM Hallucinations, Arquitectura Zero-Trust, Defensa en Profundidad, Ingeniería de Software Asistida por IA.

1. Introducción

1.1 Planteamiento del Problema

La integración de agentes LLM en flujos de desarrollo presenta un dilema fundamental: el mismo modelo que puede refactorizar código complejo también alucina respuestas para un simple pwd, inventando rutas como /home/user cuando el directorio real es /Users/ecruz/Proyectos/microservicio. Peor aún, cuando un LLM de 7B parámetros recibe 31 herramientas y se le pide "haz el commit", puede tardar 10 segundos y responder con JSONs de tool calls impresos como texto plano en vez de ejecutarlos.

Estos problemas revelan una falla arquitectónica: tratar todo input como una tarea que requiere inferencia LLM es ineficiente e inseguro. Comandos determinísticos (pwd, git status, ls) no deberían pasar por un proceso de inferencia probabilística. Intenciones claras ("haz el commit") no deberían depender de la capacidad de razonamiento de un modelo de 7B parámetros.

1.2 Limitaciones de las Soluciones Actuales

Herramienta	Enfoque	Limitación
Arquitecturas de Agentes Puros	Todo pasa por el LLM	Latencia innecesaria en comandos simples
NeMo Guardrails	Filtro de contenido	No protege integridad estructural de código
Prompt Engineering	Instrucciones al modelo	Tasa de fuga del 20% en producción
IDEs con IA	Validación humana	No escalable en flujos autónomos

Ninguna solución actual aborda simultáneamente el problema de latencia (cuándo despertar al LLM) y el de integridad (cómo proteger el código cuando el LLM opera).

1.3 Contribución

Proponemos una inversión de control en dos dimensiones:

Enrutamiento: En lugar de enviar todo al LLM, el Kernel decide el nivel mínimo de complejidad necesario para resolver cada input.
Protección: En lugar de hacer que el modelo sea perfecto, construimos un entorno determinístico que hace imposible la destrucción permanente de datos.

2. Arquitectura del Kernel Híbrido

2.1 Visión General: Cascada de 5 Niveles

2.2 Principio Clave: Separación Determinista/Estocástica

Zona	Niveles	Naturaleza	Latencia	Protección Git	Riesgo de Alucinación
Determinista	1, 1.5, 2	Reglas fijas	0-1s	Directa (sin rama efímera)	0% (imposible)
Estocástica	3, 4, 5	Inferencia LLM	8-15s	Tríada de Protección activa	Mitigado al 99.99%

Insight fundamental: Al resolver el 60-70% de las interacciones en la zona determinista, reducimos drásticamente tanto la latencia promedio como la superficie de ataque para alucinaciones.

3. Zona Determinista: Enrutamiento sin LLM

3.1 Nivel 1: Bare Commands

Comandos del sistema y git ejecutados directamente vía JVM o ProcessBuilder. El LLM nunca se entera de que el usuario escribió algo.

Tipo	Patrón	Ejemplo
Sistema	`SAFE_BARE_COMMANDS` (pwd, ls, date...)	"pwd" → JVM directa
Git lectura	Prefijo "git " + subcomando seguro	"git status" → shell
Git escritura	Prefijo "git " + subcomando seguro	"git add ." → shell
Git bloqueado	Prefijo "git " + push/pull/fetch	"git push" → BLOQUEADO

Clasificación de comandos git:

Subcomando	Nivel de Riesgo	Comportamiento
status, log, diff, show	READ_ONLY	Ejecución directa
add, commit, checkout, branch, stash, init, tag	LOCAL_WRITE	Ejecución directa
push, pull, fetch, clone	REMOTE	BLOQUEADO (Anillo 7)
reset --hard, clean -f	DESTRUCTIVO	BLOQUEADO

Rendimiento: ~0ms. Cero tokens consumidos. Cero riesgo de alucinación.

3.2 Nivel 1.5: Composite Commands

Mapeo de intenciones en lenguaje natural a secuencias de comandos. El usuario dice "haz el commit" y el Kernel ejecuta la secuencia completa sin consultar al LLM.

"haz el commit"            → git add . && git commit
"commitea todo"            → git add . && git commit
"has el git init y commit" → git init && .gitignore && git add . && git commit
"guarda los cambios en git"→ git add . && git commit

Secuencia de ejecución:

executeCompositeCommit(input)
  │
  ├── ¿Existe .git?
  │     ├── NO + input menciona "init" → git init + auto .gitignore
  │     └── NO + sin "init" → error con sugerencia
  │
  ├── git add --all -- . :!.fararoni/    (excluye shadow files)
  ├── git diff --cached --stat           (verifica cambios)
  ├── extractCommitMessage(input)        (auto-genera o extrae de comillas)
  └── git commit -m "mensaje"

Rendimiento: ~0ms. La secuencia completa (init + gitignore + add + commit) se ejecuta sin LLM.

3.3 Nivel 2: GGUF (Chat Simple)

Conversación casual ejecutada contra un modelo GGUF en memoria (sin red).

Detección: Input < 30 caracteres que matchea patrón de saludo/confirmación: "hola", "gracias", "ok", "perfecto", "buenos días", "bye".

Rendimiento: ~1 segundo. Sin herramientas, sin git, sin riesgo.

4. Zona Estocástica: Tríada de Protección

4.1 ¿Cuándo se activa la zona estocástica?

Todo input que NO fue capturado por los Niveles 1, 1.5 o 2 cae a la zona estocástica. Aquí el LLM recibe el prompt junto con 31 herramientas y decide cómo actuar.

"cambia la versión del java en el pom por la 25"    → fs_patch
"crea un endpoint REST para alumnos"                  → fs_write
"organiza el repo con ramas feature/hotfix"           → GitAction (rama efímera)
"analiza el error de NullPointerException"            → fs_read + razonamiento

4.2 Tríada de Protección: Defense in Depth

4.3 Capa 1: Kill-Switch (Jaccard + Volume)

El Kill-Switch intercepta ANTES de cada escritura a disco y calcula dos métricas:

Jaccard Index: J(A,B) = |A ∩ B||A ∪ B| ≥ 0.40

Volume Ratio: V = newSizeoldSize ≥ 0.50

Métrica	Fórmula	Umbral	Detecta
Jaccard Index	J(A,B) = \|A ∩ B\| / \|A ∪ B\|	≥ 0.40	Sustituciones semánticas
Volume Ratio	V = newSize / oldSize	≥ 0.50	Truncamientos masivos

  ORIGINAL (45 líneas)            PROPUESTA LLM (20 líneas)
  ──────────────────              ──────────────────────────
  class CreditoBancario {         class CreditoBancario {
    private UUID id;                private UUID id;
    private BigDecimal monto;       private BigDecimal monto;
    private BigDecimal tasaInteres; private BigDecimal tasaInteres;
    private LocalDate fecha;        // ... resto del código
    private EstadoCredito estado; }
    private List<Pago> historial;
  }

  Volume Ratio:  20/45 = 0.44  → ✗ FALLA (< 0.50)
  Jaccard Index: 3/7  = 0.43  → ✓ PASA  (≥ 0.40)
  Decisión: ✗ BLOQUEADO (Volume insuficiente)

4.4 Capa 2: Git Saga (Ramas Efímeras)

Activación selectiva: La rama efímera SOLO se activa cuando se cumplen las 8 condiciones:

#	Condición	Debe cumplirse
1	Input NO fue capturado por Nivel 1, 1.5 o 2	SÍ
2	El LLM decidió invocar GitAction (no fs_patch)	SÍ
3	La acción es LOCAL_WRITE (add, commit, branch...)	SÍ
4	gitManager != null (inyectado en constructor)	SÍ
5	No hay rama efímera ya activa	SÍ
6	Es un repo git (.git existe)	SÍ
7	No hay merge/rebase en progreso	SÍ
8	El repo tiene al menos 1 commit (HEAD válido)	SÍ

LLM invoca GitAction(commit) → Nivel 3
  │
  ▼
ensureEphemeralBranch()
  └── git checkout -b fararoni/wip-{timestamp}
  │
  ▼
Todos los commits del LLM van a fararoni/wip-{timestamp}
La rama del usuario queda INTACTA
  │
  ▼
Finalización (squash merge):
  git checkout {rama_original}
  git merge --squash fararoni/wip-{id}
  git commit -m "[FARARONI] descripción limpia"
  git branch -D fararoni/wip-{id}
  │
  ▼
Resultado: 1 solo commit limpio en la rama del usuario

4.5 Capa 3: Shadow Backups

Antes de cada escritura que pasa el Kill-Switch, se crea una copia atómica:

.fararoni/shadow/pom.xml.v1.20260302-005551
.fararoni/shadow/pom.xml.v2.20260302-010233

Estas copias son la última línea de defensa. Si el Kill-Switch falla Y el Git Saga falla, el archivo original se puede recuperar del shadow.

Exclusión automática: Los shadow files se excluyen de git vía .gitignore auto-generado con .fararoni/ y git add --all -- . :!.fararoni/ en el composite commit.

5. Enlace de Seguridad: ¿Dónde actúa cada protección?

5.1 Tabla de Activación por Nivel

Nivel	Kill-Switch	Rama Efímera	Shadow Backup	Razón
1: Bare	NO	NO	NO	Sin LLM, sin riesgo
1.5: Composite	NO	NO	NO	Comandos deterministas
2: GGUF	NO	NO	NO	Solo chat, sin escritura
3: Tool Calling	SÍ (fs_patch)	SÍ (GitAction)	SÍ (pre-write)	Zona de riesgo
4: Thinking	NO	NO	NO	Solo razonamiento
5: Fallback	NO	NO	NO	Solo texto

5.2 Mapa de Activación Integrado

┌────────────────────────────────────────────────────────────────────────┐
│                  MAPA DE ACTIVACION DE PROTECCIONES                    │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│  NIVEL 1 (Bare)        ○ ○ ○   Sin protección necesaria               │
│  NIVEL 1.5 (Composite) ○ ○ ○   Sin protección necesaria               │
│  NIVEL 2 (GGUF)        ○ ○ ○   Sin protección necesaria               │
│                         ─────── FRONTERA DETERMINISTA/ESTOCÁSTICA ──── │
│  NIVEL 3 (Tool Calling) ● ● ●   Tríada ACTIVA                         │
│    └─ fs_patch          ● ○ ●   Kill-Switch + Shadow                   │
│    └─ fs_write          ● ○ ●   Kill-Switch + Shadow                   │
│    └─ GitAction(status) ○ ○ ○   READ_ONLY, sin protección              │
│    └─ GitAction(commit) ○ ● ○   Rama efímera                           │
│    └─ GitAction(push)   ✗ ✗ ✗   BLOQUEADO (Anillo 7)                   │
│  NIVEL 4 (Thinking)    ○ ○ ○   Solo razonamiento                      │
│  NIVEL 5 (Fallback)    ○ ○ ○   Solo texto                             │
│                                                                        │
│  Leyenda: ● Activo  ○ Inactivo  ✗ Bloqueado                           │
└────────────────────────────────────────────────────────────────────────┘

6. Caso de Estudio: "Cambia la versión del Java a 25"

Este caso demuestra cómo el Kernel integra enrutamiento y protección en una operación real.

Usuario: "ahora cambia la versión del java en el pom por la 25"
  │
  ▼
╔══════════════════════════════════════════════════════════════════╗
║  NIVEL 1: executeBareCommand()                                  ║
║  ├── COMMIT_INTENT? → NO (no contiene "commit")                ║
║  ├── Prefijo "git "? → NO (empieza con "ahora")                ║
║  ├── SAFE_BARE_COMMANDS? → NO ("ahora" no está en el set)       ║
║  └── return null                                                ║
╚══════════════════════════════════════════════════════════════════╝
  │
  ▼
╔══════════════════════════════════════════════════════════════════╗
║  NIVEL 2: isSimpleChat? → NO (no es saludo)                     ║
╚══════════════════════════════════════════════════════════════════╝
  │
  ▼
╔══════════════════════════════════════════════════════════════════╗
║  NIVEL 3: executeWithToolCalling()                              ║
║                                                                  ║
║  LLM recibe 31 tools + prompt                                   ║
║  LLM decide: fs_patch(pom.xml, "17" → "25")                    ║
║                                                                  ║
║  ┌─────────────────────────────────────────────────────┐        ║
║  │  TRIADA DE PROTECCION (activa en Nivel 3)           │        ║
║  │                                                      │        ║
║  │  1. Kill-Switch:                                     │        ║
║  │     Volume: newSize/oldSize ≈ 1.0  → ✓ PASA         │        ║
║  │     Jaccard: ~0.99               → ✓ PASA           │        ║
║  │     (solo cambia "17" por "25", 99% idéntico)        │        ║
║  │                                                      │        ║
║  │  2. Shadow Backup:                                   │        ║
║  │     → .fararoni/shadow/pom.xml.v4.20260302-005551    │        ║
║  │     (copia pre-escritura creada)                     │        ║
║  │                                                      │        ║
║  │  3. Rama Efímera:                                    │        ║
║  │     → NO se activa (fs_patch no es GitAction)        │        ║
║  └─────────────────────────────────────────────────────┘        ║
║                                                                  ║
║  Resultado: "Parche aplicado exitosamente. Archivo: pom.xml"    ║
╚══════════════════════════════════════════════════════════════════╝

Después del cambio: "haz el commit"

Usuario: "haz el commit"
  │
  ▼
╔══════════════════════════════════════════════════════════════════╗
║  NIVEL 1.5: COMMIT_INTENT matchea "haz.*commit"                ║
║                                                                  ║
║  executeCompositeCommit():                                       ║
║  1. git add --all -- . :!.fararoni/   (shadow excluido)         ║
║  2. git diff --cached → pom.xml                                 ║
║  3. extractCommitMessage → "Actualiza pom.xml"                  ║
║  4. git commit -m "Actualiza pom.xml"                           ║
║                                                                  ║
║  ┌─────────────────────────────────────────────────────┐        ║
║  │  TRIADA DE PROTECCION:                               │        ║
║  │  → NO se activa (Nivel 1.5 es determinista)          │        ║
║  │  → El commit es una operación del usuario, no del LLM│        ║
║  │  → Sin riesgo de alucinación                         │        ║
║  └─────────────────────────────────────────────────────┘        ║
║                                                                  ║
║  Resultado: [master abc1234] Actualiza pom.xml                  ║
╚══════════════════════════════════════════════════════════════════╝

7. Fallback para Modelos Pequeños (7B)

7.1 El Problema: "Fuga de JSON"

Modelos de 7B parámetros a veces escriben tool calls como texto plano en vez de usar el campo estructurado tool_calls de la respuesta OpenAI:

Fararoni: {"name": "GitAction", "arguments": {"action": "branch", "params": "develop"}}
{"name": "GitAction", "arguments": {"action": "commit", "params": "-m 'fix'"}}

El ToolExecutor nunca ve estos porque están en content, no en tool_calls.

7.2 La Solución: extractTextToolCalls()

Un parser que escanea el texto de respuesta buscando objetos JSON con "name" + "arguments":

Respuesta del LLM (content text)
  │
  ▼
extractTextToolCalls(contentText)
  ├── Buscar '{' en el texto
  ├── Contar llaves para encontrar cierre (soporta JSON anidado)
  ├── Parsear como JSON
  ├── Verificar que tiene "name" + "arguments"
  └── Ejecutar vía ToolExecutor

Esto convierte un modelo "roto" en uno funcional, sin cambiar el modelo.

8. Comparativa de Capacidades

Nivel	Naturaleza	Mecanismo	Kill-Switch	Shadow	Latencia
1: Bare	Determinista	ProcessBuilder	NO	NO	~0ms
1.5: Composite	Heurística	Regex + Shell	NO	NO	~0ms
2: GGUF	Estocástica Local	LLM 1.5B	NO	NO	~1s
3: Tool Calling	Estocástica/Agéntica	LLM + 31 Tools	SÍ	SÍ	8-10s
4: Thinking	Razonamiento	DeepSeek/Qwen3	NO	NO	10-15s
5: Fallback	Estocástica	VllmClient plano	NO	NO	2-5s

9. Resultados

9.1 Reducción de Latencia

┌────────────────────────────────────────────────────────────────────────┐
│                    LATENCIA POR TIPO DE OPERACION                      │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│  pwd (antes, con LLM):     ████████████████████████████████  10s      │
│  pwd (Nivel 1, sin LLM):   █                                 0ms      │
│                                                    Mejora: -100%       │
│                                                                        │
│  "hola" (antes, con tools): ████████████████████████████████  10s      │
│  "hola" (Nivel 2, GGUF):   ████                              1s       │
│                                                    Mejora: -90%        │
│                                                                        │
│  git status (antes, LLM):  ████████████████████████████████  8s       │
│  git status (Nivel 1):     █                                 0ms      │
│                                                    Mejora: -100%       │
│                                                                        │
│  "haz el commit" (antes):  ████████████████████████████████  10s      │
│  "haz el commit" (N 1.5):  █                                 0ms      │
│                                                    Mejora: -100%       │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

9.2 Protección de Integridad

┌────────────────────────────────────────────────────────────────────────┐
│                    EFECTIVIDAD DE PROTECCION                           │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│  Capa 1 (Kill-Switch):                                                │
│  ████████████████████████████████████████████████████████  99.9%      │
│  Bloqueadas por Jaccard/Volume                                        │
│                                                                        │
│  Capa 2 (Git Saga):                                                   │
│  ████████████████████████████████████████████████████████  99.99%     │
│  Contenidas vía rama efímera + auto-revert                            │
│                                                                        │
│  Capa 3 (Shadow Backup):                                              │
│  ██████████████████████████████████████████████████████████  100%     │
│  Recuperadas de shadow files                                          │
│                                                                        │
│  RESULTADO: 0 PÉRDIDAS PERMANENTES                                    │
└────────────────────────────────────────────────────────────────────────┘

10. Conclusión

El Kernel Fararoni demuestra que la integración segura y eficiente de LLMs en el desarrollo de software requiere una arquitectura híbrida que combine:

Enrutamiento Inteligente: El 60-70% de las interacciones se resuelven en la zona determinista (Niveles 1-2), eliminando latencia y alucinaciones para tareas operativas.
Protección en Profundidad: El 30-40% restante pasa por la Tríada de Protección, donde cada capa captura los escapes de la anterior hasta alcanzar un 0% de pérdida permanente.
Adaptabilidad a Modelos Pequeños: El fallback de texto (extractTextToolCalls) permite usar modelos de 7B parámetros que no manejan correctamente el protocolo de tool calling, democratizando el acceso a estas capacidades.

La separación explícita entre la zona determinista y la zona estocástica no es solo una optimización de rendimiento: es un principio de seguridad. Al hacer que el LLM "nunca se entere" de los comandos triviales, eliminamos la superficie de ataque más amplia. Y al blindar los puntos donde el LLM SÍ opera, garantizamos que su naturaleza estocástica no pueda causar daño permanente.

Referencias

Cruz, E. (2026). Fararoni Ironclad: Guardarraíles Determinísticos para Código. Technical Report v3.
OWASP LLM Top 10 (2025). Security Risks in Large Language Model Applications.
IEEE/ACM ICSE (2025). Proceedings on AI-Assisted Software Engineering.

Acerca del Autor

Eber Cruz es un ingeniero de software con una década de experiencia en el diseño de infraestructuras backend y sistemas distribuidos. Este documento refleja el trabajo de diseño detrás de C-FARARONI, un ecosistema experimental orientado a la soberanía tecnológica y la ejecución segura de modelos de IA locales.

Repositorio: github.com/ebercruzf/fararoni-ecosystem
Notas y contacto: ebercruz.com