How Salesforce Scaled Engineering AI Adoption Without Stifling Innovation

By Paul Constantinides, Anubhav Dhoot and Jackie Chambers de Freitas

Salesforce’s Hyperforce Runtime Platform (HRP) engineers were already experimenting with AI. But promising capabilities remained scattered across teams, overlapping efforts competed for limited resources, and tight delivery commitments left little room for another initiative. Scaling AI adoption demanded shared practices; preserving innovation demanded team freedom. How could adoption spread without forcing a single workflow or becoming another burden on delivery? The organization needed to turn individual experiments into capabilities that could be distributed, maintained, and measured across approximately 500 engineers in roughly 70 to 80 HRP scrum teams.

Explore how Salesforce’s HRP organization made team-level AI breakthroughs available and scalable across the organization without stifling experimentation or innovation, and turned delivery bottlenecks into reasons to adopt.

Assign clear ownership in a federated AI adoption model

Opening development to more teams created an ownership problem. Who would meet the delivery date, establish quality criteria, and support a skill after release? A federated model could increase engineering capacity, but more contributors did not automatically create accountability for delivery and ongoing operation.

The team started with the foundation of an AI Steering Committee within the organization to guide and recommend AI practices and adoption. During the initial months, five contributors quickly established the HRPDX (HRP Developer Excellence) plugin, a shared Claude Code plugin that distributed AI instructions and skills to teams, providing a foundation and shared practices as an AI paved path. Teams were required to adopt.

With teams already committed to tight delivery timelines, the AI Steering Committee needed to expand participation by drawing on problems scrum teams were already working to solve. That foundation enabled AI capabilities to be contributed from the roughly 70 to 80 HRP scrum teams in the organization. Teams signed up to do the work because they wanted to resolve their own pain points, and their AI solutions could help others facing similar problems. As an example, in one release, approximately 30 AI workstreams were identified to be implemented. The delivery teams volunteered to solve and deliver on these workstreams, which were all generated organically from current friction points.

How the program is set-up for clear ownership and delivery?

As Delivery Teams signed up for these AI capabilities delivery, the engineering managers and their teams were assigned responsibility for end-to-end delivery through their scrum processes, including deadlines and ongoing operation. If a team built a skill, it owned supporting it. Architects defined technical guidance, quality gates, and acceptance criteria. The AI Steering Committee focused on reducing duplication, presenting new AI tools, governance, standards, adoption metrics, demos, community, and validating problems and goals for scalability.

AI Champions connected that structure to the team experience. They brought guidance into scrums, carried feedback back to the AI Steering Committee, and supported AI adoption across the organization through training, mentoring, community, and demos. Engineering managers and delivery owners provided workstream status updates through regular AI Champions sync points, giving distributed work a shared forum for reporting progress and AI capability adoption. As innovation happens fast, the AI champions meet weekly to showcase new capabilities that can then be adopted widely.

Scale AI tooling distribution while preserving team choice: The HRP AI Innovation Loop

Initially, useful AI work was happening across HRP teams but its benefits were staying local. One engineer built a prompt library; another team created a one-off script, skills or agents. Teams were tackling overlapping problems while resources were already committed to other initiatives. More experimentation alone would not spread the value of those solutions.

This became the catalyst that enabled the AI Steering Committee to create a model that would help shape the AI scaling initiatives that encourage teams to deliver AI capabilities to solve their own pain points, standardize how these capabilities reach teams, receive updates, and measured adoption as teams choose to use them.

Developers needed a shared foundation they could extend while retaining the tools and workflows that suited their work. It started with the HRPDX plugin, a shared Claude Code plugin that distributes AI instructions and skills to developers, to provide that foundation. It supplied baseline guidance through Claude and agentic instruction files, alongside default skills for coding and pull request reviews.

HRP AI Innovation Loop connects strategy to execution and provides the feedback loop for future ideas through metrics.

The contribution process remained open. Engineers could build capabilities for their own needs, and solutions applicable to multiple teams could enter the program for broader scalability, distribution, and measurement. The team also showcased team-specific solutions, so engineers could contribute without the pressure of proving their idea would serve the entire organization. This created an environment of open innovation: all solutions were welcomed, demoed and celebrated, even if not applicable for scalability.

This visibility helped connect AI efforts across the organization. When a smaller capability had the potential to fit within a larger workstream, the teams were encouraged to partner, generating a multiplier effect. Local experimentation and awareness of various capabilities could become part of a broader scalable solution, reducing the need for teams to keep building independently.

Use SDLC and DORA metrics to guide AI adoption decisions

The team leveraged current data pipelines to expose software development life cycle (SDLC) and DORA metrics across HRP teams at the scrum and portfolio levels. Managers could examine the inner loop of local development, pull request cycle time, the outer loop of delivery beyond the local environment, and reliability measures. That gave teams a basis for choosing capabilities relevant to their bottlenecks. To reduce dependence on work-item hygiene, the team added pull request-based measurements. Lead time for changes followed code from the first commit to the first successful deployment. Alongside deployment frequency and change failure rate, this extended the delivery view beyond a work item’s recorded status.

