Speaker 1Jev is one of the buzziest models we've had in a long time, and that's because it's not just another LLM like a GPT-6 or an Opus or Fable model, it is something fundamentally different. But because it's different, it's not necessarily clear at the beginning exactly what it's going to be best used for. With the benefit of a week and a half under our belts now though, people are discovering and sharing a slew of different use cases that take advantage of what makes Jev unique, and today we're going to get into the best of them and where they might be relevant for you. The AI Daily Brief is a daily podcast and video about the most important news and discussions in AI. All right, friends, quick announcements before we dive in. First of all, thank you to today's sponsors, KPMG, Blitzy, Harbor, and HyperAgent. To get an ad-free version of the show, go to patreon.com slash ai-daily-brief, or you can subscribe on Apple Podcasts. And to learn more about sponsoring the show, send us a note at sponsors at ai-daily-brief.ai. One more quick announcement. We have our next free webinar coming up shortly. It's all about how you can build your own personal AI benchmark so that when a new model comes out, you can test it and see how good it is for you and where it will fit into your AI stack. It's led once again by Nufar Gaspar. It will be free and you can get all the info you need at ai-daily-brief.ai. Over the last couple of weeks, one of the buzziest new things to come up in the AI world has been a new model called Jev. Now, what makes Jev interesting? Is that it is not just another LLM that you would use for the same thing as GPT-6 or Opus 5-5, but actually works in a slightly differently and, as we will see, complementary way. In the 10 days or so since launch, not only has there been a ton of buzz, I'm talking hundreds of different posts on X, which each themselves have hundreds or even thousands of likes and shares, but that attention is also translated into significant financial opportunity, with the information reporting that the company is in talks to raise as much as $1 billion at a $10 billion level. That is a decent jump from its $40 million seed that was completed at a $200 million valuation. But now that we've had a chance for people to actually get their hands on Jev itself, I wanted to go back through and talk about how people are actually using this thing outside of the buzzy visual and game demos that have been all over social media. Basically, is Jev something that the average person who's not a game designer or not a developer should be paying attention to and even thinking about as part of their larger AI stack? Now, to recap what Jev is, previously I called it a judgment model. What Jev can't do is write in the traditional way that you think about chatbots writing. Instead, the team at Typesafe who built Jev calls it a system one model after a concept from Daniel Kahneman's thinking fast and slow. System one thinking is fast instinctive pattern matching, i.e. snap judgments, and that's what Jev is built for. A good way to think about a test for whether something is a good job for Jev is where you repeatedly read something. You can take a small judgment, then take a predictable next step. So take, for example, a file landing in your downloads folder. An ordinary rule that existing software might have would be to classify it as a PDF. But what Jev can do is go a step further, identifying is it an invoice, which projects is it for, and does someone need to see it? Once the judgment is made, it can be predictably moved on to the next step in a system. There are three core types of questions that you can ask Jev. The first is pick one, or what Jev calls choice. It answers. You list up to 255 options, and Jev can find the best fit. So an example of this might be, which team should handle this ticket? Is it billing, tech support, sales, or other? The Jev model is going to give you back the pick, plus a probability for every other option. The second type of question that you can ask Jev is what they call a score, which is basically rating on a scale. You describe each level in words, from two to ten levels, and Jev can answer where something falls. So, for example, on the scale from calm to very angry, how frustrated were you? How frustrated is this customer? You're going to get back from Jev a position on that scale, as well as an indication of how sure the model is. The last type of question is a yes or no question, what Jev calls a NUL, which is short for Bernoulli. And it simply answers, is this true? So to stay on this customer service example, is this person explicitly asking for a refund? What you're going to get back is a probability from zero to one that the statement is true. Hey Stefan and X did a really cool, very simple visualization where he put a pile of emojis at the bottom of a screen. Into a text box, he wrote, you can type in classifiers like things you can wear, or things you can wear in winter. The emojis that match race to the top, or fall off, if the classification is changed. And so what's happening in the background is that every emoji is getting the same yes or no question. Does this match what you typed? And importantly, nobody labeled or tagged the emoji, as would happen in traditional machine learning. There's no rule, in other words, for winter. Every emoji gets the same question at the same moment. Does this match? And part of what you might be recognizing if you're watching this demo. Is that because what Jeff does is limited and specific, it can do it incredibly fast. When type safe launched the model, they said it can work 20 to 200 times faster and 40 to 400 times cheaper than comparable processes with LLMs. Now instead of this pile of emojis, imagine that the pile is your leads, your tickets, your documents, or some other big undifferentiated mass of information. Importantly, you can ask many questions about the same item all at once. Because questions run in parallel, asking the ninth or 10th question doesn't cost you more time, it just costs more tokens. Say for example, you have a single customer email. You might want to ask three yes or no questions at once. Is the customer angry? Did they get a delayed response? Are they dealing with an incorrect item? These are three separate questions that are each going to have their own probability. In their testing, type safe found that 13 questions handled in a single call was 12.2 times cheaper and 10 times faster than one at a time and got to the identical answers. Matthew Berman did an analysis of 724 live ads. Each ad being asked 12 questions. One about the hook archetype, one about the format, one about the offer, one about the CTA intent, one about the awareness, et cetera, et cetera. He found that that single request for the 12 questions for that ad took just 173 milliseconds to complete. And this is really where the power of the model comes in. It's not just that it's good at judgment, it's that it's fast enough and cheap enough to ask and make judgments about everything. A million input tokens cost just 4.2 cents, and output tokens are free, and each call is going to take between 70 and 500 milliseconds, and as we've seen, can combine a bunch of different questions in a single call. Now importantly, Jev makes trade-offs that allow it to be good at the things that it does, but that also means that it doesn't do certain things. It's not going to write code, it's not going to draft contracts, and it's not going to make nuanced decisions that involve a variety of factors that aren't quantifiable and clear. It's going to be used for small judgments at volume. Which bucket? How urgent? Is it relevant? Is it safe? So now let's talk about six different ways that people can make decisions. First, people are actually putting Jev to work, outside of just cool demos. A first category is analyzing what you already have. A second category is searching by meaning. A third category is triaging what comes in. A fourth category is checking work against your rules. A fifth category is speeding up AI agents. And a sixth category is responding instantly. So let's move to category one, analyzing what you already have. AKA, what's in this pile? This is basically where you're going to take a collection you already have, ask Jev the questions about every item, and then count the answers. This is analysis that previously could not be justified doing by hand, but is now going to take seconds and cost cents. One example was that from Matthew Berman that we just talked about, where he analyzed and broke down 724 live ads from 37 brands to identify every hook, every format, every offer, every CTA. The idea is to be able to then take this data and compare it to what actually performed, giving you incredibly deep and complex fine-grained information about advertising performance that would have been extremely difficult before. It took 40 seconds and nine cents worth of tokens for Berman to get the full breakdown of those 724 live ads. Two days later, Berman went further, and instead of just asking those questions in general, this time he had Jev scroll 723 ads as 30 different buyer personalities. The personalities were archetypes like gym owner, dental office manager, toddler mom, or AI curious engineer. Jev's job was to ask for every buyer in every ad, would this person stop scrolling or keep going? It took him 22 cents to get 21,690 stop or scroll decisions. Now, of course, this is not data. This wasn't 30 actual buyers. It was just buyer archetypes as considered by an AI. In other words, it's better to view this as a hypothesis generator, but it's hard not to think that marketing will shift to using this as a key part of its process to pressure test ad or landing page angles before paying for real tests. Lots of other folks are running Jev over whole archives, whether that's email archives, past X posts. Documents databases, research projects. And in each case, what Jev is doing is asking the same few questions, but about every single item in the archive. Ian Nuttall, for example, had Jev ask 8 questions each, topic, hook, and tone, about nearly 3,300 of their previous X posts, to be able to then compare that data with engagement metrics to get a better sense of what actually worked. And by the way, those 8 questions each across 3,300 posts cost about 13 cents. So how might we try something like this? Well, if you look at any big pile of data you have: a year of customer emails, CRM notes, a folder of meeting transcripts, anything where you can write a few simple questions and run them against all of those queries, that's a potentially useful place for a Jev job. Category 2 is searching by meaning. In other words, which of these match what I mean? The idea is to be able to describe what you're looking for in plain words, and let Jev check every candidate. The power is that it can find what you mean even when the words don't match. There were a bunch of examples of this. of this with people basically using it as a new approach to natural language search on websites. Justine Moore from A16Z gave the example of scanning thousands of Zillow listings and classifying properties by things you can't normally filter for, such as architectural style, renovation status, or proximity to freeways. In one example that piqued my interest, Burhan took a 90-minute video and was able to clip it based on themes that they described in natural language. So for example, across that 90-minute video, they were able to look for and clip, quote, their predictions for when AI will automate AI research, and they were able to find a bunch of examples of that in under two seconds for under two cents. Another example of this is an SEO audit where Borgia deployed Jev to read all 586 pages of their website to rebuild the site's internal link map, which it was able to do in 45.1 seconds for 21 cents. Cloud Opus 5 only got through 21 of those pages and spent $1.43. Borgia explains, internal linking is the perfect Jev job. It's not writing, it is 8,790 yes or no calls. Does this page have a real reason to link to that one? And is there anchor text already sitting in the copy? That is a classification problem, and we've been paying frontier prices to do it one page at a time. A final subcategory of the searching by meaning is filtering what you read by what you care about. So for example, Robin Bilgil built a real-time AI slop detector. As they scroll X, the slop detector gives a confidence score on that zero to one scale about how much it thinks the post is AI slop or not, blocking out the ones that reach a certain confidence threshold. So for example, Robin Bilgil built a real-time AI slop detector on that zero to one scale, blocking out the ones that reach a certain confidence threshold. This sort of filtering though can be applied in a bunch of different ways. Elvis Sananex gave an example of letting Jev browse 384 morning news stories and identifying which of them 15 different brands should be paying attention to. That was completed in 24.9 seconds for 19 cents. And by way of comparison, in that same time period, Opus 5 got through four of those articles, leaving 380 unread. Jev use case category three is triaging what comes in. In other words, what is this and where does it go? The kinds of questions that people are experimenting with are the ones that are most frequently asked. Are things like how important is this email? Is this downloaded file and invoice? Is this link malicious? Should this lead go to sales, self-serve or nurture? One really interesting experiment came from Jonathan Unikowski. He wrote, every email app shows your inbox in reverse chronological order. What if it was live prioritized by importance instead? Jev's job in this case was to rate every email's importance. And in the test, it was able to rate 100 emails in 453 milliseconds for about a tenth of a cent. With Jonathan reporting that, he was able to rate 100 emails in 453 milliseconds. He also reported that Jev's rating matched his own on every single one. This is a use case that I want right now, not tomorrow. In fact, I want it yesterday. And so do all of the people who are sitting there beating their heads against the wall because I haven't responded to them yet. Some other folks are experimenting with a pattern of asking one quick question per item. Marcel Pocchio, the CTO of Beyond Code writes, I built a Mac OS app that monitors my downloads folder along with a customizable set of rules. Is the downloaded file an invoice? Move it to a separate folder. DevEd used Jev for live chat moderation, removing swearing and negative comments as they arrive. Stephen Tay of the dub LinkShortener fed Jev 10,000 malicious domains they'd caught before to flag bad links on their free shortener service. He wrote, this has been something that we've been wrestling with since day one. With Jev, we solved it in two hours. In fact, this sort of triage is so integral to so much of business. In a post about 10 Jev use cases for a marketer, UmonX identified workflow decisions as one, saying, workflows eventually hit the same question, what should happen next? That's probably the best place to use Jev. Box gave an example, having already experimented with incident triage, where Jev is used to judge customer impact and severity, as well as things like which routes it can be escalated to. Udo CRM has a proposed module that asks three things about every new lead, their priority, their buying readiness, and whether it's spam or not. If you had to look at just one area to explore, especially if you were in a company with multiple people touching the same leads or customers or if you were in a company with multiple people touching the same leads or customers or customers, you'd be able to use this. This sort of triage and routing is, I think, where Jev is going to become absolutely integral, basically from the moment that it gets integrated into the systems. A new study from KPMG and the University of Texas at Austin found that when people work with AI, similar skills don't guarantee similar outcomes. Researchers studied more than 500 early career professionals and found that the best performers consistently amplified the value of AI by guiding, evaluating, and refining its outputs. These top performers, called AI amplifiers, weren't defined by what they knew alone, but by how they worked with AI. Learn more about what separates AI amplifiers from everyone else at kpmg.com slash us slash AI amplifiers. Blitzy's understanding of massive codebases unlocks autonomous security fixes, modernization, and new features. So what happens when there's no legacy code at all? Greenfield is supposed to be the easy part. Clean slate, no technical debt. But even Greenfield moves at human speed, one sprint at a time. Blitzy changes the unit of work from the developer to the project, autonomously planning, building, testing, and validating entire applications from scratch. Hundreds of thousands of lines of production-ready code. One Blitzy customer stood up a brand new application, 534,000 lines of code, compressing a 65-week roadmap into two weeks. Another shipped an entire application with no front-end engineer. Legacy or Greenfield, the answer is the same. Software at the speed of compute. Build what's next at blitzy.com. That's blitzy.com. Every episode, we cover the competition between OpenAI, Anthropic, SpaceX AI, Google, and Meta. Chances are you've already formed an opinion about who's leading. But every AI lab is taking a different approach, building different technologies, forging different partnerships, and developing a unique ecosystem. Harbor Capital Advisors' AI Lab Ecosystem ETF Suite gives investors a way to gain exposure to the AI ecosystem they believe is best positioned for success. Search Harbor AI Lab Ecosystem ETFs wherever you invest, or follow at Harbor Capital on X to learn more. HarborCapital.com for a prospectus containing investment objectives, risks, fees, expenses, and other important information. Read and consider it carefully before investing. Risks include principal loss and artificial intelligence-related risks. Harbor ETFs are distributed by Foresight Fund Services, LLC. Harbor is not affiliated with AI Daily Brief, and the funds are not affiliated with, sponsored by, or endorsed by any AI lab. This is a paid advertisement and not personalized investment advice. Investing involves risk, including possible loss of principal. This episode of the AI Daily Brief is brought to you by HyperAgent, where you run fleets of agents your team can manage together. Forget local agents and chat workflows waiting on your laptop to be prompted. HyperAgent deploys always-on agents in the cloud, doing real work across the tools your team already uses. Marketing agents turn competitor moves into landing pages. Sales agents enrich leads, draft emails, and updates the CRM. Ops agent chases the paperwork and tracks the budget. Every agent has access to shared context and follows your rules about scope and approvals. It's time you had agents that feel like teammates. Hire yours at HyperAgent. Get $100 in credits at hyperagent.com. A fourth category of Jev use cases is checking work against rules, i.e. does this meet the bar? Instead of the standard LLM question of please review this, you turn please review this into specific questions and then ask those questions about every draft. One example of this came from Langchain, which was grading an AI agent's work the same way every time. Harrison Chase from Langchain pointed out that Jev is, quote, great for evals. Especially online evals where you want to grade lots of traces. Now this might feel initially like something that is more for devs than for other types of knowledge workers and companies, but given how much all of us are going to start putting agents into production or managing agents that already exist, think support bots, research agents, etc., having a better tool to build evaluation systems into how we judge those agents' work seems like it could very easily become core infrastructure. And the team at Every showed how you could use this sort of ability to check work against rules at mass scale and at an incredible speed. As a way to improve AI writing, they planted mistakes on 12 passages of writing, with Jev catching 6 of 7, as compared to ClaudeFable5.1's catching all 7. Jev, however, caught at 6 in 0.35 seconds as compared to 8.83 seconds for Fable5.1, and it did so at about 580 times cheaper, meaning that you could rerun that same check a huge number of times and still have it be both cheaper and faster than using a frontier model for the same sort of review. So how might you actually turn this into something that you would use? You'd basically need to go through a translation process for your rules for writing. So let's imagine that you had a style guide, or a list of phrases you never want to see. You could turn each of those into a yes or no question, and then run those yes or no questions on every paragraph of your next long document as a way to ensure no AI-isms or other writing third rails in your key communications. And this gets, I think, at one of the biggest rewirings that we're going to need to do with Jev. A lot of the unique value of Jev is not just being able to do a thing. It's being able to do a thing. It's being able to do a thing at such scale that it actually becomes a difference in kind rather than a difference in scale. Being able to realistically check every single sentence in minute detail for AI-isms, in other words, becomes categorically different from just running a generic LLM check across the document as a whole. The fifth category of use cases that lots of people were experimenting with admittedly does get a little bit closer to the developer realm. But I think at least for the sake of completeness, it's still worth discussing. These use cases you might sum up as speeding up your AI agent. And a lot of this is around the sort of model routing that we've been talking about for the past several months. The kinds of questions people were asking were things like, which model can handle this task? How much reasoning does this step need? Which skill fits this request, if any? Is this old tool output still relevant? You can see how in each of these cases, the common thread is people using these small automated micro judgments to route an agent to the right level of intelligence, the right context, the right skills, the right tools, to do whatever its job is in the most efficient way possible. V. Chen Rose. wrote, people use Jev to pick a model before a task. I made it change GPT-6 reasoning's effort inside Codex during the task. More thinking when stuck, less for routine steps. And in their test, they found 50% lower Astra costs while also getting faster runs. People are also using Jev to manage the context window. Daniel San built something called Jev Skill Suggestion for Cloud Code, where, quote, for every request, Jev classifies which skill best matches the task, then injects only that skill into Cloud's context. This led to an 88% decrease in tokens and cost. I know a lot of even you formerly non-developers have started to be sufficiently proficient with things like Codex and Cloud Code that you've built up big skills libraries, and these sorts of Jev-based tools are potentially a way to stop sending all of those libraries to the model with every single request. And one thing to note here is that while a lot of these use cases that we're discussing are at this stage individual experiments, you're also going to see Jev and judgment models like it built into Cloud Code. So, if you're looking for a model that's going to be able to natively into the tools and harnesses we use. AJ Asper, for example, wrote, we built a new harness using Jev that cuts the cost of repetitive work by 90%. The harness learns the job as it runs, moving steps from LLM calls to code. The example they gave was compliance alerts, and they measured the cost per alert batch by batch with each batch representing 50 of those compliance alerts. At the beginning, the cost per alert was about $2.95, but by alert 1,000, it was down to just 25 cents. A sixth thing to note here is that the last category of Jev use cases are about instant response. What does this person want right now? A lot of people were experimenting with some version of this. Marcus Lowe wrote, what if copy paste was smart? Copy a resume, paste into an application, and the fields fill themselves. Norman on X also did a version of this, splitting the pasted text into pieces, working out what each field is, matching them, checking against the original, and pasting only the confident matches. Given how much work at work is moving details from one format i.e. emails, PDFs, meeting notes, etc. into other places where that information is supposed to live, like CRMs, intake forms, or templates, this is a category of use cases that feels very, very relevant. Now, just as important as knowing where Jev is useful is knowing where you gotta be careful with it as well. A couple places that I think warrant greater caution are areas like hiring, money, and security. On hiring, you can see how, if deluged by a set of applications, you might be tempted to use something like Jev to rank them, but the problem is that even if you've given it good criteria, you're not going to be able to rank them. So, if you've given it good criteria, Jev is going to return with a number that doesn't have any reasoning attached. This, by the way, is a great example of where you might want to build a more complex system that uses multiple types of AI, imagine you do that same sort of ranking with Jev, but then automatically have other types of LLM review, for example, for bubble candidates that might be deserving of a second look. TypeSafe, the makers of Jev, actually even tried to be clear about what they think Jev is bad at. Some of the things they put include multi-step questions where they see accuracy drop with each hop. They point out that Jev isn't really good at counting math or dates, that it can extract the facts, but that you're going to want to do the actual math elsewhere. And they also point out some other issues like problems with consistency and problems with reading intent. So, if you're trying to figure out if a task is a good fit for Jev, four criteria might help. The first is that you can write down the answers in advance. Think categories, a yes or no binary, a scale. If the answer is a sentence or a calculation, that's probably not a good fit for Jev's sort of judgment model. Criteria #2: is about volume. There's a pile or a stream, such as hundreds of tickets, hundreds of emails, things like that. A third criteria is about stakes, where a wrong answer is cheap or it's easy to catch. Basically, although I'm calling it a judgment model, you don't want to leave things up to its judgment alone if getting it wrong has big consequences. A final criteria is whether you can give it the evidence that it needs as text in under 32,000 tokens. Once you've figured out a good task, the next step is going to be to write good questions. Some of the tips there from the across all of these different examples are things like one judgment per question. In other words, a not-so-good question is, is this a good lead? Because that's actually not one judgment, that's a whole bunch of different judgments embedded in one. Good lead might refer to how good a fit the industry is for your service, whether the company size matches who you like to serve, how strong their buying intent is, et cetera, et cetera, et cetera. Basically, you're going to want to break questions into their constituent parts. If your question involves a scale, you need to describe each level of that scale in words, and you also might even want to take advantage of Jeff's scale opportunities to ask more questions than you think that you need. Lastly, like everything with AI, you're going to want to do some tests before you actually trust it in production. It might be a pain, but if you're using that email classifier, for example, to try to organize things based on priority, maybe you want to label 50 emails yourself as a test and see how it compares to make sure it's actually going to do for you what you want it to do. Now, as we wrap up, I will be posting this presentation that I've been working through on this episode's companion site on ai-dailybrief.ai, and the last couple of pages get a little bit more practical with one idea for each project in the six use case areas, things like a content archive analyzer, a research rater, an inbox triage, a rewrite checker, et cetera, and there'll even be a starter prompt in there as well. In the first 10 days since Jeff was released, we've gone from buzzy, exciting concept to actually valuable production use cases extremely quickly. And yet, because this is at core a new primitive in its ability to apply simple judgment at scale, at speed, and for absolutely no money, I think it's going to take some time for us to really figure out just how deeply we can weave this into all sorts of different use cases. As more and more come online, I will come back and share the best of them. For now, though, that is going to do it for today's AI Daily Brief. Appreciate you listening or watching, as always, and until next time, peace. you
PodcastTranscript AI