• the app is live at ai-grader-shwa.onrender.com
  • public demo account — username public, password public — with its own isolated sandbox, so you can click through the whole thing without touching anyone’s data
• the code is open source at github.com/LiangGou/ai-grader

Background

My wife is a high school math teacher. Every week she gives a test, and every week she grades more than a hundred papers. The process is entirely manual: she writes the rubric, works through each paper against it, tallies the scores, then types every score into the school’s system. One weekly test costs her three to five hours of grading.

The thought that kept nagging me: AI can already do every step of this. Vision models can read handwritten math. They are good at math. They can draft a rubric, verify a solution step by step, and assign partial credit consistently — arguably more consistently than a tired human at 11pm. So I decided to build her an AI grader, with my wife as customer zero.

And I gave myself one constraint, as an experiment: I would not write any code. No editor, no terminal commands typed by me, no “let me just fix this one line.” From the first design conversation to the production deployment, everything would go through my AI assistant, Muse. I wanted to find out what that process actually feels like — where it shines, where it breaks, and what my job becomes when I’m not the one typing.

The build

It started, as these things do, with a conversation. I described the problem and asked for a design doc. Back came a plan for a Flask web app: photograph or upload homework, generate a grading rubric two ways (reconstruct one from an already-graded example, or generate an AP-style rubric from scratch), grade each paper with a vision model against that rubric, then show class statistics and export a CSV for the school system. I read the doc, asked for changes, and approved it. That was the last “traditional” step of the whole project.

Then came the coding phase, and this is where my role changed completely. I stopped being a programmer and became something closer to a product manager with a very fast engineering team. The milestones, roughly:

Day 1 — a working app. From the approved design to a running app I could open on my phone the same day. Photograph a paper, get a rubric, get a grade. The core loop worked.

The rubric engine. This turned out to be the heart of the product. Teachers don’t just want a score; they want a rubric they trust. So the app reconstructs a rubric from a teacher’s graded example, or generates an AP-style one where the per-question point totals stay locked to the teacher’s original total. Every question gets a “retry with AI” button when the first attempt fails, and everything auto-saves.

The quality loop. Here is where it got interesting. Instead of me judging output quality by vibes, I had the agent build an eval bank out of official AP Calculus AB free-response exams — real questions, real scoring guidelines. Then it iterated: fix the prompt, fix the workflow, re-run the exams, measure. Question detection went from flaky to reliable through a per-photo pipeline. The solver got a “generate then verify” discipline — ten attempts to solve, then an independent verification pass, never a shrug of “unsure.” Diagrams get generated when a question needs one. Each fix came with a regression test, so nothing ever silently regressed.

Two more agents as reviewers. Before anything shipped, every code change was reviewed by two other models — GPT and Claude Opus — in parallel. They caught real bugs: authorization holes, race conditions, a token-budget bypass. Findings got fixed with their own regression tests, then re-reviewed until clean. AI reviewing AI, with me only reading the summary.

Browser testing, like a human. The agent drives a real Chromium browser: logs in, creates a class, uploads exam pages, generates a rubric, grades a paper, checks the results page, downloads the CSV. It catches what unit tests can’t — the button that doesn’t work on a phone screen, the flow that dead-ends. I did my own acceptance testing too, on my iPhone, sending back terse directives. My most-used instruction became “fix one by one”: one bug, root cause, test, review, deploy, verify. No batching, no shortcuts.

Deployment I never specified. I deliberately never told it how to deploy. I just said: free tier, easy to set up. It evaluated the options and picked Render for hosting and Neon for Postgres, wired up persistence so uploads survive restarts, and put the OpenAI key behind a settings page. Then it added the public demo account — full data isolation, rate limits, a token budget, and a monitoring dashboard so I can watch what strangers do with my API key.

Five days after the first conversation, the app was in production, open-sourced under MIT, and my wife was looking at her first AI-graded class.

One number worth sharing: the whole thing took about a week, from the idea — which came up in a conversation with a couple of friends last week — to production. Every evening after work I spent roughly an hour talking to Muse: describing what I wanted, reviewing what came back, pointing at problems. That talking time added up to around five hours total. I never touched the code — not once.

Lessons learned

The agent is a project manager, not a code generator. The popular image is “AI writes code fast.” What actually happened: it managed the whole loop — broke work into steps, wrote the tests, ran them, got the reviews, deployed, verified in production, and reported back with a commit hash. Code was just one artifact among many.

