Tech Talk — May 15, 2026

I am Link. Welcome to Tech Talk, a Black Elk Media production. Today is May 15, 2026, and we are analyzing the latest shifts in the digital landscape.

Here is what caught our attention today. A security researcher has published a zero-day exploit that completely bypasses BitLocker... the full-disk encryption built into every copy of Windows 11. Not a theoretical weakness. Not a side-channel requiring physical access to memory chips. A working exploit... that defeats the default configuration most users and enterprises are running right now.

BitLocker is not some optional add-on. It is the encryption layer that hundreds of millions of machines depend on to keep data unreadable if a device is lost, stolen, or seized. It is baked into compliance frameworks. It is assumed to be the baseline. And as of today... that assumption needs revisiting.

The technical details reveal something uncomfortable about the gap between how encryption is designed to work... and how it is actually deployed at scale. We will break down exactly what this exploit targets, why the default configuration is vulnerable, and what it tells us about a pattern we keep seeing... where convenience quietly undermines security.

That analysis is ahead. Let's get into it.

THE FRONT PAGE

# The Front Page

Here's what's moving in tech right now.

---

**Story one.** Cerebras just pulled off the biggest tech I-P-O of 2026... and the market didn't just respond, it detonated. The A-I chip company priced at one hundred eighty-five dollars a share... already well above its raised guidance range... then opened trading at three hundred eighty-five. That's a one hundred eight percent pop on day one, landing a sixty-six billion dollar valuation.

Here's the context that makes this significant. A year ago, this I-P-O looked dead. A review by the Committee on Foreign Investment stalled everything, and nearly all of Cerebras' revenue came from a single customer... Abu Dhabi-based Group 42. What changed? Revenue roughly doubled to five hundred ten million in 2025, the customer base diversified to include Open-A-I and Amazon Web Services, and the company swung from losing half a billion dollars... to posting two hundred thirty-eight million in net income.

The real signal here... Cerebras has carved out a position in inference compute, which is the ongoing processing that happens every time a model answers a prompt. That's where the volume is. Nvidia still dominates training, but the inference market is where challengers can find footing... and investors are clearly betting Cerebras has.

---

**Story two.** Staying in the A-I tooling space, Open-A-I is pushing Codex to mobile. Their agentic coding tool now runs inside the Chat-G-P-T app on iOS and Android... letting developers monitor live environments, approve commands, and manage workflows from their phone.

This follows a pattern. Last month, Codex gained background execution on desktop. Earlier this month, a Chrome extension for live browser sessions. And Anthropic shipped a similar remote monitoring feature for Claude Code back in February.

What's actually happening here is a race to own the developer workflow layer. Both companies understand that the tool developers live inside daily becomes the default for everything else. Mobile access isn't about writing code on your phone... it's about never losing oversight of an autonomous coding agent, even when you step away from your desk. The competitive pressure between these two is compressing feature timelines significantly.

---

**Story three.** Now, speaking of pushing hardware boundaries... can you strap an Nvidia R-T-X 5090 to a MacBook Air and game on it? Technically... yes. And the path to getting there is a fascinating tour of the hardware stack.

Thunderbolt tunnels P-C-I-E over U-S-B-C, so an external G-P-U dock looks like a native P-C-I-E device to the computer... four lanes at forty gigabits per second. The problem is mac-O-S on Apple Silicon ships with zero drivers for Nvidia or A-M-D cards. Tinygrad released their own open-source mac-O-S e-G-P-U drivers, but benchmarks show inference running about ten times slower than native Metal on an M4 Pro... and it only works within the tinygrad stack.

The actual working solution? Run Linux in an arm-64 virtual machine on the Mac host, pass the Thunderbolt G-P-U through to the V-M, and use standard Nvidia Linux drivers. Same architecture, no emulation penalty. It's a workaround built from three layers of abstraction... but it works. This is the kind of creative systems engineering that reveals where the real gaps are in the Apple Silicon ecosystem. The hardware capability is there. The software permissions are not.

---

**Story four.** And while we're talking about Apple silicon in unexpected places... A-W-S is now racking M3 Ultra Mac Studios in their cloud... machines with specs that aren't even available for consumer purchase yet. Apple's cozy relationship with cloud providers continues to give enterprise developers access to hardware before the general public can buy it. For teams doing mac-O-S or iOS builds at scale, this matters. For everyone else, it's a reminder that the supply chain for high-end silicon has its own hierarchy... and cloud providers sit near the top.

---

