AI-generated patch spam killed AppleTalk, AI agents are blamed for misrouting incidents, and a 70-year pattern says the ‘no more code’ promise won’t land any differently this time.

1. Linux drops AppleTalk – AI-generated patch spam forced the issue — Phoronix · Jun 17
   Linux 7.2 removes AppleTalk’s ~4,000 lines of kernel networking code, with Jakub Kicinski citing a burst of AI-generated patches that nobody was reviewing as the final push to drop it. AppleTalk has been dead since Apple killed it in macOS 10.6 back in 2009, so there’s no practical loss here – but the removal mechanism is notable: AI patch spam is now actively accelerating the cleanup of legacy code by making the maintenance cost visible. The uAPI headers stay for now to reduce controversy. Code moves to github.com/linux-netdev/mod-orphan for anyone still curious. This follows Linux 7.1 similarly dropping ARCnet, ISDN, and ham radio drivers for the same reason, so expect AI-generated noise to keep surfacing neglected subsystems as removal candidates.
2. Is a codeless future an illusion? — Thoughtworks · Jun 15
   The “AI will eliminate code” narrative is the latest in a 70-year cycle of predictions – COBOL for executives, 4GLs for non-programmers, visual UML diagrams – none of which eliminated code, they just changed what it looks like. The core argument here: making a natural language prompt precise enough to correctly specify a complex system means you’ve written a specification, and an unambiguous specification is, by definition, source code. Yes, tools like Copilot and Cursor let engineers complete coding tasks up to 55% faster, but writing is a small fraction of the job – someone still has to read, validate and own those 500 AI-generated lines, and hiding source code behind a generation layer removes the audit trail for security flaws and license compliance. The more realistic outcome is a division of labor: humans govern architecture and domain model, AI handles boilerplate and test generation, and version-controlled source code stays the binding contract between intent and execution.
3. Your AI agent just blamed the network team. Now what? — LeadDev · Jun 15
   AI diagnostic agents are moving into production incident response – autonomously querying network configs, app logs, database metrics, and cluster state to identify root causes across team boundaries, without the 3 am politics that let senior engineers deflect blame onto whoever’s easiest to bully. The author, two years into deploying multi-agent RCA systems at a large enterprise, argues the technical architecture is the easy part: the harder problems are credential scoping, blast radius controls, and getting organizational buy-in from every team whose infrastructure the system will query before you turn it on. The key practical frames: start read-only in shadow mode for at least 30 days, never grant write access until accuracy is proven across real incidents, and treat every investigation as generating a full reasoning trail – a directed graph of hypotheses tested, evidence weighed, and dead ends logged. Without that trail, the system is a black box, and operations teams won’t trust a black box with their production environment. The progression from shadow mode to limited automated remediation is described in three phases, with the author’s observation that most orgs stall between phases one and two – and that rushing phase three risks a trust failure, not just a technical one.
4. Sandbox AI coding agents with microVMs on Fedora Linux — Fedora Magazine · Jun 15
   Running AI coding agents like Claude Code or Codex unattended on your workstation is risky – they’ll happily poke around your production cluster over kubectl or SSH, and prompt injection attacks are a real concern. Containers share the host kernel, so a kernel privilege-escalation vuln breaks that boundary; microVMs give each agent its own kernel via a hypervisor, which raises the bar meaningfully without much added friction. This walkthrough uses Fedora’s native podman with the crun-krun runtime (`dnf install crun-krun`), where you pass `–runtime=krun` and podman silently boots each container as a microVM – startup is in the hundreds of milliseconds. The article covers a full working setup for a Python/uv project using podman-compose, including the UID/GID translation and SELinux volume labels (`U,z`) that trip people up, plus a wrapper script that reduces per-project setup to three commands: init, build, run. A few gotchas: the default CPU/RAM allocation is too small and will OOM; libkrun must be >= 1.8 for Enter-key handling; and the USER Dockerfile directive is ignored at boot, so you need an entrypoint to switch users. The author is explicit that microVMs aren’t bulletproof – for genuinely dangerous workloads, use a full VM.
5. LivePerson cut Logstash costs by more than half by benchmarking GCP machine types — Elastic Blog · Jun 16
   LivePerson’s observability team benchmarked five GCP machine types for their Filebeat → Kafka → Logstash pipeline and found that switching from the default e2-standard-2 to n4d-standard-2 (AMD Milan) cut cost-per-event from $5.95 to $2.70 per 1,000 EPS – more than halving processing costs at roughly 25% higher monthly instance price. The n4d also delivered 100%+ throughput improvement on Logstash, meaning fewer instances are needed, which shrinks the required Kafka partition count and the cluster itself. On the Kafka side, swapping GZIP for LZ4 compression added independent throughput gains on both producer and consumer paths. The AMD vs. Intel split within the same e2-standard-2 machine type also produced operationally significant differences, which matters because e2 instances don’t pin to a CPU platform. The team’s broader point: cloud instance families age out of competitiveness quietly, so benchmarking throughput-per-dollar periodically – not just at initial deployment – is where the real cost leverage sits. These results are GCP-specific; AWS and Azure would need their own benchmarks.

---

// In other news

Dropped AppleTalk, sandboxed the agents, halved the Logstash bill — small wins add up. See you tomorrow.