Jason Dias

We've mostly heard of the "Hype Cycle," right? What about the "Battle Royale of Reality?" I think it's time the hype cycle slid into a trough of disillusionment and stayed there. The concept: A new technology breaks through, and then we get to enjoy these neat little phases: - a "Peak" of inflated expectations - a "Trough" of disillusionment - a "Slope" of enlightenment - a "Plateau" of productivity We seem so sure of this, like we can use it to predict the weather. "AI is coming into a trough of disillusionment this morning, but don't worry, quantum computing is looking like it's coming up to its peak." The idea appeals, its simple storyline fitting right in with what we observe. But then, when we start to look at reality, things get less neat. Ok, so AI. As you can imagine, we have been working on computer language and vision for a long, long time. Over the years, we have seen many breakthroughs. These require both hardware and software components. Machine learning models hit a massive inflection point in the 2010s because we finally had ENOUGH compute to test and use theories/math that statisticians and AI researchers posited in the 70s! GPUs bring a whole other dimension to the mix. The first GPUs were used to power arcade games (obviously). Gaming, gamers, and 3D animation pushed the tech forward. The internet. There's another technology-of-technologies so integrated we cannot reason about it effectively. The way AI / LLMs exist today could not exist without the modern internet. The sheer volume and curation of training data required to drive LLM learning would not be feasible without the internet. Obviously, data science, GPU manufacturing, and the internet itself is getting shaped by LLMs too. So for a tech like AI, you have: - math built over 60 years by statisticians and theorists - gaming driving the hardware - the internet All of these foundations get changed by the product that was built. We aren't going to see a hype cycle. We are going to see surging and receding waves potentiating and canceling each other out. We are going to see storm surges and sudden calms. We are going to see the landscape change without warning and yield something we haven't even imagined yet. And it's going to force us to let go of our quaint simplifications and start observing and questioning the reality we see. Or maybe we're just climbing the "slope of enlightenment."

6

3 Comments

Think of CIEM integrations like a universal translator for your cloud: because AWS, Azure, and GCP definitely aren't speaking the same language when it comes to permissions. 🌍🗣️ #CloudSecurity #IdentityAccessManagement #CIEM #ZeroTrust #CyberSecurity #MultiCloud #DevSecOps

1

The recent wave of spec-driven development has caught my attention, particularly projects like Robert Douglass's spec-kitty. As I've been following this trend, I can't help but notice the parallels to literate programming, a concept that's been around for decades. Literate programming operated at a more granular level though. It was typically function-scoped, providing clear explanations of the "why" behind specific implementation details. Spec-driven development, by contrast, works at a much higher level of abstraction. This raises an interesting question: are we abstracting too far? There's a risk that spec-driven development, despite its promise, might still be too close to what some call "vibe coding", development where we lack sufficient control over LLM behavior, consistency across model versions, or even repeatability of outputs from the same prompts. I wonder if we'll see the pendulum swing back toward something more akin to literate programming. Perhaps what we need is a middle ground that brings back some of that step-by-step predictability while maintaining the benefits of higher-level thinking. What are your thoughts? Have you experimented with spec-driven development at work? Do you have the experience of literate programming to compare with?

9

17 Comments