So erstellen Sie Loops mit Claude Code

Die meisten Claude-Workflows sind immer noch Einmal-Aktionen.

Du schreibst einen Prompt. Claude antwortet. Die Sitzung endet. Morgen fängst du wieder bei Null an.

Das ist in Ordnung für einmalige Aufgaben.

Aber für wiederkehrende Arbeiten – tägliche Reviews, CI-Triage, Projektüberwachung, Meeting-Nachbereitungen – baust du jeden Tag denselben Kontext neu auf.

Das ist kein Workflow. Das ist Handarbeit mit KI-Garnierung.

Die bessere Abstraktion ist eine Schleife.

Merke dir das. Du wirst es brauchen.

Was eine Claude-Schleife eigentlich ist

Eine Schleife ist nicht "frag Claude einfach nochmal."

Eine Schleife ist eine wiederholbare Workflow-Struktur um das Modell herum.

Sie definiert:

→ Was den Durchlauf auslöst

→ Welchen Kontext Claude vor dem Handeln liest

→ Was Claude tun darf → Wie das Ergebnis verifiziert wird

→ Wo der Zustand gespeichert wird

→ Wann gestoppt, wiederholt oder eine menschliche Überprüfung angefordert werden soll

Das Modell erledigt immer noch das Denken.

Die Schleife liefert die Betriebsstruktur.

Der Wechsel ist wichtig, weil Claude-Sitzungen temporär sind.

Ohne eine Schleife beginnt jeder Durchlauf bei Null. Mit einer Schleife liest Claude, was zuvor passiert ist, und macht dort weiter.

6 Teile, die jede Claude-Schleife braucht

Eine Schleife ohne Struktur ist nur ein Prompt, der zweimal ausgeführt wird.

Hier sind die 6 Teile, die eine Schleife wirklich zum Laufen bringen:

→ 1. Auslöser

Was den Durchlauf startet.

Manueller Befehl. Zeitgesteuerter Timer. Dateiänderung. CI-Fehler. Git-Ereignis.

→ 2. Kontext

Was Claude vor dem Handeln liest.

Aufgabenbeschreibung. Bisheriger Fortschritt. Projektdateien. Anweisungen.

→ 3. Aktion

Was Claude tut.

Einen Bericht schreiben. Einen Fix entwerfen. Fehler klassifizieren. Ein Dokument aktualisieren.

→ 4. Verifikation

Wie du das Ergebnis überprüfst.

Checkliste. Testsuite. Erforderliche Abschnitte. Sicherheitsgrenzen-Prüfung.

→ 5. Zustandsaktualisierung

Was für das nächste Mal gespeichert wird.

PROGRESS.md aktualisiert. Blocker aufgezeichnet. Nächster Durchlauf wird geleitet.

→ 6. Entscheidung

Stoppen. Wiederholen. Oder an einen Menschen eskalieren.

Das ist die vollständige Schleife.

Und jeder Schritt zählt.

Verifikation überspringen → die Schleife vertraut sich blind.

Zustand überspringen → jeder Durchlauf beginnt bei Null.

Entscheidung überspringen → die Schleife weiß nie, wann sie aufhören soll.

Das 4-Dateien-System, das Schleifen zum Laufen bringt

Du brauchst keine Infrastruktur.

Du brauchst 4 Dateien und einen Ordner.

1my-loop/
2├── TASK.md
3├── LOOP_INSTRUCTIONS.md
4├── PROGRESS.md
5└── outputs/
6    └── daily-review.md

TASK.md — Das Ziel. Was diese Schleife erreichen soll.

LOOP_INSTRUCTIONS.md — Die Betriebsanleitung. Wie Claude laufen soll, was es tun darf, wie es verifizieren soll.

PROGRESS.md — Der Speicher. Was beim letzten Mal passiert ist, was blockiert ist, worauf sich der nächste Durchlauf konzentrieren soll.

outputs/ — Wo Claude Ergebnisse schreibt. Vorhersagbar. Überprüfbar. Sicher.

Das war's.

Claude liest diese Dateien zu Beginn jedes Durchlaufs. Aktualisiert sie am Ende. Der nächste Durchlauf macht dort weiter, wo der letzte aufgehört hat.

Das ist der Unterschied zwischen Schleifen und wiederholten Prompts.

Der Zustand lebt außerhalb des Chats.