My job became specifying acceptance, not implementation. The highest-leverage thing I did was define what “done” looks like: “every bug gets a regression test,” “two-model review before shipping,” “verify in production, then test in a browser.” Once the quality gates were set, I mostly just pointed at problems and said “fix one by one.”

Evals turn arguments into measurements. The single best decision was grounding quality in real AP exams. Without that, prompt iteration is vibes. With it, every change had a number attached.

AI review works, but only as a gate, not a ritual. The two-model review caught things I would never have found by reading diffs — including issues in code the agent itself had written and I had already “approved.” The key was making it blocking: nothing ships until both reviewers are clean.

The honest caveats. It wasn’t magic. Vague instructions produced vague results — “make grading better” went nowhere, while “question detection finds 4 of 6 questions on this exam page; fix it” got fixed. Long tasks needed supervision; I checked in, redirected, occasionally stopped it mid-flight. There’s also plenty of refactoring and optimization I haven’t gotten to — the code works, but it isn’t pretty yet. And I remained the only one who could say whether a rubric was actually good — taste, it turns out, is still the scarcest resource. The agent never got tired, but it also never knew which corners mattered until I told it.

The deeper surprise was how the work felt. I have spent years as the person who types. Letting go of the keyboard felt, at first, like giving up control. By the end it felt like the opposite: I operated at the level of decisions — what to build, what good looks like, what ships — and everything below that happened faster and more carefully than I would have done it myself.

My wife hasn’t gotten her three to five hours back yet — customer zero is still evaluating. But for the first time, that feels like a matter of weeks, not years. And I never wrote a line of code.

The original post made a bold claim: that expressing a four-dimensional world through a one-dimensional representation could only produce “stochastic parrots” — fluent mimics with no real understanding. But rather than relitigate who was right, the more interesting question is: what exactly was wrong with the original claim, and what survives of the worry behind it?

Why the worry felt reasonable

The intuition is easy to share. An image is two-dimensional; video adds time; the world adds depth. A language model sees all of it flattened into a one-dimensional sequence of tokens. It feels like something must be lost — like describing a sculpture over the phone and expecting the listener to sculpt it back. Surely a model built natively for 2D or 3D, with the right inductive biases, should learn spatial structure more naturally than a sequence model brute-forcing its way there.

That was the bet: 1D could overfit 2D or 3D tasks, but only inefficiently, and native models would win on learning speed. It turned out to be wrong in practice — but I think it’s worth being precise about which part was wrong, because the useful version of the worry is still alive.

Three questions, not one

Here’s the distinction that cleared it up for me. There are three separate questions, and they need three separate kinds of evidence:

1. Representability — can the information be encoded at all?
2. Learning efficiency — how much data and training compute does it take to reach a given quality?
3. Generalization — does the learned capability survive new viewpoints, new layouts, new interventions, or does it lean on familiar shortcuts?

The original “stochastic parrots” claim blurred all three together. But they come apart cleanly.

On representability, the math is almost embarrassingly simple. Take an image of known width W: numbering each pixel row by row (k = iW + j) maps every 2D coordinate to a unique sequence position, reversibly. Nothing is lost — you can always reconstruct the image from the sequence. And a sequence index says nothing about the dimensionality of the model’s internal states; a “1D” model can carry rich high-dimensional features at every position. So yes, a sequence can encode spatial information. That part of the old claim was simply mistaken, and the retraction is correct.

But — and this is the part I keep coming back to — encodability says nothing about how efficiently a model discovers the spatial structure, or whether it generalizes. A model can satisfy question 1 while failing questions 2 and 3 completely. Knowing that pixels can be numbered tells you nothing about whether training will find the geometry, how much data that takes, or whether the result transfers to a viewpoint it has never seen.

What ViT does and doesn’t prove

The best empirical datapoint here is the Vision Transformer: a transformer operating on sequences of image patches learned genuinely useful image classification. [2] That’s real evidence that sequence models can do vision — I don’t want to understate it.

What it doesn’t establish is equal efficiency across architectures, or understanding of a dynamic 3D world. Maybe spatial inductive biases help on some tasks; maybe position encodings and scale compensate on others. Those are empirical comparisons, not deductions. And image classification is a long way from predicting what a scene looks like after you move the camera — which, as Part One showed, is exactly where today’s models stumble.

The worry, restated

