The Tech Monoculture Is Finally Breaking  ## Document Notes ## Highlights - **Tech Monoculture Is Reversing** - The tech monoculture that centralized devices and experiences is beginning to fragment into diverse, purpose-driven hardware ecosystems. - New device classes (VR, AR, wearables, 3D printers) and niche form factors signal a renewed era of device diversity and experimentation. Transcript: Jerod Santo The tech monoculture is finally breaking. Jason Willems really lifted my spirits with this post, but first, the long slow decline. Quote, in the early 2000s, tech began a decades-long consolidation. Almost everything we used before became a function of a single device. Our devices lost their unique personalities. Phones became our alarm clocks, flashlights, calendars, watches, cameras, GPS units, music players, radios, journals, and gaming devices. At once. We betrayed our focus in the pursuit of convenience and the personality of our devices for homogeneity, end quote. The benefits of this transition were clear to us, but at what cost? Jason argues it was high. I tend to agree, but the pendulum is starting to swing in the other direction. Quote, new paradigms are emerging for the first time since mobile. VR is no longer experimental. Early AR is starting to reach consumers. Meta shipped a wearable that normal people use thanks to a clever Ray-Ban partnership and associated equity stake. 3D printers have become real household products. Wearables are diversifying. Smart rings, over-the glucose monitors, connected beds, end quote. Jason says he acquired more new devices in 2025 than in the previous five years combined, and 2026 is off to a hot start too. Quote, we'll never truly recreate the late 80s or mid 90s. SaaS, subscription pricing, and centralized ([Time 0:00:41](https://share.snipd.com/snip/0895c579-e298-452e-aa1d-4dcdad7f50c2)) - **Notepad++ Update Hijack** - Don Ho discovered a hosting-level compromise that allowed attackers to intercept and redirect Notepad++ updates. - He recommends downloading version 8.9 and running the installer to get the security enhancement and restore safety. Transcript: Jerod Santo Notepad++ author Don Ho shares some bad news. Quote, following the security disclosure published in the version 8.8 announcement, the investigation has continued in collaboration with external experts and with the full involvement Of my now former shared hosting provider. According to the analysis provided by the security experts, the attack involved infrastructure level compromise that allowed malicious actors to intercept and redirect update Traffic destined for servers for a regrettable length of time. What's a dev to do? Quote, I deeply apologize to all users affected by this hijacking. I recommend downloading version 8.9 which includes the relevant security enhancement and running the installer to update your Notepad++ manually. With these changes and reinforcements, I believe the situation has been resolved. ([Time 0:02:24](https://share.snipd.com/snip/f246b223-874b-45b6-b1a5-32b407843df7)) - **Count And Communicate Every Outage** - Track every outage, even brief partial ones, and report them transparently so trust can be rebuilt over time. - Implement concrete mitigation steps and count small incidents to measure and reduce them methodically. Transcript: Jerod Santo Tailscales Avery Penneran penned a system downtime apology so good I'm sharing it here for you to enjoy and perhaps to emulate. Quote, it's true that many of our outages don't sever existing connections. That's a deliberate part of the design. But if you happen to need the control plane during those minutes, you feel the outage at full force. That's not acceptable. Tailscale is critical infrastructure for a lot of organizations, and we have to earn that trust by making these incidents rarer and shorter. So what are we going to do about it? Well, a few things, end quote. After sharing four concrete steps the Tailscale team is taking to mitigate future problems, Avery says, quote, I'm not going to lie to you. None of us are proud of having counts on fingers, nine periods of partial downtime or maybe slowness in one month, even though almost all were resolved in less than an hour, even though Your data plane kept going because, well, that's who we are and who we are is a team that would rather over communicate than under communicate. Even when an incident is brief or affects only some customers, we want it to be visible and explained. We are going to keep counting every single small outage and measuring it and fracturing it into two smaller outages and eventually obliterating it one improvement at a time. That's just how it's done. ([Time 0:03:32](https://share.snipd.com/snip/eb4bcd46-7b02-423a-acaa-eb76a16a9ca4)) - **Forkable Databases For Agentic Development** - Agentic development needs snapshot-first, forkable state because agents branch, retry, and explore multiple paths. - Snapshot infrastructure is foundational for production AI systems and different implementations trade block size and latency. Transcript: Jerod Santo A Gentic development needs forkable databases. Replit and Tiger Data built the same thing. And here's why. A Gentic experimentation requires forkable state. Replit recently published details about their internal snapshotting infrastructure. They call it bottomless storage, and it's built on GCS with immutable 16 megabyte blocks. Tiger Data read it and realized they've been solving the same problem with fluid storage, just with different trade-offs. This convergence wasn't accidental, it's what happens when you actually build for how agents work. See, agents don't execute linearly, they branch, they fail, they retry. They explore multiple paths before converging on a solution. Traditional databases assume a few long-lived environments. Agentic developments invert this entirely. You need databases that you can fork instantly, experiment on safely, and roll back without consequences. The technical divergence is interesting though. Replit optimized for append-heavy workloads with 16 megabyte blocks, where a single 4-kilobyte update amplifies to 16 megabyte writes. Tiger Data went with 4-kilobyte blocks, about 1 millisecond of read latency, and less than 5 milliseconds of write latency, optimized for the fine-grained, random access patterns That database workloads actually produce. Different roads, same destination. Snapshot-based infrastructure isn't optional for production AI systems. It's foundational. ([Time 0:04:55](https://share.snipd.com/snip/76233cec-252a-4988-bf2a-aa58f8de8015)) - **Different Roads To Snapshotting** - Different storage designs converge on snapshotting but optimize different trade-offs like block size and latency. - Replit and Tiger Data reached the same destination via distinct technical choices suited to their workloads. Transcript: Jerod Santo The technical divergence is interesting though. Replit optimized for append-heavy workloads with 16 megabyte blocks, where a single 4-kilobyte update amplifies to 16 megabyte writes. Tiger Data went with 4-kilobyte blocks, about 1 millisecond of read latency, and less than 5 milliseconds of write latency, optimized for the fine-grained, random access patterns That database workloads actually produce. ([Time 0:05:46](https://share.snipd.com/snip/8de85bef-bc2d-4391-87c3-49ef77496589)) - **Four-Hour Deep Coding Ceiling** - Deep, focused coding realistically yields only three to four hours of high-quality work per day due to cognitive limits. - Treating that ceiling as the primary objective reduces burnout and improves software quality. Transcript: Jerod Santo Here's why. Here's Milan Milanovic. Quote, you probably felt it. After a few hours of coding, your brain isn't as fresh anymore. A good day can give you maybe three to four hours of deep, focused coding. After that, quality and focus drop. Research in cognitive psychology also supports the pattern. Across the teams I've led and coached, the same loop keeps showing up. Developers judge themselves by an eight-hour ideal, then feel behind when only a few hours produce real output. But high-focus work has a ceiling. Treating three to four hours as the primary objective leads to better software and less burnout. ([Time 0:06:22](https://share.snipd.com/snip/164c0542-e1ce-4908-9776-0d4895c8cb18)) - **Comprehension Debt From AI-Assisted Coding** - Relying on AI to write code increases 'comprehension debt' when engineers' reading skills lag behind the agent's output ability. - If review becomes mere rubber stamping, teams stop engineering and start hoping for correctness. Transcript: Jerod Santo Here's Addy Osmani on managing comprehension debt when leaning on AI to code. Quote, generation or writing code and discrimination, reading code, are different cognitive capabilities. You can review code competently even after your ability to write it from scratch has atrophied. But there's a threshold where review becomes rubber stamping. End quote. I feel seen in this one. I've certainly looked at areas of a code base I oversaw the writing of and struggled to understand what is going on. That being said, I've done that for code I wrote personally as well. Sometimes as recently as yesterday. Addie says, quote, the dangerous part, it's trivially easy to review code you can no longer write from scratch. If your ability to read doesn't scale with the agent's ability to output, you're not engineering anymore. ([Time 0:07:24](https://share.snipd.com/snip/09c66e10-0b5d-4cb1-a725-6a9d69721e0c))