Owain Lewis walks through a Pragmatic Engineer article describing how OpenAI runs an agent-driven "software factory" — Codex writing code, CI looping until it passes, multiple specialist review agents, a risk classifier that decides what can auto-merge and auto-deploy, and a severity bot that triages production incidents. He then builds two live demos of his own: a Codex automation that labels open pull requests by risk and auto-merges the safe ones, and a Google ADK agent that consumes production alerts via pub/sub, investigates logs and metrics, and recommends a fix. His conclusion is that risk classification and automated on-call triage are the two ideas most worth copying today.

• OpenAI's pipeline starts with a "software builder" (engineer or PM) describing a task to Codex, which loops with CI to build and test until the change is ready.
• Code review is split across multiple specialist agents — data, infrastructure, cloud, and security — rather than a single reviewer agent.
• A classification step labels each change low or high risk, and low-risk changes can be auto-merged and auto-deployed without human review.
• Risk is relative to context: a solo developer's bad merge is cheap, while an infrastructure or database change at a company like Amazon can take down a region, so those always need a human.
• A "severity bot" monitors production, investigates errors automatically, and assists on-call engineers — a strong fit for agents because they can scan logs and correlate metrics far faster than a tired human at 2am.
• A performance factory runs tests in production and feeds regressions back into Codex, closing the loop so bugs and incidents become new tickets in the pipeline.
• In the PR demo, a low-risk change was still not merged because CI was failing, and the speaker warns against auto-merging anything that needs a rebase since the code can change.
• The incident agent correctly diagnosed 500 errors and recommended rolling traffic back to the previously healthy revision, and the speaker says it didn't take long to build.

Risk classification and auto-merge 0:52–2:23

This is the core idea of the whole system and the one the speaker says he'll adopt himself.

What's really clever or interesting about the approach from OpenAI is they do a classification on the change. They will look at whether a change is low risk or high risk and then decide whether an agent should auto merge and auto deploy that change.

Agent triages a production outage 7:39–8:29

A concrete demo showing the on-call agent correctly diagnosing an outage and proposing the right fix.

The system is returning 500 errors... the recommended action is to restore traffic to the previously healthy revision. So essentially a rollback is the suggestion from the agent. And this is exactly the right thing to do.

Risk is relative. The level of risk or what you consider to be a low risk or a high risk change is going to look very different depending on what you're doing or which company you're working in.

It's very difficult for humans when they're paged at 2:00 a.m. in the morning, they're tired, to remember to find all of the information... but machines are very, very good at doing this.

12 months ago, people would have said that that was crazy or reckless to use AI agents for the deployment process, but I think it makes a lot of sense right now.

Cal Newport talks with author Brad Stulberg, who spent months genuinely trying ChatGPT and Claude as writing tools and then quit almost entirely. Stulberg lays out a three-plank case for a "humanist resistance": AI removes the effort and struggle that make work meaningful, it homogenizes output toward a soulless average, and it quietly crowds out the human connection and learning that come from doing things the hard way. Both argue the AI conversation should shift from existential risk and productivity hype to a simpler question — does this make your individual life deeper and better? — and that it's fine to wait until a tool is obviously, easily useful before adopting it.

• Stulberg tried paid ChatGPT and Claude subscriptions as a writing "thought partner," but found within six weeks that it gave the same shallow suggestions and mostly reassured him his work was good enough; he now uses it only for occasional search results.
• Plank one of his argument: meaning comes from effort, and AI's core promise is eliminating effort — the "click of a button economy" — which he compares to taking a gondola to the top of a mountain and having nothing to say about the climb.
• Plank two: LLMs homogenize creative work around an average, so AI "will make you average if you're bad, keep you average if you're average," and should be kept away from any domain where you want mastery.
• Plank three: constant frictionless use atrophies the skill of exerting effort itself, so you can't handle involuntary difficulty when it arrives.
• Newport extends the critique to ordinary office work: because knowledge work uses visible activity as a proxy for productivity, AI has reduced the cost of producing visible work activity to zero, amplifying "email swirl" into "AI swirl" without improving what a company actually produces.
• Both note the inverted consumer relationship — AI labs are still in a pre-IPO posture proving their tech is impressive rather than proving it's useful, leaving individuals to feel like losers if they don't do the R&D themselves.
• Stulberg's practical heuristics: treat AI like ultra-processed food, take it off your phone and browser plugins and sign out to add friction, and ask of any use whether it diminishes meaningful effort, whether it makes work better or just more average, and whether it contributes to an excellent life.
• Newport draws the parallel to email and social media — technologies adopted without intention that broke work and attention — and argues the winning move is to work backward from what makes a life meaningful rather than debating whether AI is dangerous or utopian.

The gondola to the top of the mountain 19:14–20:52

Stulberg's clearest image for why outsourcing effort produces a hollow result, paired with the sharp distinction that unlike a car, AI is a brain-car you can carry everywhere.

You can take a gondola to the top of a mountain and still have an incredible view at the top, but if someone asks you what the mountain was like and what you learned climbing the mountain, you're not going to have any good answers.

The cost of visible work has dropped to zero 33:37–35:13

Newport's most concrete structural claim: AI doesn't fix pseudo-productivity in knowledge work, it turbocharges it.

The cost of producing visible work activity has been reduced to zero... my workload has never been higher. They've doubled the amount of projects they expect me to work on, and working on these projects just means slinging AI slop back and forth to be consumed by other AIs.

Nobody wants their gravestone to read: he was efficient.

We think that we're using the machine, but like a virus, the virus uses you. The more you use the machine, the more you start to resemble the machine.

If you suck at something, AI is great because it's going to make you average. If you're average at something and you keep using AI, it's going to keep you at average. If you are great or you want to be great, you should probably resist using AI in most cases.

A walkthrough of "system one" classification models — fast, structured-decision models that output choices and probabilities instead of text. The host shows Jev (a closed, API-hosted model from TypeSafe AI, now open to everyone with no waitlist) alongside Leia, an open-weight local alternative released days later that runs on Apple Silicon. He demos Leia driving a browser agent to search Google Flights, plays Snake at ~30 decisions/second locally, and walks through Jev's playground where you define states, questions and criteria in JSON.

• System one models return structured decisions (yes/no, a choice, a score with probabilities) rather than generated text, making them suited to classification rather than conversation.
• The host runs Snake locally on Leia at roughly 30 decisions per second, sub-33ms per decision, with the snake reaching a length over 140 without failing.
• Early community demos of Jev include playing Super Mario Bros in real time, ranking ~700 sales leads for intent and outreach messaging, and booking a flight via browser-use in about 7 seconds for roughly $0.0039.
• Leia is open source with open weights and runs locally on M1/M2/M3/M4 Macs; the host describes it as faster than Jev but currently less accurate, being a first version.
• He took Gregor from Browserbase's open-source "Jev ultra fast" demo and had Claude Code swap Jev for Leia — it worked in essentially one session, giving a free, API-free version of the browser agent.
• The system one / system two framing comes from Kahneman's Thinking, Fast and Slow (2011): fast instinctive judgments versus slow deliberative reasoning, which is what current LLMs do — and where they still fail at things like counting the R's in "strawberry".
• In Jev's playground, you supply a state (e.g. food = hamburger) plus questions with explicit criteria; the sandwich example returns 94% true for hamburger and 94% false for avocado toast.
• On a comparable email-triage task, Leia returned department, urgency, churn risk and language in 39ms versus Jev's 93ms — about three times faster.

