7 software factory decisions that Jev should handle

TypeSafe AI shipped Jev, a non-LLM model that returns one answer from a fixed set of options with an attached probability, targeting the hundreds of micro-decisions inside software factories. Jev runs in 70 to 500 milliseconds versus the seconds an LLM call takes, with input tokens priced at $0.042 per million and output tokens free, and the company proposes seven uses including ticket priority scoring, resource ownership assignment, and ticket routing to owning agents. The pitch is that software factory decisions need speed and a calibrated confidence score rather than creativity.

Last week, TypeSafe AI shipped something that isn’t an LLM. I’m sure you’ve heard about it non-stop. It’s called Jev. In short, you give it a structured question with a fixed set of possible answers, and it gives you back one of those answers with a probability attached. Just: here’s the answer, here’s how sure I am. If you’ve spent any time building a software factory like we have, you probably also realize that this is a huge step forward. Software factories are really just hundreds of micro-decisions linked together. Every one of those decisions has a fixed set of outcomes. But until now, many of them have been running through a model that was trained to write essays or write code. Then it wraps the output in regex and hopes it parses. Jev is built for exactly these kinds of decisions, and it does it in 70 to 500 milliseconds instead of the seconds an LLM call takes, at a fraction of the cost input tokens run $0.042 per million, output tokens are free, because there’s no long output to generate . Software factories are full of judgment calls that don’t need creativity . They need speed and a calibrated confidence score. There are hundreds of places for Jev in the software factory, but here are 7 ideas to start with: Idea 1: Ticket scoring bug priority score The problem: Two bugs with nearly identical titles can carry completely different priority. “Checkout button misaligned on mobile” and “checkout button unresponsive on mobile” look the same from the title. One’s cosmetic. The other is blocking revenue on a customer-facing service with an SLA. How LLMs tried to solve it: An LLM reading ticket text can pick up on “unresponsive” sounding worse than “misaligned,” but it’s pattern-matching language, not checking whether the underlying service actually carries an SLA. That means it can just as easily get fooled by a dramatically worded cosmetic bug. How it works with Jev: The priority decision runs on structured catalog data instead of ticket language: service criticality tier, customer-facing SLA flag, recurrence count over the last 90 days. Two similarly worded tickets score differently because the services behind them are actually different. What to forward to Jev: Service criticality tier, customer-facing SLA flag, recurrence count over the last 90 days. What it gives back: A priority score for the ticket. Idea 2: Resource ownership assignment / assessment The problem: Every catalog has orphans: the Lambda nobody’s touched since the reorg, the repo with three former teams’ names still in the commit history. When one of those breaks, “who do we page” becomes a 20-minute Slack thread before anyone starts fixing anything. How LLMs tried to solve it: You could ask an LLM to summarize git history and guess an owner, but it’s generating a narrative answer from unstructured commit messages. It’ll happily name a team even when the signal is weak, and it won’t tell you it’s guessing. How it works with Jev: Feed Jev the actual signals as structured input: recent git activity, deploy history, existing catalog tags. You get back a ranked owner with a real confidence score. An orphaned Lambda with no owner field set should come back a strong match to whichever team made the last several deploys to it. If the activity is old or inconsistent, the score should drop to say so. What to forward to Jev: Recent git activity, deploy history, existing catalog tags. What it gives back: The most likely owning team, with a confidence score. Idea 3: Routing tickets to the relevant owning agent The problem: Most routing is keyword matching against a Slack channel name, or a static rules file nobody’s updated since the last reorg. Neither one knows the payments service got a new owner last sprint. How LLMs tried to solve it: You’d prompt an LLM with the ticket text and a list of teams and ask it to pick one. It works fine on the obvious cases and quietly guesses on the ambiguous ones, because the model has no reliable way to say “I’m only 40% sure.” It just picks a team and states it with the same confidence as everything else it writes. How it works with Jev: The routing decision is a fixed set of possible owners, not open text. Jev takes the ticket plus the catalog’s ownership data service, team, on-call, all connected and returns the most likely owning agent with an actual probability attached, in under half a second. What to forward to Jev: The ticket’s service, plus the catalog’s current ownership data for that service team, on-call . What it gives back: The owning agent to route to, with a confidence score. Idea 4: Agent decision making like in incident response: choosing a runbook The problem: When a service is throwing errors and the on-call agent suggests a runbook and it’s wrong, a human might read it and correct course. If the agent runs the runbook itself and it’s wrong, production just changed based on a guess. Same mistake, but very different amount of damage. How LLMs tried to solve it: An LLM given an incident and a list of runbooks will generate a plausible-sounding recommendation whether or not it’s actually the best match. It’s optimized to produce a confident, well-written answer because it wants to please you. How it works with Jev: Given the incident signature, Jev ranks the matching runbooks by how often each one resolved a similar incident historically, with a calibrated score per option, not a single generated recommendation that might be overconfident. What to forward to Jev: The incident signature, plus the outcome history of each candidate runbook. What it gives back: Each runbook ranked, with a confidence score per option. Idea 5: Dynamic skill routing for agents The problem: A skill is a defined capability an agent can invoke: restart this service, query these logs, open a PR. Most setups pick the skill by ticket type alone, so “database connection timeout” always triggers “restart service,” whether it’s staging or a production database under a change freeze. How LLMs tried to solve it: You’d give the LLM the ticket and a list of available skills and let it choose. It can read “production” in the ticket, but it has no structured way to check a freeze flag or a criticality tier against a hard rule. It’s inferring from text, which means the one time it matters most a freeze in effect is exactly when a text-inference model is most likely to miss it. How it works with Jev: The skill decision takes structured inputs directly environment, criticality tier, freeze status , not just ticket text, so the same ticket type can resolve to a different skill depending on the actual state of the system, checked as data rather than inferred from language. What to forward to Jev: The ticket type, plus the current environment, criticality tier, and freeze status. What it gives back: Which skill to invoke. Idea 6: Eval assessment The problem: If an agent suggested a fix, you need to check, after the fact, whether it actually resolved the issue, not whether it ran without erroring. How LLMs tried to solve it: Teams often skip this step entirely, or ask an LLM to “evaluate” the outcome in a follow-up prompt. That just produces another generated opinion, with the same lack of calibration as the original suggestion. You end up grading the model with the model. How it works with Jev: The eval question is a fixed-outcome decision: did the ticket reopen, did the fix match what a human would have done, was it faster or slower than the historical average. That’s exactly the shape of question Jev is built to answer cheaply and continuously, rather than as an occasional expensive LLM call. What to forward to Jev: What the agent suggested, and what actually happened did the ticket reopen, how long it took versus the historical average . What it gives back: A pass/fail on whether the decision was actually good. Idea 7: Skill assessment The problem: A skill can be invoked constantly and still be bad. “Restart service” might fire 50 times a week and still not resolve the underlying issue thirty percent of the time. How LLMs tried to solve it: This mostly wasn’t solved at all. Measuring resolution rate per skill requires checking outcomes across thousands of invocations, and running that through an LLM call per invocation is too slow and too expensive to do at that volume, so most teams just don’t do it. How it works with Jev: At 70-500ms and a fraction of the cost per call, checking “did this skill’s outcome actually resolve the ticket” becomes cheap enough to run on every invocation, not a sample. That’s what turns skill health from a quarterly audit into a running number. What to forward to Jev: Each invocation’s outcome did it run without erroring, did the ticket actually get resolved . What it gives back: A resolution rate per skill, separate from the run-success rate. The truth is, none of these require Jev specifically. I’m sure other models will pop up that do similar things. What is cool to see is that the assumption that a general LLM was the right tool for the whole software factory seems to be wrong. If your factory is routing every one of these through the same model you use to draft a PR description, you’re paying generation-model prices and latency for a fixed-set answer that shouldn’t cost either. Excited to see how the software factory changes with Jev What other decisions in the software factory should Jev handle? Comment below