Well that's great for you. That's some knowledge that you will possess for the rest of your life.
I want a green lawn and big bushy shrubs in front of my house. Do I need to know the intricate biology of my soil and habitat? No, of course not. I just do the surface-level things that make the lawn and shrubs thrive.
>No, of course not. I just do the surface-level things that make the lawn and shrubs thrive.
And others want the green lawn and big bushy shrubs, but don't want to learn all of the surface level things to make their lawn thrive so they hire a service to do it for them. And there's nothing wrong with that - not everyone enjoys the yard work, but they still want the thriving lawn and shrubs... and they are happy to write a check to OpenAI... err...Lawn Doctor every month to get that result since the time they save by not dealing with their lawn, they can pursue things they do want to do.
Not everyone wants to (or needs to) learn every detail along the way of getting the results they want.
I understand your point, but also imagine applying that across the whole spectrum of computing.
It's very useful that there's an intermediary that knows how that stuff works so I can build things without thinking about it in excruciating detail the whole time, I can dip down lower and learn stuff when it's relevant (like cache access and nested arrays) but I can also not do that in many situations.
There's also the argument that you can do engineering without understanding the underlying science as seen in th pyramids, the beautiful old european churches, etc
More productive? If the result can be trash, of course the AI work wins. In industries where quality and performance BOTH need to be upheld, knowing these details lets you guide the LLMs in a way that they will simply never do by themselves, and lets you meaningfully review performance critical code.
This reduces the cycle time on issues and reduces bugs and performance regressions. If I pitched that last sentence to your boss, chances are he'd take it.
Well that's great for you. That's some knowledge that you will possess for the rest of your life.
I want a green lawn and big bushy shrubs in front of my house. Do I need to know the intricate biology of my soil and habitat? No, of course not. I just do the surface-level things that make the lawn and shrubs thrive.
>No, of course not. I just do the surface-level things that make the lawn and shrubs thrive.
And others want the green lawn and big bushy shrubs, but don't want to learn all of the surface level things to make their lawn thrive so they hire a service to do it for them. And there's nothing wrong with that - not everyone enjoys the yard work, but they still want the thriving lawn and shrubs... and they are happy to write a check to OpenAI... err...Lawn Doctor every month to get that result since the time they save by not dealing with their lawn, they can pursue things they do want to do.
Not everyone wants to (or needs to) learn every detail along the way of getting the results they want.
I understand your point, but also imagine applying that across the whole spectrum of computing.
It's very useful that there's an intermediary that knows how that stuff works so I can build things without thinking about it in excruciating detail the whole time, I can dip down lower and learn stuff when it's relevant (like cache access and nested arrays) but I can also not do that in many situations.
There's also the argument that you can do engineering without understanding the underlying science as seen in th pyramids, the beautiful old european churches, etc
Who is more productive? A python dev who learns about x86 registers in his free time or one that uses AI at work?
The one who uses AI at work will eventually be replaced by someone cheaper who uses AI at work.
The one who learns about x86 registers is much more likely to continue to evolve
More productive? If the result can be trash, of course the AI work wins. In industries where quality and performance BOTH need to be upheld, knowing these details lets you guide the LLMs in a way that they will simply never do by themselves, and lets you meaningfully review performance critical code.
This reduces the cycle time on issues and reduces bugs and performance regressions. If I pitched that last sentence to your boss, chances are he'd take it.