Meister, die Welt der KI-Programmierung hat sich erneut radikal verändert. Der Vater von Claude Code und der Gründer von Lobster unterstützen gleichzeitig ein neues Paradigma – wird das Prompt Engineering damit obsolet?

„Vor einem Jahr schrieb ich Code in einer IDE, unterstützt von einer Art Autovervollständigung. Im November letzten Jahres habe ich die IDE deinstalliert, weil ich sie nicht mehr brauchte. Zu der Zeit hatte ich vielleicht 5 bis 10 Instanzen von Claude laufen. Was ich als Code schreiben bezeichnete, war eigentlich nur das Eingeben von Anweisungen an Claude, um Code zu schreiben.“

In einer kürzlichen Präsentation sagte Boris Cherny, ein Ingenieur bei Anthropic und der Schöpfer von Claude Code: „Jetzt denke ich, dass wir in die nächste Stufe gekommen sind: Ich gebe Claude keine Anweisungen mehr. Ich habe eine Reihe von Schleifen (Loops) laufen, die Claude anweisen und entscheiden, was als nächstes zu tun ist. Meine Arbeit besteht jetzt darin, Schleifen zu schreiben. Ich glaube, dass dies die nächste Wende wird, die wir in den nächsten Monaten, vielleicht sogar für den Rest dieses Jahres, sehen werden.“

Heute hat auch Peter Steinberger, der sogenannte „Vater der Hummer“ und derzeit bei OpenAI angestellt, einen Tweet gepostet: „Du solltest nicht mehr Anweisungen für Programmier-Agenten schreiben. Du solltest ein Schleifensystem entwerfen, das die Agenten anweist.“ Bis zum Zeitpunkt der Veröffentlichung hatte dieser Beitrag 1,5 Millionen Ansichten und hat zu einer lebhaften Diskussion unter Entwicklern geführt.

Die öffentlichen Kommentare von Boris Cherny und Peter Steinberger rücken ein neues Paradigma in den Vordergrund: Loop Engineering. Das bedeutet, dass Entwickler nicht mehr einfach manuell Anweisungen an Programmier-Agenten eingeben, sondern Schleifensysteme entwerfen, die die Agenten kontinuierlich anweisen, planen und einschränken können.

Einige Internetnutzer haben kommentiert, dass LinkedIn bald eine neue Modewelle rund um das „Loop Engineering“ auslösen könnte. Peter antwortete darauf: „Keine Sorge, es wird noch etwa 3 Monate dauern, bis es soweit ist. Danach werden die Leute über das ‚Entwerfen Ihrer Schleifenflotte‘ diskutieren.“

Dies zeigt, dass die Community beginnt, das „Schreiben von Schleifen“ als die nächste Abstraktionsebene nach dem Schreiben von Anweisungen (Prompts) zu betrachten. Manche beschreiben diese Veränderung auch als „vom Prompt-Engineer zum Meta-Prompt-Engineer“.

Außerdem haben einige Entwickler angegeben, dass sie diese Methode bereits getestet und sie funktioniert. „Ich baue gerade Schleifenabläufe (Loops) auf. Jetzt habe ich endlich die Konfiguration hinbekommen, aber jetzt tritt plötzlich ein Problem mit der Zeichenzahl (character bloat) auf, das meine Token-Kontingent sehr schnell verbraucht. Das ist ziemlich ärgerlich, denn es funktioniert zwar, aber wenn ich herausfinden könnte, was genau schief geht, könnte es dieselbe Aufgabe mit doppelter Geschwindigkeit und zu viel geringeren Kosten erledigen.“

Eine Schleife ist keine mechanische Wiederholung

„Ist eine Schleife nicht einfach ein Cron-Job? Sagen sie einfach immer wieder dem Modell, ‚mache diese Applikation besser‘?“ fragte ein Entwickler nach der Bedeutung des Loop Engineerings.

Ein anderer Entwickler antwortete, dass man für eine wirklich nützliche Anwendung eine Feedback-Schleife braucht.

