Same here. There is an introspective comment below by khazhoux asking the question from the opposite experience. Why do developers end up on different sides of this coin?

LLM capability is obviously important variable. But those with bad experiences report using top tier models, so that isn't it. Likewise, level of experience can be ruled out. Each side of the coin have experienced developers reporting.

A lot of the other variables are not reported but I can go from my own experience.

Greenfield vs brownfield? The first is indeed usually easier but I get great results updating large code bases with decades of development. And I suspect developing greenfield with LLM is easier as the code is better written from the start.

Rarity of the subject matter? In principle, yet another XYZ app or web page is well represented in the training data so the LLM should have an easy go at making similar. In the past with low-end LLMs, this was noticeable. Working in relatively obscure programming languages produced just garbage. But, that was prior to the inflection point. And today I get good results working on relatively arcane scientific/mathematical algorithm as I do when I ask the LLM to barf out some web app.

Different levels of testing and validation and expectation? Even best LLMs make mistakes. The better LLMs make fewer and expose fewer still to the human as they create internal tests. Maybe people have different expectations and those with bad experience expect perfection from a single prompt? Perhaps, but any experienced developer knows bugs are a part of software development.

What else?

Whatever the answer, it's not a simple one and it may be a confluence of many smaller things. Maybe different developers have a multi-variant function in their brain that pops out a different quality-of-software score and also a different threshold that divides good from bad and all we see in their reports is that binary conclusion.

But, seriously, that got me curious. There are many protocols from that early era that are still with us today. NTP, DNS, SMTP, IMAP, BGP, SNMP, NFS, ICMP. If you allow the 1990's as counting as "old" we can add SSH and SSL, DHCP, LDAP.

If I say, "start a C++ package skeleton" I'm getting CMake, not waf, make, bjam, or whatever. If I state the build system, then I'm still getting some package layout drawn from the training distribution. If I specify that, I'm still getting snake_case or CamelCase or whatever naming convention, drawn from the training distribution. If I specify that, etc etc.

It is distribution sampling all the way down.

So, yes, literally LLMs ARE reaching for "it".

Not for any neutrino experiment I know of. There are paper committees that govern publication but the actual preprint submission to arXiv is always done by one of the authors.

> I would think arXiv can work something out for these cases.

Yes, I also expect special cases would be defined.

- Keep diagram source (eg Graphviz dot) with the document.

- Write software developer manuals that can reference code robustly as the code changes (eg include code snippets from source based on regex).

- Literate Coding / Reproducible Research pattern. Eg, org file explains and generates/builds/runs code and graphs/figures which then get included back into the document.

Some of the problems

- At some scale, one needs a DAG (eg make) or to make every command idempotent with fast no-op. Otherwise, each little change to a source block takes too long and there is a worry that something didn't update which should.

- At some scale, the document becomes the size of a library/package and it does not compose and/or I want to run the code outside of the document.

- The unenlightened around me do not use Emacs so an org file is a "me" file. In some ways this is a plus as it keeps others fingers out of my pie but it also means no way to share the baking.

That was in the days before LLMs. As ellieh's #3 points out, things are different now (we all know that). I now have an LLM externalize org-babel. The LLM maintains an org or LaTeX document describing bits of work, an external library/CLI which runs to produce content including putting numerical results into LaTeX macros, a Makefile or Snakemake to regenerate content and figures. When things are found to change prior understanding the LLM remakes a section of prose in the LaTeX document. I then write my own notes or another LaTeX document so that the trip through eyeballs to fingers on the keyboard assures I keep some level of understanding.

Likewise, in the software documentation goal, it's far better to give a good LLM access to the source and have it generate documentation targeting some learning goal with follow exploration via Q&A than it is to read some prepared document that assumes my goal. Software documentation is kind of a relic useful only for those people that have not yet taken up LLM tools.

Posted. Having a preprint on arxiv is not publishing.

Many of us solve our UI problems and we land into our own happy minima.

Many of the UX "solutions" are either invented problems or not my problems or worse, grinding some anti-me agenda.

Like many, a lot of my UX improvements have been to simplify the UI. Tiling, with just a few windows per virtual desktop in herbstluftwm: kitty, emacs, browser and some rare transient application (usually PDF or image viewer).

The idea in the screen shot horrifies me. Why would I buy an expensive high pixel monitor just to use only 10% of it to display a single window? Why would I want to waste CPU to animate the migration of a full window to a single button icon (another example given)?

These UI "innovations" are great for movie props but do they actually help in reality? Not that I see. The "stagnation" of UI to me is more a plateau. Anything truly new must be driven by new "I", no input/output channels between user and computer.

The one interesting idea I saw in the article was Lifestreams. I think storage and recall is something that needs improvement and new ideas because for me that is a problem. I produce and consume too much info while recalling it is hard and while also I often do not produce or consume info that I wish I had.

Again, it's the I/O that drives the progress.

And when there are more than one transmitters in real world conditions instead of anechoic chamber?

It's cool and all and if this work is for it's own sake, for the sake of research, no issues. But otherwise, I struggle to think of practical use cases. I grant that my imagination may be deficient.

> the NVIDIA B200 achieves 1.6× to 2.3× higher intelligence per joule than the APPLE M4 MAX across QWEN 3 and GPT-OSS model variants

The B200 = "cloud", M4 = "local".

So "cloud" does even better in energy than it does in power compared to "local". Or, to flip it, "local" is both slower and more expensive than "cloud".

You misread it. From the abstract:

> local accelerators achieve at least 1.4× lower IPW than cloud accelerators running identical models

That's "intelligence per watt". They also have IPJ, per Joule.

So, they find local is 40% "dumber" than cloud for the same power or 40% more power for the same "intelligence".

Tables 13 and 14 summarize their IPW and IPJ metrics.

But, to your actual point, I think the "local is 40% dumber per watt than cloud" message is still an understatement. And maybe this is something I failed to find in the paper but they seem to ignore the "idle baseline" costs and talks about explicitly focusing on the power consumption of just the accelerator under load.

There is a large baseline power consumption just to support the accelerator. CPUs, memory, PS losses, network, fans, general environment cooling. This "cost floor" is different for data centers and a "random local computer" and I think must be in favor of data centers which are designed and built with efficiency in mind.

Idleness should also be considered. My local GPUs at $WORK and home are idle more than they are used. Idle time energy in real world scenarios should be somehow attributed to those brief, punctuated times when LLM functions are actually active on the accelerator. Actual, local LLM usage of a GPU is brief (assuming one user per PC). Even with my heavy usage developing s/w I'd guess I heat up a GPU about one hour per day total, sometimes much less. If that is local then one must pay 23 hours of idleness for that 1 hour of "intelligence". Of course a local PC is used for other things and the idleness penalty must somehow account for that. OTOH, data centers try to maximize utilization so their idle time penalty would be much less, perhaps close to zero, by construction.

- "no idea what you’re talking" = "you have outsourced expertise to an LLM"

- "solution that doesn’t actually work" = "piecemeal blocking leaves many problems still active"

- "used to be free" = "you / others in general now pay LLM services for the outsourcing leading to poor solutions while in the past poor solutions came for free"

Your observation on the readership bias of HN is a good one for people to add to their HUMANS.md before reading and commenting. :)