AI as your technical mentor: how to analyze a Salesforce request without outsourcing your thinking

Hey, dev! Welcome.

A new request just landed. It can be a functional spec, a ticket, a user story, a requirement or a bug fix, whatever your team calls it. You read it, understand half of it, paste everything into the AI, get some nice code back and push it. Then, in the code review, someone asks: "why did you do it this way?". And you freeze.

If this has happened to you, relax. It happens to a lot of people, and the problem is almost never the AI. The problem is the order in which we use it.

I put together a complete, free guide to change that order. It teaches you to use AI as a mentor: someone who asks you questions, explains things step by step and sends you to look at the environment, instead of handing you a ready answer that you cannot even check. In this article I show you the core of the method. You can download the full guide at the end, or right now:

Ready?

The rule that changes everything

Before any prompt, keep this sentence in mind:

The rest of the method exists so that, at the end of the task, you can answer those four questions without opening your AI chat.

You first, then the AI

The first reading of the request has to be yours. If you throw the text straight into the AI, you skip the exact step that builds your reasoning. Do it like this:

1. First pass: read it from start to end without trying to solve anything. Just find out which business problem is being described.
2. Second pass: mark the users, inputs, outputs, rules, exceptions, screens, integrations, acceptance criteria and every word you did not understand.
3. Third pass: write in your own words what you think needs to change, and list everything you still do not know.

And before opening the AI, complete these five lines:

• The problem is...
• Today it seems to work like this...
• The requested change seems to be...
• I still do not understand...
• To confirm it, I need to look at...

It looks simple, but these five lines become the context you will give the AI later. Good context, good answer. No context, and the AI fills the gaps with assumptions.

Not every question is for the AI

This is where most people go wrong. Before asking, classify the question:

Business questions are answered by people. If you ask the AI whether the rule applies to cancelled contracts, it will give you an answer. Convincing, well written, and made up. It does not know your client's rules.

Fact, hypothesis or guess?

During the whole task, keep a small table that separates how sure you are about each piece of information:

• FACT it is written in the request or confirmed by the person responsible.
• EVIDENCE you saw it in the environment: query, metadata, log, payload, test.
• HYPOTHESIS a possible explanation, not confirmed yet.
• QUESTION information that is still missing.
• DECISION a technical choice made after the evidence, with the reason written down.

Here is the trick: ask the AI to use these same labels in its answers. When it has to separate what you showed it from what it is assuming, there is much less room for hallucination.

The AI does not know your org

It knows Salesforce. But it does not know the customizations in your org, how your fields are named, which packages are installed, or that old Flow nobody remembers is still active. So investigating the environment is your job.

The cycle looks like this:

1. You write a question that can be checked: "where does this value come from?", "who updates this field?".
2. The AI suggests the path to investigate, not the conclusion.
3. You run it, in a sandbox, and read the result.
4. You go back to the AI with the real evidence, saying what it proves and what it does not prove yet.
5. You update your hypotheses and only then ask the next question.

Before changing anything, follow the data end to end: where the user enters it, which component receives it (OmniScript, LWC, Flow), what orchestrates it (Integration Procedure, Apex), where the value is saved and who reads it later. Every link in this chain needs evidence. If you know an OmniScript calls "something", find the real name of that something.

And one golden tip: "I did not find it" does not mean "it does not exist". It can be in a managed package, in metadata you did not retrieve, or in an external integration. Write down that limitation.

When the AI says "this needs validation"

It will say this a lot, and that is fine. The problem is when the conversation stops there. Answer with four questions:

1. Validate what, exactly?
2. Where can I validate it, in Salesforce or in the project?
3. What evidence should I bring back?
4. Which result closes the question, and which result opens a new investigation?

This way, "this needs validation" stops being a parking lot for vague questions and becomes a concrete next step.

A prompt to start today

Paste this at the start of the conversation, before you send the request:

Act as my Salesforce technical mentor. I am a junior dev and I want
to learn while I work on this task.

Mandatory rules:
1. Do not invent objects, fields, classes, components or requirements
   that I did not give you.
2. Separate: CONTEXT FACT, GENERAL KNOWLEDGE, HYPOTHESIS,
   NEEDS VALIDATION and QUESTION.
3. If context is missing, ask me questions before concluding.
4. Before suggesting code, help me understand the current flow,
   the impact and how to investigate.
5. When you suggest a query, command or code, explain it line by line.
6. Ask questions to test my understanding. Do not do everything for me.
7. Always tell me what I need to validate in the environment and in
   the official documentation.
8. If you do not know, say you do not know.

My goal is to be able to explain the solution on my own at the end.

The guide has 14 more ready-to-use prompts for everyday situations: building an investigation plan, writing SOQL with explanations, analyzing an OmniStudio payload, reviewing Apex, creating test cases, getting unstuck, and more.

Doubt the AI. Always.

AI is not the absolute truth. It is wrong with the same confidence it has when it is right, and that is exactly what makes its mistakes dangerous. Some signs that it may be making things up:

• A field, object or class you have never seen. Search for it in Object Manager or in the project. Not there? It was invented.
• An Apex method that does not show up in autocomplete. Check the official reference.
• An OmniStudio property "that solves everything". Open the documentation and the component's configuration screen.
• The answer changes when you ask again. It is not sure.
• Too much confidence about a business rule. Only the analyst or the client can confirm that.

Over time, you will need the AI less to understand things and use it more to go faster. That is the sign that you are growing.

Download the full guide

What I showed you here is the skeleton. The full guide includes:

• The complete flow, from reading the request to delivery, in 10 steps.
• An analysis script in rounds, to clean up your list of open questions and stop asking what is already answered.
• An investigation map by layer: interface, orchestration, data, business rules, integration, security.
• 14 ready-to-use prompts.
• A Definition of Done checklist and a pocket checklist to print.
• Security care: what you should never paste into the AI.
• When and how to ask a more experienced developer for help.
• A complete OmniStudio example, from start to finish.
• A growth path, from guided dev to independent dev.

Official sources

• Salesforce Trailhead: Prompt Fundamentals
• Salesforce Trailhead: Generative AI Basics
• Salesforce Developers: Salesforce Code Analyzer
• Salesforce CLI Reference: data query
• Salesforce Architects: Well-Architected Framework