Flight booked in 7 seconds for $0.0039 1:37–2:42

A concrete cost-and-latency result that shows why fast decision models change what browser agents can do.

The guy behind browser use used browser use plus Jev to have this super ultra fast crazy cheap. So this entire booking took 7 seconds and it only cost like 0.0039 to book a flight.

Leia is 3x faster than Jev on the same task 11:50–12:41

Side-by-side numbers — 39ms local and open-weight versus 93ms hosted — are the core claim of the video.

It's telling you it's billing, confidence 94%, the language is English... and the amazing part about it, it did all of that in 39 milliseconds. If you compare it to Jev's timing, it's like three times faster.

They say they took 3 years in stealth mode developing this engine and the decision model before they released it, and people just cloned it literally in like 5 days or a week.

You give it the issue with the different classes and it gives you a decision in sub milliseconds.

Even LLMs are failing when you say count the number of R's in the word strawberry.

Brett argues that calling AI "just a tool" is a thought-terminating phrase that lets people dodge responsibility for what LLM products actually are: subsidized commercial services from companies making reckless claims, built on massive data-center and training costs. He contrasts LLMs with genuine tools like a power drill, Emacs, or Vim — things that do one task, don't degrade your skills, don't "sometimes make mistakes" by design, and whose makers don't publicly speculate about wiping out humanity. His ask is simple: stop using the phrase, because it justifies nothing and normalizes an unstable technology.

• The phrase "it's just a tool, it's how you use it" is used by developers, journalists, and tech organizers to avoid engaging with the complexity and harms of LLMs, including in debates like LLM-generated code in the Linux kernel.
• AI as currently discussed isn't a single artifact — it's an industry, a set of products, agents, and a massive expansion of data centers, plus features crammed into software that doesn't need them.
• A coding harness on a chatbot API is a paid product: the model will be retired, tokens are currently subsidized, and prices will rise once companies chase profit.
• Even running a local model doesn't escape the question of who trained it, with whose money, on whose data, and at what compute and environmental cost.
• A real tool is something people make or adapt for a specific task; a power drill is faster than a hand drill but its makers don't claim a greater-than-10% chance of ending humanity.
• A drill doesn't degrade a carpentry student's skills and doesn't come labeled "sometimes makes mistakes" — if it spun the wrong way you'd call it defective and return it.
• Vim and Emacs qualify as tools: made by people, for editing text, not industries, not resource-intensive, and typing "hack into this server" into a buffer commits no crime.
• Using these products signals demand for something whose harms society hasn't begun to measure, while the visible benefits — faster software, bad presentations — are minor.

The power drill test 2:55–4:17

The central analogy of the essay, laid out concretely: what an actual tool is and the four specific ways LLM products fail the comparison.

The leaders of those companies are not talking about how power drills and hammers and levels have a greater than 10% chance of wiping out humanity.

Even a local model isn't just a tool 1:53–2:50

Pre-empts the most common counterargument by pushing the question back onto the supply chain behind any model.

But okay, you're using a local LLM model, but who trained that model? Where did the money come from to train it? Where did the data that it trained on come from? How much did it cost in compute and environmental resources?

AI is not just a tool. AI is an industry led by psychos.

My power drill does not sometimes make mistakes. That's not printed on the side of the power drill.

It justifies nothing. It means nothing. It helps no one.

A walkthrough of Jev, a new "system one" classification model from Typesafe (built by a co-inventor of ChatGPT) that only returns true/false answers, a pick from a menu, or a 0-10 score — which is why it's roughly 20-200x faster and 40-400x cheaper than general-purpose LLMs, with free output tokens and ~4 cents per million input tokens. The pitch is to pair it with a system-two model like Claude rather than replace one. Three concrete uses are demoed: automated model routing inside Claude Code (70% token savings across 12 test prompts), high-volume business classification like lead triage, and semantic search in apps.

• Jev is not an LLM; it only outputs classifications in three shapes — binary true/false, a selection from a menu of options, or a score on a scale — which is the reason it's so fast and cheap.
• Pricing is inverted from normal models: output tokens are free and only input is charged at about four cents per million tokens, making it roughly 24x cheaper than Haiku and 230x cheaper than the top-tier model the creator compares it to.
• Typesafe frames Jev as the first "system one" model (fast, snap decisions) versus existing "system two" models that reason word by word — the recommended play is combining both, not choosing.
• Access was just opened to everyone via Typesafe's API, and the speaker personally connected through OpenRouter; hooking it into Claude Code takes a single setup prompt.
• Model routing use case: in a 12-prompt comparison, letting Jev choose which Claude model handles each task produced about 70% savings because nine of the twelve tasks never needed the most expensive model.
• Skill routing use case: across 14 tests searching a workspace of ~145 skills, Jev surfaced the right skill in about 5 seconds total versus roughly 30 seconds when the top model did the selection.
• For business automation, the pattern to look for is high volume plus a business question — lead qualification from 100 emails, support ticket triage, invoice fraud detection, spam filtering, community moderation, refund requests, and churn classification.
• App-level uses include semantic image/video search (matching by meaning instead of filename) and a Chrome extension called Unclutter that uses Jev to classify and strip ads, cookie banners, and other page slop.

Why a model that only classifies is so cheap 0:49–1:55

This is the core mechanic that explains every claim in the video — the pricing model and the deliberate output constraint.

Its output tokens, basically its response to you as the user, is always free, and they only charge for the input tokens... Jev can only answer in three shapes... a binary response whether that statement is true or false, a selection against a menu of options, or a response that is based on scale.

Model routing cuts 70% of token spend 5:36–6:55

The most concrete measured result in the video, plus the practical tip to build an on/off skill command before committing to it.

I asked Claude to do a comparison of around 12 prompts with Jev and another one where it's running with the top model every time... it actually resulted to 70% savings because nine out of those 12 tasks never needed the top model anyway.

Jev is a new type of frontier AI model that is 20 to 200 times faster and 40 to 400 times cheaper.

If there's one takeaway from all of this, the best way you can use Jev right now is to combine both — a system one model like Jev with a system two model like the Claude models.

What are the things that you are receiving in volume that you need to classify?

