How the Salesforce Engineering Organization Became Truly Agentic

A few months ago, I wrote about the hard work of getting thousands of engineers to actually use AI - not just adopt it in name, but embed it meaningfully into how they work. We built the governance scaffolding, the measurement infrastructure, and the workflows to make it real. We crossed 90% adoption. That felt like a milestone.

It turns out, that was just the beginning.

Today, Salesforce Engineering isn't just using AI. We're running on it. We've moved from a world where AI was a helpful copilot to one where agentic tools are driving the software development lifecycle (SDLC) itself - writing code, reviewing pull requests (PRs), generating tests, updating documentation, managing deployments, and increasingly coordinating work that used to require significant human handoff. The change has been sharper and faster than anything I've seen in my career.

Here's what that shift actually looks like, what drove it, and what it's teaching us.

Going all in on Claude Code

The biggest inflection point was a deliberate, organization-wide pivot to Claude Code as our primary AI agent tool. We rolled it out to all of our engineers. Then we did something that sent an even clearer signal: we removed all token limits. Our primary directive was to remove every last piece of friction between our engineers and the tools that make them faster and more effective.

The results are showing up in the data. In April 2026, work items completed per developer are up 50.8% compared with April 2025. PRs merged per developer are up 79%. And most importantly, when we measure the true value of code delivered - not just the volume - using a machine learning-based Effective Output score, we're seeing that output has grown 151.3% year over year.

What Agentic Transformation actually looks like

Numbers tell part of the story. But one example from our Agentforce Commerce team tells it better.

The team faced a migration of 33 API endpoints to a new cloud-native architecture - the kind of task that, done the traditional way, would drain roughly 231 person-days, or seven per API. Manual schema mapping, manual testing, and manual documentation create massive friction, stalling momentum and trapping entire engineering teams in months of low-leverage toil.

They did it in 13 days. Eighteen times faster.

Productivity and quality are often framed as a tradeoff. We're not seeing that tradeoff.

Here's how: The team built a rule-based framework using Claude - markdown files combined with reference implementations - to standardize the AI-automated migration. Every round of PR feedback got incorporated back into the rule set, so accuracy improved continuously and outputs arrived near production-ready. They let autonomous large language model loops run (build, fix, validate) without manual intervention and parallelized migrations across isolated environments to generate multiple PRs simultaneously. Thirty-three endpoints. Five PRs. The largest single PR delivered 21 endpoints with 100% test coverage.

That's not a productivity gain. That's a different way of building software.

More output, better quality - at the same time

The skeptic's question when you push AI this hard is, what breaks?

Engineering 360, a platform that centralizes engineering data from hundreds of systems to track security, availability, quality, and developer productivity, has a clear answer: Quality went up. In April 2026, customer-facing incidents per merged PR dropped 47.1% compared with April 2025. Bugs with associated customer cases per PR fell 46.7%.

This matters because productivity and quality are often framed as a tradeoff. We're not seeing that tradeoff. Trust is our #1 value, and our engineers are investing their AI superpowers to meet our highest quality standards and nonfunctional requirements. For example, we have embedded security guardrails and quality standards structurally into the agentic workflow. When agentic tools get applied properly, quality doesn't suffer from speed. It benefits from it.

Rethinking the SDLC

Four months ago, we learned that AI had to fit into existing workflows for engineers to adopt it. Now that they've adopted it, they're using AI to completely tear down and rebuild those same workflows.

Our engineers are fundamentally rethinking how they practice the SDLC. What processes can be removed entirely? What handoffs are unnecessary? Where are humans still doing work that an agent can own? Those are the questions that unlock real productivity - not marginal improvement. And it definitely doesn't look like what we had before, with AI bolted on.

Skills, subagents, and the new engineering craft

One of the most interesting developments has been watching engineers become builders of their own agentic workflows, not just users of tools. Claude Code skills - packaged, reusable capabilities that encode team context, naming conventions, and workflow patterns - have become a new form of engineering artifact. Teams are building them, sharing them, and compounding on each other's work.

This is a different kind of engineering craft. The most important skill today is knowing how to structure problems for an agentic system.

We have also built an AI Expert Suite and the Salesforce Foundation Plugins, a curated, institutionalized library of AI skills built specifically for Salesforce engineering workflows, giving every developer a shared foundation of proven capabilities to build from rather than starting from scratch. Our internal benchmark shows clear evidence that the curated skills improve accuracy and reliability on Salesforce-specific coding tasks while reducing unnecessary cost.

Subagents and agent teams - scoped AI agents that handle parallel workstreams within a larger task, often as a team - are changing how complex work gets decomposed. An engineer no longer has to context-switch across five systems to move a single task forward. They describe the outcome, and a set of coordinated agents figures out the steps.

This is a different kind of engineering craft. The most important skill today is knowing how to structure problems for an agentic system, when to delegate versus stay in the loop, and how to build reusable patterns your team can compound on.

What we're still figuring out

A few things are still genuinely hard.

Context management in long, complex agentic sessions remains a craft that engineers are actively learning. The quality of CLAUDE.md files - the persistent context configurations that orient Claude to your codebase, conventions, and constraints - varies widely across teams, and that variance matters a lot for output quality.

And security in an agentic world requires a fundamentally different model. When agents can act on your systems - not just suggest - the blast radius of a misconfigured tool is bigger. We're investing hard in securing the agentic SDLC end to end.

Role evolution is real and worth taking seriously. When agents handle more of the execution layer, how do junior engineers grow into senior engineers if AI is absorbing much of the entry-level work? What is the role of a designer or product manager in this new world? Our unit of execution used to be a scrum team. How will this change? Is it the same for infrastructure layers like our security layer versus our products? We're experimenting with one-person units or three-person units, but these are still early experiments. We don't have clear answers yet, but the teams thinking about these issues proactively will come out ahead.

The direction is clear

When I wrote my original piece, I said the goal was to build a foundation. We built it. Now we're building on it - fast.

The engineering organization of the future doesn't look like the organization of today with AI bolted on. It looks fundamentally different. The Agentforce Commerce team didn't just go faster - they changed what was economically possible. That's what we're scaling across our entire engineering organization.
Our aim is to build the most automated, agentic SDLC in the industry, and these posts are a progress report on our way. Please feel free to share your journey as practitioners and operators.

Dive deeper