LLM Mocks: Your New Dev Shortcut

When you’re building on top of an LLM — whether it’s for code generation, image creation, or reasoning over user inputs , waiting for real-time responses can slow you down. We’ve all been there: you’ve already verified the LLM prompt and logic, but now you’re iterating on how your application processes the output. Do you really need to wait 30s to 3 minutes for every run?

Mocking saves time, speeds up feature development, and makes debugging predictable.

Here’s the better approach to mock the LLM response.

🔍 Why mocking LLM responses is important:

1. You’ve already validated your prompt, no need to re-query LLMs just to test UI or downstream logic.
2. LLM APIs are slow (esp. for image/gen tasks), mocking makes your dev loop instant.
3. You want to work offline or avoid burning through API credits.
4. Easier unit testing of LLM-dependent flows.

mock_config.json

{
  "analyseUserIntent": {
    "mock": true,
    "response": {
      "content": "User wants to create a new marketing campaign."
    }
  },
  "generateCampaign": {
    "mock": true,
    "response": {
      "content": "Here's a draft campaign based on your input..."
    }
  },
  "searchSimilar": {
    "mock": false,
    "response": {
      "content": "Matching records found: ..."
    }
  },
  "generateImage": {
    "mock": false,
    "response": {
      "content": "",
      "image_url": ""
    }
  }
}

Here’s the Python backend function that wraps LLM usage. You can do the same in any language.

def call_llm(purpose, user_input):
    if mock_config[purpose]["mock"]:
        return mock_config[purpose]["response"]

    # Actual LLM call
    return actual_llm_call(purpose, user_input)

On the frontend, we use a similar approach with conditional logic based on environment or flags.

Love to hear, what are your thoughts.