How we use Jev to build Jevfast
Jevfast is a place to find projects people have built with Jev. Each entry has a short account of what the project does, a link back to its creator, and categories that help readers browse. I also use Jev while building this directory. Its job here is to help decide those categories: a small label on the page, repeated across very different projects.
Projects reach me through GitHub, X posts, videos, and submissions. I read the source before an entry goes public: does that project really use Jev, what does Jev decide inside it, and is there enough evidence to describe it fairly? Once I have that material, I ask Jev a set of yes-or-no category questions. It returns a probability for each answer, and the code turns those scores into at most two labels.
Drape Jev Try-on made the category question interesting. In the creator's post, spoken input and the outfit on screen become context for Jev to choose clothes from a closet. I had reviewed it as Creative only. Our Experiments category is for projects chiefly testing a Jev capability, not every creative prototype described as an experiment. Would our automated labels agree?
One call sends Jev the title, summary, Jev's role, source URL, and saved evidence, with eight independent Noul questions, Jev's yes-or-no type, about that same state. Each category gets its own question because a project can belong in two places. A single Choice question makes categories compete, so a strong Creative answer could crowd out another category that also fits.
In our recorded Drape run, Creative scored 0.88 and Experiments 0.52. The code keeps the two highest scores strictly above 0.7, so Drape appears only in Creative. That matches what I saw in the creator's post.
What Jev decides
Does the saved evidence show an experiment as a substantial browsing category? Judge this independently.
The project's title, summary, Jev role, source URL, and saved creator post. The post says spoken input and outfit context help Jev pick clothes from a closet in real time.
App workflow
- Save evidence
Discovery records a repository README or creator post. A reviewer checks whether it actually describes a Jev project.
- Ask eight questions in one call
The same project state goes to eight independent Jev Noul questions, one per browsing category.
- Choose the browsing labels
Code keeps the two highest category scores strictly above 0.7. If none pass, it keeps the single highest score.
- Apply the publication gate
The catalog checks availability, evidence, engagement, and any documented unusual-project exception. A Jev category score never publishes a project by itself.
This is one question from that eight-question request. The wording is shortened for the chart; 0.52 is the recorded yes probability for Experiments.
What the cutoff cannot solve
When no category clears 0.7, the code still picks the single highest score so each project has a place to browse.
That happened with pi-typesafe. Its public README describes a Pi extension with a Jev tool, a terminal playground, and an API for other extensions. Jev gave SDKs & integrations 0.49 and Agent tooling 0.48. The fallback put it under SDKs & integrations. A hundredth separated two plausible shelves. When no category clears the cutoff, I think an LLM should make the category judgment from the source evidence instead of accepting Jev's top score. We have not built that handoff yet.
These examples show why I pay attention to the evidence we give Jev. A short post may support a different judgment from a detailed README. Jev only sees what goes into this particular request, so missing context cannot be repaired by a previous conversation.
The harder question: when popularity is too early
Category labels are only one part of content review. Jevfast normally waits for at least 20 GitHub stars or 20 X engagements before listing a project. That can miss a very new idea, so I can make an exception with a written reason. I made one for Jevthoven, a music studio that lets people revise and arrange a piece and export MIDI. At review time it had one GitHub star. Those capabilities made it worth showing early.
I have tried asking Jev whether a low-engagement project has that kind of potential. Its answers have felt about fifty-fifty useful to me, but that is an impression from informal trials, not an accuracy figure. There is no saved evaluation set or measured success rate behind it. Jev does not trigger the exception or publish a project; I still make that call and record the reason.
Why use Jev here?
A regular LLM can classify these projects. It may even do better on a borderline case after reading the surrounding conversation, earlier examples, and a long review history. Jev gets only the information we put in each call. That is a limitation when context is missing, but it also makes a surprising label easier to trace: we can go back to the specific evidence and question we supplied. Previous chats do not quietly change the next classification.
The appeal is speed and cost across many small judgments, rather than a claim that Jev understands every project better. I find the category step useful; I do not yet have a measured accuracy rate for it. TypeSafe has published workflow evaluations comparing accuracy, time, and cost on security incidents, agent traces, invoices, and customer service. Their reference answers come from a consensus of two large models. I found no published category or unusual-use benchmark for Jevfast-like projects, and our saved results have no human-labeled test set, request timings, or LLM baseline. So neither those evaluations nor our results can support a numeric quality or speed comparison here.
That is the benchmark I would like to see: a public set of real project evidence, human-reviewed category and unusual-use decisions, the same questions sent to Jev and LLMs, and the errors shown alongside latency and cost. Until then, the honest conclusion is narrow. Jev gives us fast, inspectable first-pass labels. The close calls remind us that deciding what deserves a place on Jevfast still takes a person who has read the project.