Nearshore Salesforce teams with AI agents: what changes

Nearshore Salesforce teams with AI agents produce more code per developer, and that moves the bottleneck to review. For a manufacturer the planning number becomes reviewer capacity with knowledge of your org and processes, not developer headcount. Onboarding gets faster at reading an unknown org but can skip the judgement a reviewer needs later. And every rotation in the team becomes an access event: tool accounts, org access and local agent transcripts have to be cleaned up per person. The rules from my nearshore article still hold; agents make breaking them more expensive.

What changes for nearshore Salesforce teams with AI agents?

In my article on nearshore team size I describe what slows nearshore teams down more often than missing skills: rotation, turnover, overly senior teams and missing backing from the client. Coding agents such as Claude Code, Codex, Copilot or Agentforce Vibes remove none of them. They move the pressure to review, to the mix of roles, to onboarding and to access.

The cap of about eight developers per team and a minimum stay agreed before the first sprint stay as they are. The pod model with architect, builder-reviewer and domain lead is covered in AI-native delivery: smaller Salesforce teams. Here the focus is on a team that sits in another country and another company.

Why does review become the bottleneck?

McKinsey surveyed 334 product and engineering leaders and sums it up: “Speed is improving faster than quality” (Beyond the copilot1). The 2025 DORA report2 warns that without strong testing, version control and fast feedback, “an increase in change volume leads to instability”. Veracode measured the security pass rate3 of raw AI-generated code in July 2026, including Java, the closest relative of Apex.

11.8 %

average time savings

6.2 %

less rework

56 %

security pass rate for raw AI-generated code

30 %

security pass rate for Java

In a nearshore team this lands on very few people. The mix I recommend, a few seniors who carry architecture and reviews plus developers who like to build, works at human writing speed. With agents, the same few seniors face more and larger pull requests. If they wave them through, defects reach your integration sandbox. If they check properly, the speed gain turns into waiting time. With a team in India the working day also starts hours before yours, so a pull request that needs your architect waits until Germany is online. This is what I would set up:

• Two review stages. A senior in the nearshore team reviews every pull request first, using the checks in reviewing AI-generated Salesforce code. Changes to shared objects, sharing, the data model or interfaces also need your code owner. GitHub requests code owners automatically4 when a pull request touches their files, and branch protection can make their approval mandatory. The object ownership matrix defines which objects are shared.
• Reviewer hours in the contract. A partner paid per head gains from adding developers, and with agents an extra developer mostly lengthens the review queue.
• Small pull requests with the agent’s plan attached. The plan answers the question a reviewer would otherwise ask across the time zone.
• Triage by risk. McKinsey recommends that higher-risk changes “require stronger evidence and accountable human review”: customer-facing behaviour, regulated data, security-sensitive code. For a machine builder, warranty rules, prices and anything that posts to SAP go to your reviewer; a label change in the dealer portal does not.

Steering an agent means more checking than typing

A developer who steers an agent spends more time describing, checking and correcting than typing. Salesforce describes this for its own engineers in four proficiency levels5: AI-Assisted, AI-Validating, AI-Orchestrating and AI-Native. At the second level, “Engineers shift from trusting AI output to validating it.”

I would use that grid when a partner proposes a nearshore team: for each person, which level, and which agent pull requests have they reviewed? At least the seniors who carry reviews should be at the validating level before agents write code for production.

Domain knowledge is the second shift. An agent knows Apex and Flow. It does not know, for example, whether the warranty start date is reliable for machines sold through dealers, or whether one plant maintains spare part numbers differently. A nearshore team was always far from that knowledge, and with agents a wrong assumption turns into working code within hours. That makes the domain lead on your side even more important. Whatever the team learns about your org goes into the AI rules file in your repository, so it survives the next rotation.

How does onboarding change with agents?

Agents shorten the first weeks. A new developer can let the agent read the metadata in a sandbox and explain which flows, triggers and validation rules run on Work Order before changing anything.

The risk is that the new person never builds a reviewer’s understanding. In an Anthropic study6 from January 2026, 52 mostly junior engineers learned an unfamiliar Python library. The group with an AI assistant scored 50 percent on a follow-up quiz, the group without 67 percent, with the largest gap in debugging, and was not significantly faster. Participants who asked conceptual questions or had generated code explained scored around 65 to 86 percent, those who handed coding or debugging to the AI below 40 percent. The sample is small, and the authors expect a larger effect with agentic tools.

