alt Hacker News> Its different, in that when you teach that engineer, they either leave because now they hate you, or they grow.
Or they just have their own hubris and ignore your (provably better) suggestions because their way is "better/easier/how we've always done things".
And then you end up with someone sprinkling N+1 issues throughout the system and making systems with bad architectures throughout the years, not thinking about backpressure etc., as well as shoving ALL the dependencies into a single codebase cause they're not used to creating new ones, turning patches into eventual month long version upgrades because everything keeps breaking with anything newer than JDK 8 and some of the packages are deprecated and gahhhh I should pick up woodworking as a hobby.
Though, to address the original claim:
>> If it is a better engineer than you... You need practice.
This feels like a thought terminating cliche. Like, it will spit out bullshit every now and then, and make assumptions that I don't think that many engineers would (e.g. since a lot of each app is environment-specific), but at the same time when you guide it and give it examples, it can really be quite good! So not that unlike humans at all, even competent devs might not necessarily know about every pattern in any given codebase, especially when one has been around for 10 years and grown quite a bit.
It can be quite good if you have something like ArchUnit or your own tools for linting project architecture and patterns, alongside proper documentation that doesn't assume that you're a team member with X years of experience on system Y. AI just forces people to be less lazy and ignorant about knowledge transfer, which they should have also been for the sake of other humans!
I have never had it be every now and then. It is always bullshit, the first time around. Usually followed by, "You ignored the first three rules, and all the examples, try again."
I have worked with some amazingly incompetent devs. Some promoted into place to become someone else's problem, and some parachuted in through connections, and never once have they brought the continuous and unevolving frustration of modern LLMs.
I taught one of our "React SME"s, what Typescript even was. And they, were less likely to throw a ten thousand line fix, where twenty would do. They didn't see that the DB had a list of validation rules, and copy and paste those into seven different files, instead of just querying the DB, so the code would be kept up to date. And whilst I might have had to repeat that the DD is our source of truth, they never argued that implementing the DD wasn't aligned to the intended design.
AI isn't forcing people to be better with knowledge transfer. It's taking conversations that happened in person, that were back and forth and gave both people a better understanding of a thing, and turning it into a half-assed and out-of-date wiki. Without all the things that make a wiki actually useful to onboard the next newcomer.
I do get what some of these frustrations are, and where they come from. I'm the official documentation maintainer, because nobody else ever wrote anything down on expectations. Its fairly thankless. But... All I've seen AI do in that same realm, is exacerbate misunderstanding.
Like when it presented an Apex script (Salesforce) guaranteed to exceed governor limits to our junior, who took it and ran with it. And when it aborted, the AI spent half a day leading the junior around and telling them to change config settings - that the environment was the problem, not the code.
The fix? Toss the three layers of Queueables, and use Database.insert on a list. Job done. PR for 150LoC, instead of the offered 780LoC.
(As a complete aside, can anyone convince Salesforce to fix the documentation for: https://developer.salesforce.com/docs/atlas.en-us.apexcode.m...)