Meanwhile in infrastructure land, we got fired cuz "AI replaces us". Have fun with your unpatched servers and firewalls, dickheads
Technology
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- 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, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
In my experience, AI is an amplifier.
Good engineers will produce more good code, because they ask the right questions, know what good looks like and check the output.
Bad engineers will produce reams more bad code. The mistakes they make will be amplified. They will give wrong and incomplete instructions, won't see what the problems are with the result and will ship it anyway.
This amplification also means people will spend a larger proportion of time reviewing than coding, which I think is less interesting.
All of this is stuff that can, to some extent, be addressed with policy. You help and instruct juniors, encourage people to better understand and own their code, or at worst reprimand them if they don't.
You can adjust expectations of product managers and explain to them that more is not better, as it always has been. Faster development can often come with bugs and tech debt and this is more of the same.
All I've said above is puts aside the ethical arguments of using or not using AI of course. That's a separate can of worms entirely.
Good engineers will produce more good code, because they ask the right questions, know what good looks like and check the output.
So what's the point then ?
There have been coding frameworks like game engines for decades, if system coding is beyond your ability.
If AI can't write usable code from the start its worthless.
Maybe you've misunderstood something.
No matter what framework or language you are using, AI can make the development process faster. It can help you debug a problem, write tests and refactor code. In some situations, it will be faster than writing code yourself, in others not.
Provlem being is that it is not an equal amplifier.
Good engineer spends a morning going back and forth and maybe gets something done that wild have taken them all day.
Bad engineer puts first draft slop in production in a couple of minutes.
Bad engineer gets to put out something every few minutes, good engineer works too make it actually right instead of merely looking specifically right.
That's true, but spaghetti code was always faster to write than good code before as well. I will agree that the speed gap probably has grown though. That's why tools like AI need discipline.
If managers and engineers don't understand that their code will turn into garbage and the business will get reputational harm and lose customers / get sued / have more tech debt to fix and they'll eventually learn their lesson. In the meantime it's going to be a painful process where upper management see extra speed, expand their scope or downsize their staff, then learn that they have crumbling foundations and need to adjust. This has publically happened a few times already. Things will stabilize in time.
Good engineers will produce more good code, because they ask the right questions, know what good looks like and check the output.
Best code is the code that is never written in the first place. But that concept is difficult to explain and measure for management purposes. Just because "AI" can automate well-structured, tested boilerplate for "good" developers does not mean all that boilerplate should be there.
Right. When management counted lines as progress, the software was sluggish because of bloat.
Amen. And LLMs have a bias for producing text. And the more questions I ask it, for example to solve more edge cases, it quickly escalates on the existing suggestion rather than find a new approach.
I've read that because they have less and less experience actually writing code junior developers are having trouble analyzing the code produced.
It can work as you say, but some companies are pushing 10x (or whatever) with fewer people, so quality is guaranteed to go to shit.
AI is an amplifier.
So very much this ^^^.
If you put in the same time and effort creating software using AI that you would have put in coding by hand, in my experience you get better software, much more thorough documentation and automated testing, and fewer "oops" moments down the line. Not perfection, but better.
If you just give a loosely specified prompt and take the first functional looking thing that comes out, you can get code 10x faster than ever before, and it's going to be a 100x bigger mess to maintain.
A rule of thumb (aka useless constant applied to imaginary metrics) that my colleagues and I have found is: 80%. Work on an assumption that what you get back from each AI pass is about 80% good or right. Work to identify the 20% that needs more refinement, do another pass, now you're up to 96% good - and honestly probably already better than most first pass ready for a pull request code we used to submit 2 years back. Do a third pass on that and you've probably got something that's not going to give any trouble in all but some really rare cases, and you got it in about half the time you would have spent on lower quality output.
I have been trying, with limited success, to get our junior engineers to use AI to review their own code before submitting pull requests. Some do a single pass and their PRs are pretty good, one says he "doesn't believe in AI" and his code typically needs 3-4 review passes before it's even acceptable, even though he's clearly using AI to write the documentation. AI review is how they're finding all these zero day exploits in widely used products, it works, it finds maybe 80% of things you're looking for (if you keep the scope focused inside its context window capacity.) We are having slightly more success with all the junior engineers by having them submit 5-10 small pull requests per 2 week sprint instead of one big one. This not only helps human reviewers understand the bite sized chunks, it also means the AI reviews are more thorough. It also means the architectural definition steps are much more critical because review of tiny chunks misses more of the architectural level picture.
The biggest ethical question I have about using AI centers on management of management expectations. If management really thinks the human contribution value in software creation has disappeared overnight - I'd look for different management, because that ship just steered straight into an iceberg field. Some of them may pull off the Kessel run in less than 12 parsecs, but most won't.
In my experience the time spent getting AI to do what I want can just be used to write good code in the first place.
I was just planning to do some sort of write up on this topic, although it will be internal only.
Of the three projects I’m currently on
- existing code base where AI sometimes has good ideas but almost never able to implement them successfully. This is legacy code, all human generated, and is probably too tightly coupled. Test framework is tightly coupled to the environment so ai cannot run it
- new tool implementation to give cheaper and faster context across all repos (Spotify Backstage)
- new code base almost entirely ai generated. Much more loosely coupled. There is no test /mock framework available, so it’s all scripts, which the ai is able to run at will to refine its guesses
There’s definitely distinct conditions where ai can be the right tool and can succeed vs when it can’t. In managements blind rush to vibe code everything, they need to better understand where it works and where it doesn’t
In particular, functionality I’m working on this week
- existing code base ”modify function x to cover scenario y” at best gives a useful strategy
- new code base “implement function x similar to existing code base, but that also covers scenario y” seems to work
Nah, good engineers are retiring, bad engineers are running rampant. You give yourself away calling us engineers, we were never, except for some yearly title increase instead of money. Just programmers, and that is fine. Engineer is a whole other thing from the steam age, my BSc was in Math, worked fine to get me in.
Engineer is a whole other thing from the steam age, my BSc was in Math, worked fine to get me in.
As a mechanical engineer, I would beg to differ. When you strip away all the fancy math, engineering is ultimately about critical thought and solving problems/achieving functionality with limited resources. As one of my professors liked to say, "Anyone can build a bridge to support a load, but only an engineer can design a bridge that just barely holds that load."
Engineering is an ancient domain that goes back to the very beginnings of civilization and continues to grow with our needs as we progress. Where once it was just mechanical, we now have domains like electrical, materials, and biomedical engineering. If we've hit a point where we need engineers who specialize in software, why shouldn't we welcome in a new domain?
While it does feel weird calling software developers 'engineers', that is arguably what they do. It's no less reductionist to suggest they are just programmers than it is to suggest that mechanical engineers are simply CAD and Excel jockeys. There's a layer of comprehension about the systems in play and how they can be manipulated that gets lost in the reduction.
My only real sticking point about software engineers where I tend to push back is that Professional Engineer is a legally protected title and indicates licensure, at least in the US. It requires the right degree(s) and several years of work supervised by a PE to qualify for that licensure. The importance of the PE license is that you are recognized as an authority in your field- for good or ill. You can make big decisions, but you will also be held accountable if something goes wrong.
In my experience, many software engineers brush aside the importance of those types of qualifications because their field wasn't quite as rigorous to enter. As we continue to develop a society where software mistakes can absolutely kill people (e.g. self-driving vehicles, robots, automated decision tools in medicine and insurance, etc) or cause massive economic damage, it's critical that we decide how software engineers play a role in preventing those things and how we hold them accountable when they don't.
Wow, that was a screed, (a worthy one) and yeah, an engineering degree should be special IMO, as perhaps a (pure) Math one. should also be. We have a tendency to regard you lesser, in self defense,, but that professional responsibility is significant, a more elegant weapon from a more civilized age. I do apologize,, the steam age thing was out of line (but meant with heart, trains rock, and IMO is where 'engineering' started) has it's roots.
As a software developer who also has a background in civil engineering and an EIT, I rue the fact that NCEES got rid of the software engineering PE exam before I had a chance to take it.
Any shaved ape can code. One thing that distinguishes worthwhile coding from crap is adherence to engineering principles. Nitpicking about the semantics of the word "engineer" avoids the incontrovertible fact that empirically derived principles and best practices exist and that software engineering is a thing.
Coincidentally, my MSc is in mathematics and statistics, after a dual BSc in math and physics, so we're from similar starting points. My education as a software engineer and later as a systems architect only came once I began coding. There's a considerable body of empirical knowledge in the literature (along with too much irreproducible fluffy bullshit), but in my experience, the general awareness of that knowledge is worse among the newer generation of coders than older ones. I suspect that's because they generally assume that the toolchain and processes do it for them.
The widespread adoption of Scrum has been another source of knowledge loss: it's used in a number of situations where it does more harm than good, and even where it could succeed, it's often misapplied (partially because some agile principles are impossible to implement in most real-life organizations, so misapplication is the only posssible kind of application). There are times when architecture and design matter greatly, and some agile practicioners seem to actually believe that they can be done on the fly or major shortcuts can be taken. "We're not doing waterfall!" You know what? I've been in the business since before some of those fools were born, and I've never done a waterfall project. It was already an anti-pattern in Fred Brooks's 1970 magnum opus. Agile vs waterfall was always a false dichotomy. It's just that some of the OG agile people were too ignorant to know that, or too self-interested to admit it.
I was doing a code review this week. There was nothing wrong with the code in terms of structure or performance, but it was doing this really weird operation with an ID after DB insert. I asked about it and the author was like "yeah, that's weird; I don't know why the AI did that. I'll remove it." My dude, I know you can write good code. Don't be lazy!
There was nothing wrong with the code in terms of structure or performance, but it was doing this really weird operation with an ID after DB insert
So there was plenty wrong with the code.
And it hasn't been fixed.
"Bro, its totally just you prompted it wrong"
Yeah these interaction are becoming quite fraught because there is extreme danger of AI use just shifting the burden from one person to another. That guy wrote the code super fast with AI, but you had to do an additional round trip during code review with him to eliminate that weirdness. He gets a bonus for doing twice the work in half the time, you get nothing.
blame your leadership
he’s not getting paid for good code
i dont understand that. i use ai for help reading through old stuff or to help me remember how tondo a thing i havent done in two years but blindly copy pasting blows my mind.
Same. I also code up about 50% of stuff so all the structure is there, effectively as guardrails, before using AI. Then prompting it instructions that are effectively the solution, so it doesn't come up with its own.
Then, read through it all, replace things that could've been done better, and test.
On average it's maybe 15-20% quicker than manually coding the whole lot. Try skip any of those steps and the chances of it blowing out increase to the point I just end up doing it all anyway and it's taken twice as long because of it.
It's alarming when people don't even check.
If the AI generates code in place, you don't have to copy and paste anything. They'd have to do a self-review to spot such an issue. And then notice and act upon it.
I suspect it's the same people that blindly copied stackoverflow code without understanding it. Which is likely where the LLMs are getting most of its answers from in the first place.
I worked with a guy that 100% used AI to dev everything. didn't even check to see if it would work before submitting a MR.
It got to the point that I stopped reviewing them and just rejected them outright with a simple comment, "doesn't work".
eventually he was fired. the evidence? the four months of shitty MRs he opened. the best part was, when I said "doesn't work", I was never wrong. none of his changes worked.
You only have to snorkel through the mile of shit if you let the shit-pipe in in the first place.
I mean, the pull requests will arrive.
Especially if they are security related, even if only 5% are anything, that's still quite a few actual bugs. 😞
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.
It's a great tool... and it's only getting better.
But more importantly, it's not going away. You can hate it until the sun explodes but this technology exists now and the world isn't just going to forget about it. Your best bet is to figure out how to use it efficiently so that you don't end up the guy that pushes shitty AI code and instead the guy who was able to get a lot done by using AI in a meaningful way and produce good work
Amen!
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.
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.
Yep... I'm leaving the industry after 20+ years because of this industry hellscape
If I got an AI-written codebase hard to navigate, I'd bill the AI usage it took to clean it up and, on top of it, the hours I have to put to actually do the job. We can definitely use AI to write good code, but it takes the kind of professional criteria that vibe coding lacks in order to do that.