I agree, and I can actively feel myself slipping (and perhaps more critically, not learning new skills I would otherwise have been forced to learn). It's a big problem, but somewhat orthogonal to "what is the quickest way to solve the task currently in front of me."

> but somewhat orthogonal to "what is the quickest way to solve the task currently in front of me."

That depends on if you ignore the future. You are never just solving the problem in front of you; you should always act in a way that propagates positivity forward in time.

Some jobs require investment in the future. Some do not. That’s just reality. Not white how I feel about it personally, but I think there is a fair amount of the developer trade that is operational.

Which needs to be balanced with "How do I maintain my ability to keep solving tasks quickly?"

The thing i struggle with is I feel like it’s hard to lock into which skill to learn properly. Which so much changing so quickly and it becoming easy to learn things superficially.

By moving up a level in the abstraction layer similar to moving from Assembly to C++ to Python (to LLM). There’s speed in delegation (and checking as beneficial).

Moving up abstraction layers really only succeeds with a solid working knowledge of the lower layers. Otherwise, you're just flying blind, operating on faith. A common source of bugs is precisely a result of developers failing to understand the limits of the abstractions they are using.

We only need to do that when it’s practical for the task at hand. Some tasks are life-and-death, but many have much lower stakes.

So we can all only succeed if we know how CPUs handle individual instructions?

I'm not sure whether I agree with GP, but I think you may be misinterpreting their point. I can have an understanding of CPUs in general without knowing individual instructions, and I do think knowing about things like CPU cache is useful even when writing e.g. Python.

Sure, but the comment being worried about a lack of “flexing your muscles” is perfectly countered by moving up an abstraction layer then, as you don’t have to constantly get into the weeds of coding to maintain an understanding _in general_ without knowing individual instructions.

I see what you’re getting at and it makes sense.

Goes to the larger idea that strategic and logic is important for scalability and long term success. Not just execution. Something LLMs miss often (mostly because people fail to communicate it to them).

Yes, for sure! And being able to orchestrate AI to use that knowledge provides leverage for fulfilling tasks.

Eventually, yes, I think we'll delegate to AI in more and more complete ways, but it's a process that takes some time.

There's generally a pretty quick falloff of how much help knowledge of each layer under you generally provides as you go deeper.

That being said, if you're writing in C, having a pretty good idea of how a cpu generally executes instructions is pretty key to success I'd say.

Agreed, also depends on the scale you are working at.

If you are a tiny startup, the marginal gains from these optimizations matter a lot less than if you are Netflix.

If the LLM is able to handle it why do you need to maintain those specific skills?

Should we not teach kids math because calculators can handle it?

Practically, though, how would someone become good at just the skills LLMs don't do well? Much of this discussion is about how that's difficult to predict, but even if you were a reliable judge of what sort of coding tasks LLMs would fail at, I'm not sure it's possible to only be good at that without being competent at it all.

> Should we not teach kids math because calculators can handle it?

We don't teach kids how to use an abacus or a slide rule. But we teach positional representations and logarithms.

The goal is theoretical concepts so you can learn the required skills if necessary. The same will occur with code.

You don't need to memorize the syntax to write a for loop or for each loop, but you should understand when you might use either and be able to look up how to write one in a given language.

Huh. I was taught how to use both an abacus and a slide rule as a kid, in the 90s.

Should you never use a calculator because you want to keep your math skills high?

There are a growing set of problems which feel like using a calculator for basic math to me.

But also school is a whole other thing which I'm much more worried about with LLMs. Because there's no doubt in my mind I would have abused AI every chance I got if it were around when I was a kid, and I wouldn't have learned a damn thing.

I don't use calculators for most math because punching it in is slower than doing it in my head -- especially for fermi calculations. I will reach for a calculator when it makes sense, but because I don't use a calculator for everything, the number of places where I'm faster than a calculator grows over time. It's not particularly intentional, it just shook out that way.

And I hated mental math exercises as a kid.

I do not trust myself, so even if I know how to do mental math, I still use my computer or a calculator just to be sure I got it correct. OCD? Lack of self-trust? No clue.

> I'm not sure it's possible to only be good at that without being competent at it all.

This is, in fact, why we teach kids math that calculators could handle!