12 ideas que puedes construir con Jev

Doce ideas. Doce repositorios. Y una trampa que te cuento antes de empezar, para que no te pille por sorpresa.

Llevamos dos artículos con Jev. En el primero desmontamos qué es un System One Model y qué hay de marketing en el anuncio. En el segundo nos sentamos a usarlo: consola, clave de API, SDK y umbrales. Queda la pregunta que de verdad importa y que la documentación nunca responde.

¿Y esto para qué lo uso yo?

Aquí van doce respuestas. Doce cosas que puedes construir con un modelo que no escribe ni una palabra y solo devuelve decisiones tipadas con probabilidades.

Cada una termina con un enlace a un repositorio donde alguien ya la está construyendo.

Esa es la trampa. No la cuento para desinflarte, sino justo por lo contrario. Una idea con repositorio detrás es una idea validada. El hueco existe, hay código que leer y la distancia entre «se me ha ocurrido» y «esto funciona» se acorta muchísimo cuando puedes clonar el punto de partida.

En este artículo vas a encontrar:

• Doce ideas construibles ordenadas de lo más cercano a tu día a día a lo más raro
• El criterio para saber cuándo un juicio barato le gana a un prompt caro, caso por caso
• Las características concretas que tendría cada proyecto si lo montases tú
• El repositorio que ya lo cubre, con lo que hace de verdad según su código
• Las ocho ideas que se quedaron fuera de la lista y el motivo

Las doce ideas de un vistazo ¶

Antes de entrar en detalle, el mapa completo. Fíjate sobre todo en la columna del medio, porque lo que decide el modelo en cada caso es lo que te dice si la idea se sostiene.

He verificado los doce repositorios contra su código y su README. Las cifras de rendimiento que verás son las que declara cada proyecto, no benchmarks independientes, y lo marco cuando toca. En un ecosistema con semanas de vida, conviene separar una cifra declarada de una medida.

1. Un agente de navegador que no mira capturas de pantalla ¶

Un agente que navega la web a ciegas, en el buen sentido. Nada de screenshots, nada de coordenadas, nada de pedirle al modelo que se invente un selector CSS que luego falla. Conviertes la página en una tabla compacta de elementos interactivos numerados (botones, inputs, selects) y el modelo elige dos cosas a la vez: qué operación quiere hacer y sobre qué número.

Navegar es elegir, casi siempre. Elegir entre veinte elementos de una página no es generación de texto, es clasificación con contexto. Y cuando la decisión se reduce a «cuál de estos veinte», un modelo que devuelve una distribución de probabilidades sobre opciones cerradas resuelve en una fracción del tiempo y del dinero que tarda un modelo grande en escribir el JSON con la respuesta.

Si lo montas tú, no dejaría fuera ninguna de estas piezas:

• Un snapshot atómico del DOM que numere los elementos interactivos y descarte el resto
• Operación y objetivo resueltos en una sola petición, no en dos round-trips encadenados
• Un conjunto cerrado de acciones: click, escribir, seleccionar, desplazar, esperar, terminar o declararse bloqueado
• Referencias a nodos reales del DOM en lugar de selectores generados por el modelo
• Validación previa a cada acción: que el elemento siga ahí, que no esté tapado, que la página no haya cambiado
• Delegación de la generación de texto a otro modelo, solo cuando toca rellenar un input
• Un inspector local para ver elementos detectados, probabilidades y acciones ejecutadas

Todo eso está construido y se llama browser-use/jev-ultrafast, en Python con JavaScript para los snapshots. Su ejemplo busca un vuelo de Zúrich a Londres en Google Flights y lo resuelve en 7.073 ms contando llamadas al modelo, generación de texto y esperas del navegador, con una mejora del 25% en tiempo mediano. El repositorio avisa de que eso son «tres repeticiones de una tarea en un perfil de navegador, no un benchmark general de fiabilidad». Me gusta que lo diga.

Curso gratis · paso a paso

Antes de construir nada, dale método a tu agente

El ciclo completo de Spec Driven Development con OpenSpec sobre un proyecto de juguete: proposal, spec, diseño, tareas y archivar. Lo ves funcionar entero antes de coger tú el volante.

Abrir el curso gratis →

2. Un filtro que decide qué entra en el contexto de tu agente ¶

