Build or Replaced
Today: Qwen 3.6 27B is the sweet spot for local development | .self: A new top-level domain designed to support self-hosting | Free the Icons Episode date: 2026-06-30.
Download MP3 →JOSH: It's Tuesday, June 30. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Local AI, self-hosting, and privacy all landed on the same answer today: own your systems or accept the leash. JOSH: Stick around — Erik's got an AI pro tip at the end about using a local model as your first-pass code reviewer. JOSH: [pause] JOSH: First headline. Qwen is getting talked about as a serious local coding model. Erik, useful signal or benchmark noise? ERIK: Useful signal. The point is not that it beats Claude at everything. The point is that local models are getting good enough for real builder work where privacy, cost, and repeatability matter. JOSH: Second headline. The .self domain idea is getting attention from the self-hosting crowd. Is that actually useful? ERIK: Useful as a flag. A domain does not run backups, renew certs, or patch containers. But it does say the culture is moving back toward owning your internet presence. JOSH: Third headline. The Supreme Court privacy story around geofence warrants is back in the conversation. Why should builders care? ERIK: Because location data is not harmless exhaust. If a system can identify everyone near a place, that system needs serious guardrails before someone calls it just metadata. JOSH: [pause] JOSH: Start with the local model story. Why does a builder need that when hosted models are so strong? ERIK: Because every task does not need the big brain. That is the part people keep missing. Claude is great. GPT is great. I use frontier models every day. But I do not need a premium model reading every log line, sorting every failed test, or naming every small diff. ERIK: In a real automation system, you have layers. One layer classifies the event. One layer checks if the issue has happened before. One layer proposes a small fix. One layer reviews the diff. Then the expensive model comes in when the problem actually deserves it. JOSH: So local is not replacing the big model. It is filtering the work before it gets there. ERIK: Exactly. Local models are not the boss. They are the first worker on the line. Give them narrow jobs with clear inputs and clear pass or fail conditions. ERIK: PrimeBus is built around that idea. Events come in over NATS. Workers subscribe. A failure shows up, a reviewer agent looks at it, a fixer agent may propose a patch, and then the guardrails decide if it moves forward. ERIK: The important part is the system does not trust vibes. It trusts tests, diff size, repo rules, and whether the change matches the failure. If a model writes poetry in a Python file, the pipeline should treat that like a bad packet and drop it. JOSH: That sounds less magical than the way people describe AI agents. ERIK: Good. Magical systems wake you up at night. ERIK: The agent should be boring. It gets an event, reads the context, does the job, reports the result, and exits. If it needs ten paragraphs to explain why it might have fixed the thing, I am already suspicious. JOSH: What makes a local model good enough for that front layer? ERIK: It needs to follow instructions. It needs to stay inside the task. It needs to read code without hallucinating half the repo. And it needs to be consistent enough that you can build tests around it. ERIK: I do not need it to invent a new framework. I need it to say, this failing test points to this function, here is a minimal patch, and here is why it should pass. That is the job. JOSH: And if it is wrong? ERIK: Then the system catches it. That is why you do not let a model write directly to production. You run it in a lab. You run the tests. You inspect the diff. You make the machine prove the win. ERIK: That is how I build everything. Start small. Add guardrails. Watch the failures. Then move the good pattern into the next system. JOSH: Where would you put this in your own stack? ERIK: First-pass review. Easy. A local model can scan a diff and ask basic questions. Did the file change match the error? Did it touch unrelated code? Did it add secrets? Did it change a public contract? Did it skip tests? ERIK: Then a stronger model can do the deeper reasoning. The expensive call gets cleaner context. That saves money, but more important, it reduces noise. JOSH: Noise is the killer. ERIK: Duuude, noise is the whole problem. In networking, alert fatigue is what happens when every warning pretends it is an outage. Same thing with AI. If every small event goes to your most expensive model, you built a very fancy panic button. ERIK: PrimeSentinel exists because stuck jobs are quiet. They do not always crash. They sit there looking alive while doing nothing. A local model can help classify that kind of thing, but the watchdog has to be the source of truth. JOSH: That is very network engineer. ERIK: Correct. I trust counters, logs, health checks, and repeatable tests. The model is allowed to help. It is not allowed to be the only witness. JOSH: [pause] JOSH: That connects to the .self thing. Is this all the same movement? Local models, self-hosting, owning more of the stack? ERIK: Same direction. People are tired of renting every piece of their digital life. Their notes are rented. Their automations are rented. Their identity is rented. Their audience is rented. Then one company changes a rule and suddenly you are begging an export button to work. JOSH: But a domain does not fix that by itself. ERIK: No. A domain is the sign on the building. You still need plumbing, locks, fire alarms, and someone who knows where the breaker panel is. ERIK: Self-hosting sounds clean in a diagram. It gets real when DNS fails, a cert expires, a disk fills up, a container restarts forever, or your backup job has been silently broken for two weeks. JOSH: Wait, really? ERIK: Yes. The backup job failing silently is the classic self-hosting horror story. Everyone thinks they have backups until restore day. Restore day is when you find out if you had backups or bedtime stories. JOSH: That is bleak. ERIK: It is useful. Bleak is just production being honest. ERIK: I like self-hosting. I run my own lab because I want control. But control comes with chores. You need monitoring. You need runbooks. You need a dashboard that tells you what is alive. You need watchdogs for the jobs that do not scream when they fail. ERIK: PrimeDash is my quick view. What is up, what is down, what is weird. PrimeSentinel is the thing poking jobs that should have moved by now. Those are not shiny products. They are seatbelts. JOSH: So what would make .self meaningful instead of just a badge? ERIK: Good defaults. That is the whole answer. If .self becomes a culture around sane self-hosting patterns, I am interested. If it is just vanity domains for people running three half-broken services behind a router they forgot to patch, then we learned nothing. JOSH: What are the defaults? ERIK: TLS that renews without drama. Backups that get tested. Auth that is not duct tape. Logging that survives restarts. Health checks that measure the real thing. A simple rollback path. And one place to see what is broken. ERIK: Also, do not expose admin panels to the internet because you saw a cool screenshot. That is not bravery. That is how you donate your weekend to incident response. JOSH: How does this compare to just using managed platforms? ERIK: Managed platforms are fine when the trade is clear. I pay you, you run the boring parts, I keep moving. That is honest. ERIK: The bad version is when people think managed means they own the outcome. They usually own the bill, not the system. If the platform changes limits, pricing, policy, API behavior, or access, you are downstream from someone else's decision. JOSH: So the answer is not self-host everything. ERIK: Correct. The answer is know what must be yours. Source code. Critical data. Identity. Backups. Build pipelines. The things that can stop your work should not be mysteries. ERIK: ScanBrief can use outside sources, but the scoring and delivery are mine. BookForge can call models, but the editorial backend is mine. PrimeBus can use hosted AI, local AI, or both, because the bus is mine. ERIK: That is the line. Rent tools. Own the control plane. JOSH: That one is going on a mug. ERIK: Make it a boring mug with good uptime. JOSH: [pause] JOSH: Let’s hit the privacy story. Why does a court fight about geofence warrants belong in a builder podcast? ERIK: Because builders create the exhaust. Every app that collects location, device IDs, Wi-Fi data, Bluetooth pings, or check-ins is creating future evidence. Sometimes useful. Sometimes dangerous. Often collected because someone thought maybe we will use it later. JOSH: That is the default now. Collect first, decide later. ERIK: And that default is lazy. Storage got cheap, analytics got easy, and now everyone wants to keep everything forever. Then the legal system shows up and asks for the pile. ERIK: If your system has data, someone will eventually want it. A customer. A regulator. A court. An attacker. A bored internal admin. You need to design like that is true because it is. JOSH: What should builders do differently? ERIK: Collect less. Keep it for less time. Separate what you need from what is convenient. Put retention rules in code. Log access. Encrypt the parts that matter. Make deletion real. Do not build a surveillance database because marketing wanted a heat map. JOSH: That sounds obvious, but people skip it. ERIK: People skip it because privacy is treated like paperwork. It is architecture. It belongs in the same conversation as auth, backups, and deployment. ERIK: If I am building an automation system, I ask what the agent can see, what it can change, and what gets recorded. Same thing for user data. What do we collect? Who can see it? What can it trigger? When does it die? JOSH: What is the AI angle here? ERIK: AI makes sloppy data habits worse. If you dump every ticket, log, chat, config, and customer note into a model context, congratulations, you invented a faster way to leak things. ERIK: The model should get the minimum context needed for the task. Not the whole database. Not every secret. Not every customer record because it was easier than writing a filter. JOSH: That is where agentic workflows get scary. ERIK: Right. Agents are not scary because they are magic. They are scary because they connect permissions to decisions. A bad prompt with read-only access is one kind of problem. A bad prompt with write access, API keys, and no audit trail is a different sport. JOSH: So privacy is also an operations problem. ERIK: Absolutely. You need policies the system can enforce. Not vibes in a handbook. Real gates. ERIK: HumanRail exists in my world for that reason. If a system is not confident, or if the action crosses a boundary, route it to a human. Do not let the model guess its way through something expensive, sensitive, or hard to undo. JOSH: What would you tell a builder shipping an AI product this week? ERIK: Draw the data path before you draw the UI. Where does the data enter? Where does it get stored? Which model sees it? What gets logged? What gets retained? What can be deleted? Who has access? ERIK: If you cannot answer that, you are not ready to ship the feature. You are ready to make a demo. JOSH: That is a hard line. ERIK: Good. Demos are allowed to be messy. Products are not. 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: Use a smaller model as a bouncer before your expensive model. ERIK: Here is the pattern. Take every proposed AI task and run it through a cheap classifier first. Local model if you can. Small hosted model if you have to. Ask four things. Is this task clear? Is the context enough? Is the risk low? Does it need a stronger model? ERIK: If the answer is no, do not send it forward. Ask for more context, route it to a human, or drop it. JOSH: What does that look like in practice? ERIK: For code review, give the small model the diff, the failing test, and the repo rule. Have it return JSON. Not a paragraph. JSON. Something like risk level, files touched, likely root cause, needs frontier model, and reason. ERIK: Then your workflow decides. Low risk goes to automated checks. Medium risk goes to Claude. High risk goes to a human. That one gate will save money and catch dumb tasks before they become expensive dumb tasks. ERIK: That's your tip. Use it. JOSH: We also drop daily market picks and automation tips on YouTube — search Build or Be Replaced. 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.