12 ideas que puedes construir con Jev

Doce ideas. Doce repos. Y una trampa que te voy a contar 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 nadie responde en la documentación.

¿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, solo devuelve decisiones tipadas con probabilidades. Cada una la presento como lo que es: una idea, un encaje y una lista de características.

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

Esa es la trampa. No la cuento para desinflarte. La cuento porque una idea con repo 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
• Por qué Jev encaja en cada una, con el criterio de cuándo un juicio barato gana a un prompt caro
• 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 y su README
• Las ocho ideas que me he dejado fuera de la lista y por qué

¿Cómo está montada cada una de las 12 ideas? ¶

Las doce siguen el mismo esquema, para que puedas saltar a la que te interese sin leer el resto.

Primero la idea, contada como si te la estuviera proponiendo en una cerveza. Después por qué Jev encaja ahí, que es donde está el criterio de verdad: no todo problema mejora metiendo un modelo de juicio, y voy a decirte cuál es la señal. Luego las características que le pondría si lo construyese, en forma de lista para que puedas tacharlas. Y al final el repositorio que ya existe, con lo que hace de verdad.

Un apunte antes de arrancar: he verificado cada repositorio contra 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. ¿Y si tu agente de navegador no mirase ni una sola captura de pantalla? ¶

La idea es un agente que navega la web sin visión. Nada de screenshots, nada de coordenadas, nada de pedirle al modelo que se invente un selector CSS. En su lugar, 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.

Jev encaja aquí porque navegar es, casi siempre, elegir. Elegir entre veinte elementos de una página no es una tarea de generación, es una tarea de clasificación con contexto. Y cuando la decisión es «cuál de estos veinte», un modelo que devuelve una distribución de probabilidades sobre opciones cerradas hace el trabajo en una fracción del tiempo y del coste que tarda un modelo grande en escribir un JSON con la respuesta.

Características que le pondría:

• Un snapshot atómico del DOM que numere los elementos interactivos y descarte lo que no lo es
• Operación y objetivo resueltos en una sola petición, no en dos round-trips encadenados
• Un conjunto cerrado de acciones: click, escribir texto, seleccionar, desplazar, esperar, terminar, o declararse bloqueado
• Referencias a nodos reales del DOM en lugar de selectores generados por el modelo
• Validación antes de actuar: 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 escribir algo en un input
• Un inspector local donde ver elementos detectados, probabilidades y acciones ejecutadas

Ya está en marcha en browser-use/jev-ultrafast, en Python, con JavaScript para los snapshots del DOM. Su ejemplo principal busca un vuelo de Zúrich a Londres en Google Flights y lo resuelve en 7.073 ms incluyendo llamadas al modelo, generación de texto y esperas del navegador, con una mejora del 25% en tiempo mediano. El propio 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.

Guía interactiva gratis

Doce ideas no sirven de nada si no has arrancado la primera

Un curso-juego de 17 paradas donde eliges proyecto, agente y presupuesto, con una parada entera sobre la ventana de contexto. Sales con una checklist a tu medida.

Entra en el curso gratis →

2. ¿Y si filtrases la salida de cada herramienta antes de que entre en contexto? ¶

La idea es un colador. Tu agente de código 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í para siempre, ocupando sitio y despistando al modelo. El colador se mete en medio: parte la salida en bloques pequeños y decide bloque a bloque si es relevante para lo que el agente está haciendo ahora mismo.

Jev encaja porque esta es la pregunta más repetitiva del mundo, hecha cien veces por segundo: «¿este trozo tiene que ver con la tarea?». Es binaria, es barata y admite lotes. Pagar un modelo grande por responderla sería absurdo; pagar treinta céntimos por millón de tokens de entrada, no.

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

Lo que llevaría dentro:

• Interceptar las herramientas que más ruido generan: leer archivos, ejecutar comandos de shell y buscar
• Trocear en bloques de unas 25 líneas y preguntar por todos a la vez
• Conservar lo relevante y también 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 que el agente pida el bloque completo cuando lo eche en falta
• Caché local de todo lo oculto y un digest determinista si no hay modelo pequeño para resumir
• Umbrales configurables, porque el punto de corte correcto depende de lo ruidoso que sea tu proyecto

Ya está en marcha en GhalebDweikat/winnow, un plugin de Claude Code escrito 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 bien la economía del asunto: «cien preguntas en una llamada en unos pocos cientos de milisegundos».

3. ¿Y si compactar la conversación fuese podar en vez de resumir? ¶

