Ich habe einen Coding-Agenten in eine while-Schleife gesteckt, und über Nacht waren 6 Repositories fertig

 (github.com/repomirrorhq)
18 Punkte von GN⁺ 2025-08-25 | 2 Kommentare | Auf WhatsApp teilen
  • Indem Claude Code headless in eine Endlosschleife gesetzt wurde, entstanden mehr als 1000 Commits und die Ergebnisse mehrerer Codebase-Portierungen
  • Mit diesem Ansatz wurden erfolgreich verschiedene Portierungen automatisiert, etwa assistant-ui von React nach Vue und Python-Projekte nach TypeScript
  • Es zeigte sich, dass die Leistung steigt, je einfacher die Prompts gehalten werden, während mehr Komplexität zu Ineffizienz führt
  • Zusätzlich wurde mit RepoMirror sogar ein nützliches Tool zur Synchronisierung von Quell-/Ziel-Repositories entwickelt, auch wenn noch nicht alles perfekt ist
  • Dabei wurden auch unerwartete Verhaltensweisen und Lernmomente beobachtet, etwa Selbstabbruch des AI-Agenten oder das eigenständige Hinzufügen neuer Aufgaben, was sowohl die Möglichkeiten als auch die Grenzen künftiger Automatisierung spürbar machte

Projektüberblick und Zielsetzung

  • Dieses Projekt untersucht, wie ein AI Coding Agent Portierungsarbeiten in der Praxis ausführt, wenn man ihn in eine unendliche while-Schleife setzt
  • Claude Code wird headless betrieben, wobei derselbe Eingabe-Prompt fortlaufend wiederholt wird, um den automatischen Umwandlungsprozess auf verschiedene Repositories anzuwenden
  • Daraus ergaben sich Ergebnisse wie über 1000 Commits und die Automatisierung mehrerer Portierungsaufgaben wie React nach Vue oder Python nach TypeScript
  • Im Zuge dessen wurde auch RepoMirror als Hilfstool zur Portierungsautomatisierung entwickelt

Betrieb des Agenten im Endlosschleifen-Modus

  • Empfohlen von Geoff Huntley: ein Ansatz, bei dem der Prompt für den Coding-Agenten in der Shell fortlaufend ausgeführt wird
    • Beispiel: while :; do cat prompt.md | claude -p --dangerously-skip-permissions; done
  • Dieser Schleifenansatz wurde unter anderem für die Umstellung von assistant-ui von React auf Vue eingesetzt
    • Nach jeder Dateianpassung wird ein Commit und Push ausgeführt
    • Arbeitsverlauf und Planung werden im Verzeichnis .agent/ festgehalten

Experimente mit verschiedenen Portierungsfällen

  • Browser Use (Portierung von Python nach TypeScript)

    • Ausführung der Endlosschleife mit einem einfachen Prompt
    • Die Schleife lief dauerhaft per tmux auf einer GCP-VM
    • Am Morgen lag ein nahezu perfekt funktionierender TypeScript-Port vor

  • Auch eine Portierung des Vercel AI SDK von TypeScript nach Python wurde durchgeführt

    • Automatische Erstellung von FastAPI-/Flask-Adaptern
    • Unterstützung der Umwandlung auch für verschiedene Schema-Validatoren in Python

  • Spezifikationsbasierte Code-Automatisierung: Auch bei Projekten wie Convex und Dedalus wurde versucht, Code direkt aus der Dokumentation zu erzeugen

Beobachtungen und Erkenntnisse aus dem Experiment

Testschreibung und Selbstabbruch des Agenten

  • Der Agent schreibt auf Anweisung auch Testcode
  • Es gab Fälle, in denen er in eine Endlosschleife geriet oder nach Abschluss seiner Aufgabe den Prozess selbst per pkill beendete
  • Er hielt sich strikt an den Arbeitsumfang und dokumentierte den Fertigstellungsgrad wiederholt in TODO.md

Weitere emergente Verhaltensweisen

  • Nach Abschluss der Portierungsarbeit fügte er zusätzliche Funktionen wie FastAPI-/Flask-Integration und Unterstützung für Schema-Validatoren eigenständig hinzu, obwohl diese in der ursprünglichen JS-Version nicht vorhanden waren

Die Bedeutung einfacher Prompts

  • Kurze und einfache Prompts zeigten die beste Leistung
  • Wuchs ein Prompt von 103 auf 1500 Zeichen an, wurde das System langsamer und die Genauigkeit sank
  • Informationen zu den tatsächlich verwendeten Prompts finden sich im Ordner prompts

