Build or Replaced
Today: Human mathematicians are being outcounterexampled | How we measured AI writing across arXiv, and where the measurement breaks | Jelly UI: Soft-body physics for native HTML form controls Episode date: 2026-07-21.
Download MP3 →JOSH: It's Tuesday, July 21. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Agents are getting schedules, open models are getting dangerous in the good way, and land records just reminded everybody that backups are not a vibe. JOSH: Stick around — Erik's got an AI pro tip at the end about making agents prove their work before they touch production. JOSH: First headline. Human mathematicians are getting challenged by AI-generated counterexamples. Is that as strange as it sounds? ERIK: It's strange, but it's also useful. A good counterexample is a wrecking ball for weak theory, and AI is getting very good at swinging it. JOSH: Second. Kimi Work added a built-in cron engine for agent tasks. Tiny feature or big signal? ERIK: Big signal. Agents without schedules are assistants. Agents with schedules, tools, logs, and limits start acting like workers. JOSH: Third. A hacker reportedly wiped Romania's land registry database. That's not a startup outage. ERIK: No. That's society-level infrastructure. Land records, courts, tax systems, identity systems, all the boring stuff is load-bearing. JOSH: Start with Kimi Work. Built-in cron sounds like something Linux has had forever. Why should anyone care? ERIK: Because cron itself is not the story. The story is cron attached to an agent that can think, call tools, write reports, compare state, and stop when it hits a guardrail. ERIK: A chat window is useful when you're there. A scheduled agent is useful when you're asleep. That's the difference. JOSH: So it's not "ask the bot later." It's "give the bot a job." ERIK: Exactly. And that job needs shape. Run every hour. Pull these feeds. Check these systems. Compare to yesterday. Open a ticket if this condition is true. Emit an event if this threshold gets crossed. ERIK: That's automation. Not a prompt with a calendar reminder taped to it. JOSH: What does that look like in your setup? ERIK: PrimeBus is the pattern. Something happens, it emits an event. Other systems subscribe. One agent checks context. Another checks policy. Another can generate a fix. Then tests decide whether the fix gets anywhere near a merge. ERIK: The important part is the stop sign. Everybody wants the agent that takes action. Cool. Do you also have the agent that says no? JOSH: That's less exciting. ERIK: Good. Production should be boring. Exciting production becomes a meeting with twelve people and one person saying "weird, it worked in staging." JOSH: Fair. ERIK: Kimi Work putting cron inside the agent product tells people where this is going. Daily reports. Overnight checks. Scheduled research. Background data cleanup. Contract scans. Pull request review. Compliance checks. Not one-off chats. JOSH: Give me one real example. ERIK: ScanBrief is an obvious one. I don't want to manually open fifty tabs every morning and pretend that's a workflow. The system pulls the feeds, scores the stories, ranks them, and hands me the shortlist. ERIK: Then I make the call. That's the right split. Machines gather and sort. Humans decide what matters. JOSH: Where do people mess it up? ERIK: Vague jobs. "Research AI news every day" is garbage. That's how you get mush with bullet points. ERIK: Better is: use these sources, dedupe by title and URL, score for model releases, agent infrastructure, security, and market impact, summarize each item in two sentences, then flag the top stories for review. ERIK: Now the agent has a job description. It can fail clearly. It can be tested. JOSH: That last part matters. ERIK: It matters more than the model. If the task can't be checked, the agent will eventually make you look dumb with confidence. JOSH: That's the signature move. ERIK: Yep. Confident wrong is the default failure mode. So build the workflow assuming that. Make it cite inputs. Make it show diffs. Make it run tests. Make it ask for a human when the blast radius is too big. JOSH: What should a normal builder do today with this? ERIK: Pick one recurring task. Not ten. One. ERIK: Something you already do every morning or every Friday. Inbox triage. Log review. Market scan. Backup check. Pull request summary. Then write the task like a runbook. ERIK: Inputs. Tools. Rules. Output. Stop conditions. ERIK: Once that works, schedule it. Then make it report only changes. If it tells you the same thing every day, it becomes noise. JOSH: That's the alert fatigue problem. ERIK: Same disease, new interface. If agents talk too much, people ignore them. If they only speak when something changed, people listen. JOSH: Next thread. Open models. There were several stories around Chinese open-weight models and model competition. What's your read? ERIK: Cheap strong models move the value up the stack. ERIK: If the model is good enough and the weights are available, the winner isn't automatically whoever has the fanciest model name. The winner is whoever has the best system around it. JOSH: Meaning routing, tools, data, that stuff? ERIK: Exactly. Model choice becomes a plumbing decision. Still important, but not religious. ERIK: PrimeRouter exists because I don't want every project hardcoded to one provider. That's fragile. One outage, one price change, one weird safety refusal, and your app is stuck staring at the wall. JOSH: So you put the models behind a gateway. ERIK: Right. The app asks for work. PrimeRouter decides where it goes. Cheap model for simple classification. Strong model for hard reasoning. Local model if the data needs to stay home. Another provider if the first one is slow or down. ERIK: That's just sane engineering. We already do this with networks. Nobody serious builds a network assuming one path never fails. JOSH: How do open weights change that? ERIK: They give builders more control. You can run the model yourself. You can test it on your own data. You can tune how it behaves. You can keep sensitive workloads off an external API. ERIK: But there's a trade. Now you own the mess. JOSH: The GPU mess. ERIK: The GPU mess, the memory mess, the quantization mess, the latency mess, the "why is tool calling weird on this model" mess. Open weights don't remove engineering. They move it into your house. JOSH: Wait, really? People talk about it like free intelligence. ERIK: Free like a puppy. The download is free. The care is not. JOSH: That's annoyingly accurate. ERIK: The money doesn't disappear. It moves. You pay in hardware, electricity, maintenance, debugging, evals, and time. ERIK: But for a builder, that's still powerful. If a local model can summarize logs, classify alerts, draft tests, or scan RFPs, I don't need to send every tiny task to the expensive model. JOSH: That's where GovContractScanner fits? ERIK: Yep. GovContractScanner can watch for opportunities and sort the boring parts before I read anything. It doesn't need a genius model for every line. It needs reliable extraction, scoring, and routing. ERIK: Same with PrimeDistro. A lot of that workflow is structured. Find businesses. Check for weak or missing sites. Generate previews. Prepare outreach. You don't need the biggest brain alive to decide whether a plumber has a broken homepage. JOSH: Some plumbers might disagree. ERIK: Their homepage already disagreed first. JOSH: Nice. ERIK: This is why agent architecture matters. You don't build one giant agent and hope. You build a pipeline. ERIK: Cheap model filters. Better model reasons. Tools verify. Tests run. Human reviews the exceptions. ERIK: That pattern wins because it respects cost and risk. JOSH: Does this mean closed models are in trouble? ERIK: Not dead. Not even close. The best closed models still matter for hard work. Coding, planning, long-context reasoning, weird edge cases. I'll pay for the tool when the tool earns it. ERIK: But closed providers don't get to charge premium prices for everything forever. The easy jobs are going to get eaten by cheaper models. JOSH: What's the practical takeaway? ERIK: Stop building model loyalty into your code. ERIK: Put a small routing layer between your app and the model. Even if it's basic. Task type, cost limit, fallback provider, logging. That gives you options. ERIK: Hardcoding one API everywhere is how you turn a vendor decision into a rebuild. JOSH: That's painful because it's true. ERIK: I've seen it in networking forever. People build around a box, then the box becomes the architecture. Same mistake, different logo. JOSH: Third story. Romania's land registry database reportedly gets wiped. Why does that one hit different? ERIK: Because that's not a website being down. That's ownership. Property. Courts. Banks. Government services. All the stuff people assume just exists. ERIK: A land registry is one of those systems nobody thinks about until it breaks. Then everybody learns the database was the product. JOSH: What should infrastructure people hear in that? ERIK: Backups are not a checkbox. Backups are a system. ERIK: You need immutable copies. Offline copies. Restore testing. Access controls. Separation of duties. Monitoring that proves the backup happened and proves the restore still works. ERIK: A backup you've never restored is a story you tell yourself. JOSH: That's harsh. ERIK: It's accurate. I've been in infrastructure long enough to know the restore is where the truth comes out. JOSH: How does this connect to automation? ERIK: Automation can make this better or worse. If your automation can delete everything quickly, congratulations, you've built a very fast disaster. ERIK: The answer is guardrails. Destructive actions require a different path. Backups get verified by a separate system. Deletes get delayed or quarantined. Admin actions get logged somewhere the admin can't rewrite. JOSH: So don't give the agent root and a dream. ERIK: Please don't. Also don't give the intern root and a dream. Same policy. JOSH: What would you build around a registry like that? ERIK: First, event logging that can't be casually altered. Every write, every delete, every permission change, every bulk operation. ERIK: Second, backup validation. Not "job completed." I want a restore test into a clean environment and a checksum or application-level validation that says the data is usable. ERIK: Third, blast-radius controls. No single account should be able to wipe production and backups. If it can, that's not an account. That's a loaded weapon. JOSH: And agents? ERIK: Agents can watch the boring stuff humans miss. Sudden delete volume. Weird login source. Backup size drops. Schema changes. Permission changes. Failed restore test. Those should all emit events. ERIK: PrimeBus-style thinking applies here. Everything important becomes a message. Messages trigger checks. Checks trigger action. Dangerous action hits a human gate. JOSH: That's where HumanRail would come in, right? ERIK: Exactly. When confidence is low or impact is high, route to a person. Don't pretend autonomy means never asking. ERIK: Real autonomy knows when to stop. JOSH: There's a theme today. Schedules, open models, land registries. It all comes back to systems. ERIK: That's the whole show. ERIK: Models are cool. Agents are cool. But systems decide whether anything survives contact with Monday morning. ERIK: A scheduled agent without logs is a liability. An open model without evals is a science project. A database without tested restores is fiction. JOSH: That's the episode title. ERIK: Probably too mean. Use it anyway. JOSH: You said earlier that agents should prove their work. Let's connect that before the tip. What does "prove" mean? ERIK: It means don't accept the answer as the evidence. ERIK: If an agent says it fixed a bug, show me the diff. Show me the test run. Show me the failing test before and passing test after. Show me what files changed. Show me what risk it sees. ERIK: If an agent says a market story matters, show me the source, the date, and why it outranked the others. ERIK: If an agent says backups are good, show me the restore record. JOSH: Not vibes. Receipts. ERIK: Exactly. Receipts or it didn't happen. JOSH: That feels like the line between a demo and a tool. ERIK: That's it. Demos can be charming. Tools need evidence. ERIK: Builders should be ruthless about this. Every agent output should attach proof. Logs, links, tests, screenshots, hashes, whatever fits the job. ERIK: Then you can trust the workflow without trusting the model. JOSH: That's a good distinction. ERIK: The model can be wrong. The workflow should catch it. JOSH: And if it doesn't? ERIK: Then you found the next guardrail to build. That's how this works. I don't treat every issue like a disaster. I treat it like a missing control. ERIK: Start in the lab. Prove the win. Add the guardrail. Then go to prod. 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: Make your agent return an evidence bundle, not just an answer. ERIK: Here's the prompt pattern: "Before you claim this is done, provide the command you ran, the result, the files changed, the tests passed, and the remaining risk. If you cannot verify it, say not verified." ERIK: Use that everywhere. Code fixes. Research. Data cleanup. Config changes. Anything that touches production or money. ERIK: Then wire your workflow so the next step reads the evidence, not the agent's confidence. Confidence is cheap. Proof costs something. 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. ERIK: Build or be replaced. JOSH: If you want these signals in your inbox every morning, scanbrief.dev. See you tomorrow.