Jemaclus

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."

Hey, this is very cool and creative! I like it a lot! Great job!

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.

how can i structure my income to avoid income tax? asking for a friend.

Same!

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).

Less often, I'll try to create SRE/BRE, which, again is very fun but hard to reverse engineer. Amit (creator) lost the source code years ago, but wrote up some notes here: http://www-cs-students.stanford.edu/~amitp/Articles/SRE-Desi...

Funny, I just googled SRE/BRE to find the notes, and my last comment about it on HN was one of the top Google results... It's truly a lost art!

I think about fidonet all the time. It was a magical concept.

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."

Ihttps://www.michaellivingston.com/non-fiction/1066-a-guide-t...

"Better than JSON" is a pretty bold claim, and even though the article makes some great cases, the author is making some trade-offs that I wouldn't make, based on my 20+ year career and experience. The author makes a statement at the beginning: "I find it surprising that JSON is so omnipresent when there are far more efficient alternatives."

We might disagree on what "efficient" means. OP is focusing on computer efficiency, where as you'll see, I tend to optimize for human efficiency (and, let's be clear, JSON is efficient _enough_ for 99% of computer cases).

I think the "human readable" part is often an overlooked pro by hardcore protobuf fans. One of my fundamental philosophies of engineering historically has been "clarity over cleverness." Perhaps the corollary to this is "...and simplicity over complexity." And I think protobuf, generally speaking, falls in the cleverness part, and certainly into the complexity part (with regards to dependencies).

JSON, on the other hand, is ubiquitous, human readable (clear), and simple (little-to-no dependencies).

I've found in my career that there's tremendous value in not needing to execute code to see what a payload contains. I've seen a lot of engineers (including myself, once upon a time!) take shortcuts like using bitwise values and protobufs and things like that to make things faster or to be clever or whatever. And then I've seen those same engineers, or perhaps their successors, find great difficulty in navigating years-old protobufs, when a JSON payload is immediately clear and understandable to any human, technical or not, upon a glance.

I write MUDs for fun, and one of the things that older MUD codebases do is that they use bit flags to compress a lot of information into a tiny integer. To know what conditions a player has (hunger, thirst, cursed, etc), you do some bit manipulation and you wind up with something like 31 that represents the player being thirsty (1), hungry (2), cursed (4), with haste (8), and with shield (16). Which is great, if you're optimizing for integer compression, but it's really bad when you want a human to look at it. You have to do a bunch of math to sort of de-compress that integer into something meaningful for humans.

Similarly with protobuf, I find that it usually optimizes for the wrong thing. To be clear, one of my other fundamental philosophies about engineering is that performance is king and that you should try to make things fast, but there are certainly diminishing returns, especially in codebases where humans interact frequently with the data. Protobufs make things fast at a cost, and that cost is typically clarity and human readability. Versioning also creates more friction. I've seen teams spend an inordinate amount of effort trying to ensure that both the producer and consumer are using the same versions.

This is not to say that protobufs are useless. It's great for enforcing API contracts at the code level, and it provides those speed improvements OP mentions. There are certain high-throughput use-cases where this complexity and relative opaqueness is not only an acceptable trade off, but the right one to make. But I've found that it's not particularly common, and people reaching for protobufs are often optimizing for the wrong things. Again, clarity over cleverness and simplicity over complexity.

I know one of the arguments is "it's better for situations where you control both sides," but if you're in any kind of team with more than a couple of engineers, this stops being true. Even if your internal API is controlled by "us," that "us" can sometimes span 100+ engineers, and you might as well consider it a public API.

I'm not a protobuf hater, I just think that the vast majority of engineers would go through their careers without ever touching protobufs, never miss it, never need it, and never find themselves where eking out that extra performance is truly worth the hassle.

IIRC, AvatarMUD (avatar.outland.org) has 20,000+ rooms in it. It's been a long time since I played, but it's absolutely massive!

That's exactly what the pin-pen merger is! As you know, it's not limited to pin/pen, and hearing ability (in my case, profound hearing loss) is not related to the ability to hear the difference. I don't understand the linguistics, but my very bad understanding is that there's actual brain chemistry here that means that you _can't_ hear the difference because you never learned it, never spoke it, and you pronounce them the same.

My partner is from the PNW and she pronounces "egg" as "ayg" (like "ayyyy-g") but when I say "egg" she can't hear the difference between what I'm saying and what she says. And she has perfect hearing. But she CAN hear the difference between "pin" and "pen", and she gets upset when i say them the same way. lol

