Last time this happened we got a bunch of Google employees downplaying the impact of WEI and calling it a nothingburger, that people were being hysterical. I just checked, and everyone I saw defending it has since left the company. I'm sure another wave of Google managers, keen to appeal to the higher-ups, will be here to defend this new initiative any minute now.

This makes me curious, where did they go?

at least one went to Shopify, I'm not sure about the rest

it's about the comments / votes ratio.

To be more specific, it is a heuristic for detecting flamewars and/or controversial topics and it is quite good at that.

why exactly do we want to damp flamewars by comment count? as long as an individual comment fits the rules why do we punish comments in aggregate

Because it's a global optimization problem and HN gets less optimal* when there are flamewars on the frontpage.

Do you have a different approach in mind that we could do instead?

* https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

right but feel like comment count is a poor proxy for flamewar in an age where cheap intelligence to semantically classify discussions is available, so that, as affected me in the past, an author of a post simply enthusiastically engaging with every reply is not punished.

maybe to put it in a way where your values are aligned, i'm a curious person, and i learn a lot from the discussions that happen right on HN rather that only going to the source.. indiscriminate comment count damping takes away/lowers visibility of the most interesting comments that would provoke my curiosity.

one could instead do any sort of basic classifier system ranging from bag of words to running a ModernBERT to rate flamewarness and differentially apply the downrank based on "flamewar score" rather than "really poor proxy to flamewar score"

If it's genuinely the case that you can write code faster than you can prompt it into existence then you're not being ambitious enough with your coding agent. Ask it to do more. Tackle bigger problems.

1. It's unclear why creating more code faster is a good thing. Software engineering wisdom for decades has been that code is a cost, not a product. There are great reasons for that, which haven't changed with the appearance of LLMs.

2. There absolutely are cases where modifying code "manually" is unquestionably faster than prompting an LLM. There are trivial examples for this - eg only an insane person would ask an LLM to rename a variable rather than using an LSP for that. It would provably and consistently take more keystrokes. There are less trivial examples as well, like, you know, having an understanding of your codebase and using good abstractions/libraries within it that let you make large changes to the program's behavior with little boilerplate code.

One can argue that producing a lot of complex changes through an LLM is faster, which I would agree with, but then see point #1. Sustainable software development has up to this point relied on iterative discovery of the right small components that together form a complete, functional, stable system (see "Programming as Theory Building").

There's zero indication so far that LLMs are capable of speeding up the process of creating complete, functional, stable systems. What every org within my career and friend circle is seeing (and research into productivity impacts of LLMs on software development is showing) is the same story - fast prototypes that either turn into abandonware, personal tools, or maintenance nightmares.

1. More code faster is not the goal. More features / value faster is the goal. Obviously to get there you need to write more code, but it's not writing code for code's sake.

2. Yes, true, but the point is to move up the abstraction hierarchy, so instead of asking the LLM to rename a variable you describe the concrete business goal you're trying to achieve.

It is true that coding agents cannot build fully complete stable systems completely unguided yet. That's why we still have jobs. But it's wrong to suggest that they don't deliver value or that they're destined to produce trash every time. It is a matter of oversight and guidance and setting your codebase up for success. That does require work, but it is not impossible, just a different skillset from the ones we've been used to.

bro is probably using a local LLM at 2 tokens/sec

Ad hominem

Extremely relevant as that’s the only way it would make sense that your experience with agentic coding is still so slow and so poor

it does take a little while to get good at this new skill, yes. Just like, say, learning a new programming language and the ecosystem around it takes some effort. After you get over the hump it's really very straightforward and mostly a matter of knowing the kinds of mistakes the LLM is likely to make ahead of time, and then kindly asking it to do something smarter. If you've successfully mentored junior engineers you already have this skill.

that's well put. But i'd stress mentoring junior engineers is really a high effort, high leverage, high demand skill. A good teacher is gold. and not common.

and then people get bored and stop updating them, soon we'll need a graveyard-graveyard to showcase all the failed graveyard projects.

I used to be an expert at php but now I haven’t written any in over a decade, I can still read it but it would take me a little while to get back to where I was (hopefully I’ll never need to), same thing could easily happen due to ai

Cloudflare workers shows a visualisation of your workflow in their dashboard, but it’s imperfect

unfortunately iterators have their own set of overheads and it's not clear that these new methods are any faster for most use cases.

hello, fellow wanderer! If you see this my email is in my profile.