I’ve been asking the same question for four years: if language models are superhuman at chat, where is all the automation?
I spent time at OpenAI working on the methods that made models useful at following instructions, research that eventually became part of ChatGPT. At the time, I genuinely believed chat models would lead us to AGI. But after stepping back and watching how these systems actually behaved in production, something became obvious: there was something fundamentally missing.
The missing piece wasn’t raw intelligence. It was the interface between intelligence and code.
The Hallucination Tax on Automation
Large language models are phenomenal at generating human-readable text. That flexibility is their superpower for chat and creative tasks. But it’s also their critical weakness for automation. When a model can output literally anything, constraining that output to something your code can reliably use becomes expensive and fragile.
Every tool call gets wrapped in parsing logic. Every structured output needs validation. And even with guardrails, models still hallucinate type errors at rates that kill production reliability. Prompt a model for a confidence score and it tends to be overconfident and inconsistent. A system that works 95% of the time but doesn’t know when it’s in the 5% failure case can’t actually automate anything critical.
This is why most “AI automation” today is really “AI + human-in-the-loop.” The human is there because we haven’t solved the interface problem.
A New Class: System One Models
This is where TypeSafe’s announcement of Jev becomes genuinely interesting. They’re not claiming to build a smarter model than GPT-6 Astra or Fable. Instead, they’re building a different kind of model entirely: one optimized for fast, structured decisions that software can use directly.
The architecture is purpose-built for this. Instead of autoregressively generating tokens one at a time, Jev generates all outputs in parallel. Instead of strings, it outputs type-safe structured values with calibrated probabilities. Hallucinations are mathematically impossible because the output schema is constrained at generation time.
The performance numbers are striking: 40x to 200x faster than frontier models on comparable tasks, with better calibrated confidence scores. Response times drop from seconds down to 70-500ms. At that speed, AI becomes something you can embed in real-time user experiences, not just background batch jobs.
But here’s what matters more than the raw numbers: the cost model becomes fundamentally different. When your model runs in 100ms instead of 10 seconds, the economics of automation shift. What was prohibitively expensive becomes viable at scale.
Where This Changes Everything
I’m particularly excited about the implications for https://mgks.dev/tags/automation/ at the application layer. Instead of hand-writing brittle conditional logic, engineers can now use calibrated AI decisions as fuzzy rules within normal code. Classify items, route workflows, score candidates, extract fields from messy data, branch based on probabilistic confidence thresholds.
The use cases they’re showing are telling. A game bot that reacts in real-time to hundreds of possible choices. A Wikipedia link navigation task where the model must reason through thousands of high-cardinality decisions without hallucinating invalid links. These aren’t theoretical parlor tricks; they’re demonstrations of what becomes possible when latency, reliability, and cost all flip from constraints into features.
The demos also reveal how much production automation was previously leaving money on the table. Engineers worried about making 10 queries per second because they assumed the costs would be prohibitive. With Jev at $0.042 per million input tokens, that same workload costs ~$7/hour. Suddenly you’re not choosing between “automate this” or “hire a human.” You’re choosing between many more options.
The Honest Caveats
To their credit, TypeSafe is remarkably transparent about limitations. They’re using reference models from OpenAI and Anthropic for evaluation, which biases the numbers against newer competitors. The workflows in their evals were constructed by their capabilities team, introducing some bias toward favorable results. The speed numbers come from their West Coast infrastructure, which may not match your latency in production.
They’re also being clear about what they’re giving up: Jev can’t do open-ended text generation, creative writing, or general chat. This isn’t a model replacement. It’s a specialized tool for a specific class of problem that wasn’t worth solving well until now.
What This Means for Engineering
I think we’re at an inflection point in how AI integrates into software systems. For years, the industry tried to bolt chat-optimized models onto automation problems and accepted the friction. Now we have models designed from first principles around the actual requirements of production code.
This matters because it makes AI feel less like magic and more like infrastructure. When your model can’t hallucinate, when every output comes with honest confidence scores, when latency is predictable, integration becomes straightforward. You stop worrying about whether the model will embarrass you and start thinking about how to decompose your domain into the decisions you need made.
The real test will be whether this architectural approach scales beyond TypeSafe, and whether the broader AI community recognizes that chat models and https://mgks.dev/tags/llms/ are solving different problems that maybe need different solutions. If that shift happens, automation stops being a future promise and starts being something engineers can reliably build today.