ループ構造の到来：プログラミングの未来はどう変わるのか？

「The Coming Loop」という概念が示唆するように、ソフトウェア開発における反復処理やフィードバックループの重要性が再定義されようとしています。今後のエンジニアリングにおいて、この「ループ」というアプローチがどのような変革をもたらすのか、今こそ注目すべきタイミングです。

ループが機能するのは、何を作りたいのかを事前に十分時間をかけて理解できたときだ。前提となるのは「明確さ」――ジュニアの同僚に手渡せるくらい、慎重に仕様を書き出せるレベルの明確さが必要だよ。

たいていの場合、5〜6回はダメなバージョンを書き散らさないとそこまで辿り着けない。この5〜6回の試行錯誤を加速させる方法なんてないし、どんなエージェント技術を使おうと、人間の脳が考えを深めるための時間を肩代わりなんてできないんだ。

だから、僕の時間のほとんどは、この2つのフェーズを行き来することに費やされる。まず「何がしたいのか自分でもよく分かっていない」状態から、コードを読んだり書いたりいじったりして、「よし、ようやく何がしたいか分かったぞ（実際は自分を過信しているだけなことも多い）」という状態まで持っていく。そうしてようやく、ループを回せる準備ができるってわけだ。

エージェントを使えばショートカットできると思っている人が多いけど、理解や明確さをごまかすことはできないよ。その「人間による思考フェーズ」を飛ばしたかどうかなんて、見ればすぐに分かってしまうからね。

どの時点で自分をループに無理やり押し込むのをやめるべきか、ずっと考えているよ。開発者として、コードの構造を練り上げたり、抽象化を考えたり、モジュールに分割したりといった作業は心から楽しいし、やりがいも感じている。でも同時に、ある段階から自分がボトルネックになっていることも自覚しているんだ。

もしソフトウェアの本質が「人に利益をもたらすこと」だとしたら、コードがどう見えるかなんて気にし続けるべきなんだろうか？

今のところ答えは「イエス」だと思っているけれど、3年後、あるいは10年後はどうだろうね。

「深く関わっているコードにおいて、今のやり方はあまりうまくいっていない」という指摘はその通りだね。

「自分が深く関わっているコード」のように、判断力が重要になる部分については、今回の議論の方向性には賛同できないかな。自分が深くこだわる意思決定を、エージェントに丸投げしちゃダメだ。

「エージェントループ」と「ハーネスループ」という分類は面白いけど、事前に正確な仕様を伝えられるもの、つまり「これまでのXと同じようにYもやって」といった再現可能な作業に限って任せるべきだと思う。それは結局、予測可能な範囲の作業ってことだ。

自分の判断が入らないと最終的に「NO」と言うしかないようなものなら、Arminが言うところの「エージェントループ」での協業に留めるのがいい。それなら高速かつ安全だからね。

AIエンジニアリングアシスタントが登場する前を思い出してみてよ。チームにすごく生産性の高いエンジニアが入ってくると、他のメンバーが「いいよな、あいつがいるから仕事が終わるんだろ」なんて嫉妬していたろ？ 実は彼らは、そういう天才と一緒に働くことの呪いを知らないんだ。完璧にコントロールできていないと、その手の有能な人間は猛スピードで間違った方向に走り出してしまうからね。

「手動で入念に操縦しても、LLMから自然に良いコードが出てくるわけではなく、たとえコードが出てきても、本来起こり得ないエラーまで処理しようとする」という問題は、僕もPRレビューで何度もぶつかってきたよ。

特に一度書き上げられた後だと、「過剰なnullチェックは害悪だ」と相手を説得するのは骨が折れる。より良いモデリング（あるいは、それを実現できるsum typeを許容する言語）がない限り、この手の「ショットガン・パージング（とりあえず全部チェックする）」に対する反論として、万人に納得してもらえる理屈が見つかっていないんだ。

もしかして、そんなに気にする必要はない問題なのかもしれない。でも、コードベースを読み込んでリファクタリングしているとき、不必要なチェックを管理するのはいつもイライラさせられる。一度埋め込まれると、ログを出したり大規模な調査をしない限り、安全に削除するのがほぼ不可能なケースも多いしね。

「『あらゆる不正なケースを処理せよ』というのが正しい修正ではない…LLMは起こり得ないエラーまで処理しようとしてしまう」という点は、LLMのコードにおける最大の「コードの臭い」だね。なんであんなに執着するのか分からない。

Pythonなら、完全に型チェックされているコードベースにもかかわらず、定義済みの属性に対してわざわざ hasattr でチェックを入れたりする。

なぜそんなことをするんだろう？ 事前学習のせいなのか、強化学習のせいなのか。後者なら、開発元のラボにはぜひ修正してほしいよ。

コードとは、情報システムについて共有され、構築された理解の一部だ。

