AI can build a Make scenario in minutes. That speed is real, and it’s useful. But fast and production-ready are two different things.

After months of daily use building with Claude and a custom MCP server — documented in our field report on AI-assisted Make automation — we learned that AI-built scenarios need a structured review before they go live. Not because the output is bad. Because it’s consistent in specific, predictable ways that are easy to miss if you don’t know where to look.

This post walks through that review process step by step. The checklist at the end maps directly to what we check on every scenario before a client ever sees it run.

What Does a Pre-Production Review Actually Cover?

A pre-production review is not a full QA cycle. It’s a structured pass through the scenario that catches the category of mistakes AI makes most often: missing error handlers, vague module descriptions, edge cases the AI couldn’t infer, and data mapping assumptions that look right but aren’t.

The goal is to catch those issues before they surface in production — where fixing them is slower, more disruptive, and sometimes expensive. Learn more about the specific failure patterns in our breakdown of seven things AI-built Make scenarios get wrong.

Plan for 20 to 40 minutes on a moderately complex scenario. More on complex ones. This time investment is almost always recovered the first time an error would have taken 20 minutes to diagnose.

Before You Start

Before opening the scenario in Make, gather two things:

• The original prompt or description you gave the AI
• Any API documentation that was referenced during the build

You need these because the review is partially about confirming the AI built what you described — not just that what it built looks reasonable. Vague input produces vague scenarios. If your prompt was imprecise, the review is where you find out.

Also confirm the scenario is in draft or inactive status before you begin. Never review a live scenario by running it.

Step 1: Does the Structure Match What You Asked For?

Open the scenario and do a first-pass visual check. Don’t click into modules yet. Just read the flow.

Ask yourself: does this match what you described? Count the major branches. Confirm the trigger type is correct — webhook, scheduled, watch — and that the termination point makes sense for the use case.

AI is good at inferring structure from a description, but it builds exactly what you describe. If you left something out of the prompt, the scenario will leave it out too. This pass catches structural omissions before you spend time reviewing module internals that may need to be rebuilt anyway.

Flag anything that looks like a shortcut — a filter where a router should be, a single path where the workflow should branch, a missing confirmation step. Note these before moving on.

Step 2: Are the Module Internals Correct?

Now click into each module. For every module, check three things:

1. Credentials: Is the connection mapped to the correct account? AI-seeded scenarios often carry placeholder credentials or reference the first available connection. Verify each one explicitly.
2. Field mapping: Are the mapped fields pulling from the right upstream module? AI builds clean-looking mappings, but it can reference fields that don’t exist in your actual data structure — especially on HTTP modules.
3. Data types: Numbers passed as strings, dates without timezone handling, arrays treated as single values — these won’t throw an error on build, but they will fail at runtime.

HTTP modules deserve extra attention. One of the clearest production lessons from running our Make MCP server is that AI is strong at formatting HTTP posts correctly — JSON body structure, headers, auth — but that strength depends entirely on having accurate API documentation to work from. If the docs were incomplete or outdated, the module will reflect that.

Step 3: Is Error Handling Built — and Is It Routed?

This is where most AI-built scenarios fall short.

A generic error handler — one that catches any error and stops — is not production error handling. Production scenarios need routed error handling: different responses for different error conditions. A timeout should retry. A 404 should notify and skip. A 422 should log and alert a human. Our full walkthrough of routed error handling in Make covers how to build this correctly.

For each error handler in the scenario, check:

• Is there one? Unhandled errors in production stop the scenario silently or send a generic alert.
• Is it routed by error type, or is it a single catch-all?
• Does the error path do something useful — log to a data store, send an alert with context, trigger a retry?
• Does the alert include enough information for a technician to act without digging into the scenario?

If error handling is missing or generic, build it before the scenario goes live. This is not optional.

Step 4: What Edge Cases Did the AI Not See?

AI infers from what you give it. It does not know your business logic unless you told it. That means edge cases specific to your data or your process are the most likely thing to be missing.