Aquí la propuesta es un colador. Tu agente ejecuta un grep que devuelve 800 líneas, lee un archivo de 2.000 y lanza un comando que escupe medio log. Todo eso entra en contexto tal cual y se queda ahí ocupando sitio y despistando al modelo durante el resto de la sesión. El colador se mete en medio: trocea la salida en bloques pequeños y decide bloque a bloque si tiene que ver con lo que el agente está haciendo ahora mismo.

¿Por qué un modelo de juicio para esto? Porque es la pregunta más repetitiva del mundo, hecha cien veces por segundo. Es binaria, es barata y admite lotes. Pagar un modelo frontera por responderla sería tirar el dinero.

🔑 El punto clave: filtrar no es borrar. Lo que ocultas se guarda entero y el agente lo recupera cuando lo necesita. Un filtro que destruye información deja de ser un filtro y pasa a ser un bug.

Su hoja de características tendría estas líneas:

• Intercepción de las herramientas que más ruido generan: leer archivos, ejecutar comandos y buscar
• Troceado en bloques de unas 25 líneas y una única llamada para preguntar por todos
• Conservación de lo relevante y también de lo dudoso: solo se oculta lo que el modelo descarta con claridad
• Un stub de tres líneas en lugar del bloque oculto: qué se escondió, un resumen mínimo y una clave
• Una herramienta de recuperación para pedir el bloque completo más tarde
• Caché local de todo lo oculto, con digest determinista si no hay modelo pequeño que resuma
• Umbrales configurables, porque el punto de corte depende de lo ruidoso que sea tu proyecto

Quien lo tiene resuelto es GhalebDweikat/winnow, un plugin de Claude Code en TypeScript con un sidecar en Python. Usa Jev como juez principal y cae a Claude Haiku 4.5 cuando no está disponible. Su README resume la economía del asunto en una frase: «cien preguntas en una llamada en unos pocos cientos de milisegundos».

3. Compactar la conversación podando en lugar de resumiendo ¶

Mismo problema que la anterior, atacado por el otro extremo. Cuando la ventana de contexto se llena, tu agente resume la conversación y sigue. Ese resumen es una reescritura, y toda reescritura pierde cosas: la ruta exacta de un archivo, el mensaje literal de un error, la restricción que dijiste en el minuto tres. La alternativa consiste en no resumir nada: conservas los mensajes tal cual y decides qué llamadas a herramientas siguen mereciendo su sitio.

«¿Esta llamada y su resultado siguen importando?» es justo el tipo de juicio acotado que un System One resuelve bien, y hay cientos por conversación. Lo importante es que al modelo no se le pide que escriba, se le pide que señale. Lo que sobrevive sale intacto.

Piezas del proyecto, tal y como yo lo dibujaría:

• Mensajes de usuario y asistente nunca tocados, solo pares de llamada y resultado
• Tres salidas por par: conservar entero, conservar la llamada y truncar el resultado, o eliminar ambos
• Cero reescritura de lo que se conserva
• Protección automática de los mensajes recientes, que casi siempre siguen siendo relevantes
• Reducción progresiva del estado enviado cuando la conversación no cabe
• Troceado de las preguntas en varias peticiones concurrentes si se pasa del límite
• Fallo explícito ante una respuesta inválida, para que quien llama aplique su propio plan B

Esto ya existe con el nombre de tamaratran/fast-jev-compaction, en TypeScript, distribuido a la vez como paquete npm y como plugin de Claude Code. Mantiene el estado por debajo de los 25.000 tokens y trocea cuando la petición pasaría de 30.000. Si la poda no libera suficiente, vuelve al resumen clásico en lugar de dejarte tirado.

Las ideas 2 y 3 se parecen lo justo para confundirse, así que conviene separarlas:

4. Buscar archivos en un repositorio con lenguaje natural ¶

Imagina un find probabilístico. Le preguntas al repositorio «¿dónde se gestiona la autenticación?» y, en vez de indexar el contenido entero, sueltas exploradores en la raíz. Cada uno mira los nombres de archivos y carpetas del nivel donde está, elige por dónde bajar y sigue hasta llegar a un archivo. Como van muchos y cada uno decide por su cuenta, los caminos prometedores acaban recibiendo más exploradores. El resultado es un ranking por porcentaje de exploradores que terminaron ahí.