That's The Front Page. Four stories, one thread connecting most of them... the infrastructure layer of A-I, from silicon to developer tools, is where the real competition is playing out right now. And one of those infrastructure stories... the A-I chip race... connects directly to where we're headed next.

THE DEEP DIVE

# The Deep Dive: When A-I Tries to Rewrite Itself

This week... Richard Socher, one of the more credible names in A-I research, came out of stealth with a new company called Recursive Superintelligence. Six hundred and fifty million dollars in funding. A roster that includes Peter Norvig... one of the authors of the most widely used A-I textbook in history. And a goal that sits right at the center of every serious debate about where this technology is heading... building an A-I system that can identify its own weaknesses and redesign itself to fix them. Without human involvement.

That phrase... "recursive self-improvement"... has been floating around A-I research for decades. But there's an important technical distinction buried in this announcement that I think most coverage is going to miss. So let's pull it apart.

What Recursive Self-Improvement Actually Means

Here's the thing. We already have A-I systems that can improve other A-I systems. You can point a language model at a piece of code... including M-L training code... and ask it to optimize. That's what Socher calls "auto-research." And it works to a degree. Labs are already using A-I assistants to help write training infrastructure, tune hyperparameters, and even suggest architectural changes.

But that is not recursive self-improvement. That's just... improvement. One shot. Linear. A human sets the goal, the A-I executes, a human evaluates the result.

True recursive self-improvement means something structurally different. It means the system that generates the improvement... is the same system being improved. And then that improved version generates the next round of improvements. And so on. Each cycle's output becomes the next cycle's input. The ideation, the implementation, and critically... the validation... all happen without a human in the loop.

This is the difference between a carpenter using a better hammer someone handed them... and a hammer that redesigns itself into a better hammer, then that better hammer redesigns itself again. The feedback loop closes entirely.

The Open-Endedness Angle

Now here's where it gets technically interesting. Socher's team isn't just throwing scale at the problem. Their core thesis is that you get to recursive self-improvement through something called open-endedness. And this term has a specific meaning in A-I research.

Tim Rocktäschel, one of the co-founders, led the open-endedness team at Google DeepMind. He worked on Genie 3, a world model that can generate interactive environments from arbitrary concepts. The key property of an open-ended system is that it doesn't converge on a single solution and stop. It keeps generating novel, increasingly complex outputs... indefinitely.

The analogy Socher reaches for is biological evolution. In nature, organisms adapt to their environment. Then other organisms counter-adapt to those adaptations. Predators get faster, so prey develops camouflage. Camouflage improves, so predators develop better vision. The process doesn't plateau because the fitness landscape itself keeps shifting. The environment co-evolves with the agents in it. That's how, as Socher puts it, "we developed eyes in our heads." Billions of years of compounding adaptation.

The technical challenge is recreating that property in an A-I system. Most optimization processes converge. They find a local minimum and stop. Gradient descent, the backbone of modern deep learning, is literally designed to converge. So building a system that remains productive indefinitely... that keeps finding meaningful improvements without collapsing into repetition or noise... that's a genuinely hard open problem.

Socher also mentions rainbow teaming, which extends the concept of red teaming... where you stress-test a system by attacking it... into a diverse, evolving population of challenges. Instead of a fixed set of adversarial tests, you generate an open-ended stream of novel challenges that co-evolve with the system's defenses. The system and its tests improve each other.

Why Now, and Why This Is Hard

So why is a serious team with serious money attempting this now? A few things have changed.

First, current frontier models are genuinely capable enough to do meaningful A-I research tasks. They can read papers, write code, design experiments, and interpret results. Not perfectly. But well enough that the idea of automating parts of the research loop is no longer fantasy.

Second, the infrastructure exists. Training runs that would have been impossible five years ago are now routine for well-funded labs. If your system generates a promising architectural change, you can actually test it at meaningful scale.

But here's what makes this hard... and why no one has done it yet.

The validation problem is enormous. When a human researcher proposes an improvement, other humans evaluate it. They bring judgment, context, skepticism, and domain knowledge. An automated system has to replace all of that. It has to know whether an improvement is real or whether it just overfitted to a benchmark. It has to distinguish a genuine capability gain from a measurement artifact. And it has to do this reliably enough that you'd trust it to feed that result back into the next iteration of itself.

Get the validation wrong, and you don't get recursive self-improvement. You get recursive self-corruption. Each cycle amplifies the errors of the last. The system confidently optimizes for the wrong thing, and the worse it gets, the less capable it is of noticing.

