All I can say is I personally didn’t find H2 too complex. Supporting streams was the real source of complexity, at least for us. To be fair, we built on lower-level libraries for things like frame unpacking, so the lowest levels were handled already.

Headers were actually easier in our case: compression was handled by an external library, and the elimination of futzing around with upper/lowercase simplified some code.

Some H2 complexities exist, but nobody uses them anymore, so I skipped them. Server push is effectively unworkable in the wild without heroic efforts and interrogating browser caches. RFC7540’s original priority signaling was deemed too complex and got deprecated; browsers interpreted the values differently, and servers were uneven in implementation.

I mostly agree on H3. What makes it interesting is not in HTTP itself, but the underlying transport changes to use QUIC/UDP. For internal networks, this is a lot of churn for little benefit. (H3 has some slight benefits, especially for mobile users, so I wouldn’t say you must be cloud scale, but it’s definitely pretty low on the priority list.)

score 1 · canonical

As someone who used to maintain a FOSS web server project for a few years, I’ve always lamented the fact that HTTP/2 did not displace HTTP/1.1 more thoroughly.

I’ve heard multiple variants of the argument that “HTTP/2’s improvements don’t warrant the extra complexity for internal networks”, but the counterargument is inefficiencies like this one, caused by HTTP/1’s connection and request/response models. (H1 pipelining is another problem.)

HTTP/2 is just a much more logical and efficient model. (Though it had its serious missteps too, like server push or the original priority mechanisms.)

score 1 · canonical

I would! And in fact, I use supervisor agents just like this.

But I was thinking of a different kind of serial, where instead of multiple tasks in a single long session, you have multiple sessions one after the other, one per task.

score 1 · canonical

I get that this is more of a rant, and I agree with a lot of it, but some of these are Claude-specific or have plausible reasons.

For example, I don’t think harnesses parallelize work automatically because they’re more likely to hit session limits, and they consume more tokens in message-passing, coordination, and conflict resolution than when serial.

Likewise, when it comes to model/task suitability, self-reflection on model suitability is non-existent in general, yes, but there are passable alternatives.

In Claude, I instruct it to use models appropriate for the subtask, and it kinda works, but if you use Oh-my-pi, it allows you to specify models for different roles (slow, smol, review, basic tasks, etc), and will use them consistently.

Oh-my-pi also directly supports advisor agents, where a smarter model watches another subagent, and interjects as needed, which is a hybrid solution.

score 1 · canonical

I’m very excited to see these two personal pain points fixed:

• workspaces can now be colocated with git worktrees
• workspaces have a new remove command that can delete the workspace directory at the same time as forgetting the workspace entry

score 1 · canonical

You can certainly take it that way, but my observation is it’s still an uphill battle to get people to even see the problems are related, so I prefer to focus on that first.

I actually think suggesting devs engage in collective bargaining or form a union is an even bigger leap, too big for first steps.

score 1 · canonical

At what point is this kind of post just capitalist propaganda?

It’s not, it’s example #387946 of “Your specific X/Y/Z grievance is actually a general anti-capitalist grievance”.

Socialists tend to say variants of this a lot because many people never connect the dots between their specific complaint, and the system that caused it. It’s an attempt to get people to focus on the disease, and not the particular symptom du jour.

Many, but not all, anti-AI complaints fall into this category.

score 1 · canonical

Ahh, the “dissonance” is you’re thinking of the Jevons Paradox as being about increased energy use, when it’s more specifically about the increased usage of goods and services, not necessarily energy.

You’re on the right track, but e.g., if LLM use increased 10x, but we’re able to make them 20x more efficient, the energy use will drop, despite Jevons. Alternatively, Jevons could drive 20x more carbon-neutral solar/wind development making the increased energy use of LLMs (and everything else) a moot point. This is what I think (and hope) will happen, even under capitalism.

It’s unclear to me that the Jevons Paradox would be as much of a problem under other economic systems. To use its original observation about coal: yes, ordinary citizens would continue to want coal and electricity, but much of the usage was by capitalist-driven industry. Companies had to use more coal to ensure they weren’t out-competed by those who did.

A more democratic economic system could weigh the trade-offs, and voters could decide how quickly and how much to adopt a new tech.

score 1 · canonical

People love to cite “appeal to authority” whenever an expert disagrees with them, as if it magically negates their expertise. But unless you can prove someone is NOT an expert despite having credentials/title/position/etc, their “authority” is a relevant shorthand for expertise. From a classical logic perspective, this is not true, but classical logic is simplistic. From a Bayesian perspective, authority should usefully update one’s priors.

Regardless, you provided even less justification for your assessment of the author, so it’s not like you have a logically better argument. There’s not even an argument there, just an assertion.

I know we’re being snarky, but I’ll respond to the nuance bit as if it were real. Nuance doesn’t mean we can’t write quality software without LLMs, but if we’re up-to-date on current LLM capabilities, we have to admit they can do a lot of what they say on the tin. In some areas, like debugging and security, they’re already better or faster than most human devs. Any argument that starts off assuming LLMs don’t work in any scenario, is either naive or out-of-date.

A nuanced argument involves looking at them and deciding how to handle the trade-offs instead. How do we enable junior devs to grow? How to we triage large numbers of issues/PRs? How do we compensate for LLMs’ (currently) weak high-level architectural design? How do I balance learning with throughput, so my skills don’t atrophy? Which skills are still relevant? Etc.

score 1 · canonical

The author doesn’t understand or think about what quality software is or what it takes to write some.

The author: “… a member of the GNOME Release Team, the Fedora Workstation Working Group, and the desktop team at Red Hat. Before joining Red Hat, I worked on the WebKit team at Igalia, maintaining Epiphany, WebKitGTK, and glib-networking.”

Seems more likely they understand what quality software is, you just disagree with them.

(I’m happy to see more nuanced LLM takes emerging, at least.)

score 1 · canonical

I also don’t think you can get the same results as $1 million on pentester salaries with $100 in tokens, but whatever.

You will certainly get an equivalent security analysis for orders of magnitude less than $1m in tokens though.

Anyway, your alternative scenarios for humans (pentest or loaf at home) leave out the obvious: move humans away from activity where computers do it better, and have them do something more productive, like high-level architecture and design. It’s the same logic as switching to power drills and cranes, instead of making artisanal woodworking.

Your focus on the costs without mentioning the benefits, assumes LLMs are useless (given you call them “slop machines”). But since they have workable use cases (and in the case of security, they clearly do), then it becomes like any other tech, where we weigh tradeoffs.

I personally think the environmental harms will be short-term, and mitigated over time in a variety of ways. More efficient models, cheap software rewrites into more efficient langs, increased model efficiency from more software, model-driven research into environmental tech, etc.

(Now, whether humanity would actually build the current amount of stuff more efficiently, or just build more is a separate question. But that’s much older than LLMs, and is more your-underlying-problem-is-actually-capitalism again, which cannot be solved by addressing the symptoms instead of the root cause. But that’s a whole 'nother conversation.)

score 1 · canonical