El encaje está en el volumen. Puntuar nombres contra una consulta es semántica pura y de grano finísimo, y un árbol de directorios grande genera miles de comparaciones triviales. Ese es exactamente el perfil de carga donde un modelo de juicio barato se come a cualquier alternativa.

Funciones que tendría la herramienta:

• Consulta en lenguaje natural y un directorio raíz, sin índice previo ni base de datos vectorial
• Puntuación semántica de nombres de archivos y carpetas en cada nivel
• Número de exploradores configurable, para regular cuánto gastas en cada búsqueda
• Modo superficial (solo el primer nivel) y modo recursivo
• Ranking por porcentaje, con los resultados de cola agrupados aparte
• Traza por explorador: elecciones, probabilidades, camino recorrido y destino
• Registro de tokens y coste estimado de cada búsqueda

Lo puedes clonar hoy desde ellipsis-dev/blink, escrito en TypeScript sobre Bun. Su README pone el precio encima de la mesa: 0,042 dólares por millón de tokens de entrada, con los de salida gratis. Y conviene entender qué hace y qué no, porque esto no es RAG sobre el contenido del código sino navegación por la semántica de los nombres. Si tu repositorio tiene carpetas llamadas utils2 y misc_final, ningún explorador te va a salvar.

5. Revisión de código encadenando juicios pequeños ¶

Le damos la vuelta a cómo se revisa un pull request con IA. En lugar de meter el diff entero en un modelo grande y pedirle «revísame esto», montas una tubería de etapas donde cada una hace una pregunta minúscula: si este archivo parece arriesgado, si esta región merece inspección, de qué tipo es el problema, cuánto pesa.

Dos razones para meter aquí un modelo de juicio. La primera es que cada una de esas preguntas tiene respuesta tipada. La segunda, más importante, es que el umbral que decide si algo se reporta deja de vivir dentro de un prompt y pasa a vivir en tu código, en una constante que puedes cambiar, versionar y discutir en una reunión. Eso convierte la revisión en algo repetible, no en un oráculo de humor variable.

Lo que pediría a un proyecto así:

• Dos modos: revisar solo el diff actual o escanear una base de código entera
• Etapas encadenadas de riesgo, perfilado de archivos, selección de evidencia, clasificación y severidad
• Cinco ejes de análisis: corrección, seguridad, fiabilidad, compatibilidad y cobertura de tests
• Los tests cambiados o relacionados usados como evidencia, no como decoración
• Enrutado condicional hacia distintos tipos de revisor según lo que aparezca
• Umbrales y políticas en código, fuera del alcance del modelo
• Salida en JSON y un panel local para explorar informes grandes

El que lo ha construido es devagrawal09/jev-review, en TypeScript sobre Node 24, con un panel que se sirve en 127.0.0.1:4317. Usa Choice para las decisiones de cada etapa y Score para cuantificar hallazgos. Si quieres comparar este enfoque con una herramienta ya empaquetada, mira cómo resuelve lo mismo la CLI de revisión de código de Alibaba. Cuesta interiorizarlo, pero muchas decisiones pequeñas y baratas encadenadas pueden batir a una decisión grande y cara.

6. Un guardia que no deja decir «he terminado» sin pruebas ¶

Un portero en la puerta de salida. Tu agente toca cuatro archivos, no ejecuta un solo test y te anuncia que la tarea está lista. Todos hemos estado ahí. El portero lleva un registro de lo que ha pasado de verdad en la sesión (qué archivos cambiaron, qué comandos se ejecutaron, con qué código de salida) y, cuando el agente intenta declarar el trabajo terminado, comprueba si existe evidencia que lo respalde.

El reparto de papeles es lo que hace especial a esta idea, y por eso es mi favorita de las doce. El modelo no bloquea nunca. Bloquean los hechos: si cambiaste un archivo después del último test verde, no pasas. El juicio semántico se reserva para lo ambiguo, del tipo «¿este mensaje está afirmando que el trabajo está terminado?» o «¿este diff viola la regla de no escribir identificadores a fuego?». Sus respuestas son contexto y aviso, jamás veredicto.

🛡️ Los hechos bloquean. Los juicios aconsejan. Si inviertes esa relación tienes un portero probabilístico, que es otra forma de decir un portero que a veces te deja pasar sin entrada.

Con qué lo dotaría:

• Un registro por sesión, solo de adición, con rutas y resultados pero nunca el contenido de los archivos
• Hooks normalizados para engancharse a más de un agente sin duplicar la lógica
• Detección determinista de patrones destructivos: tests borrados, secretos a fuego, fallos repetidos
• Tests, builds, lint y comprobación de tipos como comprobaciones válidas
• Veredictos reproducibles después, releyendo el registro
• Funcionamiento completo sin conexión, con valores por defecto deterministas
• Instalación por proyecto o global

Su nombre es qkal/Canny, en TypeScript, con cero dependencias en producción y adaptadores para Claude Code y el CLI de Codex. Su README lo resume en una línea que me he apuntado: «Facts go to code. Judgments go to Jev. Only facts can block».

Tu IA puede mentirte

Si los hechos son los que bloquean, necesitas más hechos

Vas a ver métodos concretos para verificar lo que entregan los agentes: ciclo anticaos, pruebas en navegador, casos Gherkin y revisión adversarial entre modelos.

Ver el método entero →

Masterclass en directo · Acceso con suscripción Web Reactiva Premium

7. Elegir modelo y nivel de razonamiento en cada turno ¶

Hablemos de enrutado. Ahora mismo eliges el modelo cuando abres la sesión y ahí se queda, tanto para «renombra esta variable» como para «rediseña la capa de persistencia». Estás pagando el precio del caso peor en todos los casos. Un enrutador pregunta antes de cada llamada qué capacidad hace falta y cuánto razonamiento merece la pena, y ajusta.

La pregunta «¿este turno necesita el modelo caro?» se responde mirando una representación compacta del estado, no el contexto entero. El modelo que ejecuta sí recibe todo; el que decide necesita mucho menos para clasificar bien. Y como decide en cada turno, incluidas las continuaciones posteriores a una herramienta, corrige el rumbo cuando la tarea se complica a mitad de camino.

El mínimo viable incluiría:

• Decisión por turno, no por sesión, con las continuaciones tras llamadas a herramientas incluidas
• Dos ejes independientes: nivel de capacidad y profundidad de razonamiento
• Estado acotado para el juez, contexto completo para el ejecutor
• El protocolo intacto, sin transformar llamadas a herramientas ni trazas de razonamiento
• Comportamiento fail-open: si el juez falla, la conversación sigue con un valor por defecto
• Interruptor local de emergencia para desactivarlo sin tocar la configuración
• Plan alternativo al agotar la cuota nativa, saltando a otros modelos disponibles
• Registro de cada decisión de enrutado para poder reproducirla

Funcionando lo tienes en 0xNatoshi/jev-codex-router, en Python, integrado con Codex Router sin hacer un fork. Declara una simulación histórica con «≈ −60 % frente a Astra completo en 237 turnos bajo la política antigua», y en la misma frase avisa de que eso no equivale a ahorro medido de cuota real ni demuestra nada sobre la política actual. Cuando un proyecto se desmiente a sí mismo en su propio README, yo le hago más caso, no menos.

8. Una caja de herramientas de juicio servida por MCP ¶

Esta idea nace de una pereza legítima: dejar de escribir integración. Si cada vez que quieres usar un modelo de juicio tienes que montar el cliente, formular las preguntas y parsear la respuesta, no lo vas a usar nunca. En cambio, si tu agente tiene diez herramientas ya formuladas para las tareas que repite (verificar, cribar, seleccionar, reordenar, clasificar, decidir, comparar, extraer, revisar), tirará de ellas sin que tú intervengas.

Todas esas primitivas son iguales por dentro: estado más preguntas tipadas, respuesta con probabilidades. Lo único que cambia es la forma de la pregunta, y eso se empaqueta una vez y se reutiliza siempre.

{
  "tool": "jev_screen",
  "arguments": {
    "content": "<el HTML que acabas de descargar>",
    "task": "Resumir la documentación de la API de pagos"
  }
}

Esa llamada responde a la vez si el contenido es relevante para la tarea y si huele a inyección de prompt, antes de que una sola línea entre en el contexto de tu agente. Con ese catálogo montas verificación de informes, reordenado de resultados de búsqueda, clasificación de issues, extracción de fechas y precios o una puerta de calidad antes de dar una tarea por cerrada.

Las herramientas que no faltarían en la caja:

