# Machine Native Intelligence Machine Native Intelligence is the thesis behind [[TypeSafe AI]] and [[Jev]]. The idea is simple: if most of the future consumers of AI are programs, then AI should behave like a good software dependency. TypeSafe's AI primer lists the properties it's after: **structure, reliability, observability, testability, speed, consistency and low cost**. You'll notice that "sounds smart in a chat window" isn't on the list. The whole thing rests on a prediction. TypeSafe expects large-scale automation to be "closer to 99% machine-to-machine interactions and 1% human interaction". If that's even half right, then the chat interface we've been polishing since ChatGPT is the wrong target for most model calls. A program calling a model doesn't care about warmth, formatting or a politely worded refusal. It wants a value of the right type, fast, plus an honest estimate of how likely that value is to be correct. ## Where the idea comes from [[Diogo Almeida]] (co-author of [[InstructGPT]], now CEO of TypeSafe) says he spent four years asking one question: "Models have been superhuman at chat for years, so where is all the automation?" His answer is that we trained the models for the wrong consumer. [[Reinforcement Learning From Human Feedback (RLHF)|RLHF]] optimizes for answers people prefer to read. Perfect for a chatbot. It's also a direct route to [[AI Sycophancy|sycophancy]], confident-sounding hallucinations and [[Mode Collapse|mode dropping]]. The primer says it in one line: "Human preference and machine trustworthiness are different optimization targets." The manifesto (typesafe.ai/manifesto, tagline "Build Prod, Not God") argues the point with two analogies I find useful: - **The horseless carriage.** "Early cars were designed as horseless carriages... inventors took the familiar carriage and replaced the horse with a motor." Chat is our horseless carriage: a new technology squeezed into an old form, because a conversation is how we used to get judgment out of *people* - **Databases before SQL.** "Intelligence today is like databases before SQL: powerful, but every use is bespoke." SQL turned databases into something any program could query in a standard way. TypeSafe wants the same for judgment: "smart if-statements" that any programmer can call, which the manifesto ties to the old neuro-symbolic dream (neural networks for perception, symbolic logic for reasoning) ## What changes when the consumer is a program | | Chat LLM | Machine-native model (e.g., Jev) | |---|---|---| | Output | Text you have to parse | A typed value: choice, probability, score | | Typical failure | Malformed JSON, invented option, refusal | A wrong but well-formed answer | | Uncertainty | Verbal ("I'm fairly sure") | A calibrated probability you can threshold | | Latency | Seconds | ~100 ms | | Repeatability | Moves between runs, even at temperature 0 | Probability std around 0.01 across 15 repeats ([[Self-Consistency]]) | | Composition | One big prompt | Many small questions, combined in code | Two positions follow from this, and both are more radical than they look: - **Refusals are type errors.** Almeida on Latent Space: "Refusal is just, like, obviously a type error... if you ever want this in a dependency running in the background, what happens if that refuses? That is... insanity." In a pipeline, a refusal behaves like a random crash in a library you depend on - **Stable beats deterministic.** There's no seed parameter. The goal is that semantically similar inputs give quantitatively similar outputs (they test it by injecting random UUIDs into prompts). Almeida says strict determinism would cost intelligence per dollar ## The architecture it implies Machine-native AI goes with a specific way of building: **code owns the control flow**, and the model shows up only where you need "programmable common sense" or an interpretation of unstructured data. TypeSafe's docs contrast three architectures: traditional software (a big decision tree of simple, reliable pieces), LLM agents (the model picks the next step, and every loop is another chance to go off the rails), and "AI-powered software", where each AI task is small and typed and can only answer within the options you gave it. That's their target. The docs list six properties that make this composable: structured, parallel, comparable (you can sort and threshold the outputs), fast, calibrated and self-consistent. In practice it means [[System One Primitives]] as the building blocks and [[Atomic Question Decomposition]] as the design method. And the economic ambition is big. The manifesto targets **global total factor productivity (TFP) growth of 3% within five years**, sustained for ten, which it calls "unprecedented in economic history". The name Jev is itself a bet on the [[Jevons Paradox]]: make judgment cheap enough and we'll use far more of it. ## Limits - **It's a slogan on top of an old idea.** Spam filters and intent classifiers were "machine native" decades ago. What's new is one general model that answers arbitrary questions over arbitrary options with no task-specific training - **99% is a forecast, not a measurement.** Nobody has data on the future mix of machine and human calls - **Humans don't leave the loop.** Somebody still writes the questions and the thresholds, and the docs themselves warn that coding agents write bad questions. The engineering burden moves; it doesn't disappear - **Calibration has to be earned per workflow.** "Calibrated" on the vendor's evals says little about your data (independent tests measured ECE from 0.031 to 0.107, see [[Jev]]) ## My take I think the diagnosis is right even if you never touch Jev. Open any agent harness and count the model calls that are really classification in disguise: which tool, is this relevant, is the agent stuck, how urgent is this. We send those to chat models because that's what we have, then we build retry loops around JSON parsing. Designing for a program as the consumer (typed outputs, honest probabilities, cheap enough to call everywhere) is the more sensible default for that layer. I'd keep the chat models for what they're good at: writing, open reasoning and the weird exceptions. ## References - [TypeSafe manifesto](https://typesafe.ai/manifesto) - [AI primer (TypeSafe docs)](https://docs.typesafe.ai/introduction/machine-learning-primer) - [How to build with System One (TypeSafe docs)](https://docs.typesafe.ai/concepts/how-to-build-with-system-one) - [Introducing System One Models & Jev (TypeSafe AI)](https://typesafe.ai/blog/introducing-system-one-models-and-jev) - [Jev: System One models for Prod, not God, with Diogo Almeida (Latent Space)](https://www.latent.space/p/jev) ## Related - [[TypeSafe AI]] - [[Jev]] - [[System One Models]] - [[Decision Models (DMs)]] - [[System One Primitives]] - [[Atomic Question Decomposition]] - [[Jevons Paradox]] - [[Reinforcement Learning From Human Feedback (RLHF)]] - [[Reinforcement Learning for Calibrated Decisions (RLCD)]] - [[AI Sycophancy]] - [[Mode Collapse]] - [[Software 2.0]] - [[LLM Structured Outputs]] - [[AI Agents]]