Those measurements helped guide the initial focus on the developer’s local environment. Its bounded context gave the team more control over the tooling it could provide. Access to Claude helped get the effort moving, while shared instructions and skills gave developers a starting point they could extend. The pipeline metrics let the team compare delivery from March through May against June through August timeframe, and drill into results across the teams and managers.

The team also built and used a Claude skill to query the pipeline and generate new reports that gave a consolidated view into the team’s delivery and productivity metrics.

Across the org, with teams AI adoption near 100%, the teams reported a 26% throughput gains and a 32% inner-loop improvement within the first three months. The cycle time dropped from 22 days to 11 days, the Sprint Forecast ratio increased from 66% to 90%, which meant that teams were delivering 90% of their committed priorities sprint to sprint, a 36% increase. All this was achieved while teams sustained a code maintainability score of 6.04, which was an acceptable and steady pace and quality. Overall, the teams saw increases in productivity and return of AI investment immediately sprint to sprint.

Teams produce more, increase innovation, and solutions scale across the organization to exponentially increase the benefits.

Automate AI tool distribution and track usage

AI tools work well when paired with the right skills. A skill could address the right problem and still require developers to install and maintain it. Repeating that work for every new skill would add friction between a team’s contribution and broader adoption. Across approximately 500 engineers, distribution needed an engineering mechanism of its own. With the HRPDX plugin, engineering teams install the HRPDX plugin once and the session-start hooks updates when new versions become available, removing the need for manual updates.

The same mechanism carries Git and pull request conventions, deployment awareness, and skills such as Flight Plan, which helps engineers plan implementation work before generating code. With 97% plugin adoption across the HRP organization, the team can make capabilities available without asking every engineer to install each one separately. AI Spec-driven development was quickly planned as the next addition through the same distribution path.

Automatic distribution removed installation work, but uptake varied by capability. The team reported 95% adoption of Prizm, Salesforce’s internal AI code-review tool that analyzes pull requests and posts findings directly on the PR. Adoption of the shared Claude instruction file was lagging, and the team was using the program’s processes to increase it. These differences reinforced the need to measure availability and usage separately. Plugin adoption establishes the distribution foundation. Tracking skill usage and delivery metrics helps the team examine which capabilities teams apply and what changes after those capabilities arrive.

Extend AI adoption into code review, testing, and deployment

Higher local output from HRP engineers exposed constraints further downstream. Engineers were producing more code, but pull request review cycles were getting longer. Production delivery depended on reviews from other teams. Faster generation increased pressure on stages outside the engineer’s direct control.

To relieve that pressure, engineers shifted the detection of anti-patterns and SME-level code review into the inner loop using team-specific Prizm skills. These skills flag common anti-patterns and apply the standards and judgment that senior reviewers typically bring during review, so every PR gets an expert SME-level review and feedback. Catching issues at this stage avoids rework, shortens review cycles, and keeps defects from surfacing later in testing and deployment. The teams also built HourGlass, a skill that analyzes a team’s PR cycle time to find bottlenecks and provides actionable recommendations on how to reduce it.

Addressing those dependencies meant working across team boundaries. The team looked at whether partner teams who gate approvals could adopt capabilities such as Flight Plan and the shared Claude guidance. Tooling was one part of the effort; approval processes were another. Internal change approval optimizations were also implemented in this time period, and the teams expected outer-loop cycle time improvements as well, hence reducing the overall PR cycle time.

The measurement also expanded to give quality and reliability more attention. The team broadened its use of DORA metrics, including deployment frequency, lead time for changes, change failure rate, and time to resolution. The goal was to understand what percentage of production changes failed and how quickly problems were resolved. Those concerns shaped the next workstreams: testing capabilities, including customer user journey generation, and examining the use of LLMs as judges in testing. The adoption effort was expanding into the work required to review, test, deploy, and operate the resulting code.

Sustain AI adoption via a paved path to continuously solve engineering bottlenecks

Distributing a plugin did not establish that every capability was being used or that every delivery constraint was improving. Teams continued to face different bottlenecks, and progress in one stage exposed limitations in another. Sustaining AI adoption across HRP required an ongoing connection between those problems and the capabilities available to address them, hence the creation of an AI paved path with measurements to validate its effectiveness.

The AI paved path model keeps the connection and the feedback loop continuously running. Teams identify pain points and contribute solutions, named owners deliver and support them, and the HRPDX plugin makes applicable capabilities available more broadly, faster and automatically. Delivery metrics help teams choose what to adopt next and examine what changes. As new constraints emerge, they shape the next contributions. The principle stays consistent: standardize distribution, preserve team choice, and make ownership explicit. Adoption becomes part of engineering work because it starts with a problem engineers already needed to solve.

Next up: the introduction of an AI teammate on each scrum team. One that will sign up to work by picking up stories and use these paved-path skills to help teams raise productivity and own their outcomes.