I'm sure they were blindly accepting the Assembly coming out of the compiler.

VorpalWay an hour ago | parent | next [-]

I don't really see this as analogous. Yes, you do choose an abstraction level to operate at, I rarely think in terms of transistors, or even gates (which by your logic an assembly programmer should do).

But I often do think across adjacent abstraction levels, because abstractions are (varying levels of) leaky. Modern compilers are after many decades good enough and modern computers fast enough that it is rare that I need to dig into the assembly (but I happens, compiler explorer is in my bookmark bar in Firefox).

Other abstractions are far leakier, it is far more common that I look in wireshark to debug network issues, the application level view is often not enough.

One of the leakiest abstractions currently is LLMs. Maybe in a decade or three they will be good enough, but they aren't yet, that's for sure. At least for the hard realtime systems level programming I do. For code generation they often make enough mistakes that the time spent after review and fixes comes out in the wash, even for simple tools. Their use for bug finding, RAG and similar is however promising.

▲

hparadiz an hour ago | parent [-]

My lived experience over the past few months is proving you wrong. I started with your position and have since been able to see how good the tools are when properly used. I've also noticed a huge gap in ability among engineers and I think the gap is widening. My theory is that some folks have the premium tools and some don't and the ones that don't are sort of in this weird limbo where they are sort of stubbornly annoyed at the idea of having to pay for these things so they lash out. Understandable but ultimately self defeating. You can in-fact force the LLM to use any pattern you want. I encountered this recently with a hand made framework I wanted to upgrade. It did stuff I didn't like. But well guess what? I provided it new constraints and it started to do what I want. Be as opinionated as you want. That's the whole point. It's basically your intern.

▲

QuantumNomad_ an hour ago | parent | next [-]

> My theory is that some folks have the premium tools and some don't and the ones that don't are sort of in this weird limbo where they are sort of stubbornly annoyed at the idea of having to pay for these things so they lash out.

At my last job the employer paid for OpenAI access for all of us.

Baby sitting an LLM is not my idea of meaningful use of time. And reviewing code that someone else had an LLM spew out even less so.

I am not lashing out because I don’t have access to LLMs. I had access and I did try it plenty.

▲

hparadiz an hour ago | parent [-]

So tldr you don't have it now and have no frame of reference.

	▲	Capricorn2481 22 minutes ago \| parent [-]
		This is really low effort man. You can do better than "You're not paying enough to be as good as me" followed by "oh...well you haven't paid this month."

▲

yoyohello13 an hour ago | parent | prev [-]

Ah yes the “you’re not paying the ai labs enough” argument.

	▲	hparadiz an hour ago \| parent [-]
		My total usage for this month is less than one days pay.

▲

AlotOfReading an hour ago | parent | prev | next [-]

Compilers are orders of magnitude more reliable than LLMs. There's a reason the saying is "it's not a compiler error".

I have a standing challenge to my co-workers that valid compiler errors will be rewarded like a birthday party, with the baked goods, alcohol, or sweets of their choice. It's only been redeemed once, and I've found less than a dozen unreported compiler bugs myself.

▲

witx an hour ago | parent | prev | next [-]

If you think that's a good analogy you're in the wronf industry ....

▲

ZyanWu an hour ago | parent | prev | next [-]

> out of the compiler

You mean a source that's been tested on billions of PCs over 45+ years?

As opposed to a LLM which outputs code that barely works on my machine™?

▲

skydhash an hour ago | parent | prev [-]

Where do you think those bugs reports for gcc and others come from? Some people do look at the assembly coming out of the compilers.

Currently the openbsd mailing list for port is currently going through a clang update and one of the main point is looking at all the packages that failed to build. I even took a long look at the usb stack and the audio subsystem of OpenBSD because of an issue I was having with my DAC.

▲

hparadiz an hour ago | parent [-]

I literally do packaging for a living and you are misunderstanding my point. Most people just take a binary and run it. There's no analysis of the assembly code. You might profile it and bench it after the fact but no one is sitting there looking at the assembly line by line unless there's a very very good reason and frankly LLMs are better at that type of investigative work. I know because I've been investigating some curious 1 in 100,000 segfaults recently and guess what? It took an LLM to build a tool to let us even hit that bug because it was basically impossible to do by hand and no one in the before times would have sat down to write the tool cause we would not have time so we would have just accepted that 1 in 100,000 requests are segfaulting. At least now I can actually fix the problem.

▲

skydhash an hour ago | parent [-]

What's the reliability of compilers this day? How likely for a bug to be in your code and not in the compiler? I think it's close to 99.99...

So when you have a bug and a core dump, you can quickly load it in debugger, see the stack frame and then theorize a model for the bug to happen. If after verifying the source and having complete confidence that it's good, then you start looking at the assembly, most likely while single stepping with the debugger. But you rarely get to that point, because 99.99... it's your code.

That reliability is what AI tooling is lacking. It's exhausting monitoring the output because errors can be as simple as a minus character or the wrong comparison operator.

	▲	hparadiz an hour ago \| parent [-]
		I'm usually compiling other people's code. Hitting that 1 in 100,000 issue in run time and then having to come up with patch. And then have to make sure it's okay in arm and amd64. The bug I'm thinking of is decidedly a human output and the LLM is cleaning up the slop.