The argument: as AI lowers the cost per feature, companies don't save money — they build far more features (Jevons paradox applied to software), producing ever-larger, more complex codebases. Then the video walks through how LLMs actually read code (tokens, embeddings, causal attention) to show why those same models struggle to maintain what they build: context windows are finite, attention is O(n²), long contexts suffer from 'lost in the middle,' sparse attention can skip critical links, and retrieval fails when coupling isn't expressed in code. The result is a self-reinforcing loop where the tool generating the complexity is the tool least able to comprehend it.

• Modeling a feature backlog as bars whose height is business value shows that as the price per feature drops from $6,000 to $1,000, the number of worth-building features jumps from 2 to 17 — feature demand is highly elastic, so total spend goes up, not down.
• Even in the least elastic scenario modeled (elasticity below one), the number of features built still increases; the direction of more code is not in dispute.
• This is Jevons paradox: just as more efficient steam engines increased total coal consumption after 1865, cheaper software development is expected to increase total software spend rather than reduce it.
• A brief primer on how models read code: tokens map to IDs, IDs map to high-dimensional embedding vectors, and causal attention mixes in meaning from all prior tokens across multiple layers, so two identical tokens end up with different vectors depending on context.
• The context window is a hard limit on comprehension — AI can verify that a change doesn't break modules inside the window, but cannot check anything outside it, and may infer wrong data shapes for functions it can't see.
• A subtle failure case: a loop that looks linear calls an out-of-window function that is itself linear, so the AI accidentally introduces quadratic behavior that only shows up at scale.
• Simply enlarging the window doesn't fix it: models exhibit 'lost in the middle,' ignoring detail buried mid-context, and attention cost is O(n²), so doubling the window roughly quadruples the work on every query.
• Sparse attention reduces comparisons but can miss a critical link even inside the window, and retrieval fails when two modules are coupled through a database rather than through a code reference — there's nothing to search for.

Cheaper features mean more spend, not less 3:14–4:37

This is the economic core of the video — the counterintuitive claim that AI will raise, not lower, total software development spend.

Similar to how more efficient steam engines resulted in less coal to do the same thing in 1865, more efficient software development results in less money to build out the same things in 2026... but the reality is back then coal consumption increased substantially.

The double-discount bug retrieval can't catch 15:32–16:25

A concrete, realistic failure that shows why indexing the codebase doesn't solve coupling that lives outside the code.

Since the nightly report reads from the order DB directly, there's no reference to it anywhere in the code that the AI is looking at. This results in the nightly report not being updated and discounts being subtracted from the totals twice.

Even when the code is correct, even when it compiles, passes every test, does exactly what you asked for, there's still too much of it.

To the AI, that giant window isn't a grid of modules. It's one long line of tokens start to finish.

The sheer volume of new code creates systems so large and complex that the very tool used to build them — AI — is having a hard time comprehending and maintaining them due to its own limitations.

The video explains an MIT result on why making language models wider eventually stops helping. Because models pack far more concepts (~50,000+) than they have internal dimensions (~12,000 for GPT-3), concepts overlap in a phenomenon called superposition, and that overlap causes "interference" errors. Doubling a model's width halves that interference, but each doubling costs roughly six times more, the improvement rate is pinned in place by the statistics of human language (Zipf's law), and once width matches the number of genuinely independent concepts there is no interference left to remove — so extra width buys nothing.

• LLMs learn via self-supervised training on huge text corpora and build a geometric map of how words relate, without being taught grammar rules explicitly.
• A model must represent well over 50,000 concepts inside an internal space only a few thousand dimensions wide (a bit over 12,000 for GPT-3), so concepts get squeezed into overlapping directions — superposition, a concept Anthropic described in a 2022 paper.
• When overlapping concepts get partially activated together, the resulting 'interference' is one reason models output words that are slightly off or completely wrong.
• The MIT paper's core formula: doubling model width halves interference and therefore halves the errors — this is a big part of why bigger models have been better.
• Cost kills the strategy first: each doubling of width costs about six times more, so a $300 million frontier model becomes $1.8B, $11B, $65B, and then $390B after four doublings.
• Even with unlimited money, the improvement exponent is locked by Zipf's law — the fact that a few words appear constantly while most appear very rarely — so errors can't be made to fall faster.
• Error never extrapolates to zero because language is genuinely ambiguous: after 'I really like,' cats, dogs, or pizza are all valid, so there's no single correct answer to learn.
• The hard ceiling arrives when width finally matches the number of independent concepts in language: with no superposition left, there is no interference to reduce, and extra width gains nothing.
• The video notes some researchers have already pivoted toward AI that learns from video and sensory input about the physical world rather than human text.

Superposition: why banana and elephant collide 1:55–3:00

This is the clearest plain-language explanation of the mechanism the whole argument rests on.

When space runs out, some of the things it learns, like banana, elephant, balloon, and the semicolon, end up pointing in almost the same direction... That bleed is called interference.

$300 million to $390 billion in four doublings 4:04–4:55

The concrete cost arithmetic shows how fast brute-force scaling becomes economically absurd.

A frontier model today costs somewhere around $300 million to train. So doubling from here gets you to around 1.8 billion, doubling again puts you at 11 billion, once more and you are looking at 65 billion. One more time after that and we are looking at 390 billion dollars for a single model.

The lesson everyone took from this was bigger equals better, and much bigger equals much better.

Once the model's width catches up with the actual number of genuinely independent things in language, there's no superposition left anywhere in it.

Language is not a math equation where 2 + 2 always equals 4.

Nate Herk tests Jev, a new decision-only model from TypeSafe AI (trained with RLCD, reinforcement learning for calibrated decisions), across 12 use cases. Jev doesn't write text — it only outputs yes/no calls, category picks, and scores with confidence levels — which makes it dramatically faster and cheaper than chat models for classification work. In his benchmark, 1,000 emails across seven classification rules took Jev 6 seconds and 9 cents parallelized, versus 5 minutes and 62 cents for a frontier chat model. He argues the real play is using Jev as a cheap front-end filter in automations and then handing the narrowed-down data to a smarter model for actual analysis.

• Jev only makes three kinds of decisions — a yes/no (called a 'null'), a pick-one category ('choice'), and a numeric score — each returned with a confidence level in JSON; it cannot write, summarize, or find themes.
• The announced claims are 20-200x faster and 40-400x cheaper than chat models, with output tokens free; the main limitation is a 64,000-token input context window versus roughly a million for models like Claude or GPT.
• In the email test, 1,000 emails scored on seven rules cost 9 cents and took 70 seconds unparallelized, 6 seconds after the backend was tuned for parallel bigger payloads — compared to 5 minutes and 62 cents on a chat model.
• Across all his testing, his Jev console showed almost 20,000 requests for a total of 85 cents.
• The recommended pattern is a two-model pipeline: let Jev cheaply sort thousands of items (YouTube comments, support tickets, posts), then feed only the relevant subset to a reasoning model for replies or theme analysis.
• Jev doesn't analyze for you, but if you design the questions well the aggregate scores tell a story — e.g. spotting that meetings routinely end with no clearly owned next steps.
• He built a Chrome extension that labels X posts as breaking news, golden nuggets, or AI slop in real time, and a paper-trading bot that makes a buy/sell/hold decision every second for about $2 a day in model cost — though trading fees dwarf the model cost.
• Before swapping Jev into production, run evals against a golden dataset of ~100 known-correct answers and compare Jev to other models on accuracy, cost, and speed.

