Implementando Compound AI para Optimizar la Efectividad en Testing

¿Quieres que la IA escriba código… o que lo arruine en silencio mientras nadie sabe por qué?

Tiempo estimado de lectura: 8 min

Introducción

Poca gente lo dice claro: no es que los LLMs sean malos. Es que los estamos soltando sin reglas. Y rápido.
Eso se nota cuando el triángulo Spec — Código — Tests se desincroniza a ritmo algorítmico. Y adivina qué aparece primero: deuda técnica.

Claire Le Goues en CMU lo adelantó hace años. No es novedad; es evolución. Reparación automática de programas y análisis de cobertura no son juguetes académicos. Son la columna vertebral de cualquier agente que quiera escribir código que aguante en producción.

Lo que estamos construyendo hoy se llama Compound AI. Y si lo manejas mal, es una mina.

Resumen rápido (lectores con prisa)

Compound AI: orquestación de múltiples modelos, validadores, bases de conocimiento (RAG) y un controlador.
Úsalo cuando necesites código reproducible, verificable y trazable en producción.
Importa porque reduce deuda técnica y fallos en producción al exigir specs operables, tests automatizados y decisiones registradas.
Funciona mediante pipelines: inputs tipados, transformaciones, validación automática y decision logging.

1) Por qué esto ya no es ML-only

Los investigadores pueden inventar algoritmos bonitos. Pero la ingeniería de verdad exige cosas aburridas: orquestación de estado, reintentos inteligentes, persistencia de memoria, latencias aceptables y observabilidad.
Necesitas backends robustos. PaaS. Infra que aguante agentes que lanzan 50 tareas concurrentes y esperan consistencia.

2) DSPy y la estructuración de llamadas

Frameworks como DSPy (o lo que quieras llamar ese nivel de orquestación) transforman llamadas LLM en flujos compilables.
Piensa en DSLs para IA: inputs tipados, outputs comprobables, rutas deterministas. Menos “ensayo y error” y más pipelines reproducibles.

3) Test-Time Inference y RLMs — lo que no es magia

En vez de quemar ciclos entrenando eternamente, gastas cómputo en inferencia inteligente.
Modelos de razonamiento (RLMs) exploran caminos, ejecutan validadores, comparan resultados y devuelven la versión que pasa las pruebas.
Sí: eso cuesta. Sí: merece la pena cuando lo que quieres no es una demo, sino software que no explote a las 2AM.

4) ¿Por qué necesitas ingenieros backend (con experiencia en PaaS)?

Porque la solución no es un notebook de investigación. Es operación:

• Orquestar estado entre modelos.
• Persistir trazas y decisiones.
• Manejar reintentos sin duplicar efectos.
• Escalar validadores y tests en paralelo.
• Aislar fallos y hacer rollback automáticos.

Si tu equipo no tiene esto, el agente será como un aprendiz con acceso root: peligroso.

5) El Triángulo que manda: Spec, Código, Tests

Si uno se desincroniza, todo se va a la mierda. Punto.

• La Spec debe ser operable. Markdown no basta. Necesitas specs con semántica, vinculadas a código y tests.
• El Código debe exponer por qué existe. No solo el “qué”.
• Los Tests no son opcionales. Deben ser ejecutados por el pipeline de agente antes de cualquier merge automático.

Implementación ≠ caja negra. Implementación comunica intención. Y esa intención debe quedar como dato.

6) Trazabilidad: la regla de oro

Cada decisión que toma un agente necesita un artefacto: quién, cuándo, por qué, y qué alternativas se descartaron.
Si el agente aplicó un “hack” para pasar un test, eso no puede quedar en un chat efímero. Tiene que vivir en tu repo, indexable. JSONL. PR metadata. Historia forense.

¿Por qué? Porque poder buscar “find all shortcuts” salva horas de debugging y evita que el mismo hack mute millón de veces.

7) Integración práctica: stack mínimo para empezar hoy

No necesitas toda una nave espacial. Esto es un MVP operativo:

• Orquestador: un servicio que planifica pasos y guarda estado (puede ser una pequeña cola + DB).
• Callers LLM: modelos rápidos (OSS) para edición y modelos potentes (RLM) para verificación.
• RAG vector DB para contexto y specs.
• Validadores: linters, pruebas unitarias, integración y un sandbox de ejecución.
• Decision store: archivo versionado (.decisions.jsonl) por PR.
• CI que no solo ejecuta tests, sino que verifica que la spec y los tests se actualizaron si el código cambió.

8) Un flujo mínimo (ejemplo)

1. Dev escribe o actualiza spec en formato operable.
2. El agente genera código y propone cambios en una rama.
3. Pipeline ejecuta tests + validadores.
4. Agente intenta optimizar. Si aplica un atajo, registra una decisión en .jsonl. Commit falla si no hay artefacto.
5. Reviewer aprueba la decisión o solicita cambio.
6. Merge + sync spec/tests/código.

Sí, agrega fricción. Es la fricción que salva producción.

