An old lesson in a new interface
In his Salesforce Ben article, “Salesforce Flow Demonstrates Why Vibe Coding Isn’t Enough”, Tim Combridge draws a useful parallel: visual automation helped more people build software, but it did not automatically give them the engineering judgement to maintain it. AI-generated code lowers the barrier again. The responsibility does not disappear.
That is not an argument against using AI to build things. It is an argument for being clear about what you have built. A prototype can demonstrate an idea. A working business tool also has to fit a process, handle the exceptions and remain understandable when its original builder is not in the room.
Our view at Mandem: the opportunity is not simply more code. It is giving the people who know the work a better way to shape its improvement, with the right support around them.
The person doing the work should help design the solution
A service coordinator may understand missing information and awkward handoffs better than someone reading a specification. A finance colleague may know which apparent duplicates are legitimate. An AI-assisted prototype can make that knowledge visible quickly: instead of describing a screen for weeks, the team can try one and say what is wrong with it.
That is valuable. It does not mean everyone needs to become a software engineer. It means process knowledge and technical judgement should meet early, rather than one being mistaken for the other.
Imagine an assistant for incoming requests
Consider a fictional team receiving service requests by email. An AI-built application extracts a few details, drafts a summary and places the request in a queue. The first demonstration looks excellent.
Then normal work arrives. A customer sends a correction in a second email. Two colleagues open the same request. An attachment is unreadable. The CRM is temporarily unavailable. A message contains a confident but incorrect delivery date.
These are not exotic edge cases. They help define the actual job. Does the tool update the existing request or create another one? Can someone see what failed and retry safely? Who checks the draft before a customer receives a commitment?
A sensible first version might prepare information for a human reviewer inside the existing CRM. It does not have to replace the CRM, set prices or send replies automatically to be useful.
Five questions between “it runs” and “we rely on it”
Before a prototype becomes part of everyday work, make these questions concrete. The depth of review should match what the tool can affect: an internal draft helper and an application making customer commitments do not need the same rollout.
1. What is the task, and what stays human?
Name the input, the desired output and the person who decides what happens next. Make the boundary explicit: preparing a recommendation is different from approving it.
2. What does it need to work with?
Map the existing systems, permissions and source of truth. Check which record is authoritative and what happens if a connection fails. Build around what already serves the team well.
3. What happens on a bad day?
Try missing details, duplicates, corrections, unavailable services and realistic volumes. Test the recovery path as well as the successful path. A clear failure can be more useful than a plausible wrong answer.
4. How will the team judge the result?
Compare representative tasks before and after. Include checking and correction time, not just generation speed. A faster draft is not a saving if it creates more work downstream.
5. Who owns it next month?
Name the business owner and maintenance responsibility. Keep useful operating notes, a way to report problems and a route back to the previous process. Make ongoing hosting, model and support costs visible.
Use AI to shorten the learning loop, too
AI coding tools can help explain unfamiliar code, draft tests and prepare documentation. Those outputs still need checking against the implementation. A convincing explanation is not proof that permissions are correct or that a retry cannot create duplicate records.
The strongest use of these tools is a short feedback loop: build something small, inspect it, try representative work with the team, review what happened and improve it. Bring someone who understands the code and its environment into the review before people depend on it.
Training belongs in that loop. Staff need to know what the tool does, where it can be wrong and how to challenge or correct its output. A walkthrough of the happy path alone will not answer those questions.
Start smaller than the replacement story
The appeal of “we can build our own version of everything” is understandable. But an existing business system usually carries years of permissions, integrations, records and operating habits behind its screens. Recreating the visible interface is not the same as replacing all of that.
Start with one bottleneck instead. Prepare a clearer request. Reduce retyping. Make a handoff easier to follow. Learn whether the team actually benefits before widening the scope.
Vibe coding can help a useful idea become tangible. What turns that idea into a dependable workplace improvement is the combination of business understanding, thoughtful implementation and clear ownership. The prompt can start the work. It does not finish it.
Source and further reading
This is an original Mandem commentary prompted by Tim Combridge’s article, “Salesforce Flow Demonstrates Why Vibe Coding Isn’t Enough”, published by Salesforce Ben. The request-handling example and five-question framework above are Mandem’s illustrative application of the topic, not a reported customer case study.
Read the original article: https://www.salesforceben.com/salesforce-flow-demonstrates-why-vibe-coding-isnt-enough/