3 ms·

> The productivity gains of 30% are probably overstated I am doubtful as well. I could imagine 30 percent among certain engineers for certain tasks, especial

> 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 ago
Salesforce 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 ago
  Thanks for the insight! That makes me even more doubtful of the 30 percent claim.
- Jach 2y ago
  I 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.
throwaway743950 2y ago
There may also be engineers working harder because of being worried about getting laid off. How could they separate those productivity increases from AI?

scherlock 2y ago

Salesforce 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 ago
Thanks for the insight! That makes me even more doubtful of the 30 percent claim.
Jach 2y ago
I 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.

throwaway743950 2y ago

There may also be engineers working harder because of being worried about getting laid off. How could they separate those productivity increases from AI?