TASK.md — Das Ziel klar definieren

Diese Datei sagt Claude, wofür die Schleife da ist.

Halte es allgemein. Packe keine Betriebsdetails hier rein. Die gehören in LOOP_INSTRUCTIONS.md.

Kopiere diese Vorlage:

1# Täglicher Projekt-Review-Loop
2
3## Ziel
4Überprüfe diesen Projektordner, fasse zusammen, was sich geändert hat,
5identifiziere Blocker und erstelle einen kurzen täglichen Review-Bericht.
6
7## Erwartete Ausgabe
8Jeder Durchlauf sollte Folgendes erstellen oder aktualisieren:
9- `outputs/daily-review.md`
10- `PROGRESS.md`
11
12## Umfang
13Claude darf Dateien in diesem Workspace einsehen und
14Berichte in den Ordner `outputs/` schreiben.
15
16Claude sollte NICHT:
17- Quelldateien ändern
18- Dateien löschen oder umbenennen
19- Nachrichten senden oder Tickets öffnen

Beachte den letzten Abschnitt.

Die erste Version jeder Schleife sollte explizite "Nicht tun"-Regeln haben.

Das liegt nicht daran, dass Claude nicht vertrauenswürdig ist.

Das liegt daran, dass du ein guter Ingenieur bist.

PROGRESS.md — Der Speicher der Schleife

Das ist die wichtigste Datei im System.

Ohne sie beginnt jeder Durchlauf von vorne. Mit ihr weiß Claude, was passiert ist, und macht dort weiter.

Die Struktur, die tatsächlich funktioniert:

1# Schleifenfortschritt
2
3## Aktueller Zustand
4- Status: Aktiv
5- Hauptziel: Tägliches Projekt-Review
6- Aktueller Fokus: [was gerade wichtig ist]
7- Zuletzt aktualisiert: [Datum]
8
9## Letzter Durchlauf
10- Datum:
11- Zusammenfassung:
12- Überprüfte Dateien:
13- Erstellte Ausgabe:
14
15## Offene Punkte
16-
17
18## Blocker
19-
20
21## Benötigt menschliche Überprüfung
22-
23
24## Nächster Durchlauf sollte
25-
26
27## Getroffene Entscheidungen
28-
29
30## Nicht wiederholen
31-

Der Abschnitt "Nicht wiederholen" ist entscheidend.

Er verhindert, dass Claude Dinge erneut versucht, die bereits fehlgeschlagen sind.

Der Abschnitt "Benötigt menschliche Überprüfung" ist entscheidend.

Er verhindert, dass die Schleife stillschweigend weitermacht, wenn sie das nicht sollte.

Zwei Regeln, um PROGRESS.md nützlich zu halten:

→ Wenn Claude es braucht, um die nächste Aktion zu entscheiden → behalte es in PROGRESS.md → Wenn du nur eine Aufzeichnung willst → verschiebe es nach outputs/history/

Zustandsdateien, die ewig wachsen, werden nutzlos.

Halte PROGRESS.md als ein Kontrollpanel, nicht als ein Archiv.

LOOP_INSTRUCTIONS.md — Die Betriebsanleitung

Diese Datei ist die Kontrollebene um Claude herum.

Sie sagt Claude genau, was es lesen, was es schreiben, was es nicht anfassen und wie es das Ergebnis überprüfen soll, bevor es anhält.

Die Vorlage, die funktioniert:

