4 ms·
1. Salesforce will continue to hire engineers 2. The productivity gains of 30% are probably overstated, in a likely effort to try and sell their AI products
by darth_avocado 2y ago
1. Salesforce will continue to hire engineers
2. The productivity gains of 30% are probably overstated, in a likely effort to try and sell their AI products
- jmward01 2y agoThis looked a lot more like marketing than reality. If there was an article on 31 Dec 2025 that said 'Salesforce didn't hire any software engineers in 2025' I would probably have more interest in it.
- 93po 2y agoas another poster pointed out, they have 104 job listings for software developers right now, so yeah. this article is just an ad.
- riku_iki 2y ago> The productivity gains of 30% are probably overstated it maybe not, LLMs deliver clear value in coding tasks, but the thing is that competitors also will have gains, deliver more features, fixes and products.
- darth_avocado 2y agoI am yet to have Google, Microsoft, Amazon or Facebook suggest that they’ve achieved 30% productivity gains from AI. Those are companies at the forefront of AI investment and if they haven’t achieved that kind of increased engineering productivity, I am ready to bet money on the fact that any other company claiming so hasn’t either. Even if 30% productivity gains are true, they are probably not because of AI. They could have fired a bunch of low performers and overworked the rest of the engineers to achieve productivity gains, but even then, I’d be very skeptical if the 30% gains would stay there long term.
- riku_iki 2y agoIt depends on vertical. Large corps likely have some huge codebases of overengineered spagetti code, which are hardly comprehendable by LLMs. But if you want to build for example some new/smaller web/mobile apps talking to various API, LLM can boost your productivity significantly, because it will easily generate ready to use code snippets.
- darth_avocado 2y agoBut, we are talking about Salesforce.
- taurath 2y agoBut the second those smaller prototype apps become big enough to need to scale or be maintained, you’re back at the same problem. The whole thing it gets you then is “faster experimentation”, which was something that was /already fast/ if you use modern tools of the day. 1 week vs 2 weeks for a prototype app may build you more prototypes but it doesn’t help when you can’t scale them. It does smooth some of the processes though - AI is maybe helpful for cognitive augmentation for coders, but it’s not going to be building you apps worth a damn.
- spac 2y agowhile I agree with the sentiment that it's hard to evaluate the real gains, it's definitely not just about code generation. Debugging is a a big part of the value, IMO.
- mullingitover 2y ago> Large corps likely have some huge codebases of overengineered spagetti code, which are hardly comprehendable by LLMs. I think it's the other way around, though. Those code monstrosities aren't comprehendible by humans, especially after the wanton RIFs that have happened in the past couple years that have cut loose a lot of people who know where the bodies are buried. However, with copilot you can just figuratively walk up to any repo and ask "@workspace what's going on in this codebase" and it'll tell you. From experience I can say this can deliver results. Downright rotten code that would've taken me a good week to figure out can be figured out in an hour. It's damn near witchcraft.
- bee_rider 2y ago“I’m not just the president.” Pause. “I’m a client too.” Pretty old trick.
- wankerrific 2y agoYep. He’s a member
- actuallyalys 2y ago> The productivity gains of 30% are probably overstated I am doubtful as well. I could imagine 30 percent among certain engineers for certain tasks, especially if you use a popular language with popular libraries and frameworks that are well-represented in the training dataset. I don’t know how typical of a codebase Salesforce has. They could also finetune a model on their own codebase or devote a small team of engineers to figuring out which prompts, models, etc. work best for their codebase and process. In theory, those advantages could boost it beyond what testing would typically show. But a consistent increase of “more than” 30 percent across the whole engineering workforce seems less plausible, especially lacking details on how they measured that and uptake numbers. Edited to add: Are they even confident that their engineers are using it consistently? At this scale, that’s not a given. I’d be interested to know whether Salesforce customers have noticed a change in the number or scope of features being announced. A change of this size seems like it should be noticeable from the outside. I’d like to hear from the engineers in particular.
- scherlock 2y agoSalesforce core is Java. A smattering of other languages in the mix. I left Salesforce a year ago, their main developer productivity drains had nothing to do with the code base. It's their build process where it takes a minimum of a day to get code committed, even with their git on top of perforce hack which is seriously impressive, but still a process smell, that coupled with massive overhead from when dealing with inter team dependencies and various "edicts" getting passed down from on high that blow up any planning. In short, you could have agents that code at 2x but it would have only a small impact on deliverabkes since non-coding processes have a higher impact on velocity.
- actuallyalys 2y agoThanks for the insight! That makes me even more doubtful of the 30 percent claim.
- Jach 2y agoI left in 2020 before a bunch of the new dev processes were made and enforced, from what I've heard since the replacements aren't better and at least half sounded insane. Wouldn't surprise me if core teams have lost more than 30% productivity... not to mention all the low morale. AI can maybe claw some back, especially if it helps long-term quality; I'd try to be optimistic on it at least helping get fast "unit" test coverage that doesn't need the world running to execute.