AI-native delivery: smaller Salesforce teams
AI-native delivery shrinks a Salesforce team to small pods: an architect, a builder-reviewer who steers the coding agents, and a domain lead from the business. For a manufacturer the larger change sits on its own side, not with the partner. Each pod needs someone from service, sales or after-sales who decides on the process every day and accepts working software in a daily demo. Short intents replace long specifications, and a named person owns every artifact. If your organisation cannot release those people, smaller partner teams will not make the programme faster.
What is AI-native delivery?
AI-native delivery means designing the whole delivery lifecycle around AI agents rather than adding a coding assistant to the old process. The clearest description for Salesforce comes from a practitioner, not a study: Amit Chaudhary’s ApexHours article1 of 19 October 2026. In his framework agents draft, build, test and document, while people “set intent and guardrails, review output, own the outcome”. He calls the alternative “the old process with faster typing”.
The framework has five building blocks that matter for programme organisation:
- Intents instead of specifications. An intent is an outcome-first requirement: the expected outcome, why it matters, the users affected, constraints and guardrails, and success criteria.
- Small pods instead of a pyramid. “Swap the big pyramid of junior developers for small pods: an architect, a builder-reviewer and a domain or BA lead.”
- A daily demo instead of a status stand-up. The team shows the product owner working software built since the day before.
- Named ownership. “A named human owns every artifact.” Agents work only in allowlisted sandboxes and scratch orgs, never in production.
- The same gates for everyone. PMD, Code Analyzer and ApexGuru run in CI for human and agent code alike.
I don’t agree with every number or every step in this framework, but it points in the right direction. And no template fits every customer one to one.
Why do Salesforce teams get smaller?
McKinsey surveyed 334 product and engineering leaders in May 2026 and published the results in Beyond the copilot2 in August.
79%
of respondents at top-accelerating organisations report smaller squads
7
people per squad there at the median, down from about ten
50 to 80%
shorter development cycles, reported by one global technology company
That technology company moved from product pods of 8 to 10 people to agentic teams of 4 to 6 and reported roughly twice the capacity. McKinsey sees two role families emerging: “definers who fuse product and design, and builders who fuse development, testing, and operations”.
Two caveats from the same source. The figures are self-reported by leaders, and 30 percent of respondents said team productivity fell. McKinsey also writes that “Speed is improving faster than quality”. DORA’s 2025 report found that AI adoption still has a negative relationship with delivery stability3, and DORA lists working in small batches and a user-centric focus4 among the seven capabilities that amplify AI’s benefit. Small pods with daily feedback are a direct answer to both points. How to check whether your own programme gets faster is the topic of measuring AI productivity in Salesforce projects.
In the programme organisation the business side becomes the bottleneck
The business side becomes the bottleneck
In a classic programme the business writes requirements, then waits weeks for UAT. In a pod, the domain lead looks at working software every day and decides on the spot. For a machine builder that means a warranty specialist from after-sales, a dispatcher from field service or someone from dealer sales who may decide on their process. In my judgement this person needs around half of their time for the pod. Heads of service rarely plan for that, and it is the first thing I would negotiate before any partner proposal.
Intents replace most of the specification
A good intent for a dealer portal story fits on half a page: dealers see the delivery date of their spare part order without calling, measured by fewer phone enquiries; constraints are dealer-specific prices and sharing by account. McKinsey adds that specifications should be clear enough “for an agent to act on”, which I read as testable acceptance criteria, not as more prose. Two things keep a precise specification: interfaces to SAP or proALPHA, because the ERP team works on its own release plan, and rules with financial effect such as warranty eligibility or price approval.
Status meetings turn into demos
The daily demo replaces the stand-up and much of the steering report. A steering committee that sees the warranty claim form working in the sandbox needs fewer traffic lights. McKinsey lists two-day sprints as an illustrative marker. I would not copy that while SAP transports move in fixed windows; a short cycle in Salesforce with a release rhythm that matches the ERP works better.
Ownership has to be written down
With fewer people, each one carries more knowledge, and an agent owns nothing. The named owner per artifact fits the object ownership matrix I use when several partners share one org: one team owns each object, one person owns each Flow, class and agent. The pipeline gates come on top, see quality gates for AI code in the Salesforce pipeline.
Worked example: from one large partner team to three pods
Assume a machine builder with Sales Cloud, Service Cloud, Field Service and an SAP integration. Its partner works with a classic team of twelve: one architect, one project lead, two business analysts, six developers (four of them junior) and two testers. All numbers here are assumptions to show the method. Three streams are planned: warranty claims from dealers, spare part ordering in the dealer portal, and field service work orders with spare part reservations.
The partner proposes three pods. Each pod gets an architect and a builder-reviewer from the partner; one platform and DevOps engineer serves all three. That is seven partner people, down from twelve. The domain leads come from the manufacturer: a warranty specialist, a dealer sales coordinator and a field service dispatcher, each at about half time, so 1.5 full-time equivalents the business did not give before.
Three decisions make or break this setup:
- No domain lead, no pod. If the head of service cannot release the dispatcher, the field service pod waits. Without daily acceptance it builds on guesses, and the demo becomes a show for the partner.
- One lead architect across the pods. Three pod architects would each design their own Account and Asset model. I would keep data model, sharing and the SAP interface with one architect on the client side.
- Formal testing stays where SAP posts. Warranty credit notes go to SAP, so that stream keeps an end-to-end test before each release. The portal stream releases after daily acceptance.
Whether seven people deliver what twelve did is an open question until cycle times are measured. The partner’s price for the new setup belongs in the commercial model, see fixed price vs time and materials.
Where does the pod model not fit yet?
- Streams dominated by waiting. If most of a story’s lead time is spent waiting for the SAP team or a middleware change, a faster Salesforce pod changes little.
- Businesses that cannot release people. Without daily decisions from service or sales, a classic team with a product owner and planned UAT is the safer setup. Its developers can still use coding agents.
- Teams without a working pipeline. Pods push more changes per day. Without version control, automated tests and validation deploys, the faster pace mostly produces faster defects.
- Thin seniority at the partner. A pod has no juniors who learn on the side. If the builder-reviewer leaves, a large share of the knowledge leaves with them. Minimum staffing periods matter even more than in the setup I describe in why I cap nearshore teams at eight developers, and what changes for nearshore teams working with agents is covered in nearshore Salesforce teams with AI agents.
Pick one stream with a clear process
- 01
Pick one stream
With a clear process, a decision maker in the business and few ERP dependencies. Dealer portal stories are often a good fit.
- 02
Name the domain lead first
Get the time approved by their manager before the partner restructures.
- 03
Write intents
For the first ten stories with testable acceptance criteria; keep precise specifications for interfaces and rules with financial effect.
- 04
Agree the guardrails
With the partner: named owner per artifact, agents only in sandboxes and scratch orgs, the same gates for all code. The contract side is in partners coding with AI: contract rules.
- 05
Measure and decide
Measure cycle time and rework, and only then decide on the other streams.
The ten intents from the third step are also the yardstick for the measurement after three months. Planning streams, team setups and the business time behind them is the core of my programme management for Salesforce programmes.
Sources4
Frequently asked questions
What is AI-native delivery in Salesforce projects?
A delivery model built around coding agents from the start: agents draft stories, code, tests and runbooks, while people define the intent, review the output and own each artifact. Small pods replace the classic pyramid of many junior developers.
Do AI-native Salesforce teams really need fewer people?
The evidence points that way but is thin. McKinsey reports that 79 percent of respondents at top-accelerating organisations saw smaller squads, median from about ten to seven, in a self-reported survey. Measure your own cycle times before you cut a team.
Who should be the domain lead in a pod at a manufacturer?
Someone from the business who knows the process and may decide on it, for example a warranty specialist from after-sales or a dispatcher from field service. Plan around half of that person's time; without it, the pod builds on assumptions.
Does a daily demo replace user acceptance testing?
For most stories it replaces the long wait for UAT, because the domain lead accepts in the sandbox every day. Processes that post into SAP, such as credit notes for warranty claims, still need an end-to-end test before release.