DEV Community: Emmanuel Paul

Jev Explained: What If AI Didn't Need to Chat?

Emmanuel Paul — Fri, 16 Oct 2026 06:30:56 +0000

Hey 👋, Emmanuel here. Unless you've been living under a rock, you’ve probably heard of Jev (a new AI decision model from TypeSafe AI). It was launched in September, and although my feeds were packed with news about it, I still had no idea what exactly it was or how it differed from standard Large Language Models (LLMs) like ChatGPT and Claude.

Well, until now, that is. Yep, I’ve done some research on TypeSafe AI’s "Jev," focusing mainly on what makes it different from standard LLMs. Could this actually change how we build AI-powered applications, or is it just another model being hyped?

What is Jev?

According to TypeSafe AI, Jev is a specialized non-generative AI decision model. Note that I refer to it as “non-generative,” which is due to the fact that it doesn’t write prose, chat, or generate text. Rather, Jev is a decision model that simply evaluates unstructured input data against predefined questions and returns structured probabilistic decisions. Unlike the traditional LLMs we are used to, Jev is a pure System One model.

System One is a conceptual method of thinking that was introduced by psychologist Daniel Kahneman in his book Thinking, Fast and Slow. Rather than slow, step-by-step reasoning, System One refers to a mode of thinking that’s fast, intuitive, effortless, and automatic.

With Jev, you don't get the usual back-and-forth conversation or a lengthy explanation containing the information you need. Instead, you get structured decisions, probability distributions, and confidence scores, all in a structured format/payload.

Jev vs. LLMs: What's the Difference?

Now, as I’m sure you’re wondering, what’s the difference? I mean, Jev being a System One model sounds cool and all, but how does that compare to the standard LLMs we know?

Firstly, let’s talk about the primary output. With regular LLMs, you get open-ended natural language, responses, code, or something similar. The response is in natural-language text and is generated sequentially by the model token-by-token.

With Jev, however, you get zero natural-language text. Instead, the decision model returns fixed, type-safe (no wonder the company name) structures. These may be predefined choices, numerical scores from 0 to 1, or simply Yes/No probabilities.

Next, the speed. LLMs usually operate autoregressively, as each generated token depends on the previous ones in a loop-like sequence. As expected, this method of token generation is relatively slow, taking from a fraction of a second to several seconds or minutes, depending on the operation.

On the other hand, Jev is non-autoregressive and evaluates independent decisions in parallel in a single pass. Instead of writing out a paragraph or parsing JSON, Jev directly maps the input state against predefined choices, scores, or probabilities in one unified evaluation. Hence, it’s quite fast (40x to 200x faster), taking around 70-500 ms (at least according to reports from TypeSafe AI).

Lastly, and perhaps most importantly, cost. Standard LLMs charge for both input tokens that are processed and output tokens that are generated. For instance, a lightweight model like GPT-4o Mini offers a pricing structure of about $0.15 per 1M input tokens and $0.60 per 1M output tokens ($0.15 / $0.60).

Now, as I’ve mentioned quite a few times already, Jev doesn’t generate output tokens, so that’s a part of the pricing you don’t have to worry about. For inputs, you get charged $0.042 per 1M tokens processed, making the final pricing structure about ($0.042 / $0.00).

Let's Put It to Work

One great way to truly understand how Jev works is by an example I found online: classifying customer support tickets. Now, forgive me for being unoriginal, but if it works, it works.

Imagine you're building a customer support system for an e-commerce store. Customers submit complaints every day, and someone has to read each one, figure out what it's about, determine its urgency, and route it to the right team. Now, you decide to automate the whole classification process using an AI model to be more efficient as your business grows.

Consider this ticket:

"I've been trying to pay for my order since yesterday, but checkout keeps failing. I've also been charged twice, and nobody has responded to my email!"