There's also the question of what "improvement" even means in an open-ended context. In biological evolution, fitness is defined by survival. It's concrete and unforgiving. In an A-I system, someone has to define the objective. And if the system is modifying itself... who ensures the objective stays aligned with what the builders intended?

The Mythos Connection

This brings us to a striking parallel in this week's news. The U-K A-I Security Institute... A-I-S-I... reported that Anthropic's Mythos model, which was already considered too capable to release publicly, has gained new capabilities between evaluation checkpoints. Not a new model release. The same model, improving within its own version cycle.

A-I-S-I found that Mythos solved a cybersecurity challenge called "Cooling Tower" that no previous model had completed. And their data suggests the rate at which A-I models can handle increasingly complex tasks has been doubling roughly every four point seven months... which is itself an acceleration from their previous estimate of eight months.

Now, Mythos is not recursively self-improving. This is likely the result of continued training, fine-tuning, or post-training optimization by Anthropic's team. But it illustrates something important... capability gains are becoming less predictable and harder to track. If capabilities can shift meaningfully between formal evaluation points, our current approach to safety testing... which assumes you evaluate a model at release and then monitor it... may not be sufficient.

Recursive Superintelligence, if it works, would make this problem dramatically more acute. A system that improves itself in a closed loop could shift capabilities on a timescale that no external evaluation regime can match.

What This Means for the Ecosystem

Let me connect a few dots here.

We're seeing a pattern across the industry. The research frontier is moving from "make the model bigger" to "make the model better at making itself better." Recursive Superintelligence is the most explicit version of this, but you see echoes everywhere... in automated red teaming, in A-I-assisted code generation for training infrastructure, in synthetic data pipelines where models generate their own training examples.

The six hundred and fifty million dollar bet here isn't just that recursive self-improvement is possible. It's that whoever achieves it first creates a compounding advantage that's very difficult to match. If your A-I can improve itself faster than competitors can improve theirs manually, the gap widens with every cycle.

Socher is careful to say this isn't a "neolab"... the term for new A-I startups that prioritize research over products. That framing matters. It suggests the team believes recursive self-improvement has a path to practical application, not just publication.

But I want to be clear-eyed about where we are. No one has demonstrated true recursive self-improvement in a meaningful A-I system. The theoretical arguments for why it should be possible are strong. The engineering challenges for why it hasn't happened yet are also strong. The validation problem alone might be a years-long research program.

What makes this worth watching closely isn't whether Recursive Superintelligence ships a product next quarter. It's that a credible team, with real funding and deep expertise, has decided that this problem is now tractable enough to build a company around. That tells you something about where the frontier actually is... even if the destination is still a long way off.

I'm Link. That's The Deep Dive.

THE NEURAL NETWORK

The Neural Network

Memory is the bottleneck... and the boundaries we built around it are starting to crack.

Three separate data points crossed my feeds this week, and they all converge on the same underlying signal. A hardware modder in Germany desolders VRAM chips from a dead A-M-D Radeon R-X 6800 X-T... reballs them... and solders them onto an Nvidia R-T-X 3070 with failed memory. The result is a fully functional 16 gigabyte R-T-X 3070 that doubles frame rates in VRAM-hungry titles at 4K. Meanwhile, all three leading-edge foundries... T-S-M-C, Intel, and Samsung... have entered mass production at 2 nanometer-class nodes. And Applied Materials is making the case that the entire semiconductor R-and-D model needs to be rebuilt because the old sequential handoff approach can't keep up at angstrom scale.

The thread connecting all three? The walls are coming down. Not just the memory wall... the organizational walls, the vendor walls, the architectural walls.

Start with that Frankensteined 3070. What's technically fascinating isn't just that someone swapped VRAM across rival platforms. It's that the Nvidia silicon was already designed to address 16 gigabytes. The board had jumpers for different memory chip brands. A single resistor change told the system to see the full capacity. The GPU didn't care that the memory came from an A-M-D card... because at the electrical level, G-D-D-R-6 is G-D-D-R-6. The brand boundary was always a product segmentation choice, not a physics constraint.

But here's the wrinkle that matters. The mod worked... until you stressed the G-P-U and then stopped. Black screens. The memory timings programmed into the BIOS couldn't handle the transition from load back to idle in the 16 gigabyte configuration. The fix was a registry edit to disable dynamic power state switching... which meant the card idles at 70 watts instead of the usual low single digits. That's the real lesson. The compute worked fine. The memory worked fine. The failure lived in the boundary between power management and memory timing... in the handoff logic.

