this post was submitted on 08 May 2024
1702 points (99.2% liked)
Technology
60048 readers
2835 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Take all you want, it will only take a few hallucinations before no one trusts LLMs to write code or give advice
Because none of us have ever blindly pasted some code we got off google and crossed our fingers ;-)
It's way easier to figure that out than check ChatGPT hallucinations. There's usually someone saying why a response in SO is wrong, either in another response or a comment. You can filter most of the garbage right at that point, without having to put it in your codebase and discover that the hard way. You get none of that information with ChatGPT. The data spat out is not equivalent.
That's an important point, and and it ties into the way ChatGPT and other LLMs take advantage of a flaw in the human brain:
Because it impersonates a human, people are more inherently willing to trust it. To think it's "smart". It's dangerous how people who don't know any better (and many people that do know better) will defer to it, consciously or unconsciously, as an authority and never second guess it.
And the fact it's a one on one conversation, no comment sections, no one else looking at the responses to call them out as bullshit, the user just won't second guess it.
Your thinking is extremely black and white. Many many, probably most actually, second guess chat bot responses.
Think about how dumb the average person is.
Now, think about the fact that half of the population is dumber than that.
When you paste that code you do it in your private IDE, in a dev environment and you test it thoroughly before handing it off to the next person to test before it goes to production.
Hitting up ChatPPT for the answer to a question that you then vomit out in a meeting as if it’s knowledge is totally different.
Which is why I used the former as an example and not the latter.
I’m not trying to make a general case for AI generated code here… just poking fun at the notion that a few errors will put people off using it.
Split segment of data without pii to staging database, test pasted script, completely rewrite script over the next three hours.
We should already be at that point. We have already seen LLMs' potential to inadvertently backdoor your code and to inadvertently help you violate copyright law (I guess we do need to wait to see what the courts rule, but I'll be rooting for the open-source authors).
If you use LLMs in your professional work, you're crazy. I would never be comfortably opening myself up to the legal and security liabilities of AI tools.
Eh, we use copilot at work and it can be pretty helpful. You should always check and understand any code you commit to any project, so if you just blindly paste flawed code (like with stack overflow,) that's kind of on you for not understanding what you're doing.
The issue on the copyright front is the same kind of professional standards and professional ethics that should stop you from just outright copying open-source code into your application. It may be very small portions of code, and you may never get caught, but you simply don't do that. If you wouldn't steal a function from a copyleft open-source project, you wouldn't use that function when copilot suggests it. Idk if copilot has added license tracing yet (been a while since I used it), but absent that feature you are entirely blind to the extent which it's output is infringing on licenses. That's huge legal liability to your employer, and an ethical coinflip.
Regarding understanding of code, you're right. You have to own what you submit into the codebase.
The drawback/risks of using LLMs or copilot are more to do with the fact it generates the likely code, which means it's statistically biased to generate whatever common and unnoticeable bugged logic exists in the average github repo it trained on. It will at some point give you code you read and say "yep, looks right to me" and then actually has a subtle buffer overflow issue, or actually fails in an edge case, because in a way that is just unnoticeable enough.
And you can make the argument that it's your responsibility to find that (it is). But I've seen some examples thrown around on twitter of just slightly bugged loops; I've seen examples of it replicated known vulnerabilities; and we have that package name fiasco in the that first article above.
If I ask myself would I definitely have caught that? the answer is only a maybe. If it replicates a vulnerability that existed in open-source code for years before it was noticed, do you really trust yourself to identify that the moment copilot suggests it to you?
I guess it all depends on stakes too. If you're generating buggy JavaScript who cares.
I feel like it had to cause an actual disaster with assets getting destroyed to become part of common knowledge (like the challenger shuttle or something).
Yeah but if you're not feeding it protected code and just asking simple questions for libraries etc then it's good
Maybe for people who have no clue how to work with an LLM. They don't have to be perfect to still be incredibly valuable, I make use of them all the time and hallucinations aren't a problem if you use the right tools for the job in the right way.
The last time I saw someone talk about using the right LLM tool for the job, they were describing turning two minutes of writing a simple map/reduce into one minute of reading enough to confirm the generated one worked. I think I'll pass on that.
LLM wasn't the right tool for the job, so search engine companies made their search engines suck so bad that it was an acceptable replacement.
Honestly? I think search engines are actually the best use for LLMs. We just need them to be "explainable" and actually cite things.
Even going back to the AOL days, Ask Jeeves was awesome and a lot of us STILL write our google queries in question form when we aren't looking for a specific factoid. And LLMs are awesome for parsing those semi-rambling queries like "I am thinking of a book. It was maybe in the early 00s? It was about a former fighter pilot turned ship captain leading the first FTL expedition and he found aliens and it ended with him and humanity fighting off an alien invasion on Earth" and can build on queries to drill down until you have the answer (Evan Currie's Odyssey One, by the way).
Combine that with citations of what page(s) the information was pulled from and you have a PERFECT search engine.
That may be your perfect search engine, I jyst want proper boolean operators on a sesrch engine that doesn't think it knows what I want better than I do, and doesn't pack the results out with pages that don't match all the criteria just for the sake of it. The sort of thing you described would be anathema to me, as I suspect my preferred option may be to you.
They are VERY VERY good at search engine work with a few caveats that we'll eventually nail. The problem is, they're WAY to expensive for that purpose. Single queries take tons of compute and power. Constant training on new data takes boatloads of power.
They're the opposite of efficient; eventually, they'll have to start charging you a subscription to search with them to stay in business.
So my company said they might use it to improve confluence search, I was like fuck yeah! Finally a good use.
But to be fair, that’s mostly because confluence search sucks to begin with.
You're describing Bing Chat.
And google gemini (?) and kagi's LLM and all the other ones.
Yeah, every time someone says how useful they find LLM for code I just assume they are doing the most basic shit (so far it’s been true).
That's a 50% time reduction for the same output which sounds great to me.
I'd much rather let an LLM do the menial shit with my validation while I focus on larger problems such as system and API design, or creating rollback plans for major upgrades instead of expending mental energy writing something that has been written a thousand times. They're not gonna rewrite your entire codebase, but they're incredibly useful for the small stuff.
I'm not even particularly into LLMs, and they're definitely not gonna change the world in the way big tech would like you to believe. However, to deny their usefulness is silly.
It's not a consistent 50%, it's 50% off one task that's so simple it takes two minutes. I'm not doing enough of that where shaving off minutes is helpful. Maybe other people are writing way more boilerplate than I am or something.
Those little things add up though, and it's not just good at boilerplate. Also just having a more intelligent context-aware auto complete itself I've found to be super valuable.
The quality really doesn't matter.
If they manage to strip any concept of authenticity, ownership or obligation from the entirety of human output and stick it behind a paywall, that's pretty much the whole ball game.
If we decide later that this is actually a really bullshit deal -- that they get everything for free and then sell it back to us -- then they'll surely get some sort of grandfather clause because "Whoops, we already did it!"
People keep saying this but it’s just wrong.
Maybe I haven’t tried the language you have but it’s pretty damn good at code.
Granted, whatever it puts out needs to be tested and possibly edited but that’s the same thing we had to do with Stack Overflow answers.
I've tried a lot of scenarios and languages with various LLMs. The biggest takeaway I have is that AI can get you started on something or help you solve some issues. I've generally found that anything beyond a block or two of code becomes useless. The more it generates the more weirdness starts popping up, or it outright hallucinates.
For example, today I used an LLM to help me tighten up an incredibly verbose bit of code. Today was just not my day and I knew there was a cleaner way of doing it, but it just wasn't coming to me. A quick "make this cleaner: " and I was back to the rest of the code.
This is what LLMs are currently good for. They are just another tool like tab completion or code linting
I use it all the time and it's brilliant when you put in the basic effort to learn how to use it effectively.
It's allowing me and other open source devs to increase the scope and speed of our contributions, just talking through problems is invaluable. Greedy selfish people wanting to destroy things that help so many is exactly the rolling coal mentality - fuck everyone else I don't want the world to change around me! Makes me so despondent about the future of humanity.
Have you tried recent models? They're not perfect no, but they can usually get you most of the way there if not all the way. If you know how to structure the problem and prompt, granted.
We already have those near constantly. And we still keep asking queries.
People assume that LLMs need to be ready to replace a principle engineer or a doctor or lawyer with decades of experience.
This is already at the point where we can replace an intern or one of the less good junior engineers. Because anyone who has done code review or has had to do rounds with medical interns know... they are idiots who need people to check their work constantly. An LLM making up some functions because they saw it in stack overflow but never tested is not at all different than a hotshot intern who copied some code from stack overflow and never tested it.
Except one costs a lot less...
This is a bad thing.
Not just because it will put the people you're talking about out of work in the short term, but because it will prevent the next generation of developers from getting that low-level experience. They're not "idiots", they're inexperienced. They need to get experience. They won't if they're replaced by automation.
First a nearly unprecedented world-wide pandemic followed almost immediately by record-breaking layoffs then AI taking over the world, man it is really not a good time to start out as a newer developer. I feel so fortunate that I started working full-time as a developer nearly a decade ago.
Dude the pandemic was amazing for devs, tech companies hiring like mad, really easy to get your foot in the door. Now, between all the layoffs and AI it is hellish
I think it depends on where you live. Hiring didn't go crazy where I live, but the layoffs afterwards sure did.
So, the whole point of learning is to ask questions from people who know more than you, so that you can gain the knowledge you need to succeed…
So… if you try to use these LLMs to replace parts of sectors, where there need to be people that can work their way to the next tier as they learn more and get better at their respective sectors, you do realize that eventually there will no longer be people that can move up their respective tier/position, because people like you said “Fuck ‘em, all in on this stupid LLM bullshit!” So now there are no more doctors, or real programmers, because people like you thought it would just be the GREATEST idea to replace humans with fucking LLMs.
You do see that, right?
Calling people fucking stupid, because they are learning, is actually pretty fucking stupid.
Where did I say "Fuck 'em, all in on this stupid LLM bullshit!"?
But yes, there is a massive labor issue coming. That is why I am such a proponent of Universal Basic Income because there are not going to be enough jobs out there.
But as for training up the interns: Back in the day, do you know what "interns" did? And by "interns" I mean women because sexism but roll with me. Printing out and sorting punch cards. Compilers and general technical advances got rid of those jobs and pushed up where the "charlie work" goes.
These days? There are good internships/junior positions and bad ones. A good one actually teaches skills and encourages the worker to contribute. A bad one has them do the mindless grunt work that nobody else wants to. LLMs get rid of the latter.
And... I actually think that is good for the overall health of workers, if not the number (again, UBI). Because if someone can't be trusted to write meaningful code without copying it off the internet and not even updating variable names? I don't want to work with them. I spend too much of my workday babysitting those morons who are just here there to get some work experience so they can con their way into a different role and be someone else's problem.
And experience will be gained the way it is increasingly being gained. Working on (generally open source) projects and interviewing for competitive internships where the idea is to take relatively low cost workers and have them work on a low ROI task that is actually interesting. It is better for the intern because they learn actual development and collaboration skills. And it is better for the staff because it is a way to let people work on the stuff they actually want to do without the massive investment of a few hundred hours of a Senior Engineer's time.
And... there will be a lot fewer of those roles. Just like there were a lot fewer roles for artists as animation tools stopped requiring every single cell of animation to be hand drawn. And that is why we need to decouple life from work through UBI.
But also? If we have less internships that consist of "okay. good job. thanks for that. Next time can you at least try and compile your code? or pay attention to the squiggly red lines in your IDE? or listen to the person telling you that is wrong?"? Then we have better workers and better junior developers who can actually do more meaningful work. And we'll actually need to update the interviewing system to not just be "did you memorize this book of questions from Amazon?" and we'll have fewer "hot hires" who surprise everyone by being able to breath unassisted but have a very high salary because they worked for facebook.
Because, and here is the thing: LLMs are already as good, if not better than, an intern or junior engineer. And the companies that spend money on training up interns aren't going to be rewarded. Under capitalism, there is no reason to "take one for the team" so that your competition can benefit.
Do so at your own peril. Because the thing is, a person will learn from their mistakes and grow in knowledge and experience over time. An LLM is unlikely to do the same in a professional environment for two big reasons:
The company using the LLM would have to send data back to the creator of the LLM. This means their proprietary work could be at risk. The AI company could scoop them, or a data leak would be disastrous.
Alternatively, the LLM could self-learn and be solely in house without any external data connections. A company with an LLM will never go for this, because it would mean their model is improving and developing out of their control. Their customized version may end up being better than their the LLM company's future releases. Or, something might go terribly wrong with the model while it learns and adapts. If the LLM company isn't held legally liable, they're still going to lose that business going forward.
On top of that, you need your inexperienced noobs to one day become the ones checking the output of an LLM. They can't do that unless they get experience doing the work. Companies already have proprietary models that just require the right inputs and pressing a button. Engineers are still hired though to interpret the results, know what inputs are the right ones, and understand how the model works.
A company that tries replacing them with LLMs is going to lose in the long run to competitors.
Actually, nvidia recently announced RAG (Retrieval-Augmented Generation). Basically the idea is that you take an "off the shelf" LLM and then feed your local instance sensitive corporate data. It can then use that information in its responses.
So you really are "teaching" it every time you do a code review of the AI's merge request and say "Well.. that function doesn't exist" or "you didn't use useful variable names" and so forth. Which... is a lot more than I can say about a lot of even senior or principle engineers I have worked with over the years who are very much making mistakes that would get an intern assigned to sorting crayons.
Which, again, gets back to the idea of having less busywork. Less grunt work. Less charlie work. Instead, focus on developers who can actually contribute to a team and design meetings.
And the model I learned early in my career that I bring to every firm is to have interns be a reward for talented engineers and not a punishment for people who weren't paying attention in Nose Goes. Teaching a kid to write a bunch of utility functions does nothing they didn't learn (or not learn) in undergrad but it is a necessary evil... that an AI can do.
Instead, the people who are good at their jobs and contributing to the overall product? They probably have ideas they want to work on but don't have the cycles to flesh out. That is where interns come into play. They work with those devs and other staff and learn what it means to actually be part of a team. They get to work on really cool projects and their mentors get to ALSO work on really cool projects but maybe focus more on the REALLY interesting parts and less on the specific implementation.
And result is that your interns are now actually developers who are worth a damn.
Also: One of the most important things to teach a kid is that they owe the company nothing. If they aren't getting the raise they feel they deserve then they need to be updating their linkedin and interviewing elsewhere. That is good for the worker. And that also means that the companies that spend a lot of money training up grunts? They will lose them to the companies who are desperate for people who can lead projects and contribute to designs but haven't been wasting money on writing unit tests.