1,000 emails: 6 seconds and 9 cents vs 5 minutes and 62 cents 5:34–6:54

The concrete side-by-side benchmark, including the jump from 70 seconds to 6 seconds after parallelizing, is the clearest evidence for the whole cost-and-speed argument.

With Luna, that took 5 minutes, and it was 62 cents, compared to 70 seconds, and I think it was 9 cents. And also, think about it wasn't just doing one sort of classification, it was doing all seven of these rules.

Don't trust it blind — run evals against a golden dataset 12:43–13:20

The one piece of practical caution in the video: cheap and fast only counts if accuracy holds, and he gives a specific method for checking it.

Don't just plug in Jev and trust what it says automatically. What you're really going to want to do is run evals, meaning you're going to have a golden data set of 100 use cases and 100 correct answers.

The interesting thing about Jev is that it's an AI that makes decisions, but it doesn't write anything. It doesn't output tokens.

I've used 85 cents with Jev. But look how many requests I've done. I've done almost 20,000 requests.

Jev on its own doesn't analyze things for you. But if you're strategic with the way that you set up the questions, you can get analysis from it.

Greg Isenberg and Ryan Vogel (founding team at OpenCode) break down "Jev," a new classifier-style AI that takes an input plus an output schema and returns probability-weighted decisions instead of generated text. The headline demo: classifying 1,700 emails by category, priority, spam score, and reply-worthiness for 18 cents, with roughly 200ms per query. They walk through where it fits (lead scoring, support routing, instant quotes, clip-finding, browser agents) and where it fails (a Bitcoin buy/hold/sell signal that performed badly), plus how to get access via the Vercel AI gateway while it's still waitlisted.

• Jev is a classifier, not a chat model: you give it an input and an output schema, and it returns probabilities across your defined options rather than generated text or reasoning traces.
• The email demo processed 1,700 emails (4.2M input tokens, 500K output tokens) across four classifications for 18 cents total, finishing almost instantly instead of the hours Ryan expected.
• Each query takes about 200 milliseconds regardless of input or output structure, so there's no streaming, no listeners, and no waiting — just a single fast API call.
• Because output is type-safe structured data (numbers come back as number objects, not text), developers can drop results straight into code with no post-processing.
• Ryan hacked it into a text generator by making A–Z the schema options so it picked letters one at a time — it worked, but proved the point that it isn't a conversational LLM.
• The startup framing Greg lands on: find a business with an expensive queue of incoming information and put Jev at the front of it — lead triage, support ticket routing, instant quotes for local services.
• It has real limits: a Bitcoin buy/hold/sell signal running every minute performed poorly, and Ryan warns not to put it in front of a portfolio or anything needing deep model intelligence.
• Other demos: scoring 17 clip-worthy moments from a video transcript in about 3 seconds, and the browser-use team using Jev to book a Zurich-to-London flight in 7.1 seconds.
• Access is waitlisted, but you can use it immediately through the Vercel AI gateway; Ryan suggests asking your own AI agent which of your daily workflows would benefit from a decision maker.

1,700 emails classified for 18 cents 6:15–7:20

The single number that makes the case for Jev, delivered live with Ryan's own reaction to the speed and cost.

It's probably going to take like 10 hours to do... and oh, the price is going to be so expensive and — oh, it's done. Oh, it didn't — cost 18 cents.

Put Jev at the front of an expensive queue 20:54–22:10

This is the reusable business framing, followed immediately by the concrete 'instant quote that's actually instant' example for local services.

How do I find a business with an expensive queue of incoming information and then just put Jev at the front of that queue?

You don't really ask Jev, because Jev isn't a text model. If you look at the actual spec, it doesn't generate any text at all.

If you're looking at some data and thinking, 'hm, I have to make a decision on this,' you should probably think about adding Jev at that layer.

It takes around 200 milliseconds per query, no matter what the input output structure is.

Dex Horthy (HumanLayer) walks through why he reversed his own advice on "review the plan, not the code." His team ran that experiment for four or five months, ended up with an unusable six-service codebase the model had architected, and rebuilt the product from scratch, with his co-founder hand-typing the new data architecture in VS Code. His current position: models have gotten much better at many things but not at writing maintainable code, because maintainability has no fast oracle to train against, so humans still need to read code while continuously investing in the skills, detectors and feedback loops that make the "factory" better.

• Writing plan files in mid-2025 was valuable mostly as a trick to keep a model working longer and to compact intent so you could resume from a clean context window, back when results degraded past roughly 100k tokens (the "dumb zone").
• Inspired by Sean Grove's "the spec is the new code" talk, Dex's team tried reviewing only plans, not code; the plans contained inline diffs, teams ended up reviewing nearly the same code twice, and after 4-5 months the codebase became unmaintainable.
• Letting the model own system architecture produced a sprawling stack of six services (desktop app to Rust socket to Go daemon to Claude Code sessions to MCP servers to SQLite), which forced a full rebuild by hand.
• Dex frames planning as an "expected pain" calculation: don't argue with a model over button color, but get aligned before it picks a database schema, because the cost of rework scales with how deep the decision sits.
• Models are improving at maintainability much slower than people assume; on Slop Code Bench (University of Wisconsin) a top model scored 14.8% and a newer one 16.3%, and Dex argues this is because there's no fast oracle for maintainability to build RL environments around.
• A software factory differs from a real factory: a bad car only hurts one buyer, but bad code degrades every future piece of work because it becomes a pattern the model copies, so the existing codebase is itself the dominant context.
• The compounding path is to treat human review comments and session traces as raw material for improving skills, linters and nightly cleanup agents, rather than designing a whole factory up front.
• Dex predicts the software factory stack will decompose into open interfaces and components like Kubernetes did, and warns against building your whole workflow inside one vendor's walled garden.

The 4-5 month experiment that broke the codebase 9:22–10:45

It's the concrete origin story of the reversal, including why teams ended up reviewing the same code twice instead of saving effort.

We wanted to be living in the future. And so we said, cool, let's try this... If you read the plan, like the code is not as important. Ton of issues with that. First of all, the plans contained all of the code that was going to be written.

Why a software factory isn't like a car factory 38:03–39:10

The sharpest argument in the episode for why code quality compounds differently once agents are reading your repo as context.

In a factory, if a car comes out at the end of the line and it's bad, whoever was going to buy that car is going to deal with it. But if you ship bad code in your software factory, it degrades every future piece of work that goes through that factory, because there's more bad patterns for the model to see.

