ExpertsFMJev for beginners: how to use it and what to build
How I AI · September 28, 2026
5 Selected Lessons:
framework · 2 case · 2 heuristic · 1
Match model type to task type: decision models vs generative models
Source
How I AI — Jev for beginners: how to use it and what to build (September 28, 2026) · at 0:00 ▸ · at 2:47 ▸
When this applies
when choosing a tool for any job — ask whether the task fundamentally requires generating new content or merely requires making a constrained decision from a known set of outcomes
The takeaway
Decompose a workflow into 'generate new content' steps and 'pick from known options' steps, and route each to a tool built for that narrower job.
Why it works
Standard generative models pay for unconstrained output tokens and do extra work producing free text, while decision models only need to select among predefined outputs, so they can be architected to be far cheaper and faster.
One level up
Cost and speed gains often come from reducing the shape of the problem, not just picking a 'smarter' model.
Where it stops holding
This stops working when the task genuinely requires open-ended generation or nuanced synthesis that can't be reduced to choice/score/boolean outputs.
Detail
procedure:
- Identify if the task needs generated content (text, code) or a decision (choice/score/yes-no)
- Route generation tasks to standard LLMs or 'big brain' models
- Route decision/classification/routing tasks to a fast cheap decision model like JEV
benchmarks: {"jev_cost":"4 cents per million input tokens, no output token charge"}
rationale: Decision models are architected to output almost nothing, so they can be made dramatically cheaper and faster than generative LLMs.
In their words
You know, standard LMs, chatbots, where you want text in, you want text out, coding where you want, you know, code to be produced. And so it's it's great for things where you need stuff generated, but JEV is really great for making decisions.
Tiered pipeline: cheap classifier → cheap labeler → brainy analyzer
Source
How I AI — Jev for beginners: how to use it and what to build (September 28, 2026) · at 13:31 ▸
When this applies
when facing a dataset too large/nuanced for an expensive model to process directly, but containing structure that could be extracted cheaply first
The takeaway
Build a funnel: use the cheapest capable tool to reduce scale and structure a problem, then apply the most capable (expensive) tool only to the reduced, structured output.
Why it works
Running an expensive, high-reasoning model directly over huge unstructured data is costly and often fails to surface structure; pre-processing with a cheap, fast classifier to cluster/tag/filter the data first dramatically shrinks what the expensive model has to reason over, making the whole pipeline both cheaper and more accurate.
One level up
Expensive intelligence should be reserved for synthesis, not spent on volume reduction — let cheap tools do the triage.
Where it stops holding
This stops working when the raw data has no decomposable structure a cheap classifier can meaningfully tag, or when the classification step itself is the bottleneck (too ambiguous for a simple choice/score).
Detail
procedure:
- Use JEV to do pairwise comparisons / classification / clustering of raw unstructured signals
- Use a cheap generative model (e.g., Gemini Flash-lite) to label the resulting clusters
- Feed the structured, labeled clusters to a 'big brain' model (Astra) for analysis, strategy, and insight extraction
- Use a generative model (Soul/Luna) only where new content generation is needed
benchmarks: {"scale":"~1,100 raw signals, 200,000+ classification/pairwise groupings","cost":"about $4 on the JEV side for this step"}
rationale: Previously this was attempted by brute-forcing with expensive frontier models alone and cost thousands to tens of thousands of dollars with poor results; splitting the work by capability made it both cheap and effective.
In their words
I've spent thousands of dollars, if not tens of thousands of dollars trying to prototype this. It's just hard. And I think I cracked this baby with Jev.
Real-time performant search/classification requires batching and score-promotion architecture
Source
How I AI — Jev for beginners: how to use it and what to build (September 28, 2026) · at 18:26 ▸
When this applies
when trying to make any system feel instantaneous at scale — recognize that raw speed of a single component isn't enough; you need an architecture around it
The takeaway
A fast primitive still needs a surrounding architecture (batching, filtering, score-ranking) to deliver a real-time user experience at scale.
Why it works
Even a very fast per-call model becomes slow if called naively against every record sequentially; batching calls and promoting only high-scoring results preserves apparent real-time responsiveness.
One level up
Don't mistake a component's raw speed for a finished system's speed — the orchestration layer is where real-world performance is actually won.
Where it stops holding
This stops working when dataset size is small enough that naive sequential calls are already fast enough, making the extra architecture unnecessary overhead.
Detail
rule: To get real-time performance from a fast decision model over large data, batch the results, score them, and push the high scores up — don't just call the model once per item.
threshold: n/a — qualitative architectural rule
rationale: The host explicitly warns against pretending JEV alone, 'slapped in the middle,' can evaluate thousands of items that quickly without this architecture.
In their words
Just for, like, behind the scenes, you have to, like, batch the results and then score them and then push the high scores up to get that kind of performance. So there is some architecture here. I don't wanna pretend like Jev, you just, like, slap Jev in the middle and evaluate all 4,400 that quickly.
Local coding-session log analysis reveals shift in personal work mix over time
Source
How I AI — Jev for beginners: how to use it and what to build (September 28, 2026) · at 11:15 ▸
When this applies
when an individual wants an objective picture of how their job/work mix has shifted over time, using records they already generate but never analyze
The takeaway
Personal or team activity logs that already exist passively can be turned into a trend dashboard almost for free, revealing shifts in focus that intuition alone wouldn't quantify.
Why it works
Locally stored interaction logs are unstructured but classifiable; running a cheap classifier over them by time period surfaces trends that would otherwise require manual self-tracking.
One level up
Passively generated exhaust data is often a free source of self-knowledge if you bother to classify it.
Where it stops holding
This stops working when session logs are sparse, poorly labeled, or don't capture the actual nature of the work (e.g., context outside the tool isn't logged).
Detail
situation: Wanted to understand how much of his time was spent on engineering vs. other tasks (agents, media publishing, client work, personal) as his role evolved.
decision: Ran JEV-based classification over all locally stored Claude Code/Codex sessions, grouping by user turns and by session days.
outcome: Found that in January he was almost exclusively doing engineering tasks, but by September less than 40% of tasks were engineering, with the rest split across agents, media publishing, client delivery, and personal work.
lesson: This kind of meta-analysis on local data costs basically nothing and surfaces insight that would otherwise be hard to get without manual tracking.
In their words
And then as you kind of, like, come into this new world, now in September, less than 40%, it looks like, of my tasks are actually engineering tasks.
Real-time voice-to-color-and-quote emotion app
Source
How I AI — Jev for beginners: how to use it and what to build (September 28, 2026) · at 22:30 ▸
When this applies
when exploring whether a fast decision model can glue together multiple real-time signals (sensor input, scoring, external lookups) into a responsive experience
The takeaway
When prototyping real-time multimodal experiences, use a constrained-choice decision model for the fast internal matching step, and expect any external/generative API in the chain to be the latency bottleneck.
Why it works
Because the decision model only needs to score a fixed small list of options (hex color codes, quote filters) per utterance, it can keep up with a real-time voice stream, while the external quote API becomes the actual latency bottleneck.
One level up
Fun, low-cost prototypes are a cheap way to validate an architecture pattern before committing it to a serious product.
Where it stops holding
This stops working when the external APIs in the pipeline (e.g., content generation, lookup services) can't match the decision model's speed, limiting overall responsiveness regardless of the decision model's speed.
Detail
situation: Wanted to demonstrate a fun real-time use case for JEV beyond business analytics.
decision: Built an app that takes live voice input, uses JEV to score a list of hex colors against sentiment and pick a matching quote filter, then displays a color and quote.
outcome: The color-matching step worked quickly and accurately; the quote API introduced noticeable latency, showing the decision model wasn't the bottleneck.
lesson: A fast decision model can enable fun real-time experiences, but the overall experience is only as fast as its slowest external dependency.
In their words
You can tell the quote API has a little latency in it, but you can imagine how fun it would be to be able to build these real time experiences.