Jemaclus

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.

Sure. But this is a little pedantic, no?

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.

Conversely, imagine only requiring carpenters to know how to use a chainsaw.

Yes, exactly.

I mean, it's the same idea, no? You hire contractors to build your house, but not to put together an IKEA bookshelf.

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

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.