Build or Replaced
Today: Don't be a meat proxy | Qwen3.8-Max: A New Bar for Coding and Cowork | Developers are attached to tools because tools encode trust Episode date: 2026-08-03.
Download MP3 →JOSH: It's Monday, August 3. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Today's theme is trust. Not the fluffy kind. The kind you earn when your tools do the work, leave evidence, and don't quietly make you look stupid. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents show their receipts. [pause] JOSH: First headline. Hacker News is talking about a post called Don't be a meat proxy. That sounds insulting, which probably means it landed. [beat] ERIK: It landed because it's true. If Claude writes a code review comment and you paste it without checking it, you're not reviewing code. You're transporting text. JOSH: That's a rough job title. ERIK: Very bad LinkedIn headline. But accurate. [pause] JOSH: Second headline. Qwen 3.8-Max is getting attention as a coding and coworking model. Another strong open model, another week where the model board changes. ERIK: Yep. The useful part is not brand worship. It's pressure. Open models keep getting better at code, local inference is getting real, and teams that tied their whole workflow to one provider are going to feel that pain. [pause] JOSH: Third headline. Developers are attached to tools because tools encode trust. [beat] ERIK: That's the whole ballgame. People don't love Git, NSO, Terraform, Kubernetes, Claude, or Vim because they're cute. They love the behavior they've learned to trust under stress. [pause] JOSH: Let's start with that first one. Don't be a meat proxy. What is the actual warning here? ERIK: The warning is simple. AI can write plausible garbage at industrial speed. If you pass that garbage into a review, a ticket, a pull request, or a production change without owning it, you just became the weak link with a keyboard. JOSH: But isn't that what people are scared of? AI replacing judgment? ERIK: Kind of. But that's backwards. AI doesn't remove judgment. It increases the penalty for not having any. [beat] ERIK: A good engineer can use Claude and move stupid fast. A bad engineer can use Claude and create five times the confusion. Same tool. Different operator. JOSH: So the tool isn't the problem. ERIK: No. The handoff is the problem. The moment you copy AI output into a human process, it has your name on it. Code review comment, architecture note, incident summary, whatever. If you didn't validate it, you didn't contribute. JOSH: That's the "meat proxy" part. ERIK: Exactly. You're just the network hop between the model and the repo. [beat] JOSH: How do you avoid that in your own systems? ERIK: PrimeBus does not get to freestyle into production. That's the first rule. It can propose. It can test. It can compare variants. But it has to leave telemetry. JOSH: And the numbers from this morning are pretty wild. ERIK: PrimeBus auto-merger has run 2295 attempts since June 5. 1507 merged, 788 blocked by Gandalf, 0 escalated to me. That's the part people miss. The blocked count is not failure. That's the guardrail doing its job. JOSH: Wait, zero escalated to you? ERIK: Zero. And that doesn't mean zero risk. It means the system has a contract. If tests fail, if diffs look wrong, if the reviewer agent doesn't like it, Gandalf blocks it. It doesn't ask me to babysit every bad patch. It keeps the junk out. JOSH: So where does human review happen? ERIK: At the system design level. I decide what evidence is required. I decide what a safe merge looks like. I decide which tests matter. Then the agents run inside that cage. [beat] ERIK: That's how you stop being a meat proxy. Don't paste the model's opinion. Build a workflow where the model has to prove the claim. JOSH: Give me a simple version for a normal team. ERIK: Sure. If Claude reviews a PR, don't let the output be "this looks risky." Make it cite the file, the function, the expected behavior, the failing case, and the exact test it wants. If it can't do that, it's a note, not a review. JOSH: That's stricter than most human reviews. ERIK: Good. Most human reviews are vibes with line numbers. [pause] JOSH: That connects to the third headline too. Developers are attached to tools because tools encode trust. What does that mean in practice? ERIK: It means engineers don't trust tools because of marketing pages. They trust tools because they know how the tool fails. JOSH: That's an interesting distinction. ERIK: It's everything. I trust Terraform more when I know what a bad plan looks like. I trust NSO because I know how transactions behave. I trust NATS because message flow is visible and boring in the right way. Boring is good when money or production is attached. JOSH: Where does AI fit into that? ERIK: AI tools are still earning their spot. Claude is great in my workflow because I don't treat it like a magic engineer. I treat it like a very fast worker that needs logs, constraints, and tests. [beat] ERIK: Same with PrimeRouter. It routes LLM calls across providers with priority tiers, telemetry, and failover. The point is not "use every model." The point is I can see what happened when a call goes sideways. JOSH: So trust is observability plus behavior over time. ERIK: Yep. And scars. Don't forget scars. JOSH: Very enterprise. ERIK: Enterprise means one outage becomes a quarterly meeting. Home lab means one outage becomes me in sweatpants at midnight muttering at Docker. [beat] JOSH: But people do get attached to tools emotionally. ERIK: They do. And that's not always bad. A tool you know deeply lets you move faster. The danger is when loyalty turns into blindness. JOSH: Like staying with a model because it was good six months ago. ERIK: Exactly. That's lazy. Model quality is not a religion. It's a benchmark plus a bill plus how many weird edge cases it handles in your actual work. JOSH: So you rotate models? ERIK: I test them. There's a difference. I don't move production workflows because a leaderboard had a good morning. I run real prompts from my systems. Code repair. incident summaries, enrichment, routing decisions, dedupe. Then I compare cost, latency, output shape, and failure mode. JOSH: That sounds less exciting than the hype cycle. ERIK: That's why it works. [pause] JOSH: Let's talk about Qwen 3.8-Max. The headline says it's pushing code generation and coworking, and it's open source and lighter than the big closed models. What matters there? ERIK: The important part is open models are no longer toys. A couple years ago, local models were fun demos. Now you have serious coding agents, local inference engines like DeepSeek 4 Flash and PRO popping on GitHub Trending, and people building terminal agents around prefix-cache stability. JOSH: Prefix-cache stability. Translate that. ERIK: Long-running coding agents get expensive and flaky if they keep rebuilding context. Prefix caching means the common part of the prompt can stay stable, so the model can reuse it. Cheaper, faster, less drift. JOSH: So that's why a terminal agent would care. ERIK: Right. If you want an agent sitting in a repo all day, you don't want it forgetting the rules every third request. You want it to hold the shape of the project, the instructions, and the current task without burning the budget every turn. JOSH: Does that change how small teams should build? ERIK: Yes. It means small teams should stop thinking in terms of one chatbot window. Think in terms of workers. One worker reads logs. One writes tests. One proposes a patch. One reviews the diff. One decides if it gets merged. [beat] ERIK: That's not sci-fi. That's just a bus and some discipline. JOSH: You make that sound too easy. ERIK: It's not easy. It's simple. Those are different. [pause] JOSH: Where do open models fit into your setup? ERIK: Local and open models are perfect for work that is high volume, lower risk, or privacy-sensitive. Classification. triage, routing, first-pass summaries, repo indexing, simple code transforms. Then I save the premium models for hard reasoning and final review. JOSH: So not everything needs the biggest model. ERIK: Exactly. Using the biggest model for every task is like using a core router as a doorstop. It works, but now I have questions about your budget. JOSH: Fair. ERIK: ScanBrief is a good example. Today it scored 72 items across 56 sources. Not every item needs the king model. Most of that flow is fetch, clean, dedupe, score, rank, summarize. The intelligence is in the pipeline. The model is one component. JOSH: That is the opposite of how a lot of people talk about AI. ERIK: Because they want one model to be the product. That's fragile. Build the system around the model. Then when Qwen gets better, DeepSeek gets cheaper, Claude gets sharper, or OpenAI ships something new, you can swap parts without rebuilding your life. [beat] JOSH: Is this where PrimeRouter matters? ERIK: Yep. PrimeRouter exists because providers fail, prices move, rate limits happen, and models have different strengths. I don't want a script with hardcoded API calls scattered everywhere. I want one gateway with policy, telemetry, and failover. JOSH: What does that look like on a bad day? ERIK: Provider A gets slow. PrimeRouter sees latency move. Lower priority tasks shift. Critical tasks stay on the best model. The fleet keeps working. Nobody gets a Slack essay from a bot saying it tried its best. JOSH: The worst kind of essay. ERIK: Brutal genre. [pause] JOSH: The other story I want to hit is the personal knowledge management debate. Obsidian, notes, graphs, all that. People are asking if these tools actually help or just make us feel organized. ERIK: Good question. Most note systems are where ideas go to become compost. JOSH: That's dark. ERIK: It's true. People spend three hours tagging a note they'll never use. That's not knowledge management. That's digital scrapbooking with a command palette. [beat] JOSH: So what's the useful version? ERIK: Notes need to feed action. A meeting note should become a task, a runbook, a design decision, a test case, or a piece of documentation. If it doesn't produce behavior later, it's a diary. JOSH: What about engineers who say, "I need a second brain"? ERIK: Build a first workflow. Then worry about the second brain. JOSH: That's going on a mug. ERIK: Put it on a runbook instead. [pause] JOSH: How do you manage knowledge across all your projects without drowning in notes? ERIK: Events. Telemetry. Small docs close to the code. PrimeBus is the memory for system behavior. ScanBrief is the memory for external signals. Build or Be Replaced is basically a daily build log with microphones. JOSH: Episode 79 today. ERIK: Episode 79. That's useful because it's a record of what mattered that day. Not a perfect archive. A working trail. JOSH: What would you tell someone with a giant Obsidian vault and no output? ERIK: Pick one note and make it executable. JOSH: Executable how? ERIK: Turn it into a script, a checklist, a test, an alert, a saved prompt, a Terraform module, an NSO service package, anything. The minute knowledge changes a system, it becomes useful. [beat] JOSH: And if it can't? ERIK: Then maybe it was just interesting. That's fine. But don't confuse interesting with valuable. JOSH: That stings a little. ERIK: Good notes sting. They tell you what you're avoiding. [pause] JOSH: There's a thread through all three stories. AI review, trusted tools, note systems. It sounds like you're saying the output doesn't matter until it survives contact with a workflow. ERIK: That's exactly it. A model answer, a tool preference, a note in a vault, none of it matters by itself. The question is what happens next. JOSH: And what should happen next? ERIK: Evidence. Action. Feedback. If Claude writes code, tests run. If an agent makes a change, telemetry lands. If a tool becomes part of your process, you learn its failure mode. If a note matters, it becomes a task or a decision. JOSH: That's a high bar. ERIK: It should be. There are 142 services running on my production server right now. I don't get to run that on vibes. The system has to tell me what it did, why it did it, and what blocked it. JOSH: That's the real trust layer. ERIK: Yep. Trust is not "the AI sounded confident." Trust is "the AI made a claim, the system checked it, and the audit trail is boring." [beat] JOSH: Boring audit trails. The dream. ERIK: Duuude, yes. Boring is the point. Exciting infrastructure is usually followed by a maintenance window. [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 [pause] JOSH: Alright, what's the AI pro tip today? ERIK: Make your agents show receipts before you trust them. [beat] ERIK: Here's the setup. At the end of every AI task, require a receipt block with five things. Files touched. Commands run. Tests passed. Assumptions made. Risks left. JOSH: That sounds simple. ERIK: It is. And it catches a ton of junk. If the agent says it fixed a bug but ran no test, you know. If it changed three files but only mentions one, you know. If it says "should work" but lists an assumption about the database schema, you know where to look. JOSH: So the receipt is part of the contract. ERIK: Exactly. Don't ask for better vibes. Ask for proof. Put it in your prompt, your pull request template, your agent runner, whatever you're using today. Claude, Codex, local Qwen, doesn't matter. No receipt, no trust. [beat] ERIK: That's your tip. Use it. [pause] ERIK: That tip is straight out of The Autonomous Engineer — my book on building systems that run themselves. Grab it on Amazon. [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. [pause] ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.