A salesperson creates a project revenue plan in Salesforce CRM and manually calculates when three months from the start will end. The Qest team handed this form change over to AI agents. The agent that designed the solution made a mistake in the design itself, a second agent caught it during review as part of the process, and a developer decided on the fix.
In this article:
- Agents do the work, people approve
- Strong models think, cheaper ones build
- The bug the reviewer caught
- What the pilot showed
Agents do the work, people approve
Qest introduced AI SDLC at a company that implements Salesforce and builds its own CRM and ERP on top of it. Developers work in Claude Code connected to Jira, the repository and a sandbox. They also have a project knowledge base and an internal marketplace of approved skills and agents. Agents cannot deploy to production: before every deploy command runs, a PreToolUse hook checks the target environment and blocks production.
Every ticket goes through four phases: Understand, Design, Build and Ship. At three points the agent stops and waits for a human: design approval, plan approval and pull request handover. When the agent runs into a contradiction, it asks. In the demo, it found a comment on a related ticket saying the change was already part of that ticket. The change was missing from the repository, so the agent left the decision to the developer.
Strong models think, cheaper ones build
The strongest model handles design, plan and review; in the demo, that was Opus. Sonnet handled the implementation based on the finished plan, and Haiku is enough for purely mechanical steps. “The agents already know from the plan what to implement. It’s a mechanical action,” says Daniel Strach, team leader and AI architect at Qest. Build starts in a clean session with only the specification and the plan. Less context means lower token consumption and fewer hallucinations. The agent logs its progress to a file, so after an outage it picks up from the last completed task. Before the agent could rely on a passing validation, it deliberately inserted a bug into the code and checked that the validation really catches it.
The bug the reviewer caught
The form now prefills the project start from the deal close date and calculates the end from the duration in months. A separate reviewer found in the code that a project starting on 15 March would create four monthly plans instead of three and inflate the planned man-days by roughly a third. Before showing the finding to a human, the main agent verified all three of the reviewer’s claims directly in the code. It then presented options for the fix. The agent recommended automatically aligning the calculation to the start of the month, but the developer chose a different rule: in duration mode, a project must start on the first day of a month, or the form will not let the user continue. The developer went against the agent’s recommendation on two of the three questions.
You need a developer at the table who understands the domain.
Daniel Strach
Team leader and AI architect, Qest
What the pilot showed
The agent worked on the ticket for about 50 minutes, including time spent waiting for the developer. In that time, the developer wrote nine inputs: five short instructions such as “Approve” or “ship” and four answers to the agent’s questions. A more junior developer would need an estimated half a man-day for the same work. Qest sees the main benefit in parallelization: a senior developer launches several smaller tickets and meanwhile works on more complex Apex. The team also ran the same skills in Codex and GitHub Copilot, so the approach works across tools.
Every run is followed by a retrospective. In it, the agent sorts the lessons learned into the knowledge base and the skills marketplace. A human approves changes to both via pull request. Because of the CLI and configuration stored as metadata, the agent handles roughly 99% of the manual tasks a developer would otherwise click through in the GUI. The developer is left with the requirements, the decisions and the review. While searching for test data, the agent also found a production token hardcoded in the code.
A general AI SDLC rollout takes roughly 3 to 4 months. Deploying the ready-made Salesforce package on a similar project takes about 10 man-days.
To discuss a suitable pilot project for your team, contact Qest at info@qest.cz.
See AI-driven SDLC in practice
Join our webinar on AI in software delivery and see how agents, human gates and reviews work on real Salesforce projects.