• Una por tarea recurrente, con nombres que el agente entienda sin documentación
• Verificación de afirmaciones contra evidencias, con veredicto y confianza
• Criba de contenido externo antes de que entre en contexto
• Selección y reordenado de candidatos contra una consulta
• Clasificación por lotes contra un catálogo compartido
• Extracción con expresiones regulares más verificación semántica del valor encontrado
• Una puerta final que combine revisión de parche y comprobación de afirmaciones de finalización

Con nombre y apellidos: jkudish/jev-mcp, en TypeScript, con las diez herramientas listas. Existe además el enfoque contrario en itsmostafa/typesafe-mcp, un binario de Go que expone una única herramienta genérica, evaluate, y deja que el agente decida cuándo y cómo usarla. Diez especializadas o una general: la vieja discusión de las APIs, ahora con agentes de por medio. Si vas a montar el servidor tú, conviene saber antes por qué MCP eliminó las sesiones y qué implica para tu servidor.

9. Grep semántico para la terminal y los scripts de CI ¶

Juicio semántico dentro de la shell. No en un servicio, no en una librería, no detrás de un SDK: en una tubería, con código de salida, para encadenarlo con lo que ya usas. Un comando que evalúa un predicado sobre un texto y devuelve 0 o 1. Otro que elige entre opciones. Otro que filtra un JSONL línea a línea.

El encaje es doble. La shell es donde más trabajo repetitivo y de grano pequeño se acumula, y los códigos de salida se llevan de maravilla con las respuestas tipadas. Lo bonito no es que funcione, es que se comporta como un programa de Unix y no como un chatbot.

# Filtra un stream de issues conservando solo las que parecen bugs de seguridad
cat issues.jsonl | semdecide filter --field body \
  "describe una vulnerabilidad de seguridad explotable" > security.jsonl

# Y en CI, una puerta con código de salida
semdecide is "el mensaje de commit explica el porqué del cambio" \
  --text "$(git log -1 --pretty=%B)" || echo "Mejora el mensaje, anda"

Lo que debería traer de serie:

• Subcomandos por tipo de decisión: predicado, elección, puntuación con rúbrica y filtrado
• Códigos de salida pensados para la shell, con uno propio para la incertidumbre
• Entrada desde stdin, texto directo o archivo
• Orden de los registros preservado al filtrar JSONL
• Metadatos del juicio añadidos al registro, o el registro original intacto, a elección
• Validación de tamaño, codificación y formato antes de gastar una llamada
• Una receta de seguridad que separe juicio y política: el modelo detecta señales, tu código decide permitir, escalar o bloquear

Esto lo resolvió sharziki/semdecide, en Python 3.10 o superior, con cinco subcomandos (is, choose, score, filter, guard) y cinco códigos de salida: afirmativo, negativo, entrada inválida, resultado incierto y fallo del proveedor. Ese tercer estado, el de «no lo tengo claro», es el que convierte la herramienta en algo usable en CI. Un sí o no forzado en una zona gris es una bomba de relojería.

10. Navegar un grafo de Neo4j salto a salto ¶

Tienes una base de datos de grafos y una pregunta en lenguaje natural. La respuesta típica consiste en volcar medio subgrafo en un modelo grande y rezar. La alternativa es caminar: te plantas en un nodo, miras sus relaciones salientes y preguntas cuál lleva con más probabilidad a tu objetivo. Un salto, una pregunta.

Ese salto es un Choice de manual, y en la misma llamada puedes preguntar además si ya has llegado. Dos preguntas, una petición, un salto. Y como lo que vuelve son probabilidades, puedes acumularlas y comparar caminos enteros en lugar de quedarte con el primero que pintaba bien.

Su lista de características:

• Cada relación saliente convertida en una opción, sin esquema del grafo escrito a mano
• La pregunta de «objetivo alcanzado» viajando en la misma petición que la elección
• Búsqueda en haz para mantener vivos varios caminos prometedores a la vez
• Logaritmos de probabilidad acumulados para puntuar rutas completas sin sesgo de longitud
• Tres tipos de objetivo: descripción libre, nodo destino concreto o patrón de relaciones
• Descubrimiento automático de etiquetas, tipos de relación, propiedades e índices
• Límite de relaciones por nodo, para que un supernodo no se coma el contexto
• Búsqueda del nodo inicial por coincidencia exacta, texto completo o vectores

Lo encontrarás como jexp/neo4jev, en Python 3.12, con librería reutilizable, notebooks y una aplicación en Streamlit que dibuja las rutas y muestra las probabilidades salto a salto. Esa visualización es media gracia del proyecto, porque ver por qué el camino se fue por donde se fue explica más que el propio resultado.