Denken wir darüber nach, was ein Entwicklungsteam braucht: Wir müssen wissen, ob eine neue Funktion wie erwartet funktioniert, wo es Verbesserungspotenzial gibt, welche anderen Probleme die Benutzer haben, welche Arbeitsabläufe optimiert werden können und welchen Wert diese Optimierungen bringen können usw.

Bei manchen Dingen kann das Large Language Model (LLM) direkt auf Daten zugreifen. Man kann aber auch Daten generieren, z. B. durch Benutzerinterviews oder das Erstellen von Aufgaben, oder es kann selbst Daten generieren, z. B. durch A/B-Tests oder die Erhöhung der Überwachung.

Genau wie ein Entwicklungsteam braucht man auch einige OKR oder Ziele. Wenn man eine Applikation für interne Mitarbeiter entwickelt, können die Ziele mit der Verbesserung der Leistung, der Reduzierung der Fehlerrate, der Automatisierung oder Vereinfachung von Arbeitsabläufen usw. zusammenhängen. Bei einem E-Commerce-Business könnten die Ziele die Optimierung des Prozesses von der Conversion-Funnel bis zum Abschluss des Kaufs und die Steigerung des Umsatzes sein. Es kann auch zur Aktualisierung von Bibliotheken verwendet werden, ähnlich wie Dependabot, um Sicherheitslücken zu beheben, technische Schulden zu verwalten, die Nutzung zu analysieren, Qualitätssicherungen durchzuführen usw. Man braucht klare Ziele und eine Feedback-Schleife, um die Ergebnisse zu überprüfen.

YC CEO Garry Tan hat beim Weiterleiten der Diskussion auch gewarnt, die Agenten nicht zu einer Art „Foxconn-Fabrik“ zu machen, die nur mechanische Wiederholungen ausführt. Er meint, dass Agenten normalerweise intelligent, denkfähig und nicht gefährlich sind. Entwickler sollten ihnen mehr Aufgaben übertragen, anstatt sie nur wiederholt die gleiche Aktion ausführen zu lassen.

Einige Entwickler haben darauf hingewiesen, dass Agenten mehr Aufgaben übernehmen können, aber die Grenzen müssen klar definiert sein. Das Ziel sollte nicht sein, jeden Schritt zu überwachen, sondern den Agenten klare Kontexte, vertrauenswürdige Tools, nachvollziehbare Handlungsaufzeichnungen und sichere Stoppbedingungen zu geben. So können sie autonom arbeiten, ohne zu einer unkontrollierten „Schattenautomatisierung“ zu werden.

Ein Entwickler hat unter Peters Beitrag auch darauf hingewiesen, dass das Entwerfen einer Schleife nur die Hälfte der Arbeit ist. Die andere Hälfte besteht darin, in die Schleife eine Mechanik einzubauen, die sagen kann „nein“, z. B. Tests, Typüberprüfungen oder echte Fehler. Andernfalls wird eine Schleife ohne Feedback-Mechanismus den Agenten nur wiederholen und sich selbst bestätigen. Peter antwortete darauf, dass er in seinem Projekt die Datei VISION.md verwendet.

All dies zeigt, dass ein wirklich effektives Loop Engineering kein einfaches Automatisierungsskript ist, sondern ein Engineering-System mit einer Feedback-Schleife. Eine Schleife muss wissen, wann sie weiterlaufen soll, wann sie stoppen soll, wann sie rückgängig machen soll und wann sie an Menschen übergeben soll. Andernfalls können die Fehler der Agenten in der Schleife immer weiter vergrößert werden.

Einige Entwickler haben auch angegeben, dass dies stark von der konkreten Anwendungssituation abhängt. Wenn man Loops verwendet, um eine Web-Applikation zu bauen, kann dies zu einer Überkomplizierung des Systems führen. Dann müsste man wieder Loops verwenden, um die Komplexität zu reduzieren. Deshalb muss man eine strenge Governance-Struktur und klare Regeln aufbauen.

