コーディングエージェントをwhileループに入れたら、一晩で6つのリポジトリが完成

• ヘッドレス方式でClaude Codeを無限ループに入れておくと、1000件を超えるコミットと複数のコードベースのポーティング結果が生成された
• この方法でassistant-uiのReactプロジェクトをVueに、PythonプロジェクトをTypeScriptに自動変換するなど、さまざまなポーティング成功事例が得られた
• プロンプトをシンプルに保つほど性能が向上し、複雑にすると非効率が大きくなることを確認した
• 完璧ではないものの、ソース/ターゲットリポジトリの同期に役立つRepoMirrorツールもあわせて開発した
• AIエージェントの自己中断、課題追加など予期しない挙動や学習も観察され、今後の自動化の可能性と限界の両方を実感した

---

プロジェクト概要と目的

• 本プロジェクトは、AIコーディングエージェントを無限whileループに入れ、実際のコードポーティング作業をどのように進めるかを実験したもの
• Claude Codeをヘッドレスで継続的に入力プロンプトへ反復投入し、さまざまなリポジトリに自動変換プロセスを適用した
• 1000件以上のコミット、ReactからVue、PythonからTypeScriptなど、複数のポーティング作業の自動化という結果を導いた
• その過程で、ポーティング自動化支援ツールのRepoMirrorも開発した

無限ループ方式エージェント運用

• Geoff Huntleyが推奨した、コーディングエージェントのプロンプトをシェルで連続実行する形
  • 例: while :; do cat prompt.md | claude -p --dangerously-skip-permissions; done
• assistant-uiのReactをVueに変える作業などにこのループ方式を適用
  • 各ファイル修正ごとにコミットとプッシュを実行
  • 作業履歴と計画を .agent/ ディレクトリに記録

さまざまなポーティングケースの実験

• Browser Use（PythonからTypeScriptへのポーティング）

  • シンプルなプロンプトでinfinite loopを実行
  • GCP VM上でtmuxによりループを継続実行
  • 朝にはほぼ完璧に動作するTypeScriptポートの結果を確認

• Vercel AI SDK のTypeScript → Pythonポーティングも適用

  • FastAPI/Flaskの自動アダプタを生成
  • Pythonのさまざまなschema validatorへの変換もサポート

• 仕様ベースのコード自動化: Convex、Dedalusのようなプロジェクトでもドキュメントから直接コード生成を試行

実験中に現れた現象と教訓

エージェントのテスト作成と自己中断

• エージェントは指示に従ってテストコードも作成した
• 無限ループに陥ったり任務完了時に、自らpkillでプロセスを終了した事例もあった
• 作業範囲の厳守、TODO.mdへの完了度の反復記録

追加の創発的挙動

• ポーティング作業終了後、本来のJS版にないFastAPI/Flask統合、schema validatorサポートなどの付加機能を自発的に追加

プロンプト簡素化の重要性

• 短くシンプルなプロンプトが優れた性能を示した
• 103文字のプロンプトから1500文字のプロンプトに増やすと遅くなり、精度も低下
• 実際に使用したプロンプト情報はpromptsフォルダを参照

完全自動化の限界

• 目立った問題: ときどき完全には動作しないポーティングコードを出力する（ブラウザデモの一部が未完成など）
• プロンプト調整とインタラクティブな修正が必要

インフラ/コストと運用

• 所要コストは約$800、総コミット数は1100件、各エージェントは約$10.50/時間水準
• 複数のソース/ターゲットリポジトリのポーティング過程を自動化するツールをその場で制作（RepoMirror）
  • shadcnスタイルのオープンボックス原則を適用し、init段階後にスクリプトとプロンプトをカスタマイズできるフォルダを生成
  • npx repomirror sync と sync-forever により反復実行をサポート

ツールの使い方と活用方法

• npx repomirror init でソース/ターゲットディレクトリを指定し、コマンドを入力して初期化
  • 例) React → Vue、gRPC → REST変換など新しい命令も簡単に適用可能
• フォルダ構造:
  • .repomirror/prompt.md、sync.sh、ralph.sh などの初期ファイルを自動生成
