Cómo usamos Jev para dos tareas en la revisión de código con IA
El modelo de decisión Jev responde con números, no con texto. Lo usamos en dos tareas de revisión de código con IA, y de lo medido sale una regla: compara, no juzga.
Resumen. Un modelo de decisión (decision model) es un modelo de IA que no escribe texto y responde con un número a preguntas tipadas. diffox ultra usa el modelo Jev de TypeSafe en la cuarta etapa de una revisión, cuando elige qué publicar. En septiembre de 2026 medimos dónde ayuda y dónde no; en este artículo contamos lo que medimos y las lecciones que sacamos.
- Dos tareas. Antes de la selección, responde a diez preguntas sobre cada hallazgo candidato. Después de la selección, encuentra los hallazgos que llevan a la misma causa raíz y deja solo uno.
- Dónde ayuda: comparar. Al preguntarle si dos hallazgos describen el mismo error, 46 de los 47 pares que señaló eran de verdad el mismo error.
- Dónde no ayuda: juzgar. Ante «¿es real este hallazgo?», no distinguió mejor que la puntuación de confianza del modelo que escribió el hallazgo.
- La regla. Pide a un modelo de decisión que elija, no que juzgue: «¿son iguales estos dos?», «¿cuál?», «¿qué nivel?».
Cómo responde un modelo de decisión
Los tres primeros artículos contaron los resultados de diffox, su precio y las cuatro etapas de una revisión. Este trata de un modelo que trabaja en una de esas etapas sin escribir una sola frase.
Si le haces una pregunta a un modelo de lenguaje, la respuesta es un texto. A un modelo de decisión, en cambio, le das un estado y preguntas tipadas, y responde a cada una con un solo número: una probabilidad de sí, una distribución entre opciones o un nivel en una escala. Responde a la vez a todas las preguntas de una petición. Jev, de TypeSafe, es un modelo así; TypeSafe lo llama modelo «System One».
Como la respuesta no es texto, dos cosas se vuelven más fáciles: decidir con un umbral y combinar la respuesta con otras señales. Una se vuelve más difícil: el modelo solo responde a la pregunta que le haces y nunca dice que estaba mal planteada. Por eso tuvimos que medir para saber qué preguntas vale la pena hacer.
Qué hace Jev en diffox ultra
Una revisión pasa por cuatro etapas: contexto, revisión especializada, verificación de pruebas, y elegir y publicar. Jev solo trabaja en diffox ultra y solo en la cuarta etapa. Las verificaciones de pruebas siguen siendo código normal; diffox, el producto principal, no usa ningún modelo de decisión.
La primera tarea llega antes de la selección. En diffox ultra, dos modelos distintos leen el cambio. Por cada hallazgo candidato de esas dos revisiones, el modelo de decisión recibe dos rondas de preguntas, y sus diez respuestas entran en la puntuación de la selección junto con las señales propias del hallazgo. Se publica el hallazgo cuya puntuación supera el umbral. Por sí solo, el modelo de decisión no publica ni elimina ningún hallazgo; sus respuestas son una de las entradas de la puntuación.
La segunda tarea llega después de la selección. Los hallazgos que se van a publicar pasan al modelo de decisión de dos en dos: «¿describen estos dos la misma causa raíz?». Si la respuesta es 0,5 o más, el siguiente se descarta y se queda el mejor puntuado. Si un candidato esperaba el hueco que queda libre, lo ocupa cuando pasa la misma prueba. En la verificación de pruebas, Second Witness une la misma objeción hecha en el mismo lugar; el modelo de decisión, en cambio, encuentra hallazgos que están en líneas distintas pero llevan al mismo error.
Si el modelo de decisión no responde, la revisión sigue: la selección se hace sin sus respuestas, se omite la búsqueda de duplicados y el registro de la revisión lo indica.
Qué le preguntamos al modelo de decisión
Las preguntas de la primera tarea no buscan saber si un hallazgo es correcto, sino qué tipo de afirmación hace y en qué se apoya. Por cada hallazgo candidato, el modelo de decisión recibe cuatro cosas: el título del pull request, el agente que escribió el hallazgo y su descripción, el cambio en el archivo del hallazgo (como máximo 15.000 caracteres) y el texto del hallazgo.
| Pregunta | Qué mira | Respuesta |
|---|---|---|
| ¿En el camino principal? | ¿El error ocurre con una entrada normal y válida, o solo cuando falla otra cosa, con una entrada maliciosa o con un ajuste poco habitual? | probabilidad de sí |
| ¿Una precaución? | ¿El hallazgo informa de un resultado erróneo, o propone una precaución: una validación, una comprobación defensiva, otro tipo de error? | probabilidad de sí |
| ¿Un efecto visible? | Si no se corrige, ¿vería un usuario o quien llama alguna diferencia? El código muerto, un import sin usar o una documentación desfasada no muestran ninguna. | probabilidad de sí |
| ¿Depende de lo que no se ve? | ¿La afirmación se apoya en código, en quien llama o en un ajuste que no se muestran aquí? | probabilidad de sí |
| ¿Lo causa este cambio? | ¿El problema viene de las líneas que este diff añade o modifica, o ya existía antes? | probabilidad de sí |
| ¿Lo comentaría un revisor? | ¿Comentaría este punto un revisor con experiencia? La escala va desde no mencionarlo hasta bloquear el merge. | nivel del 1 al 5 |
| ¿Contrastado con código hermano? | ¿El hallazgo se apoya en código hermano del mismo cambio que hace lo mismo de otra forma y muestra la forma correcta? | probabilidad de sí |
| ¿Un arreglo pequeño? | ¿Bastaría con cambiar un nombre, un valor, un operador o una condición para corregir el código? | probabilidad de sí |
| ¿Con reservas? | ¿La afirmación dice «podría, quizá», o dice con certeza qué sale mal? | probabilidad de sí |
| ¿Intencionado? | A juzgar por el título del pull request y la forma del diff, ¿el comportamiento que objeta es el propósito de este cambio: algo quitado a propósito, un límite nuevo? | probabilidad de sí |
Nueve de las diez son preguntas de sí o no, que se responden con una probabilidad de sí; la otra, la del revisor, pide un nivel del 1 al 5. Las diez respuestas entran en la puntuación de la selección junto con las señales propias del hallazgo: su gravedad, su tipo, el resultado de las verificaciones de pruebas y si otros hallazgos señalan el mismo lugar. Después, la puntuación decide qué hallazgos se publican. Además, a cada agente se le hacen una o dos preguntas sobre su propio tema, pero en la puntuación solo entran estas diez respuestas.
Lo que tienen en común estas preguntas es que la respuesta ya está delante del modelo. Si un error está en el camino principal lo dice el escenario del hallazgo; si la afirmación tiene reservas se ve en la propia frase. Al modelo de decisión no le pedimos que vuelva a juzgar el hallazgo, solo que lea el texto que tiene delante y lo coloque en una casilla.
Dónde ayuda el modelo de decisión
En septiembre de 2026 medimos dónde ayuda el modelo de decisión. Usamos hallazgos que cuatro configuraciones de revisión distintas encontraron en pull requests de proyectos de código abierto, cada uno cotejado con errores que personas habían marcado de antemano. El resultado más claro llegó en una pregunta: ¿describen dos hallazgos el mismo error? Es la que evita que un error reciba un segundo comentario.
Preguntamos «¿la misma causa raíz?» sobre 374 pares de hallazgos; 58 de ellos describían de verdad el mismo error. Con un umbral de 0,5, el modelo de decisión señaló 47 pares y acertó en 46. Su puntuación de separación fue 0,99; la de una regla que solo pregunta «¿mismo archivo?» es 0,73. La puntuación de separación es la probabilidad de que un par del mismo error, elegido al azar, quede por delante de un par de errores distintos elegido al azar: 0,5 es cara o cruz y 1 es perfecta.
El mismo tipo de pregunta sirvió en otro caso: situar la gravedad de un hallazgo en uno de cuatro niveles. La coincidencia exacta con la gravedad que dieron las personas fue del 49,5 % con el criterio propio del motor y del 56,8 % con la corrección del modelo de decisión (222 hallazgos). Lo medimos, pero hoy no está activado en ninguno de los dos productos.
Dónde no ayuda
El mismo modelo fue débil ante «¿es real este hallazgo?». 315 de 656 hallazgos coincidían con un error conocido. La puntuación de separación del modelo de decisión fue 0,64, frente a 0,65 de la confianza del modelo que escribió el hallazgo: no mejor que una señal que ya teníamos.
Acotar la pregunta no cambió nada: doce preguntas concretas y un modelo aprendido que las combina solo llevaron la puntuación de separación a 0,67.
La diferencia está en la propia pregunta. Al comparar dos textos, el modelo tiene todas las pruebas delante. Si el código se comporta de verdad así no está escrito en ningún sitio; para saberlo hay que leer el código y construir un escenario. En diffox ese es el trabajo de los agentes especializados, y la afirmación se demuestra con una cita del archivo.
¿Qué herramienta para cada tarea?
En una revisión trabajan cuatro tipos de herramientas, y cada una es buena en una tarea distinta.
| Herramienta | Produce | Misma entrada, misma respuesta | Su tarea en diffox |
|---|---|---|---|
| Código normal | un sí o un no claro | siempre | verificaciones de pruebas, detectores basados en reglas |
| Modelo de decisión | una probabilidad, una elección o un nivel | casi: preguntado de nuevo, varió como mucho 0,07 | en diffox ultra, diez preguntas y la búsqueda de duplicados |
| Modelo de lenguaje (LLM) | texto | no | agentes especializados; títulos y sugerencias de corrección |
| Selector aprendido | una puntuación | siempre | qué hallazgos se publican |
El reparto del trabajo sale de la tabla. Una pregunta que se puede responder con una regla fija va al código. Comparar dos cosas que tiene delante, o elegir una entre pocas opciones, va al modelo de decisión. Leer código, construir un escenario y explicárselo a un lector va al modelo de lenguaje. Convertir todas esas señales en una sola decisión de «publicarlo o no» va al selector aprendido.
Siete lecciones para usar un modelo de decisión
Lo que aprendimos al llevar un modelo de decisión al producto, de nuestros propios experimentos:
- Pídele que elija, no que juzgue. La respuesta a «¿son iguales estos dos?», «¿qué nivel?», «¿cuál?» está delante de él; la de «¿es correcto?» no.
- Envía en una sola petición las preguntas que comparten un estado. Añadir una pregunta apenas retrasa la respuesta. Una de nuestras etapas no lo hacía: enviaba una petición por hallazgo y el mismo diff cada vez. Con una sola petición, el estado enviado se redujo un 55 %.
- Fija la versión. Los umbrales se miden sobre las probabilidades de una versión. diffox ultra usa una versión fija, no un alias «latest»; si la versión cambia, el umbral se vuelve a medir.
- Antes de añadir una señal, compárala con lo que ya tienes. Una señal nueva vale lo que añade a las que ya tienes. Nuestra pregunta «¿es real?» no añadió nada a la puntuación de confianza propia del hallazgo.
- Úsalo como entrada, no como barrera. En diffox ultra, las respuestas del modelo de decisión no eliminan ni publican por sí solas ningún hallazgo; entran en la puntuación de la selección. Lo único que elimina es un segundo comentario sobre el mismo error.
- Elige el umbral pensando en el lector. El umbral de la búsqueda de duplicados es 0,5: 46 de los 47 pares que señala son correctos. Con 0,9 no habría ningún error, pero solo se encontraría el 36 % de los duplicados.
- Si no llega respuesta, que la revisión siga sin ella. Y que lo deje anotado en el registro: una etapa que falta es mejor que una que se salta en silencio.
Preguntas frecuentes
¿Qué es un modelo de decisión (decision model)?
Un modelo de IA que no escribe texto. Le das un estado y preguntas tipadas, y responde a cada una con un número: una probabilidad de sí, una distribución entre opciones o un nivel en una escala. Responde a la vez a todas las preguntas de una petición. Jev, de TypeSafe, es un modelo así; diffox ultra lo usa en la etapa de selección de una revisión.
¿En qué se diferencia un modelo de decisión de LLM-as-a-judge?
Con LLM-as-a-judge, un modelo de lenguaje lee una salida y escribe su veredicto como texto, a menudo con su razonamiento. Un modelo de decisión no escribe texto: devuelve para cada pregunta una probabilidad de sí, una elección o un nivel, y responde a la vez a todas las preguntas de una petición. Por eso su respuesta es fácil de comparar con un umbral y de combinar con otras señales; así lo usa diffox ultra.
¿diffox también usa un modelo de decisión?
No. El modelo de decisión solo trabaja en diffox ultra. En diffox, qué hallazgos se publican se decide con las señales propias de los hallazgos, y el código normal une la misma objeción hecha en el mismo lugar.
¿El modelo de decisión ve mi código?
Por cada hallazgo candidato ve su texto, el cambio en su archivo (como máximo 15.000 caracteres), el título del pull request y la descripción del agente que lo escribió. Esos datos van a TypeSafe, que sirve el modelo, directamente o a través de OpenRouter; nuestra página de privacidad indica qué servicios se usan.
¿Puede el modelo de decisión eliminar un hallazgo?
Por sí solo, no. Sus respuestas entran en la puntuación de la selección, y la puntuación decide qué hallazgos se publican. Lo único que elimina es el segundo hallazgo de una misma causa raíz; se publica el mejor puntuado.
¿Por qué no preguntáis al modelo de decisión si un hallazgo es real?
Lo medimos: en esa pregunta no separó mejor que la puntuación de confianza del modelo que escribió el hallazgo. Saber si el código se comporta de verdad así exige leerlo y construir un escenario; en diffox lo hacen los agentes especializados, y la afirmación se demuestra con una cita del archivo.
¿Da siempre la misma respuesta a la misma pregunta?
Casi. Al hacerle de nuevo las mismas preguntas, sus respuestas variaron como mucho 0,07. Por eso medimos los umbrales sobre las probabilidades de una versión y fijamos la versión.