TL;DR eBPF is the technology that lets you run safe, sandboxed programs inside the Linux kernel without writing kernel modules. In 2026 it is the foundation under most serious observability, networking, and runtime security tools. The interesting story is not the technology itself - it is the wave of products built on top of it: Cilium for networking, Tetragon for runtime security, Pixie, Parca, and Coroot for observability, plus a long tail of vendor offerings using eBPF under the hood. For platform engineers, eBPF is not “a thing you have to learn to write.” It is a thing you have to know about so you can choose tools intelligently and understand what is happening on your nodes when those tools cause problems. The most important shift eBPF has enabled is observability without instrumentation. You can see what is happening on a system without modifying the application, without restarting it, and with low overhead. That is genuinely new. What eBPF Actually Is eBPF stands for “extended Berkeley Packet Filter,” which is historical and confusing because eBPF has long since outgrown packet filtering. The simple version: ...

TL;DR Data pipelines were optimised for human consumers - dashboards, BI tools, analysts. In 2026 a growing share of pipeline output flows directly to language models, agents, and retrieval systems. That changes the design constraints in ways that catch teams off guard. Aggregation matters less. Context fidelity matters more. Freshness behaves differently. Schema moves from rigid to negotiated. Cost shifts from compute to tokens. The biggest mistake is treating an LLM consumer as if it were just another dashboard. It is not. It does not skim, it does not interpret charts, it does not have working memory across rows. It needs to be fed. The new patterns - retrieval-aware partitioning, embedding pipelines, structured-document outputs, prompt-shaped views, evaluation harnesses for data quality - are the actual subject of “AI-native data engineering” in 2026. The Underlying Shift For thirty years the implicit consumer of every data pipeline was a human looking at a screen. Even when the pipeline ended in an API or a CSV, the conceptual end-user was someone who would interpret the output with judgement, context, and skim-reading. ...

TL;DR The open table format war between Apache Iceberg, Delta Lake, and Apache Hudi is effectively over in 2026 - and the outcome is not a single winner but a clear settlement. Iceberg has won the role of the neutral standard that engines and platforms expect to read and write. It is the format you choose when you do not want to be coupled to a single vendor. Delta has won the role of the incumbent default inside the Databricks ecosystem and remains a strong choice if Databricks is your primary engine. Delta UniForm has narrowed the gap by letting Delta tables expose Iceberg metadata. Hudi has not won a category outright. It retains a smaller but loyal user base for streaming-heavy and CDC-heavy workloads, where its design choices still genuinely fit. The interesting battle has moved up the stack to the catalog layer. The format question is mostly settled. The catalog question is the new fight. The Format Wars - A Brief History For most of the early 2020s the lakehouse story was a three-way argument about how to put ACID transactions on top of object storage. ...

TL;DR “Onchain AI agents” became the dominant crypto narrative in 2025 and has cooled meaningfully in 2026 as the picture has gotten clearer. The honest taxonomy has three buckets: agents that hold wallets and trade, agents that automate DeFi operations, and agents that exist primarily as tokens with a chatbot attached. Only the first two are doing real work. Real revenue is concentrated in agent-driven DeFi automation, MEV strategies executed by agents, and onchain payment rails for AI services. Most of the rest is meme economics dressed in technical clothing. The structural question - “do AI agents need crypto rails at all” - has become a genuinely live debate. The answer in 2026 is “yes, but only for a narrow set of jobs, and most of those jobs are not what was being pitched.” If you are evaluating an onchain AI agent project, the test is brutally simple: strip away the token and ask whether the agent does something useful. If the answer is no, the project is a token with extra steps. How We Got Here The phrase “onchain AI agent” started showing up in crypto Twitter in late 2024 and exploded in early 2025. By the middle of last year there were thousands of agent tokens, dozens of agent platforms, and a handful of agents with billion-dollar implied market caps doing things that would have embarrassed a 2010-era chatbot. ...

TL;DR Kubernetes won the orchestration argument years ago. The question is no longer “should we use Kubernetes.” It is “should this particular team, with this particular workload, with this particular budget, pay the operational tax.” For genuinely large, multi-tenant, multi-region platforms with dedicated infrastructure teams, the answer is still mostly yes. The ecosystem maturity is unmatched and the alternatives lose at scale. For mid-sized engineering organisations, the answer in 2026 is probably not, and increasingly not. Managed serverless, container platforms like Fly and Railway, and the new generation of platform-as-a-service offerings are competitive in ways they were not three years ago. For startups and small teams, the answer is almost always no, and stop pretending otherwise. The honest read in 2026: Kubernetes is the right answer to fewer questions than it used to be, and being honest about that is now a competitive advantage rather than a heresy. How We Got Here Kubernetes was the right idea at the right time. By the late 2010s, every serious engineering team needed an answer to “how do we run containers in production.” Kubernetes provided one, it was open, it was backed by a credible foundation, and the cloud providers all blessed it. Within five years it was the default. Within ten years it was the assumption. ...