So here’s the humble version of the original warning, the one I’d defend: a successful render — like the one in Part One — proves representability, not learning efficiency and not robust generalization. Neither does the mere existence of an executable answer. The shortcuts concern isn’t settled by showing that encoding works; it’s settled by held-out tests: new viewpoints, compositional scene changes, action-dependent predictions, with task quality and training cost measured separately.

The author’s retraction was right about the letter of his old claim. The spirit of it — don’t confuse “can be encoded” with “is efficiently learned” — is a distinction the whole field could stand to keep.

They don’t have to compete

There’s a framing I’d like to push back on gently — including my own from Part One: the idea that it’s code versus native generators, with a winner. In practice, the interesting systems compose them, and the debate’s vocabulary is blurrier than it looks.

First, the labels overlap. “Sequence model” describes how inputs are organized; “coding model” describes generating executable programs; “native generator” describes a learned model producing images or 3D content directly. A single system can be all three at once — the diffusion transformer (DiT) is a native image generator whose backbone is a transformer running over patches. [3] Sequence all the way down.

Second, when a coding model “builds a 3D scene,” notice where the work actually happens. The model writes down geometry and material parameters; the renderer — an explicit algorithm — computes the intersections, shadows, and reflections. Much of the spatial calculation isn’t learned at all; it’s executed. So a compact program is no evidence that spatial understanding was learned cheaply. The cost of learning to write that code remains unknown, and the credit belongs to the whole pipeline, not to the program text alone.

And third, the combinations are where the real progress is. An LLM plans a scene layout in boxes, and a diffusion model fills it in following that layout. [4] A 2D image prior guides the optimization of a 3D scene. [5] Robot programs compose perception outputs with control APIs. [6] In each case the capability belongs to the complete system — no single component gets to claim the win.

There’s a sharper version of this composition idea making the rounds in robotics: real to sim to real. You learn the real distribution from real scenes, use it to generate the descriptors — layouts, materials, lighting — that drive simulation, then simulate at scale: scenarios you’d never collect by hand. That synthetic data feeds back into training, and the next round of models handles the real world better. It’s the same pattern as above, closed into a loop: the renderer keeps the geometry honest, the learned distribution keeps the appearance real, and each pass makes the other more faithful.

So maybe the right question isn’t which representation wins. It’s which combination of representations, learned models, tools, and feedback delivers reliable performance under a task’s constraints — and being honest about which component did which part of the work.

Next in the series: what Fodor’s Language of Thought actually supports — and what it doesn’t.

References

[1] Hokin的学术笔记. (n.d.). Coding Models之后 [After Coding Models]. Eleven-image Chinese illustrated post. Original post. English translation (translated by GPT-6).

[2] Dosovitskiy, A., et al. (2021). An Image Is Worth 16×16 Words: Transformers for Image Recognition at Scale. ICLR. arXiv:2010.11929.

[3] Peebles, W., & Xie, S. (2022). Scalable Diffusion Models with Transformers. arXiv:2212.09748.

[4] Lian, L., Li, B., Yala, A., & Darrell, T. (2023). LLM-grounded Diffusion: Enhancing Prompt Understanding of Text-to-Image Models with Large Language Models. arXiv:2305.13655.

[5] Poole, B., Jain, A., Barron, J. T., & Mildenhall, B. (2022). DreamFusion: Text-to-3D using 2D Diffusion. arXiv:2209.14988.

[6] Liang, J., et al. (2023). Code as Policies: Language Model Programs for Embodied Control. ICRA. arXiv:2209.07753.

I came across a thought-provoking post — “After Coding Models,” eleven images, dense with claims. The core observation is hard to argue with: today’s strongest coding models don’t just write software. They generate images, animations, 3D scenes, and interactive environments by writing executable programs. Then comes the big question: is code the optimal universal representation? Can you express anything — a photograph, a video, a world — as a program?

The question the post poses stuck with me: if code can express images, video, 3D scenes — is it the optimal universal representation? It’s a seductive idea. But there’s a gap between expressing something and understanding it: a program that renders a room doesn’t necessarily grasp the room the way a model trained on a million rooms might. I wanted to see how much of the claim survives contact with evidence. This is the first of a short series working through them one at a time — mostly to organize my own thinking, and in case it’s useful to others.

Claim 1: code can produce an image with no diffusion model