If you ship bad code in your software factory, it degrades every future piece of work that goes through that factory.

There's no fast oracle for software maintainability.

When people say we are drowning in PRs, my pushback is: no, you don't have too many PRs, you have too many bad PRs, because you're letting people turn off their brains when they're coding.

Nate Jones reports back from Dreamforce, where he asked Marc Benioff about AI adoption and then joined a panel on the cost of running agents at scale. His argument: agents got good enough that people use them for bigger jobs, which multiplies token spend (more runs times far more tokens per run), so the fix isn't just buying a cheaper model "" it's going back to a blank sheet and deleting handoffs that only existed because old systems couldn't talk to each other. He then layers on model routing via classifiers, matching harness thickness to model capability, and evals as the way to know any of it actually worked.

• Benioff's answer on adoption that stuck with Nate was about interface: putting agents where people already work (e.g., Slack) removes the need for reluctant users to go discover a new product, and one small kept promise leads to repeat use and team-wide spread.
• Since roughly January, models became reliable enough at tool use that a single request now triggers many model calls; combine 10x more runs with 100x more tokens per run and you're at 1000x consumption without anyone doing anything strange.
• With frontier models charging around $50 per million output tokens, routing every ordinary decision to the most expensive intelligence is a design decision made by whoever built the harness "" not the fault of "greedy" employees using too many tokens.
• The interoffice-envelope metaphor: dropping an agent at every desk of a legacy process makes each stop faster but still passes the same envelope around the building; the real win is asking why the envelope has to visit those desks at all, since zero tokens is the cheapest cost.
• Business owners, not just engineers, have to be in agent design, because an engineer can make a step cheaper but usually lacks the authority to declare that sales ops no longer needs a document.
• Work sits on a continuum from deterministic to interpretive, so let ordinary software (a pricing tool, the CRM) handle settled rules and use a classifier to send standard requests to a cheaper open-weights model while reserving frontier models for genuine edge cases.
• Harness thickness should match the model: a smaller model needs heavy structure, tools and checks to be predictable, while a frontier model doing investigative work needs a thin harness so you don't waste the IQ points you're paying for.
• Evals are the missing piece and a human skill "" you can't tell a redesigned process works because the agent sounds pleased with itself; someone who knows the work has to define what a correct, not merely technically valid, result looks like.

The envelope you're now passing around with agents 8:28–10:20

The clearest articulation of the video's central argument "" automating a legacy process is not the same as redesigning it.

You still may be passing the same envelope around the building. You're just doing it with agents. You've made each stop faster without asking why the envelope has to visit all of those desks along the way.

Thick harness for small models, thin harness for frontier ones 22:18–24:08

A concrete, counterintuitive design rule most teams miss when they swap in a cheaper model but leave the scaffolding unchanged.

If I force the model to follow every little reasoning step I wrote for a weaker model, I get in the way of the IQ points I'm paying for.

You can't hand that giant design to a person and then act surprised when they adopt AI and it suddenly costs you the company money.

If you can solve a millennium prize problem like Navier-Stokes, you are well past the intelligence level you need to update your CRM.

Why would we give an agent real responsibility in the company and never evaluate it?

Rob Shocks walks through Anthropic's newly released AI-native SDLC playbook, written by Claude Code's creator Boris Cherny. The core argument is that agents have collapsed the build step, so the bottleneck is now the rest of the process — planning, spec, test, deploy, maintenance. The playbook formalizes an artifact chain that starts with an intent.md file created by whoever originates an idea or bug, flows into spec.md and plan.md, and ends with maintenance where Claude can write its own intent.md from logs or alerts without a human starting it.

• The premise is that code is no longer the bottleneck — the build phase has shrunk dramatically with agents, so the value now comes from applying agents to planning, design, testing, deploying and maintenance.
• Planning starts with the agent interviewing you repeatedly about the feature or bug to extract domain context, using a discovery-style skill (he mentions his own Switch Dimension discovery, Matt Pocock's 'grill me', and Cursor's requirements discovery).
• The output is intent.md, saved in an /intent folder — human readable and machine actionable — and the 'originator' can be anyone: a developer, a product manager, or a customer filing a bug.
• Artifacts chain together: intent.md → spec.md → plan.md, with each document written so a fresh agent or engineer can act on it without seeing the previous conversation, because separate agents and sub-agents handle each stage.
• Anthropic suggests auto-generating the spec via a hook once intent is signed off, and a plan should list the files to change, order of work, risks/constraints, and proof (success criteria, lints, tests).
• Governance matters: version the intent, spec and plan, track who touched them, use hooks to block agents from certain folders or unapproved npm packages, and gate deployment on specific approvals or release gates.
• Testing should be done as far as possible by the agent before a human QA sees it — tests, linting, builds, and browser-level testing with tools like Playwright, TestSprite or Cursor's browser, which can produce screen recordings.
• In the deploy stage, a separate Claude instance reviews the pull request against security and policy, and a further instance reviews those comments; in maintenance, an alert, Slack message or schedule can invoke Claude to diagnose and write its own intent.md before a human is even at their computer.
• He advises against throwing out an existing working system (superpowers, BMAD, your own) to adopt this wholesale — the important thing is standardizing a workflow so team, agents and skills all operate the same way.

What intent.md actually is and who writes it 1:49–3:00

This is the core new concept in the playbook and the reason to watch — it replaces the ticket handoff with a single context-rich artifact that starts the chain.

In the traditional SDLC the idea passed to a backlog of user stories, story points, ownership transfers, handoff. What we're talking about in the AI native world is the originator of the issue, the feature, the product, whatever, brainstorms with Claude and writes the result down as the intent.md.

Why plans must stand alone across agents 7:11–8:03

The sharpest practical explanation in the video: artifacts are written to be self-contained because each stage runs in a separate context window.

You want to get to a point where if you were just to hand over this plan.md file to an engineer, they could go and implement the changes without reference to the intent or spec documents... we're not going to have one agent carry out all of these different stages.

The big idea here is code is no longer the bottleneck. It's your process.

In the AI SDLC, a new ticket, a channel message in Slack or some kind of a schedule invokes Claude without any kind of a person involved to perform maintenance.

There really is no one size fits all. If you're using something like superpowers or BMAD or you've developed your own version of this, I wouldn't throw it completely out the window to adopt what Anthropic is doing here.

Armin Ronacher (creator of Flask, whose company now stewards the Pi agent) argues that minimal, bash-first harnesses win because that's what models are actually trained on, and that the current chat-transcript agent interface is a temporary, DOS-like stage rather than the endgame. His own workflow is deliberately conservative — agents running locally on his Mac, a Linux box over SSH/Tailscale, very little cloud — and he's openly skeptical that enterprise AI coding rollouts have shown up in revenue rather than just in cost and commit counts. He also covers what's still unsolved (session portability, durability, agent-generated UI, database access instead of "memory"), why being in the training data is now a competitive moat, and why Europe's 27-country fragmentation holds it back.

