> Typing it is a complete waste of time unless getting up close and personal with it will result in some kind of useful and actionable improvement in you or your understanding.

I believe this is the general belief about basically every human skill, that if you stop doing the technical fundamentals you get worse at understanding the activity. The question is whether coding is like sailing a square-rigged wooden ship, which became completely useless knowledge after the invention of the steam engine, or if it's like playing an instrument, which while technically unnecessary after the advent of MIDI and other tools, absolutely hurts your ability to arrange, compose and perform if the skill is neglected.

For my money: I think the AI scenario is more like the latter, but "humans are worse at coding" isn't the consequence I see coming. I worry that in ten years we will be awash in software that's impossible to understand. I don't think that's happened in any human industry ever. Someone has always understood how the machines are built, even if they're very remote from the users of the machine.

No serious programmer is regularly bottlenecked by typing speed. Even the ones who type slowly.

If you find yourself writing repetitive code you should consider adding a layer of abstraction. If your language isn't powerful enough you can write a code generator.

> Typing it is a complete waste of time unless getting up close and personal with it will result in some kind of useful and actionable improvement in you or your understanding.

Like, perhaps, understanding that it is free of security and functionality bugs.

This is such a delusional take it's borderline trolling. Code is an expression tool to precisely describe a process that does useful thing. Typing prompts is not too different from writing some very vague code, which is arguably a waste of time by itself.

The typing was never the bottleneck.

> a live, running process that does useful things

That is one of the things code does. It also communicates the developer's thoughts about how that process should work to others. If the latter is neglected, the code becomes very difficult to collaborate on. Very few lines of code that are written are "write once". Mostly they're changed, repeatedly, over time by many people. The live, running process is a very temporary entity by comparison. Yes, it needs to exist and do useful work. No, it is absolutely not the only thing that matters.

> Typing it is a complete waste of time unless getting up close and personal with it will result in some kind of useful and actionable improvement in you or your understanding.

I would argue that this is nearly always the case. I don't think people really understand programs that they've only read at more than a very superficial level. This is why I tend to make (temporary) small changes, printlns, etc. when exploring a new code base: it aids greatly in understanding how a program actually works.

And it's even worse (in my experience) with LLM generated code, as it tends not to result in particularly understandable code. It is a lot like LLM generated prose: it often looks entirely reasonable at a surface level, but has a of weirdness/incorrectness hidden beneath the surface. But that surface level makes it very hard to avoid glossing over the details when reviewing the code. For this reason, I personally find it's much more effort to carefully review code than it is to write it.

Humans make mistakes all the time, but their code tends to naturally be structured for human understanding (to some degree based on skill/experience) because they themselves needed to understand it to write it.

I think LLMs are very useful tools, but after quite a lot of experience using them, I think it's generally better to use them as a sounding board, or to help you get unstuck or remove points of friction. Using them to write all of your code (at least for me) seems like a net negative.

I also think it's extremely easy to overestimate how much time they save. It feels like they're a productivity boost because it takes less intense focus to implement something. But I've experienced several instances where actually writing the code myself would have been both quicker and have resulted in better code.

All that being said, it can also be really hard to not write all of your code with agents once you get used to it. There's also a kind of slot-machine-like effect where you write a prompt, excited for the result, and when it doesn't quite come out right, you think "ah just one more prompt and it'll be good." It's hard to see when you're actually doing it though.

It's also weird to me how much people think typing is what the LLM is replacing. Typing was never the hard part. It's the translation of the high-level idea into an unambiguous process that's hard. That's also the valuable part, that requires thinking through the edge cases and consequences of decisions, and that just gets glossed over when using an LLM unless you rigorously review what the LLM has done.

At the end of the day there's a real tradeoff to be made, and it's worth being conscious of what's being given up.