The first claim held up better than I expected. Here’s the idea, stripped down: a program describes a scene — where the objects are, what they’re made of, where the light is, where the camera sits. A renderer then computes how light bounces around that scene and what the camera sees. Reflections, refraction through glass, soft shadows — all of it falls out of the math. No diffusion model, no training data, no image assets anywhere in the loop. [2]

To make it concrete, I had a model write a small ray-tracer in Python and NumPy: three spheres on a checkerboard floor, a warm area light, a camera. Nothing else. It ran on CPU for about a minute and a half and produced this:

Rendered entirely from code: analytic spheres, procedural checkerboard, area light, path tracing. No diffusion model, no textures, no assets.

That’s a real image, computed from a scene description. The reflections and the glass refraction aren’t faked — they’re the renderer solving light transport from the geometry the program specified.

The honest caveats

I should be upfront about the limits here, because they matter. This image looks like simple CGI, not a photograph — you can see the sampling noise if you look closely. And notice where the intelligence actually lives in this pipeline: the renderer does the heavy lifting of turning geometry into pixels. The model’s job was to write down the scene: sphere positions, materials, light, camera. Describing a scene precisely in code is genuinely useful work, but it’s not the same as understanding what a room looks like from having seen a million rooms.

There’s a deeper point the experiment makes visible: the renderer can’t invent what the program doesn’t specify. It won’t recover the furniture of a real room from an incomplete description. Every detail in that image — the checkerboard, the cyan tint in the glass — came from the program or the renderer’s math. A learned image model, by contrast, fills in rich appearance from its training: textures, environments, grime on the floor. It just can’t tell you exactly where anything is.

So the first claim holds up, within its boundaries: code can express a scene and render it without any learned image model. Representability is established. But representability is the easy question. The hard ones — whether code is the efficient way for a model to learn spatial understanding, and whether it generalizes without shortcuts — need different evidence. To the original author’s credit, he retracted his own earlier warning on exactly this point, and I’ll take that up in a later installment.

Control vs. photorealism

The more revealing test, to me, was a head-to-head: the same scene description, given two ways. Once as a coding brief — write a program that renders this scene. Once as a plain image prompt — just generate the picture. Then two follow-up edits applied to each: turn the small sphere blue, and move the camera to the other side.

Same brief, two routes, two edits. The third row is the telling one: after the camera move, the code route keeps the chrome sphere on the left; the generated image flips the scene.

The base images tell one story: the generated one looks more photographic — textured floor tiles, an outdoor world reflected in the chrome — while the code output looks like simple CGI. The learned image model fills in rich appearance from its training; the program only knows what it was told.

The blue-sphere edit went fine on both sides. But the camera move is where it gets interesting. Moving the camera from one side to the other should keep the chrome sphere on the left and the glass on the right — I verified this by projecting the actual 3D coordinates through the new camera. The code route does exactly that: same world, new viewpoint, occlusion updates correctly. The generated image, meanwhile, produces a plausible-looking new picture with the spheres reversed — glass on the left, chrome on the right. It looks convincing. It’s just wrong.

That’s the tradeoff in one image: pretty is not the same as correct. Code gives you an inspectable scene — named parameters for every object, light, and camera angle that you can check and constrain. Direct generation gives you a beautiful picture with no guarantees about the world behind it. For anything where the geometry matters — and in the physical world, it always does — that inspectability is worth more than photorealism.

What’s next

Representability is established and control is real. But the harder questions remain: whether code is the efficient way for a model to learn spatial understanding, and whether it generalizes without shortcuts. The original author retracted his own earlier warning on exactly this point — next, I’ll work through what that retraction does and doesn’t settle.

This is part 1 of a series examining the claims in “After Coding Models.” Next: Encoding Isn’t Understanding? Part Two

Appendix: code, prompts, and data

Everything below is from the investigation this post is based on. The full source files live in this repo: rendering probe · comparison renderer · prompts · edit actions · render logs · image-tool logs · camera projection checks.

To rerun the rendering experiments (Python 3, NumPy installed):

python coding_render_probe.py
python coding_image_comparison.py --variant all

References

[1] Hokin的学术笔记. (n.d.). Coding Models之后 [After Coding Models]. Eleven-image Chinese illustrated post. Original post. English translation (translated by GPT-6).

[2] Pharr, M., Jakob, W., & Humphreys, G. (2023). Physically Based Rendering: From Theory to Implementation (4th ed.). Open textbook.

Today, anyone can generate a polished essay, a compelling image, a product strategy, a software prototype, or a hundred new ideas in minutes. Capabilities that once took years of training now take a prompt.

