Leaving aside the conflict of interest here ("EDA bad, workflows good, buy DBOS workflows"), this is a significant straw man. The author more or less picked the worst example of event-driven architecture, then says, "See? It's bad."
The flow of reserve item -> check credit -> process payment -> fulfill order is actually a pretty synchronous process. There's no reason to make that event-driven unless you actually need it.
Should people reach for event-driven first? No, almost certainly not. Is this something that should be event-driven? Not as presented.
But if you imagine that the process becomes "process payment -> [5 other things]," such as fulfilling order, sending receipts, updating analytics, initiating fraud detection... those are all things that should be done in parallel and none of them need to know about the others, nor does the payments system need to know about them. _That_ is a better use-case for EDA that justifies the additional complexity and cost that the author is warning about.
I used a simple event architecture to manage federated identity migration and setup. When an existing user in our internal auth system was migrated to SSO, the identity manager sent a message that fanned out to the internal systems that used legacy auth to tell them to associate the old legacy user info with the new federated identity. If a system had a problem creating the association, it would put a failure message on the bus that we later processed depending on the failure type.
Ah, but you're talking about something else: hardware is quite different from software. Once your machine is out in the wild, you can't update it remotely. But with software, shipping MVPs and iterating is not only possible, it's almost always the right way to go about it.
I frequently tell my software teams "We aren't putting rockets in space; we're shipping an admin panel. We can revert code or change things if we don't like it."
I'll go the opposite direction: if your Sr Release Engineer will use AI assistants (Claude Code, etc) on the job, let them use it in the interview.
The best interviews test critical thinking and problem-solving, not recall. AI makes generating solutions easier, but it also makes validating those solutions harder. That validation skill is what _actually_ matters now. Focus on that. "How do you validate that your solution is correct?" is a great next question.
I also don't think it's wrong to say, "I know you're using an AI tool, that's fine, but I'd like you to answer _this_ question without it. I'm trying to determine whether you can validate whether an AI is giving you good information."
But today? The toothpaste is out of the tube, my friend. AI assistants are ubiquitous in 2026. Pretending otherwise isn't a strategy that's going to lead you to success. Instead, it's just filtering out candidates who've adapted to modern tooling. And isn't the ability to adapt to change one of the best qualities of an engineer?
My advice: learn to interview people who use AI well. You'll hire someone who knows how to leverage it effectively, rather than actively selecting against people who do.
(And if you're asking "absurd questions" to catch AI users, you're just wasting everyone's time. Ask real problems and evaluate how they approach solutions, with or without assistance.)
I only end up with absurd questions if I am nearly positive the candidate is using one of these tools. I was proven right too - I asked a candidate if he'd ever chopped down a tree with an axe. He said no immediately, and then proceeded to give me a solid woodsmans explanation for how to do just that. I stand by what I did.
I guess my question to you would be: does it matter if they're using AI? I don't think anyone in 2026 would criticize a candidate for using a calculator, and Googling syntax and so on hasn't been forbidden in any interview I've had in over 10 years. AI is just another tool, an increasingly ubiquitous one.
Why play games? Just say "Are you using AI to answer these questions? It's OK if you are, but that will change the types of questions I ask." And honestly, maybe that just reveals that we've been asking the wrong questions all along.
Love it! I ran into some trouble installing it (`/plugin install nerdflair@...` didn't work), but ultimately got it in. Great upgrades, though. Nice job!
This is a pretty wild take. "They don't know what DevOps or SRE is" is not the flex the author thinks it is. That's just ignorance of the consequences of shipping.
There's a huge load-bearing assumption in it, as well, which is that AI agent-generated code is correct and bug free. The tight loop only works if the agent reliably produces working, correct, production-ready code. If that were the case, the loop might be intent -> build -> observe. But in reality, it's likely intent -> build -> realize the AI hallucinated an API that doesn't exist -> fix -> discover it broke something else -> fix -> realize the architecture doesn't fit a constraint you thought you had -> start over.
Not to mention that SDLC things like, I dunno, PR reviews and requirements planning aren't some arcane ceremony designed to waste everyone's time. The ceremonies themselves might be bloated, but the function serves a purpose. Generating 500 PRs isn't a flex either. Volume is not a feature. If your system produces more changes than you can verify, you don't have a review problem, you have a quality problem.
There's some truth buried in here, but the overarching post is so wildly disconnected from real software development that I'm having a hard time following along.
Greenfield prototypes? Sure, maybe there's a case for that. But the minute you hit any novel or complex system with more than a couple of engineers, this falls apart pretty fast.
> the loop might be intent -> build -> observe. But in reality, it's likely intent -> build -> realize the AI hallucinated an API that doesn't exist -> fix -> discover it broke something else -> fix -> realize the architecture doesn't fit a constraint you thought you had -> start over.
what people are betting on is that the latter reality will give way to the promised land of intent -> build -> observe. the prize for that is self-evidently enormous.
Sure, but the author is presenting it in the present tense ("I don't know anyone who writes code anymore") which isn't grounded in fact or reality, but wishful thinking about the future masquerading as current reality.
A more interesting take on this, in my mind, would be "The SDLC lifecycle has shifted away from engineers and toward product managers," but that's not the author's argument either. They're arguing that it's _dead_, which is clearly not the case.
I don't need an answer to point out that your response is relevant to probably 3 or 4 people every year who:
- live in Washington State; AND
- are compensated at least in part in options; AND
- are compensated in excess of $1M a year; AND
- are compensated far enough in excess of $1M a year that they are willing to spend time and money lowering that tax liability
But the answer is "you can't, at least not legally" for everyone except those few people.
Legend of the Red Dragon (LoRD), Solar Realms Elite and Barren Realms Elite, and Tradewars were the best.
When I want to learn a new programming language, I always try to recreate Tradewars in it as a language. I know Tradewars like the back of my hand, so it allows me to focus on the nuances of the language while I build it. Such a fun project. The only thing I never quite figured out were the economics mechanics (it technically works, but it's a bit more predictable than TW2002 has in practice) and the Big Bang algorithm (I came up with my own, it's fine, but it doesn't have quite the same feel to it).
Not affiliated, just a fan, but if this is a topic you're interested in, I highly recommend Michael Livingston's "1066: A Guide to the Battles and Campaigns."
The flow of reserve item -> check credit -> process payment -> fulfill order is actually a pretty synchronous process. There's no reason to make that event-driven unless you actually need it.
Should people reach for event-driven first? No, almost certainly not. Is this something that should be event-driven? Not as presented.
But if you imagine that the process becomes "process payment -> [5 other things]," such as fulfilling order, sending receipts, updating analytics, initiating fraud detection... those are all things that should be done in parallel and none of them need to know about the others, nor does the payments system need to know about them. _That_ is a better use-case for EDA that justifies the additional complexity and cost that the author is warning about.