TL;DR Artemis III is supposed to land two astronauts near the lunar south pole using a stripped-down SpaceX Starship as the Human Landing System (HLS). The architecture is genuinely audacious - it requires a new super-heavy rocket to fly several times before the crewed mission, on-orbit cryogenic propellant transfer at a scale that has never been demonstrated, and a lunar surface stay enabled by a vehicle three times taller than the Saturn V’s lunar module. The technical risk is concentrated in propellant transfer, boil-off management, engine relight reliability, and crew ingress/egress from a 50-metre tower on a sloped, unprepared surface. The schedule risk is concentrated in everything that has to happen before the crewed flight - and most of it has not happened yet. The mission can succeed. The honest read in mid-2026 is that it will succeed late, and the more interesting question is which of these subsystems is actually the long pole. How Artemis III Is Supposed To Work Artemis III’s architecture is not Apollo. Apollo carried everything it needed in one stack on a Saturn V. Artemis III spreads the mission across multiple launches, multiple vehicles, and two distinct propulsion systems, with a crew transfer in lunar orbit. ...

If you’ve spent any time with Pianoteq or the Audio Modeling SWAM instruments, you’ve felt something different. Not the crisp accuracy of a sampled library, not the flexibility of wavetable synthesis - but something that responds like an instrument. Strings that vibrate with sympathetic resonance. Piano keys with wooden resistance. A cello that sings differently when you bow it hard versus soft. This is physical modeling: mathematics as an instrument, not just a sampler or synth engine. ...

A technical reader’s guide to where AI and crypto actually meet - without the hype. TL;DR The AI-token sector has stratified. There is a clear top tier of projects with real engineering, real revenue and visible institutional interest, and a long tail of speculation. The total AI-crypto market just crossed $17B and the measurable-infrastructure share is growing faster than the speculative tail. The five tokens worth understanding in May 2026 are Bittensor (TAO) as the conviction long, Virtuals Protocol (VIRTUAL) as the speculative growth bet, Render (RENDER) as the infrastructure hold, Artificial Superintelligence Alliance (FET / ASI) as the deep value play, and NEAR Protocol (NEAR) as the AI commerce layer. Every name on the list has drawn down 60%+ from its all-time high in the last 18 months. The drawdowns are not theoretical and they will happen again. Position-sizing matters more than picks. Worth flagging without putting them in the main basket - Kite (KITE), Internet Computer (ICP) and The Graph (GRT). Worth avoiding - the long tail of “AI memecoin” launches. Nothing here is investment advice. Prices are snapshots from publicly available data (CoinGecko, CoinMarketCap) as of 4 May 2026 and will be stale within hours. Why The Sector Looks Different In 2026 A year ago the AI-token sector was mostly a betting market on which token had “AI” most prominently in its tagline. In May 2026 the picture has changed character. There is a clear top tier of projects with measurable engineering output, real revenue, and visible institutional interest, and a long tail of names whose only product is a narrative. The total AI-crypto market cap just crossed $17B, and the share of that capital flowing into infrastructure with measurable usage has grown faster than the speculative tail. ...

TL;DR The interesting question in 2026 is not “can a local model do this”, it is “which jobs should you give it”. My stack: Ollama for inference, Letta for persistent agent memory, Obsidian as the second brain, Home Assistant for the physical world, and a small router that decides where each thought goes. Three jobs are the sweet spot for local: inbox triage, note enrichment, and routine automation. Each one is repetitive, private, and tolerant of a bit of latency. Two jobs are still worth handing to a frontier cloud model: anything novel-and-hard, and anything where you want the best draft on the first attempt. The bit nobody talks about is the router. The model is not the product. The thing that decides which model gets which job is the product. Why Local Got Interesting For years the answer to “should I run an LLM locally” was “no, just use the API”. The API was cheaper, faster, smarter, and you did not have to think about VRAM. The only reason to go local was privacy, and most people did not actually care about privacy enough to give up the quality gap. ...

Most people writing about AI risk in 2026 are recent arrivals. Roman Yampolskiy is not. He has been making the same argument - that advanced AI systems may be fundamentally uncontrollable - since before the field of AI safety had a settled name, which is partly because he is the one who gave it that name. Whether you find his conclusions alarmist, prescient, or somewhere in between depends mostly on how you read the gap between current systems and the ones he writes about. This post is an attempt to lay out the man, the argument, and the reasons it deserves more than a dismissal. ...