11. Bucles de control en tiempo real sin visión ¶

Un emulador de NES, el estado del juego sacado de la memoria RAM en vez de capturas, convertido a JSON, y un modelo decidiendo qué botón conviene pulsar. Sin visión, sin generación, sin aprendizaje por refuerzo. Mario, vaya.

La latencia lo permite y el conjunto de acciones es minúsculo: siete macros de mando. Pero lo que de verdad demuestra el experimento es el patrón que se repite en toda esta lista: estado estructurado, juicio rápido, acción, nuevo estado. Mario es la excusa. El patrón sirve para cualquier sistema que decida muchas veces por segundo sobre un estado que tu código ya sabe describir.

Lo que no puede faltar dentro:

• Extracción del estado desde la RAM y la telemetría del emulador, nunca desde píxeles
• JSON con posición, velocidad, si está en el suelo, fase del salto, enemigos, huecos y obstáculos
• Un conjunto cerrado de macros de mando en lugar de pulsaciones sueltas
• Varios juicios por decisión: la acción principal, la conveniencia del salto y el nivel de peligro
• La aritmética de tiempos en el código, jamás delegada al modelo
• Medición del retraso entre observar y actuar, guardada en cada registro de decisión
• Registro en JSONL y modo sin interfaz para lanzar comparativas

Hay dos proyectos que lo demuestran. El primero es fhshaik/typesafe-mario, en Python 3.13, que combina Choice para la acción, Noul para el salto y Score para el peligro en cada decisión. Y si Mario te parece poco serio, la misma arquitectura late en RomanSlack/jev-drone: un cuadricóptero simulado en MuJoCo con cuatro capas a distinta frecuencia, control a 500 Hz, seguridad a 50 Hz, percepción a 15 Hz y juicio táctico a unos 2,5 Hz. El modelo elige la maniobra. El código conserva el derecho de veto. Ese reparto es la parte que merece la pena copiar.

12. Evaluar una idea de producto con diez microjuicios ¶

Cierro con un evaluador de ideas que no te escribe una crítica. Le cuentas tu idea de producto y, en vez de devolverte tres párrafos amables, la descompone en preguntas concretas (si hay un problema real, si hay un cliente claro, si hay demanda, si se puede cobrar, si puedes llegar a ese cliente, si se diferencia, si se puede construir, si se comparte sola) y puntúa cada una por separado. Tu código pondera y agrega. El veredicto sale de la aritmética, no de la retórica.

Diez preguntas en paralelo no cuestan casi nada, y una evaluación subjetiva se convierte así en una batería de microjuicios explícitos. Pero el motivo de fondo es otro: un modelo generativo te dirá que tu idea es interesante. Un modelo que solo puntúa no tiene forma de ser amable contigo.

El armazón de un evaluador que sirva para algo:

• Todas las preguntas en una sola petición, con respuestas independientes
• Criterios extra según el objetivo: ganar dinero, proyecto abierto o pura diversión
• Pesos distintos por criterio, definidos y versionados en el código
• Una comprobación aparte de si la idea se entiende, que pide más detalle en vez de fingir una evaluación
• Veredicto por umbrales, no por narrativa
• Respuestas en crudo a la vista: probabilidades, confianza, latencia y tokens consumidos
• Modo simulado para desarrollar la interfaz sin gastar llamadas
• Histórico local opcional y desactivable

Y sí, ya está construido: monteduro/killmyidea, en TypeScript con Vite y funciones serverless. Puntúa ocho dimensiones de 0 a 4, las multiplica por 25 y las pondera. Por debajo de 50 es KILL, entre 50 y 64 es FIX, y a partir de 65 es SHIP. Es el proyecto más pequeño de los doce y probablemente el que puedes replicar en un fin de semana.

Lo que comparten las doce ideas ¶

Cuatro cosas, y aparecen en casi todas.

La primera: el estado lo construye tu código, no el modelo. Mario saca la posición de la RAM, el agente de navegador numera el DOM, el revisor trocea el diff. Ninguno le pide al modelo que interprete píxeles o prosa cuando puede darle una estructura.

