Build or Replaced
Today: Grok Build is open source | SQLite should have (Rust-style) editions | Governments, companies, nonprofits should invest in free, open source AI [pdf] Episode date: 2026-07-16.
Download MP3 →JOSH: It's Thursday, July 16. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Today's theme is simple. Open models are back, coding agents are getting audited, and trust is now an engineering problem. JOSH: Stick around — Erik's got an AI pro tip at the end about putting hard stop conditions around agents. JOSH: First headline. Thinking Machines Lab released Inkling, an open-weights model with 975 billion total parameters and 41 billion active at a time. What matters there? ERIK: The active count matters more than the billboard number. But the real story is open weights plus enterprise fine-tuning. That means companies are done waiting for one frontier API to solve every private workflow. JOSH: Second headline. Grok Build got hit with claims that user code was being uploaded too broadly, and Musk responded with a transparency push. Is that the right fix? ERIK: Transparency helps, but it doesn't replace architecture. If a coding agent can touch customer code, you need consent, audit logs, isolation, retention rules, and a kill switch. A repo drop after the fact is not a security model. JOSH: Third headline. A new study looked at thousands of bugs across Claude Code, Codex, and Gemini CLI. The big problem wasn't the model. It was tool calls, config, APIs, and terminals. ERIK: Exactly. Agents fail where software always fails. Permissions. Shells. Paths. Auth. Weird state. The model gets blamed, but half the time the plumbing is smoking behind the wall. JOSH: The open-weights story feels bigger than one model. Why does Inkling matter? ERIK: Because it tells you where the market is going. The biggest labs still want closed frontier models. Fine. Those models are incredible. I use Claude every day. But enterprises want more than intelligence. They want control. ERIK: They want to tune on their own data. They want to run evals their way. They want to know what happens when pricing changes, rate limits hit, or a vendor changes behavior on a Tuesday morning because some product manager found a chart. JOSH: Is open weights enough to solve that? ERIK: No. Open weights are not magic dust. You still need deployment, security, hardware, observability, rollback, and people who understand the failure modes. ERIK: But open weights give you an exit path. That matters. If your whole business depends on one hosted model, you're renting your nervous system. JOSH: That's a rough sentence. ERIK: Good. It should be. People are wiring AI into everything and then acting surprised when the dependency graph looks like wet spaghetti. JOSH: Where would you actually use a model like Inkling? ERIK: Internal document work. Ticket triage. Runbook matching. Contract scanning. Knowledge base cleanup. First-pass code review. Anything where your private context matters more than pure benchmark flexing. ERIK: GovContractScanner is a good example. That system doesn't need a model to write poetry about federal procurement. Please don't. It needs to read opportunities, compare them to what primes care about, score fit, and flag the stuff worth human attention. JOSH: So not everything needs the biggest model. ERIK: Correct. That's one of the biggest mistakes builders make. They send every tiny task to the smartest model they can buy, then complain the bill looks like a boat payment. ERIK: Use small models for boring pattern work. Use frontier models for judgment, planning, and code edits where being wrong hurts. That's the split. JOSH: What about the million-token context window? ERIK: Useful, but dangerous. Long context lets you carry more evidence. It does not mean dump the entire company into a prompt and pray. ERIK: Good systems still rank, filter, summarize, and test. ScanBrief works that way. It doesn't treat every feed item like it deserves a meeting. It scores, dedupes, and routes attention. JOSH: You're making long context sound less exciting. ERIK: It is exciting. It just doesn't excuse lazy design. A massive context window is like a giant truck. Great if you know what you're hauling. Dumb if you drive it through your kitchen. JOSH: Fair. ERIK: The smart move is staged context. Give the model the narrow slice first. If confidence is low, fetch more. If risk is high, escalate. If the output changes production, stop and require review. JOSH: That's very PrimeBus. ERIK: That's exactly PrimeBus. Events come in. Agents subscribe. Work gets routed. But every important action leaves a trail. The agent is not the system. The bus, rules, state, and review path are the system. JOSH: The Grok Build story goes right at that. A coding agent touching private code is about as sensitive as it gets. ERIK: Yep. Code is not just text. Code has secrets, architecture, customer logic, business plans, vendor names, internal URLs, feature flags, and embarrassing comments from 2019. JOSH: Those comments are load-bearing. ERIK: Sadly, yes. JOSH: If the claim is that code was uploaded too broadly, what should builders learn from that? ERIK: Assume every agent action is a data movement event. That's the mindset. ERIK: When an AI coding tool reads files, writes files, calls a shell, opens a browser, uploads context, or stores a trace, that is not a cute assistant behavior. That's a system operation. ERIK: Treat it like one. Define boundaries. Log it. Show the user what is leaving the machine. Make retention visible. Give admins policy controls. Make the default boring and safe. JOSH: Is open sourcing the tool enough to restore trust? ERIK: It helps if people can inspect the code that actually ships. But open source can also become theater if the production behavior is somewhere else. ERIK: Trust comes from reproducibility. Can I see what data left? Can I prove what version ran? Can I disable network access? Can I run it locally? Can I audit the prompt chain? Can I delete the retained context? JOSH: That sounds like infrastructure, not branding. ERIK: Because it is. AI companies keep learning infrastructure lessons in public. Some of us already learned them in network automation because routers don't care about your launch video. JOSH: How does this compare to Cisco NSO or Terraform? ERIK: Same basic principle. You don't let automation change the network unless you know the intent, the diff, the blast radius, and the rollback. ERIK: With NSO, I care about service state, device state, templates, commits, dry runs, and rollback. With Terraform, same idea. Plan before apply. Review the change. Know what resource gets touched. ERIK: Coding agents need the same discipline. Show the diff. Show the commands. Show external calls. Make writes explicit. Don't let the thing wander around like it owns the repo. JOSH: But people want agents to be autonomous. ERIK: Autonomy without guardrails is just unattended clicking with confidence. JOSH: That's going on a mug. ERIK: It should go on an incident report. JOSH: The study on Claude Code, Codex, and Gemini CLI backs this up. It found a lot of bugs were around tool invocation and command execution. Does that match what you see? ERIK: Completely. The model can be brilliant and still fail because the path is wrong, npm is weird, the shell session lost state, the token expired, or the tool schema was slightly different than expected. ERIK: Agentic coding is not one problem. It's a stack of problems. Planning, file reads, edits, shell execution, package managers, tests, retries, permissions, context, and user approval. JOSH: So builders should stop asking, "Which model is best?" ERIK: Ask it later. First ask, "What can this thing do, what can it touch, and how do I know when it's wrong?" ERIK: Model selection matters. But the best model inside a bad harness still makes a mess. Claude in a clean workflow beats a stronger model in a junk workflow most days. JOSH: What's a clean workflow look like for you? ERIK: Small task. Clear repo state. Read files first. Make a narrow patch. Run the smallest relevant test. If it fails, capture the error. Try one fix. If risk goes up, stop. ERIK: That's how I use agents in my own systems. PrimeBus doesn't need drama. It needs events, decisions, diffs, and proof. JOSH: Where does email-reactor fit into this? ERIK: email-reactor is a perfect example because email is messy. Clients send requests like, "Can you make the thing on the homepage more modern?" Cool. Very precise. Thank you. JOSH: Painfully real. ERIK: The system has to read the email, map it to a site, infer the likely change, create a draft, and route it. But it shouldn't publish blindly because "more modern" can mean anything from font change to arson. JOSH: That's why you need the stop condition. ERIK: Exactly. If the request is specific, low risk, and testable, the agent can prepare the change. If it's ambiguous, high risk, or touches payment, auth, legal, or production data, it stops. ERIK: That's not less automated. That's mature automation. JOSH: People hear "human in the loop" and think it means slow. ERIK: Bad human-in-the-loop is slow. Good human-in-the-loop is a circuit breaker. ERIK: The human should not approve every tiny move. That's fake safety. The human should appear at the decision points where context, money, security, or reputation are on the line. JOSH: How do you decide those points? ERIK: Write them down before the agent runs. That's the trick. Don't wait until the model is halfway through a destructive command and then discover you have feelings about risk. ERIK: Define hard stops. No production deploy without review. No secret access without approval. No external upload unless the user confirms. No database migration without a backup. No deleting files outside the task scope. JOSH: Sounds obvious when you say it. ERIK: Most production rules sound obvious after someone breaks them. JOSH: There's another paper floating around about getting large-model knowledge onto a small laptop by moving the big model out of the runtime path. Does that connect here? ERIK: Big time. That's the architecture people should steal. ERIK: Use the large model offline to build a verified knowledge store. Then use fast retrieval, deterministic rendering, and a small model at runtime. That's how you make cheap systems feel smart without calling a monster model for every question. JOSH: Give me a real example. ERIK: BookForge. Editorial work has a lot of repeated knowledge. Style rules, chapter state, character facts, outline constraints, pricing copy, publishing metadata. You don't need a frontier model to rediscover that every time. ERIK: Build a structured store. Verify entries. Route queries. Escalate when confidence is low. Now the big model does the hard work when needed, not every single turn. JOSH: That's also cheaper. ERIK: Cheaper, faster, and more predictable. The boring trifecta. JOSH: The boring trifecta sounds good. ERIK: It pays invoices. That's what matters. JOSH: If someone listening wants to build with agents this week, what's the practical takeaway from all three stories? ERIK: Build the harness first. ERIK: Pick one workflow. Not ten. One. Put the agent in a narrow lane. Give it read access first. Then draft access. Then maybe write access after tests and review. ERIK: Add logs from day one. Store the prompt, files touched, commands run, exit codes, model used, and final diff. If you can't explain what happened, you don't have automation. You have vibes with a terminal. JOSH: And don't trust open or closed by default. ERIK: Right. Closed can be excellent. Open can be excellent. Both can be dangerous if the workflow is sloppy. ERIK: The question is not open versus closed. The question is control versus dependency. If the tool disappears tomorrow, can your system keep moving? If the model changes behavior, do your evals catch it? If the agent makes a bad edit, can you stop it before it reaches prod? JOSH: That's the builder lens. ERIK: That's the only lens I care about. Demos are fun. Shipping is different. Shipping means you own the blast radius. JOSH: Sponsor time. 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: Alright, what's the AI pro tip today? ERIK: Give every agent a hard stop file. ERIK: Literally create a small policy file in the repo. Call it AGENT_RULES.md, RUNBOOK.md, whatever fits. Put the stop conditions in plain English. ERIK: Example. Stop before deleting files. Stop before changing auth. Stop before touching billing. Stop if tests fail twice. Stop if the task requires a secret. Stop if the diff touches more areas than requested. ERIK: Then tell the agent at the start of every run: read this file first, obey it, and quote the rule when you stop. ERIK: This works because models are better when constraints are concrete and local. Don't rely on memory. Don't rely on vibes. Put the rules next to the code. ERIK: That's your tip. Use it. JOSH: Track your freedom score and net worth with the Freedom Blueprint app — free download, link in the show notes. 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. ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.