1# Schleifenanweisungen
2
3Du führst einen täglichen Projekt-Review-Loop aus.
4
5## Bevor du beginnst
61. Lese `TASK.md`
72. Lese `PROGRESS.md`
83. Überprüfe den Projektordner
94. Identifiziere, was sich geändert hat, was unvollständig ist, was eine menschliche Überprüfung benötigt
10
11## Was du tun sollst
12Schreibe einen kurzen täglichen Review in `outputs/daily-review.md`, der Folgendes enthält:
13- Zusammenfassung des aktuellen Zustands
14- Überprüfte Dateien
15- Wesentliche Änderungen
16- Blocker oder ungelöste Fragen
17- Empfohlene nächste Schritte
18
19Aktualisiere nach dem Schreiben `PROGRESS.md` mit:
20- Datum dieses Durchlaufs
21- Zusammenfassung des Geschehenen
22- Geprüfte Dateien
23- Was der nächste Durchlauf tun soll
24- Ob eine menschliche Überprüfung erforderlich ist
25
26## Sicherheitsregeln
27- Lösche keine Dateien
28- Benenne keine Dateien um oder verschiebe sie
29- Ändere keine Quelldateien
30- Schreibe nur in `outputs/daily-review.md` und `PROGRESS.md`
31- Wenn du dir unsicher bist, ob eine Aktion erlaubt ist → stoppe und frage
32
33## Verifikations-Checkliste
34Beende den Durchlauf erst, wenn Folgendes bestätigt ist:
35- `outputs/daily-review.md` existiert mit allen erforderlichen Abschnitten
36- `PROGRESS.md` wurde aktualisiert
37- Es wurden keine Dateien außerhalb der erlaubten Pfade geändert
38
39## Fehlerstrategie
40Wenn die Verifikation fehlschlägt:
411. Fehlender Abschnitt im Bericht → einmal korrigieren
422. PROGRESS.md nicht aktualisiert → einmal aktualisieren
433. Verbotene Datei geändert → sofort stoppen
444. Dieselbe Prüfung schlägt zweimal fehl → als benötigt menschliche Überprüfung markieren

Beachte die Fehlerstrategie am Ende.

Die meisten Schleifen haben keine Fehlerstrategie.

Wenn also etwas schiefgeht, improvisiert Claude.

Dort entstehen Probleme mit Schleifen.

Definiere den Fehlerpfad explizit. Immer.

Deine erste Schleife manuell ausführen

Plane noch nichts ein.

Führe sie zuerst manuell aus.

Öffne den Ordner in Claude Code oder Claude Desktop/Cowork. Verwende diesen Prompt:

1Führe den täglichen Projekt-Review-Loop für diesen Workspace aus.
2
3Befolge `LOOP_INSTRUCTIONS.md` genau.
4
5Lies vor dem Handeln:
6- `TASK.md`
7- `PROGRESS.md`
8- `LOOP_INSTRUCTIONS.md`
9
10Überprüfe dann den Workspace, schreibe den täglichen Review in
11`outputs/daily-review.md`, aktualisiere `PROGRESS.md`,
12führe die Verifikations-Checkliste aus und berichte, was sich geändert hat.
13
14Ändere keine Dateien außer
15`outputs/daily-review.md` und `PROGRESS.md`.

Überprüfe nach dem Durchlauf zwei Dinge:

→ outputs/daily-review.md — strukturierter Bericht mit allen Abschnitten

→ PROGRESS.md — aktualisierter Zustand, Anleitung für den nächsten Durchlauf, Flags für menschliche Überprüfung

Wenn beides richtig aussieht → funktioniert die Schleife.

Führe sie nun 3-5 weitere Male mit kleinen Änderungen aus.

Füge eine Notizdatei hinzu. Füge einen Blocker zu PROGRESS.md hinzu. Ändere etwas im Workspace.

Jeder Durchlauf sollte die Änderungen aufnehmen, ohne bei Null zu beginnen.

Diese Kontinuität ist der springende Punkt.

Verifikation: Der Teil, den die meisten überspringen

Hier ist die Fehlerart, über die niemand spricht.

Claude führt die Schleife aus. Sagt, es ist fertig. Aktualisiert den Zustand. Stoppt.

Alles sieht gut aus.

Aber dem Bericht fehlen erforderliche Abschnitte. Oder PROGRESS.md wurde nicht wirklich aktualisiert. Oder Claude hat stillschweigend eine Datei bearbeitet, die es nicht hätte bearbeiten sollen.

Du findest es erst heraus, wenn etwas kaputtgeht.

Deshalb gibt es die Verifikation.

Die Schleife sollte nicht aufhören, weil Claude sagt, dass sie fertig ist.

Sie hört auf, weil eine konkrete Bedingung überprüft wurde.

Gute Verifikation sieht so aus:

Führe einen Verifikationsdurchlauf für die letzte Schleifenausführung durch.

Überprüfe die Ausgabe anhand der Verifikations-Checkliste

in \LOOP_INSTRUCTIONS.md\.

Berichte:

1. Welche Prüfungen bestanden wurden
2. Welche Prüfungen fehlgeschlagen sind
3. Welche Dateien geändert wurden
4. Ob der Durchlauf sicher akzeptiert werden kann
5. Ob eine menschliche Überprüfung erforderlich ist

