Build or Replaced
Today: Show HN: Physically accurate black hole you can put in your room | The New AI Superpowers: Focus and Followthrough | Go Analysis Framework: modular static analysis by go team Episode date: 2026-07-27.
Download MP3 →JOSH: It's Monday, July 27. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: ScanBrief scored 72 items across 54 sources this morning, and the signal is simple: builders are getting sharper tools, and the lazy middle is getting squeezed. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents prove their work before they touch your code. [pause] JOSH: First up. Moonshot's Kimi-K3 hit HuggingFace today. Open-source, giant model, coding and reasoning focus. Erik, is this another leaderboard headline or something builders should care about? ERIK: Builders should care. A 3-trillion-parameter open model changes who gets to experiment at the frontier. You still need hardware, money, and patience, which are three things most people pretend they have. But the direction matters. JOSH: Next. The Go team has a modular static analysis framework making noise on Hacker News. That sounds dry. ERIK: Dry is where the money is. Static analysis is how you catch dumb mistakes before they become 2 a.m. incidents. If the Go team makes analysis easier to compose, teams will wire it into CI, agents, editors, and review bots. JOSH: Third headline. A U.S. citizen was charged after a GrapheneOS phone wiped during an airport search. That's a weird one. ERIK: Weird and important. Security features are not magic shields. If your device wipes during a lawful search, the legal system may treat that very differently than your threat model does. Builders need to understand consequences, not just features. [pause] JOSH: Let's start with Kimi-K3. Open models keep getting bigger. Why does this one matter? ERIK: The interesting part is not just size. Size gets the headline. The real story is access. When capable models land on HuggingFace, builders can inspect them, test them, compare them, and wire them into their own systems without waiting for one vendor's product roadmap. JOSH: But can normal people actually run that? ERIK: Not the full thing at home unless your home lab looks like a small utility company. My lab is not built for that class of model. I've got 132 services running on the production server right now, and those services are built around orchestration, not pretending I own a national GPU cluster. [beat] ERIK: But here's where people miss it. You don't need to run the full frontier model locally to benefit. You need competition. Competition changes pricing, model behavior, context lengths, coding ability, and the deal you get from hosted providers. JOSH: So it's pressure on the closed labs? ERIK: Exactly. Claude, GPT, Gemini, Kimi, Qwen, DeepSeek, all of it. The closed labs have the polish. The open models create pressure. When open gets good enough, the closed labs have to be better than convenient. That's healthy. JOSH: How do you test a model like that in your own systems? ERIK: Same way I test any tool. I don't ask, "is it smart?" That's useless. I ask, "can it do this job under constraints?" Give it a failing test. Give it a repo with weird naming. Give it a network automation task with NSO templates and real service logic. Give it logs from PrimeSentinel and ask what happened. [beat] ERIK: Then score the output. Did it preserve the interface? Did it invent APIs? Did it run the tests? Did it explain the risk? Did it produce a patch I would let near production? That's the job. JOSH: That's a lot more boring than the demo videos. ERIK: Good. Boring means you might actually ship. Flashy demos are where everyone claps while the thing quietly deletes your config folder. JOSH: Wait, really? ERIK: Not literally today. But spiritually, yes. Models are confident. Confidence is not correctness. That's why Gandalf sits in the path. PrimeBus auto-merger has run 2295 attempts since 2026-06-05: 1507 merged, 788 blocked by Gandalf, 0 escalated to Erik. That's the shape you want. JOSH: The blocked number is the point. ERIK: Yep. People hear blocked and think failure. No. Blocked means guardrails worked. The model proposed something. The reviewer caught it. The system refused to merge it. That is a win. [pause] JOSH: That connects to the Go analysis story pretty cleanly. Static analysis feels like the unglamorous cousin of AI coding. ERIK: Static analysis is the adult in the room. AI writes code fast. Static analysis tells you when the fast code is nonsense. The Go story matters because Go is already used in infrastructure, CLIs, Kubernetes tooling, network services, and all the boring things that actually run companies. JOSH: What does a modular analysis framework change? ERIK: It changes how easily teams can build their own checks. Not just generic linting. Local rules. Company rules. Project rules. "Don't call this function without a timeout." "Don't create a goroutine without a cancellation path." "Don't touch this package from that layer." That stuff saves you. JOSH: So less style police, more production safety. ERIK: Exactly. Style checks are fine, but they don't move the needle by themselves. I care about checks that prevent outages, bad merges, flaky agents, security drift, and sleepy humans clicking approve. [beat] ERIK: In my world, this is how you make AI useful. You don't just throw Claude at a repo and hope. You wrap it with tests, static checks, review agents, telemetry, and a bus. PrimeBus gets the event. Agent picks it up. Gandalf reviews. CI runs. Merge happens only if the gates pass. JOSH: That's the architecture, not the prompt. ERIK: Correct. Prompts matter, but architecture wins. A great prompt inside a bad workflow is still a guy with a clipboard standing in a burning building. JOSH: Dry humor noted. ERIK: It's infrastructure humor. Nobody asks for it, but it arrives anyway. JOSH: How would a normal team start with this? ERIK: Pick one painful class of bugs. One. Don't boil the ocean. If your Go services keep shipping missing context deadlines, write an analyzer for that. If your Terraform keeps exposing ports, write a check. If your Kubernetes manifests keep missing resource limits, block it in CI. [beat] ERIK: Then connect it to the agent. When the analyzer fails, don't just print red text. Create an event. Feed the agent the exact failure, the rule, the file, the test command, and the acceptance criteria. Make it fix the narrow problem. JOSH: So the agent isn't wandering. ERIK: Right. Wandering agents are expensive interns with admin rights. Narrow agents are useful. Give them a job, a boundary, and a judge. JOSH: How does this compare to old-school automation? ERIK: Old-school automation was mostly deterministic. Runbook says if interface is down, check this, then that. Network automation with NSO, Python, NATS, Terraform, whatever. That still matters. AI adds judgment in the messy parts, but you still need deterministic rails around it. JOSH: Rails first, model second. ERIK: Yes. The model is not your control plane. It is a worker. Treat it like one. PrimeSentinel doesn't ask a model if a job is stuck as its first move. It checks timestamps, heartbeats, process state. Then if it needs help, it can route context to an agent. Facts first. Model second. [pause] JOSH: Let's hit the GrapheneOS airport story. This one sounds like security, privacy, and law all colliding. ERIK: That's exactly what it is. A phone wipes during an airport search, and now the technical behavior becomes part of a legal argument. Builders love to talk about encryption, secure wipe, duress modes, lockdown features. All valid. But features have consequences in the real world. JOSH: What should builders take from that? ERIK: Threat models need an operator section. Not just attacker, asset, control. Also: what happens when a human uses this under stress? What happens at a border? What happens when law enforcement sees an automated wipe? What happens when your feature does the secure thing and creates a legal mess? JOSH: That sounds uncomfortable. ERIK: It should be. Security engineering is not sticker collecting. You can't just say "GrapheneOS" or "YubiKey" or "Signal" and call it done. You need to understand policy, user behavior, and failure modes. [beat] ERIK: Same idea applies to automation. If PrimeTrader gets a TradingView webhook, I don't want it making emotional decisions. It has rules. If PrimeBus sees a fix, it doesn't merge because the patch sounds confident. Gandalf checks it. CI checks it. The guardrails decide. JOSH: The pattern keeps coming back to consequences. ERIK: Always. Every useful system has consequences. If an agent can merge code, it can ship a bug. If a phone can wipe, it can destroy evidence. If a static analyzer can block a build, it can stop a release. The answer is not "never build powerful features." The answer is build them with audit trails, intent, and recovery paths. JOSH: What does that look like in practice? ERIK: For software, start with logs people can actually read. Who triggered it? What input did it see? What decision did it make? What policy allowed it? What would have stopped it? Then store enough context so you can answer those questions later without doing archaeology through six dashboards and a Slack thread. JOSH: That's very specific. ERIK: Because vague logging is a tax on future you. Future you is tired, annoyed, and has meetings. JOSH: That's wild. ERIK: It's true. The systems that survive are not the ones with the coolest model. They're the ones where the boring trail exists when something goes sideways. [pause] JOSH: There's also a story today called "The New AI Superpowers: Focus and Followthrough." That feels tied to all of this. ERIK: That's the builder theme. Focus and followthrough are the gap between playing with AI and making AI produce value. Everybody can ask a model for a prototype. Very few people turn that into a service, monitor it, bill it, maintain it, and improve it. JOSH: Why is followthrough so hard with AI? ERIK: Because AI makes starting cheap. Starting used to filter people. If you couldn't code the first version, you stopped. Now anyone can get a first version. The new filter is shipping the tenth version, fixing the auth bug, writing the cron, handling the stuck job, adding telemetry, and waking up tomorrow to make it better. [beat] ERIK: That's where builders separate. Not in the prompt. In the loop. JOSH: What's your loop? ERIK: Build small. Put it on PrimeBus. Emit telemetry. Let ScanBrief or Gandalf or whatever agent is responsible see the event. Add tests. Add a watchdog. Push it. Then watch what breaks. When it breaks, the system teaches you where the next guardrail goes. JOSH: That sounds like a lot of systems for one person. ERIK: It is. That's the point. The 12 agents in the Bobaverse fleet are there because one person can't manually babysit everything. Neo, Homer, Bill, Echo, Gandalf, Claude, GPT, all wired into the work. Not as toys. As workers with rules. JOSH: And the human stays where? ERIK: On design, judgment, and deciding what matters. I don't want to approve every tiny dependency fix. I do want to decide what the system is allowed to do. That's the difference between being replaced and becoming the person who builds the replacement machine. [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 agent produce a proof packet before it changes anything important. JOSH: What's in the packet? ERIK: Four things. The exact goal. The files it plans to touch. The commands it will run. The rollback plan. That's it. [beat] ERIK: If it can't name the files, it doesn't understand the job. If it can't name the commands, it can't prove the fix. If it can't explain rollback, it shouldn't be near production. JOSH: So this is before the patch? ERIK: Before the patch for risky work. For tiny edits, fine, move. But for code that affects auth, billing, infra, migrations, trading, network config, or anything customer-facing, make the model stop and write the proof packet first. JOSH: How would you prompt that? ERIK: Say: "Before editing, produce a proof packet with objective, touched files, validation commands, risks, and rollback. Do not modify files until the packet is complete." Then enforce it in your workflow. Don't make it a vibe. Make it a gate. [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.