Andere haben gefragt, ob die Schleife in der CLI, in einem Shell-Skript oder direkt von Claude selbst ausgeführt wird.

Tatsächlich hat Claude Code bereits die Loop-Funktion eingeführt. Entwickler können direkt in der CLI periodische Anweisungen festlegen, damit Claude Code Aufgaben in festen Intervallen wiederholt ausführt.

Boris Cherny hat kürzlich auch seinen aktuellen Arbeitsablauf beschrieben: Er lässt eine Vielzahl von AI-Agenten parallel arbeiten, normalerweise laufen in der Nacht „tausende“ von AI-Agenten, die tiefgreifendere Entwicklungstasks ausführen. Er verwaltet diese Aufgaben über die Claude App. Der Schlüssel für diesen Arbeitsablauf liegt in zwei Funktionen von Claude Code, die auf kontinuierliche Automatisierung ausgerichtet sind: /loops und Routines.

Cherny erklärte, dass Benutzer /loops lokal über cron zeitgesteuert ausführen können, damit die Agenten Aufgaben nach einem Plan in Schleifen ausführen. Routines werden auf dem Server ausgeführt und können periodische Aufgaben ausführen. So können die Agenten auch weiterarbeiten, wenn der Ingenieur seinen Laptop schließt.

Der entscheidende Unterschied bei den Loops ist, dass sie nicht mehr von externen cron- oder Shell-Schleifen abhängen. In der Vergangenheit, als man das claude -p-Skript verwendete, war jeder Aufruf ein „Kaltstart“ und es fehlte der Kontext der vorherigen Runde. Die Loops laufen hingegen in einer fortlaufenden Claude Code-Sitzung, behalten das Kontextfenster, die Tool-Berechtigungen und die MCP-Verbindung bei, so dass der Agent die vorherige Aktion im Gedächtnis behalten und in der nächsten Runde weiterarbeiten kann.

Entwickler können Aufgaben in natürlicher Sprache erstellen, z. B.: „Überprüfe alle 5 Minuten, ob der PR-Build erfolgreich war. Wenn nicht, lies die Fehlerprotokolle, behebe die Probleme und pushe einen neuen Commit.“ Oder sie können es auch über einen Befehl erstellen:

/loop "Zusammenfasse alle neuen Posts mit dem Tag #announcements im Slack-Kanal des Teams" --interval 30m --expires 8h

Als ein Internetnutzer Peter fragte, wie er das geschafft hat, antwortete Peter nur, dass er claw verwendet, um seinen Codex zu überwachen, und erläuterte es nicht weiter.

Derzeit hat Codex zwar Automatisierungs- und Zeitsteuerungsfähigkeiten, aber in der CLI gibt es keine klar definierten nativen Schleifenbefehle wie bei Claude Code, z. B. cron create, um eine neue geplante Schleife zu erstellen, cron list, um alle aktiven Schleifen in der aktuellen Sitzung anzuzeigen, und cron delete, um eine bestimmte Schleife sofort über ihre ID zu beenden.

Interessanterweise fragte ein Nutzer Peter, wie man dies in VS Code umsetzen kann. Peter fragte zurück: „Wer benutzt noch VS Code?“

„Wir sind von ‚lernen, wie man Code schreibt‘ zu ‚lernen, wie man das Ding schreibt, das Code schreibt‘ gekommen. Irgendwie klingt das sowohl wie Fortschritt als auch wie ein Pyramidschema.“ kommentierte ein Internetnutzer.

Entwickler: Ihr habt unbegrenzten Token-Zugang, ich nicht

Die Vorstellung ist schön, aber die Realität ist: Die Token-Konsumtion bei diesem Loop-Engineering ist nicht gering. Sowohl Boris Cherny als auch Peter Steinberger haben von ihrer Firma nahezu unbegrenzten Token-Zugang. Aber für viele in der Community ist ihr Token-Budget nicht so hoch.

