Build or Replaced
Today: Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k | How to read more books | Ask HN: Add flag for AI-generated articles Episode date: 2026-07-13.
Download MP3 →JOSH: It's Monday, July 13. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Today's theme is simple: agents are cheap until they get chatty, confident until they touch prod, and dangerous when nobody measured the before picture. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents show their receipts before they touch your repo. JOSH: [pause] JOSH: First headline. Claude Code reportedly sends thirty-three thousand tokens before it even reads the user's prompt. OpenCode sends seven thousand. Erik, is that bad? ERIK: It depends what's in the bag. Context can save you, but thirty-three thousand startup tokens is not free. That's latency, cost, and attack surface before the real work starts. JOSH: That's a large cover charge. ERIK: Yeah. That's not a prompt. That's a carry-on bag with three laptops and a bowling ball in it. JOSH: [beat] JOSH: Second headline. A production AI agent moved to GPT-5.6 and claims it got two point two times faster and twenty-seven percent cheaper. ERIK: That's the useful kind of model news. Same workload, measured cost, measured runtime. Not vibes. Not a benchmark nobody can reproduce. Actual jobs finishing faster for less money. JOSH: Model religion gets expensive fast. ERIK: Always. And it usually has terrible logs. JOSH: [beat] JOSH: Third headline. GhostLock. A Linux kernel stack use-after-free that sat around for fifteen years. ERIK: That's the one infra teams should care about. Local privilege escalation, possible container escape path, old kernel code. Everybody loves AI news until the floor under Kubernetes has a hole in it. JOSH: [pause] JOSH: Let's start with the token story. Thirty-three thousand tokens before the prompt sounds ridiculous. What's actually happening there? ERIK: Agent tools don't just read your sentence. They build a working view of the world. Repo instructions, file summaries, tool schemas, shell context, safety rules, maybe recent history, maybe the last thing the agent learned about the project. Some of that is useful. Some of it is baggage. JOSH: So the bill starts before the work starts. ERIK: Exactly. And worse than the bill, the delay starts there too. People blame the model for being slow. Sometimes the wrapper is the slow part. It drags half the garage into context, then asks the model to change one line. JOSH: What would you measure first? ERIK: Input tokens by phase. Pre-prompt context. Planning context. Tool result context. Final response context. Don't give me one big total at the end. That's like saying the server is using CPU. Cool. Which process. JOSH: Why split it that way? ERIK: Because each phase has a different fix. If pre-prompt context is huge, trim instructions, repo maps, and unused tool schemas. If tool results are huge, stop dumping entire logs into the model. If final answers are huge, that's behavior. Tell the agent to be shorter. Different sickness, different medicine. JOSH: [beat] JOSH: You track that kind of thing in PrimeBus? ERIK: Yeah. PrimeBus is event-first. Every agent action emits telemetry. Tool call started. Tool call ended. Tests failed. Fix proposed. Review blocked. Merge allowed. I don't need a poetic summary from an agent. I need a trail I can query when something acts weird. JOSH: That sounds less fun than watching the agent type. ERIK: Watching an agent type is theater. Telemetry is what pays the bill. If ScanBrief starts pulling weird sources, I don't want to hear that it felt confident. I want the source, score, dedupe reason, and why it made the morning brief. JOSH: So token count is an ops metric. ERIK: Yep. Treat tokens like CPU, memory, disk, queue depth, and API rate. If your agent suddenly sends five times more context for the same task, that's a regression. Doesn't matter if the answer sounds smart. JOSH: What should a builder test today? ERIK: Pick one small repo task. Run it through Claude Code. Run it through OpenCode. Same prompt. Same repo state. Record input tokens, output tokens, tool calls, wall clock, test result, and files touched. Then ask which one got the job done with the least junk in the pipe. JOSH: What counts as junk? ERIK: Repeated instructions. Giant file lists. Full stack traces when the top twenty lines tell the story. Entire lock files. Tool schemas for tools that won't run. Old context from a different task. That's the stuff that quietly eats budget while everyone argues about which model has better taste. JOSH: But more context can help. ERIK: Absolutely. I'm not anti-context. I'm anti-mystery context. If a tool can tell me why it sent a chunk, fine. If it can't, cut it. Agents should earn their context like engineers earn root access. JOSH: [pause] JOSH: That connects to the GPT-5.6 migration story. Faster and cheaper sounds great, but what makes that claim believable? ERIK: Same workload. Same input set. Same scoring method. Enough runs to catch weird outliers. If they changed the prompt, changed the tools, changed the cache behavior, and changed the model, then the comparison is soup. JOSH: Soup with a chart. ERIK: Very serious soup. Probably in a slide deck. JOSH: [beat] JOSH: Two point two times faster and twenty-seven percent cheaper is still a big swing. ERIK: It is. And the reason usually isn't just token price. The real savings come from fewer retries. A better model reads the right file sooner, asks fewer bad tool calls, and stops when it's done. JOSH: Retries are the hidden bill. ERIK: Huge hidden bill. A model that costs half as much but retries three times is not cheaper. A model that does one clean pass and leaves the repo alone outside the fix is the model I want. JOSH: How do you test that without turning it into a science project? ERIK: Give the model work that matters but won't burn the house down. Failing unit test. Lint error. Broken import. Small Terraform drift. Let it propose a fix. Run the checks. Compare wall clock, files touched, and whether a human would merge it. JOSH: That sounds like how you run your own pipeline. ERIK: Pretty much. PrimeBus doesn't care which model has the nicer announcement page. It cares which agent fixed the failing check, passed tests, and didn't wander into unrelated files. Cold measurement beats loud marketing. JOSH: Where does this land for network automation? ERIK: Same place. In NSO or Terraform, the model isn't special because it can write config. A junior engineer can write config. The value is whether it can read state, understand intent, generate the smallest change, run validation, and stop. Stop is a feature. People forget that. JOSH: Stop is a feature. That's annoyingly true. ERIK: Most outages are not caused by doing nothing. They're caused by doing one more thing after the correct thing. Agents need a kill switch, a diff budget, and a reason to continue. JOSH: What's a diff budget? ERIK: A hard limit on blast radius. For example, this task may touch one test file and one implementation file. Or this change may modify one service and no database migrations. If the agent exceeds that, it pauses. HumanRail exists for that exact pattern. When confidence drops or blast radius grows, route to a person. JOSH: So the workflow is not just model selection. ERIK: Right. Model selection is one dial. The system is the product. Prompt, tools, tests, permissions, telemetry, rollback, review gates. That's where builders win. The model is the engine. You still need brakes. JOSH: [pause] JOSH: Let's talk GhostLock. Fifteen years in kernel code sounds fake. ERIK: It sounds fake until you work around enough old systems. Kernel paths get trusted because they've been there forever. That's exactly why they're dangerous. Age is not proof. It's just uptime with better branding. JOSH: What happened in plain English? ERIK: A stack use-after-free means code kept using memory after it was no longer valid. In kernel space, that's nasty because you're not crashing a random app. You're playing near the operating system's authority layer. If an attacker can shape that memory and control the timing, privilege escalation becomes possible. JOSH: And the container angle? ERIK: Containers share the host kernel. That's the part people forget. Kubernetes gives you scheduling, isolation, policies, namespaces, cgroups. Great tools. But the kernel is still the floor. If the floor breaks, the walls don't matter as much. JOSH: Wait, really? ERIK: Yeah. Containers are not tiny VMs. They don't bring their own full kernel. That's why kernel bugs matter to platform teams, even when the app team says, "But it's in a container." Cool. The bug does not care about your Jira component. JOSH: What's the first real action? ERIK: Inventory. Not patching. Inventory. You need to know which kernels are running across nodes, build agents, lab hosts, old appliances, weird edge boxes, and anything pretending to be temporary. Temporary machines have a funny way of becoming load-bearing furniture. JOSH: Then patch? ERIK: Then patch based on exposure. Internet-facing hosts first. Shared build runners. Multi-tenant Kubernetes nodes. Anything running untrusted workloads. Then the boring fleet. Boring does not mean optional. It means nobody will thank you until it saves them. JOSH: How would you wire that into automation? ERIK: Put kernel version checks on the bus. NATS event from each node. Scanner tags vulnerable versions. Policy engine decides severity. Ticket opens only when action is real. If it's high exposure, send it to an agent to prepare the change plan. If the plan touches production, require a human approval. That's not complicated. It's just discipline. JOSH: That's the runbook becoming software. ERIK: Exactly. A runbook sitting in Confluence is a museum piece. A runbook wired to events, checks, and approvals is infrastructure. When ScanBrief surfaces a kernel story, I don't want to read it and hope I remember later. I want the system asking, "Do we have this exposure?" before coffee. JOSH: That feels like the difference between news and operations. ERIK: That's the whole show. News is entertainment unless it changes a system. GhostLock should trigger inventory. The token story should trigger measurement. The model migration should trigger A/B tests. If nothing changes after you learn something, you collected trivia. JOSH: Dry, but fair. ERIK: I left school at sixteen and worked at a car wash. I did not self-teach my way into network automation so I could collect trivia with better fonts. JOSH: [beat] JOSH: For a small team, what's the minimum GhostLock response? ERIK: One command across the fleet to collect kernel versions. One spreadsheet if that's all you have. Mark exposed systems. Patch the riskiest first. Then add a recurring check so you're not doing archaeology next time. JOSH: And for a bigger team? ERIK: Tie it to asset inventory, vulnerability feed, CI runners, Kubernetes node pools, and change control. Make the system show stale kernels without someone asking. If the only person who knows exposure is a tired engineer with a terminal, that's not a process. That's a hostage situation. JOSH: There's the line. ERIK: It's true, though. The future isn't an AI agent magically fixing every CVE. The future is boring event plumbing. Good inputs. Clear policy. Small actions. Human approval when the blast radius gets real. JOSH: [pause] ERIK: This episode is sponsored by Prime Automation Solutions. If you're still doing it manually, we automate it. Also, special on a website — $250. primeautomationsolutions.com JOSH: [pause] JOSH: Alright, what's the AI pro tip today? ERIK: Make your agent produce a receipt before it edits. The receipt should say which files it plans to read, which files it may edit, what command will prove success, and what rule makes it stop. Keep it short. Five lines is enough. JOSH: Before any code changes? ERIK: Before any code changes. If the plan says it needs to edit ten files for a one-line bug, that's your warning. If it can't name the test command, it doesn't understand done. If it can't name the stop condition, it will keep wandering. JOSH: What does the prompt look like? ERIK: Say this: "Before editing, return a receipt with read files, write files, validation command, risk, and stop condition. Wait for approval if write files exceed three or risk is medium or higher." That's it. Put that in your agent instructions today. JOSH: Simple. ERIK: Simple is the point. Agents don't need more inspirational text. They need boundaries they can repeat back. That's your tip. Use it. JOSH: [pause] ERIK: That tip is straight out of The Autonomous Engineer — my book on building systems that run themselves. Grab it on Amazon. JOSH: [pause] JOSH: One more thing — we started a Discord for builders. If you're shipping AI, automation, or anything that makes a human obsolete — come hang out. Link at buildorbereplaced.dev. ERIK: Post what you built. We'll post what we're building. Real wins, real builds, no fluff. JOSH: [pause] ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.