How Salesforce doubled effective coding output with Claude Code

Salesforce CTO Muralidhar Krishnaprasad says nearly every new application or user experience shown at Dreamforce probably had some influence from Claude. Asked what the company could ship that was previously out of reach, he points to Claudeforce and the work needed to make Salesforce applications accessible without relying on their usual interfaces.

Salesforce has existed for decades, and not every part of its products had an API, a way for software to interact with it. Krishnaprasad estimates that examining setup pages and filling the gaps across the applications could have taken six months to a year. Instead, he says the team reached 80–90% API coverage across its clouds in less than a few months, without meetings across the teams. The striking part, he adds, was changing decades-old code rather than starting fresh.

Boris Cherny asks how Salesforce measures the return on faster work. Krishnaprasad says counting lines of code is inadequate: someone could add comments without making the software more useful. Salesforce worked with Stanford researchers on an “effective output” score that gives more weight to changing logic or creating something new than to comments and simple edits.

The company also looks at dollars per unit of effective output. Krishnaprasad says the output measure has doubled and that Salesforce is now looking for suitable measures in other functions, such as the number of cases handled. It compares results before and after workflow or organizational changes alongside AI token consumption, then asks whether a missing improvement reflects the way a tool is used or whether the tool is simply wrong for the job.

Salesforce uses Claude Code across much of its software development process, Krishnaprasad says. To make that use more systematic, the company worked on an agent maturity curve: many engineers were still asking for small, low-level tasks rather than making agents work on their behalf. In a month or two, he says, a large share moved to more advanced levels, with output rising and quality higher rather than twice as many bugs.

Richard Pack explains that people often begin by issuing a short instruction without describing what a good result looks like. That can work on simple jobs but fail on longer ones. The next steps include making a comprehensive plan, using teams of agents and smaller delegated agents, splitting work across isolated copies of the code, and eventually automating more of the workflow.

In one example of that progression, an agent could pick up a failed automated test, investigate and fix it; another could review and merge the change. Krishnaprasad says thousands of people are now in this autonomous mode. A major challenge was teaching people that the more advanced levels represented a different way of working, rather than just a competition over a score.

The adoption effort relied on inspiration and real data. Pack says people demonstrated their own ways of working by solving problems live and sharing the results. Krishnaprasad adds that teams produced actual products in weeks that might otherwise have taken months, giving colleagues concrete evidence that the approach could help.

One architect told Krishnaprasad that understanding unfamiliar code normally took several days and conversations with three or four teams. Having agents help her understand it removed those meetings. He also describes growing interest in using agents during incidents, when engineers spend considerable time finding the information needed to respond.

Each team now has incident-resolution agents, Krishnaprasad says. In one Slack incident he followed, the service initially paged was only the outer layer: the actual problem was in an inner service. The agent identified the cause and the responsible team, paged that team and supplied a contact. He says the alternative could have involved waking nine teams in succession.

Salesforce also built a place to share the reusable instructions, or skills, that teams were producing. Pack says the idea grew into a marketplace with evaluations: the team can replay sessions with and without a skill, or ask Claude to suggest changes that use fewer tokens or reach a conclusion faster. The aim is to show whether a shared skill actually improves an outcome.

The shared system covers more than coding: it helps teams see which parts of software development they are automating and design workflows at company, team and smaller group levels. Salesforce has thousands of repositories. Pack says helping an engineer fix a bug anywhere requires a way to identify the relevant repositories and interfaces, then work in unfamiliar code and produce a quality proposed change.

Cherny describes the pattern as allowing innovation from the bottom up and scaling it when it works, then asks about safeguards. Pack says quality is central: teams need to evaluate capabilities scientifically in different contexts, understand what a skill’s creators expect it to achieve and check whether other developers actually get that value.

Krishnaprasad says Salesforce nearly doubled its code volume during the recent push to move faster, but did not see bugs or customer cases double with it. On average, he says, bugs per unit of generated code fell. He credits checks and balances, including both traditional mechanisms and new ones, for maintaining quality as output rose.

Asked how others might measure this, the Salesforce team says its starting point is consistently labeled tickets linked to proposed code changes. Pack’s team also built a benchmark set from past work. Salesforce can replay those tasks with a new model or skill to compare results and cost before deciding what the change is worth.

The benchmarks include short and long tasks across product development, as well as tasks that models have repeatedly failed. When a new model begins passing those persistent failures, Krishnaprasad says, that can be a reason to adopt it: the company can identify capabilities it was previously unable to use.

Cherny asks Pack what evidence he requires before trusting an agent. Pack starts with objective criteria for good and bad outcomes. For example, if the task is to create a new schema, a negative test might check whether the agent changed an existing schema or broke something else. Rather than simply ask the agent to review itself, he asks it to find the relevant features and show the evidence and sources in a matrix; if it cannot, it goes back to work.

For task size, Pack generally prefers a larger bundle of features to a collection of tiny jobs: the setup for a very small task may not be worth the effort. He works with the model or its surrounding tools to break a larger assignment into isolated pieces. A job that takes only a few minutes can remain an interactive session; other work he accumulates. Krishnaprasad adds that better planning at the outset produces more and better output.

Asked about a rollout mistake, Krishnaprasad says teams need the right model for the length and complexity of each job at the right price. People had used powerful models to generate ordinary files that did not require them. Choosing the model well matters to the return on the work.

Pack recalls a product bug whose cause the team could not find after several investigations. They assigned Claude Opus to debug the code, make changes, compile and continue investigating. After 24 hours, he says, it found the problem and proposed a fix. Because the business software is critical to customers and a wrong answer could affect finances, he emphasizes validating that a small bug fix does not create a larger, equally elusive bug.

For CTOs, Krishnaprasad advises being bold while allowing innovation from both leadership and the teams doing the work, with safeguards and a learning environment for sharing. Pack tells engineers to dig in: he has been able to work through a backlog quickly and understand teams’ code changes in ways he had not thought possible. He sees plenty left to discover and learn.