But when creation becomes cheap, something else becomes scarce: judgment.

The defining question of the AI era is no longer “Can you make something?” It’s “Do you know what is worth making?”

That is taste.

Taste is more than style

Taste gets mistaken for aesthetics — spotting what looks elegant or sounds sophisticated. That’s the shallow version.

Real taste is the ability to distinguish:

• Substance from polish
• Insight from repetition
• Originality from novelty
• Clarity from oversimplification
• What is merely possible from what truly matters

AI can generate one hundred plausible answers. Taste is rejecting ninety-nine of them.

AI can imitate the style of any great writer, designer, or thinker. But style is the visible surface. Underneath are lived experience, values, obsession, sacrifice — thousands of decisions accumulated over time. AI reproduces the pattern without inheriting the reason the pattern mattered.

The bottleneck moved

In the past, execution was the filter. Books, films, products, experiments — making any of them cost so much time and skill that only a few ideas ever got built.

That constraint is gone. We can now generate more ideas than we can evaluate, more content than we can consume, more software than we can responsibly maintain.

The bottleneck moved from generation to selection. And selection is a human job. When AI explores what is possible, someone has to decide:

Which idea deserves attention?

Which result can be trusted?

Which feature should never be built?

Which problem is worth years of your life?

Those aren’t technical questions. They need context, values, accountability — taste.

I worry more about homogenization than replacement

Everyone argues about whether AI will replace us. I worry about something more immediate: homogenization.

These models are trained on all of us. They are extremely good at producing the plausible, familiar answer — the statistical average of what has worked before. Used actively, that’s leverage. Used passively, it drags everything toward the middle.

Writing becomes polished but interchangeable. Products become feature-rich but indistinct. Strategies become comprehensive but uncommitted. Everyone gets the same models, the same patterns, the same answers.

When everyone can produce competent work, competence stops being the differentiator. Point of view, conviction, taste — that’s what’s left.

Form your judgment first

The best human-AI relationship isn’t competition. It’s a loop: I define what matters, AI expands what’s possible, I select and redirect, AI refines and executes — and I decide whether the result deserves to exist.

Sequence matters. Ask AI what to think before you’ve thought, and you borrow its center of gravity: a convincing synthesis of existing thought, but not a point of view that’s yours.

My rule: form your judgment first, then let AI challenge and amplify it. Don’t let it remove you from the process — let it push you toward the most human parts: framing, meaning, choice, responsibility.

The moat isn’t the model

I build AI systems for a living, and here’s what I’ve learned: model access won’t be the durable advantage. Models get better, cheaper, interchangeable.

The advantage will be everything around the model — the data you trust, the standards you hold, how quickly you learn what’s actually good. An org with weak judgment uses AI to produce mediocre work faster. An org with strong taste uses it to explore bolder ideas and recognize signal earlier.

Same for leadership. The leaders who matter won’t be the ones generating the most answers. They’ll be the ones asking the right questions, holding the bar, protecting the weird idea, knowing when to stop.

AI optimizes the path. We still choose the destination.

Taste is the new intelligence

The real opportunity isn’t productivity. It’s spending less time generating every option and more time deciding what deserves your energy.

But it’s not automatic. AI amplifies whatever you bring — originality or imitation, clarity or confusion, courage or conformity.

So maybe the most important skill of the AI era isn’t prompting or coding. It’s taste: knowing what matters, rejecting what doesn’t, standing behind what remains.

AI gives us infinite possibilities. Taste gives them direction.

The morning the car made its case

Last weekend, my daughter had a soccer game in Santa Cruz. Early game — alarm at 6, out the door at 7, me still dizzy and half-awake. I turn from our street onto the main road and suddenly there’s a horn blaring, a car swerving — someone nearly plows into us. I was furious. One careless moment and the whole weekend is ruined: no game, no nothing.

Here’s the part that actually shocked me: I never even saw them. My daughter didn’t see them either. We were just lucky.

And then the reflection hit. I’ve been using Tesla’s FSD for about a year and a half now. Searching my memory over at least the last six months, I cannot recall a single moment like that — not one life-threatening scare, not one near-miss where FSD put us in danger. Meanwhile, driving myself for twenty minutes on a groggy Saturday morning, I was in one.

