In May, Srinivas Tallapragada shared what happened when Salesforce Engineering went agentic. This is the story of how we scaled that work across 15,000 engineers.

It’s one thing to talk about agentic coding on a greenfield side project. It’s a different problem entirely to do it across a business running production systems for hundreds of thousands of customers, where every deployment touches revenue and trust. Doing this at our scale is a powerful demonstration of what’s possible.

The numbers continue to accelerate. Work items completed per developer are up 90.5% in July year over year. Pull requests merged per developer are up 88.1%. Effective Output — our machine learning–based productivity score developed with Stanford University — is up 200.3%. (This score is assigned to every commit after a machine learning model automatically reviews the code the way a panel of senior engineers would, delivering expert-level judgment on quality, complexity, and effort, to truly measure the value of the code, not just the volume.) As impressive as those figures are, it’s more important to focus on the operating model behind them. That’s where I think the real learning is for most organizations navigating this shift.

The culture that made it possible

Before we rolled out a single tool, Salesforce already had something invaluable: an engineering culture where the default response to a missing capability is to build it — and then share it.

For example, as we scaled agentic workflows, engineers needed a way to manage fleets of agents — tracking progress, keeping autonomous sessions on track, catching issues without constant monitoring. No vendor offered exactly what they needed. So a group of engineers built their own orchestration layer and distributed it across the entire organization. We didn’t prescribe it. We didn’t fund it through a special program. The culture did it. And this was not a one-off.

That behavior — identify the gap, build the solution, share it broadly — is what separates an organization that adopts an AI tool from one that transforms around it to compound productivity gains. Without it, adoption stalls at the team level and never multiplies. We let a thousand flowers bloom. Teams across the organization experimented with different approaches, but we were also disciplined about quickly identifying which ones made sense to scale and standardize. That balance between bottom-up innovation and top-down curation is what let us create the right tools and skills fast. And that build-it, share-it instinct is why teams didn’t standardize on a single tool. Options like the AI Expert Suite and Dev Bar exist because engineers needed the flexibility to move between tools and models as the work demanded, which turned out to be good preparation for the model diversification we’ll get to later. 

The pilot-to-scale playbook

We didn’t start by flipping a switch for 15,000 engineers. We started smaller, deliberately.

A 30-day pilot, back in March. Roughly 44 teams across 10 different product clouds. Over 200 engineers, chosen to represent the full complexity of Salesforce systems — greenfield codebases alongside deeply interconnected legacy systems, high-velocity teams alongside maintenance teams, early AI adopters alongside skeptics. Use cases spanning innovation, migration, and ongoing maintenance work.

The pilot’s job wasn’t to prove that Claude Code worked (and today we have additional tools to choose from). It was to prove that it could be trusted across the full complexity of what we actually build and operate: production-grade, mission-critical systems at enterprise scale. That confidence became the basis for everything that followed.

Beyond validating the tools, the 30 days were about discovering where the friction lived — in the workflows, in the human habits, in the cross-functional dependencies that an accelerated inner loop would eventually expose. A technology proof of concept answers, “Does this work?” An organizational one answers, “Can we absorb this change at speed?” For us, the second question turned out to be the more important one. 

Once the pilot established trust, we moved fast. Enablement ran jointly with Anthropic. Leaders reinforced the message at every meeting, not as a campaign but as a genuine operating expectation. We used a “champions” structure to scale learnings laterally across teams, rather than waiting for a center of excellence to push knowledge downward. We featured internal spotlights and examples regularly.

The ambition was enterprisewide transformation, enabling new capabilities that weren’t possible before for the business and for customers. So we gave every engineering team a new challenge: Achieve exponential productivity in 90 days. Not refine the pipeline. Reimagine it. The target was deliberately sized so that reaching it required rethinking how software is built, not augmenting what already existed.

A hard deadline also serves as a diagnostic. Teams that fell short weren’t failing but revealing the real bottlenecks: the cross-functional dependencies, approval chains, and process overhead that an accelerated inner loop suddenly made visible. Those gaps became the agenda for the next phase.

The maturity curve that redefined adoption

Scaling transformation across thousands of engineers requires a shared language for where people actually are, not just whether they’re using the tools but how deeply.

To help us articulate that, we built the Agent Coding Maturity Curve — nine stages, from basic code generation to fully trusted autonomous operation — and distributed it across the engineering organization. The goal was to move the entire engineering population to stage 6 and beyond, where individual gains translate into measured customer outcomes.

Open Image Modal

Image Modal

