alt Hacker NewsI kind of think this article misses the mark a little.
There is skill loss from heavy AI use.
But I want to acknowledge the awkward elephant in the room. AI Is making people too fast. I don't mean that a faster output is bad. It's a faster output and code rather than a full understanding and experience in producing the code. It's rewarding people who try to talk about business value rather than the people that are building and making safe decisions with deep knowledge.
AI: Yes, its good and it can produce some good solutions, however it ultimately doesn't know what it's doing and at the best of cases needs strong orchestrators.
We're in a cesspit of business driven development and they're not getting the right harsh and repulational punishments for bad decisions.
Replies
Skill loss is real. BUT, I have been complaining about skill loss to my bosses for literally a decade. So AI is just one problem for me. I was coding less and less every year for some reason.
I'm not sure skill loss is such a huge issue, in other words. It might just be a sign that the nature of our work if shifting. Being able to recite the C++ standard and using all the 100s of features correctly will just not be as highly regarded as knowing good architecture instead?
> too fast
Another aspect is that it reorders some of our problems.
In typical development, we're more likely to go back and forth about "is this really what we want to make" or "what could possibly go wrong if we do that", and ideally we do it before PR's get approved or anything is merged/deployed. Some portion of that is getting moved to "we'll see if anyone complains later". As they say, an ounce of prevention is worth a pound of cure.
> We're in a cesspit of business driven development
In a business-driven world with business-driven governments writing business-driven rules, what's the alternative if you want to optimize for success?
> We're in a cesspit of business driven development
It's not just businesses doing it either, I regularly see big PRs get merged on open source projects that seem fine on the surface but contain a 1000 paper cuts worth of bugs (not critical, but just enough to annoy you)
On top of that, the code wasn't idiomatic C++ (for this specific project) and the LLM completely ignored available APIs. Sure, it can be fixed, and maintainers should've caught it, but the amount of code being generated requires so much energy on everyone's behalf.
I don’t disagree with any of that, but I think the brutal truth is that the priority of most businesses was always that approximate, slipshod, business-driven development. The human engineering process was only coincidentally a check back against the worst outcomes of that philosophy, not intentionally one.