It seems I’m the only software engineer on Lemmy who loves having AI. It’s not perfect, but it’s so much better than doing everything from scratch and it’s far more reliable for solving obscure runtime errors than chasing down all the typically dead-end results on a search engine for the stack trace. Or maybe I’m just the only one willing to endure the down votes. Either way, AI has been an exceptional boon in my daily workload.
I agree, but that’s a result of fascism, not technology. How it’s being utilized should be the target of ire, not the technology itself. The benefits of AI should be shared by all of society, but instead it’s being used to create even more wealth disparity. That actress should have access to Universal Basic Income and be able to do the work she feels passionate about, no matter what it is. Instead we have oligarchs extracting ever more from a suffering populace.
I see an LLM as my good-but-not-perfect assistant, there to code up boring bits “loop thru this data and extract…”, “improve this bit of code please”, and to help with errors “why does this code give that error”.
I never let it do big slabs of code, and always run and check its code incrementally.
It is my code and the LLM just makes it easier to do. Thanks LLM.
This is probably a fine and responsible way of using LLM, but sadly the loudest voices are those crowing about coding being a “solved” problem and bragging about being 10x more productive by doing very little and certainly not reviewing refactoring and understanding the generated code.
Only gotcha for this is LLM is being offered well below cost, will you still want yo use it at 5x or 10x the cost?
No. I stopped using Copilot after the price increase. Now I do everything locally using Qwen. There’s a significant decrease in quality, not because Qwen is inherently worse, but because I only have 12GB of VRAM, but at least it’s affordable, and still better than no AI.
I tried using LocalAI to get some kind of agent not being used to entrench fascism and destroy the environment and consume irreplaceable clean water and haven’t had much luck. Even on a beefy machine with a chonky graphics card, it’s slow. That was after trying it on my laptop and damn near burning my legs off with the graphics card going nuts and the fans spinning up like jet turbines.
I did an experiment where I tried to get it to write some code that I had already written myself, just as a test case. Even when I found a model that worked more quickly, the code it produced didn’t do the thing I had told it to do. I had to tell the LLM that, contrary to its “thinking,” inline HTML does, in fact, make for valid Markdown, and that it could actually do the thing I had already explicitly told it to do.
The second iteration worked, but the code was far from ideal. If I had been in a professional situation where i would have been putting that up for review, it would have taken me even longer to make the code presentable and up to my standard. In the end, the code I wrote was better by a mile and I wrote it maybe twice as fast as the LLM.
I’m sure this is faster if I use Claude or something and engage the Torment Nexus, but that’s kind of my point. It takes so much juice to make these things viable, and the hardware you need at home to replicate that usefulness is expensive and becoming less available. And removing the energy cost from the user’s machine (where you can literally hear and feel the energy consumption) to some bank of servers you’ll never see in person does a lot to distance a user from the effects of their usage of the tool. Running a local agent only made my view on AI lower than it already was.
I did not try the Qwen model, though I suppose I ought to since I’ve now seen you claim success with it a few times on here. Will I finally be impressed? Man, I doubt it, but I’ll give it a go.
When working with a local micro, be sure to use a prompt to seed itl. Inform it that it is an expert in whatever language you’re using, and that it is methodical, professional, intelligent, knowledgeable, and accurate; and that it produces only highly efficient, well-documented code that compiles and utilizes best practices. Throw whatever adjectives or descriptors you think are appropriate in there. This goes double if you’re using an MoE, as it primes the model to know which layers/sub-models to activate, so you don’t have code being written by the wrong aspect, such as junior programmers and examples of poorly written code.
I have coworkers with varying degrees of proficiency with AI. The ones that are better with it rein it in when it goes haywire. I have less of an issue with this. It still does awkward stuff here and there. The ones that are bad with it just commit the code for review and annoy me. When 60-80% or so of your PR can be refactored away then it’s a crap PR and honestly never should have been one. Don’t make me read through 2000 lines that should have been 400. It’s a waste of time. This mostly is it doing brain dead things like instead of passing a parameter into a method it makes 4 nearly identical methods.
I mostly use AI to implement a solution, not come up with the solution. I don’t care how fast you can type…AI can type faster. That also means I understand what it’s trying to build and how it should be going about it. That does mean you still have to use your brain and not offload your critical thinking to the machine which is what I see a lot of people doing with it.
In that regard I like AI but it’s still a love/hate relationship for sure. It both saves and costs me time just in different ways.
I have had a fair amount of success getting AI to do those refactorings, reducing 2000 lines of code to 400, and generating 3000 lines of documentation (including flowcharts) explaining how the 400 lines work, adding 1200 lines of automated testing to prevent regressions, etc. etc.
The shotgun approach with AI is extremely terrible. That’s where you basically give the AI your code, a description of the bug/feature, and ask it to deliver. That’s insane levels of laziness. It’s unprofessional. I’ve done it, hence I know it’s a bad idea. I usually spend more time fighting the AI in these cases because the code turns into a poison. Its context gets filled up with the bad styling, bad decisions, … the code smell gets baked into the attention layer itself, propagating through anything the AI session spits out.
I have much better results when I orchestrate the AI session. I have put together several standard SKILL.md files for doing code-review, grill-me, feature-design, … and I end up using these in whichever order I prescribe to be best. The idea is, I want to guide the session context in the best possible way in order to receive the best possible output from the machine.
I still review output and argue with it a bit, but much less now. I’ve also noticed token consumption go down when I put useful information in things like AGENTS.md
When 60-80% or so of your PR can be refactored away then it’s a crap PR and honestly never should have been one.
So their time savings in getting AI help to write their code means that you spend more of your presumably more expensive time doing reviews and educating them about slop removal instead of some higher-value activity. Sounds like you’re veering into negative ROI for the AI use if that’s true.
Luckily, I don’t review PRs very often, I have people to do that. But the general principle is that the content of a PR is the responsibility of the submitter, regardless of its source. Wrong algorithm? Their fault. No-good UTs? Their fault. Inappropriate or unsafe dependencies? Their fault. Slop? Their fault.
Luckily, with the work we do, there’s often nothing someone could train an LLM on, so we don’t see all that many PRs with AI-generated content, unless we’re using some well-known commodity library or framework in a common way. And that was always the easy stuff anyway.
A slop PR should be the submitter’s responsibility, but if they’re trying to push out unreviewed slop, you know they’re just going to ask an LLM to refactor it instead of looking at it themselves. The best response is just to reject it outright and have someone else work on a new solution.
Yeah, I use it to spar with when deciding on solving something. I ask it what are the domain-or-language-typical, idiomatic or best-practice ways of solving something. I trace errors by using AI. I even take whole-sale code it produces if it isn’t “serious” like just wanting the HTML or CSS lines that will do the trick.
It will definitely suggest things that I don’t think are correct and then I ignore it. It definitely wastes my time sometimes. I definitely don’t learn things well enough when using it. But I only have so much time and too many problems I need to solve.
I recently helped evaluate it for company use. My test considered of vibecoding an App that takes a Pipewire screencast and does some basic image processing on each frame. In C#, which doesn’t have great options for talking to Pipewire. I did several runs with various iterations of Claude.
On the upside, it had few problems navigating DBus to negotiate a screencast handle. So that’s one annoying API out of the way.
On the downside, all attempts at taking to libpipewire through P/Invoke failed, usually because Claude hallucinated parts of the API or set constants to incorrect values. I only got a working program when I allowed the use of a prerelease Pipewire NuGet package.
The generated code was of acceptable quality but I wouldn’t allow it into a codebase without a refactor. The code has zero consistency and one time the whole solution didn’t have any namespaces. The fact that the LLM writes and rewrites the code during a single prompt means that you can get mild spaghetti as an initial state.
Honestly, I can see it for something like rapid prototyping or implementing basic scaffolding for an annoying API. But damn is Claude bad at detail work.
It seems I’m the only software engineer on Lemmy who loves having AI. It’s not perfect, but it’s so much better than doing everything from scratch and it’s far more reliable for solving obscure runtime errors than chasing down all the typically dead-end results on a search engine for the stack trace. Or maybe I’m just the only one willing to endure the down votes. Either way, AI has been an exceptional boon in my daily workload.
There’s a lot of existential dread out there… try talking with an out of work actress about AI and find out how she really feels…
I agree, but that’s a result of fascism, not technology. How it’s being utilized should be the target of ire, not the technology itself. The benefits of AI should be shared by all of society, but instead it’s being used to create even more wealth disparity. That actress should have access to Universal Basic Income and be able to do the work she feels passionate about, no matter what it is. Instead we have oligarchs extracting ever more from a suffering populace.
I see an LLM as my good-but-not-perfect assistant, there to code up boring bits “loop thru this data and extract…”, “improve this bit of code please”, and to help with errors “why does this code give that error”.
I never let it do big slabs of code, and always run and check its code incrementally.
It is my code and the LLM just makes it easier to do. Thanks LLM.
This is probably a fine and responsible way of using LLM, but sadly the loudest voices are those crowing about coding being a “solved” problem and bragging about being 10x more productive by doing very little and certainly not reviewing refactoring and understanding the generated code.
Only gotcha for this is LLM is being offered well below cost, will you still want yo use it at 5x or 10x the cost?
No. I stopped using Copilot after the price increase. Now I do everything locally using Qwen. There’s a significant decrease in quality, not because Qwen is inherently worse, but because I only have 12GB of VRAM, but at least it’s affordable, and still better than no AI.
I tried using LocalAI to get some kind of agent not being used to entrench fascism and destroy the environment and consume irreplaceable clean water and haven’t had much luck. Even on a beefy machine with a chonky graphics card, it’s slow. That was after trying it on my laptop and damn near burning my legs off with the graphics card going nuts and the fans spinning up like jet turbines.
I did an experiment where I tried to get it to write some code that I had already written myself, just as a test case. Even when I found a model that worked more quickly, the code it produced didn’t do the thing I had told it to do. I had to tell the LLM that, contrary to its “thinking,” inline HTML does, in fact, make for valid Markdown, and that it could actually do the thing I had already explicitly told it to do.
The second iteration worked, but the code was far from ideal. If I had been in a professional situation where i would have been putting that up for review, it would have taken me even longer to make the code presentable and up to my standard. In the end, the code I wrote was better by a mile and I wrote it maybe twice as fast as the LLM.
I’m sure this is faster if I use Claude or something and engage the Torment Nexus, but that’s kind of my point. It takes so much juice to make these things viable, and the hardware you need at home to replicate that usefulness is expensive and becoming less available. And removing the energy cost from the user’s machine (where you can literally hear and feel the energy consumption) to some bank of servers you’ll never see in person does a lot to distance a user from the effects of their usage of the tool. Running a local agent only made my view on AI lower than it already was.
I did not try the Qwen model, though I suppose I ought to since I’ve now seen you claim success with it a few times on here. Will I finally be impressed? Man, I doubt it, but I’ll give it a go.
When working with a local micro, be sure to use a prompt to seed itl. Inform it that it is an expert in whatever language you’re using, and that it is methodical, professional, intelligent, knowledgeable, and accurate; and that it produces only highly efficient, well-documented code that compiles and utilizes best practices. Throw whatever adjectives or descriptors you think are appropriate in there. This goes double if you’re using an MoE, as it primes the model to know which layers/sub-models to activate, so you don’t have code being written by the wrong aspect, such as junior programmers and examples of poorly written code.
I have coworkers with varying degrees of proficiency with AI. The ones that are better with it rein it in when it goes haywire. I have less of an issue with this. It still does awkward stuff here and there. The ones that are bad with it just commit the code for review and annoy me. When 60-80% or so of your PR can be refactored away then it’s a crap PR and honestly never should have been one. Don’t make me read through 2000 lines that should have been 400. It’s a waste of time. This mostly is it doing brain dead things like instead of passing a parameter into a method it makes 4 nearly identical methods.
I mostly use AI to implement a solution, not come up with the solution. I don’t care how fast you can type…AI can type faster. That also means I understand what it’s trying to build and how it should be going about it. That does mean you still have to use your brain and not offload your critical thinking to the machine which is what I see a lot of people doing with it.
In that regard I like AI but it’s still a love/hate relationship for sure. It both saves and costs me time just in different ways.
I have had a fair amount of success getting AI to do those refactorings, reducing 2000 lines of code to 400, and generating 3000 lines of documentation (including flowcharts) explaining how the 400 lines work, adding 1200 lines of automated testing to prevent regressions, etc. etc.
Exactly.
The shotgun approach with AI is extremely terrible. That’s where you basically give the AI your code, a description of the bug/feature, and ask it to deliver. That’s insane levels of laziness. It’s unprofessional. I’ve done it, hence I know it’s a bad idea. I usually spend more time fighting the AI in these cases because the code turns into a poison. Its context gets filled up with the bad styling, bad decisions, … the code smell gets baked into the attention layer itself, propagating through anything the AI session spits out.
I have much better results when I orchestrate the AI session. I have put together several standard SKILL.md files for doing
code-review,grill-me,feature-design, … and I end up using these in whichever order I prescribe to be best. The idea is, I want to guide the session context in the best possible way in order to receive the best possible output from the machine.I still review output and argue with it a bit, but much less now. I’ve also noticed token consumption go down when I put useful information in things like AGENTS.md
So their time savings in getting AI help to write their code means that you spend more of your presumably more expensive time doing reviews and educating them about slop removal instead of some higher-value activity. Sounds like you’re veering into negative ROI for the AI use if that’s true.
Luckily, I don’t review PRs very often, I have people to do that. But the general principle is that the content of a PR is the responsibility of the submitter, regardless of its source. Wrong algorithm? Their fault. No-good UTs? Their fault. Inappropriate or unsafe dependencies? Their fault. Slop? Their fault.
Luckily, with the work we do, there’s often nothing someone could train an LLM on, so we don’t see all that many PRs with AI-generated content, unless we’re using some well-known commodity library or framework in a common way. And that was always the easy stuff anyway.
A slop PR should be the submitter’s responsibility, but if they’re trying to push out unreviewed slop, you know they’re just going to ask an LLM to refactor it instead of looking at it themselves. The best response is just to reject it outright and have someone else work on a new solution.
Yeah, I use it to spar with when deciding on solving something. I ask it what are the domain-or-language-typical, idiomatic or best-practice ways of solving something. I trace errors by using AI. I even take whole-sale code it produces if it isn’t “serious” like just wanting the HTML or CSS lines that will do the trick.
It will definitely suggest things that I don’t think are correct and then I ignore it. It definitely wastes my time sometimes. I definitely don’t learn things well enough when using it. But I only have so much time and too many problems I need to solve.
I recently helped evaluate it for company use. My test considered of vibecoding an App that takes a Pipewire screencast and does some basic image processing on each frame. In C#, which doesn’t have great options for talking to Pipewire. I did several runs with various iterations of Claude.
On the upside, it had few problems navigating DBus to negotiate a screencast handle. So that’s one annoying API out of the way.
On the downside, all attempts at taking to libpipewire through P/Invoke failed, usually because Claude hallucinated parts of the API or set constants to incorrect values. I only got a working program when I allowed the use of a prerelease Pipewire NuGet package.
The generated code was of acceptable quality but I wouldn’t allow it into a codebase without a refactor. The code has zero consistency and one time the whole solution didn’t have any namespaces. The fact that the LLM writes and rewrites the code during a single prompt means that you can get mild spaghetti as an initial state.
Honestly, I can see it for something like rapid prototyping or implementing basic scaffolding for an annoying API. But damn is Claude bad at detail work.