Building with Reason
Built with reason, not hype. Taught by Scott's avatar.
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?
More episodes
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.