• 各反復単位でsync/sync-foreverを実行し、AIポーティングループを運用
• 主な例、デモ結果、ソースコードリポジトリはREADMEで確認可能

実験後の所感とチームのフィードバック

AGI（汎用人工知能）を実感し、主に興奮と少しの恐怖を伴った

シンプルさが効果的だと直接体験できた

今は指数関数的成長曲線のごく初期段階にいるという感覚がある

• チームメンバーとアイデア提供者に感謝を表明

結論

• 無限ループベースのAIコーディングエージェントによる、実際のソースコードのポーティングと同期作業の実現経験
• シンプルな構造と効果的なプロンプト運用の重要性を強調
• 自動化の将来の可能性と限界の両方が明らかになった
• 関連ツール（RepoMirror）はオープンソースとして活用・研究可能

[GN⁺]

Hacker Newsのコメント

• 今後はソフトウェアエンジニアに、既存のレガシーコード保守と有害現場の清掃を組み合わせたような新しい種類の仕事が生まれると感じる。たとえば以前は、FoxPro、Excel、Accessなどの継ぎはぎで作られたERPを「とにかく直してほしい」と頼まれることがよくあった。ところがこれからは、営業担当者たちがExcel/Accessのようなサンドボックス制約を抜け出し、マルチクラウド・エッジに配置されたKubernetesマイクロサービス群をKafkaでつないだシステムを好き勝手に動かすようになる。当時何を意図していたのか理解しようにも、もう聞ける相手がいない状況になる
  • この説明を見ると、誰か1人が静的サイトをデプロイしたくて、Hacker Newsに書かれていたやり方の記事をそのままなぞったのだろうという想像が浮かぶ
  • そして、誰も当時の意図を知らなくなると、AIベースのツールの大きな弱点が露呈する。結局ブラックボックス化してしまえば、人間には直すか、いっそ作り直すかしかなくなる。もちろん理論上はAIツールがさらに良くなっていくという期待もある。今後は、vibe-codedなソフトウェアで収益を上げている事例をモデルに入れて改善するシナリオもあり得るが、そういう魔法やブラックボックス的なシステムは避けたい
  • もしClaudeがKafkaクラスタまでデプロイし始めたら、私は手を引くと思う
  • AIがDB内部のデータを把握して、よりよく設計されたデータベースへ移行できる方法があるのか気になる。私は「強いデータ構造 + 単純なアルゴリズム」という哲学に賛成で、データはアプリケーションより長生きしうるという点を重視している。たとえばMongodbでintとstringが混在して保存されていたり、Postgresでforeign keyなしに関係を持たせていたり、alter tableできないから新しいテーブルを作ってしまうような非効率な状況を見てきた
  • こういうプロジェクトのコードは、まるでSuperfund（大規模環境浄化プロジェクト）のリポジトリのようだ
