Jev: System One Decision Model

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 1 of 14. You probably spend more time writing defensive code and regular expressions to parse language model outputs than you do building your core application logic. You ask for a clean data structure, and the model returns a friendly paragraph that just happens to contain your data. This friction is called The Token Generation Mismatch. To understand the solution, we must clear up a common misconception about Jev itself. Jev is not a traditional generative language model. It is a System One decision engine. This distinction matters because the vast majority of AI automation moving forward will be machine-to-machine communication. When software services interact, they do not need conversational pleasantries or explanations. They need structured, typed decisions to dictate application control flow. Traditional large language models rely on next-token prediction. They are optimized for human dialogue. When you feed them a prompt, their fundamental architecture drives them to generate readable text. Take a backend service that evaluates an incoming transaction. Your code needs two explicit fields: a numeric risk score and a boolean flag indicating whether to block the user. You construct a prompt instructing the model to return a strict JSON object and absolutely nothing else. Under ideal conditions, the model obeys. It outputs a curly brace, your parser reads the keys, and the application continues. But eventually, the probabilistic nature of the model takes over. It gets conversational. It starts its response with "Here is the JSON you requested," or wraps the output in markdown code blocks. Your backend parser expects a raw object, hits a standard text character instead of a curly brace, and immediately throws a syntax error. This is the core of the Token Generation Mismatch. You are taking an engine designed for fluid, unstructured text and coercing it into a rigid, deterministic software decision layer. You are fighting the underlying mechanics of the tool. Language models lack intrinsic understanding of programming contracts, schemas, or strict data types. They only understand the likelihood of the next word. Developers end up compensating by building fragile wrappers around their network calls. They add exponential backoff for retries, write aggressive string manipulation functions to strip out formatting, and cross their fingers that the next response is clean. Every conversational token the model generates before or after your actual data wastes compute cycles, increases latency, and costs money. A decision engine bypasses this problem entirely. It does not predict conversational tokens. It evaluates inputs and natively outputs a typed data structure. This is the part that matters. Building reliable machine-to-machine AI requires abandoning conversational text generation in favor of deterministic types. If your software needs a boolean, your model must natively yield a boolean, not a probabilistic string that happens to spell the word true. By the way, if you want to help keep these episodes coming, you can support the show by searching for DevStoriesEU on Patreon. Thanks for listening, happy coding everyone!

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 2 of 14. You ask a language model to classify a ticket, and it replies with a three-paragraph essay explaining its thought process. That is expensive, slow, and completely unnecessary for most tasks. The System One Paradigm fixes this. In psychology, specifically Daniel Kahneman's book Thinking Fast and Slow, the brain operates in two modes. System Two is slow, deliberate, and logical. System One is fast, instinctive, and automatic. Traditional Large Language Models are built for System Two work. They generate text, they reason step-by-step, and they synthesize information. But not every problem requires deep reasoning. Sometimes you just need an immediate, structured answer. This is exactly what the System One paradigm in Jev is built for. A System One model does not write text. It does not explain its logic, and it certainly does not write code. If you expect a System One model to generate a script or draft an email, it will fail. Instead, it strictly returns structured decisions and mathematical probabilities. It makes a fast classification based on the input it receives, outputting pure data rather than language. Consider a customer support pipeline. A user submits a ticket asking for a refund because their delivery was late. In a standard setup, you might pass this text to an LLM and ask it to figure out what to do. The model slowly streams back an explanation before finally telling you to route it to billing. With a System One model, you skip the essay. You pass the customer message to Jev, along with a predefined list of issue types. Jev processes the text and instantly returns a typed response. It gives you the exact category, like refund request, alongside a confidence probability. It operates in milliseconds, entirely bypassing text generation. The flow is straightforward. First, you define the structure you want back, such as a set of categories or a simple true-or-false flag. Next, you pass your raw input data into the model. The model calculates the probabilities for your defined options and returns the highest scoring match as a strict data type. Your application code then takes that strongly typed result and triggers the next step in your workflow. There is no string parsing required. This is the part that matters. When Jev returns that refund classification, the attached probability is just as crucial as the label itself. A high confidence score, like ninety-eight percent, means your code can automatically approve the routing without hesitation. A low score, like thirty percent, acts as an automatic circuit breaker. Your system can catch that low probability and safely escalate the ambiguous ticket to a human. You get deterministic control over a probabilistic engine. System One models treat AI not as a conversational agent, but as a fast, typed function that turns messy data into strict control flow. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 3 of 14. The exact training method that makes modern chatbots wonderfully polite also makes them dangerously sycophantic when you need objective software decisions. You ask a question, and instead of giving you the harsh truth, the model tells you what it thinks you want to hear. The solution to this is Training for Decisions with RLCD. Most modern language models use Reinforcement Learning from Human Feedback. Human raters prefer models that are helpful, polite, and agreeable. While this creates a pleasant chat experience, it introduces fatal flaws for automation. The first is sycophancy. If a user aggressively insists that a basic math equation is wrong, a model trained on human preference will often apologize and agree with the incorrect math just to be polite. The second flaw is mode dropping. When optimizing for human approval, the model collapses its potential outputs into a narrow band of safe, generic responses. It loses the ability to accurately weigh diverse or edge-case outcomes. This makes these models highly unreliable for driving automated decision engines. Reinforcement Learning for Calibrated Decisions, or RLCD, completely replaces human preference with statistical calibration. Instead of training the model to be liked, RLCD trains the model to align its confidence with reality. The goal is to produce probabilities that perfectly match real-world correctness. There is a common misunderstanding about what calibration actually means in this context. Calibration is not a guarantee of correctness for a single, isolated answer. If a model assigns a zero point eight probability to a specific output, it does not mean it is eighty percent sure that one answer is right. Calibration is a property of scale. It means that if you look at ten thousand decisions where the model assigned a zero point eight probability, exactly eight thousand of them will be correct. It is about predictable reliability across a large sample size. When you apply RLCD to the math scenario, the behavior completely changes. An RLCD model evaluates the probability of the incorrect math, calculates that the statistical likelihood is zero, and flatly rejects the user's premise. It does not apologize, and it does not try to soften the blow. It simply outputs the calibrated reality. This is what makes RLCD critical for system-one thinking in software. When a model's probabilities are strictly calibrated, your application logic can trust them. You can write code that automatically executes actions when the model's confidence crosses a specific threshold, and falls back to a human operator when it drops below it. You cannot do that with a model that inflates its confidence just to give a pleasing answer. When you build automated systems, you do not need an agreeable conversationalist; you need a statistical engine that knows exactly how often it is right. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 4 of 14. Sometimes the most reliable AI decision is not a parsed JSON response or a text explanation. It is just a mathematically sound coin flip that your code can threshold directly. Today we are looking at State and the Noul primitive. Every decision requires context. In Jev, the data you provide for evaluation is called the State. State is the raw material the decision model analyzes. It does not have to be a massive document. It can be a simple string, a structured object, or an array containing historical data. Whatever data shape you need evaluated, that becomes your State. Once you have your State, you need a way to evaluate it. Often, applications do not need a creative text response. They just need a binary judgment. Did a specific event happen. Is a request safe. Does the user qualify for a refund. This is exactly what the Noul primitive does. Noul evaluates a declarative statement against your State and returns a single probability value between zero and one. It bypasses text parsing entirely. You do not ask a model to output the word true or false and then write regular expressions to catch variations. You get a raw mathematical probability that the statement applies to the State. A common mistake developers make when first using Noul is looking for a separate confidence score alongside a strict yes or no answer. Noul does not have a separate confidence metric. The returned probability itself carries the uncertainty. If the primitive returns zero point nine nine, that is a highly confident yes. If it returns zero point zero one, that is a highly confident no. If the value sits around zero point five, it means the model is unsure given the State provided. The output is always just one float value representing the truth of the statement. Consider a routing layer for a customer support application. You want to know if a conversation needs to be escalated. Your State is an array of recent chat messages between the user and an automated bot. You pass this array into Jev as your State. Then, you use the Noul primitive to evaluate a specific statement. That statement is simply that the customer explicitly requested a human agent. The model reads the array of support messages. If the customer wrote to stop talking and get a real person, Noul evaluates the statement as true and returns a high probability, perhaps zero point nine five. Because you are receiving a standard float, your application logic remains perfectly simple. You write a basic conditional threshold. If the returned probability is greater than zero point nine, you route the conversation to the human support queue. If it is lower, the bot continues handling the chat. This separation of State as the input and Noul as a mathematical probability output keeps your code predictable. You avoid the fragility of relying on a language model to format its output correctly. The highest value of this pattern is that it reduces complex semantic analysis into a simple numeric threshold your standard business logic can trust. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 5 of 14. What if your code could branch on an AI classification directly, without ever writing error handlers for hallucinated categories? You need a mechanism that forces the model to pick from a fixed menu, and that is exactly what the Choice primitive provides. Choice is a tool for selecting exactly one option from a predefined set based on an input. It is necessary to clear up a common misunderstanding right away. This is not generative categorization. You are not asking a language model to invent a label and hoping it matches your system. The model strictly evaluates the input against a criteria map you provide. It will never invent a category or return a label outside of your defined keys. Take a common scenario like routing an e-commerce support ticket. A customer sends a frustrated message stating they were charged twice but their package never arrived. You need to route this ticket to either billing, shipping, or returns. To do this, you invoke the Choice primitive and pass it a map of your options. The keys are your system identifiers, like billing or shipping, and the values are short descriptions explaining what each department handles. You then pass the customer message as the input. The primitive processes the text and returns a structured object containing three specific pieces of data. The first is the chosen option. This is the single category the model determined is the best fit. Because it is guaranteed to match one of your predefined keys exactly, you can drop this value straight into a routing function. You do not need to parse strings or check for formatting errors. The second piece of data is the full probability distribution. Routing decisions in the real world are rarely absolute. In our example, a customer complaining about a double charge for a missing package clearly spans two departments. The Choice primitive might return an object showing billing with a fifty percent probability, shipping with a forty-five percent probability, and returns with five percent. This is the part that matters. Because you have the full distribution, you can handle ambiguity programmatically. If the top choice wins by a large margin, you route it automatically. But if you see the probability split closely between billing and shipping, you can write logic that flags the ticket for manual review instead of blindly trusting a narrow winner. The third component of the response is a confidence value. While the probability distribution shows how the model weighed the options against each other, the confidence value indicates how certain the model is overall. If a user submits a ticket complaining about a completely unrelated topic, the probability distribution will still add up to one hundred percent across your options, but the overall confidence score will be extremely low. You use this score as a threshold to discard invalid or vague inputs entirely. The true power of the Choice primitive is not just text categorization, but transforming fuzzy natural language into safe, deterministic control flow while exposing the exact math you need to handle edge cases. Thanks for tuning in. Until next time!

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 6 of 14. If you tell a language model to rate an input on a scale of one to ten, it is essentially randomly guessing. It has no strict internal concept of what a seven means versus an eight. To get reliable, precise evaluations, you have to stop asking for raw numbers and start describing concrete situations. That is exactly what the Score primitive allows you to do. The Score primitive is designed to evaluate where a piece of text falls on a continuous spectrum. Instead of asking the model for a digit, you provide an ordered array of text descriptions called levels. The model analyzes your input against these descriptions and returns a fractional position indicating where the input lands along that defined scale. Take a practical scenario like rating the severity of an incoming bug report. You decide you need a three-level scale. A very common mistake developers make here is putting numbers directly into the level descriptions. Do not write your levels as zero for low severity, one for medium severity, and two for high severity. This breaks the evaluation logic. The model evaluates each text description independently and does not actually know its integer index in your array. If you just give it numbers, it loses the semantic meaning it needs to make a decision. Instead, write descriptive situations for each level. Your first level should describe a cosmetic issue that does not affect core functionality. Your second level should describe a functional bug where a clear workaround exists. Your third level should describe a blocking issue that completely stops user progress. When you pass a new bug report to the model along with these three levels, the model returns a decimal number. Because you provided three levels, the resulting index scale goes from zero to two. Zero maps exactly to the first level, one maps to the second, and two maps to the third. Because Score returns a fractional position, it captures nuance automatically. You might submit a bug report and get back a score of one point four three. This number tells you the issue falls almost halfway between the second and third levels. Perhaps the bug has a workaround for most people, but it completely blocks a specific subset of enterprise users. It is demonstrably worse than a standard workaround bug, but not quite a total system blocker. This decimal output is incredibly powerful because it saves you from trying to document every single edge case. The fractional space handles the gray areas for you. This means you can keep your array of levels short, distinct, and highly readable. Three to five well-written levels are often enough to capture highly granular differences across a vast range of inputs. This is where it gets interesting. Treat your level descriptions as fixed anchor points in a narrative, and let the model use the fractional score to measure the exact distance between them. Thanks for listening. Take care, everyone.

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 7 of 14. What if you could ask an AI thirteen different questions about a document, and get all the answers in the exact same time it takes to ask just one? Normally, asking more questions means waiting longer, but that changes when you use Parallel Questions. When you use a standard autoregressive language model to evaluate a checklist, you face a computational bottleneck. You typically ask question one, wait for the tokens to generate, ask question two, and wait again. The latency scales linearly with every question you add. Even if you push all your questions into a single large prompt, the model still generates the answers sequentially, one word after another. This introduces a second problem. Because standard models predict the next token based on all preceding tokens, the answer to your third question might subtly alter how the model interprets your fourth question. This is cross-contamination. System One models operate on a fundamentally different logic. Instead of generating conversational text, they are built to classify data. Because of this architecture, you can bundle multiple questions into a single request, and the engine will evaluate every question in parallel. It runs them simultaneously against the exact same initial state. Consider a scenario where you have a thirteen-question regulatory checklist that must be run over a newly published news article. You need to know if the article contains financial advice, if it quotes a specific executive, if it includes forward-looking statements, and ten other strict compliance checks. With an autoregressive model, gathering these distinct answers is a slow process. With Jev, you send the article and an array of all thirteen questions in one single API call. The model looks at the context and processes all thirteen checks at the exact same moment. The response you get back is a set of individual snap judgments. A snap judgment is a definitive, discrete classification for a single question. It is not a paragraph of reasoning. It is the specific answer you requested, paired directly with its corresponding question. Because the evaluation is parallel under the hood, you receive all thirteen snap judgments instantly. Adding more questions to the request incurs practically no latency penalty. The execution time remains flat whether you ask one question or twenty. This is the part that matters. The parallel execution guarantees zero cross-contamination. Because the questions are evaluated simultaneously, the outcome of question two physically cannot influence the evaluation of question twelve. Every single question gets a pristine, isolated look at the original document. There is no context rot where the model loses track of the instructions halfway through generating a long response, because it is not generating a continuous stream of text. Each question stands completely on its own. By separating the evaluation of multiple prompts into isolated parallel tracks, you gain strict consistency. When you need to run dozens of distinct checks against a single piece of context, you no longer have to choose between the high latency of sequential calls and the contamination risks of a single massive prompt. Thanks for listening, happy coding everyone!

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 8 of 14. I do not know is the absolute most important phrase an AI can produce in a production environment. When an automated process fails disastrously, it is almost always because the system lacked a mechanism to express doubt before acting. Calibration and Confidence is how you build that exact mechanism. There is a common misconception that a model's confidence is some sort of magical internal variable, or a vibe check it performs on its own output. It is not. Confidence is strictly derived from the mathematical spread of the probabilities across different options. When a decision model evaluates an input, it assigns a probability to every possible outcome. The shape of that probability distribution tells you everything. Calibration is the process of translating that shape into a reliable metric. If the shape is highly peaked, meaning one option has a massive probability and the rest are near zero, the model has high confidence. If the shape is flat, meaning several options have roughly equal probabilities, the confidence is low. You are simply collapsing the shape of the probability distribution into a single number you can use in your code. Take a system designed to categorize incoming support tickets using a choice question. A user sends a message that is vague, and two categories overlap perfectly in context. The model calculates the probabilities and finds that both category A and category B are equally likely. Because the probability distribution is flat, the mathematical collapse results in a very low confidence score. This is the part that matters. You structure your code around this score using a three-path framework. You do not just ask the model for an answer and blindly execute it. Instead, you design your application logic to handle three distinct states based on the confidence threshold. The first path is automatic action. When the confidence score is high, the system routes the ticket immediately without human intervention. The second path is proceed with caution. If the score is in the middle, you might accept the model's answer but flag it in your database for a later review, or perhaps trigger a secondary fallback check. The third path is the escalation. When the confidence score drops below your minimum threshold, like in our overlapping ticket scenario, the system refuses to guess. It defaults to a safe state and escalates the decision to a human operator. In your actual code, this looks like a straightforward conditional block. You request a decision from the model. The model returns an object containing both the selected choice and a numerical confidence score. First, you check if the confidence is greater than your high threshold. If so, you execute the automatic action. Else, if the confidence is greater than your minimum threshold, you run your caution logic. Finally, if the score falls below that minimum, you trigger the escalation function. The model makes the evaluation, but your code strictly controls the consequences based on the math. If you enjoy these episodes and want to support the show, you can search for DevStoriesEU on Patreon. The true value of a decision model is not just how often it gets things right, but how predictably it stops itself when it is about to get things wrong. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 9 of 14. The fastest network request is the one you never make. When working with traditional endpoints, you optimize performance by asking for the absolute minimum amount of data required. But when dealing with Large Language Models, that logic flips completely. To make your application faster, you should ask the model questions you might not even need. This approach is called Speculative Fan-out. If you have spent your career optimizing database queries or standard web APIs, fetching unnecessary fields feels wrong. The standard practice is to fetch exactly what you need, check a condition in your code, and then make a second request if you need more details. With language models, that sequential pattern is a trap. Every time you make a new request, you pay a massive penalty for network transit and the model time to first token. Because modern models process their input context and generate structured outputs in a heavily parallel way, asking five questions in a single payload takes almost the same amount of time as asking just one. This is the mechanical reality that makes Speculative Fan-out highly optimized rather than wasteful. Instead of building a conditional chain of API requests, you bundle every question your downstream logic might possibly need into a single schema. The model evaluates the input text once and populates all those fields simultaneously. Once the data comes back, your deterministic application code takes over. It looks at the primary condition in the payload and simply drops the answers that turn out to be irrelevant. Consider a system that triages incoming customer support tickets. When an email arrives, you need to know the general category. If that category turns out to be a software bug, you also need to know the bug severity and whether the customer provided reproducible steps. The sequential way is to ask the model for the category first, read the response, and then trigger a second API call to ask about the severity and the steps. Speculative Fan-out eliminates that second call. You configure your payload to ask for the category, the bug severity, and the reproducible steps all at once, for every single ticket that comes into the system. The model returns all three answers. This is the part that matters. Your Python code receives that complete payload and checks the category field first. If the category comes back as billing, your code routes the ticket to the finance team and entirely ignores the severity and reproducible steps fields. You throw away the speculative data in memory, which costs zero time. The time you save by avoiding a second round trip to the model completely dwarfs the negligible compute cost of generating a few extra tokens. You trade a few milliseconds of text generation for a massive reduction in overall system latency. Do not treat the language model like a database you query step by step; treat it like a compute engine that should evaluate every possible branch of your downstream logic in a single pass. That is it for today. Thanks for listening, go build something cool.

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 10 of 14. Showing a user the wrong dashboard screen is a minor glitch. Executing a wire transfer to the wrong account is a financial disaster. Yet many automated systems treat the artificial intelligence's certainty for both of these actions exactly the same. To fix this, you need a pattern called Confidence-Gated Routing. A common mistake is treating an AI confidence threshold as a global constant for your entire application. You might set a system-wide minimum confidence of point eight, assuming that blanket number makes the application safe. That approach fundamentally misunderstands how risk works. Risk is not uniform. Therefore, confidence cannot be treated as a single global filter. Routing a request based purely on intent, meaning the system just figures out what the user wants to do, is only half the equation. You need confidence as a second decision axis. You must evaluate how sure the model is against the severity of the specific action it wants to take. Consider a voice-controlled banking application. A user speaks a command, and the model parses that audio to determine the intent. If the user asks to check their checking account balance, the consequence of getting this wrong is extremely low. If the system misinterprets the request and shows the savings balance instead, the user just taps back and tries again. For this low-risk action, a confidence threshold of point six is perfectly acceptable. It keeps the interaction fast, fluid, and highly automated. Now take the exact same banking application, but the user tells it to wire five thousand dollars to a vendor. This is a destructive, high-risk action. If the model hallucinates an account number or misunderstands the amount, the damage is real and immediate. A point six confidence score is entirely unacceptable here. For a wire transfer, you must require a strict, tailored threshold, perhaps point eight five or higher. The logic flow for this pattern is straightforward. When a user request comes in, you prompt your model to return structured data containing two distinct fields. The first is the requested action. The second is a confidence score, usually represented as a float between zero and one. The model simply provides its self-assessment. Your application code then takes over. It looks up the requested action in your business logic and retrieves the specific threshold required for that exact task. You then compare the model's score against that requirement. If the score meets or exceeds the threshold, the action executes automatically. If the score falls below the required threshold, the request is gated. The system intercepts the flow before any execution happens and triggers a defined fallback mechanism. For that wire transfer that only scored a point seven five, the application pauses. It might prompt the user on their screen, asking them to manually review and confirm the transfer details. It might hand the session over to a human agent. The action degrades gracefully instead of failing catastrophically. This architectural separation is what makes the pattern effective. The language model handles the probabilistic work of guessing the intent and assigning a score. Your deterministic application code handles the safety boundaries. You cannot eliminate the probabilistic nature of large language models, but by gating execution behind action-specific thresholds, you strictly control the blast radius when they get it wrong. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 11 of 14. If you are sending every single user message to a heavy, GPT-4 class model, you are burning money and adding massive latency for no reason. The architectural fix for this is Intent Routing. Developers often default to using large language models for everything. A user asks for a simple order status, and the backend spins up a massive neural network just to figure out it needs to trigger a database lookup. This approach creates unnecessary bottlenecks. Jev resolves this by acting as a lightweight gateway. It functions as your fast, reactive System 1. It sits directly in front of your heavy, analytical System 2 models and your human agents. The intent routing pattern uses Jev strictly as a fast, cheap classifier. It evaluates the user input to determine both the intent and the complexity of the request before any heavy processing occurs. You define a strict set of allowed categories in your code. When a message arrives, Jev maps the incoming text to one of those predefined routes. It does not generate a conversational response for the user. It simply acts as a traffic director, outputting a structured category label in milliseconds. Consider a customer service routing system. You set up Jev to recognize three distinct paths. A user message comes in. Jev reads it and assigns a classification. If the message is a basic request asking where a package is, Jev classifies it as an order status intent. Your backend application receives this label and hits a simple switch statement. The code bypasses the AI generation layer entirely and executes a deterministic SQL query to fetch the tracking number. The user gets an instant response, and you spent almost zero compute. If the user message asks about compatibility between two different hardware components, Jev flags it as a complex product question. This is where the heavy lifting belongs. Your application code routes this specific query to your System 2 model. The heavier model, loaded with your product documentation, takes the required time to reason through the technical details and construct a nuanced answer. Finally, if the message contains aggressive language or describes a high-complexity billing dispute, Jev immediately classifies it for escalation. Your system routes the ticket instantly to a human agent dashboard. The human gets the context right away, avoiding the friction of forcing an angry user to argue with a conversational agent first. This is the part that matters. You are separating the decision of what to do from the actual execution. By placing a specialized decision model at the front door, you orchestrate the flow based on predetermined rules. You pass the raw text in, you get a clean routing variable out. Your existing application logic takes over from there. The expensive generation model only activates when deep reasoning is genuinely required. Treating intent classification and response generation as two distinct architectural steps is the primary way to build AI infrastructure that remains fast and cost-effective at scale. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 12 of 14. You try to tweak an LLM prompt to prefer leadership over coding skills, and suddenly you inadvertently break ten other things. The model gets confused, ignores the coding requirement entirely, or changes its grading scale. Here is how to fix that instability with simple math using Composite Scoring. Large language models are terrible at balancing competing priorities in a single prompt. If you ask a model to evaluate a candidate and weigh their Python skills slightly higher than their system design skills, the model will struggle to apply that math consistently. Composite Scoring solves this by taking the math away from the model and putting it back in your code. You stop asking the model for a final, weighted decision. Instead, you split the complex judgment into several independent Score questions. Think about screening engineering resumes. You care about Python depth, team leadership, and system design. Rather than writing one massive prompt trying to juggle these three things, you ask Jev to score them separately. You define three distinct Score questions. Python depth gets a score from one to five. Team leadership gets a score from one to five. System design gets a score from one to ten. The model just looks at the text and outputs three isolated numbers. It does not know how these numbers will be used together. Now you have three raw numbers in your code, but you cannot just add them up or apply weights immediately. Because system design is out of ten and the others are out of five, system design carries twice the raw weight by default. To fix this, you have to normalize the scores. Normalizing a score simply means dividing it by its top level number. If a candidate gets a three out of five for Python, you divide three by five to get zero point six. You do this for every score, placing them all on a standard mathematical scale from zero to one. This ensures that scales of different lengths can be merged fairly. This is the part that matters. Now that you have normalized scores, you multiply them by custom weights in your standard code to create a final composite score. You get full mathematical control over the formula without ever rewriting prompts. If you are hiring a Senior Individual Contributor, your code might multiply the Python and system design scores by zero point four each, and leadership by zero point two. If you are hiring an Engineering Manager from the exact same batch of resumes, you do not need to run the language model again. You just write a second function that takes those same normalized scores and multiplies leadership by zero point six, giving less weight to Python. You have completely separated the extraction of facts from the logic of your business. By moving the weighting out of the prompt and into your deterministic code, you gain the ability to change your grading criteria instantly without risking a regression in how the model reads the data. Thanks for hanging out. Hope you picked up something new.

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 13 of 14. If you are instantiating a new API client inside every function call, you are bottlenecking your entire AI infrastructure on TLS handshakes. This is where connection management becomes critical, and it is exactly what we are covering today with the High-Performance Python SDK. The Jev Python SDK provides two distinct entry points for your application. You have a synchronous client and an asynchronous client. For any high-throughput backend service, the asynchronous client is mandatory. Blocking your main execution threads on network calls will instantly starve your application under load. You must initialize this async client exactly once at the start of your application lifecycle. You then pass that single instance to whatever functions or background workers need it. Recreating the client per request destroys performance because every new HTTPS connection requires multiple network round trips to negotiate encryption before a single byte of your actual payload is sent. This brings us to a common misconception about network protocols. You might assume that enabling HTTP 2 will automatically improve performance because it multiplexes multiple requests over a single connection. For massive request rates, the opposite is often true. HTTP 2 places strict server-side limits on how many concurrent streams can exist on that single socket, frequently capping out at one hundred concurrent requests. When you push hundreds of requests per second, you will hit that ceiling rapidly and your requests will queue locally. Instead, forcing the client to use HTTP 1.1 allows it to open a massive pool of separate TCP connections. This approach bypasses the single-socket bottleneck and scales far better under extreme concurrency. To configure this properly, you need to adjust the underlying async library. The async client runs on aiohttp. When you initialize your client, you pass in a custom TCP connector. You set the connection limit parameter on this connector to match your expected peak concurrency. You also set a persistent keepalive timeout, typically around thirty seconds. This keeps the network sockets open during quiet periods. When a sudden burst of traffic hits your server, the connections are already established. The TLS handshakes are already done. Your requests go straight to the server without any setup latency. Network calls will inevitably fail. Rate limits will trigger, and packets will drop. When you are pushing high concurrency, you need resilience built directly into the client. The SDK allows you to define a custom retry policy and attach it during client initialization. You can specify exactly which HTTP status codes trigger a retry, such as a 429 for rate limits or a 503 for service unavailability. You define how many times to attempt the call and the delay between attempts. You should always configure this retry policy to use exponential backoff with jitter. Jitter introduces a random delay into the retry timer. If two hundred concurrent requests fail at the same time, jitter ensures they do not all retry at the exact same millisecond and cause a secondary traffic spike. By handling this at the client level, your business logic stays clean. You simply call the execution method, and the client manages the transient network failures behind the scenes. The real secret to scaling an AI backend is rarely about the model execution itself. The actual ceiling is always network overhead, and mastering your connection pool is the only way to break through it. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. Jev: System One Decision Model, episode 14 of 14. To truly master a powerful tool, you have to know exactly where it breaks. You try to pass a receipt image directly into your classifier, or you ask the model to explain why it assigned a low bug severity score, and your pipeline fails. This happens when you treat Jev like a conversational assistant. Today we cover the jagged edges of Jev version 1.13, focusing on its rigid limitations. The first hard boundary is modality. Jev only accepts text. The state you pass to the model can be a simple string or a structured JSON value, but it can never be an image, an audio file, or binary data. If your workflow involves classifying receipts or analyzing voice recordings, you must transcribe or extract that data before it ever reaches Jev. There is also a language limitation within that text processing. While the model handles English exceptionally well, its accuracy drops noticeably for Chinese, Japanese, and Korean. If you route localized user inputs in those languages, you need to account for a lower confidence threshold. The second edge is structural. Jev strictly lacks reasoning. Unlike a standard large language model, it does not think step by step, and it will not generate a paragraph explaining its logic. It is a System One model built for instant pattern recognition. If you pass in a bug report and it returns a low severity classification, you cannot prompt it to justify that decision. It simply maps the input directly to an output. This lack of reasoning text is a frequent source of confusion. All transparency into Jev decisions must come from your own architecture, not from the model chatting with you. To understand why a specific output was chosen, you have to inspect the raw probabilities returned by the API or analyze the individual weights if you are using Composite Scoring. If a task requires complex, multi-step deduction, Jev will fail if you try to execute it in a single pass. You must manually decompose the problem. Break the large task into small, independent routing or classification steps, and feed them to Jev one by one. There are also structural changes in how you interact with the model in code. If you are using the Python SDK, pay attention to the version zero point seven point zero release. The SDK migrated entirely to Pydantic for validation. This introduces breaking changes to how inputs are handled. Your state objects, whether raw strings or complex JSON payloads, are now strictly validated against Pydantic schemas. If your input types are loose or your JSON structures do not match your defined schemas exactly, the SDK will throw strict validation errors before the request even leaves your server. Jev is exceptionally fast and predictable, but only if you respect its boundaries. You have to feed it text, break your complex logic down into granular pieces, and rely on raw probabilities rather than written explanations to debug its behavior. Since this wraps up our series on Jev, I encourage you to read through the official documentation and test these boundaries hands-on in your own code. If you want to suggest a new technology for us to cover in a future series, visit devstories dot eu and let us know. Thanks for spending a few minutes with me. Until next time, take it easy.