I think this is a pretty solid analogy but I look at the metaphor this way - people used to get strong naturally because they had to do physical labor. Because we invented things like the forklift we had to invent things like weightlifting to get strong instead. You can still get strong, you just need to be more deliberate about it. It doesn't mean shouldn't also use a forklift, which is its own distinct skill you also need to learn.

It's not a perfect analogy though because in this case it's more like automated driving - you should still learn to drive because the autodriver isn't perfect and you need to be ready to take the wheel, but that means deliberate, separate practice at learning to drive.

I like this analogy along with the idea that "it's not an autonomous robot, it's a mech suit."

Here's the thing -- I don't care about "getting stronger." I want to make things, and now I can make bigger things WAY faster because I have a mech suit.

edit: and to stretch the analogy, I don't believe much is lost "intellectually" by my use of a mech suit, as long as I observe carefully. Me doing things by hand is probably overrated.

I do appreciate the visual of driving a forklift into the gym.

The activity would train something, but it sure wouldn't be your ability to lift.

Misusing a forklift might injure the driver and a few others; but it is unlikely to bring down an entire electric grid, expose millions to fraud and theft, put innocent people in prison, or jeopardize the institutions of government.

There is more than one kind of leverage at play here.

Wondering why the obvious solution isn’t applied here - instead of giving already well known problems that have been solved thousand times give students open research opportunities- stuff which is on the edge of being possible, no way to cheat with Ai. And if Ai is able to solve those - give harder tasks

I feel like the aviation pilot angst captured by "automation dependency" and the fears around skills loss is another great analogy. [0]

[0] https://eazypilot.com/blog/automation-dependency-blessing-or...

How seriously do you mean the analogy?

I think forklifts probably carry more weight over longer distances than people do (though I could be wrong, 8 billion humans carrying small weights might add up).

Certainly forklifts have more weight * distance when you restrict to objects that are over 100 pounds, and that seems like a good decision.

Thanks for the analogy. But I think students may think to themselves:"Why do I need to be stronger if I can use a forklift?"

The real challenge will be that people almost always pick the easier path.

We have a decent sized piece of land and raise some animals. People think we're crazy for not having a tractor, but at the end of the day I would rather do it the hard way and stay in shape while also keeping a bit of a cap on how much I can change or tear up around here.

I've been showing my students this video of a robot lifting weights to illustrate why they shouldn't use AI to do their homework. It's obvious to them the robot lifting weights won't make them stronger.

https://www.youtube.com/watch?v=Be7WBGMo3Iw

I like the weightlifting parable!

Unlike weightlifting, the main goal of our jobs is not to lift heavy things, but develop a product that adds value to its users.

Unfortunately, many sdevs don't understand it.

Sounds a little bit like the stories from Feynman, e.g.: https://enlightenedidiot.net/random/feynman-on-brazilian-edu...

The students had memorized everything, but understood nothing. Add in access to generative AI, and you have the situation that you had with your interview.

It's a good reminder that what we really do, as programmers or software engineers or what you wanna call it, is understanding how computers and computations work.

This the kind of interaction that makes be think that there are only 2 possible futures:

Star Trek or Idiocracy.

Lots of theory but no practice.

This is exactly the end state of hiring via Leetcode.

> Teaching how code works is more important than teaching how to code.

People learn by doing. There's a reason that "do the textbook problems" is somewhat of a meme in the math and science fields - because that's the way that you learn those things.

I've met someone who said that when he get a textbook, he starts by only doing the problems, and skipping the chapter content entirely. Only when he has significant trouble with the problems (i.e. he's stuck on a single one for several hours) does he read the chapter text.

He's one of the smartest people I know.

This is because you learn by doing the problems. In the software field, that means coding.

Telling yourself that you could code up a solution is very different than actually being able to write the code.

And writing the code is how you build fluency and understanding as to how computers actually work.

> I never did any meaningful amount of assembler programming. It was mostly no longer a relevant skill by the time I studied computer science (94-99). I built an interpreter for an imaginary CPU at some point using a functional programming language in my second year.

Same thing for assembly. Note that you built an interpreter for an imaginary CPU - not a real one, as that would have been a much harder challenge given that you didn't do any meaningful amount of assembly program and didn't understand low-level computer hardware very well.

Obviously, this isn't to say that information about how a system works can't be learned without practice - just that that's substantially harder and takes much more time (probably 3-10x), and I can guarantee you that those doing vibecoding are not putting in that extra time.