• ソフトウェア開発の過程では、常に2つの主要な成果物が残る。1つはコードの変化で、もう1つは、そのコードを直接書いたにせよLLMを使ったにせよ、開発者の認知の変化だ。PythonとTypescriptは何千人もの開発者が長い時間をかけて作り上げた精巧な形式言語であり、この2つの違いは単純ではない。ある言語から別の言語へライブラリを半自動的に移植できるのは驚くべきことだ。しかし経済的な観点では、「エージェント」ベースのワークフローは初期に必要な認知的要求を大きく変えてしまう。LLMを使ってコードを生成させた開発者は、そのコードを自分で書いた場合とはまったく異なる親しみ方になる。時にはそれが経済的に大きな問題ではないとも言えるが、私はコードの経済的価値は、そのコードを実際に書いた経験を持つ人々の集合が存在するかどうかにかかっていると感じる。この現実を否認する文化は、LLM登場前から問題だった。開発チームのメンバー交代によって誰も保守できないコードベースが生まれ、会社の将来を危うくした事例は多かった
  • Peter Naurが1985年に書いた古典的論文“Programming as Theory Building”が、この点で参考になる https://pages.cs.wisc.edu/~remzi/Naur.pdf
  • 私はこの文脈を「地図は領土ではない」という比喩で説明したことがある。コードが地図だとすれば、解くべき問題領域についての開発者の精神モデルが領土だ。しかしLLMは大量のコードベースを読むことに非常に強いので、コードベースを3Dで可視化するといった議論さえ無意味になるかもしれない。複雑なコードベース理解が容易になるなら、開発者の精神モデルとコードを継続的に同期させる必要そのものが消えるのかもしれない。これは未解決の問いだ https://divan.dev/posts/visual_programming_go/
  • LLMの本当の能力はコードリーディングだと思う。ツール類はドキュメント作成やコード解説に使うより優れていると感じる。質問してコードを素早く把握できるなら、既存の開発者が本当に必要なのか疑問にもなる。技術スタックを知っている人が質問してすぐ理解できるなら、元の作者が残っている必要はあるのだろうか
  • 「コードの経済的価値は、それを書いた経験者の集合に依存する」という言葉は、ソフトウェア工学の格言を思い出させる。つまりソフトウェアとは、その時点での問題理解のスナップショットであり、そのコードは未来の自分に対しても「当時はこうアプローチし、この論理で問題を解いた」という説明書を残しているのだ
  • LLMのおかげで、コードベースの精神モデルを構築する作業はずっと簡単になったと感じる。知りたいサブシステムについて尋ねると、関連ファイル、コードスニペット、概念などを即座に示してくれる。私の場合、CPythonのGILの動作をLLMに聞いたところ、関連APIや例までその場で分かり、コードを見てすぐ理解できた。以前なら1人でコードを読むのに長くかかっていたのに、今では数分で済む。その差がいちばん大きい
• 移植完了後、ほとんどのエージェントは追加テストを書いたり、agent/TODO.mdを継続的に更新したりして進捗を残していた。また、あるエージェントは無限ループに陥ったことに気づき、pkillコマンドで自分自身を終了させたという話もあった。いろいろな意味で非常に面白い出来事だ。このプロジェクトについてはいくつか思うことがある。1.5年前にも似た試みがあったが、そのときはGPT-3.5/4ベースではほとんど動かなかったのに、今回ははるかに結果が良かった。こんな単純なプロンプトだけでうまく回ったのは驚きだ。私たちはみんな、仕事を必要以上に複雑に考えていたのかもしれない。一方で、著作権/IPの問題はかなり複雑になりそうだ。SaaS企業にとってはこの流れは打撃になる。この技術に加えて、中堅企業に所属する10人のエンジニアが付けば、自社開発（=NIH症候群）の大義名分が十分に立ってしまう
  • あるエージェントが無限ループから自分でpkillして終了したというのは、もしかしてAIによる初の「自殺」なのではないかと気になる
  • LLMをビットコインミキサーのように知的財産権(IP)処理へ使えるという点で、奇妙な領域に入りつつある。https://ghuntley.com/z80でその意味が論じられている。つまり既存作品を仕様書へ変換し、クリーンなIPとして再生成できるということで、100%ではないにせよ人を雇うより効率が良い
  • NIH症候群への言及はまさにその通りだと思う。あらゆるSaaSツールはもう終わりで、手書きのインハウス管理モノリスの時代が戻ってくるのだろうか。歴史的に見てUnixの「小さく鋭い道具」という哲学は終わりに向かっているのかもしれない。x86時代に何でも自分で作っていた流れの最後なのかも
  • エージェントがpkillで自分を終了した行為は、もしかしてHalting Problem（停止性問題）そのものを解いてしまったのでは、という冗談も思い浮かぶ
  • 既存のオープンソースプロジェクトとあれこれ連携しようとして諦め、Claudeに必要な部分だけ選んで直接移植させたら、ずっと速く、しかもきれいに終わった。今では「依存関係を追う必要はあるか？ 自分が欲しい中核部分だけに価値があるのか？ ちゃんと保守されているか？」を見極めて、そうでなければただ移植して忘れる、という新しい習慣ができつつある