Ändere während dieses Verifikationsdurchlaufs keine Dateien.

Führe den Arbeiter aus. Führe dann den Verifizierer aus. Getrennt.

Mit der Zeit kannst du sie zusammenführen. Aber während der frühen Tests halte sie getrennt.

Der Verifizierer braucht einen Bestehen/Fehlschlag-Standard.

"Überprüfe das und sag mir, ob es gut aussieht" ist KEIN Verifizierer.

"Überprüfe diese 7 Bedingungen und markiere den Durchlauf nur dann als akzeptiert, wenn alle 7 bestanden sind" IST ein Verifizierer.

Planung mit /loop

Die Schleife läuft zuverlässig manuell.

Jetzt plane sie ein.

Verwende in Claude Code /loop:

1/loop 24h Führe den täglichen Projekt-Review-Loop für diesen Workspace aus.
2
3Befolge `LOOP_INSTRUCTIONS.md` genau.
4Lies zuerst `TASK.md` und `PROGRESS.md`.
5Schreibe den Bericht in `outputs/daily-review.md`.
6Aktualisiere `PROGRESS.md` vor dem Stoppen.
7Führe die Verifikations-Checkliste aus.
8Wenn es keine wesentlichen Änderungen gibt → halte den Bericht kurz.
9Wenn eine menschliche Überprüfung erforderlich ist → markiere es deutlich in `PROGRESS.md`.
10Ändere keine Dateien außer `outputs/daily-review.md`
11und `PROGRESS.md`.

Die Intervall-Optionen:

→ /loop 15m — Test-Rhythmus (verwende, während du zusiehst)

→ /loop 1h — Stündliche Überwachung

→ /loop 24h — Tägliches Review

→ /loop 7d — Wöchentliche Bereinigung oder Zusammenfassung

Wichtig: /loop ist keine Zauberei.

Es wiederholt nur den Prompt.

Die Qualität der Schleife kommt von der Struktur um den Prompt herum – den Dateien, den Anweisungen, der Verifikation, dem Zustand.

/loop liefert nur den Auslöser.

Wisse auch über /goal Bescheid:

/loop = führe erneut aus, weil Zeit vergangen ist.

/goal = führe weiter aus, bis eine Bedingung erfüllt ist.

1/goal outputs/daily-review.md existiert, PROGRESS.md ist aktualisiert,
2Verifikations-Checkliste bestanden, keine verbotenen Dateien geändert.

Verwende /loop für zeitbasierte Arbeit (tägliche Reviews, Überwachung).

Verwende /goal für abschlussbasierte Arbeit (reparieren, bis Tests bestehen; schreiben, bis alle Abschnitte fertig sind).

Die Berechtigungsleiter

Hier gehen die meisten Schleifen schief.

Leute bauen eine Schleife, die funktioniert. Und geben ihr dann sofort zu viel Macht.

Die Schleife postet direkt in Slack. Pusht Code ohne Review. Schließt Tickets automatisch.

Dann geht etwas schief und es ist ein Chaos.

Verwende stattdessen die Berechtigungsleiter:

1Stufe 1 — Nur lesen
2Claude liest Dateien, Tickets, Logs, Issues.
3
4Stufe 2 — Ausgaben entwerfen
5Claude schreibt nur in outputs/.
6Berichte, Pläne, Empfehlungen.
7Nichts Externes.
8
9Stufe 3 — Sandbox-Bearbeitungen
10Claude ändert Dateien innerhalb einer kontrollierten Sandbox.
11Isolierter Branch oder Worktree.
12
13Stufe 4 — Externe Aktionen entwerfen
14Claude bereitet PR, Slack-Nachricht, Ticket-Update vor.
15Sendet oder merged NICHT.
16
17Stufe 5 — Von Menschen genehmigte Aktionen
18Claude wendet Änderungen nur nach expliziter Genehmigung an.
19
20Stufe 6 — Automatisierte risikoarme Aktionen
21Claude erledigt eng umrissene Aufgaben automatisch.
22Mit Logs, Limits und Rollback.

Deine erste Schleife sollte auf Stufe 1 oder Stufe 2 leben.

Das ist keine Schwäche. Das ist Ingenieurskunst.

Schleifen der Stufen 1 und 2 können trotzdem enorm wertvoll sein.