> The point of this analogy: compilers are important tools. It's more important to understand how they work than it is to be able to build one in assembler. You'll probably never do that. Most people never work on compilers. Nor do they build their own operating systems, databases, etc. But it helps to understand how they work. The point of teaching how compilers work is understanding how programming languages are created and what their limitations are.

I don't know that it's all these things at once, but most people I know that are good have done a bunch of spikes / side projects that go a level lower than they have to. Intense curiosity is good, and to the point your making, most people don't really learn this stuff just by reading or doing flash cards. If you want to really learn how a compiler works, you probably do have to write a compiler. Not a full-on production ready compiler, but hands on keyboard typing and interacting with and troubleshooting code.

Or maybe to put another way, it's probably the "easiest" way, even though it's the "hardest" way. Or maybe it's the only way. Everything I know how to do well, I know how to do well from practice and repitition.

I only learn when I do things, not when I hear how they work. I think the teacher has the right idea.

When I did a CS major, there was a semester of C, a semester of assembly, a semester of building a verilog CPU, etc. I’d be shocked if an optimal CS education involved vibecoding these courses to any significant

> A good analogy here is programming in assembler. Manually crafting programs at the machine code level was very common when I got my first computer in the 1980s. Especially for games. By the late 90s that had mostly disappeared.

Indeed, a lot of us looked with suspicion and disdain at people that used those primitive compilers that generated awful, slow code. I once spent ages hand-optimizing a component that had been written in C, and took great pleasure in the fact I could delete about every other line of disassembly...

When I wrote my first compiler a couple of years later, it was in assembler at first, and supported inline assembler so I could gradually convert to bootstrap it that way.

Because I couldn't imagine writing it in C, given the awful code the C compilers I had available generated (and how slow they were)...

These days most programmers don't know assembler, and increasingly don't know languaes as low level as C either.

And the world didn't fall apart.

People will complain that it is necessary for them to know the languages that will slowly be eaten away by LLMs, just like my generation argued it was absolutely necessary to know assembler if you wanted to be able to develop anything of substance.

I agree with you people should understand how things work, though, even if they don't know it well enough to build it from scratch.

While I may not write assembler, there is still significant value in being able to read assembler e.g. godbolt.

What abstraction levels do you expect will remain only in the Human domain?

The progression from basic arithmetic, to complex ratios and basic algebra, graphing, geometry, trig, calculus, linear algebra, differential equations… all along the way, there are calculators that can help students (wolfram alpha basically). When they get to theory, proofs, etc… historically, thats where the calculator ended, but now there’s LLMs… it feels like the levels of abstractions without a “calculator” are running out.

The compiler was the “calculator” abstraction of programming, and it seems like the high-level languages now have LLMs to convert NLP to code as a sort of compiler. Especially with the explicitly stated goal of LLM companies to create the “software singularity”, I’d be interested to hear the rationale for abstractions in CS which will remain off limits to LLMs.

If I find myself writing code in a way that has me saying to myself "there has to be a better way," there usually is. That's when I could present AI with that little bit of what I want to write. What I've found to be important is to describe what I want in natural language. That's when AI might introduce me to a better way of doing things. At that point, I stop and learn all that I can about what the AI showed me. I look it up in books and trusted online tutorials to make sure it is the proper way to do it.

Also, in college, I'd follow the derivation that the prof did on the chalkboard, and think I understood it. Then, doing the homework, I'd realize I didn't understand it at all. Doing the homework myself was where the real learning occurred.

This concept can be taken to ridiculous extremes, where learning the actual useful skill takes too long for most participants to get to. For example, the shop class teacher taking his students out into the wilderness to prospect for ore, then building their own smelter, then making their own alloy, then forging billet, etc.

In middle school (I think) we spent a few days in math class hand-calculating trigonometry values (cosine, sin, etc.). Only after we did that did our teacher tell us that the mandated calculators that we all have used for the last few months have a magic button that will "solve" for the values for you. It definitely made me appreciate the calculator more!

The natural solution is right there in front of us but we hate to admit it because it still involves LLMs and changes on the teaching side. Just raise the bar until they struggle.

> "Why think when AI do trick?"

> grug once again catch grug slowly reaching for club, but grug stay calm

That makes sense. Some skills just have more utility than others. There are skills that are universally relevant (e.g. general problem solving), and then there are skills that are only relevant in a specific time period or a specific context.