Walk through three scenarios mentally:

1. The empty record: What happens if a required field is blank? Does the scenario filter it out, error gracefully, or crash?
2. The duplicate: If this trigger fires twice for the same record, what happens? Does it create two records downstream?
3. The unexpected value: If a field contains something outside the expected range — a status your system uses that wasn’t in the prompt — does the scenario route it or ignore it?

Add filters, conditions, or branches for any scenario that would cause bad data or a broken run. Document what you added so the next person reviewing the scenario knows it was intentional.

Step 5: Does the Test Run Confirm It?

Run the scenario manually with a controlled test record. Not a real record. A test record you can verify end-to-end.

Check the execution log after the run. Look for:

• Any yellow warnings — these often indicate a field mapped but empty, which may be fine or may be a problem depending on downstream use
• Skipped bundles — confirm these are intentional (filtered correctly) not accidental
• Output data at the final module — verify it matches what was expected, not just that the scenario completed

If the scenario includes an HTTP module calling an external API, confirm the response code and parse the response body manually. A 200 with an error message in the body still shows as a successful run in Make.

How to Know It Worked

The review is complete when you can answer yes to each of these:

• The scenario structure matches the original prompt with no unexplained gaps
• Every module has verified credentials and correct field mappings
• Every error path is routed by error type and sends a useful alert
• Edge cases for empty, duplicate, and unexpected values are handled
• A manual test run completed without errors or unexplained warnings
• Output data at the final module is correct

If you cannot answer yes to all six, the scenario is not ready. That’s not a judgment on the AI output — it’s just the standard for production.

Pre-Production Checklist

Use this checklist on every AI-built scenario before it goes live.

Structure

• Scenario flow matches original prompt
• Trigger type is correct (webhook / scheduled / watch)
• All required branches are present
• No structural shortcuts that should be full branches

Module Internals

• Credentials verified on every module
• Field mappings reference correct upstream data
• Data types confirmed (strings, numbers, dates, arrays)
• HTTP modules: JSON body, headers, and auth verified against API docs

Error Handling

• Every module with a failure mode has an error handler
• Error handlers are routed by error type — not catch-all
• Error paths log context and send a useful alert
• Alert messages include enough detail to act without scenario access

Edge Cases

• Empty required fields are filtered or handled gracefully
• Duplicate trigger fires produce expected behavior
• Unexpected field values are routed, not ignored

Test Run

• Manual run completed with test record
• No unresolved warnings in execution log
• Skipped bundles confirmed as intentional
• Output data at final module verified correct
• HTTP response codes and bodies confirmed

What Are the Most Common Mistakes People Make Skipping This Review?

The most common is assuming a clean build means a production-ready build. A scenario can complete without errors in a test run and still fail in production if the test data was too clean — no blanks, no edge cases, no unexpected values.

The second most common is skipping error handler review because the scenario looks simple. Simple scenarios have fewer modules, but they’re just as likely to encounter a bad API response or an empty field. The cost of an unhandled error in a simple scenario is the same as in a complex one.

For a deeper look at the failure patterns behind these mistakes, see our post on production lessons from running a custom Make MCP server — and the category-level breakdown of what AI-built scenarios get wrong.

AI is a strong build partner. It completes scenarios without broken modules, handles HTTP post formatting well, and routes error handlers correctly when you tell it what to do on each error condition. The review process is not about distrust — it’s about the difference between what AI can infer from a prompt and what your production environment actually requires.

Build fast. Review before you launch. Those two things are not in conflict.

Keep Automating,
Jeff

Information in this article is deemed to be accurate at time of publishing. 4Spot Consulting reviews and updates content periodically as best practices evolve.

Sources & Further Reading

• What Is AI Automation — Make.com
• How to Handle Errors — Make Help Center
• Overview of Error Handling — Make Help Center
• Scenarios Documentation — Make Help Center
• AI Code Review Automation Guide 2025 — Digital Applied