Comment by beardbandit

Yeah but then it goes the same way with LLMs? Just spend a few weeks delving the stack and then you go on coding. Learning a codebase of enterprise-scale compiler-generated assembly sounds like a much bigger nightmare than fixing up ai generated code.

*Many* devs would be completely incapable of learning assembly. Heck, many would be unable to learn C.

Likewise, *many* vibecoders would absolutely fail to adapt, and some would adapt, with this being their first experience. Just think of how many people started coding by using old gamemaker tools or scratch, or playing silly games. It is not the same as an LLM, but the idea that it is a gateway is definitely there. I wouldn't call LLMs "programming", because they're doing more: they're building products, which involves a lot more than programming -- hence why the skills to really thrive with LLMs are not just those of a good developer or engineer.

But weeks? I'd say less than 10% of the devs I've known my entire life would develop properly in assembly (and I'm being quite generous). Memory management, pointers, registers...just to name a few.

I think far too many people fail to realize that, with LLMs, the brain of a good problem solver, especially one with engineering background, gets much better results than someone with different characteristics. Similarly, the mind of a good product developer (and even someone with good UX inclination) does a much better job and building usable products.

This idea that LLMs are doing all of the work is frankly mind-boggling to me. It must stem from vastly different experiences of what LLMs do or whomever is using them around who says these claims. Obviously they do a lot of work, especially in the development prototyping, architecture and even ideation parts. But they only do (almost) "all of the work" in very simple or bad apps.

I've seen loads of terrible vibe-coding jobs: UX is terrible, bugs everywhere, clearly no consideration at any point for architecture (and thus the product is barely holding on). And I've seen the opposite: products that feel and act like premium stuff, because they were built by people with true love for what they do, sometimes even with a very good problem solving mind to add to that (leading to a not-so-terrible-albeit-still-barely-holding-on-but-thats-clearly-good-enough-for-the-product architecture). For every good app there are maybe 100 lovable apps that all look the same and break the second you do the wrong sequence of clicks, but the good ones do exist.

It's a tool that enables mediocrity to exist where it didn't previously, but it also empowers so many people in incredible ways. Still, you definitely need to be good at using the tool, and it definitely doesn't just happen overnight.

> All the devs would spend a couple weeks learning assembly and go on coding

A couple weeks?! Really slacking, why not a few hours?

Add the violin and calculus while they're at it.

> Which one is more at risk of having the wipe-out and cost levers: your FOSS language/compiler or your paid third party LLM?

Neither is likely to go away. I do not expect it will ever be difficult to access an LLM in the forseeable future, barring massive legislation + enforcement to entirely ban them (I can run several capable coding models locally)

Nor is it likely that for developers at most companies will not have access to at least some LLM of comparably intelligence to those we have today (more advanced models may be restricted or too expensive) - right now large parts of the world economy are retooling to expand ai inference volume, not decrease it

This seems like "what if you don't have a calculator!" - and like with a calculator, there are benefits to learning things without the tool aid of course, n(including developing a sense for when things are wrong) but professionals are using the right tools for the job

Do you think its likely ?

How feasible is it to have a local, FOSS, encyclopedic LLM for question answering and basic help with common technical tasks? I feel like that would be enough for me.

Nobody says it does. However, if I am solving big business problems and making enough to justify a private cook, why wouldn't I do that to optimize and focus on my area of expertise?

I don't want to be a code monkey. I want to talk to business people and come up with solutions. I don't care if LLM writes most of it or a junior dev...well I do LLM is better.

You can learn to run a restaurant without learning how to cook. That's part of the grief, fewer cooks and more restaurant managers. Some people like being cooks.

The ironic thing is the head chefs of restaurants do almost no cooking. They order around the sous chef, who orders around the kitchen staff, while being focused on the big picture.

In case you've never seen it before, you can watch how a burger's made (in case of LLMs anyway) and eventually replicate it. You can also inspect the recipe after the fact to learn.

No it doesn't

But if I have to intervene at every fricking point along the way from frozen patty to cooked burger, if I have to tell the worker not to drop the patty on the floor and continue cooking it, which dials to turn on which machines, how long to leave the thing cooking at this stage, if I have to have the holistic knowledge (if not the details of the PID loop for the heating element), then it's a lot more than "calling for a burger".

"I" wrote a compiler with help from Claude - it's not the first compiler I've written, probably won't be the last, but it's a damn sight easier to tell the machine to implement LICM or to specify the requirements of the SSA invariants rather than actually do it myself.

Here’s the full and complete source of a GPU-powered Mandelbrot program:

     #use "Stdio.xc"
     #use "Par.xc"
     #import "../src/include/bench_time.xc"

     #define W 2048
     #define SIZE (W * W)

     i32 main(void)
     {
     // Eight runs: the first carries one-off costs (a GPU builds its kernel
     // then), so the figure is the best run; the first is printed too. Auto
     // decides after its fourth (two on each device), and uses the rest.
     u32 total = 0;
     i64 best = 0;
     i64 first = 0;
     for (u32 rep in 0..8)
        {
        total = 0;
        i64 t0 = bench_now_us();
        par mandel :reduce(+ total)
            {
            for (u32 i in 0..SIZE)
                {
                float cx = (float)(i % W) * (3.0f / 2048.0f) - 2.0f;
                float cy = (float)(i / W) * (3.0f / 2048.0f) - 1.5f;
                float x = 0.0f;
                float y = 0.0f;
                u32 k = 0;
                while (k < 256 && x * x + y * y < 4.0f)
                    {
                    float xt = x * x - y * y + cx;
                    y = 2.0f * x * y + cy;
                    x = xt;
                    k = k + 1;
                    }
                total = total + k;
                }
            }
        i64 t1 = bench_now_us();
        if (rep == 0)
            first = t1 - t0;
        if (rep == 0 || t1 - t0 < best)
            best = t1 - t0;
        }
     printf("%u %lld %lld\n", (total + 500000) / 1000000, best, first);
     return 0;
     }

Just one line in that source code is what turns it from a bog-standard C-like program into a GPU kernel, automatically tracked, scheduled, and all data hazards transparently managed.

On my M4 max, that one line of code takes it from 481ms to 1.6ms. All ‘par’ does is say “this next block of code, call it “mandel”, is data-parallel, and for the ‘total’ variable all execution units should combine their output to that variable using +

No huge GPU boilerplate, no stream management for data transport from cpu to gpu and back, no memory barriers, no hassle. Just “hey, do this on the gpu”.

GPU blocks are bound at runtime using the best design for the hardware on the machine, obtained by measuring it (if it hasn’t been measured before). If it has, the cache is read. The user can always override, which is why ‘par’ blocks can be named.

One of the nice things about that is that if you find the bit you want to accelerate is too small to be useful, say the data-transport outweighs the computational speedup, (a) the runtime computer will figure that out and (b) you can hoist more code into the GPU if that's an option, to give it more work to do. The language is the same for both CPU and GPU so it's transparent...

The other thing is that the compiler will produce MSL, PTX for nvidia, SPIR-V and WGSL versions of the 'par' block, and since it's bound at runtime, you get support for pretty much everything.

What I'm looking at right now is multi-GPU systems. Consider a GPU to be a 'worker thread', and for each thread overlay the time spent uploading work units, the time spent computing, and the time spent downloading work results to the host. Now on Windows you only get 1 asynchronous copy engine for "consumer" GPUs like RTX {3|4|5}0x0 so there are limits, but MSL lets you have more I think and I haven't looked at AMD GPUs yet.

The thing that most people latch onto is the speed upgrade (419ms -> 1.6ms) but the real story here is the simplicity - using any dedicated language (CUDA, MSL, ...) you write a load of boilerplate and you have to worry about data hazards etc. I think of this as similar to when Apple introduced ARC (Automatic Reference Counting) - prior to that, engineers were constantly having to manage their memory manually, and there cough were a lot of errors. ARC changed the game, and I think xc is "ARC for GPUs".