Unsurprisingly, it's necessary to understand a problem to solve it - just like the proverbial infinite monkey would in theory produce the entire body of work of Shakespeare given enough time, in reality, only Shakespeare managed to write proper Shakespeare the first time out.
AI is the infinite monkey of coding. I, as a senior developer, have spend entirely too many hours of my working life fixing code written by monkeys, and I have already had to correct AI code (thankfully small and generated by a colleague who promptly apologized and decided to do his homework and study the problem at hand instead of winging it with Crapilot).
AI coding is an improvement on infinite monkey Shakespeare in the sense that it only types whole words from a dictionary. Although that dictionary has been built from a mix of classic literature and SNS posts.
I am indeed lucky because the company I work for cares about its employees. It's literally written in the company statutes: the company exists to make money of course, but first and foremost to serve its workforce and the community, and takes decisions to maximize the well-being and the personal growth of the employees and the community.
We took an honest look at including AI in our workflow, but we decided it wasn't worth the social destruction. Only a few employees use it - mostly the marketdroids to generate illustrations on the sales literature.
I am aware that this is a rare type of company and I cherish that job.
As an engineer, I’m not looking forward to the entire generation(s?) of vibe coders who couldn’t explain what a byte is and the ways one might be stored on a system.
No, but it constraining the labor market. AI is a hammer that employers are enthusiastically wielding to “discipline” labor, and to put developers “in their place” and accustomed to asking for and accepting less.
AI (and the threat of AI) is being used to end the days of developers enjoying high pay and strong market leverage. Investors and c-levels don’t care about the craft of software, they care about profit. Labor costs are an impediment to more profit.
If one senior level developer can be replaced with AI plus two or three entry level devs in India cranking out shit that barely works but still sells, at half the cost, then you know what will happen.
They do not care about you, your job, or your craft. You are seen as a tool in their designs, and you have had too much power for too long. They want to dispense with as many expensive, opinionated knowledge workers as quickly as possible. Even AI that half works is better than a competent but uppity expensive employee, from their POV.
I agree, this is the real impact of Ai. It won't replace developers, but make them work for less money. But I actually think real programmers will be even more needed in the future, if there is ton of bad code written by non coders with Ai or even by real coders with the support of Ai. That means we get more code, that needs to be reviewed and worked on by real programmers.
Therefore on one hand it will lessen the money earned for real programmers, on the other hand they will be more useful and needed in the future.
I wouldn't trust current models to do any real work. Aaand I think humans will be cheaper than LLMs for a long time to come. Ultimately all costs are labor and if you need to give the power plant people (running the plant, mining the fuel, building the plant) sandwiches to get them to provide power for your llm, you're probably better off giving a human programmer sandwiches instead.
The ai bubble pops when investors decide they want dividends instead of speculative gains.
Not really for writing yet either. Its an assistant. It can write code sections and comments that then have to be reviewed and edited a bit. Rather than a coder having to go back and forth between a search engine as they write they are more likely to be able to stay in the ide.
Have you actually worked in a programming role before? Googling things is absolutely the norm. Most people don't know every single in and out of every library/framework they're using, especially when learning new ones. This goes double for more complex or sprawling frameworks where it may be less than obvious how to perform a particular task from the documentation alone or when running into undocumented limitations or bugs (although admittedly an in-IDE assistant won't be too useful for that anyway).