La idea ataca el mismo problema que la anterior 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 es no resumir nada y podar: conservas los mensajes tal cual y decides qué llamadas a herramientas siguen mereciendo su sitio.

Jev encaja porque la decisión «¿esta llamada y su resultado siguen importando?» es exactamente el tipo de juicio acotado que sabe hacer, y hay cientos por conversación. Y porque no se le pide que escriba: se le pide que señale. Lo que sobrevive sale intacto.

Características que le pondría:

• Mensajes de usuario y asistente nunca tocados, solo pares de llamada y resultado
• Tres salidas por cada 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 que se envía al juez cuando la conversación no cabe
• Troceado de las preguntas en varias peticiones concurrentes si se pasa del límite de contexto
• Fallo explícito ante una respuesta inválida, para que quien llama aplique su propio plan B

Ya está en marcha en 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 vez de dejarte tirado.

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

4. ¿Y si buscar un archivo fuese mandar cien exploradores a la vez? ¶

Aquí la idea es un find probabilístico. Le preguntas a un 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 en el que está, elige por dónde bajar y sigue hasta llegar a un archivo. Como son muchos y cada uno decide por su cuenta, los caminos más prometedores acaban recibiendo más exploradores. El resultado es un ranking por porcentaje de exploradores que terminaron ahí.

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

Características que le pondría:

• 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 quieres gastar en cada búsqueda
• Modo superficial (solo el primer nivel) y modo recursivo
• Ranking por porcentaje de exploradores con los demás resultados agrupados aparte
• Traza por explorador: elecciones, probabilidades, camino recorrido y destino final
• Registro de tokens y coste estimado de cada búsqueda

Ya está en marcha en ellipsis-dev/blink, 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: esto no es RAG sobre el contenido del código, es 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. ¿Y si la revisión de código fuesen cien juicios pequeños en vez de un prompt gigante? ¶

La idea es darle 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 etapa hace una pregunta minúscula: ¿este archivo parece arriesgado?, ¿esta región merece inspección?, ¿de qué tipo es el problema?, ¿cómo de grave es?

Jev encaja porque cada una de esas preguntas tiene respuesta tipada, y porque el umbral que decide si algo se reporta no debería vivir dentro de un prompt. Vive en tu código, en una constante que puedes cambiar, versionar y discutir en una reunión. Eso es lo que hace que la revisión sea repetible en vez de un oráculo de humor variable.

La lista de características:

• 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 del mecanismo 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 se encuentre
• Umbrales y políticas en código, fuera del alcance del modelo
• Salida en JSON y un panel local para explorar informes grandes

Ya está en marcha en devagrawal09/jev-review, en TypeScript sobre Node 24, con un panel que se sirve en local en el puerto 4317. Usa Choice para las decisiones de cada etapa y Score para cuantificar hallazgos. Me parece la mejor demostración de una idea que cuesta interiorizar: muchas decisiones pequeñas y baratas encadenadas pueden batir a una decisión grande y cara. Si quieres comparar este enfoque con una herramienta de revisión ya empaquetada, mira cómo resuelve el mismo problema la CLI de revisión de código de Alibaba.

6. ¿Y si tu agente no pudiese decir «he terminado» sin enseñar las pruebas? ¶

La idea es un guardia en la puerta de salida. Tu agente de código toca cuatro archivos, no ejecuta un solo test y te anuncia que la tarea está lista. Todos hemos estado ahí. El guardia 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.

Jev encaja aquí de una forma muy particular, y por eso esta idea es mi favorita de las doce. El modelo no bloquea nunca. Los hechos bloquean: si cambiaste un archivo después del último test verde, no pasas. Jev se reserva para lo ambiguo: «¿este mensaje está afirmando que el trabajo está terminado?», «¿este diff viola la regla de no escribir identificadores a fuego?». Sus respuestas son contexto y aviso, no 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.

Características que le pondrí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 escritos a fuego, fallos repetidos
• Tests, builds, lint y comprobación de tipos como comprobaciones válidas
• Veredictos reproducibles después, releyendo el registro
• Comportamiento completo sin conexión, con valores por defecto deterministas cuando el juez no está
• Instalación por proyecto o global

Ya está en marcha en 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. ¿Y si decidieses el modelo en cada turno en vez de al principio? ¶

La idea es un enrutador. 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». Eso es pagar 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.

