540
540deg.com · Jev · IA en 540

Jev para code review Un examen tipo test para la IA.

Jev es un modelo de IA que solo elige entre opciones. Le das un contexto y unas preguntas con respuestas cerradas, y te devuelve la opción que elige y con qué probabilidad. Aquí lo contamos con una prueba real: evaluar los findings de una code review automática.

Actualizado · Octubre 2026
01

Qué es Jev

Un LLM normal

Le preguntas y te responde con texto. Tú tienes que interpretar ese texto para decidir qué hace el programa.

¿Hay que arreglar esto?«Sí, parece un problema real porque el campo vacío…»
Jev

Le preguntas con opciones y marca una. El programa usa esa opción directamente, como en un switch.

¿Hay que arreglar esto? aplicar / descartar / dudar● aplicar (93 %)

Como no genera texto, es mucho más rápido y barato que un LLM. Y la probabilidad dice cuánta seguridad tiene en cada respuesta.

02

Dónde lo hemos probado

En puntuar una code review. Un agente revisa el código y genera findings, que son los problemas que encuentra. Después, cada finding resta puntos a una nota de 10.

01La reviewUn LLM revisa el código y lista los findings.
02Evaluar cada finding¿Es real? ¿Cómo de grave? ¿Qué parte del código afecta?
03Restar puntosSegún la gravedad y la parte afectada.
04La notaUna nota de 10 por cada parte.
Antes · un LLM evalúa

El LLM revisa cada finding (si es real, si se aplica, de qué tipo es) y el scoring resta según el tipo (testing −2, alineamiento −1, naming −0,5). La respuesta no dice cuánta seguridad tiene.

Ahora · Jev evalúa

Jev responde esas mismas preguntas, cada una con su probabilidad. Con el ámbito y la gravedad se calculan los puntos. Si la probabilidad es baja, decide una persona.

03

El finding

Un nombre vacío deja una fila sin título

El código comprueba que el nombre exista, pero no que tenga texto. Si el nombre llega como '', la fila de la pantalla se queda sin título.

Arreglo propuesto: comprobar también que tenga texto y añadir un test para el caso vacío.

A Jev le mandamos este finding con su contexto: el código de alrededor, los criterios del ticket y las decisiones previas del equipo. Y le hacemos cinco preguntas en una sola llamada. Jev las responde a la vez y cada una por separado, sin usar la respuesta de las demás.

04

El test, contestado

05

Del test a la nota, un ejemplo

Tres reglas, en este orden
  1. Si se decidió a propósito, se descarta.
  2. Si Jev no llega a la seguridad mínima, decide una persona. La nota queda pendiente hasta que decida.
  3. Si no, se aplica y resta puntos según la gravedad.

Mueve la seguridad mínima para ver por dónde sale este finding.

    Resta de ejemplo: crítico −3, mejora −1, limpieza −0,25. Los pesos reales son otros.

    06

    Por qué Jev

    LLM normalJev
    Qué devuelveTexto o JSON que hay que validarUna opción de la lista
    SeguridadNo la daProbabilidad por opción
    Esta llamada—3.635 tokens de entrada, 95 de salida, ≈ $0,00015
    LatenciaSegundos70–500 ms según TypeSafe (sin medir aquí)

    Límites

    • No explica sus respuestas. El finding y el arreglo los sigue escribiendo el LLM de la review.
    • Clasifica tan bien como estén escritas las opciones.
    • Admite poco contexto: 32.000 tokens para el contexto más la pregunta más larga. Además, acierta menos si el contexto trae mucho ruido, así que hay que mandarle solo lo que necesita.
    • De momento hemos hecho pocas pruebas.
    07

    La llamada real

    La petición 
    {
  "model": "jev-latest",
  "state": {                          // 1
    "finding": { "title": "An empty plan name…", … },
    "plannerAssumptions": [ /* decisiones previas */ ],
    "acceptanceCriteria": "<criterios del ticket>",
    "codeAroundFinding": "<80 líneas>"
  },
  "questions": {                      // 2
    "intentional": {
      "type": "noul",                   // 3
      "instructions": "Does one of the planner…",
      "criteria": { "true": "…", "false": "…" }  // 4
    },
    "decision": {
      "type": "choice",
      "criteria": { "apply": "…", "discard": "…", "doubt": "…" }
    },
    /* genuineImprovement, severity, scope */
  }
}
    1. 1
      state es el contexto, en bruto y sin esquema: el finding, las decisiones previas, los criterios del ticket y el código de alrededor.
    2. 2
      questions son las preguntas del test. Jev las responde todas a la vez en una sola llamada.
    3. 3
      type dice qué forma tiene la respuesta. noul es un sí/no y choice elige de una lista.
    4. 4
      criteria explica en lenguaje natural qué significa cada opción. De lo bien escrito que esté depende que Jev acierte.
    La respuesta 
    {
  "answers": {
    "intentional":        { "noul": 0.15 },  // 1
    "genuineImprovement": { "noul": 0.89 },
    "decision": {
      "choice": "apply",                  // 2
      "probabilities": {
        "apply": 0.93, "doubt": 0.05, "discard": 0.02
      },
      "confidence": 0.90                   // 3
    },
    "severity": { "choice": "improvement", … },
    "scope":    { "choice": "codeQuality", … }
  },
  "usage": {                            // 4
    "input_tokens": 3635, "output_tokens": 95
  }
}
    1. 1
      noul es la probabilidad de que la respuesta sea «sí». 0,15 quiere decir que casi seguro es «no».
    2. 2
      choice es la opción elegida, y probabilities reparte el 100 % entre todas las opciones.
    3. 3
      confidence resume cuánto destaca la opción elegida sobre el resto. Es el número que usa el código para la seguridad mínima.
    4. 4
      usage son los tokens de la llamada. Solo se paga la entrada.
    08

    Documentación