Reglas como tests: escribís la regla una vez y corre en cada commit

El patrón en un dibujo

Un test chequea un pedazo de código. Escribís el código, después escribís su test, uno por uno.

Un código también tiene reglas: «las entidades de un test reusan los mocks del slice», «cada caso de fallo afirma su código de error». Esas reglas vivían en un documento y en la cabeza de quien revisa. Ahora cada regla pasa a ser un test propio. Lo escribís una vez, y corre sobre cada archivo de su alcance, incluidos los que un agente escriba mañana.

Esa es la idea entera. El resto del post cuenta cómo funciona, cómo se ve el test y por qué cambia lo que cuesta revisar código escrito por IA.

Por qué lo necesitaba

Mis agentes de IA commitean pasando por un gate de guardianes: subagentes revisores, uno por área del código, que leen el diff en stage y le ponen nota.

Los guardianes revisan bien, y se pagan en cada pasada. Un fix de una línea reabre la ronda, porque cualquier cambio en el área de un guardián anula su nota. Planes que tendrían que llevar minutos se llevaban una tarde.

Casi todo lo que chequea un guardián es un juicio puntual sobre un solo archivo. Esa pregunta pide un modelo que lea el archivo, y solo ese archivo.

Jev, en dos líneas

Jev es el modelo de evaluación de TypeSafe. Le das un contexto y un conjunto de preguntas de sí o no, y te devuelve la probabilidad del sí para cada una, al ritmo de un linter, cobrando solo la entrada.

Cómo funciona

Una regla es un archivo declarativo que vive en el repo. Dice qué mirar y qué preguntar:

export default {
  title: 'The test reuses the slice’s mocks and leaves them untouched',
  on: 'src/**/*.test.ts',
  // Las piezas de contexto que Jev recibe por cada archivo.
  state: ['file', 'subject', 'mocks'],
  questions: {
    reuses_slice_mocks: {
      // Por debajo de esta probabilidad el test falla. Sale de un rojo y un verde reales.
      barrier: 0.6,
      // El código decide a quién se le pregunta: sin mocks, no hay pregunta.
      applies: { mocks: true },
      instructions:
        'Does every entity-shaped object in `file` ' +
        'name an imported mock or spread one?',
    },
  },
}

El motor arma las piezas de cada archivo (el test, el módulo que prueba, los mocks que podría usar), saltea los archivos que quedan fuera del alcance de la pregunta y le manda a Jev una llamada por regla con todas sus preguntas.

Cómo se ve el test

Es una suite de Vitest común: un describe por archivo, un test por regla, una fila por pregunta. Un rojo nombra el archivo, la regla y la pregunta exacta que falló, así quien lo lea (una persona o un agente) sabe qué arreglar.

Se fabrica una vez, corre en todos lados

El test de la regla se fabrica una vez y corre en el hook de pre-commit, en el push, en CI/CD, en una barrida del árbol entero y adentro del propio loop del agente mientras escribe código. Cada corrida lleva menos de 500 ms.

Los resultados se guardan por hash del contenido. El gate del commit solo lee ese registro, así que funciona sin red y al instante, y el mismo archivo con las mismas preguntas se pregunta una sola vez.

Lo que ahorra: tiempo, tokens, rondas

La diferencia está en dónde se cierra el loop. Con un guardián, cada fix vuelve a pasar por un agente que razona. Con el test de la regla, el mismo agente que escribió el código corre la regla, lee el rojo, arregla la línea y la corre de nuevo, todo antes de pedir el commit.

Por qué funciona la arquitectura

La decisión de diseño que sostiene todo es la separación. Las reglas viven en el repo y se revisan como código; el motor que las corre vive afuera y evoluciona por su cuenta. Sumar una pregunta es una entrada, sumar un scope es una carpeta de reglas, y una falsa alarma se arregla con una línea de alcance.

Dónde está la línea

Jev es fuerte en un juicio sobre un archivo. Todo lo que compara dos listas, cuenta o depende del orden es trabajo del código común. La regla práctica que salió de calibrar: el código enumera, Jev juzga de a una cosa.

Cómo empezar

1. Listá lo que chequea tu revisor. Cada guardián, cada checklist de review.
2. Repartí cada ítem en código (un grep, un chequeo de AST), un juicio sobre un archivo o razonamiento de verdad.
3. Escribí el cajón del medio como reglas. Una pregunta de sí o no cada una, con el mecanismo visible en el texto.
4. Calibrá cada pregunta con un rojo y un verde reales antes de dejar que frene algo.
5. Enchufá la suite al hook y a CI, y guardá al agente revisor para el último cajón.

El agente revisor sigue estando, y se lo llama para las preguntas que necesitan razonar, con una fila en rojo como brief. Todas las demás reglas pasan a ser un test que escribís una vez.