But yeah, that's one of the things that makes accents accents. It's not just the sounds that come out of our mouths but the way we hear things, too. Kinda crazy. :)

I'm also deaf, and I took 14 years of speech therapy. I grew up in Alabama. The only way you would know I'm from the South is because of the pin-pen merger[1]. Otherwise, you'd think I grew up in the American Midwest, due to how my speech therapy went. Almost nobody picks up on it, unless they are linguists that already knew about the pin-pen merger.

[1]https://www.acelinguist.com/2020/01/the-pin-pen-merger.html

This is WILD. I love it. Congrats on shipping!

Oh, interesting. Well, TIL.

Does that even exist? It's basically what they described but with some additional installation? Once you install it, you can select the LLM on disk and run it? That's what they asked for.

Maybe I'm misunderstanding something.

You should install it, because it's exactly what you just described.

Edit: From a UI perspective, it's exactly what you described. There's a dropdown where you select the LLM, and there's a ChatGPT-style chatbox. You just docker-up and go to town.

Maybe I don't understand the rest of the request, but I can't imagine a software where a webpage exists and it just magically has LLMs available in the browser with no installation?

Probably because it's intentional. There are many theories why, but one might be that by saying "You're absolutely right," they are priming the LLM to agree with you and be more likely to continue with your solution than to try something else that might not be what you want.

Sort of in the same vein as "you don't need to understand gravity to recognize that it's important," you not understanding what the answer is doesn't mean there isn't an answer and that the answer isn't important.

I don't have "the answer" (I have _an_ answer, see below), and I also don't need to know "the answer" in order to understand that the managerial class doesn't exist for shits and giggles. There's value there.

If Bezos thought getting rid of managers at Amazon would make him another half a billion dollars, you bet your ass he'd do it.

My answer? It's exactly what that group of seniorish people would do: make decisions. But the seniorish people can't make decisions all day and ALSO do the things they're senior at. You may not like that answer -- and you don't have to! -- but "making decisions" is something that needs to get done at scale without sacrificing the actual productive work that ICs do.

But again, I think you're asking a great question, and I think there's room to say "Is the current paradigm the best paradigm?" and explore other alternatives.

But the very clear answer from all research in addition to basic intuition is "As far as we know, yes."

Why? Doesn't really matter. We just know that if we didn't have managers, the world as we know it wouldn't exist. (For better or for worse!)

But the larger point is still true: For every "why don't they just do X? It's so obvious!" you can look around and note that [almost] /nobody/ is doing that, and that should be a pretty big signal about the idea.

My original post is about the intuition behind how to approach questions like that. Whenever anyone says "Why don't they just do $OBVIOUS_THING?" the answer is "because nobody is doing it."

Now, with respect to that particular feature, I can provide some personal experience to explain /why/ [almost] nobody has that feature. As a disclaimer, I don't know HEB's website. They were just someone we dealt with, and I don't live in their service area, so it's interesting that they have the feature.

What I can tell you from experience is that it would not be a significant driver of revenue, certainly not enough to be a majorly supported feature by a major company that has other value props out there. By far the biggest revenue driver for a grocery company are the staples that people buy every single week: the same milk, the same bread, the same cereal, the same ground beef, the same mac 'n cheese.

People, as a general population, are not adventurous at home When you want something new and interesting, you go out to a restaurant. When you want something familiar and comfortable and, most importantly, easy, you make it at home. I would hazard that the number of times that the average American family of four would cook a brand new recipe they've never had before is probably less than a dozen times /per year/.

So if you're a company that gets >90% of its revenue from weekly recurring users and staples, and <1% of its revenue from recipe-driven results, and you have limited resources, which of those do you think you should focus on? Obviously, you focus on the former. A 10% increase in staples sales is worth millions and millions of dollars, whereas a 10% increase in recipe sales is worth, maybe, a few hundred thousand dollars. It's not nothing, but it's not really worth it from an ROI perspective. Maybe if it's a set-it-and-forget-it kind of feature, it might work?

But over the long run you'll have to come back and upgrade dependencies and migrate to the newest framework du jour, and blah blah blah, and the next thing you know you have a team of four full-time engineers working on a feature that brings in half their salary.