Claude kann deine GitHub-Issues einsehen, CI-Fehler lesen, PRDs überprüfen und alles zusammenfassen – ohne etwas Wichtiges anzufassen.

Beweise zuerst, dass die Schleife auf Stufe 2 funktioniert.

Entscheide dann, ob sie Stufe 3 verdient.

Wenn Schleifen schiefgehen (und wie man es verhindert)

Schlechte erste Schleife:

Verbessere jeden Tag die Produktstrategie, bis sie sich stärker anfühlt.

→ Keine Stopp-Bedingung → Keine Verifikation → Kein Zustand → "Fühlt sich stärker an" ist kein Checklistenpunkt

Diese Schleife wird entweder nichts Nützliches tun oder Dinge ändern, die sie nicht ändern sollte.

Gute erste Schleife:

Überprüfe jeden Freitag das Produktstrategie-Dokument.

Identifiziere Abschnitte, die sich diese Woche geändert haben.

Liste ungelöste Annahmen auf.

Schreibe eine strukturierte Überprüfungsnotiz in outputs/strategy-review.md.

Bearbeite das Strategie-Dokument nicht direkt.

→ Klarer Zeitplan → Begrenzter Umfang → Vorhersagbare Ausgabedatei → Sichere Berechtigungsgrenze

Der Unterschied ist nicht Intelligenz. Es ist Design.

Die 5 Dinge, die Schleifen zum Scheitern bringen:

→ Planung vor manuellen Tests

→ Keine Zustandsdatei – jeder Durchlauf beginnt von vorne

→ Keine Verifikation – die Schleife vertraut sich selbst

→ Keine Fehlerstrategie – schlechte Ergebnisse improvisieren

→ Zu viele Tools zu früh – der Schadensradius wächst

Behebe alle fünf vor dem ersten /loop-Befehl.

Hinzufügen von Tools und Verbindungen

Sobald die lokale Schleife stabil ist, kannst du sie erweitern.

GitHub. Slack. Linear. Jira. CI-Logs.

Aber jedes neue Tool vergrößert den Schadensradius.

Befolge dasselbe Prinzip: zuerst lesen, dann entwerfen, erst nach wiederholten erfolgreichen Durchläufen schreiben.

Tool-spezifische Regeln gehören in LOOP_INSTRUCTIONS.md:

1## Tool-Berechtigungsrichtlinie
2
3### GitHub
4Erlaubt:
5- Offene Issues lesen
6- Pull-Request-Status lesen
7- CI-Status lesen
8- Zusammenfassung in `outputs/github-review.md` entwerfen
9NICHT erlaubt:
10- Commits pushen
11- Pull-Requests mergen
12- Issues schließen
13- Öffentlich kommentieren ohne Genehmigung
14
15### Slack
16Erlaubt:
17- Nachricht in `outputs/slack-update.md` entwerfen
18NICHT erlaubt:
19- Nachrichten senden
20- Benutzer erwähnen
21- In Kanäle posten
22
23### Linear/Jira
24Erlaubt:
25- Zugewiesene Tickets lesen
26- Vorgeschlagene Aktualisierungen entwerfen
27NICHT erlaubt:
28- Status ändern
29- Tickets schließen
30- Tickets ohne Genehmigung erstellen

Wenn das Tool nicht aufgeführt ist → stoppe und bitte um menschliche Überprüfung.

Das schützt dich davor, dass die Schleife Dinge tut, an die du nicht gedacht hast.

Wie deine erste vollständige Schleife aussieht

Hier ist der vollständige Aufbau von Grund auf.

1## Tool-Berechtigungsrichtlinie
2
3### GitHub
4Erlaubt:
5- Offene Issues lesen
6- Pull-Request-Status lesen
7- CI-Status lesen
8- Zusammenfassung in `outputs/github-review.md` entwerfen
9NICHT erlaubt:
10- Commits pushen
11- Pull-Requests mergen
12- Issues schließen
13- Öffentlich kommentieren ohne Genehmigung
14
15### Slack
16Erlaubt:
17- Nachricht in `outputs/slack-update.md` entwerfen
18NICHT erlaubt:
19- Nachrichten senden
20- Benutzer erwähnen
21- In Kanäle posten
22
23### Linear/Jira
24Erlaubt:
25- Zugewiesene Tickets lesen
26- Vorgeschlagene Aktualisierungen entwerfen
27NICHT erlaubt:
28- Status ändern
29- Tickets schließen
30- Tickets ohne Genehmigung erstellen