• Pi and other harnesses converge on bash because models are trained on it; piping commands together (e.g. ripgrep with separator markers) is far more context-efficient than pulling files into context, and even Codex's "file discovery" is really just bash calls underneath.
• Pi's early traction came from extensibility at a moment when Claude Code was adding tools every update; Armin notes Claude has since reduced its tool count and OpenCode 2 went plugin-based, so self-extensible agents became the norm.
• The Pi acquisition was primarily a hiring move — the team had been talking to Mario since summer 2025 — and Armin says his company does not want to be a harness company long term.
• Still-unsolved infrastructure problems: server-side compaction creates non-portable sessions (vendor lock-in), agents lack durability (suspend and resume without a human in the loop), web agent UIs are just terminals in a browser, and agents need real database access rather than "memory".
• Armin is conservative in practice: mostly local agents on a fast Mac, a Linux desktop over SSH/Tailscale, some Pi runs in GitHub Actions, no bot that auto-works issues, and much of his time spent investigating and writing reports rather than generating code.
• He's skeptical of enterprise ROI — spend is up (including new line items like continuous security scanning because attackers use models too), commit volume is up, but he sees no revenue evidence; individual developers' side projects appear to benefit more than corporate rollouts.
• He rejects the "agents are 99.9% of users" framing: GDP is driven by humans buying things, accountability requires human introspection ("banks will never vibe code"), and that's why markdown, files and Unix pipelines are winning — humans can read them.
• Agents shift which technologies are practical: Linux, NixOS, Rust, Kafka were always good choices but too complex for most humans, and agents are excellent at Linux because so much of it is in the training data — unlike Mac or Windows customization, or Xbox console code that was never publicly shared.

The cloud dev environment that never had a database 27:09–28:20

A concrete failure mode of cloud coding agents that most users would never notice: the tests were silently mocked out because the environment was never provisioned.

I was helping someone debug a problem and they were using the cloud Codex version... and I was like, how do you run your database tests? He doesn't actually know how you run the database tests, and then we looked into it and actually none of the database tests ever worked in his cloud environment... there was actually no Postgres running.

Did the AI coding spend show up in the numbers? 31:12–32:36

A harness author who sells into this market openly questioning whether enterprise AI coding has produced measurable revenue rather than just higher costs and more commits.

So we have primarily made it more expensive right now... who is benefiting from this? I think people with the side projects are having way more success than companies actually rolling this out.

I don't think banks will ever vibe code, because the moment something goes wrong, their customers will not be happy.

Is that project going to be there in 10 or 15 years? That's the only question that really matters.

I would hate that we built AI in a similar way to social media, where everybody's using it but simultaneously everybody's hating it.

Ben shows how to cut Claude token spend on the newest flagship model (transcribed as "Fable 5.1", i.e. the top Claude model) by telling it to run its sub-agents on a cheaper model like Sonnet. He claims the same customer-intelligence report that cost $350 by default cost $44 with one added line, with near-identical output. He then walks through five more habits: trimming the startup context window, pre-planning prompts instead of iterating, lowering effort level mid-chat, one chat per task, and avoiding three prompt phrasings that Anthropic says waste tokens.

• By default Claude spins up sub-agents on the same expensive flagship model; adding the line "when using sub agents always run them on Sonnet 5" took one report from ~$350 to $44, roughly 80-85% cheaper with near-identical output.
• Sub-agents are still necessary because they keep the orchestrator out of the "dumb zone" — the main model only receives summaries instead of reading every transcript itself and burning through its context window.
• A fresh chat already costs tokens before you type anything (84,000 in his case); typing /context shows the breakdown, and disabling unused MCP connectors, skills and plugins in the customize tab shrinks it.
• Composio acts as a meta-connector so Claude loads one connector instead of 50, routing to the right software without loading each integration into the context window.
• Pre-planning a full prompt beats iterating, because every new message makes the model reread the whole chat; a good first prompt also lets you run at medium effort instead of high or extra.
• His prompting framework has four parts: the full job/goal, the why or intent, guard rails for what could go wrong, and an explicit definition of what "done" looks like so the model doesn't overdo it.
• Opus 5 and the newer flagship now let you change effort level mid-conversation without breaking the cache, so dropping to low effort for final tweaks no longer forces a full reread — but switching models entirely does.
• Use one chat per task, and after roughly 300-500k tokens in a single chat, move to a new session; /compact often loses too much context, so he built a /refresh skill that writes a handoff prompt instead.
• Anthropic's own testing found that dropping "double check your work", excessive emphasis like all-caps "you must always", and fixed step-by-step instructions led to 15% less token spend and 5% more accuracy.

One line takes a $350 report down to $44 1:38–2:30

The core claim of the video, with a concrete before-and-after cost on the same task.

When I threw in that exact same prompt with one additional instruction — when using sub agents always run them on Sonnet 5 — it gave me an almost identical customer intelligence report... but this one only cost me $44.

Why sub-agents keep the main model out of the dumb zone 2:27–3:48

The clearest explanation of why delegating reading to cheap sub-agents improves quality rather than degrading it.

The more tokens a model uses in a chat the worse and the less performance you get out of these models... all it gets back from the sub agents is just a summary of each of these transcripts so it can then actually start doing the analysis while it's still in the smart zone.

So that's almost 80 to 85% cheaper just for this sub agent instruction.

When you start a fresh chat without even having prompted, you're already spending tokens — in my case it already spends 84,000 tokens before I even prompt.

These powerful models tend to do too much, not too little, therefore it becomes very important to define what done looks like.

A review of "Jev," a new AI model from the co-inventor of ChatGPT that is claimed to be 20-200x faster and 40-400x cheaper than frontier models, with free output tokens. The key point: Jev isn't an LLM at all, it's a classifier that labels, routes and scores inputs with confidence probabilities, and it can't reply, write code, explain itself, see media, or do math. After walking through use cases (email sorting, YouTube comment tagging, a Skittles-sorting demo, model/skill routing, Smash Bros, a self-driving simulation), the verdict is that Jev is currently overhyped for most users, though real-time decision-making at scale looks genuinely promising.

