- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
Over the past few years, the evolution of AI-driven tools like GitHub’s Copilot and other large language models (LLMs) has promised to revolutionise programming. By leveraging deep learning, these tools can generate code, suggest solutions, and even troubleshoot issues in real-time, saving developers hours of work. While these tools have obvious benefits in terms of productivity, there’s a growing concern that they may also have unintended consequences on the quality and skillset of programmers.
I have heard the same rhetoric about IDEs, autocomplete (Intellisense, Jedi, etc.), DevOps, and frameworks. The kernel of truth across all of them is the separation between a dev and good dev. It is getting easier and easier to have something built for you using AI in your IDE in a framework that abstracts all the things away dumped into a prebuilt pipeline that deploys your artifacts for you. A dev can do that. A good dev understands the tools and knows when to dig into things.
I have yet to see a decrease in the number of good devs I meet even though IDEs slowly replaced text editors (and editors became strong enough to become IDEs). Frameworks have enabled more good devs to focus on business logic. DevOps provides solid guard rails for everything.
I don’t know if there’s an increase in the number of superficial devs. I haven’t interviewed junior dev candidates in awhile. I do know the market is flooded right now so I’d argue there might be other factors.
Also overall I do agree with the idea that letting copilot do everything for you means you don’t understand anything. Shit was the same way when cookbooks were common.
I browsed author own codebase and the first thing I saw is 150 lines of C# reimplementing functions available in the .NET standard lib.
Once again: https://en.wikipedia.org/wiki/Dunning–Kruger_effect
Link? I’d like to see. Always amusing to see that kind of thing.
https://github.com/bizzehdee/bzTorrent/blob/master/bzTorrent/Helpers/PackHelper.cs
Which is entierely covered by https://learn.microsoft.com/en-us/dotnet/api/system.buffers.binary.binaryprimitives
There are a LOT of superficial devs out there. You dont even have to be interviewing junior devs. Plenty of them out there at medium and senior levels. They existed before LLMs were spitting code like today, and this will undoubtedly lower the bar for bad developers to enter. It remains to be seen if this can help the gold developers in a meaningful way.
If LLMs allow bad programmers to deliver work with good enough quality to pass themselves off as good programmers, this means LLMs are fantastic value for money.
Also worth noting: programmers do learn by analysing the output of LLMs, just as the programmers of old learned by reading someone else’s code.
I think I could have states my opinion better. I think LLMs total value remains to be seen. They allow totally incompetent developers to occasionally pass as below average developers. Is that good or bad? I don’t know. What an average and excellent developer can do with LLM assistance is less clear. Certainly it can help those developers in some situations.
This is a baseless assertion from your end, and a purely personal one.
My anecdotal evidence is that the best software engineers I know use these tools extensively to get rid of churn and drudge work, and they apply it anywhere and everywhere they can.
I’m don’t disagree. Good developers use the tools to do better, but its incremental not revolutionary improvements for already competent developers.