Jev encaja porque la pregunta «¿este turno necesita el modelo caro?» se responde mirando una representación compacta del estado, no el contexto entero. El modelo que finalmente ejecuta sí recibe todo; el que decide solo necesita lo justo para clasificar. Y como decide en cada turno, incluidas las continuaciones después de una herramienta, corrige el rumbo cuando la tarea se complica a mitad.

Características que le pondría:

• Decisión por turno, no por sesión, incluidas las continuaciones posteriores a llamadas a herramientas
• Dos ejes independientes: nivel de capacidad y profundidad de razonamiento
• Estado de decisión acotado para el juez, contexto completo para el ejecutor
• El protocolo intacto: nada de 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 cuando se agota la cuota nativa, saltando a otros modelos disponibles
• Registro de cada decisión de enrutado para poder reproducirla

Ya está en marcha en 0xNatoshi/jev-codex-router, en Python, integrándose 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. ¿Y si tu agente tuviese una caja de herramientas de juicio en 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. En cambio, si tu agente tiene diez herramientas ya formuladas para las tareas que repite (verificar, cribar, seleccionar, reordenar, clasificar, decidir, comparar, extraer, revisar), las usa sin que tú intervengas.

Jev encaja porque estas primitivas son todas iguales por dentro: estado más preguntas tipadas, respuesta con probabilidades. Lo que cambia es la forma de la pregunta, y eso se puede empaquetar una vez y reutilizar 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 eso montas verificación de informes, detección de inyecciones, 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.

Lo que le pondría dentro:

• Una herramienta 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

Ya está en marcha en jkudish/jev-mcp, en TypeScript, con las diez herramientas listas. Y existe 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: es la vieja discusión de las APIs, ahora con agentes de por medio. Si vas a montar el servidor tú, conviene que sepas antes por qué MCP eliminó las sesiones y qué implica para tu servidor.

9. ¿Y si grep entendiese lo que busca? ¶

La idea es meter el juicio semántico en 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 que puedas 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 el sitio 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"

Características que le pondría:

• Subcomandos por tipo de decisión: predicado, elección entre opciones, 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 el juicio semántico de la política: el modelo detecta señales, tu código decide permitir, escalar o bloquear

Ya está en marcha en 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 esto en algo usable en CI. Un sí o no forzado en una zona gris es una bomba de relojería.

10. ¿Y si recorrer un grafo fuese elegir la siguiente arista con probabilidades? ¶

Toca navegación semántica sobre un grafo. Tienes una base de datos de grafos y una pregunta en lenguaje natural. La respuesta típica es 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 más probablemente 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 devuelve probabilidades, puedes acumularlas y comparar caminos enteros en vez de quedarte con el primero que parecía bueno.

Características que le pondría:

• 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

Ya está en marcha en 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. ¿Y si un modelo que no ve nada se pasase el primer nivel de Mario? ¶

La idea es un bucle de control en tiempo real. Coges un emulador de NES, sacas el estado del juego de la memoria RAM en vez de mandar capturas, lo conviertes en JSON y le preguntas al modelo qué botón conviene pulsar. Sin visión, sin generación, sin aprendizaje por refuerzo.

Jev encaja porque la latencia lo permite y porque el conjunto de acciones es minúsculo: siete macros de mando. Pero lo que de verdad demuestra 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 tenga que decidir muchas veces por segundo sobre un estado que tu código ya sabe describir.

Las características que no me saltaría:

• 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 cercanos, 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 de cada decisión en JSONL y modo sin interfaz para lanzar comparativas

Ya está en marcha en fhshaik/typesafe-mario, en Python 3.13, combinando 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 está 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. ¿Y si tu idea de producto pasase por un tribunal de diez preguntas? ¶

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 (¿hay un problema real?, ¿hay un cliente claro?, ¿hay demanda?, ¿se puede cobrar?, ¿puedes llegar a ese cliente?, ¿se diferencia?, ¿se puede construir?, ¿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.

El encaje está en que una evaluación subjetiva se convierte en una batería de microjuicios explícitos, y en que diez preguntas en paralelo no cuestan casi nada. 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.

Características que le pondría:

• 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

Ya está en marcha en 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.

¿Qué tienen en común 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 de código 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 filtro de datasets no toca las filas que acepta. El colador guarda lo oculto entero. Cuando el modelo señala en vez de redactar, no hay sitio donde se cuele una invención.

¿Qué ideas me he dejado fuera y por qué? ¶

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 ya 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. Decir que son «proyectos Jev» sería vender humo, y de eso ya hay bastante.

¿Por dónde empiezo si solo tengo 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) es la que 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 por copiar 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á todo 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