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
2. The productivity gains of 30% are probably overstated, in a likely effort to try and sell their AI products
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.
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.
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.
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.
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.
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.
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.
At my job, our main repo is over 300k lines of just Ruby code, plus a bunch of JS, ERB templates, and other stuff. Every AI tool I've thrown at it is great at making surgical edits to single files (or small groups of files) but completely chokes if you ask it a question that requires it to understand context across the repo. I'm always hoping that I'm just using the tools wrong, but so far that doesn't seem to be the case.
Pretty old trick.