「どうしても時間がかかること」ってあるよね。焦らず待つのもエンジニアの嗜み

世の中には、どれだけハックしても、どれだけハイスペックなマシンを使っても、どうしても一定の時間を必要とすることがあります。ビルド、モデルの学習、DNSの浸透、あるいはエンジニアとしての成長……。焦らずに、その「必要な時間」を受け入れる心の余裕も大切かもしれませんね。

僕みたいにAIやエージェントツールをフル活用してる人は、逆にどんどん時間がなくなってる気がするんだよね。すぐに新しいタスクで時間を埋めちゃう罠にハマってる。瓶を砂でいっぱいにしたら、大きな岩を入れるスペースはなくなる。でも、先に大きな岩を入れれば、砂が入るスペースはいくらでもある。岩を一つどければ、すぐに砂がその隙間を埋める。まずは大きな岩から入れるようにしないとね。

第3段落でついていけなくなった。スイスの時計とかエルメスのバッグ、古い不動産に高い金を払うのは、それがステータスシンボルとして認知されてるからであって、作るのに時間がかかったからじゃない。うちのおばあちゃんが俺の着てるセーターを編むのにものすごい時間をかけたとしても、その市場価値はほぼゼロだろうしね。

シド・マイヤーズ パイレーツのクローンを（娘たちのために）プリンセス仕様で作ってるんだけど、AIを使っていていくつか確信したことがある。 ・AIはPoC（概念実証）を作るのがめちゃくちゃ早い。 ・ストーリーラインや分岐のアイデア出しにも役立つ。 ・それでも、アートワークの選定やストーリーの整合性など、決めるべきことは山ほどある。 ・プレイテストと改善は結局人間のスピードでしか進まない。ターゲットが人間なら、フィードバックを得るには「コンピュータ時間」じゃなくて「人間時間」が必要だから。 AIは膨大な時間を節約してくれるけど、制約理論にある通り、結局はどこか別のボトルネックが全体を遅くするんだっていう良い例だと思う。

現代のAIツールの速さばかり強調されるけど、速度（Velocity）はベクトル量だっていうことを忘れがちだよね。正しい方向に向かってなきゃ、いくらスピードを上げても目的地には早く着けない。コースを大きく外れてたら、加速するのは逆効果で、目的地に着くのがかえって遅くなる。 LLMベースのコーディングツールについて聞く良い話も悪い話も、だいたいこの単純な事実で説明がつく気がする。調査やデモ作成にAIを使うのは、進むべき方向を決めるのに役立つ。エージェント型のワークフローも、AIが脱線しないようにガードレールを引く作業に近い。今のところ成功例の多くはこのパターンだよね。一方で、単にプロンプトを投げて既存システムに新機能を追加させようとすると、勘違いや思い込みでデッドエンドに突き当たることが多い。方向がわからないまま爆速で動いてるだけなんだ。

いろんなところで似たような話を聞くね。「時間は取り戻せない」という問題は、早めに理解しておいたほうがいい。お金を稼ぐために必死に働いて、子供が育つ過程を見逃した知り合いを何人も知ってるけど、「子供が小さかった頃の時間」は後から買い戻せないんだ。 エージェント型コーディングって、なんかビデオゲームのガチャ（ルートボックス）を引く感覚に近い。レバーを引いて、エピックな武器が出ることもあれば、ただのゴミが出ることもある。生成されたコードが「良い」か「使える」かなんてことより、「UIを頼んだら一瞬でガツンと出てきた！」っていう興奮の方が勝っちゃってる感じがするな。

最高の記事だね。良いプロジェクトには100個の新機能より改善（イテレーション）が必要だってことを、みんな忘れちゃってる気がする。機能を最高の状態にするには、いろんな段階で何度も作り直す必要がある。 1）開発者は自分の考えが正しかったか、変更がシステムにどう影響するかを作業しながら確認し、コンテキストを積み上げていく。 2）一度作った機能はそれで終わりじゃない。みんなもっと良く、速く、スムーズにしたいと思うもの。でも、じっくり磨き上げる代わりに次の機能に移っちゃう。今の機能をいじる時も、改善じゃなくてやり直しになっちゃってる。 コーディングにAIを使う流れは定着すると思うけど、何のために何を作っているのかっていう強い理解はこれからも必要だと思う。

ニーチェの考えで好きなのが、文明が概念を「消化」して同化させるには何千年もかかるっていうやつ。当たり前っぽく聞こえるけど、今の世の中の前提って「あらゆる問題は単なるリソースの問題だ」みたいになってる。 例えば、高度な技術は単なる数学の問題であって、現実世界で動かし、学び、時間をかけて教訓を統合していくプロセスじゃないと思われてる。 別の言い方をすれば、経験が過小評価されて、知識が過大評価されてるんだ。たぶん経験は代替不可能だし、市場システムで簡単に数値化できないからだろうね。 ※1. たぶんニーチェの独創じゃなくて、もっとヘーゲル的な考えかも。ヘーゲルには詳しくないから断言できないけど。

著者の視点には共感するけど、俺はLLMをワークフローに取り入れてて、自分でも驚くほど開発スピードが上がってる。 でも、ただエージェントに丸投げしてるわけじゃない。チャットインターフェースで対話しながら進めてるし、うまくいかなければ1時間分のやり取りを全部捨てることもある（実際、30分前にもやったよ）。 でも、自力で解決しようとして10時間かけるのに比べれば、その1時間は安いもん。LLM（とgit）があれば、とりあえず試してみて様子を見るっていう使い方ができる。大規模なコードベースで実験して、ダメならバッサリ捨てるなんてことも気兼ねなくできるんだ。 俺のやり方を「不器用で古臭い」と馬鹿にする人もいるだろうけど、結果にはかなり満足してる。他のみんなよりは遅いかもしれないけど、クオリティはめちゃくちゃ高いしね。 一番気に入ってるのは、例えば5つのSDKファイルを全部LLMにぶち込んで、JSONのやり取りを貼り付け、バグの状況を説明して原因を探してもらうこと。10回中9回は、すぐに本当のバグを見つけてくれる。提案された解決策がいつも気に入るわけじゃないけど、原因特定が一番時間かかる作業だから、そこを助けてくれるのはデカいよ。

オープンソースプロジェクトには長年の継続的な努力が必要だっていうのは本当にその通りだけど、多くのプロジェクトがなぜ死んでしまうのか、そこが抜けてる気がする。作者が飽きちゃうこともあるけど、見ず知らずの他人が使うものをメンテナンスするのは、自分のために作るのとは全く別の仕事なんだよね。その転換の大変さは、誰も教えてくれない。

「何人の女性を割り当てようと、子供を産むには9ヶ月かかる」 ―― プロジェクト管理についてのフレッド・ブルックスの言葉だね。