HEB doing it is, well, it's interesting. I am supremely confident it is not a significant revenue driver. It might be something that increases NPS scores or something to that effect, but it's not going to move the needle on revenue very much. So it's interesting that they have the feature.

So if you take all of that into account -- you'll just have to trust me that I know what I'm talking about, I'm sorry about that -- then you can see that someone saying "What if we just got senior people in a room to see what they think?" is a question that doesn't deserve much attention. Not because it's a dumb idea, but because it's actually an interesting idea that has no merits when you dig down and look at it.

If it worked, as the intuition goes, the industry at-large would be doing it. And the evidence bears that out.

I think you should ask yourself that last question again, and this time really think about it. Why /do/ all companies seem to have managers?

(Tone clarification: I'm not approaching this in a condescending manner, but more of a "let's talk through this problem out loud and see where it gets us." So please don't take this as condescension.)

One way to think about "obvious" solutions to problems, such as a "no manager" solutuon, is this: if it's so obvious, why is no one doing it? For example, I worked for a grocery delivery startup for a while. Every single new hire, without fail, would show up at the end of the first week and say "I have a great idea, why don't we let users shop by recipe?"

On its face, it sounds like a brilliant idea! One intuition-based shortcut to find the answer is: if that's such an obvious thing, why doesn't Amazon or Kroger or Safeway or HEB or any of the major grocery chains let you do that?

And of course, the answer is: that's not how users shop. If it worked, the big players would be doing it. They're not. Are you smarter than Amazon? Probably not. That's not to say a smaller group can't innovate past Amazon, but Amazon has some /really fucking smart people/ working for them, and the odds are fantastically small that you'll out-think them. (You can certainly out-_pivot_ them by doing something faster than they can, but if it turns out to be valuable, in the long run, they'll do it too.)

So when you approach a conversation like this and say, "Maybe just see what a group of seniorish people think?", one way to do a quick sanity check on it is: can you think of successful companies that are run that way?

You probably can't. I certainly can't.

There's a similar problem in the theatre world. It is universally understood that someone doing a 60 second monologue for an audition is _the worst way to evaluate theatrical performance_... except for everything else.

And similarly, it appears, based on scanning the successful companies, that having managers is possibly also the worst way to ensure performance... except for everything else.

So... managers it is. It's unlikely that there's a better way to do this at scale. Many people have tried. Management chains always win.

I'll second this. It's fantastic.

I don't think I'm making the case that you shouldn't test things or care about the results, but rather a matter of degree of risk that should be acceptable. In medicine, if you get it wrong, people /die/. In software, if you get it wrong, /you sell fewer widgets/. That's a pretty major difference. You can't get it wrong in medicine, but you /can/ get it wrong in software without it being catastrophic failure.

I'm basically making the case that "Your startup deserves the same rigor [as medical testing]" is making a pretty bold assertion, and that the reality is that most of us can get away with much less rigor and still get ahead in terms of improving our outcomes.

In other words, it's still A/B testing if your p-value is 0.10 instead of 0.05. There's nothing magical about the 0.05 number. Most startups could probably get away with a 20% chance of being wrong on any particular test and still come out ahead. (Note: this assumes that the thing your testing is good science -- one thing we aren't talking about is how many tests are actually changing many variables at once and maybe that's not great!)

Absolutely. If you're the business owner, selling fewer widgets is Very Bad!

But in my post, I specifically called out a line in OP's article that I disagreed with: (paraphrasing) "Your startup deserves the same rigor as medical testing."

To clarify -- and support your point --, we're shipping software, not irreversible medical procedures. If you get it wrong, you sell fewer widgets /temporarily/ and you revert back to a known better solution. With medicine, there aren't necessarily take-backsies -- but there absolutely are in software. Reverting deploys is something all of us do quite regularly!

Is it A/B testing? Maybe, maybe not. I'm not a data scientist. But I think saying that your startup deserves the same rigor as a medical test is misleading at best and harmful at worst.

I just think companies should be more okay with educated risks, rather than waiting days, weeks, months for statistical significance on a feature that has little chance of actually having a negative impact. As you said elsewhere in the thread, for startups, stasis is death.

(BTW, I've read a lot of your other comments in the thread. I think we're pretty well aligned!)

I think you're being overly pedantic here. I'm not a data scientist, just an engineering manager who is frustrated with data scientists ;)

That said, I do appreciate your corrections, but I don't think anything you said fundamentally changes my philosophical approach to these problems.

Excellent response. Thank you!