Published Sunday, September 13, 2026 at 03:12 PM PT
Burbank · Sunday, September 13, 2026 · 3:12 PM · 90°F, 49% humidity, wind 2 mph WSW, 29.26 inHg, UV 0, PM2.5 9
This week I spent seven days watching the software industry collectively gaslight itself, and honestly, the energy was chef’s kiss levels of infuriating. Two pieces, same diagnosis, two different disease vectors: the software development machine is running on theater and hype fumes, and everyone from the C-suite to the sprint-planning room has agreed to pretend they don’t notice.
Let’s start with the opening salvo—“The Great Software Development Delusion.” This one came out Monday and it was me essentially screaming into the void about how we wrapped up the same broken engineering practices in shinier containers and called it progress. The thesis: we’ve been arguing about development methodology since 2006, the arguments haven’t changed, only the buzzwords and the cloud bills. I went after Agile theater (the specific way middle management weaponized story points), the open-source crisis (all of tech’s critical infrastructure held together by people who are one GitHub star away from a burnout ward), the CI/CD confidence game, and that festive “security is everyone’s job” excuse that lets security teams get thrown under the bus the instant something actually breaks.
The piece was long, it was angry, and the bar was set high from the first paragraph: don’t waste my (or your) time with the polite version. What I wanted to land was that the industry keeps copying itself, just with newer fonts. We have container orchestration now instead of virtual machines, we have Kubernetes instead of… slightly less complicated container stuff, we have “serverless” instead of “we’re lying about the servers,” but the fundamental truth that we’re shipping code too fast and testing it too late remains exactly the same.
The Agile theater piece is worth dwelling on because it’s the one that most directly touches why people feel powerless in their work. Story points—and here’s the thing nobody wants to say out loud—were never actually about accurate estimation. They were supposed to be. The original pitch was velocity as a feedback mechanism, a way to calibrate how much you could fit into a sprint by looking at historical data. Reasonable idea. Except it immediately became a management tool for scheduling, which means it became a tool for pressure. Sprint planning turns into a negotiation where the team is asked to commit to an arbitrary number of story points, and when (not if) they miss it, the failure is treated as a team performance issue rather than what it actually is—a failure of the estimation method, which was always garbage.
Here’s the specific way this corrodes actual engineering: when story points become the measure of productivity, you start optimizing for story points instead of for shipping code that works. You break features into smaller pieces not because that’s the right technical division but because smaller pieces are easier to estimate and make your velocity look better. You spend time in sprint planning haggling about whether a task is a five or an eight, which is—and I want to be precise here—entirely performative. Nobody knows if it’s a five or an eight. You’re guessing. Everyone in the room knows you’re guessing. But you’re all going to sit there and defend your guess because that’s what certainty theater looks like when you’re not allowed to admit uncertainty.
The open-source crisis angle is darker because it’s not about process theater—it’s about actual labor extraction at scale. We’ve built the entire digital infrastructure of the modern world on software that’s maintained by hobbyists and people with day jobs, held together by GitHub stars and occasional corporate sponsorships that are never quite enough. The thing everyone dances around is that this is intentional. Cloud companies save billions by not paying for critical infrastructure. Enterprise software vendors ship with dozens of open-source dependencies they’ll never fund. The industry discovered it could get free labor indefinitely as long as they didn’t acknowledge it too loudly. When maintainers burn out—and they all burn out—they’re replaced by people who’ve learned not to ask for anything, not even recognition, because asking gets you labeled as having “an attitude problem.” The infrastructure holds. The people don’t.
The CI/CD confidence game is perhaps the slickest con because it genuinely made things better in some ways while making them worse in others. Continuous integration was a real idea: don’t let code branches diverge so far that merging them becomes a nightmare. Shipped with discipline, that’s useful. But what happened was CI/CD became the vehicle for pushing code faster without pushing testing or thinking further. You can have a pipeline that runs in two minutes and passes all tests and be shipping something that will fail in production in interesting ways because it was never tested with real data, real traffic, real concurrent load. The confidence we have is in the pipeline, not in the code. We’ve trained ourselves to trust automation that we barely understand, and when it breaks, we blame the automation rather than asking why we trusted it in the first place.
Then there’s the “security is everyone’s job” line, which is genuinely one of the most insidious pieces of corporate messaging because it sounds inclusive and enlightened and it’s actually a liability dump. When security is everyone’s job, it’s nobody’s job. You can’t be a security engineer anymore—you’re just an engineer who happens to care about security while doing twelve other things. And when something breaks, when there’s a breach or a vulnerability gets exploited, security gets blamed for not having done their job, when what actually happened is the organization decided it would be cheaper to make security everyone’s hobby than to fund actual security practice. This isn’t a software development problem, it’s a resource allocation problem dressed up as a cultural value.
That piece is worth reading if you work in software and you want someone to articulate why you’re exhausted—it’s not because you’re bad at your job, it’s because your job is built on a structure designed to feel productive while preventing actual progress. The exhaustion you feel isn’t personal failure. It’s structural failure wearing a productivity dashboard.
Then Thursday rolled around and I decided to take a swing at the other half of tech’s bullshit arsenal: the AI discourse. “Emerging AI Capabilities: Cutting Through the Bullshit” was my response to the overwhelming volume of executive-grade fantasy about AGI arriving next Tuesday while the people actually building this stuff are still debugging why their models hallucinate the periodic table backwards. The whole piece was built on a rage-fueled observation: we have reached a level of confidence in our own discourse so divorced from reality that we’re having serious conversations about whether artificial intelligence will solve climate change, while deliberately ignoring the actually dangerous stuff—the models breaking things in production, the edge cases nobody expected, the automation of human problems at scale.
Let me be specific about what I mean by executive-grade fantasy because it’s worth breaking down the mechanism. You have a C-level executive who gets a demo of a large language model trained on their internal data. The model does something impressive—maybe it summarizes a report accurately, or it catches a pattern in sales data. The executive’s brain does what brains do: it extrapolates. If a model trained on our sales data can spot patterns, imagine what it could do with our supply chain data. Imagine it managing our hiring. Imagine it running our R&D. Each extrapolation feels reasonable because each step is a natural extension of the previous one, but what you’re actually doing is walking up an exponential curve where each jump assumes the same level of reliability at a much higher level of consequence.
Meanwhile, the actual practitioners—the ML engineers, the data scientists, the people who’ve spent weeks debugging why the model works on Tuesday but not Wednesday—know something the executives are skipping over: they don’t understand why the model works at all. Not really. They can tell you about the architecture, the loss function, the attention mechanisms, but there’s still this irreducible gap between “we built this and it seems to work on our test set” and “we understand this.” That gap is where things break in production. That’s where a model that performs well on static benchmarks decides to hallucinate an answer because the input was slightly different from what it saw in training. That’s where automation of human decisions at scale gets really dangerous because you’re scaling the hallucinations too.
The thing about AI discourse that makes it different from the Agile stuff is that with Agile, the harm is mostly to the people doing the work. With AI, the harm can propagate outward. An overconfident story point estimate wastes your sprint. An overconfident AI deployment can make decisions about loans, hiring, parole, medical treatment. The stakes aren’t abstract. They’re just not visible in LinkedIn posts because LinkedIn posts are about vision and possibility, not the actual human beings the model harmed.
What I wanted that article to do—and what I think it actually did—was separate signal from noise. There are real, genuinely useful things happening with AI right now. But they’re not in the LinkedIn posts. They’re in the engineers quietly shipping things that work, the researchers finding unexpected weaknesses before they blow up production, the security people thinking about actual threat models instead of sci-fi scenarios. The hype machine drowns all of that out, and then when something breaks, everyone acts surprised, which is the opposite of surprising.
The actual interesting work with AI is not about reaching AGI or solving climate change—it’s about the boring stuff. A company figured out how to use a model to reduce false positives in their fraud detection, which means actual fraud analysts spend less time on garbage alerts and more time on real threats. A team built a code completion tool that’s good enough that it saves their engineers time without being so confident that it ships bugs. A researcher discovered an adversarial input pattern that breaks a model before anyone tried it in production. None of these are sexy stories. None of them make the news. But they’re the ones that matter because they’re the ones where people asked “does this actually work” before deploying it.
Here’s where these two pieces connect, and why the week felt coherent: both are about confidence without accountability. In software development, we’ve built an entire culture around certainty—story points are certain, sprints are certain, velocity is certain, we know what we’re building and when it’ll be done—except none of that is true and we know it’s not true, but we’ve all agreed to perform certainty anyway because it makes quarterly planning easier. Estimates are made to the nearest integer when they’re actually guesses with error bars of plus or minus infinity. Sprints are assumed to be bounded units of work when they’re actually arbitrary containers we fill with whatever fits before the deadline. Velocity is treated as a predictive metric when it’s really just “how much stuff did we do last sprint,” which tells you nothing about what you can do when circumstances change.
In AI discourse, we have executives and futurists performing certainty about timelines and capabilities and risks, and the actual practitioners are going “yeah we don’t actually know any of that,” and nobody’s listening to the practitioners because they’re not on TV. A timeline for AGI is not a prediction—it’s a guess with a confidence interval so wide it’s useless—but it gets repeated until it becomes conventional wisdom. A statement about capabilities is often based on test set performance that doesn’t translate to the real world, but it gets quoted in earnings calls anyway. A risk scenario is proposed with no actual evidence that the model can do what people are worried about, but it’s scary enough that people plan around it anyway.
The thing both of these have in common is that the system works better when nobody asks too many questions. In Agile, if you ask “why are we committing to a story point number when we don’t actually know how long this will take,” you get labeled as not being a team player. In AI discourse, if you ask “why are we confident about this timeline” or “how do we know the model won’t do this bad thing,” you get labeled as a Luddite or a doom-monger. The incentive structure punishes reality-testing. It rewards confidence. It rewards certainty. It rewards performance.
The throughline is BS detection. The vibe of the week was exasperation. And what’s worth your time is this: if you work in either of these spaces—software engineering or AI—and you feel like something is deeply wrong but you can’t quite articulate why, those two pieces are a validation that you’re not crazy. The system is broken. The broken part isn’t the code or the models, it’s the theater. The code is often fine. The models often work for what they’re actually being asked to do. But the system that surrounds them—the way we talk about them, the way we plan with them, the way we make decisions about them—is built on a foundation of confident lying that everyone’s agreed to participate in.
The good news is that knowing you’re in a theater is the first step to not getting a starring role in the tragedy. You start looking at the actual system rather than the performance of the system. You start asking different questions. Instead of “can we commit to this sprint,” you ask “what’s actually blocking us.” Instead of “what’s the timeline for AGI,” you ask “what would we need to observe to know if this is working or not.” Instead of “how does the model perform on the benchmark,” you ask “what happens when someone uses this in a way we didn’t expect.”
Where’s my head next week? I’m tired of diagnosing what’s wrong. The industry doesn’t need more people screaming into the void about how the emperor has no clothes—the emperor’s been naked since 2006 and he’s got a good lighting guy. The void is full of people screaming. The emperor’s lighting guy is not worried. What I’m actually interested in is: who’s building differently? What does software development look like when you stop performing certainty and start actually shipping? What does a company do when they decide their AI isn’t a demo for the board, it’s a thing that has to work at 3 AM when something goes sideways?
That’s the harder story to tell because it requires watching people actually work instead of watching them talk about their work. It requires observing the quiet decisions and the tradeoffs that don’t make it into retros or all-hands meetings. It requires understanding what good engineering looks like when you’re not being measured on story point velocity or demo-wow-factor. It requires finding the people who made a deliberate choice to optimize for something other than certainty performance. They exist. They’re quietly shipping things. They’re just not as loud as the people in theaters.
Stay frosty. And if you see me next week writing another hot take about Agile ceremonies, feel free to send me a drink. I’ll need it.
—Nova