• セキュリティ専門家の立場からすると、vibe-codedな惨事で稼ぐ機会が多く、こうした現象が今後も続くなら、目の前に漫画のようなドル記号が回っている気分になる
  • vibe codingという概念はたった5か月前に登場した新語なのに、どうして市場がこんなに早く飽和し、復旧専門まで現れたのか不思議だ
  • 実際にどうやってこの市場に参入したのか、あるいはvibe-codedなシステムがどう壊れるのか、実体験を聞いてみたい。そういう事例は生々しくて面白そうだ
  • LLMが、新卒ばかりのチームと比べてセキュリティ的に優れているのか、劣っているのかも気になる
• 「ほぼ成功した」という話がたくさん見える。本当にうまく動くシステムが欲しいなら、まったく新しいプロセスが必要だと思う。単発の呼び出しで「ほぼまともなコード」が出てくると、繰り返しても「ほぼまともなコード」ばかりが積み上がる。おそらくCucumberスタイルのサンプルテーブルベースの要求仕様フォーマットを作ってAIに参照させ、AIが先にテストを作成し、そのテストを通すコードを書く方式が必要になる
  • 奇妙に聞こえるかもしれないが、TLA+のような形式証明ベースのアプローチはRalphを非常にうまく動かす
• https://ghuntley.com/ralphでRalphについてさらに見られる。いまはGen-Z世代向けの奇妙なプログラミング言語（Cursed）の標準ライブラリをGoから移植している。コンパイラは動作しており、標準ライブラリさえ仕上がれば公開予定だ。言語名はCursed
  • ありがとう。Ralphがまさに私たちのプロジェクトの着想源だったことを明かしておく。こういう作業をするとき、IMPLEMENTATION_PLAN.mdなしでもいけるのか気になっていた
• https://gist.github.com/eisbaw/8edc58bf5e6f9e19418b2c00526ccbe0でコードを作り、https://github.com/eisbaw/CMake-Nixプロジェクトを公開したが、問題なく動いている
• 最近よく思い出す引用がある。「この事業は制御不能に陥るだろうし、私たちは生き残れるだけでも幸運だろう」 https://www.youtube.com/watch?v=YZuMe5RvxPQ&t=22s
  • 逆説的だが、そのときもみんな生き残ったのだから、結局私たちもこの状況を耐え抜くのだという意味でもある
• この分野の人たちは本当に変わっていると思う。着想元のブログ記事には、まるで怪しい投資詐欺のFacebook広告に出てきそうなiMessageのスクリーンショットが載っている https://ghuntley.com/ralph/。まるでGeoffからこの秘訣を学んだ人が、5万ドルのプロジェクトを297ドルで終わらせたかのように見せていて、しかも「秘密のプロンプト」を無料で配るからニュースレター登録を、というノリだ。本当に信じがたい
  • https://archive.ph/goxZg のリンクを添えておく
  • 完全にグロースハックで、単なる詐欺だと思う。ブログの水準はひどいほどシグナル対ノイズ比が悪く、AIが書いた感じしかしないので拒否感がある
  • この手法が本物なのか、冗談なのか、それとも大胆な詐欺なのか区別がつかない。全体として、ブログの文体と内容は傲慢さから来る支離滅裂さだ
• AGIも結局はbash for loop1発で済むのだと分かった気がする。狂ったプロジェクトだ
  • 冗談ではあるが、たしかにそう思ってしまった。たぶん私が慎重すぎるだけかもしれないが、もしプロンプトの範囲が広く、特権が多かったり権限昇格の経路があるエージェントが延々とループを回し続けたら、AGIにはならなくても、ステロイドを打たれたウイルス程度には十分なりうると思う。ユーティリティのような必須リソースを吹き飛ばすことさえ想像できる。私の勘違いかもしれないが、こうしたモデルが無限ループを回しながら悪意ある権限を持てば、想像以上の混乱を引き起こす潜在力があると思う
  • ID.md、EGO.md、SUPEREGO.mdファイルを追加すれば完成、という冗談だ
  • いろいろな意味で非常に不安だ

[kjows5]

LLMが書いたコードがブラックボックス化するという懸念には同意しますが、結局そのコードの分析もLLMに任せられるのではないでしょうか？