The quote is from Diogo Almeida, not from a critic: large language models generate sequentially, which is “great for a natural conversation, but totally useless for computers.” The New Stack used it as the headline of its launch report, and the phrase has been repeated as both a provocation and a thesis.
Read literally, it is false. LLMs are extremely useful to computers; they write code, drive tools, and produce structured output through JSON modes. Read as a claim about the interface, it is sharper: a computer does not need a paragraph. It needs a value it can branch on. The argument is not that text is useless. It is that text is the wrong output when the next step is a decision.
What the critique gets right
The Hacker News thread contains the strongest version of the counterargument: type safety is not factual correctness, and a forced boolean answer cannot abstain on out-of-range input. That is correct. A typed output is not a guarantee that the value is right. It only guarantees the shape.
The Contextually Aware episode makes the same point from an operator's perspective: type safety does not guarantee a correct decision. Luis Calderon reports roughly 20x faster Coach testing, but the show notes describe it as an early observation with no established baseline, sample size, or timing boundary. The hosts distinguish it from TypeSafe's vendor benchmarks and focus on latency, confidence, and escalation.
So the critique lands on the strong version of the marketing claim: “cannot hallucinate” is not the same as “cannot be wrong.”
What the critique misses
The quote is not really about correctness. It is about the cost of the handoff. If a program asks an LLM to decide, it has to:
- Turn the state into a prompt.
- Wait for generated text.
- Parse the text.
- Validate the parsed value.
- Retry when parsing or validation fails.
That pipeline is where a lot of production complexity lives. The primitives guide describes the alternative: send a state and a typed question, get back a choice, a score, or a yes/no probability. There is nothing to parse. The advanced structure guide adds that instructions, options, criteria, and legends can be structured JSON, so the question can carry a schema rather than a prose description.
The AI Coding Daily roundup captures the practical reaction: Armin Ronacher said Jev fits applications where traditional LLMs were not viable on speed or cost. That is the real claim. Not “LLMs are useless,” but “for a bounded decision, the LLM pipeline is the expensive way to get a value.”
The “smart if statement” framing
The Merge records Allie Laabs explaining the same idea at the first Jev hackathon: instead of turning program state into a prompt and parsing text back, Jev returns a choice, a score, or a yes/no probability, with nothing to parse. She calls it “the intelligence per dollar” and says making it as cheap as possible is a cornerstone.
That is a better metaphor than “useless.” Jev is an intelligence-infused if, not a replacement for the program. The The New Stack report also cites Flavio Copes calling Jev “a smart if statement” and a small component inside an ordinary application. That is exactly the right scope: the model makes one judgment, and the application keeps the control flow.
Where the quote becomes misleading
The quote becomes misleading when it is used to argue that a decision model can replace reasoning. It cannot. The jaggedness notes list counting, date arithmetic, literal reading, and contradictory criteria as known failure modes. The TypedBench evaluation found a hosted model followed the policy but was wording-sensitive and underconfident. A decision model is a bounded classifier, not a general problem solver.
The jev-ai.org audit is a useful corrective: TypeSafe's four-workflow average put Jev at 67.8% accuracy against 74.1% for a frontier model. The cost and speed win is real; the capability win is not universal. If your task needs open-ended reasoning, the “useless for computers” framing is exactly backwards.
The useful version of the thesis
The defensible claim is: for a decision the program can specify in advance, the output should be a typed value with a probability, not a generated paragraph. That claim does not require dismissing LLMs. It requires separating two jobs:
- Generation: produce text, code, or a plan. Keep the LLM.
- Decision: choose among known options, score a bounded property, or answer yes/no. Use a decision model if the economics and accuracy fit.
The workflow evals show why the separation matters: models are more accurate, cheaper, and faster when a workflow is decomposed into typed questions than when the same policy is a single prompt. That is the strongest evidence for the thesis, and it is about workflow design, not about the uselessness of text.
A short checklist
- Read “useless for computers” as a claim about interface, not capability.
- Keep an LLM for generation and open-ended reasoning.
- Use a decision model for bounded choices, scores, and gates.
- Do not confuse typed output with correctness.
- Test the pipeline cost, not only the model cost.
- Check accuracy against the model you are replacing.
- Treat the quote as a design principle, not a product verdict.
The quote is a good provocation and a bad literal claim. The useful version is narrower: computers need values, and a model that returns values removes a parsing step. That is enough to justify the category without pretending text is obsolete.
