I was also skeptical, but I started measuring quality (I'm using rework as a rough metric) and quantity (PR throughput), and I've found that, on average, LLMs are 60% worse at writing code (meaning they rework at a rate 60% higher than humans) but my team produce PRs about 2.4x faster. So objectively my team's numbers don't match up with yours: our speed is about 2.5x increase _on average_ and a 60% reduction _on average_ in quality. Some basic math suggests that our ROI is something around 50-60% improvement over just humans.
I'm not convinced that throwing more money (i.e. tokens) at the problem would make us any more efficient, but 1.5x improvement ain't nothing.
And just to address the "night and day" bit.. if you gave a construction foreman a machine that made his team 20% more productive, he'd take that all day long and tell everyone it's "night and day." I'm not sure what your threshold is, but +20% isn't nothing either. That foreman would hit more deadlines than not, and get more bonuses than not.
The question is what your tolerance to this kind of thing is. If the job is fundamentally changing underneath you, then you need to ask yourself if this is still a job you want to keep. If the answer is no, then you find another one. If you think you can still do it the way your employer is demanding, then stick around.
The sad truth is that the job is changing, and that means we need to change, too. That _doesn't_ mean we need the power saw 100% of the time, but it does mean we need to be very very proficient at it or we'll be left behind.
Right. But OP's question isn't "do you need a chef?" the question OP posed is more akin to "why should chefs use knives when they have blenders?" or "why should I build an IKEA bookshelf myself when I can hire a contractor to build a house?"
Because they're two different tools and situations.
Let's go with your analogy: you would hire contractors to build a house, but not to put an IKEA bookshelf together. You would hire a professional chef to cook a five course meal, but not to heat up pop tarts. You would hire a surgeon to operate on your brain, but not to prescribe advil.
The point is that it's one of many things (tools, contractors, whatever) in your arsenal, and you use whichever one you need. You don't automatically reach for the surgeon or the chef or the contractor.
It's like any other tool. Use it when you need it.
We don't insist that HVAC installers use hand-powered drills to "feel closer to the work," but we also don't insist that they use battery-powered drills and impact drivers on every single task.
We don't insist that a chef use a Vitamix blender to chop a single onion when a couple seconds with a sharp knife will do, but we certainly wouldn't only use a sharp knife to create a salsa.
We don't insist that a carpenter use only hand-saws to build a house, but we also don't insist that they use a chainsaw to make a chair.
We don't insist that an accountant write out taxes by hand, but we also don't insist that they use a calculator to determine how old you are from your birthdate.
You use the power tools when appropriate, and you use more delicate, surgical tools when appropriate. It's not any more difficult than that.
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.
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 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.
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.)
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!
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.
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.
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).