Binary adoption metrics tell you who has the tool. They don’t tell you whether engineers are using it to write a function or orchestrate an autonomous agent across a multiservice migration. Those are categorically different things, and the difference shows up in productivity data.

The curve also changed how managers coach. Instead of asking if engineers are using AI, the conversation becomes “Where are you on the curve, and what would move you to the next stage?” (Caitlin Mann took a deeper look at how we built this enablement strategy at scale.) That’s a concrete, actionable conversation. It surfaces the specific behaviors that separate stage 3 from stage 6 — not just tool familiarity but context quality, task decomposition skill, the willingness to delegate full ownership of a workflow to an agent.

That wasn’t an easy sell at first. Plenty of engineers were skeptical, worried this was a curve that would keep moving, where someone would always be stuck at the bottom no matter how much they improved. Getting past that required a real cultural shift, helping people see the curve as a shared map for the whole organization’s progress, not a permanent ranking of any individual.

The shared vocabulary for what “good” looks like mattered as much as the specific stages. I’d be curious whether others have built something similar and what they’ve learned.

Cost discipline as engineering discipline at scale

Ultimately, we treated token optimization as an engineering discipline, and one insight in particular drove our thinking: Over-contexting degrades quality, not just budget. It’s tempting to assume that giving a model more context can only help — more information, better decisions. In practice, we found the opposite past a certain point. Every wasted token carries three costs. Financially, you’re paying for tokens that add no value. On latency, larger context windows take longer to process, slowing down every interaction. And on accuracy, longer inputs dilute a model’s focus. Even when the extra information is technically relevant, it can crowd out the signal that actually matters to the task at hand.

The engineers who learned to manage context well didn’t just spend less. They got better results, faster. The incentives turned out to be perfectly aligned.

We now think about six levers of context discipline:

1. Context hygiene: Knowing when to /clear, /compact, or /branch based on whether the session history is still useful. Treating context like working memory, not a transcript.
2. Skill libraries: Building out global skills, local skills, and team-specific skills so common workflows don’t re-derive context and instructions from scratch every time. 
3. Model selection: Defaulting routine work to more cost-efficient models. Treating the most-capable models as an explicit choice for genuinely hard problems.
4. Effort calibration: Reserving higher-effort modes for ambiguity, complexity, and high-stakes decisions. Not applying maximum effort to every task.
5. Tool selection: Using focused retrieval tools like CodeSearch MCP rather than broad context dumps that load noise along with signal.
6. Task decomposition: Using subagents and effective execution plans to split complex work into parallel focused threads, each with its own scoped context.

Auto-compaction alone — context windows automatically compacting at 200,000 tokens — drove a 24.8% reduction in all-engineering spend, sustained over three weeks. Smart model defaults saved $864,000 in the first week. In selective cases, optimized prompting modes reduced tokens by 70% or more with no measurable quality drop.

The broader principle: Model diversification is now a first-class engineering concern. The landscape is moving fast enough that we don’t think any organization can afford to build infrastructure that assumes one model or one provider indefinitely. Building the harness (the routing logic, skill infrastructure, and context management practices) allows the underlying model to swap as the market evolves. While we believe this is the right posture, it’s an area where we’re still learning.

What stays true

The specific tools and models will keep changing faster than any article can keep up. What we think matters more is the sequence:

Build the foundation before you scale. A codebase that’s agent-ready. CLAUDE.md files. Accessible institutional knowledge. Observable workflows. A starting library of reusable skills so teams don’t build from scratch. All treated like code.

Prove it works across your real systems. A pilot designed around your real complexity, not a clean demo environment. The confidence that comes from that is what enables the speed that follows.

Set an exponential target. Not because you’re certain you’ll hit it but because it forces the reimagination that incremental targets don’t. Use the gaps as diagnostics.

Build a shared language for depth. Adoption metrics tell you who has the tools. Maturity frameworks tell you whether transformation is actually happening.

Treat cost discipline as engineering discipline. The right tokens for the right outcome. Infrastructure that can move as the landscape moves.

Invest in the culture throughout. The engineers who build what doesn’t exist and share it are the ones who compound the advantage — not any particular tool.

That’s what we’ve learned so far. I’d genuinely like to hear how others are approaching this — what’s working, what isn’t, and where the real friction lives in your organizations.

The frontier keeps moving. So do we.

Read more:

• Pioneering the agentic shift within Salesforce Engineering
• How we got our engineers to use AI — without breaking everything
• Eight design principles for the Agentic Enterprise

This article may include references to services or features that are still in development and are unreleased. Customers should make their purchase decision based on fully released and available features.