posted in Technology

Cory Doctorow: The people who tell you ‘AI is changing everything’ are lying

www.thenerve.news/p/cory-doctorow-ai-business-incentive-to-lie-useless-chatbots-report-nikhil-suresh
Cory Doctorow: The people who tell you ‘AI is changing everything’ are lyingThe NerveCory Doctorow: The people who tell you ‘AI is changing everything’ are lyingIt has become impossible to tell managers mesmerised by artificial intelligence that the tools are not, in fact, helpful. So employees just play along with the fiction to keep their jobs, writes our tech columnist

Replying to @⁨GoatSynagogue@lemmy.world⁩

I’m a software developer since the 90s, basically before the internet, we had some C books for reference and that’s it. I can tell you that I started last year to use copilot in vscode and some chatgpt on a web page, and it basically changed my world, and all my 50+ years old coworkers are amazed by what it can do really.

You are right it will not fade at all in software development.

Replying to @⁨Magister@lemmy.world⁩

Completely disagree. The difficult part of software development was never writing code OR speed of delivery. It was understanding requirements and problem solving. LLMs still can not do either of those things and there is no evidence they ever will be able to.

An example of how harmful LLMs actually are to development can succinctly be described with an issue I had a few weeks ago. I found an issue in an open source project, code was fine if a bit hard to understand. I came up with a PR to fix the problem.

In the time from me checking out the code to submitting the PR, a little less than 24 hours, the maintainer had completely rewritten the entire project with Claude. It was complete nonsense. Incredibly difficult to understand. Abstracting things that didn’t need abstracting. My PR was useless, because the entire project was new. The maintainer definitely didn’t understand the changes either. If a bug came up there’s no way AI would be able to solve it (the bug was still there even though the code was entirely new).

LLMs don’t understand the code. They just make things that look like they will work. And then a human has to maintain it (or keep paying billions of dollars for Claude to try to fix it).

Replying to an earlier post

I’m sorry but to me your comment is a bit misguided. You raise extremely valid point and are completely right in what you say, and yet all your argument fails to prove that software development hasn’t changed.

The difficult part was understanding requirements and problem solving: absolutely true. Yet most of the time of a developer was spent in writing code. Now it’s spent refining the analysis so that the LLM stops producing slop. And many programmers are doing it, even with all its downsides, because for them the fun part is understanding the requirements and problem solving, not writing code nor delivering fast. They are delegating those tasks to a machine, even with all the risks and issues.

Your second point (and the anecdote) further proves how programming changed. Before it was unthinkable that some random person, likely with no clue about what they are doing, would refactor an entire codebase in a night.

Both are massive changes. For the best? Arguably not, but I seriously doubt there will be any going back now.

Replying to @⁨the_wonderfool@piefed.social⁩

Now it’s spent refining the analysis so that the LLM stops producing slop

The thing is that actually doing this isn’t faster than writing the code, robs the practitioner of learning, and more often than not doesn’t actually happen, so you have a harder to maintain codebase with more bugs and less knowledgeable developers to maintain it.

Edit: and as a fun bonus accelerates glacier melting!

Replying to @⁨Feyd@programming.dev⁩

robs the practitioner of learning

Not at all. It gives the practitioner the option of skipping the learning.

Starting in the 1990s I started skipping the learning of assembly language, compilers got good enough that I just don’t need to know how the latest SIMD/MIMD/ whatever instructions work, I just express what I want in C and gcc or whatever handles the optimization for me.

Replying to @⁨Feyd@programming.dev⁩

entirely complete abstraction where you (almost) never have any benefit to looking under the covers like c over assembler is completely dishonest.

Is it, though? In the early 1990s I could still optimize compiler output by hand, here and there. In the 1980s it was common practice and necessary in many circumstances to make complex things happen on the constrained hardware. In the 1970s there were a lot of programmers who never touched Fortran, just practiced assembly all the time because Fortran was too inefficient for their needs.

I’ll say that LLMs, this year, are something like compilers were in the 1960s - a revolutionary improvement in accessibility of coding, being able to express what you want in “natural language” - like COBOL did starting in 1959.

LLMs have plenty of pitfalls that COBOL doesn’t today, but I’ll note that Borland Turbo C++ compiler in 1991 was too damn buggy to do anything much more complex than “Hello, World.” with.