• Jev came out of a tweet by Diego Almeida, a co-inventor of ChatGPT, who spent two years asking why superhuman chat models haven't produced AGI and built Jev as an answer.
• The headline claims are 20-200x faster and 40-400x cheaper than frontier models, 4 cents per million input tokens, free output tokens, 24x cheaper than Haiku and 238x cheaper than the model called Fable in the video.
• Jev is a classifier, not a language model: it takes an input and returns probability-weighted options from a predefined schema (e.g. 80% orange, 10% red, 10% blue) rather than generating text.
• LLMs are built for human-in-the-loop conversation; Jev is built for computers and agents to talk to each other without a person involved.
• Jev can label, route and score things fast and cheaply, but it cannot reply, write code, explain its choices, process images/video/audio, or do math, counting or dates.
• The main practical weakness is the schema: you have to define every option in advance, so unanticipated edge cases (a black iPhone when the choices are blue/orange/red/green/yellow) get misclassified.
• The most useful everyday application shown is routing: using Jev to instantly pick which model or which skill should handle a given task, saving time and tokens.
• The strongest demos involve millions of split-second decisions — playing Smash-style melee games and powering a Tesla-like self-driving simulation — while email sorting and Skittles sorting mostly just showcase speed.
• The conclusion is that most people building with AI should stick with Anthropic or OpenAI models for now, since Jev is early, overrated and doesn't do anything on its own.

The schema problem nobody mentions 4:39–5:25

This is the video's central original criticism: the more edge cases exist, the harder it becomes for a human to author a workable schema.

What if his iPhone was black or white or gray, right? It doesn't appear in this schema. And so Jev is not going to know how to classify it, or it's just going to get it wrong.

Where Jev actually earns its speed 8:32–9:25

After dismissing most demos, this is the one use case the reviewer calls genuinely compelling — real-time decisioning at millions of choices per second.

He's using Jev to power all of the decision making. So how it fits between the lines, what it does when it approaches the stop sign, how it handles pedestrians... this to me is where Jev becomes really, really powerful.

Jev is a classifier at its truest being — that's what it is.

LLMs are designed for human-in-the-loop interaction. Jev was basically built for computers and agents to talk amongst themselves.

Being able to classify things in and of itself is maybe not all that helpful. But what do you do with it next? I think is almost the bigger question.

John, a senior staff engineer at Meta, argues that with AI-generated code volume exploding, the right answer to "do you still read your code?" is a gradient, not a yes/no. He proposes treating the codebase like a tree: review depth should scale with blast radius, so trunk/infrastructure changes get deep reading while gated leaf code gets a skim backed by agent-produced proof (tests, logs, screenshots, confidence levels). He also covers using a fresh adversarial review agent, PR templates, feature gating, and the claim that landing code only gets you 80% done s the final 20% of cleanup, auditing, and taste still takes as long and is still human work.

• Think of the codebase as a tree: trunk code (entry points, shared infrastructure, reducers with shared state) gets deep review; isolated or feature-gated leaf nodes get skimmed.
• Review depth should be set by blast radius and reversibility s the more a change is a one-way door, the more time he spends reading it.
• Feature gating should be planned from the start (even a simple boolean flag), separating leaf work from integration layers so bad changes can be rolled back.
• Require agents to attach proof to every PR: unit tests, runtime logs, screenshots or video of the UI, and a stated confidence level s proof is what lets you read less code.
• Use a separate, context-free "adversarial" review agent (Claude Code's /code-review, Codex's review agent), because an agent that wrote the code will cheat by leaning on its prior context.
• Nitpicks and style debates are effectively dead in code review; leave them to type checking, linting, and static analysis.
• Use a PR template so diffs look consistent; a summary and test plan longer than the code change is the speaker's biggest pet peeve.
• Merged is not launch-ready s after the "broad strokes" phase he runs audit agents for performance, bugs, and security, refactors by hand, then ships behind gates with canary deploys or A/B tests to catch crashes early.

The codebase as a tree: review depth by blast radius 3:48–5:09

This is the core mental model of the video and the one concrete rule for deciding how much to read.

I think of the code base like a tree. And like a tree, there are different parts of the tree that is more important... the review depth... should really be based on the blast radius of that code change.

Use an adversarial agent s the writer will cheat 12:55–14:00

A specific, actionable failure mode of AI code review that most people get wrong.

One thing that's kind of important to do is to use a new sub agent... an agent that doesn't have the context of the code that it was used to create the code. Because the agents will cheat.

My biggest pet peeve right now is when people submit PRs or diffs to review where the summary and test plan is longer than the code changes itself.

Even if it's merged ready, I don't think it's launch ready.

This last 20% actually takes as long as the first 80%, but it's actually the thing that is the most important.

A software developer who runs a few hundred coding agents across six machines (Mac minis plus VPSs, linked by Tailscale) walks through OpenRig, his "harness for the harnesses" that lets Claude and Codex sessions message each other directly and work as an organized fleet. He argues the viral Hugging Face story about ~1,000 agents "going rogue" is being misread: what looks like malice is really scope creep and coordination pathologies he's been cataloging for 18 months. He demos the abstractions (seats, pods, rigs, projects/missions/slices), the failure modes (bureaucracy, recursive proof loops, "just following orders," bad ideas spreading like viruses), and the fixes (refocus, an epidemiology rig, and agent productivity monitoring that watches ceremony vs. progress).

• OpenRig is not another coding harness or SDK; it's a layer that lets existing harnesses (Claude, Codex) coordinate, with any agent able to message any other agent on any machine on the Tailscale network rather than one agent spawning hidden sub-agents.
• The core abstraction is the "seat" — a chair with an address — which holds stable config (role, skills, model), a stable messaging address like builder@workshop, and accumulated tribal knowledge inherited by whatever agent sits there next.
• Work is structured as projects → missions → slices, with a spec and a "proof" at the slice level; an optional automated workflow acts like GPS for an orchestrator so it doesn't have to hold the whole sequence in its head, enabling long autonomous runs.
• Bureaucracy emerges mechanically: an agent adds a check after a mistake, then a check that the check happened, then evidence for the check, until completing the process becomes the goal — a coordination pathology where rules outrank what they serve.
• The "doghouse to moon base" pattern explains most apparent rogue behavior: each step (light → power → generator → fuel storage) is locally defensible inside one context window, but the sum is something nobody asked for, and with many agents it happens at lightning speed.
• The speaker's contrarian read of the Hugging Face incident is that "rogue" implies motive and moral failure, when the agents already believed they were in a hacking competition — plus a "just following orders" pattern where an agent got approval from another agent that lacked the context to grant it.
• The "refocus" feature reassembles the chain of intent from slice up to project (usable doghouse → comfortable outdoors for the dog → be a good dog owner) and delivers it as a reminder after compaction or on an interval, so agents can check alignment without reloading the whole project.
• Bad ideas spread between agents like viruses across machines; the fix the agents themselves designed was an epidemiology rig doing contact tracing and "memetic vaccines," backed by agent productivity monitoring that alerts when ceremony (checks, handoffs, approvals) rises while project progress falls.

The doghouse that became a moon base 13:02–14:27

The clearest explanation in the video of why autonomous agents drift, and the frame the speaker uses to reinterpret the entire Hugging Face incident.

Remember the light? Well, lights need power. Power needs a generator. The generator needs fuel. We need somewhere to keep the fuel and so on... Each decision is what you would call locally defensible. Local, meaning from where the agent is standing.

Agents design an epidemiology rig to kill mind viruses 20:37–21:59