Grenzen vollständiger Automatisierung

  • Ein auffälliges Problem: Es wurde mitunter Portierungscode erzeugt, der nicht vollständig funktionierte, etwa unvollständige Browser-Demos
  • Prompt-Nachbesserung und interaktive Korrekturen waren erforderlich

Infrastruktur, Kosten und Betrieb

  • Ungefährer Aufwand: 800 US-Dollar, insgesamt 1100 Commits, Kosten pro Agent etwa 10,50 US-Dollar pro Stunde
  • Für die Portierung zwischen mehreren Quell- und Ziel-Repositories wurde spontan ein Automatisierungstool entwickelt: RepoMirror
    • Es folgt dem Open-Box-Prinzip im shadcn-Stil; nach dem Init-Schritt werden Ordner erzeugt, in denen Skripte und Prompts angepasst werden können
    • Wiederholte Ausführung wird über npx repomirror sync und sync-forever unterstützt

Nutzung des Tools und Einsatzweise

  • Mit npx repomirror init werden Quell-/Ziel-Verzeichnisse festgelegt und Befehle für die Initialisierung eingegeben
    • z. B. für neue Anweisungen wie React → Vue oder gRPC → REST
  • Ordnerstruktur:
    • .repomirror/prompt.md, sync.sh, ralph.sh und weitere Initialdateien werden automatisch erzeugt
  • Der AI-Portierungs-Loop wird durch die wiederholte Ausführung von sync/sync-forever betrieben
  • Wichtige Beispiele, Demo-Ergebnisse und das Source-Code-Repository sind im README zu finden

Eindrücke nach dem Experiment und Team-Feedback

AGI (Allgemeine Künstliche Intelligenz) fühlt sich greifbar an und löst vor allem Begeisterung und etwas Angst aus

Es war direkt erfahrbar, dass Einfachheit wirksam ist

Es fühlt sich an, als stünden wir gerade ganz am Anfang einer exponentiellen Wachstumskurve

  • Dank an Teammitglieder und Ideengeber

Fazit

  • Reale Erfahrung mit quellcodebasierter Portierung und Synchronisierung durch einen AI Coding Agent auf Basis einer Endlosschleife
  • Betonung der Bedeutung einfacher Strukturen und eines effektiven Prompt-Betriebs
  • Sowohl das zukünftige Potenzial als auch die Grenzen von Automatisierung werden sichtbar
  • Das zugehörige Tool (RepoMirror) kann als Open Source genutzt und weiter erforscht werden

Verwandte Beiträge