La segunda: el modelo decide, el código manda. El dron tiene veto sobre la maniobra. El guardia de las pruebas no deja bloquear a las probabilidades. El enrutador sigue funcionando si el juez se cae. En todos los proyectos que aguantan producción, el juicio semántico es una entrada más de un sistema determinista.

La tercera: muchas preguntas en una llamada. El colador de contexto pregunta por cien bloques a la vez, el evaluador de ideas lanza diez criterios juntos, el navegador de grafos mete elección y comprobación de objetivo en la misma petición. La latencia por petición es el recurso caro, no el modelo.

Y la cuarta, la que más cuesta aceptar: lo que sobrevive no se reescribe. La poda de historial conserva los mensajes literales. El colador guarda lo oculto entero. Cuando el modelo señala en vez de redactar, no queda ningún hueco por donde se cuele una invención.

Las ocho ideas que se quedaron fuera ¶

Partí de veinte candidatas y me quedé con doce. Las ocho descartadas tienen su motivo, y alguna te puede interesar más que las que entraron.

Fuera por ser variantes de algo que ya estaba: itsmostafa/typesafe-mcp, el MCP minimalista que cito en la idea 8, y RomanSlack/jev-drone, el mismo patrón que Mario con mejor ingeniería y la lista de frecuencias más bonita del ecosistema.

Fuera por demasiado específicas para un post general: AkashPriyadarshii/jev-curate, un filtro de datasets en Rust que declara más de 1.500 filas por segundo y 4,20 dólares por cada 100 millones de tokens (cifras de la casa, sin verificación independiente); jarrodwatts/jev-trader, un bot de creación de mercado que decide comprar o vender en cada bloque de Monad, cada 300 ms; y emrickgarrett/OneVOneJev, un shooter en el navegador donde peleas contra el modelo y el servidor le manda el estado unas nueve veces por segundo.

Y fuera por una razón distinta: vercel-labs/json-render, lahfir/agent-desktop y irfndi/prism-liquidity-agent son proyectos excelentes que no están construidos alrededor de Jev. En el primero es una integración experimental, en el segundo es opcional y en el tercero ni siquiera aparece. Llamarlos «proyectos Jev» sería vender humo, y de eso ya hay bastante.

Por dónde empezar si solo tienes un fin de semana ¶

Por la idea más pequeña que resuelva un problema que tengas tú de verdad.

Si tu dolor es el contexto, el colador (idea 2) es un plugin y lo notas el primer día. Si tu dolor es que tu agente miente sobre lo que ha hecho, el guardia de las pruebas (idea 6) tiene el diseño más limpio para copiar. Si nunca has metido un juicio tipado en nada, empieza por los comandos de shell (idea 9): una tubería, un código de salida y ya tienes la sensación en los dedos.

Y si lo que quieres es construir algo tuyo de cero, el evaluador de ideas (idea 12) es el patrón mínimo completo: preguntas en paralelo, pesos en tu código, veredicto por umbrales. Cambia los ocho criterios por los que te importen a ti y tienes un producto distinto con la misma arquitectura.

Lo único que no te recomiendo es empezar clonando un repositorio entero. Clona, lee cómo formulan las preguntas, y quédate con eso. La parte difícil de todos estos proyectos no es el código que llama a la API: son las preguntas.

Y si al leer las doce has pensado que esto se parece mucho a montar un arnés alrededor del modelo, es porque lo es. La ruta completa está en cómo ser Harness Engineer en siete preguntas.

TL;DR ¶

• 🧭 Las doce ideas comparten arquitectura: tu código construye el estado y manda, el modelo solo juzga sobre opciones cerradas
• 🧹 Lo más rentable a corto plazo es la gestión de contexto: filtrar antes de que entre (Winnow) o podar sin resumir (fast-jev-compaction)
• 🛡️ El mejor diseño de la lista es el de Canny: los hechos bloquean, los juicios aconsejan, y nunca al revés
• ⚡ Los bucles en tiempo real ya funcionan: Mario desde la RAM, un dron a 2,5 Hz de juicio táctico y un agente de navegador sin capturas
• 💸 Casi todas las cifras de rendimiento que verás son de los propios repositorios, no benchmarks independientes: trátalas como indicios

Preguntas frecuentes sobre qué construir con Jev ¶

¿Necesito saber programar con IA para construir alguna de estas ideas?
No hace falta experiencia previa con modelos generativos. Jev se usa mandando un estado y una lista de preguntas tipadas, y la respuesta son probabilidades. Se parece más a validar un formulario que a escribir prompts. Si sabes llamar a una API REST y manejar umbrales, tienes lo necesario.