With how rapidly the world has been changing lately, it has become difficult to estimate which of those more specific skills will remain relevant for how long.

I am rather positive that if you were sat down in a room and couldn't leave unless you did some mildly complicated long division, you would succeed. Just because it isn't a natural thing anymore and you have not done the drills in decades doesn't mean the knowledge is completely lost.

I'd prefer it to tell me it can't help me rather than write random code that I then have to spend time debugging.

The counterargument here is that there is a distinction between an arbitrary line in the sand (C++ stdlb is bad) and using a text-generating machine to perform work for you, beginning to end. You are correct that as a responsibly used tool, LLMs offer exceptional utility and value. Though keep in sight the laziness of humans who focus on the immediate end result over the long-term consequences.

It's the difference between the employee who copy-pastes all of their email bodies from ChatGPT versus the one who writes a full draft themselves and then asks an LLM for constructive feedback. One develops skills while the other atrophies.

When in school the point is often to learn how to write complex code by writing things the standard library does.

Though also in the 90's the standard library was new and often had bugs

I would interpret his take a little bit differently.

You write sorting algorithms in college to understand how they work. Understand why they are faster because it teaches you a mental model for data traversal strategies. In the real world, you will use pre-written versions of those algorithms in any language but you understand them enough to know what to select in a given situation based on the type of data. This especially comes into play when creating indexes for databases.

What I take the OPs statement to mean are around "meta" items revolved more around learning abstractions. You write certain patterns by hand enough times, you will see the overlap and opportunity to refactor or create an abstraction that can be used more effectively in your codebase.

If you vibe code all of that stuff, you don't feel the repetition as much. You don't work through the abstractions and object relationships yourself to see the opportunity to understand why and how it could be improved.

You didn't write sorting code or assembly code because you were going to need to write it on the job. It gave you a grounding for how datastructures and computers work on a fundamental level. That intuition is what makes picking up minecraft hack mods much easier.

> I don't particularily care if people can write code like they work at the assembly line. I care [...] That they can deliver business value quickly.

In my experience, people who talk about business value expect people to code like they work at the assembly line. Churn out features, no disturbances, no worrying about code quality, abstractions, bla bla.

To me, your comment reads contradictory. You want initiative, and you also don't want initiative. I presume you want it when it's good and don't want it when it's bad, and if possible the people should be clairvoyant and see the future so they can tell which is which.

> That being said. I have no idea how you'd actually go about teaching students CS these days, considering a lot of them will probably use ChatGPT or Claude regardless of what you do.

My son is in a CS school in France. They have finals with pen and paper, with no computer whatsoever during the exam; if they can't do that they fail. And these aren't multiple choice questions, but actual code that they have to write.

Let them use AI and then fall on their faces during exam time - simple as that. If you can't recall the theory, paradigm, methodology, whatever by memory then you have not "mastered" the content and thus, should fail the class.

> That they will know when to do abstractions

The only way to learn when abstractions are needed is to write code, hit a dead end, then try and abstract it. Over and over. With time, you will be able to start seeing these before you write code.

AI does not do abstractions well. From my experience, it completely fails to abstract anything unless you tell it to. Even when similar abstractions are already present. If you never learn when an abstraction is needed, how can you guide an AI to do the same well?

> I'm an external examiner for CS students

> Hell, I'd even like developers who will know when the code quality doesn't matter because shitty code will cost $2 a year but every hour they spend on it is $100-200.

> Except most of the actual computer science parts are gone, replaced with even more OOP, design pattern bullshit.

Maybe you should consider a different career, you sound pretty burnt out. There are terrible takes, especially for someone who is supposed to be fostering the next generation of developers.

Ah, see, you're outside of the US.

In the US education has been bastardized into "job training"

Good workers don't really need to think in this paradigm.

What is an "external examiner?"

I'm taking CS in college right now, and when we do our projects we're required to have a editor plugin that records every change made. That way when they grade it, they see how the code evolved over time, and not just the final product. Copying and posting has very distinct editor patterns, where organically developed code tends to morph over time.

In-person analog checkpoints seem to be the most effective method. Think internet-disabled PCs managed by the school, written exams, oral exams, and so forth.

Making students fix LLM-generated code until they're at their wits' end is a fun idea. Though it likely carries too high of an opportunity cost education-wise.

If I was a prof, I would make it clear to the students that they won't learn to program if they use AI to do it for them. For the students who wanted to learn, great! For those who just wanted to slide through with AI, I wouldn't care about them.