---
title: Kann ich Make mit ChatGPT nachbauen?
canonical: "https://kannkidas.de/produkte/make/"
pubDate: "2026-08-11T00:00:00.000Z"
updatedDate: "2026-08-11T00:00:00.000Z"
author: Pascale Beier
description: "Kann KI Make ersetzen? Analyse zu visuelle Szenarien, Connectoren, Mapping, Scheduling, Fehlerbehandlung und den realistischen Eigenbau."
---

# Kann ich Make mit ChatGPT nachbauen?

**Urteil:** Feste Szenarien sind machbar · **Score:** 56/100

**Erste sinnvolle Version:** 4–9 Wochen für feste interne Szenarien

**Mindestens nötig:** Integration Engineering, Backend und Betrieb

Visuell geplante Abläufe zwischen wenigen bekannten Systemen sind baubar. Makes breiter Connector-Katalog, Datenmapping, Verzweigungen, Scheduling, Fehlerbehandlung und transparente Ausführung bilden eine komplexe Integrationsplattform.

## Was gut machbar ist

- Ein visueller Status für wenige vorgegebene Szenarien kann Fachanwendern Betrieb und Fehler verständlich machen.
- Datenumformungen lassen sich als geprüfte, versionierte Funktionen hinterlegen.
- Zeitpläne, Webhooks und manuelle Starts können in einer gemeinsamen Laufhistorie landen.

## Wo die Grenzen liegen

- Freie Graphen mit Routern, Aggregatoren und Schleifen benötigen eine sichere Ausführungsengine.
- Große Payloads und lange Läufe brauchen Checkpoints, Quoten und kontrollierte Teilwiederholung.
- Fremde API-Fehler sind uneinheitlich und können fachlich erfolgreich wirken, obwohl Daten fehlen.

## Die erste sinnvolle Version

1. Vier vorgegebene Szenariovorlagen mit konfigurierbaren Feldern statt freiem Canvas.
2. Schrittweiser Laufstatus, maskierte Ein-/Ausgaben und Wiederholung ab sicherem Checkpoint.
3. Quoten, Timeout, Dead-Letter-Queue und Alarm an einen benannten Prozessverantwortlichen.

## Technischer Ansatz

- Versionierter gerichteter Ablauf mit typisierten Knoten und validierter Konfiguration.
- Queuebasierte Worker mit Checkpoints und getrennten Connectoradaptern.
- Laufjournal mit maskierten Daten, Kosten-/Volumenmetriken und manueller kontrollierter Wiederholung.

## Risiken

### Teilzustand (sehr hoch)

Ein Ablauf kann nach mehreren erfolgreichen Schritten scheitern; Kompensation und Wiederaufnahme müssen pro Schritt definiert sein.

### Datenprotokoll (hoch)

Laufdetails helfen beim Debugging, dürfen aber keine Geheimnisse oder unnötigen Personendaten speichern.

### Kostenexplosion (hoch)

Schleifen und große Datenmengen brauchen harte Quoten, Vorschau und Notabschaltung.


## Bauen oder kaufen?

### Selber bauen, wenn …

Bauen lohnt sich für wenige langlebige Integrationsprozesse, die besondere Kontroll-, Datenresidenz- oder Prüfanforderungen haben.

### Fertige Lösung wählen, wenn …

Make ist besser für viele visuelle Szenarien, zahlreiche SaaS-Connectoren, Fachanwender und häufige Prozessänderungen.

## Prompt für den begrenzten Eigenbau

Baue vier konkrete Szenariovorlagen statt eines freien Automations-Canvas. Definiere jeden Schritt typisiert mit Eingabe, Ausgabe, Timeout, Idempotenz und möglicher Kompensation. Worker verarbeiten über Queues und schreiben nach sicheren Grenzen Checkpoints. Ein Laufjournal zeigt Status und maskierte Felder; Rohgeheimnisse werden nie protokolliert. Begrenze Laufzeit, Datenmenge, Parallelität und Kosten pro Szenario. Fehler enden nach Backoff in einer Dead-Letter-Queue und alarmieren den benannten Eigentümer. Wiederholung beginnt nur an einem dokumentiert sicheren Checkpoint und wird im Audit festgehalten.

## Quellen

- [Make Platform](https://www.make.com/en) — Celonis
- [Make Developer Hub](https://developers.make.com/) — Make
- [Make – Sicherheit](https://www.make.com/en/security) — Make