AI is changing how Salesforce projects get built. It’s reasonable for clients to expect that to bring the price down. If the work takes less time, why should it cost the same?

The catch is how much work remains after AI produces something that looks finished. Someone has to check its assumptions, test the exceptions, confirm permissions and make sure the change works with everything already in the org.

That validation can take longer than expected and eat into the time saved building. AI can be useful without delivering the dramatic reduction in project costs clients are hoping for.

A faster draft is not a finished change

A Salesforce rollout includes requirements, data model decisions, permissions, data migration, integrations, regression testing, user acceptance testing, training, adoption and the maintenance that follows.

AI can help with plenty of that: summarizing discovery notes, flagging likely duplicate records, drafting test scenarios. But each piece still needs someone to decide whether the result is right for this org, these users and this data.

There’s also a basic budgeting problem. If building takes 30% of a project’s hours and AI cuts that phase by 40%, the saving from that change alone is 12% of total hours, assuming everything else stays the same.

Those are hypothetical numbers, not research findings. But they show why a large improvement in one part of a project produces a smaller improvement across the whole thing. AI may help in other phases too. Those savings need to be measured rather than assumed.

And hours aren’t dollars. Saving development time while adding senior architecture and review time does not necessarily reduce the bill by the same proportion.

Other people are identifying the same problem

The sources below do not establish a Salesforce implementation savings percentage. They do explain why generating work faster and delivering it for less money are different questions.

At DORA, Jessica Baolin and Nathen Harvey analyzed 1,110 open-ended responses from Google engineers collected in the third quarter of 2025. A recurring theme was that time saved creating code was often spent auditing and verifying it. They describe this as a verification tax.

They also identify the burden placed on reviewers when developers can produce large changes quickly. DORA’s broader 2025 research found that higher AI adoption was associated with both greater delivery throughput and greater delivery instability. Teams were delivering more, but that did not automatically mean smoother delivery.

That is an association, not proof that AI causes instability or increases project costs. It is still a reason to look beyond how quickly the code gets written.

Salesforce’s own engineering team describes a related problem. In “Why AI-Generated Code Is Easy but Engineering Trust Is Hard,” Nakul Pandey explains how an AI-generated change can pass its build, tests and review while resting on a misunderstood requirement.

The code and the tests can agree with each other and still be wrong for the business.

His team’s response included explicit specifications, plans supported by evidence from the existing codebase, and independent review. That is one engineering team’s account rather than a controlled study, but the practical lesson applies: someone has to establish what correct means before a passing test proves anything useful.

Then there’s the question of whether people can accurately judge the time they save.

In its early-2025 study, METR found that 16 experienced open-source developers took about 19% longer across 246 tasks when using the AI tools available at the time. The developers believed the tools had made them faster.

That finding needs its qualification. METR’s February 2026 update, by Joel Becker and colleagues, says newer tools are likely helping developers more. Selection effects and difficulties measuring time prevented a dependable estimate of the current benefit.

I would not use the 19% figure to estimate a Salesforce project today. I would use the study as a warning against treating a feeling of productivity as a measured saving.

Salesforce makes context particularly important

A change rarely lands in an empty org.

It lands alongside existing Flows, Apex, validation rules, managed packages, permission sets and integrations. Some of that will be documented. Some of it will require investigation.

Salesforce’s developer guidance on agentic AI highlights system design, quality validation, cross-system thinking and understanding the inherited org as increasingly important parts of the work.

That context matters when evaluating an AI-generated solution. A Flow can look reasonable in isolation and duplicate something already running. A test can exercise the expected path without checking the permissions of the person who will actually use it. An integration can work on one record and behave differently during a migration.

AI can help investigate these things. It still needs access to the right evidence, clear requirements and a process that checks its conclusions.

Keep the testing budget honest

Testing was necessary before AI. Calling all of it an added AI cost would be misleading.

But it would be equally misleading to assume that producing the implementation faster means the testing estimate should shrink with it.

I would separate three things.

The testing the project already required. Business rules, permissions, integrations, regression testing and user acceptance still need coverage. That work belongs in the original estimate.

Additional checking the AI output requires. Do the fields, objects and APIs it references exist and behave as expected? Do its assertions prove the business requirement, or simply confirm what its own code does? Did it recognize the existing automation?

Human-written work needs these checks too. The amount of additional effort depends on the tool, the task and the quality of the context supplied. Some projects will see little extra overhead. Others may spend considerable time correcting plausible output.

The effect of producing more changes. If faster drafting leads to additional features or variations, there is more to test. That is a scope decision. It should not disappear inside an optimistic productivity claim.

AI can also generate tests, prepare synthetic test data and suggest edge cases. Those benefits belong in the estimate. So does the work required to confirm that the tests are meaningful.

Take a discount approval process

Consider this hypothetical policy:

• Sales reps may authorize discounts up to and including 10%.
• Managers may approve discounts above 10% through 20%.
• Anything above 20% requires a VP.

AI drafts the Flow and its tests. Everything passes.

Now check what those tests actually establish.

At exactly 10%, does the discount stay with the rep? Does a discount just above 10% route to a manager? At exactly 20%, does it stay with the manager, or did the implementation incorrectly send it to the VP?

A rep trying to approve 15% should fail. A manager trying to approve 25% should fail. A user without the required permission should be denied or routed according to the approved requirement.

Then check the surrounding system. What happens when thousands of historical opportunities are loaded? Does another automation change the discount after approval? How does the ERP integration handle a discount edited twice in quick succession?

AI can help write those scenarios. Someone still has to confirm they reflect the policy and then verify the results.

The time spent getting the first Flow onto the screen tells you very little about how long all of that will take.

What clients should ask before accepting an AI savings estimate

If a vendor or internal team says AI will make the project substantially cheaper, ask them to explain the calculation.

• Where are the savings? Development, documentation, testing, migration preparation—or the whole project?
• What is the comparison? A previous comparable project, a measured pilot or an assumption?
• Who reviews the output? Include their time and rate.
• What testing remains? Look for permissions, realistic data volumes, integrations and existing automation.
• How is scope being controlled? Additional features consume some of the time saved.
• Where do the benefits go? A lower price, an earlier delivery date, more scope or better coverage?
• Who owns the result after launch? Generated work still needs to be understood and maintained.

Those are reasonable commercial questions. Clients should benefit when AI produces real efficiencies. They should also understand when saved development time is being used elsewhere in the project.

The cost of running AI features in production is another part of the budget. I covered that separately in Agentforce Flex Credits: The Cost Conversation You Need Before Go-Live.

AI can make Salesforce delivery better and, in the right circumstances, cheaper. But a fast build is only part of what the client is buying.

The rest is confidence that the system does what the business needs, works for the people using it and holds up after launch. Until the estimate accounts for that work, the promised saving is still an assumption.

If you want a second opinion on an AI-assisted Salesforce plan or estimate, MotionDog can help assess the architecture, validation work and delivery assumptions before you commit.