¿Cuál de las doce ideas es la más fácil de replicar?
El evaluador de ideas (killmyidea) es el proyecto más pequeño: una sola petición con diez preguntas en paralelo, pesos en el código y un veredicto por umbrales. Es replicable en un fin de semana y su arquitectura sirve para cualquier evaluación multicriterio.

¿Se puede usar Jev sin escribir integración propia?
Sí. Hay dos caminos por MCP: jev-mcp expone diez herramientas ya especializadas (verificar, cribar, reordenar, clasificar, revisar) y typesafe-mcp expone una sola herramienta genérica llamada evaluate. Para la shell, semdecide da subcomandos con códigos de salida usables en CI.

¿Qué pasa si Jev falla o devuelve algo inválido?
Depende de cómo lo montes, y ese es el punto. Los proyectos serios de la lista tienen plan B explícito: el enrutador de Codex sigue con un valor por defecto (fail-open), el colador de contexto cae a un modelo pequeño, el guardia de pruebas usa valores deterministas sin conexión y la poda de historial falla de forma explícita para que quien llama aplique su fallback.

¿Merece la pena meter un modelo de juicio en un agente de código?
Merece la pena donde haya muchas decisiones pequeñas y repetidas: filtrar salidas, elegir archivos, clasificar hallazgos, enrutar turnos. No merece la pena para decisiones únicas y complejas donde el coste del modelo grande es irrelevante frente al valor de acertar.

¿Jev sustituye a un LLM en estos proyectos?
En ninguno de los doce lo sustituye del todo. El agente de navegador delega la generación de texto a otro modelo, el colador de contexto usa un modelo pequeño para resumir y el enrutador elige entre modelos grandes. Jev ocupa el hueco de las decisiones, no el de la redacción.

¿Cómo evito que un filtro semántico me esconda información importante?
Con dos reglas que aplican los proyectos que funcionan: conservar también lo dudoso (solo se oculta lo que se descarta con claridad) y guardar entero lo oculto con una forma de recuperarlo. Un filtro que borra de verdad no es un filtro, es pérdida de datos.

¿Sirve esto para algo fuera del mundo de los agentes de código?
Sí. La navegación de grafos, el filtrado de datasets, el evaluador de ideas de producto y los bucles de control en tiempo real no tienen nada que ver con agentes de código. El patrón común es tener muchas decisiones acotadas sobre un estado que tu código ya sabe describir.

¿Son fiables las cifras de rendimiento de estos repositorios?
Son declaraciones de cada proyecto, no benchmarks independientes, y varios lo advierten en su propio README. El agente de navegador aclara que sus mediciones son tres repeticiones de una tarea, y el enrutador de Codex dice que su ahorro simulado no equivale a ahorro real medido.

¿Por dónde empiezo si nunca he llamado a Jev?
Por la consola y el playground antes que por el código, y luego por una primera llamada con el SDK. Está explicado paso a paso en la guía de cómo empezar con Jev y TypeSafe, incluidos los umbrales de confianza y los límites que conviene conocer.

Fuentes ¶

• browser-use/jev-ultrafast — agente de navegador con espacio de acciones indexado
• GhalebDweikat/winnow — filtro de contexto para Claude Code
• tamaratran/fast-jev-compaction — compactación sin resumen generativo
• ellipsis-dev/blink — búsqueda de archivos con exploradores probabilísticos
• devagrawal09/jev-review — tubería de revisión de código por etapas
• qkal/Canny — guardia de evidencia para agentes de código
• 0xNatoshi/jev-codex-router — enrutado de modelo y razonamiento por turno
• jkudish/jev-mcp — diez herramientas MCP de juicio tipado
• itsmostafa/typesafe-mcp — MCP minimalista con una herramienta evaluate
• sharziki/semdecide — decisiones semánticas en la shell
• jexp/neo4jev — navegación de grafos Neo4j con búsqueda en haz
• fhshaik/typesafe-mario — control de NES desde estado estructurado
• RomanSlack/jev-drone — dron simulado en MuJoCo con juicio táctico
• monteduro/killmyidea — evaluación de ideas por microjuicios ponderados
• Documentación de TypeSafe — referencia de Choice, Score y Noul

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter