OpenAI's super PAC operates an AI-generated disinformation site targeting regulation critics; California's data-deletion platform goes enforceable; and two pieces ask what engineers lose when they stop owning what they build

Tobias Gruhn

Don't Be a Meat Proxy

The piece is short but points at something structurally important as AI coding tools become ubiquitous: the failure mode where engineers become conduits rather than practitioners. A 'meat proxy' — a human who queries AI, receives output, and forwards it without processing — creates a system that could be short-circuited by directly querying the AI, which means the human in the loop adds only latency, not value. The damage compounds: reviews conducted by meat proxies carry no epistemic authority, team members who observe the pattern lose trust in recommendations, and the organization gradually loses the capacity to distinguish good outputs from plausible ones. The practical prescription is that engineers should read, validate, and synthesize AI outputs before passing them on — taking ownership of the recommendation, not just the delivery. This pairs with the parallel piece by Ankur Sethi about manually retyping LLM-generated code: both make the same underlying argument that the value of AI assistance comes from integration rather than delegation, and that the cost of losing that integration is paid slowly and invisibly in organizational knowledge decay. Neither piece is anti-AI; both are making the case that what distinguishes a professional from a pipe is judgment, and that judgment requires actual engagement with the material being relayed.

Ankur Sethi

Prevent Cognitive Debt by Manually Retyping LLM-Generated Code

Sethi's proposal — manually retype LLM-generated code rather than accepting it — is explicitly a middle path that sounds counterproductive until you work through the argument. The practice isn't primarily about verifying correctness (which careful review achieves); it's about maintaining what he calls a 'spatial map' of the codebase — the tacit understanding of how pieces relate, why structures are shaped as they are, and where the fragile assumptions live. Code accepted wholesale from an LLM can be individually correct and collectively incoherent: the functions work but the architecture has no author who understood it. Manual retyping catches hallucinations, exposes design choices worth rejecting, and keeps the engineer's mental model synchronized with what's actually in the repository. The practical implication for teams is that velocity metrics can look excellent while the underlying system becomes progressively more opaque to its maintainers — the same dynamic as technical debt, but faster and less legible because the system appears well-formed. The deeper claim is about professional responsibility: engineers should not outsource understanding to machines entirely, because systems that no one understands fail in ways that no one can diagnose. The piece reads well alongside 'Don't Be a Meat Proxy,' which addresses the same failure mode at the level of communication rather than construction.

Linuxiac

EU Age Verification Project Mandates Hardware-Bound Attestation

The EU's open-source age verification project has published its technical specification, and the central architectural requirement is hardware-bound attestation: any age credential must be cryptographically bound to a hardware security enclave (TEE) that cannot be duplicated, to prevent a single verified credential from being replicated across many devices. The security logic is sound — without hardware binding, verified credentials could be shared, defeating the verification purpose — but the implication is that 'open source' is not synonymous with 'open to participate in.' Linux desktop users, custom ROM communities, and anyone without an EU-approved secure enclave cannot participate, regardless of their ability to read and compile the source. This is a recurring collision in government digital identity work: the security properties required by the political goal (preventing circumvention of age restrictions) are in tension with the civil liberties properties required by the design goal (not requiring state-approved hardware to access a public network). The project's mandate is effectively a decision about who gets to participate in the digital public square — a decision with significant equity and access implications that the technical specification doesn't surface explicitly. The broader pattern is worth tracking: as governments build digital identity infrastructure, the security requirements they choose encode political choices about device approval regimes, which become de facto barriers to participation for communities outside the mainstream hardware market.

Ohad Ravid

Practical Memory Safety

The article takes aim at a common conflation in systems programming discourse: treating 'memory safe' as a binary property determined by whether a language can prevent exploitable vulnerabilities. Ravid's practical definition is sharper — a language is memory safe to the degree that its safety rules are intuitive and automatically enforced, meaning the cognitive burden of safety is carried by the language designer rather than the programmer. This reframing matters because 'safe' languages that require complex invariant tracking or frequent unsafe blocks give back much of the safety they promise: developers will circumvent difficult rules under time pressure, making theoretical guarantees and operational behavior diverge. The analysis is relevant to Rust in particular, which occupies an unusual position — technically safer than C++ in well-defined ways, but with ergonomic friction that puts safety in tension with productivity under deadline pressure. The deeper implication is that language safety properties should be evaluated not by their theoretical guarantees but by their empirical usage patterns: how often do people reach for `unsafe`, and why? Safety that's too hard to use correctly is safety that won't be used, and the gap between the language spec and the code that actually ships matters more than the gap between two language specs.

Cloudflare Blog

Welcome to Agents Week

Cloudflare is running a week-long publishing series on what they're calling the 'Agent Cloud' — infrastructure redesigned from first principles for AI agents rather than retrofitted from human-facing primitives. The core argument is that everything in the current web stack — pages tuned to hold human attention, dashboards built for clicking through, interfaces optimized for reading pace — is the wrong substrate for agents that have fundamentally different requirements around speed, structured data access, and persistent state. The 'Agent Cloud' must do two things simultaneously: provide agent-native primitives (durable execution, structured storage, fast tool dispatch) and translate between the human-shaped web as it exists today and the agent-optimized web being built. The framing is explicitly architectural: what does an agent actually need from the infrastructure layer? Secure access to organizational data, a development lifecycle that removes humans from the continuous operational loop, and web services that expose capabilities in machine-readable rather than human-readable form. Whether Cloudflare can build this is separate from whether the problem statement is correct — and the problem statement seems correct. The current situation, where agents scrape HTML and parse JSON APIs designed for human developers, is a significant source of reliability and efficiency loss; something like an agent-native infrastructure layer will be needed, and the question is who builds it and what primitives it exposes.