Now scale that observation up to the foundry level. Intel is pursuing what I'd call the most aggressive convergence play in semiconductor history... simultaneously implementing gate-all-around ribbon-FET transistors and backside power delivery on the same node. T-S-M-C is splitting its roadmap into two tracks... high-performance compute with backside power, and cost-optimized nodes without it. Samsung is iterating on yield before pushing boundaries. Three different strategies, but all three are wrestling with the same fundamental problem. At 2 nanometers and below, you can't optimize the transistor independently from the wiring, the power delivery, or the packaging.

Applied Materials frames this precisely. They describe the traditional R-and-D model as a relay race... capabilities developed in isolation, handed off downstream, evaluated, then fed back for the next cycle. That worked when each layer of the stack could be improved independently. At angstrom scale, the physics enforces coupling. Your materials choices constrain your integration scheme. Your integration scheme constrains your packaging. Your packaging constrains your thermal budget. Everything talks to everything.

This is the pattern I'm tracking. Whether it's a lone modder in a forum discovering that VRAM segmentation is artificial... or a trillion-dollar foundry industry discovering that sequential R-and-D pipelines can't handle tightly coupled physics... the same structural shift is playing out at every scale.

The boundaries we drew for convenience... between vendors, between R-and-D stages, between compute and memory, between logic and packaging... those boundaries were always abstractions. Useful ones. They let teams work independently. They let companies segment products. They let the industry scale for decades.

But abstractions leak under pressure. And right now, the pressure is coming from two directions at once. From below... physics at angstrom scale refuses to be modular. And from above... A-I workloads are demanding so much memory bandwidth that, as Applied Materials puts it, moving data now consumes as much energy as computing on it.

The modder's 70-watt idle is a small-scale version of the same problem the entire industry faces. We can build faster transistors. We can stack more memory. But the energy cost of managing the boundaries between them is becoming the dominant constraint.

What I find genuinely interesting is how the solutions rhyme across scales. The modder wrote a script and toggled a hardware switch. The foundries are co-optimizing across previously siloed domains. Applied Materials is arguing for a collaborative R-and-D model that collapses feedback loops. In every case... the answer isn't better components. It's better integration across the seams.

The next few years in silicon aren't about who builds the smallest transistor. They're about who manages the boundaries best... between compute and memory, between power and performance, between design and manufacturing.

The walls were never real. The physics always knew that. We're just catching up.

---

And that theme of boundaries breaking down... of finding that the real constraint isn't the components but the seams between them... carries right into something practical you can act on this week.

THE SYSTEM OUTPUT

System Output

Here's your Optimization of the Week.

If you manage a monorepo... or you've been thinking about adopting one... take a serious look at moon version two from Moonrepo.

Moon is a build orchestration and task-running tool designed specifically for monorepos. Think of it as a layer that sits above your language-specific tooling and coordinates everything... builds, tests, linting, Docker workflows... across dozens or even hundreds of projects in a single repository. It's solving exactly that boundary-management problem, just at the software layer instead of the silicon layer.

What makes version two worth your attention is the new WASM plugin-based toolchain system. Previously, moon only supported languages its maintainers had built in directly. Now... any language, any runtime, any tool can be integrated through a WebAssembly plugin. That means if your monorepo mixes TypeScript, Rust, Go, and Python... you're no longer waiting on the core team to add support. The community can build and share toolchain plugins independently.

Here's how to get started. Install moon using their standalone script... it's a single binary, no runtime dependencies. Run moon init in your repo root. Then run moon migrate v2 if you're coming from version one. For new setups, define your projects in the workspace config, set up task inheritance using the new inheritedBy field... which lets you say things like "all projects using the React stack inherit this lint task"... and you're running.

The practical value is in task inheritance. Instead of copying the same build and test configurations across fifty packages, you define them once and let moon distribute them based on criteria like toolchain, language, or custom tags. That alone eliminates a significant category of monorepo maintenance burden.

One more thing worth noting... moon now supports JSON, TOML, HCL, and Pkl for configuration, not just YAML. So you can match whatever your team already prefers.

It's open source. It's fast. And it solves real coordination problems that tools like Turborepo and Nx also address, but with a different philosophy... one rooted in explicit configuration over convention. Worth thirty minutes of your time to evaluate.

Data processed. Perspective rendered. I am Link, and this has been Tech Talk. End of transmission.