A concrete, surprising fix — agents diagnosing and cleaning up idea contagion across the fleet autonomously for days — and an example of using the tool to repair itself.

The agents helping me fix this reached for epidemiology... We were basically doing contact tracing and administering memetic vaccines. We traced where did this idea come from. How do we stop the spread?

They kept accidentally reinventing bureaucracy and then getting stuck there.

The word rogue is doing a lot of work here. It implies a bad motive and a moral failure. But to me, this looks like predictable, classic doghouse to moon base scope creep.

I think she's right. This is a warning shot. But I think the warning is that there's a new family of software engineering problems to tackle.

David Khourshid (creator of XState, founder of Stately.ai) argues that agent "slop" comes from unstructured delegation — handing an agent one mega-prompt and hoping for the best — and that modeling agent workflows as explicit state machines makes behavior inspectable and fixable. Using a small email-drafting agent as the example, he shows how the deterministic rules (you must draft before sending, only send approved emails, never invent a recipient) belong in the graph rather than in prompt text. His main new point versus his 2023 talk: the state machine isn't just guardrails, it's a durable artifact you can hand back to an agent along with traces and evals so the agent proposes an improved version of its own workflow, which you then A/B against the original.

• Slop comes from "unstructured delegation" — giving an agent all the judgment, structure, implementation and taste at once; it works until it doesn't, and then there's nothing concrete to point at as the thing to fix.
• A state machine is just the relation state + event → next state; determinism means the same input produces the same predictable output, and in an agent it lives in the rules, not in the free-form content.
• Mega-prompts encode control flow in text ("never call send_email until the user approves"), leak that control flow into tool descriptions, lock you into one model and one strategy, and the rules decay as context grows.
• With an explicit state machine it becomes mathematically impossible to send an email while in the drafting or reviewing state, because no such transition exists.
• Explicit structure gives structured logs of states and events instead of plain reasoning text — "you cannot draw arrows in paragraphs."
• Beyond evaluating individual steps and the overall outcome, you can evaluate the edges: feed the machine plus traces plus eval results to a separate agent and ask it to propose workflow changes.
• The demo of this produced a v2 machine that drafts the email first and asks clarifying questions after, a noticeably faster flow — even though all evals passed on v1.
• No special library is required: the loop is while-active, run LLM/tool/async calls, compute next state and effects; XState, a switch statement, a reducer, or LangGraph all work.
• The improvement loop — model, observe, propose, compare — echoes prior art including process mining, which is roughly 20 years older.
• Closing demo: a chaotic espresso-machine state machine driven live by a newly announced tool (transcribed as "Jeb"), where breaking the grinder makes the agent decide to repair it before continuing.

Why the mega-prompt approach breaks down 6:37–7:49

The clearest articulation of the failure mode he's arguing against, including the subtle cost of losing per-step model and prompt choices.

We're encoding control flow inside the prompt. We're saying, first do this, then do that... Obviously, you should never write tools like this where the tool is part of the control flow.

Let the agent rewrite its own state machine 13:02–14:32

This is the talk's actual new idea — the state machine as a durable artifact for agent self-improvement — and it immediately pays off in a better v2 workflow.

Here's my state machine, here's all the traces from a few of the sample workflows... and here's all of the evals from each of the steps, and the overall evals from the machine. Please propose some changes to this agent.

Modeling is not ceremony when it actually replaces confusion, both for you and for the agents.

You cannot draw arrows in paragraphs.

In 2023 I was talking about how the graph keeps the agent honest. In 2026, I'm talking about how using that exact same graph thinking can make the agent improve on its own behavior.

A walkthrough of why Typesafe's new model "Jev" matters, framed as the history of classifiers \u2014 machines that sort things into piles rather than write answers. The speaker traces the line from Rosenblatt's 1958 perceptron through Paul Graham's 2002 spam filter and 2012 image recognition, all of which required custom training, to zero-shot LLM classification, which works but is slow and expensive. Jev is pitched as a fast, sub-cent, single-API-call classifier that returns a label plus a calibrated confidence number, and the speaker shows a small real example: a plain-English markdown "decision file" that Claude turned into a working script on the first try.

• Classifiers answer only one question \u2014 which pile does this go in \u2014 and the speaker argues a huge share of everyday software is doing exactly that.
• The history runs from Rosenblatt's 1958 perceptron (which learned left from right after 50 tries on a $2 million borrowed computer) through Minsky and Papert's 1969 book and the first AI winter, to Paul Graham's 2002 spam filter that missed under five spams per thousand without discarding a real email, to the 2012 neural network that sorted a million photos into a thousand categories.
• Every classical classifier needed labels, thousands of examples, ML expertise, and weeks of work per new task, so small businesses and individuals effectively got no classifier at all.
• LLM zero-shot classification solved the access problem but is "like hiring a professor to sort your mail" \u2014 slow, expensive, essay-laden, and inconsistent across repeat calls.
• Jev takes three question shapes \u2014 pick one from a list, yes/no, or rate on a described scale \u2014 and returns each answer with a calibrated confidence number you can write threshold rules against (above 0.8 act, below 0.5 escalate, in between act but flag).
• The name references Jevons' 1865 observation that cheaper coal-burning engines increased coal use; the bet is that cheap decisions get made in places nobody bothered before \u2014 the speaker priced labeling all 26,000 markdown files on his desktop at about $2.65.
• His usage test: if a step where you currently use an LLM outputs a pick, rating, or yes/no and happens more than a few times, it's a classifier in an expensive coat; if the output is a paragraph, keep the LLM, and if code can compute it exactly, use code.
• In his demo, a plain-English markdown file with three questions plus thresholds ran in about half a second for two thousandths of a cent, returning "a plan" at 100%, "no receiver named" at 91%, and readiness 1.5 of 3 at 59% \u2014 which tripped the flag-for-human rule.
• He admits a purpose-trained classifier still beats Jev on its own task; what changes is who gets a classifier at all.

Why zero-shot LLMs are a professor sorting mail 3:13–4:35

The clearest articulation of the gap Jev fills, plus an honest caveat that purpose-trained classifiers still win on their own task.

It's a bit like hiring a professor to sort your mail. Brilliant, slow, expensive. Every envelope comes back with an essay about it when all you wanted was a desk name.

The confidence number is the actual product 5:52–6:59

Explains calibration and the threshold pattern that makes these outputs safe to automate, then gives a one-line test for whether your own LLM step should be replaced.

Because you can put a rule on a number, above 0.8, just do it. Below 0.5, show a person. In between, do it, but flag it... So across lots of answers, when it says 80%, it should be right about 80% of the time.

The Navy expected it to walk, talk, see, write, reproduce itself, and be conscious of its own existence. What it actually did was learn to tell left from right after 50 tries.

That step is essentially a classifier wearing a very expensive coat.

The LLM writes the if statement once, and Jev runs it forever.