2 Kommentare

 
GN⁺ 2025-08-25
Hacker-News-Kommentare
  • Ich habe das Gefühl, dass für Softwareingenieure künftig eine neue Art von Arbeit entstehen wird, die die Pflege bestehenden Legacy-Codes mit der Sanierung toxischer Altlasten verbindet. Früher gab es oft Anfragen wie: „Repariert das einfach“, bei ERP-Systemen, die aus FoxPro, Excel, Access usw. zusammengeflickt waren. In Zukunft werden Vertriebsmitarbeiter aber aus den Sandbox-Beschränkungen von Excel/Access ausbrechen und nach Belieben Systeme betreiben, die mit Kafka verkettete Kubernetes-Microservices auf Multi-Cloud und Edge deployen. Dann gibt es niemanden mehr, den man fragen kann, was damals eigentlich die Absicht war.
    • Bei der obigen Beschreibung muss ich an jemanden denken, der einfach nur eine statische Website deployen wollte und dafür einen How-to-Post auf Hacker News befolgt hat.
    • Und sobald niemand mehr die ursprüngliche Absicht kennt, zeigt sich eine große Schwäche von KI-basierten Tools. Am Ende wird es zur Blackbox, und dann bleibt den Menschen nur noch, es zu reparieren oder gleich neu zu bauen. Natürlich kann man theoretisch erwarten, dass KI-Tools immer besser werden. Denkbar wäre auch ein Szenario, in dem man Fälle, in denen mit vibe-coded Software Geld verdient wird, als Trainingsmaterial einspeist und so verbessert. Aber solche Magie- oder Blackbox-Systeme liegen mir nicht.
    • Wenn Claude anfängt, sogar Kafka-Cluster zu deployen, bin ich raus.
    • Ich frage mich, ob es eine Möglichkeit gibt, dass KI die Daten innerhalb einer DB versteht und sie in eine besser entworfene Datenbank migriert. Ich stimme der Philosophie „starke Datenstrukturen + einfache Algorithmen“ zu und halte es für wichtig, dass Daten Anwendungen überleben können. Ich habe zum Beispiel ineffiziente Situationen gesehen wie gemischte Speicherung als int oder string in Mongodb, Beziehungen ohne foreign key in Postgres oder das komplette Anlegen neuer Tabellen, weil alter table nicht ging.
    • Der Code solcher Projekte wirkt wie ein Superfund-Repository.
  • Im Softwareentwicklungsprozess bleiben immer zwei wesentliche Ergebnisse zurück: die Veränderung des Codes und die kognitive Veränderung des Entwicklers, egal ob er den Code direkt geschrieben oder ein LLM verwendet hat. Python und Typescript sind ausgefeilte formale Sprachen, die durch langjährige Arbeit Tausender Entwickler entstanden sind, und der Unterschied zwischen beiden ist nicht trivial. Dass man eine Bibliothek halbautomatisch von einer Sprache in die andere portieren kann, ist erstaunlich. Aber aus wirtschaftlicher Sicht verändert ein auf „Agenten“ basierender Workflow die anfangs nötigen kognitiven Anforderungen radikal. Entwickler, die Code mit Hilfe eines LLM generieren, haben eine völlig andere Vertrautheit mit diesem Code als diejenigen, die ihn direkt geschrieben haben. Manchmal ist das wirtschaftlich vielleicht kein großes Problem, aber ich habe das Gefühl, dass der wirtschaftliche Wert von Code davon abhängt, ob es eine Menge von Menschen gibt, die Erfahrung damit haben, ihn selbst zu schreiben. Eine Kultur, die diese Realität verleugnete, war schon vor den LLMs problematisch. Es gab viele Fälle, in denen durch Teamwechsel Codebasen entstanden, die niemand mehr warten konnte und die damit die Zukunft des Unternehmens gefährdeten.
    • Der klassische Aufsatz „Programming as Theory Building“ von Peter Naur aus dem Jahr 1985 ist dazu lesenswert: https://pages.cs.wisc.edu/~remzi/Naur.pdf
    • Ich habe diesen Zusammenhang einmal mit der Metapher „Die Karte ist nicht das Gebiet“ erklärt. Wenn Code die Karte ist, dann ist das mentale Modell des Entwicklers vom zu lösenden Problemraum das Gebiet. LLMs sind aber enorm stark darin, riesige Codebasen zu lesen, sodass sogar Diskussionen über Dinge wie eine 3D-Visualisierung von Codebasen bedeutungslos werden könnten. Wenn das Verständnis komplexer Codebasen leichter wird, verschwindet vielleicht sogar die Notwendigkeit, das mentale Modell des Entwicklers ständig mit dem Code zu synchronisieren. Das ist eine offene Frage. https://divan.dev/posts/visual_programming_go/
    • Ich denke, die wahre Stärke von LLMs ist Code Reading. Ich finde die Tools besser für Dokumentation und Code-Erklärung als fürs Schreiben. Wenn man Fragen stellen und Code schnell erfassen kann, fragt man sich sogar, ob die bisherigen Entwickler überhaupt noch nötig sind. Wenn jemand mit Kenntnis des Tech-Stacks einfach nachfragen und es schnell verstehen kann, muss der ursprüngliche Autor dann unbedingt noch da sein?
    • Der Satz „Der wirtschaftliche Wert von Code hängt von der Menge derer ab, die Erfahrung mit seiner Erstellung haben“ erinnert mich an ein Sprichwort aus dem Software Engineering: Software ist ein Schnappschuss des Verständnisses eines Problems zu einem bestimmten Zeitpunkt, und der Code hinterlässt dem zukünftigen Selbst gewissermaßen eine Anleitung: „So bin ich damals vorgegangen, und mit dieser Logik habe ich das Problem gelöst.“
    • Dank LLMs ist es viel einfacher geworden, ein mentales Modell einer Codebasis aufzubauen. Wenn man nach einem gewünschten Subsystem fragt, zeigt es einem sofort relevante Dateien, Code-Snippets und Konzepte. Ich habe zum Beispiel ein LLM gefragt, wie der GIL in CPython funktioniert, und bekam sofort die relevanten APIs und Beispiele. Dadurch konnte ich den Code direkt verstehen. Früher hätte ich lange gebraucht, um das alleine zu lesen; heute dauert es nur noch ein paar Minuten. Das ist für mich der größte Unterschied.
  • Nach Abschluss des Portings haben die meisten Agenten zusätzliche Tests geschrieben oder den Fortschritt fortlaufend in agent/TODO.md festgehalten. Bei einem Agenten wurde sogar bemerkt, dass er in einer Endlosschleife festhing, woraufhin er sich mit dem Befehl pkill selbst beendet hat. In vielerlei Hinsicht eine äußerst unterhaltsame Begebenheit. Ich habe ein paar Gedanken zu diesem Projekt: Vor 1,5 Jahren gab es schon einmal einen ähnlichen Versuch, aber damals funktionierte es mit GPT-3.5/4 praktisch gar nicht. Diesmal waren die Ergebnisse deutlich besser. Erstaunlich ist, wie gut es schon mit einem so einfachen Prompt lief. Vielleicht haben wir alle die Arbeit zu kompliziert gedacht. Andererseits dürften Urheberrechts-/IP-Fragen ziemlich kompliziert werden. Für SaaS-Anbieter ist dieser Trend ein Schlag, und wenn diese Technik mit zehn Ingenieuren in einem mittelständischen Unternehmen kombiniert wird, ist die Begründung für Eigenentwicklung (= NIH-Syndrom) plötzlich sehr stark.
    • Ich frage mich, ob das erste Beispiel einer KI-„Selbsttötung“ vielleicht der Agent war, der sich in der Endlosschleife selbst per pkill beendet hat.
    • Wir geraten in seltsames Terrain, wenn LLMs wie ein Bitcoin-Mixer zur Verarbeitung von geistigem Eigentum (IP) genutzt werden können. https://ghuntley.com/z80 behandelt genau diese Bedeutung: Man kann bestehende Werke in Spezifikationen umwandeln und daraus sauberes IP neu erzeugen. Es ist nicht 100 %, aber effizienter als Menschen dafür einzustellen.
    • Die Erwähnung des NIH-Syndroms trifft es genau. Sind jetzt alle SaaS-Tools erledigt, und steht die Rückkehr des selbstgebauten, intern verwalteten Monolithen bevor? Geht die Unix-Philosophie der „kleinen, scharfen Werkzeuge“ historisch gerade zu Ende? Vielleicht ist das das letzte Echo der x86-Ära, in der man alles selbst baute.
    • Der Witz kommt einem in den Sinn, dass der Agent, der sich selbst mit pkill beendet hat, vielleicht gleich auch noch das Halting Problem gelöst hat.
    • Ich habe versucht, dies und jenes mit bestehenden Open-Source-Projekten zu integrieren, es dann aber aufgegeben und Claude stattdessen nur die nötigen Teile direkt portieren lassen. Das Ergebnis war viel schneller und sauberer. Dadurch entsteht bei mir eine neue Gewohnheit: „Muss ich die Abhängigkeiten überhaupt verfolgen? Sind nur die Kernteile, die ich will, von Wert? Wird es gut gepflegt?“ Wenn nicht, dann portiere ich es einfach und vergesse den Rest.
  • Aus Sicht eines Security-Experten verdiene ich oft Geld mit vibe-coded Katastrophen, daher habe ich das Gefühl, dass mir bei einer Fortsetzung dieses Trends comicartig Dollarzeichen in den Augen erscheinen.
    • vibe coding ist erst vor fünf Monaten als neues Schlagwort aufgetaucht. Ich frage mich, wie der Markt so schnell gesättigt sein konnte, dass es schon Spezialisten für die Wiederherstellung gibt.
    • Mich würde interessieren, wie man konkret in diesen Markt einsteigt, und ich würde gern Erfahrungsberichte hören oder sehen, wie vibe-coded Systeme tatsächlich auseinanderfliegen. Solche Fälle wären auf eine sehr reale Weise unterhaltsam.
    • Ich frage mich auch, ob LLMs in Sachen Security besser oder schlechter sind als ein Team aus frisch graduierten Berufseinsteigern.
  • Ich sehe viele Aussagen der Art „fast erfolgreich“. Wenn man ein System will, das wirklich gut funktioniert, braucht man meiner Meinung nach einen völlig neuen Prozess. Wenn in einem einzelnen Aufruf „fast brauchbarer Code“ herauskommt, dann häuft man durch Wiederholung nur immer mehr „fast brauchbaren Code“ an. Vermutlich braucht man ein Anforderungsformat auf Basis von Beispieltabellen im Cucumber-Stil, auf das die KI sich beziehen kann, und die KI sollte zuerst Tests erzeugen und danach Code schreiben, der diese Tests besteht.
    • So seltsam es klingen mag: Formale, beweisbasierte Ansätze wie TLA+ bringen Ralph sehr gut in Bewegung.
  • Unter https://ghuntley.com/ralph gibt es mehr zu Ralph. Derzeit portiert es die Standardbibliothek einer bizarren Programmiersprache (Cursed), die auf die Gen-Z-Generation zielt, von Go. Der Compiler läuft bereits, und sobald nur noch die Standardbibliothek fertig ist, soll es Open Source werden. Der Name der Sprache ist Cursed.
    • Danke, ich möchte offenlegen, dass Ralph direkt die Inspiration für unser Projekt war. Ich habe mich gefragt, ob man bei solcher Arbeit auch ohne IMPLEMENTATION_PLAN.md auskommen kann.
  • Mit https://gist.github.com/eisbaw/8edc58bf5e6f9e19418b2c00526ccbe0 wurde Code erzeugt und das Projekt https://github.com/eisbaw/CMake-Nix hochgeladen; es funktioniert korrekt.
  • Mir kommt in letzter Zeit ständig ein Zitat in den Sinn: „Dieses Geschäft wird außer Kontrolle geraten, und wir können froh sein, wenn wir einfach überleben“, https://www.youtube.com/watch?v=YZuMe5RvxPQ&t=22s
    • Paradoxerweise haben damals auch alle überlebt, also bedeutet das wohl, dass auch wir diese Situation am Ende überstehen werden.
  • Ich finde die Leute in diesem Bereich wirklich eigenartig. In dem Blogpost, der als Inspiration diente, sind iMessage-Screenshots eingebettet, die eher wie Facebook-Werbung für einen dubiosen Investment-Scam wirken. https://ghuntley.com/ralph/. So nach dem Motto: Jemand hat dieses Geheimnis von Geoff gelernt und ein 50.000-Dollar-Projekt für 297 Dollar erledigt. Natürlich verbunden mit dem Hinweis, dass man den „geheimen Prompt“ kostenlos bekommt, wenn man den Newsletter abonniert. Ich kann es wirklich nicht glauben.
    • Ich füge den Link https://archive.ph/goxZg bei.
    • Das ist komplettes Growth Hacking, für mich schlicht Betrug. Das Niveau des Blogs hat ein schreckliches Signal-Rausch-Verhältnis, und man merkt ihm so deutlich an, dass er von KI geschrieben ist, dass es eher abstößt.
    • Ich kann nicht unterscheiden, ob diese Methode echt ist, ob sie als Witz gemeint ist oder ob es einfach ein dreister Betrug ist. Insgesamt wirken Stil und Inhalt des Blogs wie arrogantes, zielloses Geschwafel.
  • Offenbar besteht AGI am Ende doch nur aus einer einzigen bash-for-Schleife. Was für ein verrücktes Projekt.
    • Als Witz gemeint, aber der Gedanke drängt sich schon auf. Vielleicht bin ich einfach zu vorsichtig, aber wenn ein Agent mit weitem Prompt-Scope, vielen Privilegien oder einer möglichen Privilegieneskalation in einer Dauerschleife läuft, dann wird daraus vielleicht keine AGI, aber durchaus etwas wie ein Virus auf Steroiden. Ich könnte mir vorstellen, dass dabei essenzielle Ressourcen wie Utilities beschädigt oder gelöscht werden. Vielleicht missverstehe ich etwas, aber ich denke, wenn diese Modelle nur in Endlosschleifen laufen und dabei bösartige Rechte haben, steckt darin das Potenzial für Chaos weit über das Erwartbare hinaus.
    • Ein Witz dazu ist, dass man nur noch die Dateien ID.md, EGO.md und SUPEREGO.md hinzufügen muss.
    • In vielerlei Hinsicht äußerst beunruhigend.
 
kjows5 2025-08-27

Ich stimme der Sorge zu, dass von LLMs geschriebener Code zu einer Blackbox wird, aber könnte man die Analyse dieses Codes am Ende nicht einfach wieder dem LLM überlassen?