Früher hat die Developers Digest in einem Artikel gewarnt, dass jede Iteration einer Schleife eine vollständige Anweisung ausführt. Wenn man es auf einmal pro Minute einstellt und es 8 Stunden lang laufen lässt, führt dies zu 480 API-Aufrufen. Deshalb müssen Teams die Kosten im Voraus planen.

Beim Problem der Token-Konsumtion hat sogar Peter keine Lösung. Nachdem jemand darauf hingewiesen hatte, dass ein 20-Dollar-Abo nicht ausreichen würde, sagte er nur: „Stimmt. Aber ist deine Zeit wirklich nicht wert?“

Ein anderer Entwickler sagte: „Eine Schleife kann eine for-Schleife oder eine while-Schleife sein. Firmen mit genügend Token können while-Schleifen verwenden. Start-ups mit knappen Token können dasselbe Ziel auch mit for-Schleifen erreichen, aber es dauert länger.“

Ein Internetnutzer sagte Peter halb im Spaß: „Wie unehrlich von dir. Sagst du das an Leute mit unbegrenztem Token-Zugang? Warum machst du es so, als wäre es ein technisches Problem und nicht ein Geldproblem?“ Peters Antwort war ziemlich unverbindlich: Ein guter Verkaufsidee braucht immer noch menschliche Kreativität.

Beim praktischen Einsatz versucht Claude Code, das Problem der Token-Konsumtion durch verschiedene Beschränkungen zu lösen:

Loops unterstützen ein Mindestintervall von 1 Minute und können maximal 3 Tage laufen. Danach stoppen sie automatisch, um unüberwachte Hintergrundprozesse und unkontrollierte API-Rechnungen zu vermeiden. Loops sind kein dauerhaftes Hintergrundtasks-System. Sie sind an die aktuelle Claude Code-Sitzung gebunden. Wenn man das Terminal schließt oder die Sitzung beendet, stoppt die Schleife. Diese Designentscheidung dient der Sicherheit und Vorhersagbarkeit, um zu vermeiden, dass die Aufgaben weiterhin API-Kontingent verbrauchen, wenn der Benutzer sie vergisst. Außerdem bietet Claude Code einen Schalter, um die Loops zu deaktivieren. Wenn Benutzer befürchten, dass die Automatisierungsaufgaben außer Kontrolle geraten oder die API-Kosten zu hoch werden, oder wenn sie nicht möchten, dass Teammitglieder den Schleifen-Agenten-Arbeitsablauf verwenden, können sie diese Funktion deaktivieren.

Abgesehen von den Kosten kann die Implementierung von Loops schwieriger sein, als man denkt.

„Alle rennen auf Loops los, aber das Debuggen eines Zustandsautomaten, der bereits 47 Runden gelaufen ist, ist 10 Mal schwieriger als das Beheben eines Prompts.“ sagte ein Internetnutzer. „Die Richtung der Loops ist richtig, aber wir haben eine wichtige Phase übersprungen: Die meisten Menschen können noch nicht einmal einen zuverlässigen einmaligen Prompt schreiben.“

Einige Entwickler, die bereits Loops verwenden, haben angegeben: „Am Anfang war alles einfach einzurichten, aber dann merkt man, dass es eine Menge Probleme gibt und es ist sehr mühsam, sie zu beheben.“

„Jetzt denke ich, dass ich meinen Kollegen etwas schuldig bin, weil ich die Loops in unsere Organisation eingeführt und verbreitet habe. Wenn wir jetzt zu einer anderen Lösung wechseln, würde es viel Zeit und Ressourcen kosten. Deshalb müssen wir es noch eine Zeit lang aushalten, bis es wirklich unerträglich wird.“ schrieb ein Entwickler in einem Kommentar.

„Wir haben das auch versucht. Wir haben es integriert und wollten Loops in einem Projekt testen. Jetzt braucht es schon so viel Zeit und Energie, um die Daten aus diesem Projekt zu exportieren und in das Tool zu migrieren, das wir jetzt verwenden. Niemand will das machen. Meiner Empfehlung nach sollte man so früh wie möglich wechseln. Je länger man wartet, dest