Hacking IKEA Furniture | Build or Be Replaced

Today: Hacking IKEA Furniture | “I just chose words carefully” | Creepy Crawlies Episode date: 2026-08-31.

Transcript

JOSH: It's Monday, August 31. This is Build or Be Replaced — powered by ScanBrief.dev. I'm Josh, here with Erik Anderson. ERIK: Today's theme is simple. The internet is getting eaten by bots, clouds, and complexity, and the builders who measure it are the only ones who can fight back. JOSH: Stick around — Erik's got an AI pro tip at the end about turning vague agent tasks into testable contracts. [pause] JOSH: First headline. AI crawlers are apparently hammering Linux kernel mirrors harder than real users. Erik, is that as bad as it sounds? ERIK: Worse, because it's hidden tax. They measured fourteen CPU cores across five geo nodes just rendering git commits as HTML for crawlers. That's not traffic. That's unpaid infrastructure work. [beat] JOSH: Next up. Somebody says it takes five cloud services to hear their doorbell. ERIK: That's the perfect modern tech story. A button by your door now needs identity, push notifications, cloud routing, mobile permissions, and a prayer. Your doorbell has a dependency graph. Congrats. [beat] JOSH: Third headline. P99 zero millisecond autocomplete across 240 million domain names. ERIK: That's the one builders should read twice. Fast search isn't magic. It's data layout, memory, careful indexing, and being allergic to waste. I respect that deeply. [pause] JOSH: Let's start with the AI crawlers. What actually happened there? ERIK: A kernel mirror operator measured the load from AI crawlers, and the number that jumped out was fourteen cores doing work for crawlers across five nodes. Not serving humans. Not package downloads. Rendering git commit pages into HTML so some crawler can vacuum it up. [beat] ERIK: That matters because everybody talks about AI cost like it's only GPU spend. That's not true. There's the cost to train the model, sure. Then there's the cost shoved onto everyone else. Docs sites, mirrors, forums, Git repos, bug trackers, tiny personal blogs. They all become free training infrastructure. JOSH: Wait, really? Just crawling can be that expensive? ERIK: Absolutely. Git is cheap when you're using it like git. Ask for objects, clone packs, fetch deltas. But if a crawler walks every commit as a rendered web page, now the server is doing template rendering, disk reads, compression, TLS, logging, rate-limit checks, all of it. Multiply that by crawlers that don't cache well or don't respect crawl-delay, and you've built a CPU heater. [beat] ERIK: This is why observability matters. If you don't tag traffic, you won't see the bill. You'll just see load average climbing and assume normal growth. That's how teams get cooked. They don't know what's eating them. JOSH: How would you handle that on your own systems? ERIK: First thing, classify the traffic. User agents are not enough, but they're a start. Put the crawlers in their own bucket. Then measure CPU per route, not just requests per second. A bot hitting one expensive page can cost more than a thousand humans hitting static assets. [beat] ERIK: In my world, that event goes on PrimeBus. If a service starts burning CPU on a path that shouldn't be hot, PrimeSentinel catches the shape, and an agent can pull logs, compare yesterday, and open a task. That's the point of having telemetry. Not dashboards you admire. Systems that do something. JOSH: You've got actual numbers from this morning too, right? ERIK: Yeah. PrimeBus auto-merger has run 2295 attempts since 2026-06-05: 1507 merged, 788 blocked by Gandalf, 0 escalated to Erik. That's the story. The blocked count is not failure. That's guardrails doing their job while I sleep. [beat] ERIK: Same idea with crawler control. Don't just block everything because you're mad. Put it behind rules. Known good bots get one lane. Unknown crawlers get throttled. Expensive dynamic pages get cached or denied. Source downloads stay available. HTML vanity pages don't get to melt the box. JOSH: What does that mean for smaller builders? ERIK: It means stop assuming your hosting bill is honest demand. Add access logs. Add per-path cost. Add a crawler policy. If you're running docs, Git, package mirrors, image transforms, anything dynamic, you need rate limits before the bill shows up. [beat] ERIK: Also, static wins again. If a page doesn't need to be rendered on request, don't render it on request. Prebuild it. Cache it. Put boring files behind boring servers. Boring infrastructure survives the robot stampede. JOSH: That sounds like the least glamorous answer possible. ERIK: Correct. Glamour is expensive. Nginx serving static files is undefeated. [pause] JOSH: The doorbell story feels related, but in a different direction. Why does a doorbell need five cloud services? ERIK: Because companies turned simple events into product funnels. Press button. Camera wakes. Video goes to vendor cloud. Identity checks your account. Push service wakes your phone. App asks the cloud what happened. Maybe an automation platform gets involved. Maybe a smart speaker announces it. Five services later, someone is standing on your porch wondering if you moved. [beat] ERIK: The funny part is the physical event is tiny. A button closed a circuit. That's it. The complexity came after. JOSH: Is this just consumer tech being silly, or does it matter for work systems too? ERIK: It matters everywhere. Enterprises do the same thing. A router throws an alarm, then SNMP sends it to one tool, syslog sends it to another, ticketing opens a case, chat posts a message, somebody checks a dashboard, and nobody owns the actual workflow. It's the same doorbell. Just more expensive. [beat] ERIK: Networking taught me this. Cisco NSO is good because it gives you a source of intent and a transaction model. You don't want ten random scripts poking devices. You want declared state, service models, validation, rollback. That mindset applies outside networks too. JOSH: So what's the better pattern? ERIK: Event bus first. Then subscribers. Pressing the button should create one clean event. Doorbell pressed. Timestamp. Device ID. Confidence. Maybe a snapshot reference. After that, subscribers decide what to do. Notify phone. Turn on light. Save clip. Announce in the kitchen. But the event stays clean. [beat] ERIK: That's what PrimeBus is for in my setup. Today there are 151 services running on the production server right now, and 140 distinct projects have emitted telemetry to PrimeBus. I can't manage that with vibes. Everything talks through events, and the agents subscribe to the work they understand. JOSH: That sounds like a lot for a home lab. ERIK: It is a lot. That's why it has to be disciplined. If every service talks directly to every other service, you get spaghetti with invoices. If everything emits events and consumers are small, you can reason about it. [beat] ERIK: Take email-reactor. A client asks for a website change by email. The email gets parsed. The request becomes an event. An agent checks the site, drafts the change, runs tests, and routes risky stuff for review. I don't need the email parser to know how deployment works. I need it to describe the request clearly and hand it off. JOSH: And if it gets stuck? ERIK: PrimeSentinel watches for that. Stuck jobs are their own signal. That matters because failure is rarely dramatic. Usually it's a queue that stopped moving, a token expired, or a worker waiting forever because someone assumed happy path. [beat] ERIK: That's why the five-cloud-service doorbell bothers me. Not because clouds are evil. Because the user has no control plane. If it fails, what do you check? Wi-Fi? App permissions? Vendor outage? Push notification token? Home automation bridge? The answer is yes, which is a bad answer. JOSH: What's the builder version of fixing that? ERIK: Draw the event path. Literally. Button to event. Event to action. Action to confirmation. Then remove anything that doesn't need to be synchronous. If your system can't tolerate one vendor being slow, it's not automated. It's fragile with a nice app. [pause] JOSH: Let's talk about the autocomplete story. P99 zero milliseconds for 240 million domain names sounds fake. ERIK: It sounds fake because people use big numbers as fog machines. But this one is believable if you understand what they're chasing. P99 means nearly every lookup returns under the visible timer threshold. Not because physics ended. Because the data is shaped so the lookup barely has to think. [beat] JOSH: What's the trick? ERIK: Usually it's some combination of tries, finite-state structures, memory mapping, tight encoding, prefix pruning, and avoiding allocations. The real trick is caring. Most systems are slow because nobody made latency a requirement until after the product got fat. [beat] ERIK: Autocomplete is brutal because humans feel delay instantly. You type one letter, wait. Type another, wait. That feels broken. If the index is local, compact, and built for prefix search, you can make it feel instant. If every keystroke calls a remote API and waits on a database query, enjoy your spinner. JOSH: How does that compare to AI workflows? ERIK: Same principle. Put the expensive thinking where it belongs. Don't call Claude for work a deterministic function can do. Don't ask a model to sort branches by last commit date. Git already knows. Don't ask an agent to scrape a page if Selenium with a clear selector works. Use AI where ambiguity exists. [beat] ERIK: This is where builders waste money. They turn every step into a model call because it feels futuristic. Then the workflow is slow, expensive, and impossible to debug. The model should be the reasoning layer, not the hammer for every nail, screw, and sandwich. JOSH: Sandwich? ERIK: Some teams would send the sandwich to an LLM and ask for JSON. [beat] JOSH: Fair. ERIK: ScanBrief is a good example. This morning it scored 72 items across 56 sources. The system doesn't ask AI to do everything. Feed collection is boring code. Deduping is structured. Scoring has rules. Summaries use models where language matters. That's how you keep cost and latency sane. [beat] ERIK: Same with autocomplete. The best systems are humble. Precompute what you can. Cache what repeats. Keep hot paths tiny. Measure the ugly stuff. The faster you want the user experience to feel, the less improvisation belongs in the request path. JOSH: Is that the bigger theme today? Less magic, more measurement? ERIK: Exactly. AI crawlers expose hidden cost. Doorbells expose dependency mess. Fast autocomplete proves careful engineering still wins. None of these are really about novelty. They're about control. [beat] ERIK: Builders need to stop treating complexity like weather. It didn't just happen. Somebody added a service. Somebody skipped a cache. Somebody let crawlers hit dynamic pages. Somebody made the button depend on a cloud status page. You can choose differently. JOSH: That sounds harsh. ERIK: Good. Harsh is cheaper than an outage. [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: Write agent tasks like contracts, not wishes. Bad prompt: fix the failing job. Better prompt: inspect the failing test, identify the smallest code path that caused it, make one patch, run the exact failing test again, and stop if the fix touches unrelated files. [beat] ERIK: Add three things every time. Inputs, boundaries, and proof. Inputs are logs, files, command output. Boundaries are what the agent can change and what it must not touch. Proof is the command that decides if it worked. [beat] ERIK: Then make the agent report in a fixed shape. Cause. Change. Verification. Risk. That lets another agent, or you, review it without reading a novel. This is how you get from chat toy to production helper. 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.