Cardumen on vs. off: what we measure
How we design on/off comparisons with the same repo, model and task; what signals we observe and why the sample still demands caution.
A number without experimental design is copy. That is why the first question is not “how much does Cardumen improve?”, but “which variable changed and who judged the result?”
Our comparison uses a kill switch: same repository, model and task; the harness changes from on to off.
What we try to isolate
Cardumen groups several pieces: code map, compiled memory, rules, result contract, guards and verification. An on/off test compares the complete system with a prompt that has no such scaffolding.
That lets us measure the combined effect. It does not let us attribute the entire change to one individual piece.
The minimum protocol
Same task
The question should touch enough architecture to require navigation and reasoning while preserving a verifiable answer.
Same environment
Model, version, repository, commit, prompt, permissions and tools. If one condition changes, record it.
External judge
The agent does not decide quality. Compare against tests, build, real code or an adversarial reviewer who verifies every claim.
Keep the worst cases
An expensive or slow run is not deleted because it looks anomalous. Variance and worst case matter when a team needs to budget time and cost.
What we have observed so far
In a real NestJS monorepo, a cross-service audit ran three times per arm with a frontier model. Average quality was the same in both arms, but cost was more stable with Cardumen:
- with Cardumen: average of 13,211 tokens and standard deviation of 425;
- without Cardumen: average of 20,587 tokens and standard deviation of 12,876;
- the worst run without the harness reached 38,737 tokens, 23 turns and 9.6 minutes.
That result describes one task, one repository and six runs. It is directional evidence, not a universal promise.
In another test with local qwen3.5-9b on a repository rich in memory and graph data:
- tokens fell from 312,991 to 178,581;
- exploration went from 16 to 8 steps;
- wall-clock time increased in that run.
The honest reading is not “everything improved”. The harness reduced exploration and tokens, but that case did not demonstrate lower latency.
What we measure
| Dimension | Why it matters |
|---|---|
| Verifiable result | Prevents rewarding convincing but false answers |
| Tokens | Approximates cost and quota pressure |
| Wall-clock time | Captures waiting and real overhead |
| Turns and tools | Shows exploration and loops |
| Variance | Reveals predictability |
| Worst case | Exposes the risk hidden by the average |
What we still cannot claim
We cannot generalize these results to every language, team or model. We also cannot claim that a local model matches a frontier model.
The current samples are small — between three and six runs depending on the test — and the repositories have particular conditions. Before turning a signal into a commercial promise, reproduce it in the buyer's environment.
Bring the protocol to your repository
- select a task that already has a judge;
- freeze commit, model, permissions and prompt;
- define metrics before running;
- run both arms several times;
- keep failures and outliers;
- publish the sample, conditions and limits alongside the number.
Good evidence does not remove uncertainty. It makes uncertainty visible.
Una cifra sin diseño experimental es copy. Por eso la pregunta inicial no es “¿cuánto mejora Cardumen?”, sino “¿qué variable cambió y quién juzgó el resultado?”.
Nuestra comparación usa un kill-switch: mismo repositorio, modelo y tarea; el harness cambia de encendido a apagado.
Qué intentamos aislar
Cardumen agrupa varias piezas: mapa del código, memoria compilada, reglas, contrato de resultado, guards y verificación. Una prueba on/off compara el sistema completo contra un prompt sin ese andamiaje.
Eso permite medir el efecto conjunto. No permite atribuir todo el cambio a una pieza individual.
El protocolo mínimo
Misma tarea
La pregunta debe tocar suficiente arquitectura para exigir navegación y razonamiento, pero conservar una respuesta verificable.
Mismo entorno
Modelo, versión, repositorio, commit, prompt, permisos y herramientas. Si cambia una de esas condiciones, se registra.
Juez externo
La calidad no la decide el agente. Se compara contra tests, build, código real o un reviewer adversarial que verifica cada afirmación.
Peores casos conservados
Una corrida cara o lenta no se borra por parecer anómala. La varianza y el peor caso importan cuando el equipo necesita presupuestar tiempo y costo.
Lo observado hasta ahora
En un monorepo NestJS real, una auditoría cross-service se ejecutó tres veces por brazo con un modelo de frontera. La calidad media reportada fue la misma en ambos brazos, pero el costo fue más estable con Cardumen:
- con Cardumen: media de 13.211 tokens y desviación de 425;
- sin Cardumen: media de 20.587 tokens y desviación de 12.876;
- la peor corrida sin el harness alcanzó 38.737 tokens, 23 turnos y 9,6 minutos.
Ese resultado describe una tarea, un repositorio y seis corridas. Es señal direccional, no una promesa universal.
En otra prueba con qwen3.5-9b local sobre un repositorio rico en memoria y
grafo:
- los tokens bajaron de 312.991 a 178.581;
- la exploración pasó de 16 a 8 pasos;
- el tiempo de pared aumentó en esa corrida.
La lectura honesta no es “todo mejoró”. El harness redujo exploración y tokens, pero ese caso no demostró menor latencia.
Qué medimos
| Dimensión | Por qué importa |
|---|---|
| Resultado verificable | Evita premiar respuestas convincentes pero falsas |
| Tokens | Aproxima costo y presión de cuota |
| Tiempo de pared | Captura esperas y overhead real |
| Turnos y herramientas | Muestra exploración y loops |
| Varianza | Revela predictibilidad |
| Peor caso | Expone el riesgo que esconde el promedio |
Qué todavía no podemos afirmar
No podemos generalizar estos resultados a cualquier lenguaje, equipo o modelo. Tampoco afirmar que un modelo local iguala a uno de frontera.
Las muestras actuales son pequeñas —entre tres y seis corridas según la prueba— y los repositorios tienen condiciones particulares. Antes de convertir una señal en promesa comercial, toca reproducirla en el entorno del comprador.
Cómo llevar el protocolo a tu repositorio
- selecciona una tarea que ya tenga un juez;
- congela commit, modelo, permisos y prompt;
- define métricas antes de ejecutar;
- corre ambos brazos varias veces;
- conserva fallos y outliers;
- publica muestra, condiciones y límites junto a la cifra.
La evidencia buena no elimina la incertidumbre. La vuelve visible.
Traceability
Sources and scope
- Cardumen evidence
Public source for the runs, methodology, limits and on/off metrics cited in this article.
- Cardumen documentation
Defines the harness components isolated in the comparisons: graph, memory, guards and verify.
- Cardumen security
Sets the local-first model and data restrictions that apply when running tests on real repositories.
- Evidencia Cardumen
Fuente pública de corridas, metodología, límites y métricas on/off citadas en este artículo.
- Documentación Cardumen
Define los componentes del harness cuyo efecto se aísla en las comparaciones: grafo, memoria, guards y verify.
- Seguridad Cardumen
Delimita el modelo local-first y las restricciones de datos aplicables al ejecutar pruebas en repositorios reales.