71–80 of 189 posts
The bitter lesson is going to be for junior engineers who see less job offers and don’t see consulting power houses eat their lunch.
I think this particular anxiety was explored rather well in the anonymous short story 'The End of Creative Scarcity': https://www.fictionpress.com/s/3353977/1/The-End-of-Creative... Some existential objections occur; how sure are we that there isn't an infinite regress of ever deeper games to explore? Can we claim that every game has an enjoyment-nullifying hack yet to discover with no exceptions? If pampered pet ani…
The thing is: the industry does not need people who are good at (or enjoy) programming, it needs people who are good at ( and enjoy) generating value for customers through code. So the OP was in a bad place without Claude anyways (in industry at least). This realization is the true bitter one for many engineers.
It's not true that coding would no longer be fun because of AI. Arithmetic did not stop being fun because of calculators. Travel did not stop being fun because of cars and planes. Life did not stop being fun because of lack of old challenges. New challenges would come up. If calculators made the arithmetic easy, math challenges move to next higher level. If AI does all the thinking and creativity, human would move to…
Well this sounds delightful! Glad to be free of the thinking and creativity!
The thing is: the industry does not need people who are good at (or enjoy) programming, it needs people who are good at ( and enjoy) generating value for customers through code. So the OP was in a bad place without Claude anyways (in industry at least). This realization is the true bitter one for many engineers.
Generating value for the shareholders and/or investors, not the customers. I suspect this is the next bitter lesson for developers.
The one part that I believe will still be essential is understanding the code. It's one thing to use Claude as a (self-driving) car, where you delegate the actual driving but still understand the roads being taken. (Both for learning and for validating that the route is in fact correct)
It's another thing to treat it like a teleporter, where you tell it a destination and then are magically beamed to a location that sort of looks like that destination, with no way to understand how you got there or if this is really the right place.
The models all have their specific innate knowledge of the programming ecosystem from the point in time where their last training data was collected. However, unlike humans, they cannot update that knowledge unless a new finetuning is performed - and even then, they can only learn about new libraries that are already in widespread use.
So if everyone now shifts to Vibe Coding, will this now mean that software ecosystems effectively become frozen? New libraries cannot gain popularity because AIs won't use them in code and AIs won't start to use them because they aren't popular.
All articles of this class, whether positive or negative, begin "I was working on a hobby project" or some variation thereof. The purpose of hobbies is to be a hobby, archetypical tech projects are about self-mastery. You cannot improve your mastery with a "tool" that robs you of most of the minor and major creative and technical decisions of the task. Building IKEA furniture will not make you a better carpenter. Why…
I think it also misses the way you can automate non-trivial tasks. For example, I am working on a project where there is tens of thousands of different data sets each with their own meta data and structure but the underlying data is mostly the same. But because the meta data and structure are all different, it’s really impossible to combine all this data into one big data set without a team of engineers going through…
So if you want to translate that, there is value in doing a processing step manually to learn how it works - but when you understood that, automation can actually benefit you, because only then are you even able to do larger, higher-level processing steps "manually", that would take an infeasible amount of time and energy otherwise.
Where I'd agree though is that you should never lose the basic understanding and transparency of the lower-level steps if you can avoid that in any way.
>This is the exact same feeling I’m left with after a few days of using Claude Code.
For me what matters is the end result, not the mere act of writing code. What I enjoy is solving problems and building stuff. Writing code is a part.
I would gladly use a tool to speed up that part.
But from my testing, unless the task is very simple and trivial, using AI isn't always a walk in the park, simple and efficient.
The thing is: the industry does not need people who are good at (or enjoy) programming, it needs people who are good at ( and enjoy) generating value for customers through code. So the OP was in a bad place without Claude anyways (in industry at least). This realization is the true bitter one for many engineers.
The realization that productive workers aren't just replaceable cogs in the machine is also a bitter lesson for businessmen.