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.
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.
This is the first comment section i’ve seen on lemmy with a reasonable discussion about AI use that wasnt instantly downvoted into oblivion for being pro-AI
Usually this place is full of the “EVERYTHING IS SLOP” crowd without any nuance as to how it is being actually used to do small tasks well under the supervision of a qualified person.
This comment thread reads 100% like AI astroturfing. AI is not an amplifier, there’s literally no evidence from any study that’s been done that backs that. That’s just AI company marketing.
“AI sucks at X, but sometimes useful at Y… use with caution.” = astroturfing
“AI SUCKS AT LITERALLY EVERY TASK!!! ITS ALL SLOP!!! SLOP SLOP SLOPPITTY SLOP!!!” = only organic discussion and reasonable take…
Look, there are 100s of valid reasons why AI sucks and is unethical… in fact, it’s pretty much 100% built on unethical methods, no doubt…
But “AI sucks at everything and literally has zero good use cases” is not a real argument, but it seems to be the most popular opinion around here.
I disagree with 90% of the pro-AI stuff out there, i’m just pointing out that its rare to hear a reasonable discussin on the topic here that isnt just 100% hate
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.
There are different ways to go about “programming” - if you’re “just a programmer” that’s fine, you’re essentially doing window dressing for a department store, the world needs a lot of you. There are engineering aspects to software too, and if you let "just a programmer"s handle all of that, you will find out what they are lacking as soon as the engineering gets tested in use.
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.
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.
ultimately about critical thought and solving problems/achieving functionality with limited resources
I find in software engineering that the resources tend to be ample, it’s the capacity for critical thought that’s constrained. Predicting the users, predicting the future, predicting what users will do and want to do in the future… get that right and you’ve got the requirements for good software. Without good requirements, your software can build all kinds of fancy bridges to nowhere.
At one point, about 10 years after graduating with my Masters’ in Computer Engineering, I looked around about getting a PE license and the reality was: it had (and still has as far as I can tell) no value in the software field. I have a BS in EE, and if I wanted to start signing drawings for building electrical systems, a PE is just the thing for that. Around here, you need to apprentice under a PE for a time to get them to certify you as a PE, and the PEs we have aren’t in software, they wouldn’t know how to evaluate your software skills or professionalism. Reminds me of high school where they recognized that about 6 of the students knew far more about computer programming than the best (and only) teacher we had for it, so we were put in an “independent study” class to learn what we could from the equipment that various local businesses had donated to the school. Even as a practicing EE in the biomedical device design field, there was really no value to the PE license - for similar cultural reasons: the best biomedical engineers are in a different world from our existing PEs.
you will also be held accountable if something goes wrong.
I graduated before the internet. I had researched local companies the old fashioned way, and the first one I drove to to ask about a job, when I got there the parking lot was empty and there was a padlock and chain on the door. Guess I need to go to #2 on the list… turns out they (a pacemaker company) had been reprocessing faulty devices and shipping them with inadequate testing after rework, leading to the devices going bad shortly after surgical implant, requiring additional surgery for replacement. A whole chain of technicians, engineers, and executive management were culpable for the expense and risk they were causing for the users of their pacemakers. Other than the FDA shutting them down, there was a bunch of blow-hard talk about accountability, fines and jail time for management, but neither even came to a court hearing. Our system is, frankly, still very wild-west in terms of accountability for engineers in emerging fields.
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.
Agreed, but software has already had life-safety-critical and massively financially impactful roles in society for 50+ years now, and I see precious little progress toward formal accountability.
You clearly have a lot more experience than me- I’m fairly fresh out the gate. Like you, though, I work in a field where licensure isn’t super relevant (manufacturing).
It was drilled into my head in school and by my dad (cheme but does civil work and is on the committee that writes the cheme PE) that that for some domains, like civil and chem, it’s nigh impossible to find work without a PE (even entry level often requires at least the EIT accreditation).
Our system is, frankly, still very wild-west in terms of accountability for engineers in emerging fields.
It’s deeply unfortunate that your experience with the accountability side of things went the way it did. That’s another thing that they drilled into my head at school- if you sign a drawing and that park killed or hurt someone, the victims could call on you in a court of law to explain or even include you as a defendant in the suit. Does that always happen? Obviously not, but at least the possibly is there I guess.
Agreed, but software has already had life-safety-critical and massively financially impactful roles in society for 50+ years now, and I see precious little progress toward formal accountability.
Fully agreed here, I was just struggling to think of older life-critical examples after travelling for 22 hours lol (long day yesterday).
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.
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.
empirically derived principles and best practices exist and that software engineering is a thing.
The thing I find most vexing about “software engineering” is that the majority of it comes down to sociology/psychology more than it does science. People make mistakes. They mis-communicate, under-specify, assume, overlook, forget, and screw up.
Programmers practice somewhere between lawyers, authors and graphic artists, and other than the graphic art side of their endeavors, most people never “read” their product. The most valuable principles of software engineering have nothing to do with the complexity of sort algorithms, logic trees or other abstract concepts they were teaching in “computer science” back in the 1980s. The most valuable principles come down to: how do you manage the problems inherent in the situation of human beings writing a bunch of code that almost nobody ever sees which can be fraught with problems that almost nobody will detect until years after the original authors have all but forgotten what they did?
Bad & meh engineers get praised because they “waste” less time directing ai and reviewing output - barely working is good enough in the race to market.
I’ve seen things as serious as a privileged user for one customer having admin access to all customers being discovered during the last minute pentest literally days before the planned product launch. That product is supposed(and likely will) to move 250M USD for customers in the second half of this year. Under the current policy at my day job, coming all the way from the top, reviewing ai generated code at all should be an exception reserved for 0.1% most critical code. Yes, in finance.
I was working in a university town, happened to get hired in at decent market rates by a biomed startup that didn’t mind paying for me. When they left town, I stayed, and a precious few other companies would pay “my rate” - so I ended up cold calling on quite a few places just to see what they were about. I stumbled into the software development manager’s office of a company that did ATM and POS software - they used the same tech stack I was using for biomed. After a few minutes the manager stopped the conversation and said “sure, fine, I want you, but: can I afford you? What’s your current salary?” I told him, he laughed and said: “Well, I’m the highest paid software guy in the building and I don’t make half that. Mostly we hire kids from the Uni who think they want the experience, they turn over every few months on average. I’ve told management how bad that is for the quality of our software, they don’t care.”
The major difference is that payment processors and money transfer agents are heavily regulated and require a government issued license to operate. At least KYC is not yet handled by ai…
Hopefully, those are the sorts of companies that should fail or get sued, so they learn their lesson. Not holding my breath though.
Companies have been doing insane shit for the sake of saving a buck or getting to market fast for decades, it’s nothing new. AI may or may not just make it worse.
It comes down to risk-reward. If the risk is low enough, they take it - assuming the additional reward outweighs the consequences.
When your decision makers can just declare corporate bankruptcy when the risk finally happens, with no personal exposure other than loss of future income? You can bet they’ll take that risk every time.
The neck of the finance woods my employer is in is highly regulated.
Just failing to notify a regulator on time you blocked a transaction attempt involving a sanctioned individual means hundreds of thousands in fines per transaction (not up to, flat 6-digit fine) + potential prison time (can’t remember if it was up to 15 or 20 years)
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.
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.
This is the first comment section i’ve seen on lemmy with a reasonable discussion about AI use that wasnt instantly downvoted into oblivion for being pro-AI
Usually this place is full of the “EVERYTHING IS SLOP” crowd without any nuance as to how it is being actually used to do small tasks well under the supervision of a qualified person.
This comment thread reads 100% like AI astroturfing. AI is not an amplifier, there’s literally no evidence from any study that’s been done that backs that. That’s just AI company marketing.
“AI IS AMAZING AND INEVITABLE!!!” = astroturfing
“AI sucks at X, but sometimes useful at Y… use with caution.” = astroturfing
“AI SUCKS AT LITERALLY EVERY TASK!!! ITS ALL SLOP!!! SLOP SLOP SLOPPITTY SLOP!!!” = only organic discussion and reasonable take…
Look, there are 100s of valid reasons why AI sucks and is unethical… in fact, it’s pretty much 100% built on unethical methods, no doubt…
But “AI sucks at everything and literally has zero good use cases” is not a real argument, but it seems to be the most popular opinion around here.
I disagree with 90% of the pro-AI stuff out there, i’m just pointing out that its rare to hear a reasonable discussin on the topic here that isnt just 100% hate
And… there it is.
exactly; well said
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.
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.
There are different ways to go about “programming” - if you’re “just a programmer” that’s fine, you’re essentially doing window dressing for a department store, the world needs a lot of you. There are engineering aspects to software too, and if you let "just a programmer"s handle all of that, you will find out what they are lacking as soon as the engineering gets tested in use.
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.
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.
I didn’t know NCEES even entertained doing a software engineering license, interesting. When was that?
I find in software engineering that the resources tend to be ample, it’s the capacity for critical thought that’s constrained. Predicting the users, predicting the future, predicting what users will do and want to do in the future… get that right and you’ve got the requirements for good software. Without good requirements, your software can build all kinds of fancy bridges to nowhere.
At one point, about 10 years after graduating with my Masters’ in Computer Engineering, I looked around about getting a PE license and the reality was: it had (and still has as far as I can tell) no value in the software field. I have a BS in EE, and if I wanted to start signing drawings for building electrical systems, a PE is just the thing for that. Around here, you need to apprentice under a PE for a time to get them to certify you as a PE, and the PEs we have aren’t in software, they wouldn’t know how to evaluate your software skills or professionalism. Reminds me of high school where they recognized that about 6 of the students knew far more about computer programming than the best (and only) teacher we had for it, so we were put in an “independent study” class to learn what we could from the equipment that various local businesses had donated to the school. Even as a practicing EE in the biomedical device design field, there was really no value to the PE license - for similar cultural reasons: the best biomedical engineers are in a different world from our existing PEs.
I graduated before the internet. I had researched local companies the old fashioned way, and the first one I drove to to ask about a job, when I got there the parking lot was empty and there was a padlock and chain on the door. Guess I need to go to #2 on the list… turns out they (a pacemaker company) had been reprocessing faulty devices and shipping them with inadequate testing after rework, leading to the devices going bad shortly after surgical implant, requiring additional surgery for replacement. A whole chain of technicians, engineers, and executive management were culpable for the expense and risk they were causing for the users of their pacemakers. Other than the FDA shutting them down, there was a bunch of blow-hard talk about accountability, fines and jail time for management, but neither even came to a court hearing. Our system is, frankly, still very wild-west in terms of accountability for engineers in emerging fields.
Agreed, but software has already had life-safety-critical and massively financially impactful roles in society for 50+ years now, and I see precious little progress toward formal accountability.
You clearly have a lot more experience than me- I’m fairly fresh out the gate. Like you, though, I work in a field where licensure isn’t super relevant (manufacturing).
It was drilled into my head in school and by my dad (cheme but does civil work and is on the committee that writes the cheme PE) that that for some domains, like civil and chem, it’s nigh impossible to find work without a PE (even entry level often requires at least the EIT accreditation).
It’s deeply unfortunate that your experience with the accountability side of things went the way it did. That’s another thing that they drilled into my head at school- if you sign a drawing and that park killed or hurt someone, the victims could call on you in a court of law to explain or even include you as a defendant in the suit. Does that always happen? Obviously not, but at least the possibly is there I guess.
Fully agreed here, I was just struggling to think of older life-critical examples after travelling for 22 hours lol (long day yesterday).
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.
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.
The thing I find most vexing about “software engineering” is that the majority of it comes down to sociology/psychology more than it does science. People make mistakes. They mis-communicate, under-specify, assume, overlook, forget, and screw up.
Programmers practice somewhere between lawyers, authors and graphic artists, and other than the graphic art side of their endeavors, most people never “read” their product. The most valuable principles of software engineering have nothing to do with the complexity of sort algorithms, logic trees or other abstract concepts they were teaching in “computer science” back in the 1980s. The most valuable principles come down to: how do you manage the problems inherent in the situation of human beings writing a bunch of code that almost nobody ever sees which can be fraught with problems that almost nobody will detect until years after the original authors have all but forgotten what they did?
Bad & meh engineers get praised because they “waste” less time directing ai and reviewing output - barely working is good enough in the race to market.
I’ve seen things as serious as a privileged user for one customer having admin access to all customers being discovered during the last minute pentest literally days before the planned product launch. That product is supposed(and likely will) to move 250M USD for customers in the second half of this year. Under the current policy at my day job, coming all the way from the top, reviewing ai generated code at all should be an exception reserved for 0.1% most critical code. Yes, in finance.
Finance software is astoundlingly sloppy.
I was working in a university town, happened to get hired in at decent market rates by a biomed startup that didn’t mind paying for me. When they left town, I stayed, and a precious few other companies would pay “my rate” - so I ended up cold calling on quite a few places just to see what they were about. I stumbled into the software development manager’s office of a company that did ATM and POS software - they used the same tech stack I was using for biomed. After a few minutes the manager stopped the conversation and said “sure, fine, I want you, but: can I afford you? What’s your current salary?” I told him, he laughed and said: “Well, I’m the highest paid software guy in the building and I don’t make half that. Mostly we hire kids from the Uni who think they want the experience, they turn over every few months on average. I’ve told management how bad that is for the quality of our software, they don’t care.”
The major difference is that payment processors and money transfer agents are heavily regulated and require a government issued license to operate. At least KYC is not yet handled by ai…
Insane stuff.
Hopefully, those are the sorts of companies that should fail or get sued, so they learn their lesson. Not holding my breath though.
Companies have been doing insane shit for the sake of saving a buck or getting to market fast for decades, it’s nothing new. AI may or may not just make it worse.
It comes down to risk-reward. If the risk is low enough, they take it - assuming the additional reward outweighs the consequences.
When your decision makers can just declare corporate bankruptcy when the risk finally happens, with no personal exposure other than loss of future income? You can bet they’ll take that risk every time.
The neck of the finance woods my employer is in is highly regulated.
Just failing to notify a regulator on time you blocked a transaction attempt involving a sanctioned individual means hundreds of thousands in fines per transaction (not up to, flat 6-digit fine) + potential prison time (can’t remember if it was up to 15 or 20 years)