With a standard LLM, you send it this ticket alongside a prompt like “You must return valid JSON. Do not include markdown formatting…" or something similar. Then you might need to add a lot more output constraints and validation to get the required information. Plus, the AI might hallucinate more ticket categories or mess up the exact wording, like using “Billing Error” instead of the predefined category “Payment Issue."

Now with Jev, you get direct classification from a decision model. During setup, you configure Jev with a strictly-typed question schema (using question types such as Choice, Score, or Noul). For our example, we might go with:

Category (Choice): “Payment Issue” - “Technical Issue” - “Shipping Delay” - “Account Lockout” - “Other”
Urgency Score (Score): 1 to 5 (Routine to Critical)
Sentiment (Choice): “Positive” - “Neutral” - “Angry”

Note that this is just a rough template from the top of my head (Don’t judge me)

With that, Jev returns structured results that fit the schema we've defined. Since the available choices are predefined, Jev can't return a new category outside the options we've specified for that question. It can still make the wrong classification, though, which is why we need to consider its probabilities and confidence level rather than blindly trusting every result.

Now, I’m not writing this because normal LLMs can’t stick to strict schemas or always hallucinate. The difference is that Jev is designed around predefined decisions from the start. You're defining the possible answers beforehand, and Jev returns its decision alongside probability information that can help your application handle uncertainty.

Are LLMs Becoming Obsolete?

So, are Large Language Models done? Truth be told, that’s what I was thinking about when I first heard of a pure System One AI model that’s significantly faster and cheaper. However, that’s not actually the case.

Instead, the major shift here is how we separate generative tasks from decision tasks. Using a standard LLM for evaluating data and making decisions from a predefined list can be overkill, especially when we consider speed, cost, and accuracy. As a decision model, Jev is faster, cheaper, and simply better at classification and routing according to strictly set schemas.

However, Jev isn’t a generative model, so you don’t get anything new like text, prose, or anything like that. For instance, it can’t be used to automatically draft an email to send to customers whose tickets have been analyzed. Obviously, we need standard LLMs for such generative tasks.

Therefore, the future might be hybrid systems. Decision models can be used to efficiently filter and sort data in a pipeline. A model like Jev could classify incoming requests, filter spam, or determine which workflow should handle a particular task.

When a request actually needs a human-readable response, a traditional LLM could take over and generate one. It can also be used as some sort of router to determine which tool is best suited to a task, depending on the input provided and the range of available options.

Rather than treating Jev and traditional LLMs as direct replacements for one another, we can think of them as different components that may work better together.

What I Learned

This is probably my longest piece yet, though I consider it worth the effort. What are my key takeaways? Well, now I understand the differences between generative and decision tasks, as I’ve been naively mashing them together. What truly separates Jev from regular models is that it’s configured around our predefined decisions, so we get structured decisions, classifications, and probability scores.

Keep in mind, though, most of these claims are based on information from TypeSafe AI’s reports. It’s probably best to take them with a pinch of salt until independent benchmarks are available.

Although AI models keep getting better, it’s quite clear that the brute force approach has its limits. Building specialized models for specific tasks and combining them into a single pipeline could be a more efficient approach, depending on the use case.

Monolith or Microservices: One App or Many?

Emmanuel Paul — Fri, 09 Oct 2026 08:39:30 +0000

As someone who’s still fairly new to the software industry, I’ve heard a lot of people throw terms like “Monoliths” and “Microservices” left and right. Truth be told, I’ve mostly pretended to know what these words mean, well, until now.

After spending some time on Google and checking out a few well-written articles, I’ve decided to just write my take on it. Keep in mind, I’m not some expert, so I’m always open to constructive criticisms (not random hole poking) in my logic.

The Monolith

Monolithic architecture is pretty much a traditional approach to software development where the entire application is built as a single unified program. Every part of the application, whether it’s the UI, the business logic, or database access, is written within one codebase.

Based on what I’ve learned, this means the different parts of the application are tightly coupled and typically deployed as one unit. While mixing multiple frameworks or languages is technically possible, doing so can introduce much complexity.

