Last week, Gearset published "What is the Agentic Development Lifecycle and do you need it?" alongside the launch of Cam, their agentic AI teammate. The positioning on the Gearset homepage is "Agentic change governed by DevOps." It is sharp framing. But moving to an agentic development lifecycle does not compress your overall timeline. It moves where the timeline gets stuck.
The bottleneck before agentic tools was generation. Writing metadata, building flows, and scaffolding validation rules was slow work. You had one developer or one admin, finite hours, and a backlog longer than the sprint. An agentic development lifecycle attacks that constraint directly. Tools in this category can draft components at a pace no single developer can match. For instance, HighRev claims 60% faster design cycles; a customer using Salto cut deployment prep from four or five hours to thirty minutes. These are real accelerations. For better or worse, the build phase is no longer your primary constraint.
What speeds up, and what doesn't
The thing that doesn't speed up is review.
Say your team ran five Salesforce changes a week before you introduced any agentic tooling. A developer built each one. A senior admin reviewed. The ratio was roughly one build per review, and the schedule was dictated by how long building took. Now your team adopts an agentic development lifecycle and that same developer generates fifteen components in the time it used to take to build five. Build rate tripled. Review rate stayed exactly the same, because review is still a human doing human work: reading a diff, tracing field dependencies, confirming logic is actually correct rather than just syntactically valid.
I'll call it the review gap. You now have three times as many components waiting for a qualified person to approve them before they go anywhere near production. The acceleration happened in the wrong place.
Why this is a sharper problem in Salesforce
Part of it is that the first wave of Salesforce DevOps tooling, platforms like Gearset and Copado, was built around deployment risk and version control. The agentic development lifecycle framing is a newer layer on top of that infrastructure, and the review consequences are second-order. Teams underestimate them until the queue backs up.
Part of it is also specific to how Salesforce changes fail. A flow that fires incorrectly at scale is not a minor bug. It is a data quality problem that lands in your CRM records and in your customer-facing operations. On their homepage, Flosum put it plainly: "agents are changing your Salesforce org at machine scale." If your review process cannot keep pace with machine-scale generation, the cost of a single missed review grows accordingly.
I don't have a great answer for why the Salesforce community hasn't talked about this more directly. My feeling is that most teams haven't hit the wall yet. They will.
The three changes that close the gap
There are three things that move this in practice.
The first is tiering your reviews by risk. A low-stakes field rename is not the same as a flow touching revenue recognition or a permission set change affecting a security-sensitive profile. If your agentic development lifecycle treats every generated component identically, you are spending senior-architect time on work that doesn't warrant it. The reason to triage by risk level first is so that reviewer time goes where the failure cost is highest.
The second is shifting review left. If you are reviewing at deployment time, the diff is already large, context is stale, and there is schedule pressure because something is waiting to ship. The review needs to happen at generation time, as part of the same cycle as the build. That way you catch problems when they are small and the author still has full context.
The third is automated pre-screening before the human sees the diff. Not to replace the reviewer, but to shrink what they have to assess. If an automated check confirms that the generated component does not conflict with existing field dependencies, does not violate known org rules, and stays within its intended scope, the reviewer is checking logic rather than hygiene. That is a faster review with a lower miss rate.
What this means for teams adopting an agentic development lifecycle
Teams that adopt an agentic development lifecycle without changing their review infrastructure will feel faster for a few weeks. Then the queue builds, the senior person becomes the constraint, and sprint velocity looks roughly the same as before, except the work in progress is larger and the cost of a missed review is higher.
This isn't an argument against agentic tooling. The direction is right. Platforms like Copado and Gearset are pointing there: AI-generated Salesforce changes at higher volume, governed by proper DevOps practices, is where this market is heading.
The argument is that generation speed and delivery speed are different things. A team that builds generation capacity without building review capacity at the same time is trading one bottleneck for another.
The way we think about it at FlowSprite is the hand-off. When you move to an agentic development lifecycle, you don't reduce the number of hand-offs per sprint. You increase them. What we're building is designed to make those hand-offs safer without slowing them down. There is more on how we approach the specifics over on the FlowSprite AI blog.
Build the review side at the same time you build the generation side. Otherwise you have just moved the queue.