もし「ルーパー（ループ回し勢）」たちが、ソフトウェア開発という絶え間ない波に乗り続けろと言うのなら、我々はシステム設計のより高いレイヤーを目指すことになる。そこでは、ビジネス要求と会社のニッチな市場をどうすり合わせるかという、人間の判断がすべてだ。となると、プログラマーは全員、ビジネスアナリストや市場調査員、実業家になる必要がある…あるいはAIツールが歯が立たない特定領域に引きこもるか、さもなくばAIトークン補助金時代が終わってループ運用が採算割れするのを待つか。これはかつてのエキスパートシステムやLispマシンの再来のように感じるね。コード自体ができないことというより、結局「組織の構造がそのままソフトウェアに反映される」という事実に直面しただけというか。組織を変えられないなら、ソフトウェアの柔軟性にも限界があるっていうことさ。

データフロー図やドメイン知識、ドメインモデリング、ユビキタス言語が、品質や機能的・非機能的な基準を定義するためのメタ言語になるかもしれない。「完了」の定義は、もはやコンパイルが通るとかデプロイできるということではなく、ユーザーや運用者、保守担当者の要求をすべて満たすことになった。だから、構文を知っていることよりも、ビジネスアナリストやアーキテクトとしての能力が求められるようになるはずだ。UMLの復讐であり、宣言的・論理的設計やBDDが勝利する時代が戻ってくるのかもね。

結局それって、具体的には何を意味しているの？ 抽象的な概念を並べ立てて壮大な話に見せかけているだけで、要するにAIにコードを書かせるって話だよね。

将来こうなるってこと？ 自分たちがまだ思考のリーダーであるように見せかけるために役割を神秘化して、実際はAIという馬鹿な部下を群れのように導いて正解を出させ、自分たちは手を汚さないようにする。それでいて、中身はただのテック系専門用語の羅列であることを悟られないようにする、と。

僕の経験だと、ボトルネックは常に「仕様」にある。だからエージェントループは、今やそこまで重視していないんだ。

何を作りたいかを明確に理解して、Claude Codeのプランニングモードで「実行可能な仕様書（コードじゃなくてね）」を書くための指示出しをすれば、エージェントが実装に入った時に素晴らしい結果が返ってくる。

ただ、この戦略は効果的だけど、仕様書を書くためにかなりの負荷が自分にかかる。エージェントの方は、各タスクを（コードレビューに基づいた2〜3回の修正で）完璧にこなしてくれるんだけど、結局のところ、次の仕様書を書くフェーズに戻らなきゃいけないからね。

もう一つの問題は、僕が離れている間にエージェントがタスクを終えたときのことだ。技術的には次の仕様に基づいて作業を進められるはずなのに（ファイルが重ならないから衝突もない）、新しいブランチを作って勝手に始める、ということができない。寝る前に「タスクXを終わらせてプッシュしたら、そのままタスクYに取り掛かって」と伝えても、うまくいった試しがないんだ。大抵の場合、Yに取りかかって何かしら質問が出て、あとはアイドル状態で放置されてしまう。

さらに依存関係の問題もある。今日なんて、バックグラウンドジョブプロセッサを書いていたんだけど、当然ながら後続のタスクはシステムが完成していることを前提としている。こういうことは頻繁に起こるし、実装後に詳細が決まったことで仕様を修正しなきゃいけないこともある。

とはいえ、外部ループを求める段階に差し掛かっていることは確かだ。ゲートはほぼ100%「仕様作成」と「PRレビュー」にある。そこをクリアできれば、あとはエージェントにどんどん走らせておきたいね。

余談だけど、人間には扱いにくくてもLLMにとって扱いやすいツールを積極的に使うべきだと強く思うよ。例えばRustはコンパイラが厳しすぎて人間には面倒だけど、LLMには最高だよ。

ソフトウェアを「生命体」として捉えるというパラダイムシフトについては、著者の言う通りだと思う。生き物は、コードを深く理解しなくても、学ぶ過程や成長する過程で我々にリアルなやり取りを経験させてくれる。動物や植物を世話するのに、その遺伝情報を理解する必要なんてないのと同じだよ。ソフトウェアとの関係もこうなるべきだと信じているし、そこに到達するためには新しい設計・開発手法を学ぶ必要があるだろうね。僕も空き時間を使って「Mycelium」というローカルなサーバーブラウザシステムでこの仮説を検証しているよ。OpenClawに似ているけど、プライベートなローカルWebを作ったり、自分好みの2D Electronブラウザを出力してWebを操作したりできるんだ。

これはここ数ヶ月ずっと言っていることと繋がるな。LLMはタスクを完遂するのは得意だけど、美学やセンスはからきしダメだ。

仕事には2種類ある。一つはゴール駆動型で、達成すべき目標があって、そこに至るプロセスはどうでもいいもの。セキュリティはその典型だ。システムをハックする時に、その手法がいかに美しいかなんて誰も気にしない。重要なのは超極秘の核兵器の計画書へのアクセス権だけだからね。研究もそうだ。「研究用コード」なんてAIが登場する前ですらひどいものだったし。

もう一つはセンス駆動型の仕事だ。大きなコードベースに機能を追加する時、みんな自分の目標は「機能を追加すること」だと思っているけど、実際は違う。コードベースを将来の変更に耐えうる状態に保ち続けることの方が、個別の機能追加よりもはるかに重要なんだ。それには「センス」が必要になる。付け加えると、保守性とコードの品質は同義じゃない。コードの品質はあくまで手段であり、目的は保守性だからね。