For a nearshore team that matters because today’s juniors are the reviewers you need after the next rotation. If they spend their first months delegating, nobody can replace a senior who leaves.

So I would build onboarding around explanation: the agent explains existing automation, the new person writes the test, and reviews of other people’s agent pull requests start in the first month. A four-week plan is in chapter 9 of my AI masterclass. About 38 percent of McKinsey’s respondents name lack of time to learn as a top barrier, so I would put the onboarding days into the nearshore plan and agree who pays for them.

Which access rules apply when nearshore developers use agents?

Tools, model routes, data classes and no production access belong in the contract, see partners coding with AI: what belongs in the contract. For nearshore teams three points get sharper, because people change.

Settings the developer cannot change. According to the permissions documentation7, Claude Code’s managed settings cannot be overridden by user or project settings. That is where deny rules such as Read(./.env) and disableBypassPermissionsMode, which prevents sessions without approval prompts, belong. Agentforce Vibes can be disabled per org8 under Setup, Agentforce Vibes Extensions, which I would do for production. The local Salesforce DX MCP Server only reaches explicitly allowlisted orgs9; its end of life is covered here.

Rotation is an access event. Claude Code keeps session transcripts in plaintext under ~/.claude/projects/ for 30 days by default, according to Anthropic’s data usage page10. When a developer leaves, their laptop holds what the agent read. The offboarding checklist per person removes the tool account, org access and allowlist entry, and the partner confirms that local transcripts with your code are deleted.

No real data in agent context. Service cases with customer names, serial numbers and dealer prices stay out, wherever the developer sits. Where prompts are processed depends on the model route; Anthropic’s own API offers only “us” and “global” as inference regions11. For your in-house staff the works council comes in, see AI coding tools, works council and GDPR.

Worked example: the field service stream with a nearshore team

Assume a machine builder with Service Cloud, Field Service, a dealer portal and SAP. A nearshore partner carries the field service stream with seven developers and one senior who reviews; the client has an architect and an admin. The partner introduces coding agents. All numbers are assumptions.

• Before agents: about 25 pull requests per sprint, first review within a working day.
• After four sprints: about 40 larger pull requests per sprint. The median wait for a review rises to three days, and the client architect sees more changes to Work Order and Asset, which the service stream also uses.
• Decisions: a second partner reviewer billed as reviewer hours, CODEOWNERS for Work Order, Asset and the SAP interface, and a size limit per pull request.
• Rotation in month five: the offboarding checklist runs within a day, and the replacement starts with two weeks of explanation tasks on the work order automation.

Whether the stream got faster stays open until cycle time and rework are compared with the baseline, see measuring AI productivity in Salesforce projects. The extra developer the partner offered first would only have lengthened the queue.

Count reviewers per team

1. Count reviewers per team, not only developers, and check their backlog.
2. Ask the partner for the agent level per person.
3. Set up code owners for shared objects, sharing, data model and interfaces.
4. Put managed settings, org allowlists and the offboarding checklist in place before agents write code.
5. Plan onboarding time and agree who pays.
6. Measure cycle time and rework before and after.

For point 1, a look at the open pull requests and how long they wait for a review on average is enough. Planning team setups, reviewer capacity and rotation rules is part of my programme management for nearshore teams.

Sources11

1. 1Beyond the copilot (opens in a new tab)mckinsey.com
2. 22025 DORA report (opens in a new tab)cloud.google.com
3. 3security pass rate (opens in a new tab)veracode.com
4. 4requests code owners automatically (opens in a new tab)docs.github.com
5. 5four proficiency levels (opens in a new tab)engineering.salesforce.com
6. 6Anthropic study (opens in a new tab)anthropic.com
7. 7permissions documentation (opens in a new tab)code.claude.com
8. 8disabled per org (opens in a new tab)developer.salesforce.com
9. 9explicitly allowlisted orgs (opens in a new tab)developer.salesforce.com
10. 10Anthropic’s data usage page (opens in a new tab)code.claude.com
11. 11inference regions (opens in a new tab)platform.claude.com