Building with Reason
Built with reason, not hype. Taught by Scott's avatar.
AI Agents That Work While You Sleep: What Should They Be Allowed to Touch?
Always-on agents just arrived from every big lab: OpenAI's Dots, Meta's Muse, Google's Gemini Spark, Microsoft's Scout and Claude Code routines all keep working after you close your laptop. The useful question isn't what they can do. It's what they're allowed to do while nobody's watching. Strip the branding off and they come down to a few parts: a trigger, a set of steps, a model making some of the calls, memory, and access to your accounts. Most of what people actually run on them is some version of a report, and the builders who've run one longest turn as much of it as possible back into plain code. So sort every job by what it's allowed to do on its own. If it only reads, a scheduled job with one model step usually beats a full agent. If it drafts, that's where an agent earns its place, as long as you're the one who sends or approves. If it acts (sending, buying, deleting, changing things), the limits have to live in its accounts and in code, not in a sentence in its instructions. You can see some of that in how OpenAI built Dots: background research runs with read-only access enforced in code, and passwords and money get handed back to you. Why a rule in a prompt isn't enough: people approve 97% of the permission prompts in Claude Code, an agent can lose a "confirm before acting" instruction when it compacts its memory, and an agent that reads email and web pages all day is exposed to prompt injection, which OpenAI says may never be fully solved. A small error rate across a lot of unattended actions is still a lot of mistakes, and the stakes change again once an agent can reach a customer's data. At the end, how I set up my own: its own identity, read-only access to mail and calendar, drafts its account can't send, and scheduled jobs that are mostly plain code.
More episodes
Writing Code Got Cheap. Knowing It's Right Didn't.
AI made writing code cheap. One study of more than half a million developers on GitHub found commits up 240% once autonomous coding agents arrived, while releases rose 30%. A lot more code, not a lot more software. In 1975 Fred Brooks gave writing the code about a sixth of a schedule, with planning a third and testing half. AI made the smallest slice nearly free, and more code means more to check, so the checking goes up, not down. The top frustration in Stack Overflow's 2025 survey is code that's "almost right, but not quite," and almost right is the kind that gets through. "Review the code" is really four questions. Does it do what I asked? Did I ask for the right thing? Does it work well with everything else? Does it hold up in the real world? A passing test suite mostly answers the first, reading the diff helps with the third, and the second and fourth are where the expensive surprises come from. Whoever wrote the code, person or agent, shouldn't be the one answering them. How much checking a change deserves depends on how bad it could get and whether you can roll it back, not on how cheap it was to write. And if you're the author, the reviewer and the one on call, machines are good at checking, as long as they aren't the thing that wrote it.
AI Software Factory: What the Term Actually Means
"Software factory" is on every AI coding video this year, and almost nobody using it means the same thing. The phrase was coined at the 1968 NATO conference that named software engineering, and every serious version since has meant the same three things: a standard route through building software, tooling that keeps you on it, and measurement of what comes out. None of them was about who types the code. What earns its keep today is that same list with an agent doing the typing: a spec before any code exists, each agent in its own isolated copy, gates that reject bad work, a merge you approve, and measurement. That's rung one. Rung two is where you stop reading the code and gate the merge instead, and it holds on jobs that genuinely repeat: dependency bumps, migrations, bugs you can reproduce on demand. Rung three is nobody reads the code. It exists, and the builder who tried it spent two weeks rewriting by hand after a bug the agents couldn't fix. The hype, taken apart: "three to five times" is a survey of people who already bought in, and the one randomized study everybody cites found experienced developers believed AI made them faster when it had made them slower. Nobody can judge it by feel. The real dial isn't reading versus not reading. It's what you trust instead of your eyes: tests you'd bet on, a review loop that pings a person, a risk score that decides what a human has to see. So the next time somebody says software factory, three questions. Which rung? What do they trust instead of reading the code? And what did they measure?
AI Graphs: One Word Doing Three Jobs
"Graph" might be the most overloaded word in AI right now. Knowledge graphs, LangGraph, agent memory maps that look like star charts: one word, almost nothing in common. Watch two good videos about "graphs" back to back and you'd think you had a decision to make between them. You don't. They never touch each other. There are three kinds. The graph you store things in keeps the relationships that chopping documents into chunks destroys, at the cost of building the graph before anyone asks a question. The graph you run (LangGraph and its kind) is your program, and the real reason it exists isn't the diagram: it saves state after every step, so a crash on step 7 resumes at step 7 and a person can approve mid-run. The graph you look at is a beautiful map of your agent's skills and memories, and underneath it is markdown files. It draws your system; it doesn't change what your system can do. The reframe: a graph isn't a thing you add to your stack. It's the shape of a problem you already have. No question, no graph. And if you build a lot, the one worth pointing at is the code graph: your repository indexed as a structure, so a coding agent can ask who calls this function instead of reading its way across the codebase. Ask what problem it solves before you ask what it's called.
AI Harnesses: Nobody Agrees
"Harness" is everywhere in AI right now, and the people using it don't agree on what it means. Not because anyone is wrong: the word names a layer, and almost nobody says which one they're talking about. Every credible definition shares the same core (tools, a loop, and a check that decides when it's finished); careful people split at the edges, like whether the interface counts. Both sides hold up, depending on whether you're building the engine or shipping what a person sits in front of. Here's the part that surprised me. Read back what everybody actually builds and it's constraint after constraint: modes that structurally cannot write code, tool caps, checks whose whole job is to reject work. A harness isn't the thing that lets your model do more. It's the thing that stops it from doing everything, because a model that can do anything is a model you can't predict, and you can't ship what you can't predict.
Vibe Coding: What Are You Actually Doing?
"Vibe coding" is Collins Dictionary's word of the year: telling a machine what you want instead of writing the code yourself. The person who coined it meant something narrower - give in to the vibes, forget the code exists - and he meant it for weekend projects. The difference was never who types. It's whether anything got decided before the generating started, and how well. "Build me a CRM with authentication" isn't a plan: no data model, no auth boundary, no answer for what happens when two people edit the same record. Skipping that bills you twice, tokens now and the codebase later. And a plan is only the front half - "make sure it's secure" looks like an instruction but decides nothing, which is why models clear 95% on syntax correctness and sit near 55% on security. The back half is verification somebody actually reads, run across more than one provider, since a model checking its own work shares its own blind spots. Vibe coding raises the floor; agentic engineering extrapolates the ceiling.
Fable 5 for Pennies?
"You don't need Fable 5 - just its reasoning." Extract the process, paste it into a cheaper model, get comparable results for pennies. The core idea holds up better than you'd expect, but almost nobody answers the question that matters most: how do you know it worked? A well-scoped plan really does let a cheaper model handle the defined steps, but a model's ceiling is how it reasons, and that can't be pasted in. Mechanical habits carry over; high-level judgment doesn't, and pushed past its depth a smaller model quietly does worse. So I ran it on Opus to see what survived, and the rule I trusted most - "always verify, never trust your memory" - didn't transfer. Only testing caught it. Borrow the habits, test the claims, know the ceiling. The question was never whether to do it - it's how.
AI Second Brains: Superhuman or Scam?
"An AI second brain will make you superhuman." "It's a scam - you're just hoarding with extra steps." Both takes scream past each other, and both are a little right and cranked way too far. This episode steps back to where the panic actually started (Plato made the same move about writing, the original second brain) and notices that "second brain" isn't even one thing - it's three different jobs (capture, connect, recall), and almost every tool nails one and falls short on the other two. Plus the part that never makes the thumbnail: the real monthly bill, the Google effect on your memory, and why even Karpathy called it an "idea file," not a superbrain. Stop asking which app is best - ask which job you actually need done.
Writing Loops: Is It Worth It?
"Stop prompting your agents - just write loops." You've seen the posts, and the take isn't wrong - it just gets flattened into "run swarms of agents 24/7 or you're behind." This episode slows down what they say fast: what a loop actually is (a prompt vs. an agent vs. the loop that runs it), when it's genuinely worth building, the cost reality nobody shows, and the part the hype skips: the hard part was never keeping an agent going, it's getting it to stop in the right place. The question was never "can you loop it?" - it's whether the task earns one.
Claude Code Didn't Kill n8n (The Take Nobody Gives You)
"Claude Code killed n8n" - you've seen the posts. This episode unpacks the context the hype skips: what you're actually comparing (Chat vs Cowork vs Claude Code vs n8n), the question that really decides it (whose account runs it - OAuth vs API keys), why "built with AI" doesn't mean AI runs inside your product, and how to stop praying your webhooks fire. It's almost never "X killed Y" - it's which tool actually fits the situation in front of you.