9) Herramientas y patrones recomendados

• Esquemas validados: usa Zod o similar para validar outputs LLM cuando tocas boundaries.
• Captura de decisiones: .jsonl con campos: id, pregunta, decisión, autor (LLM/humano), timestamp, diff link.
• Umbrales configurables: “strict” para core, “lenient” para experiments.
• Rollbacks automáticos: si una decisión se revoca, tus pipelines deben poder revertir o marcar la rama como needing-fix.
• Observabilidad: traces de latencia, éxito de validadores, número de decisiones por PR.

10) Cultura, no solo stack

No automatices los valores. Automatiza la disciplina.
Si el equipo ve la herramienta como un juez en lugar de asistente, la odiarán. Hazla útil. Hazla pequeña. Hazla punitiva solo cuando tenga que serlo.

• Regla simple: cada cambio que no sea trivial necesita al menos una línea en la spec o una entrada en el decision log.
• No más “and let it run and we go answer some email and then we come back and now I get a decision and I’m like, that’s insane. Don’t do that.” Si vas a delegar, que quede registrado.

11) Riesgos reales y cómo mitigarlos

• Ruido: Demasiadas decisiones pequeñas saturan. Solución: umbrales y agrupación por categoría.
• Alucinaciones del LLM: Validadores estrictos y esquemas runtime.
• Duplicidad de specs: Fragmenta specs por dominio y mantén ownership.
• Ataques o leak de credenciales: todo secreto rotatable y accesible solo a procesos autorizados.

12) Qué cambiar en GitHub (si tuvieras la varita mágica)

• Markdown como entidad semántica. No solo texto.
• Linkar decisiones ↔ specs ↔ tests ↔ diffs en la UI.
• Búsqueda por “intención” (por ejemplo: “find decisions that relaxed auth checks”).
• Hooks nativos que prevengan merges sin decision artifacts.

13) Resultado: ¿qué ganas si lo haces bien?

• Menos deuda acumulada.
• Onboarding más rápido. Nuevos devs leen la historia de decisiones.
• Automatización sin descontrol.
• Auditoría real para compliance.
• Velocidad que no se convierte en caos.

14) No es sexy. Es efectivo.

Las grandes respuestas técnicas no son flashes de genialidad. Son procesos con disciplina.
Tenemos herramientas para bajar esa disciplina a la realidad operativa. Compound AI no es excusa para saltarse pasos. Es oportunidad para formalizarlos.

¿Quieres que lo vuelva práctico?
Puedo:
– Escribir el template de .jsonl para decisiones.
– Diseñar el flujo de CI (GitHub Actions) que bloquee merges sin sincronía spec↔tests↔code.
– Crear un checklist para ponerlo en marcha en 2 semanas.

Respóndeme “Dame el template” o “Quiero la CI” y te lo entrego listo para copiar.
Y recuerda: velocidad sin registro es solo una forma elegante de cavar tu propia trampa. Esto no acaba aquí.

Si quieres avanzar en pipelines, validación y decision logging con ejemplos prácticos y plantillas, revisa los recursos y experimentos de Dominicode Labs. Es una continuación lógica para equipos que quieren pasar de prototipos a procesos operables. Encontrarás ejemplos de decision logs y patrones de integración que encajan con lo expuesto arriba.

FAQ

• ¿Qué es Compound AI?
• ¿Cuándo debo usar validadores estrictos?
• ¿Qué debe contener un decision log (.jsonl)?
• ¿Cómo evito que el agente aplique hacks sin supervisión?
• ¿Qué cambios mínimos implemento en CI?
• ¿Cómo balancear fricción y velocidad?

¿Qué es Compound AI?

Compound AI es la orquestación de múltiples modelos, herramientas de validación, bases de conocimiento (RAG) y un controlador que decide qué modelo o herramienta usar, cuándo y cómo, para producir resultados reproducibles y verificables.

¿Cuándo debo usar validadores estrictos?

Usa validadores estrictos en componentes core que afectan seguridad, integridad de datos o disponibilidad. Para experimentos o prototipos puedes aplicar umbrales más lenient, pero documentándolo en el decision log.

¿Qué debe contener un decision log (.jsonl)?

Campos mínimos: id, pregunta, decisión, autor (LLM/humano), timestamp y diff link. Debe ser indexable y versionado por PR.

¿Cómo evito que el agente aplique hacks sin supervisión?

Bloquea commits sin artefacto de decisión; ejecuta validadores en CI; exige que cualquier atajo quede registrado en .jsonl y sea revisado por un humano antes del merge.

¿Qué cambios mínimos implemento en CI?

1) Ejecutar tests y validadores automáticamente. 2) Comprobar que specs y tests cambien si el código cambia. 3) Fallar merges que no incluyan decision artifacts.

¿Cómo balancear fricción y velocidad?

Define umbrales configurables: “strict” para core y “lenient” para experiments. Agrupa decisiones pequeñas y aplica políticas de batching para reducir ruido sin sacrificar trazabilidad.