Scaling AI agents across large teams requires more than just tools; it demands a shift in mindset. By focusing on a shared framework for delegation and verification, organizations can turn individual productivity gains into scalable, AI-native engineering excellence.
Giving thousands of software engineers access to agentic tooling is straightforward. Helping them fundamentally change how they build software is another matter entirely; one every engineering organization eventually runs into. The real constraint on enterprise agentic engineering is not model power, rather, it is an organization’s ability to build new skills, establish shared expectations, and create a common language for human-agent collaboration.
Left on their own, engineers do exactly what you would expect, but not all in the same way. Across an engineering organization spanning thousands of engineers, different patterns emerge. Some engineers experiment immediately, building their own workflows and standards as soon as new tools appear, which is often where the biggest productivity gains surface first. However, without a shared vision and explicit expectations from leadership, that experimentation stays local and can lead to inconsistent practices, competing definitions of “good,” and no path from individual gains to organization-wide ones.
Salesforce faced this directly. The question was never whether our engineers could shift to agentic coding; most already had. The real challenge was building the shared language needed so individual bursts of productivity could compound into productivity at scale. Salesforce’s Technology, People, Innovation, and Learning (TPIL) team took on that challenge: helping an entire engineering organization, not just its early movers, learn and grow together.
When software engineers receive a powerful new capability, they naturally incorporate it into their own workflows. One engineer develops a prompting strategy that accelerates coding. Another focuses on testing, debugging, or documentation. Others discover completely different ways to integrate agents into planning, code reviews, or daily engineering work. None of those approaches are wrong. They are exactly what experienced engineers should do when exploring new technology.
TPIL realized the organization was not struggling because engineers lacked curiosity. The challenge was that experimentation alone was not creating a shared understanding of what effective agentic coding actually looked like. Many engineers were still asking the same questions:
From the beginning, TPIL treated one reality as non-negotiable: engineers do not all learn the same way. Some immediately build production systems. Others prefer examples, structured guidance, or repeated practice before changing how they work. Sustainable organizational change depends on meeting engineers where they are and helping them build confidence as they progress. That principle shaped every design decision Salesforce made in approaching this next phase of agentic transformation. At its core, this was an organizational learning challenge, not a technology one.
Recognizing the agentic transformation as an enablement challenge raised another question. If becoming AI-native was not a single skill to master, what did the journey actually look like? TPIL was not the only team asking. Different pockets of the organization had already started answering it in their own way. One team built a five-level model that broke out orchestration from looping. Another team focused on a 2×2 model which centered on telemetry. What each model ultimately revealed was that everyone was describing a version of the same underlying journey.
Despite working on different products and technologies, engineers consistently described the same breakthroughs, frustrations, and periods of uncertainty. They advanced through similar stages and plateaued in similar places, a pattern we captured in this recent blog on the Agent Coding Maturity Curve. No single model told the whole story, but together they pointed at the same thing.
TPIL combined that convergence with its own learning strategy to build the Proficiency Level (PL) Framework, deliberately grounded in mindset and behavior, not tools or dashboards. That distinction was the whole point. A framework built around any single tool, IDE, or product would only describe how to use that tool well; the moment the tooling changed, the model would need to be rebuilt. Instead, the PL Framework gave the organization a shared language for how to think and behave differently with agentic tooling: how to delegate, verify, and collaborate with agents as a capability rather than a feature of one product. Master that mindset once, and it travels with you to whatever tool comes next.
What it gave engineers and managers, above all, was a shared definition of “good.” A common answer to what strong agentic work actually looks like at each stage, in place of dozens of competing, tool-specific ones.
Designing the PL Framework solved only part of the problem. The larger challenge was helping engineers progress from one level to the next.
One of the most important mindset shifts involved validation. Many software engineers quickly discover that generating code with AI is easier than judging its quality. Outputs are not always correct. Requirements are not always interpreted as intended. Small mistakes can quietly produce unreliable software. This is where many agentic adoption efforts stall. The challenge is learning how to communicate intent, evaluate agent outputs, and build reliable engineering workflows around them. Learning to write code with agents is only part of the shift; the deeper change is how engineers think about software development itself.
As engineers continue progressing, they shift from using agents to complete individual tasks toward orchestrating systems of agents. Each stage introduces a new mental model, reinforcing that becoming AI-native depends on continuous capability development rather than isolated technical skills. For engineering leaders, that progression carries an important implication: success is measured by whether engineers are consistently developing the judgment, confidence, and capabilities needed to reach the next stage, not by how quickly they reach the final one.
A shared definition of “good” pointed engineers in the right direction, but direction alone does not move anyone through levels like these. TPIL built hands-on programs that made progression something engineers experienced, not just understood. AI camps gave engineers dedicated time to practice and experiment rather than just hearing about agentic tooling. Weekly sessions met engineers wherever they were starting from, then evolved as their questions did. Coaching guides gave managers a common language to move a one-on-one conversation from “are you good at AI?” to “what is the next stage of growth?,” turning progression into something managers could actively support rather than simply measure.
What turned the PL Framework from a model into an enablement practice was that combination: a framework that defined the destination and programs that helped engineers actually travel it. The four levels below are what that practice looked like in action.
The nine stages on the Agentic Coding Maturity Curve were accurate, but accuracy was not the problem TPIL needed to solve. Nine stages give a detailed picture, but they are a lot to hold in mind day to day. Change management and learning research consistently point to the same practical limit: four or five steps is about the most someone can act on at once.
TPIL built the PL Framework around four steps: a clear and progressive path with a beginning, an end, and a manageable number of stops in between. Each level does not tell an engineer which feature to reach for next; instead, it tells them which skill, mindset, or behavior to shift.
The four proficiency levels were designed to make growth visible, not to evaluate engineers. This was never meant to be a scoring system, a dashboard, or a telemetry-driven measure of who was “ahead”; it was a shared language for describing how an engineer’s thinking and workflow were changing. Growth was something engineers and managers talked about together, not something a tool measured for them.
What mattered at each level was not what engineers knew, but how their behavior actually changed.
Rather than focusing on attendance or course completion, TPIL looked for evidence that engineering behavior across the organization was actually changing.
Countless engineers participated in AI camps globally during the first quarter and adopted AI tools faster than the organizational baseline. Volume and speed did not prove behavior changed, but they provided TPIL with a large enough population to start tracking whether it did.
The clearer signal came from how the questions themselves changed. Weekly session attendance naturally declined as participants moved beyond foundational topics. The questions shifted with them, moving from how to get better outputs from AI to where human judgment still mattered most. That shift suggested that engineers were not just using agents more; they were thinking about the work differently.
Every engineering organization pursuing enterprise AI adoption will encounter similar challenges, regardless of the AI models or tools they choose. Salesforce’s experience offers four principles that extend well beyond any single framework.
Every engineering organization will have access to increasingly powerful AI models. Not every organization will become AI-native. The difference is not the technology, it is how effectively an organization helps its engineers learn, adapt, and grow together.
Learn More
The post How Salesforce Built an Agentic Engineering Enablement Strategy for Thousands of Software Engineers appeared first on Salesforce Engineering Blog.
Continue reading on the original blog to support the author
Read full articleScaling localization for global software is a major bottleneck. This approach replaces manual workflows with a multi-stage AI orchestration pipeline, maintaining quality across 34 languages while reducing costs by up to 90% and handling massive volume growth without extending release windows.
Manual bug triage at scale is slow and inconsistent. By combining custom ML with LLMs, teams can automate complex engineering judgments, preserving institutional knowledge while reducing months of manual effort to days, significantly accelerating product quality improvements.
This approach transforms tribal knowledge from code reviews into executable system requirements. By automating feedback loops and multi-tier evaluations, engineers can reduce repetitive manual reviews and ensure AI-generated artifacts consistently meet organizational standards.
As AI agents accelerate code production, traditional manual review becomes a bottleneck. Engineers must pivot from writing code to architecting automated verification systems, ensuring high-velocity output doesn't compromise system reliability, security, or maintainability.