Then There's Microservices

If monoliths mean joining everything in one codebase, microservices seem to be the exact opposite. The large application is broken into small, independent services that communicate over a network (APIs, I believe). Each service handles a specific task, which may be processing payments, sending notifications, or simply authentication.

As services are independent units that simply communicate, they can be written in different languages, depending on their use. For instance, using Python for a service that requires a decent amount of data manipulation and Node.js for a real-time chat service. Plus, if one service fails, the others keep functioning, rather than taking every part of the app down alongside it.

What’s The Catch?

If either one of these approaches was perfect, there wouldn’t be much debate between the two. Whether you go for monoliths or microservices, there are a few downsides to consider.

With monoliths, scaling can eventually become inefficient. Horizontal scaling requires cloning the entire application stack instead of just the limited features, which wastes server resources. Changing the framework or programming language is also nearly impossible once a monolith reaches a massive size. Furthermore, working in one codebase can easily become a nightmare as the engineering team grows, leading to constant git merge conflicts, slow build times, and a slow development cycle.

When it comes to microservices, you get far more complexity in terms of infrastructure. You may need container orchestration (e.g., with tools like Kubernetes), service meshes, and automated CI/CD pipelines. Besides that, you have to consider network latency, connectivity issues, and securing connections, as various services need to communicate to run the application.

Don't Overengineer It

I have quickly become what I call an “expert” in the whole “Monolith vs. Microservices” debate, and here’s my take: Don’t overengineer it. The best software development approach depends on your current needs. If you’re building some kind of MVP or startup project, then just stick to a monolithic architecture, as it is modular and supports rapid early development and simple deployment.

On the other hand, if you’re scaling an enterprise application, with large distributed teams across several domains, microservices may make more sense. You get the fault isolation, independent scaling capability, and much more flexibility.

At the end of the day, there’s no universal winner here. Start with what solves your current problem, and let your architecture change as the problem gets bigger.

🐾 PawSafe: An AI-Powered Food Safety Checker for Dogs

Emmanuel Paul — Mon, 17 Aug 2026 00:18:35 +0000

This is a submission for Weekend Challenge: Dog Days Edition

What I Built

PawSafe is an AI-powered web application that helps dog owners answer a simple but important question:

"Can my dog eat this?"

Users can enter the name of a food, upload a photo, or provide both. PawSafe then analyzes the information using Google's Gemini API and provides a simple safety assessment.

The result is categorized into four levels:

🟢 Generally Safe
🟡 Use Caution
🔴 Not Safe
⚪ Unable to Determine

Along with the result, PawSafe provides explanations, potential warnings, and safer alternatives when appropriate.

My goal was to build something that was useful, simple to understand, and approachable for dog owners rather than making users search through multiple sources every time they encounter an unfamiliar food.

Demo

Live Demo

Code

GitHub Repository

How I Built It

PawSafe is a full-stack application built with:

Frontend

React
Vite
Tailwind CSS
Lucide React

Backend

Node.js
Express
Multer
CORS
Google Gemini API

Deployment

Render
GitHub

The basic flow looks like this:

User
  ↓
Food name / Image / Both
  ↓
React Frontend
  ↓
Express API
  ↓
Google Gemini
  ↓
Structured Analysis
  ↓
PawSafe Result Card

One of the main technical decisions I made was to keep the Gemini API integration on the backend rather than exposing the API key in the frontend.

The frontend sends the user's food information to the Express API. The backend then communicates with Gemini and returns the structured analysis to the frontend.

I also wanted the application to support both text and images independently, while still allowing users to provide both when additional context is useful.

Prize Categories

Best Use of Google AI

PawSafe is submitted for the Best Use of Google AI prize category.

Google's Gemini API is the core intelligence behind the application. It is used to analyze both text-based and image-based food information and generate a structured safety assessment.

The AI response is then presented through PawSafe's interface as an easy-to-understand result rather than exposing users to a raw AI response.