The problem is that if you take away the LLM, all of a sudden you can't do any of the things you "learned". It's confusing familiarity with understanding.
I did actually use an LLM to teach myself photoshop recently for a fantasy map building project. Mostly I'd just ask it things like "I have a mask with 50/50 gray and would like an elevation height map to be an embossed layer on it. Where do I find that in the menus?" those sorts of questions.
I finished the project out feeling pretty confident in my photoshop abilities. Then I did a similar project later and realized I had to open up the LLM again as there were still a ton of holes in my knowledge. After this second time though I'm feeling confident enough on my own that referring back to the LLM is increasingly less common, as it's just a waste of time if I already know what to do.
but this is not how people use - or providers sell - LLMs. They don't ask questions about how to do small steps, they just ask it to do the entire project, finish quickly and learn nothing. If the workflow was many, tight iterations it would be closer to a tool than an automation.
"some" do not a system make. "Some" people succeed in the current educational system, but others would argue people succeed "despite" the system, not "because" of it.
It seems we're about to get a massive stress test of such a theory.
Based on my experiences seeing what people actually do with AI tools: very. If this was a situation where I was seeing higher quality apps, PR's, and community building I would have few qualms about AI.
Instead it's created swamps in the art community, choas and bloat in the FOSS communities, a stronger sense of mistrust with traditional search, a deepening of the Dead Internet Theory, more broken tools to scrounge through... where is this supposed "benefit" I'm getting out of this?
Bear in mind it takes very few individuals to create a LOT of this sort of low-quality AI content. That makes it hard to judge how many are using Agentic methods vs "only Advice" vs "no AI."
LLM is an issue (to most of us) when it replaces exploration, thinking and effort to aquire skill. Whether it's vibe-coding an app, or thinking through a math problem. Jury is out this will atually dimish the next generation of thinkers. But seems like a valid concern to me.
2. This particular case of LLM usage (to teach us photoshop) is replacing traditional tutorials. It can help people learn things. This is also valid to me.
The existence of 2, doesn't eliminate 1. Existence of 1 doesn't eliminate 2. There's no strawmans here. I also think it's fair that the promise of LLMs (and AIs), isn't to replace tutorials, but to displace and automate much more.
Look at the marketing. "Complete projects", "Build apps". "Get advice". How often are we seeing "build a functioning workflow and validation pipeline and collaborate in incremental stages" or anything boring to that effect?
As someone who spent a lot of time supporting users and understanding their challenges with these tools, there's a lot of can you do X vs how can I do X, at least a 10x if not 100x difference.
IE: Model do this for me vs teach me.
Enough that I know people who have built businesses purely training people.
There was a brief moment where programs had decent built-in help you could search to easily find where stuff was in menus. Didn't need a billion parameters or a giant faraway data center...
Or, better, the global menu search. Intellij's shift+shift shortcut is great.
This knowledge has always been present in the product’s documentation. What you needed for learning is a chatbot, not general-purpose probabilistic automation which acts as a conversation simulator.
The learning is at that level of abstraction, so yes taking away the abstraction prevents will stymy you.
Just like if you pressed a button to wipe out our main language stack at our job, yeah none of us would know how to do anything with assembly or machine code.
> Just like if you pressed a button to wipe out our main language stack at our job, yeah none of us would know how to do anything with assembly or machine code.
All the devs would spend a couple weeks learning assembly and go on coding. And all the non-dev vibe coders would be unable to continue.
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.
Isn't OS still required for a CS degree? Didn’t we all write our own kernel and virtual memory system in MIPs assembly code? We’ve been here before, I’m sure a lot of future AI coders will be forced to learn the abstraction stack like we did in a formal CS program.
As the field of "computing" develops more and more high level abstractions, that necessarily reduces the amount of time that can be spend on lower-level stuff. These days I think it's typical to have one or two courses that cover OS/embedded/assembly/compiler type of topics, but that's the bare minimum for awareness, not near enough for actual learning. On the spectrum from low-level to high-level, CS sits just below SE. Computer engineering is the field/degree that gives people actual skills in OS-level programming.
I've seen "software engineering" degrees where they teach some high level coding and how to manage tickets and this sort of stuff.
0 mathematics, 0 algorithms, 0 formal languages.
Universities are pumping out "professionals" like crazy, plus nowadays they are replacing courses with new courses about AI (which might be machine learning in the best case or just prompting in the worst case).
The result is that you need to go and ask what courses where in a degree, and even then it's not really a guarantee of anything (I've met master student with bachelor in computer science who were completely unable to find the smallest number in an array).
The courses might have assembly and stuff on paper (in many places not even that) but in most cases you write very simple toy programs, nothing like real-world stuff, reading compiler output or writing larger asm programs.
And yet: I have not written assembly since school except for one Advent of Code challenge, and I expect it would take me quite a while to pick up a productive level of facility with it.
I learned MIPS assembly and there were brief references to x86 assembly, and I know most of my friends would do fine with assembly, but, alas, most engineers I've known barely even know what memory management is, so being able to create proper abstractions with assembly would definitely be out of their league.
It's vaguely similar to how JS and Node enable so many people to flood the market without really knowing the underlying technology. Many of those would definitely not pick up assembly (which is the entire point I was trying to make)
Hell, I did a Physics degree, and I had to learn assembly (the NS 32k), which wasn't a huge issue alongside the 6502, Z80 and m68k that I already knew.
Now retired (come join the dark side, we have cookies) but still a few years away from what people would call "retirement age"
I need to retire so I can really tear into my massive project backlog. :) I'm really enjoying teaching, but it's unclear if this position will exist 3 years from now.
I think some still do. But writing a few lines of code in some computer architecture course isn't really enough. It's not just the language, it's the libraries and not understanding how things work under the hood.
I remember back in 2014 we had a class in assembly (we used x86 assembly running in DOSbox). One of the projects I most vividly remember was writing a simple paint program controlled using the arrow keys.
I imagine that was x86, which was relatively easy but also horrible. Very few people are writing assembly today because you'd need to be able to do x86-64 SIMD, ARM64, and maybe RISC-V, which are all quite a bit more complicated.
MIPS, because of the books provided for computer architecture (Hennessy and Paterson) were written by the MIPs designers. No one I knew of learned X-86, the Dragon compiler book however had all its examples in VAX assembly.
Everyone else is saying MIPS, but we learned Motorola 68k Assembly. Which I suspect was mainly because we had a bunch of dev boards for it. It was fun starting off by toggling the lights, using the switches to make a primitive binary calculator, before leveling up to making programs than communicated over the serial port.
We learnt MIPS assembly as part of the processor design class, where we built a DLX processor & emulated it running our code, and then we learnt x86 assembly as part of a class on debugging & reverse engineering (which is also where you'd usually have the good old bomblab assignment). That was in 2014.
To add to what you're saying, that's also ignoring that having the time or ability to build really complex things in assembly is harder, higher level languages making things easier also enables people to do more complex things
Assembly is simple. You can learn it quickly. It’s writing a large program in it that’s hard. How roller coaster tycoon was written in it boggles my mind.
The notion that the average developer would recover from the removal of modern high level language abstractions and frameworks, learn assembly, and go back to their regular coding velocity is patently absurd.
But that’s the whole problem. Almost no one has experience programming in the large with assembly. It’s far more difficult than building the simple toys built even in good university programs. It would be a total shit show and probably upwards of 80% would quit or crash out.
but even the smallest modern programs would be monsters in Assembly, so it's simplicity doesn't help much, and you're juggling a lot more than 3 bean bags.
Which one is more at risk of having the wipe-out and cost levers: your FOSS language/compiler or your paid third party LLM?
Sure, there are similarities, but while we're figuring out a FOSS solution that will run on your machine and we'll have access to more than the weights, the abstraction ladder isn't as equivalent as we think they are.
> 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
>I do not expect it will ever be difficult to access an LLM in the forseeable future
If you scope LLM's to "frontier models", I do expect it to be an ever-growing moat. Maybe not if you work at BigCo who will pump out $X0 million/yr to gain access to it, but definitely for the singular use cases of people navigating to Claude.ai and asking a quick question. That's assuming the companies stay afloat long term to begin with.
If you open it up to open-weight models, then I question how many this will filter out. Will it be a tool valuable enough for people to overcome the large starting hump like Photoshop? Or will some future company come in and streamline the UI/UX to make them as intuitive as possible? Those are the truly interesting questions in my mind.
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.
Ironic that the parent poster should use the phrase "code monkey" since most would likely agree being an "LLM prompt monkey" is an even lower rung on the ladder than that. The business people can surely find a LLM prompt monkey for much less salary than what a code monkey gets so I'm not sure anyone would want to embrace that future. In fact, if the AI gets good enough, the business people won't need the LLM prompters at all; they'll talk to the AI themselves.
Business people already talk to LLMs, and people who know how to code hate it.
I haven't written single line of code since Dec but I've been putting a lot of focus into systems design and making sure I understand how all the pieces of our system work together even if I don't know how the individual parts work.
The amount of times I hear my (fairly technical, mind you!) boss say "why can't we do X, Claude says it's simple" is pretty baffling, and my coworkers and him will have hours long debates about it.
Lol. I think a disconnect that engineers often have with product people is that product people want it to be done now (right or not) and engineers want it to be done right, which obviously takes more time. But I think a good engineer knows how to get it 80% of the way there quickly, and knows which 20% is ok to sacrifice or take on as tech debt.
Alas I'm not one of those engineers, but I'm fortunate enough to work with some.
There is a lot of that, but there is also the fact that you can get lulled into a false sense of "it is working" in general the motto is 90% of the work in 10% of the time and 90% of the time to get the 10% more done, and the devil is always in those 10% that often hinge on decisions made during the 90% phase.
It also depends on the requirements, and what the actual thing you want done. For software, sure you can probably patch it and there are some inconveniences you can live with depending on the clients requirements, for hardware... a little bit tougher... But it still depends on what is being done and what are the constraints, as long as people are reasonable, usually, it works out... Except that people rarely seem to be reasonable...
The issue is that the business problem you're solving is the problem of producing food. Why should you be kept around as the middleman, instead of hiring the chef directly?
No it hasn’t, middle managers are the ones telling everyone below them to use AI as much as possible, even if it makes no sense and screws things up. AI is a middle manager’s dream.
Yes, this is what I meant. There hasn't been much news on it for some reason, but in Microsoft at least they're getting pushed out of their role, either to some more direct role, or out.
I'm sorry to say but the business people don't want to talk to you, they want to replace you, that's what the LLM is for as far as they're concerned. Currently you're just filling the role of beta testing that replacement. The fact that you're so happy to throw away your fellow devs in the hopes of getting in bed with those people just makes this whole situation quite sad.
Maybe just get an MBA or something, I doubt its any safer from LLMs but thats clearly what you want to be doing
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.
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".
I don't think this is true. The LLM provides confidence that it won't be a tremendous waste of time to try something you don't already know how to do. But eventually it gets tedious to consult the LLM all the time so you stop doing so. That initial "couldn't hurt to try" boost is worth a lot.
LLMs have also pushed me to learn a lot, but I don’t find the shape to be terribly different than before. I rarely remember the exact sequence of commands or flags or syntax. What my learning was useful for before and after LLMs is to 1) build an intuition of how something behaves and what it should do and 2) expose me to non-obvious possibilities that I wouldn’t have come to on my own. With those two things in place, the next execution without the LLM is a docs search, same as it always was (for me maybe some people are better at remembering this stuff).
What’s different after LLMs for me is that there are some things that just don’t care about and I’m fine if they are a black box that the agent handles for me. I didn’t have that luxury before.
No, the real test is if you can talk coherently about AI acquired knowledge to someone else. And there’s a lot that I’ve learned that I can now talk to other people about to coherently no agent involved.
I recently spent a day coding by hand. I was able to build a project, about 200-300 lines in python. Took me half day. But I could still do it. LLM would have done this in less than half an hour.
After this I realized why I personally choose LLM to write code: it is simply more convenient.
As a parallel, once you learn how to drive you stop walking, as for the primary mode of transportation.
Where do these weird car analogies come from lately... No, walking is still my primary way of getting around. That analogy isn’t as universal as you seem to think.
I'm walking as my primary mode of transport. Am abke to drive, live in city centre can reach my common destinations by foot. Public transportat for things bit further away. Car at low to mid distances is more hassle than it's worth due to parking.
Are you suddenly a history expert because you listened to every Hardcore History podcast? Better to read 1 book on a subject than listen to hours of podcasts. I gaurentee more is remembered from the book.
Just that there is still a big latency. Its smaller than finding the correct information on the web, but you can do so. Especially with MCP. The question is when this goes over into the physical world.
Watching Youtube videoas about anything that requires skill does the same.
Wouldn't you still be able to learn from the resources you created with LLMs? I've not found it that difficult to figure out how an LLM coded a program or website when requested, or to manually make changes based on its output.
If I use an LLM to create something in a programming language I'm not an expert in, I still have a reference point for later use. And that reference should drastically speed up the process of learning how to use said language myself later.
you can "learn", but it is the same and when you start to learn coding, or do homework, you read the solution and "aaah, I get it", but next time you still won't be able to do it unless you've done without reading the answer before.
reading code is not the same as writing code, the second one is much harder.
I have sat down and figured out how to program an Apple //e this year for fun. It is possible. It was quite instructive on how much has been added to the idea of what a computer is these days.
> if you take away the LLM, all of a sudden you can't do any of the things you "learned"
What? That is absolutely not true. I've been using LLMs for language learning, math/physics, clarify home improvement best practices that I now regularly think about, etc. and that knowledge is not LLM-bound at all. Instead of acquiring from a regular textbook, I acquired it from a model.
You're in a sarcasm thread. Distillation is nothing like stealing. Distillation is what's gonna save us from mistreatment by would-be monopolists who "stole" everything they "own" in the first place.
And it depends on the stock market continuing to go up relative to inflation (real inflation, not measured) and the labour market being strong enough to employ people. Which in turn relies on the USA's exorbitant privilege, which relies on all other western countries generally trusting it.
I think it's like driving without navigation systems. Yes, you have to make an effort to do it, but then it's fine. You don't have to use LLMs every minute of the (work)day.
This is why local LLMs is THE most interesting thing at this moment in time; the distribution of the tech is fundamental to it's long term viability. But now that this is happening in very solid fashion I would wager that LLMs are technically akin to most things a modern humans use during their daily life, utterly beyond their capability to understand, yet totally practically useful - this trend has been going on for hundreds of years at this point.
edit: this is the actively maintained fork https://canvascommons.io/
reply