rootnod3

I keep reading these pro LLM articles. And I keep thinking that it is abysmal. Sure, for now it works, because there are senior engineers that refine the rough edges and know what's going on.

And especially some folks keep claiming that one just needs to get better at prompting and describe a detailed spec.

Wanna know what a detailed spec is called? An unambiguous one? It's called code.

LLMs still feel like a very round-about way of re-inventing code. But instead of just a new language, it's a language that nondeterministically creates "code" or a resemblance thereof.

And I am aware that this is currently not a popular opinion on HN, so keep the downvotes coming.

If you use LLMs outside the popular Github languages, it will fail hard on you. It is glorified text-completion, that's what it is.

Oh lovely. Will definitely check that out. Reminds me a bit of CIEL

Just by what people seem to use.

Yes. Unfortunately it seems that Matrix is the winner, but I think Matrix is over-engineered.

XMPP was nice. Especially in the old times when Google Hangouts and Facebook Chat were also XMPP based. Being able to talk to people on another service without needing an account there was a nice thing to have for a few months.

And an added "6 months" later to see which delivered result didn't blow up in their face down the road.

That has to be the worst analogy I have read in a while, and I’m HN that says something.

Sounds more like just adding a ton of wasted time for the reviewer to read through those discussions. At least summarize it yourself, e.g. "After discovering manpage XYZ, it became clear that the correct usage of this function is fooBar()".

The only future I see is that prompts will become so refined that you give them all the requirements an they write the code for ya. And that prompt language has to be unambiguous and so detailed that you loop around and re-invented a programming language, just this time it wastes tons of water.

Or why you shouldn't....

I am not contesting that stackoverflow isn't bad in many regards, but to equate that to massive PRs or code changes done via AI slop is a different level. At worst, you might get a page or two out of stack overflow but still need to stitch it together yourself.

With LLMs you can literally ask it to generate entire libraries without activating a single neuron in your nogging. Those two do NOT compare in the slightest.

Another difference: stack overflow tells you you are wrong or tells you and do your own research or to read the manual (which in a high percentage of cases is the right answer). It doesn't tell you that you are right and proceeds to hallucinate some non-existent flags for some command invocation.

Difference: companies are not pushing their employees to use stack overflow. Stack overflow doesn't waste massive amounts of water and energy. Stack overflow does not easily abuse millions of copyrights in a second by scraping without permission.

"I have seen some people be quite successful with this."

Wait until those people hit a snafu and have to debug something in prod after they mindlessly handed their brains and critical thinking to a water-wasting behemoth and atrophied their minds.

EDIT: typo, and yes I see the irony :D

Sorry, but why would including the prompt in the pull request make any difference? Explain what you DID in the pull request. If you can't summarize it yourself, it means you didn't review it yourself, so why should I have to do it for you?

It's not a problem for the senior dev directly, but maybe down the road. And it definitely is a problem for the company once said senior dev leaves or retires.

Seriously, long term thinking went out the window long time ago, didn't it?

Ok, now assume you start relying on it and let's assume cloud flare has another outage. You just go and clock out for the day saying "can't work, agent is down"?

I don't think we'll be out of jobs. Maybe temporarily. But those jobs come back. The energy and money drain that LLMs are, are just not sustainable.

I mean, it's cool that you got the project knocked out in a month or two, but if you'd sit down now without an LLM and try to measure the quality of that codebase, would you be 100% content? Speed is not always a good metric. Sure, 1 -2 months for a project is nice, but isn't especially a personal project more about the fun of doing the project and learning something from it and sharpening your skills?

I don't think the chess analogy grabs here. In chess, you play _against_ the chess computer. Take the same approach and let the chess computer play FOR the player and see how far he gets.

Might be a weird suggestion but here we go: - use whatever diff tool you used before LLMs came around and actually review the code? Just a suggestion. If people claim they always examine the full output at the end before they commit it, then why not fully review it using the tools used before the dawn of LLMs?

Cool cool cool. So if you use LLMs as junior devs, let me ask you how future awesome senior devs like you will come around? From WHAT job experience? From what coding struggle?

Maybe unpopular, but papers should be in n markdown flavor to be determined. Just to have them more machine readable.

It's my goto for new languages, but Gameboy instead of Chip8. It covers good parts of new languages when learning them.

Yes. The AI companies for the token usage.

My first manager at Amazon was like that. Loved him to pieces. He didn't micro-manage, he didn't even fully care about the scrum. Just said "I can see the ticket status myself. If you are blocked by something, need any info or resource, I'll hunt it down for you, otherwise you keep cooking".

Famous last words of empires. I doubt that if current situations continue that the US will in any sense be still thought of as the reserve currency.

Count how many services you have that are not already defined by the system itself in its order? So, remove core system services. System itself should already make sure that USB starts after PCIE and all that.

So go and count all the services that are not base install and tell me how many you have.

Still daily driving an old x220 and a T480. Last time they were actually decent. You can pry them out of my cold dead hands.

I wish they'd make something like the x220 again.

Best practice would be to pack the service into a jail and then use `ractl` to monitor I/O. Could also then monitor the VNET socket of the jail for network stats.

Or you just grab the PID and get it through that. A bit more manual, but composable.

Here's an idea for LLM makers: allow for a very rigid and structured Claude.md file. One that gives detailed instructions, as void of ambiguity as possible. Then go and refine said language, allow maybe for more than one file to give it some file structure. Iterate on that for a few years and if you ever need a name for it, you might wanna give it a name describing something that describes a program, or maybe if you are inclined enough....a programming language.

Have we really reached the low point that we need tutorials on how to coerce a LLM into doing what we want instead of just....writing the god damn code?

The just released FreeBSD 15 for example as a major release is supported until end of 2029, how much more LTS support do you want?

The minor point releases are close to a year in support. And that is only talking base system. Packages and ports you can also easily support yourself with poudriere and others.

As for backwards compatibility: FreeBSD has a stable backwards compatible ABI. That is why you can run a 11.0 jail on a 15.0 host. With zero problems.

Other way around is what doesn't work. You can't run a 15.0 jail on a 11.0 host for example. But backwards compatibility is definitely given.

[1]: https://www.freebsd.org/releases/15.0R/schedule/

Do we now need https://unkilledbygoogle.com?