Fülle dann jede Datei aus (verwende die Vorlagen von oben).

Führe sie dann manuell aus:

1Führe den täglichen Projekt-Review-Loop für diesen Workspace aus.
2
3Befolge `LOOP_INSTRUCTIONS.md` genau.
4Lies vor dem Handeln TASK.md, PROGRESS.md
5und LOOP_INSTRUCTIONS.md.
6Schreibe den täglichen Review in `outputs/daily-review.md`.
7Aktualisiere `PROGRESS.md` vor dem Stoppen.
8Führe die Verifikations-Checkliste aus.
9Ändere keine Dateien außer
10`outputs/daily-review.md` und `PROGRESS.md`.

Dann verifiziere:

1Führe einen Verifikationsdurchlauf durch.
2Überprüfe anhand der Verifikations-Checkliste in
3`LOOP_INSTRUCTIONS.md`.
4Berichte, welche Prüfungen bestanden wurden, welche fehlgeschlagen sind,
5welche Dateien geändert wurden, ob eine menschliche Überprüfung erforderlich ist.
6Ändere keine Dateien.

Führe 3-5 manuelle Durchläufe mit kleinen Workspace-Änderungen durch.

Plane dann ein:

1/loop 24h Führe den täglichen Projekt-Review-Loop aus...
2[gleicher Prompt wie manuell, mit /loop 24h vorangestellt]

Überprüfe die erste Woche geplanter Ausgaben, bevor du ihr vertraust.

Das ist das vollständige System.

Der Wechsel, der alles verändert

Vor Schleifen:

→ Du hast einen Prompt geschrieben

→ Claude hat geantwortet

→ Morgen hast du denselben Prompt wieder geschrieben

→ Claude hatte keine Erinnerung an gestern

→ Du hast manuell verfolgt, was sich geändert hat

→ Alles wurde mit jeder Sitzung zurückgesetzt

Nach Schleifen:

→ TASK.md definiert das Ziel einmal

→ PROGRESS.md trägt Erinnerungen über Durchläufe hinweg

→ LOOP_INSTRUCTIONS.md steuert das Verhalten

→ Claude liest, handelt, verifiziert, aktualisiert, stoppt

→ Morgen macht es dort weiter, wo es aufgehört hat

→ Du überprüfst Ausgaben, nicht Prompts

Der Engpass verschiebt sich vom Erzeugen von Arbeit zum Überprüfen von Arbeit.

Das ist der wirkliche Hebel.

Du stellst Claude nicht bessere Fragen.

Du entwirfst ein System, das ohne dich weiterarbeitet.

10 Schleifen, die du diese Woche bauen kannst

→ Tägliches Projekt-Review – liest Workspace, schreibt Zusammenfassung

→ Meeting-Nachbereitungs-Extraktor – verwandelt Notizen in Aktionspunkte

→ Ordnerbereinigungs-Planer – organisiert, schlägt vor, rührt nichts an

→ CI-Fehler-Triage – liest Logs, klassifiziert Fehler, entwirft Untersuchung

→ GitHub-Issue-Zusammenfasser – liest offene Issues, gruppiert nach Thema

→ PR-Review-Assistent – liest Diff, markiert potenzielle Probleme

→ Newsletter-Recherche-Schleife – sammelt Quellen, entwirft Zusammenfassungen

→ Dokumentationslücken-Finder – liest Doku, markiert fehlende Abschnitte

→ Täglicher Standup-Entwurf – liest PROGRESS.md, schreibt Standup

→ Wöchentliche Retrospektiven-Schleife – überprüft die Woche, identifiziert Muster

Jede einzelne beginnt mit demselben 4-Dateien-System.

Das Einzige, was sich ändert, sind TASK.md und LOOP_INSTRUCTIONS.md.

Falls das nützlich war:

→ Teile es, um es mit jedem Entwickler zu teilen, der Claude verwendet

→ Folge @sairahul1 für weitere Systeme, die ohne dich arbeiten

→ Setze ein Lesezeichen – die Vorlagen sind kopier- und einfügbar

Abonniere theaibuilders.co für weitere interessante Artikel dieser Art

Ich schreibe über KI, Produktentwicklung und Automatisierungssysteme.