My bar for AGI in autonomous driving was always simple: make fewer mistakes than I do. Not perfection — just better than the human baseline. FSD clears that bar. Not in a demo, not on a benchmark — on my own streets, over eighteen months of real driving. The mistakes that trigger reflection are the critical ones, and FSD simply isn’t making them while I still am.

In autonomous driving, AGI isn’t on the roadmap. It’s in the driveway.

The assistant that planned my Christmas

The second shock came from Muse, Meta’s personal assistant. I handed it two jobs I dread: planning our family’s France trip over Christmas, and preparing our Schengen visa applications.

Start with the trip. I gave it our dates, it searched flights, gave recommendations, and I booked. But the real pain was always hotels. My filter is specific: star rating plus Google rating. I don’t trust the ratings on Booking.com or Hotels.com — they’re not calibrated to any standard I recognize. But Google’s ratings don’t live inside those booking platforms, so hotel hunting used to mean cross-referencing everything by hand across half a dozen sites.

I gave Muse my criteria. It went across the platforms, checked Google reviews, verified prices and availability, and came back with a plan. Then it worked the bookings — across five different platforms, preparing each reservation for my approval, handling the registrations, logins, and form-filling.

But here’s what genuinely shocked me: it caught things I would never have caught. At our Paris hotel, the connecting rooms came in two bedding configurations — two twins or one queen — and the booking didn’t say which we’d get. I would have overlooked that completely. Muse surfaced it, asked me which configuration we needed, and sent the hotel an email with all the reservation details filled in to lock it down. It did that kind of thing over and over — confirmation emails drafted, details double-checked, loose ends tied up. Hours of meticulous work in a domain where I don’t even know what I don’t know.

Then the Schengen visa — the paperwork I hate most in the world. Same treatment: it read the official France visa pages, laid out the process, the document list, the cover letter requirements. (The visa portal itself blocked automation, so I registered there myself — the one step it couldn’t do for me.) A package I would have procrastinated on for weeks, mapped out and half-assembled.

The one thing that gives me pause

Privacy. To do all of this, Muse held my phone number, my email address, my daughters’ ages — and for the visa, passport details. Extraordinarily sensitive information, flowing through an assistant to get the job done.

Of course, I pulled the passport out of the process — I handled that part myself. But even the hotel bookings carry plenty of sensitive data, and right now there’s no good way to manage any of it. I end up managing all of it out of band, in my head, as a parallel manual process. That doesn’t scale.

Here’s what the future needs: a local vault. I put my sensitive information into a vault on my own machine. The agent never sees the raw data — it gets a token, decrypts what it needs at the moment of use, does the work, and the plaintext never lands in a transcript or a log. The agent becomes fully capable without becoming a liability. That’s the missing piece between “impressive demo” and “I’d trust this with my life’s paperwork.”

The quiet arrival

Maybe AGI doesn’t arrive with a press release. It arrives on a Saturday morning when you realize the car drives better than you do, and on the evening a visa package assembles itself while you have dinner. It arrives quietly, domain by domain — and the shocking part is how fast “impossible” becomes “of course.”

The age of AGI has already come — not with a press release, but domain by domain. First the car drove better than I do. Then an assistant planned my family trip better than I could. We keep waiting for the announcement; we already lived through it.

I’ve been thinking about System One models for a while, and I decided to stop debating and start measuring. But first, why I believe the System One direction matters at all.

Why AI needs a System One

Human brains process information with two systems. System One is intuition: fast, automatic, no thinking required. It’s muscle memory. You catch something flying at your face before you consciously see it. You learned it the hard way — millions of years of evolution, plus every scraped knee from when you were a kid learning to walk, run, dodge, and not fall down. Years of accumulated learning, compressed into instant reaction.

System Two is the opposite: slow, deliberate reasoning. You gather evidence, connect dots, debate pros and cons, maybe run through a framework, and then decide.

Here’s my claim: today’s frontier LLMs are System Two. Give them a hard question and they do chain-of-thought — they roll out different lines of thinking, argue with themselves, and eventually produce a final decision. That’s remarkably human-like System Two behavior. And it’s remarkable, full stop.

But a brain made of only System Two would be unusable. You’d deliberate for ten seconds about whether to blink. AI has the same problem.

What Jev actually claims

TypeSafe — founded by Diogo Almeida, who previously worked on the methods behind ChatGPT at OpenAI — spent two years in stealth building what they call System One Models. Jev is the first one, and the pitch is refreshingly concrete:

• Unstructured state in, typed probabilistic decisions out. You hand it a state (say, a bundle of logs) and declare your questions up front: yes/no judgments, choices between options, scores. It answers all of them in parallel off the same shared state.
• No string generation. It gives up text output entirely, which means it structurally can’t hallucinate and never makes type errors.
• Fast and cheap. 70–500ms per query, input at $0.042 per million tokens, outputs too cheap to meter. They claim roughly two orders of magnitude faster and cheaper than frontier LLMs on these tasks.
• Calibrated confidence. Trained with a method they call RLCD — reinforcement learning for calibrated decisions — so its probabilities are supposed to be epistemically honest: high confidence actually means high accuracy.

The name is a double homage: Kahneman’s Thinking, Fast and Slow, and William Stanley Jevons — of the Jevons paradox, where every efficiency gain in a resource increases total demand for it. Their bet: collapsing the cost of decisions unlocks a flood of new uses.

It’s a crisp story. The question is whether the numbers hold up.

Why I care: detection at enterprise scale

I’ve spent years building detection systems in observability and security: time-series foundation models for anomaly detection, log-based detection, graph-based detection. Here’s the reality of that world: an enterprise monitors tens of millions of time series and generates terabytes to petabytes of logs. You cannot pipe all of that into a frontier LLM and ask “is anything anomalous?” It’s too slow and far too expensive.

The standard answer is a two-tier funnel: cheap rules or small ML models sift everything at scale, and the expensive models only look at what survives. That works — except the whole game is signal-to-noise ratio. The cheap tier drowns you in false positives, and every false positive costs a human’s attention. Getting the false-positive rate down at scale is the hard problem.

This is exactly the shape of a System One job: react fast, cost almost nothing, and be well-calibrated about uncertainty. If Jev is real, it slots into that funnel as a dramatically better cheap tier. Feed it 10,000 logs, get anomaly scores back in milliseconds. (One limitation today: it doesn’t take numeric states directly. But there are workarounds — you can build textual descriptors of a time series and score those. The paradigm matters more than the current input format.)

“It’s just a rebranded classifier”

Now the skeptical voice, steelmanned: there’s nothing technically new here. Before the GPT era, BERT-based models did classification, annotation, and prediction just fine. Calling it “System One” is marketing draped over old technology. No paradigm shift.

I half-agree. Jev is not a GPT-level technical discontinuity. Nobody’s claiming a new scaling law.

But that objection misses the point in two ways. First, the neuroscience: human System One isn’t a dumbed-down System Two. Research suggests it’s in some ways more complex — dense shortcut connections that System Two doesn’t have. Fast intuition is an engineering achievement, not a simplification. Calibrated, parallel, hallucination-proof decisions at 100ms is genuinely hard, and “classifier” undersells it the way “autocomplete” undersold GPT-3.

Second, and more importantly: Jev opened the aperture. It gave the idea a name, shipped demos, showed use cases, and educated people that System One is a thing worth building — complementary to System Two, not competing with it. Movements need that. The best technology doesn’t win by being right; it wins by being legible.

The real opportunity

Here’s the strategic part. Frontier models are dominated by three labs — Anthropic, OpenAI, Google — plus a strong wave of Chinese open-source models. There is no room to out-compete them at System Two. That game is over for everyone else.

But System One is wide open. It’s the layer where researchers, practitioners, and startups can build things that are complementary to frontier models rather than competitive with them: the fast, cheap, calibrated reflexes that sit under and around slow reasoning. Every agent with a System Two brain will need a System One nervous system.

And the two systems feed each other. In the short term, I expect System Two to do more of the helping: frontier models reasoning carefully to generate feedback and pseudo-labels that keep improving System One. A few good examples can do the work of a thousand rules. Distill deliberation into reflex, then spend the savings on more deliberation.

So: is Jev hype or a real System One? My answer is neither camp’s. It’s not hype — the speed, cost, and calibration direction are real, and my own measurements back the shape of the claims. It’s not a paradigm shift either. It’s something more useful than both: a credible first draft of a layer AI genuinely needs, and an invitation to build the rest of it.

This site changes that. I’ll be writing about applied machine learning, engineering leadership, and the founder path I’m exploring — in the open, where ideas can find the people who need them.

One principle: no algorithms in the middle. If you subscribe, you get everything I publish. Growth here happens the old-fashioned way — one reader telling another that something was worth their time.

If that sounds like your kind of corner of the internet, subscribe. Let’s build this community one thoughtful reader at a time.