this post was submitted on 27 Jun 2026
423 points (98.2% liked)
Technology
87780 readers
3532 users here now
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
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
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?