Post: 5 Automation Tasks AI Handles Well — and 5 It Still Gets Wrong
We have been building Make scenarios with AI assistance long enough to see the pattern. Some tasks come out clean the first time. Others look fine on screen and fall apart the moment real data hits them.
This post comes directly from our production field report on AI-assisted Make builds — months of real scenarios, real clients, and real errors. Two lists. No filler. If you are deciding how much to trust AI in your next automation build, start here.
The Quick Answer
AI handles the mechanical, structure-heavy parts of Make scenario construction well — HTTP modules, error routing, JSON formatting, and webhook patterns. It struggles with anything that requires knowing your business: what data actually looks like in production, what edge cases matter, and what happens when something breaks at 2 a.m. and a real person has to fix it.
| AI Handles Well | AI Still Gets Wrong |
|---|---|
| HTTP module construction | Business process understanding |
| Routed error handling | Edge case anticipation |
| Credential injection (seeded) | Data shape assumptions |
| Schema-compliant JSON | Change management |
| Standard webhook patterns | Production support |
5 Things AI Handles Well in Make Automation
1. Building HTTP Modules from API Docs
Hand the AI a vendor’s API documentation and it builds the HTTP module correctly — headers, authentication, body structure, and all. This used to take 30-45 minutes of reading and testing. Now it takes minutes.
- Reads the endpoint spec and maps it directly into Make’s generic HTTP module
- Formats the JSON body correctly the first time
- Handles bearer tokens, API keys, and basic auth without confusion
- Collapses the “no native Make module” problem for newer vendors
Verdict: This is where AI pays for itself fastest. If your stack has any tool without a native Make connector, AI just removed the biggest friction point in building for it.
2. Routed Error Handling
Tell AI what you want to happen when a specific error fires and it builds the routing correctly — not a generic catch-all, but actual conditional paths per error type.
- Identifies which module types need error handlers
- Routes 4xx and 5xx responses to different paths
- Can build retry logic with backoff when you specify the conditions
- Keeps the main scenario path clean while errors route separately
Verdict: Most manually built scenarios skip or shortcut error handling. AI builds it in by default when you ask for it — and builds it right.
3. Credential and Connection Injection (When Seeded)
Once we seeded our MCP with existing scenarios, it learned the JSON structure Make uses — including how connections and credentials are referenced. From that point forward, it includes the right credential references automatically.
- No manual fill-in required for connection IDs already in the system
- Carries forward app-specific authentication patterns it has seen before
- Eliminates the step of hunting down connection references after the build
Verdict: Seeding is the setup cost. After that, credential injection is invisible — which is exactly how it should be. See our full comparison of AI builds versus manual builds for how this changes build time.
4. Schema-Compliant JSON Construction
AI is precise about JSON. Brackets, nesting, field names, data types — it gets the structure right consistently. This matters because Make is unforgiving about malformed payloads.
- Builds nested objects without dropped brackets or type errors
- Handles arrays of objects correctly, including dynamic length
- Validates against a schema when you provide one
- Catches its own formatting errors when you ask it to review
Verdict: JSON errors are silent killers in automation. AI reduces them significantly on the build side — though it cannot account for what the source data actually sends at runtime.
5. Standard Webhook Intake Patterns
Webhook triggers, payload parsing, response formatting — AI knows the standard patterns cold. If you are building a webhook-triggered scenario that follows a common structure, it will get it right on the first pass.
- Builds the trigger module with correct response handling
- Maps payload fields to downstream modules without manual wiring
- Handles both synchronous and asynchronous webhook patterns
- Knows common platform webhook formats (Stripe, Typeform, Calendly, etc.)
Verdict: Webhook builds are where AI looks most like a senior developer. The patterns are well-established and AI has seen enough of them to build them cleanly.
5 Things AI Still Gets Wrong in Make Automation
1. Business Process Understanding
AI builds what you describe. It does not know what you mean. If you leave out a step because it seems obvious to you, AI will leave it out of the scenario too — and the gap will not show up until a real transaction runs through it.
- Cannot infer intent from context the way an experienced consultant can
- Does not push back when a described process has a logical gap
- Will build exactly the wrong thing if the brief is ambiguous
- Process mapping still has to happen before AI touches the build
Verdict: This is why OpsMap™ still matters. The build step was never where the value lived — and AI just made that more obvious. Garbage in, garbage out applies here at a higher speed.
2. Edge Case Anticipation
AI builds for the happy path. It will handle the error conditions you tell it about. It will not imagine the ones you did not mention — the null field, the duplicate trigger, the record that exists in one system but not the other.
- Does not ask “what if this field is empty?” unless you raise it
- Misses conditional logic needed for records in partial states
- Assumes clean, complete data unless told otherwise
- Edge cases still require a practitioner who has seen them before
Verdict: This is the most expensive gap. Edge cases are where production scenarios fail. We document the common ones in seven things an AI-built Make scenario gets wrong.
3. Data Shape Assumptions
AI assumes the data coming in matches the shape you described. In production, it rarely does exactly. Field names shift. Arrays come in where single values were expected. Dates arrive in three different formats from three different sources.
- Maps fields based on your description, not on what the API actually returns
- Does not account for vendor API changes after initial build
- Misses type mismatches that only appear with real records
- Requires a human to test with live data before the scenario goes live
Verdict: Always run the scenario on real data before calling it done. AI builds to spec. Real data does not always match the spec.
4. Change Management
Automation does not exist in a vacuum. When a process changes — a new hire, a policy update, a vendor switch — someone has to update the scenarios. AI cannot track those changes or flag when a live scenario is now out of sync with the current process.
- Has no visibility into what is live versus what is documented
- Cannot alert you when a business rule change affects an existing build
- Documentation drift is invisible to AI until someone reports a failure
- Human oversight of the automation stack is still mandatory
Verdict: This is an OpsCare™ problem, not a build problem. AI compressed the build timeline. It did nothing to reduce the ongoing responsibility of keeping automations current. That responsibility got more important, not less. See the budget implications of the build step commoditizing.
5. Production Support
When something breaks at 2 a.m., AI cannot call the client, triage the failure, decide what to roll back, or communicate the issue upstream. It can help diagnose — and we have built our MCP to send technicians an email with error analysis — but a human still has to act on it.
- Diagnosis support is real and valuable — research time dropped from 20-30 minutes to a glance at an email
- But diagnosis is not resolution — a technician still makes the call
- Client communication, escalation decisions, and rollback judgment are human work
- Production support requires a person who understands both the system and the business
Verdict: AI made production support faster. It did not make it optional. The human in the loop is still load-bearing.
How We Evaluated These
These lists come from direct production experience — real client scenarios built with AI assistance across multiple industries. We evaluated each category on three factors: first-pass accuracy, failure mode when it goes wrong, and whether the gap is closeable with better prompting. The five things AI gets right are closeable with better tooling. The five things it gets wrong are not — they require human judgment, business context, or ongoing operational ownership that no prompt can replace.
What This Means for Your Next Build
Use AI for the mechanical work — HTTP modules, error routing, JSON, webhook patterns. That is where it saves real time with real accuracy.
Keep humans responsible for process design, edge case definition, data validation, change management, and production support. Those are not gaps waiting to be closed by a better model. They are the work.
The budget implication is straightforward: less time on build, same time on everything else. If you are pricing or scoping automation work based on the old build time assumptions, you need to revisit that. The build step got cheaper. The rest did not.
Information in this article is deemed to be accurate at time of publishing. 4Spot Consulting reviews and updates content periodically as best practices evolve.
Related Reading
- Make Skills for Claude: Field Report from Production Builds
- 7 Things an AI-Built Make Scenario Gets Wrong
- AI-Assisted Make Builds vs. Manual Builds: A Direct Comparison
- The Build Step Is Commoditized — What That Means for Your Automation Budget
