[simonw]

> but languages often have fundamental concepts that they’re built that and need to be understood in order to be effective with them

I completely agree. That's another reason I don't feel threatened by non-programmers using LLMs: to actually write useful Go code you need to figure out goroutines, for React you need to understand the state model and hooks, for AppleScript you need to understand how apps expose their features, etc etc etc.

All of these are things you need to figure out, and I would argue they are conceptually more complex than for loops etc.

But... don't need to memorize the details. I find understanding concepts like goroutines to be a very different mental activity to memorizing the syntax for a Go for loop.

I can come back to some Go code a year later and remind myself how goroutines work very quickly, because I'm an experienced software engineer with a wealth of related knowledge about concurrency primitives to help me out.

[danw1979]

What are your thoughts on humans learning from LLM output ?

I’ve been encouraging the new developers I work with to ensure they read the docs and learn the language to ensure the LLM doesn’t become a crutch, but rather a bicycle.

But it occurred to me recently that I probably learned most of what I know from examples of code written by others.

I’m certain my less experienced colleagues are doing the same, but from Claude rather than Stack Overflow…

[skydhash]

Not Simon, but here is my take.

Code are practical realizations of concepts that exists outside of code. Let's take concurrency as an example. It's something that is common across many domains where 2 (or more) independent actors suddenly need to share a single resource that can't be used by both at the same time. In many cases, it can be resolved (or not) in an ad-hoc manner. And sometimes there's a basic agreement that takes place.

But for computers, you need the solution to be precise, eliminating all error cases. So we go one to define primitives and how these interacts with each other and the sequence of the actions. These are still not code. Once we are precise enough, we translate it to code.

So if you're learning from code, you are tracing back to the original concept. And we can do so because we are good at grasping patterns.

But generated code are often a factor of several patterns at once, and some are not even relevant. Just that in the training phases, the algorithm detected similarity (and we know things can be similar but are actually very different).

So I'm wary of learning from LLMs, because it's a land of mirages.

[ivm]

I've been programming since 2009 and lately I've been also learning a ton from LLM output. When they review my code or architecture ideas, they sometimes suggest approaches I outright didn't know because my day-to-day "rut" has been different so far.

LLMs are like a map of everything, even it's a medieval map with distorted country sizes and dragons in every sea. Still, it can be used to get a general idea of where to go.

[simonw]

I think an important skill to develop as a software developer (or any other profession) is learning to learn effectively.

In software these days that means learning from many different sources: documentation and tutorials and LLM-generated examples and YouTube talks and conference sessions and pairing with coworkers and more.

Sticking to a single source will greatly reduce the effectiveness of how you learn your craft. New developers need to understand that.

[skydhash]

> But... don't need to memorize the details. I find understanding concepts like goroutines to be a very different mental activity to memorizing the syntax for a Go for loop.

That's one of the argument that seems to never make any sense to me. Were people actually memorizing all these stuff and are now happy that they don't have too? Because that's what books, manuals, references, documentations, wiki,... are here for.

I do agree with you both that you need to understand concepts. But by the time I need to write code, I already have a good understanding of what the solution is like and unless I'm creating the scaffolding of the project, I rarely needs to write more than ten lines at time. If I need to write more, that's when I reach for generators, snippets, code examples from the docs, or switch to a DSL.

Also by the time I need to code, I need factual information, not generated examples which can be wrong.

[simonw]

Yes, I was memorizing the stuff.

The reason I used to stick to just a very small set of languages that I knew inside out is that because I was using them on a daily basis I was extremely productive at writing code in them.

Why write code in Go where I have to stop and look things up every few minutes when I could instead of use Python where I have to look things up about once an hour?

LLMs have fixed that for me.

> Also by the time I need to code, I need factual information, not generated examples which can be wrong.

If those generated examples are wrong I find out about 30 seconds later when I run the code: https://simonwillison.net/2025/Mar/2/hallucinations-in-code/

[skydhash]

> Why write code in Go where I have to stop and look things up every few minutes when I could instead of use Python where I have to look things up about once an hour

My workflow is different. Whenever I can't remember something, I look it up. And for something that I'm not familiar with, that usually means a lot of browser tabs. But I try to retrieve it from my memory first (and it usually exists in my short-term memory). And after some days, it has become part of my long-term memory and I don't need to look it up again. If I don't touch the language and its ecosystem for a while, I forgot some details, but they are refreshed with a quick read.

> If those generated examples are wrong I find out about 30 seconds later when I run the code

I would be grateful if those were the only kind of wrong I encounter. Writing code that does the stuff is usually easy. The difficult part is to ensure that the data fits the definition of correct at every stage of the process. And there's not some corrupting action somewhere. Doing so exhaustively is formal verification and it is costly (mostly in terms of time). So what you do is other kind of testing which only covers the most likely places and dimensions where thing can go wrong.

The stressful part is when you have to change some part to fit a new use case. You then have to carefully revise both the change and the other parts so that their definition of correct is consistent. And sometimes there's some decoupling mechanism which makes the link non-obvious.

That's the definition of wrong that I'm fearful of. Where two part are internally correct, but their integration is not consistent.

[ivm]

Yes, for example that's why https://learnxinyminutes.com/ exists. Like, I don't remember the particulars of JavaScript syntax or the core library after a year of not touching it, so before I had to reconstruct it in my head even for small tasks. Now LLMs solve this issue.

[pyman]

I agree Simon. With the little time I have these days for side projects, LLMs have become my new best friends. I'm more worried about the future of my students than my own. I'm sure I'll grow old gracefully alongside the machines that helped me graduate and build a career.

I run Python workshops on weekends, and honestly, I'm speechless at the things students are already doing. But is it realistic to encourage them to study computer science in a year or two, when it's still a 4-year degree? By the time they start uni, LLMs will be 100 times more powerful than they are today. And in 6 years?

Any advice?