来たるループ
(lucumr.pocoo.org)- コーディングエージェントの外側で作業キューとハーネスが反復を管理するハーネスレベルのループが、エージェントエンジニアリングの新たな中心パターンとして浮上している
- モデルが長く自律実行するほど、強い不変条件よりも局所的な防御や fallback を積み増しやすくなり、長期保守コードでは設計理解と統制が揺らぐ可能性がある
- 逆に、コード移植、性能実験、セキュリティスキャン、研究のように、結果を検証または破棄しやすい領域では機械的な反復がすでに強く機能している
- 攻撃者とレポーターがループを回せば、メンテナーも triage、再現、対応に機械を使わざるを得ない圧力を受け、curl の事例は AI 生成レポートが生む負荷を示している
- 今後の課題はループを使うかどうかではなく、その中でも人間の判断とエンジニアリングの規律、責任ある監督、理解可能なアーキテクチャを維持することにある
コーディングエージェントの外側で回るループ
- コーディングエージェントの内部にはすでに、モデルがツールを呼び出し、結果を反映し、ファイルを読み書きし、テストを実行してから応答を返すエージェントループがある
- 新たに目立ってきたパターンは、その外側にあるハーネスレベルのループである
- タスクがキューに入る
- 機械がそのタスクを拾って試行する
- 停止した後、ハーネスが本当に完了したかを判定する
- 終わっていなければ、同じセッションにメッセージを注入するか、修正したコンテキストで新しいセッションを開始するか、別の機械にタスクを渡す
- この外側のループは、モデルが通常「終わった」と言う地点を過ぎてもタスクを生き続けさせる
- ループ自体は新しくないが、最近はエージェントエンジニアリングや Twitter 上の議論でより頻繁に見られるようになっている
- Pi 上でもこうした流れは一部見られ、Pi はハーネスであるため、こうした実験の中心に置かれている
長く保守するコードで生じる居心地の悪さ
- 深く気にかけるコードには、まだこのやり方はあまり合わない
- 核心は好みと統制にある
- デプロイするコードを理解していたい
- プレッシャー下や他人との議論の場で、まず機械に説明させなくてもシステムの振る舞いを説明できる必要がある
- 現時点では、コード理解は依然として重要だ
- 手を離して生成されたコード、とりわけループから出てきたコードには、繰り返し現れる問題がある
- 防御的すぎる
- 複雑すぎる
- 局所的な推論にとどまる
- 強い不変条件を避ける
- 誤った状態を不可能にするのではなく fallback を追加する
- 重複コードや悪い抽象化を生み、曖昧な設計をさらに多くの仕掛けで覆い隠す
- Claude Code と Fable のような組み合わせは、一つの問題に 30 分以上途切れず取り組めるため、以前よりhuman in the loopが減っている
- 現在の、手を離したハーネス方式のコード品質は昨秋よりむしろ悪くなったと感じられるほどで、少なくともこの好みからすると改善はほとんど見えない
ループがモデルの癖を増幅する
- モデルは局所的な失敗を見ると、局所的な防御を追加する傾向がある
- Andrej Karpathy は、モデルは例外を「致命的なほど恐れている」と述べている
- 重要な不変条件を持つシステム、特に永続データ形式や中核インフラでは、「あらゆる malformed case を処理する」というやり方が正しい修正でないことがある
- より良い方向は、malformed case を表現できないようにするか、最初から書けないようにすることだ
- LLM は多くの手動操舵があっても、この種のコードを自然に出すのが難しく、不可能になったエラーまで処理しようとすることがある
- この癖をループの背後に置くと、問題は増幅される
- 各反復が小さな防御を一つずつ足していく
- システムはより堅牢に見えるが、次第に理解しづらくなる
- 手を離すほど、この傾向は強まる
- 明確な指針なしにジュニアにこの種のツールを与えると、悪い実践を学習させてしまうかもしれない
- 理由を問えば、もっともらしく自分の選択を弁護できてしまう
ループがうまく合う領域
- ループのパターンは、すでに一部の領域では非常にうまく機能している
- コード移植は代表例である
- Bun の一部を Zig から Rust に移す作業のような大規模な自動移植の事例がある
- MiniJinja を Go に移植する際にも成功裏に使われている
- 性能探索にもよく合う
- 機械が実験を試す
- ベンチマークを実行する
- 失敗を捨てる
- 探索を続ける
- セキュリティスキャンや、ほぼあらゆる種類の研究にも自然に適合する
- 複雑な問題空間を探索し、結果を報告させられる
- 必ずしも長く残るコードをコミットする必要はない
- 成功している事例に共通するのは、成果物が長期保守を要しないか、既存コードの変換であるか、proof of concept・アイデア・発見・機械的変換に近い点である
- ハーネスに必要なのは、完全に客観的または二値的な信号ではなく、次の反復を前に進めるのに十分役立つシグナルである
- 多くの成功事例では、別の LLM を judge や orchestrator として使っている
- 機械的翻訳は binary test case で検証することもできるし、LLM に判断させることもできる
- Claude Code は、実験ワークフロー全体を作って実行することにますます長けてきている
- 生成コードが雑であっても、それはハーネスの判断能力よりモデル側の問題に近い
ソフトウェアを機械より生物のように扱う変化
- 長く残るコードを同じループ方式で書くことには、まだ抵抗がある
- 従来の理想は、ソフトウェアを決定的な機械のように理解することに近かった
- 一層ずつ剥がせば、より深く理解できた
- 非決定的に観測される機械は、理想的とは言いがたかった
- アーキテクチャは、より多くの決定性へ向かうのが望ましいとされていた
- 新しいエンジニアでも複雑なコードベースを探索できるようにすることが良い設計だと考えられていた
- うまく設計されたシステムには、どこに不変条件があり、どの部分が load-bearing で、どの変更が安全かを把握しているエンジニアがいた
- 大規模ソフトウェアはすでに人間の頭にすべて収まるものではなく、分散システムには、医師が症状を見て仮説を立て、さらに検査を指示するように診断される側面がある
- LLM はこの方向をさらに速く押し進める
- 本番障害が起きると機械がログを読む
- root cause を提案する
- パッチを上げる
- 別の機械がレビューし、ときには人間の監督なしで main に反映する
- このやり方は強力で魅力的だが、人間は以前のようにはシステム全体を理解できなくなるかもしれない
- 扱い、監視し、安定化はするが、必ずしも理解はしない
- すべてのコードが人間の著作を必要とするわけではなく、過去にももっとひどいコードは書かれていたかもしれない
完全には抜け出しにくい圧力
- 完全な機械主導の未来からopt outするのは難しいかもしれない
- 最も分かりやすい例はセキュリティである
- 自分がループでソフトウェアを作っていなくても、他人はそのソフトウェアを対象にループを回している
- 攻撃者は機械を回し続ける
- 攻撃者でなくても、セキュリティ研究者が自動化された作業を行う
- その結果、本物の問題とノイズが一緒に流れ込む
- Daniel Stenberg の curl に関する summer of bliss は、メンテナーがすでに受けている圧力を示している
- curl の中核開発で AI が大きな役割を果たしているようには見えない
- それでもメンテナーはレポートに圧倒されており、その大半は AI 生成レポートである
- 攻撃者とレポーターがループを回すなら、防御側も追随しなければならない
- 必ずしも自分で直接パッチを書くためとは限らない
- triage、再現、対応の圧力ゆえに機械を使わざるを得ない可能性がある
- 競争圧力も同様である
- あるチームは、純粋な速度だけで他チームより多くを作れるかもしれない
- 小さなグループが機械をうまく調整すると、プロジェクトが突然加速することがある
- スタートアップの中には、以前なら 50 人必要だった仕事を 5 人でこなせるようになるところもあるかもしれない
- 誰かがその製品を対象にループを回し、「別物のように作り直せ」と指示できるかもしれない
- すべてのソフトウェアが同じように影響を受けるわけではない
- ある領域では雑さが罰せられ、信頼と責任が求められる
- 多くのソフトウェアでは、速度、迅速な実験、広いカバレッジが非常に重要である
ループが生む新たな依存
- ループが作るツールは、単なる一回きりのコストではなく、継続的な認知的依存を生みうる
- 以前のソフトウェア開発は、コンパイラのような高コストな道具に依存していたが、今のツールは継続的にアクセスする必要があるシステムに近い
- コードベースがループで作られ、ループでレビューされ、ループでパッチされ、ループで保守されるなら、同水準のシステムアクセスが途切れたときに問題が起きる
- 貿易制限によって最も強力なモデルへのアクセスが失われるかもしれない
- コストが負担不能になるかもしれない
- チームが、機械なしでコードを理解する最後の能力を失うかもしれない
- 人間にとって保守しづらいという程度を超え、機械の参加を保守モデルの一部として前提にするコードベースが生まれうる
- すでにいくつかの変化が見えている
- 完全には説明できないコードをマージする人が増えている
- issue レポートやチャットでの議論を、機械が提供したコンテキストで補強したり書き直したりしている
- 要約と文脈化を機械に依存している
- LLM を介して会話する人がより頻繁に見られる
- これが必ずしも間違いだと言い切ることはできないが、従来のやり方からの大きな変化である
これから必要になるハーネスとツール
- より多くのループをオーケストレーションするだけでは十分ではない
- 変更、オーケストレーション、エージェントをよりうまく可視化しても、理解が自動的に回復するわけではない
- 必要な方向は次の二つのどちらかである
- 人間を再びループの中へ強く引き戻し、ループによる変更を長期的に読めるようにする方法
- ますます複雑になるシステムを、よりうまく構成する方法
- Pi に対する考えも変わってきている
- Pi は慎重だったし、その慎重さは良いことだ
- あらゆる相互作用が、追いかけにくい機械の群れによる変更へと変わる未来は望まない
- Pi が、自分自身を書くソフトウェア競争に勝つために保守不能な混沌になるのも望まない
- Pi がこうしたエンジニアリングを助長することも望まない
- それでも Pi はハーネスであり、ハーネスは新しい実験の中心にある
- コーディング作業キュー、エージェントオーケストレーション、subagent、durable session はますます重要になるだろう
- ループを盲目的に受け入れない人も、実験は始めるべきである
- この未来を境界の内側に留め、耐えられるものにする方法を理解しなければならないからだ
ループを制御するという問題
- ハーネスループを受け入れると、仕事がいつ終わったかをハーネスが決める
- エージェントループでは、モデルが最終的に「done」と言い、人間がレビューする
- その前にも、通常は人間が途中で操舵する
- 人間は関与し、その過程で学ぶ
- ハーネスが運用するループでは、人間の役割が不明確になる
- 「done」のシグナルも意味を失い、別の機械が判断するためのメッセージになる
- 人間の役割はメッセンジャーに近づくかもしれない
- 現時点でこの方式で作られたコードのかなりの部分は好みに合わず、AI 支援で作られたソフトウェアとの相互作用も心地よくない
- ループは強力だが、責任を徐々に取り除き、現時点では機械への服従を促す側面がある
- それでも、ループの未来はやって来るように見える
- ごく小さなチームが不可能に見える速度で構築する事例がすでに見えている
- コードベースは、より曖昧で混沌とした有機体のように変わっている
- そうしたコードベースは、同時に有用で雑でもある
- 今後の問いは、「ループを回すかどうか」ではなく、むしろ次のようなものになる
- ループの中で判断を手放さない方法
- 良いエンジニアリング規律を保つ方法
- 責任ある人間が継続して監督できるようにする方法
- 正気を保てるよう、コードアーキテクチャをどう考え直すか
1件のコメント
Hacker Newsの反応
ループは、事前に自分の望むものを十分に理解する時間をかけたときに機能する。前提は明確さであり、ジュニアの同僚に渡せるくらい慎重な仕様を書ける必要がある。
たいてい、そこまで理解するには壊れた雑なバージョンを5〜6回は経る必要がある。この5〜6回の試行錯誤は加速できず、どんなエージェント技術でも人間の脳が考える時間を回避させてはくれない。だから大半の時間は、「自分が何を望んでいるのかわからない、コードを読んで書いていじってみる必要がある」と「もう十分時間が経って、何を望んでいるのかわかった気がする」の間を行き来して過ごすことになる。自分をだますのはとても簡単だが、本当に望むものがわかって初めてループを使える。多くの人はエージェントで先回りできると思っているが、理解と明確さは真似できず、その段階を飛ばした人は痛いほど目立つ
何を望むかを長く考える必要はなく、ただそれをやらせたかっただけだ。結果はまだ入り混じっていて、繊細なコードベースを任せられるほど信頼はしていないが、作っているゲームでは確認に使う時間が以前の1/5に減った。必ずしも良いことばかりではない。時間を減らしたことで良いアイデアを見逃している可能性が高い。ただ、以前はプロンプトが機械的に
#now-do-this、#now-review-thatになっていて、提案の90%が正しい状態で停滞していた。今は「難しいことからやって、進めながら整理・リファクタリングせよ」と、最初の返答の後に「作業を振り返れ」と自動で思い出させ、残っている問題を吐き出させてから、それをガイド生成プロンプトに入れて新しい作業をばらまけばよい反復は速くなったが、その雑なバージョン群を通るのに必要な労力はほぼ同じだ。依然として、どのアイデア、原則、設計が解法に合っているか、次に何を試すかを理解し、自分のメンタルモデルを調整しなければならないからだ。結局、より短い時間の中でより多くの精神的努力を使っている感覚で、コードを書く部分で少し節約できる程度だ。熟練していれば、コードのタイピング自体はもともと大きな比重ではなかった。「ただ」プロンプトを書いてコードを読むだけのように見えても、同じように疲れるし、圧縮された反復サイクルのせいでさらに疲れることもある
最近は毎日こういうことを経験していて、気落ちするし不安になる。完全には説明できないコードを以前より多くマージしている理由は、以前はコードを書くことや協調的な技術計画を通じて築いていたメンタルモデルを、今はコードレビューに任せているからだと思う。
コードレビューはこの目的には向いていない。ただし、教育学を参考にした構造化された練習をコードレビューに組み合わせることで、摩擦と理解のバランスをもっと良くできるとは思う。こうした練習をテストするのを手伝ってくれる人を探している
GitHubの貧弱なPR UIも助けにならない。直接変更されてはいないが影響を受けるコードベース周辺を探索して問題を見つけ、強調するためのツールが限られている
間違った境界条件を代替経路で処理するのではなく、不可能にするシステムを好むべきだという原文の指摘はとても重要だ。代替経路方式は、代替経路の上にさらに代替経路を実装させ、各代替経路がコード量を幾何級数的に増やし、しかもなぜか常に新しい問題を生む。ほとんど「システム設計の一般法則」と呼べるほどだ。代替経路は失敗リスクを下げるが、実際に失敗が起きたときには、より複雑で有害なものにする。ソフトウェアエンジニアとしては、AIが生み出す新しいコーディング環境は気に入っている。ビッグテックが自分のために無限の仕事を作ってくれたからだ。人間の開発者はコード実行の中核的な構成要素になり、必ず時々発生する、ほぼ無限にある難しい未処理例外に対処するため、常に待機しなければならない。今やソフトウェアエンジニアは労働者というより、たいてい机に座ってコーヒーを飲み、まれに問題が起きたら介入する警備員に近い
ここ数か月言ってきたこととつながる。LLMはタスク完了には優れているが、美意識や好みには弱い。
仕事には二種類ある。ひとつは目標志向の仕事で、達成すべき目標があり、そこに至る方法はあまり重要ではない。セキュリティは完璧な例だ。システムをエクスプロイトしたいなら、そのエクスプロイトが美しいかどうかはほとんど気にせず、ただ極秘の核計画にアクセスしたいだけだ。研究も似ていて、「研究品質」のコードはAI以前から悪名高くひどかった。もうひとつは嗜好志向の仕事だ。大きなコードベースに機能を追加するとき、目標はその機能追加だと思いがちだが、実際にはそうでないことが多い。コードベースを将来の変更を受け入れやすい状態に保つことのほうが、その特定の機能よりずっと重要で、そこにはセンスが必要になる。保守性とコード品質は同義ではなく、コード品質は手段にすぎず、その目的は保守性だ
LLMが自然に誤ったケースまで処理しようとする問題は、多くのPRレビューで戦ってきた部分でもある。特に一度書かれてしまった後では、過剰なnullチェックが有害だと説得するのが非常に難しい。
より良いモデリング、そして合併型を許す言語でもない限り、こうした「散弾銃的パース」に対して普遍的に通用する反論はまだ見つけられていない。もしかすると本当に大きな問題ではないのかもしれない。だが実際にコードベースを読んでリファクタリングするときには、こうした不要なチェックを管理するのはいつももどかしかった。いったん入ってしまうと、ロギングや広範な調査を先に追加しない限り、安全に削除するのがほぼ不可能なことすらある
これこそが、望ましくない状態を表現不可能にするという言い方の核心でもある
いまは何もこの関数に負の値を送らないとしても、将来のコード変更でその前提が壊れるのはどれほど難しいだろうか？ 明確なエラーが最善だとずっと考えてきた。コードに不慣れな人でも、入力の有効範囲にどんな前提があるのか分かるし、不可能な外れ値を考慮する必要もなくなる
私のボトルネックは仕様にある。エージェントループはいまや私にとってそれほど重要な問題ではなくなった。
作りたいものを明確に理解し、Claude Codeの計画モードで実行可能な仕様を書くことを目標として伝えると、エージェントが実装に入ったとき概ね非常に良い結果が出る。だがこの効果的な戦略は、仕様を書く負担を私に大きく負わせる。エージェントは各仕様をたいてい見事に処理し、コードレビューに基づく後続作業も通常2〜3回で済むが、すぐまた仕様が必要な段階に戻る。そして私が席を外している間にエージェントが一つの作業を終え、ファイルが重ならず衝突のない既存仕様を始められる場合でも、新しいブランチを作って始めてよいとは分からない。寝る前に「作業Xをして、完了・pushしたら作業Yを始めろ」と言ったりするが、それ以上はあまりうまくいかない。しばしばYを始めたところで質問が生じ、その後エージェントは残り時間ずっと止まってしまう。最後の問題は、上と結びついた依存関係だ。たとえば今日はバックグラウンドのジョブワーカーを書いたが、当然その後の作業のジョブはそのシステムを必要とする。こういうことはかなり頻繁に起きる。実装中に決まった細部を反映するためには、仕様自体も実装後に更新しなければならない。それでも、いまや外側のループが必要になる直前まで来ている。関門はほとんど完全に仕様作成とPRレビューにある。その関門が重要でないところでは、エージェントに回り続けてほしい。ついでに言えば、私たちは、自分たちには使いにくくてもLLMにはより良いツールを使い始めるべきだと強く思う。たとえばRustは、コンパイラが厳しすぎて私には煩わしいが、LLMには素晴らしい
いまや作ることがより自動化されたのだから、仕様とシステム設計が再び重要な先導役を担える。エンジニアリングと品質が戻ってくるかもしれない
AIは技術的に動くそこそこの解法を作るのは得意だが、解法について良いビジョンを持つのはかなり苦手だ。アイデアをやり取りして探索しながら理解を深めるのには、依然として非常に有用だが、LLMが実装できる良い仕様を書くことは、自分で直接コードを書くよりはるかに簡単というわけではない
https://www.aihero.dev/skills-handoff
/handoffは最近できた私のいちばんお気に入りのスキルだ。https://www.youtube.com/watch?v=dtAJ2dOd3ko
エージェントがいようがいまいが、パンチカードだろうがインタープリタだろうが、突き詰めればプログラミングはプログラミングだ
LLMの最大のコードスメルは、「あらゆる誤ったケースを処理」しようとして、今では不可能なエラーまで処理しようとする点だと思う。なぜそこまで執着するのか分からない
Pythonでは、完全に型検査されたコードベースで、その属性が存在すると定義された型に対して
hasattrチェックを付ける形でよく現れる。なぜこうなるのだろう？ 事前学習のせいなのか、強化学習のせいなのか気になる。後者なら研究所には直してほしいHNではこの話題がよく出るが、オープンソースでも職場でも、自分が書いていないコードベースがこれを本当にうまくやっているのを見ると今でも驚く。ほとんどのプログラマは、エラーが起きないようにしてデータにその事実を反映させるより、エラーメッセージが飛び出した地点で破片を拾って直すような考え方をする。「ほとんど」と言ったのは、今のAIにもこうした思考様式そのものの問題があると見ているからだ。人間がコードベースを最終段階で理解する水準、つまり保証の流れを全体として理解する水準を、今のAIに与えるのは難しい。生のコードのレベルでは、こうした保証がコンテキストウィンドウを簡単に吹き飛ばすほど多くのコードにまたがっていることが多い。メモリ風のファイルに要約しようとしても問題がある。保証に関するテキストが書かれているからといって、AIが正しい情報を取り出すとは限らないし、人間でもコードだけを読んで同じことが起きる。AIにこうした理解を与えるのが「不可能」だとは言わないが、仮に理解させられたとしても、AIの作業のしかたはその理解にしばしば逆らって働く。自分の解決策は、たいていAIがこれを理解することを諦めることだった。普通の人がするように問題の解法をプロンプト化し、不正な悪い状態を表現不可能にしたいなら、必要なリファクタリング過程をAIに段階的にやらせる。とても小さければ自分でやる。マップ/辞書、配列、文字列、整数だらけのコードを、より徹底して型付けするよう段階的に指示すると、実際かなりうまくやる。どれだけ詳しく書いても、単一のプロンプトで良い設計が出てくることはあまりなかった。2つの別作業として扱うほうがうまくはまる。そして型の違いを注意深く見なければならない。AIは
.JustSetItAndIgnoreAllThePreAndPostConditions(string)のようなメソッドをこっそり差し込むのが好きだ。現場には、「エラー状態を表現不可能にするよううまく構造化された型に、後から保守担当者がやって来て、すべてを壊すJustEffingDoItメソッドを追加した」学習データが多いのだと思う。最善の防御の1つは、こうした型を専用ファイルに置き、追加されたすべてのメソッドを簡単にざっと見られるようにして、そんなことをしたらすぐ直すことだ。ドキュメントに、やってはいけないという警告や、維持される事前条件・事後条件を山ほど書いてみたが、変化はわずかだったgetattrを使うのは奇妙な選択だコードは、情報システムについて共有され蓄積された理解の一部だ
こうしたループが、絶えず押し寄せるソフトウェアの波の中で私たち全員を動かし続けるのだとしたら、最も高いレベルの論理的な情報システム設計では、結局のところ人間の判断とビジネス要件のバランスがすべてになる。会社や市場の特定のニッチに合わせるには、すべてのプログラマがビジネスアナリスト、市場調査者、事業家にならなければならない。ただし、AIツールがうまく「ガタつけない」特定のニッチや、補助金付きのAIトークン時代が終わってこうしたループが高くつきすぎる場合は別だ。これは、エキスパートシステムや Symbolics Lisp マシンの繰り返しのように感じられる。しばらくの間、私たちが突きつけられた事実は、コードそのものに何かができないというより、会社の組織構造が結局そのままソフトウェアに載るので、会社組織を変えられないならソフトウェアの柔軟性にも限界がある、ということだった。データフロー図とドメイン知識、ドメインモデリング、ユビキタス言語が、私たちが品質、機能、非機能標準と慣行を定める メタ言語 になりうる。「ループを回る clanker」たちが「完了」と言う前に、データ・動作・性能の契約を満たすようにしなければならない。今や「完了」は、コンパイルできるコード、ビルドできるコード、デプロイできるコード、さらには本番運用に載ったコードだけを意味しない。ユーザー要件、運用者要件、保守者要件をすべて満たすコードでなければならない。だから、使われる言語は、私たち全員を文法を知っている人というより、ビジネスアナリストやソフトウェアアーキテクトに近づけるかもしれない。UMLの復讐と、宣言型・論理型設計・BDDの回帰なのだろうか？
スペルチェックは gemma4-12b で行ったが、メッセージは変えさせなかった
いつから自分がループの中に無理やり入っていなくてもよくなるのか、ずっと考えている。開発者として、コードの構造を磨き、より明確にし、良い抽象化を考え、モジュールに分けるのが本当に好きだ
そこに楽しさを感じるが、ある時点で自分が制約要因になることも理解している。ソフトウェアの目的が人々に利益をもたらすことなら、コードがどう見えるかを今でも気にするべきだろうか？ 今は答えが「そうだ」と思うが、3年後は？ 10年後は？
何かが多くの判断を要求し、しかも「自分が深く大切にしているコード」なら、ここで述べられている方向性には同意しにくい。自分が深く気にかける判断を委任しようとすべきではない
エージェントループとハーネスループという区別は気に入っているが、あらかじめ正確に仕様化できるものだけを委任すべきだ。私の場合はたいてい反復可能な作業、たとえば「Xをどうやったか見て、Yにも同じようにやって」のようなもので、これは本質的に予測可能な仕事だ。自分の判断が抜けたら結局自分が「ノー」と言うようなことなら、Arminが言うエージェントループの中で協業する方向に戻るべきだ。それでまったく問題ない。速くて安全だ。AIコーディング支援以前にも、ときどきとてつもなく生産的なエンジニアがチームに入ってくることはあった。同僚たちは「君たちがそれを全部やり切れたのは、チームにXがいたからだろ！」と羨ましがったが、そういう人をそばに置くことの呪いは経験していないのだ。完全に足並みがそろっていなければ、彼らはものすごい速度で間違った方向へ走っていく
これが実際に何を意味するのかわからない。より大きな絵を示唆するよう設計された抽象概念を並べた長広舌な文章にすぎず、結局はAIにコードを書かせる話だ
これからはこうなるのか？ 実際には私たちはソートリーダーではなく、AIの間抜けな群れを正解の方向へ追い立てようとする疑似教師になりつついるのに、それでも思考のリーダーのように見せるために役割を神秘化しなければならないのか？ それが全部技術的なハッタリだと見抜かれないようにしながら？
筆者はもっと簡潔に磨き上げることもできただろうが、現状のレベルで読者が内容を理解できないからといって、神秘化が起きていることを意味するわけではない
私は仕事でも個人プロジェクトでも、原文が言っていることをまさに目にしているのだが、これを「抽象概念を並べた長広舌な文章」と見る人がいるのは恐ろしい。大多数は今起きていることをまったくわかっていないのではないかと思う
AI分野では最新最高技術の賞味期限は2週間ほどだ。Ralph Wiggumループに追いつけていなかったが、今では追いつこうとしなくてよかったと感じている
https://news.ycombinator.com/item?id=46682325