Jev: cuando quien consume el modelo es el código

La idea en una frase

Un modelo cuyo consumidor no es una persona, sino el código.

Es la tesis de Jev, que Diogo Almeida, CEO de TypeSafe AI, explica a swyx en Jev: System One models for Prod, not God (Latent Space, 22 de septiembre de 2026). Los modelos actuales están hechos para autocompletar internet (preentrenamiento) o para contestar a personas (RLHF). Jev, un modelo «System 1» o large programmable model, está diseñado para que lo llame software directamente; de ahí el nombre de la empresa, TypeSafe.

El nombre viene de la paradoja de Jevons: si la inteligencia se abarata, se consume mucha más. Por eso el objetivo declarado no es la frontera de inteligencia absoluta, sino la de inteligencia por dólar.

Tres estrellas polares

Según Diogo, el entrenamiento de LLMs ha perseguido tres objetivos, y dos están mal elegidos:

• RLHF (feedback humano): el modelo aprende a complacer. Resultado: alucinaciones, sicofancia y dependencia permanente de humanos. Lo vuelve menos fiable, no más.
• RLVR (rewards verificables por programa): optimiza benchmarks. Resuelve Navier-Stokes, pero agrava la inteligencia dentada: brillante en unas cosas y torpe en otras. Y se integra mal con otro software.
• RLCD (Reinforcement Learning for Calibrated Decisions): la apuesta de TypeSafe. Busca respuestas con probabilidades epistémicamente honestas en tareas de System 1. No está publicada: ni paper ni detalles.

El argumento de fondo no va de algoritmos. Cita la bitterest lesson: lo más importante del machine learning es elegir la tarea y los datos. Por eso se definen como un laboratorio de datos, no de modelos.

Si quien consume es código, cambian las reglas

Sin refusals. En un chat, una negativa es una molestia que se puede sortear. Dentro de una dependencia que corre en segundo plano, el software se rompe de forma estocástica porque un usuario escribió algo raro.

En un producto, el safety alignment tiene sentido. En una API es un error de tipo.

• La API debe hacer lo que se le pide: cuanto más predecible, menos tiene que probarla quien la integra.
• La comparación que usa: a una base de datos no le toca decidir para qué se usa.
• Tampoco identidad: quien construye un chatbot sobre la API no quiere que diga que es otro. Jev no lleva «soy Jev de TypeSafe» dentro.

El mecanismo que une todo esto: cada sobreajuste fractura la inteligencia. Optimizar para chat produce sicofancia, exceso de confianza, alucinaciones y el estilo LM Arena (negritas, emojis, respuestas largas y una pregunta de seguimiento al final).

Robustez, no determinismo

La distinción más aprovechable de la entrevista:

• Determinismo: mismos inputs, mismos outputs. Según Diogo, es el objetivo equivocado; como mucho, útil para tests unitarios.
• Robustez: inputs parecidos, outputs parecidos. Es lo que de verdad se necesita.

Concepto: un cambio irrelevante en la entrada no debería cambiar la decisión. Los LLMs son, según él, sorprendentemente malos en esto.

Acciones:

• Para medirlo, repite cada caso de tus evals con UUIDs distintos (u otro ruido irrelevante: orden de campos, espacios, nombres) y comprueba que las respuestas son equivalentes.
• No pidas determinismo al proveedor si lo que quieres es estabilidad: TypeSafe no descarta ofrecerlo, pero avisa de que cuesta inteligencia por dólar.

Tipos nuevos: Choice, Score y Noulli

La API de Jev expone tres primitivas que no existen en los lenguajes, pero que se traducen directamente a control de flujo:

• Noulli viene de Bernoulli: un booleano continuo, la probabilidad de que algo sea cierto. El umbral lo pones tú.
• Las entradas (estado, instrucciones, criterios) pueden ser objetos JSON estructurados. Si lo conviertes todo a texto y lo metes en un system message, estás pensando a la antigua.

Los system messages son variables globales: lo metes todo de golpe y esperas que el modelo acierte con cada instrucción.

Construir descomponiendo

Concepto: trocear el problema en las unidades semánticas más pequeñas posibles y hacer muchas preguntas independientes en vez de una grande. Cada decisión pequeña es medible y verificable por separado: machine learning sin el machine learning.

Acciones:

• En vez de preguntar «¿debería negarme aquí?», pregunta por separado por cada situación concreta que justificaría la negativa.
• Si el modelo falla porque no especificaste algo, es buena noticia: añades la pregunta o el umbral, lo conviertes en caso de test y queda resuelto para siempre. No se olvida por context rot.
• Pasa estado y criterios como datos estructurados, no como prosa en el prompt.

Casos de uso

1. Dark data: montañas de datos que las empresas nunca analizaron porque era caro. Según él, el mayor generador de ingresos.
2. Agentes de código: el mayor volumen hoy.
3. Tiempo real: todo producto que mejora quitando 10 ms, computer use incluido.
4. Verificarlo todo: observabilidad sobre llamadas a LLMs.
5. Software componible: hasta lenguajes de programación construidos sobre Jev.
6. Videojuegos y NPCs, su favorito personal.

Mi opinión

Me quedo con cuatro cosas:

1. Las tres estrellas polares. Es la forma más limpia que he visto de explicar por qué un modelo resuelve problemas dificilísimos y falla en cosas básicas.
2. Robustez antes que determinismo. No necesito que el modelo responda siempre exactamente igual; necesito que un detalle irrelevante no le haga cambiar de opinión. Y eso se puede probar ya: repetir cada caso de test cambiando solo el ruido y comprobar que la respuesta no cambia.
3. Una negativa en una API es un fallo, no una protección. En un chat, las normas del producto tienen sentido. En una pieza de infraestructura, una negativa inesperada rompe el programa que la llama. Esas normas tienen que vivir en el producto, no en el modelo que está debajo.
4. Muchas preguntas pequeñas mejor que una grande. Cada decisión por separado se puede medir, tiene su umbral y su test, y cuando falla sabes exactamente dónde. Sirve con cualquier modelo, no solo con Jev.