AIロックスター開発者たちの後始末
(codingwithjesse.com)- 過去の「ロックスター開発者」が残した理解しにくいコードベースの問題が、LLM生成コードの拡大によってチーム全体の 保守負担 として大きくなっている
- ロックスター開発者は新技術、新しいパラダイム、新しいアーキテクチャを素早く導入し、難しい仕事をすばやく終わらせたが、他の人が理解して一緒に作業できるコードを書くことには関心が薄かった
- LLMエージェントは以前の作業を記憶しないまま、短時間で数万行のコードを作り、システム全体に合っているかや理解しやすさが向上するかには気を配らない
- 生成コードが増えるほどシステムの 複雑性 は大きく増し、それを理解するために再びLLMに依存する流れが生まれる可能性がある
- 長く使われるソフトウェアには、LLMを小さなコード断片の生成に限定し、人間が設計を主導し、問題の複雑さに合わせてアーキテクチャを単純化する姿勢が必要である
ロックスター開発者が残した構造
- ロックスター開発者はチームに加わると、新技術、新しいパラダイム、新しいアーキテクチャに対する強いアイデアを提示する
- 会社の中核アーキテクチャの大半を書き直し、新しいビルドプロセスやツールや言語を導入する
- 多くのプルリクエストを却下し、チームメンバーに求められる基準を引き上げたが、他の人たちはそのコードを理解できるかどうかを表に出せない
- 最も難しい作業はロックスター開発者に割り当てられ、彼は他の人より速く終わらせる
- 他のチームメンバーは新しいライブラリを学び、ロックスター開発者のやり方に合わせる必要があるため、動きが遅くなる
- 数年後、ロックスター開発者はより難しく大きな会社のプロジェクトを求めてチームを去る
余波に対処する
- 残されたチームメンバーはロックスター開発者のプロジェクトを引き継ぎ、コードの中で圧倒される状況に直面する
- データフローは追いにくく、まるで誰かが殺人を隠蔽しようとしているかのように感じられるほどだった
- 単純なバグ修正から始めたが、ノートPCでコードを実行するだけで1週間かかった
- コードの半分は理解できない言語で書かれ、残りの半分は聞いたこともないライブラリで書かれていた
- コードの書き直しが必要だと上司に伝えたが、ロックスター開発者が書いたコードだという理由で受け入れられなかった
- 雑然としたコードをさまよううちに、求人情報を眺めながら去ることを想像するようになる
ロックスターの後片付け
- 多くのチームやエージェンシーは、このようなロックスター開発者が残したコードベースの整理を必要としている
- 複雑なコードベースを理解して救い出す過程は、絡まった電球のコードをもう一度使えるようにほどく作業にたとえられる
- ロックスター開発者はコーディング、学習、新しいパラダイムの利用を好み、自分の能力の限界まで押し進める
- 可能な限り賢いコードを書こうとし、できるだけ速く動くことに集中する
- 他の人が一緒に作業できるコードを書くことは、ロックスター開発者にとって最も優先度の低い仕事になる
人工知能の登場
- ここ数年、多くのチームはロックスター開発者の軍団に圧倒されるような状況を経験している
- 誰かが新しいチャットを始めるたびに、チームへロックスター開発者を追加するリスクが生まれる
- エージェントは昨日やったことを覚えておらず、数分で数万行のコードを生成する
- エージェントは人間には不可能なほどの速さで作業完了を追求する
- 生成されたコードがシステム内の他のコードと合っているか、システムがより理解しやすくなるかには関心を持たない
- AIは、その状況には適していないかもしれないベストプラクティスの道具箱を抱えている
- 複雑性が利益を上回るときでさえ、AIは「ベルトとサスペンダー」方式の過剰な安全装置にこだわる
- コードレビューを依頼すると、簡単には同意しにくい項目が多い長い改善リストを作り出す
- LLMを使わなければ永遠に取り残されるように感じる人が増えている
- LLMにすべてのコードを書かせるやり方は、結局は取り残される結果につながると見ている
何百人ものAIロックスターの後始末
- 雑然とした生成コードの山を整理することは、ロックスター開発者1人のコードを整理するのと同じくらい楽しいわけではない
- 少なくともロックスター開発者には何らかの設計意図があり、最善を尽くそうとする試みがあった
- バイブコーディングで作られた雑然としたコードの山は、1人の人工開発者が書いたものではない
- 複数のチャットと複数の文脈の中で、機能1つあるいはバグ修正1つずつ生成されたコードベースになる
- これは、何百人もの異なるロックスター開発者が書いたコードベースに近い
- 場合によっては、技術的負債が大きくなりすぎて、決して返済できない水準に達する
長く生きるソフトウェアを作る
- LLMをロックスター開発者のように振る舞わせない形で使う方法はいくつもある
- 人間がエンジニアリングを主導し、LLMには一度に小さなコード断片だけを生成するよう導くことができる
- チームメンバー全員が容易に理解し、作業できる形でソフトウェアが書かれていることを確認しなければならない
- LLMが何をなぜしているのか理解できないまま迷走しているなら、速度を落とすべきである
- 生成するソフトウェアの品質を保証するために、よりゆっくり進めるのは問題ない
- 過剰なエンジニアリングを防ぎ、アーキテクチャが問題の複雑さに見合うまで単純化し続けてもよい
- ときにはLLMを道具箱にしまったまま、自分でコードを書くのもよい
- 職人技は常に人の手に残るものであり、機械にアウトソーシングできない領域である
2件のコメント
Hacker Newsの意見
「職人技は常に人の手に残り、機械に外注することは決してできない」という最後の一文は少し気がかりだ
他の産業でも職人技が死んだわけではないが、はるかに安くて手に入りやすい代替品に押しやられてきた。手作りの革靴は今でも買えるが、$1000以上払いたい人は少ないし、何週間もかけた絵も買えるが、たいていの人はHomeGoodsで壁飾りや雑貨を買う
核心の違いは 使い捨てであるという前提 であり、残念ながらソフトウェアも次第に他の製品のように「使い捨て」になりつつある。単純なカウントダウンアプリなら捨ててもよいが、長く動き続ける業務プロセスを支えるソフトウェアはそう扱うべきではない
ソフトウェアの職人技に焦点を当てると、問題が「自分の用途に必要なもの」対「ブティック風で高価かつ不要なもの」に見えてしまうかもしれない。実際には「保守可能で信頼できるもの」対「捨ててもよいもの」であるべきだ
この流れがOpenAIやAnthropicのような大手モデル提供者に利益をもたらすかどうかとは別に、ここで言いたいのはそこではない
平たい箱に入って届き、自分でドライバーを使って組み立てた安い机も工場で大量生産されたものだが、その 設計 にはオーダーメイド品よりはるかに多くの専門家の職人技が込められているかもしれない。高い初期設計コストをかけた後、低い限界費用で大量生産する構造だ
ソフトウェアは最初からだいたいそういうものだった。Firefoxをダウンロードするとき、職人が自分専用にWebブラウザを作っているのではなく、どこかのデータセンターにあるCDNサーバーがキャッシュからバイト列をコピーしているだけだ
AIが脅かしているのは、他の産業では大規模には起きたことのない 初期投資型の職人技 の代替だ。AIがよりうまく置き換えてきたのは低価格の「手工業的」ソフトウェアで、これはこれまで採算性が低すぎて事実上存在しなかったカテゴリだ
そのため 品質への投資 にずっと大きなレバレッジが生まれる
ソフトウェアが同じ意味で使い捨てだという点にも同意しにくい。一時的な問題ならコードを捨てて、別の問題が生じたときに新しく作ればよい。しかし継続する問題なら、コードは残り続ける
ねじはかつては特注の貴重品で、良いねじを1本作るのに途方もない時間と労力が必要だった。今われわれが 機械ねじ と呼ぶものも、非常に熟練した人が極度の手間をかけなければ作れなかった
しかし機械は職人技を移すことができる。本当に良いねじを1本作れば、機械がそのねじの品質を無数の新しいねじへ移転してくれる
現代では、あらゆる種類と品質のねじがほとんど同じように消耗品になっており、昔なら手で何日も何週間もかけて削っていたようなねじを、今日では何十億本も作っている
AIもリードスクリューのない旋盤のようなものだと見ている。最初は自分の手でねじを作らなければならず、その後は自分が出せる品質をいくらでも新しいねじに移せる。より良いねじを作れるようになれば、それを旋盤に入れて、より良いねじをもっと多く作れる。しかし根本的には、自分が直接作れるねじの品質に制限される。曲がっていてでこぼこしたひどいものしか作れないなら、機械から出てくるのもその程度だ
ソフトウェア開発者は固有の知的財産を作るのであって、ソフトウェアの単位を製造しているのではない。書籍の著者や音楽家に近い
ソフトウェアには単位製造に相当するものはない。単にビットをコピーして移しているだけだからだ
したがって、ソフトウェアの文脈で「職人技」とは、良いものを設計するのにどれだけ気を配るかを意味する。私たちが使うソフトウェアの品質すら重要でなくなる地点に達しない限り、それは消えないし、今のところそうした方向に進んでいる兆候もない
より適切な比較は、靴工場の 製造設備を作り保守するエンジニア かもしれない。消費者からは一段離れているが、そこにも確かに職人技はある
AIや外注コードを直す仕事は好きだ。先週、ある顧客が部署向けのツールをバイブコーディングで作ろうとしていたことを知ったのだが、できあがったのはコンパイルにメモリ10GBを必要とする巨大な Next.jsのゴミ で、lintエラーは数千件、Gitにはうるさい開発ログまで入っていた
いまやこちらが直さなければならないので、こういう案件は繰り返し1万〜5万ユーロ相当のタダ同然の仕事みたいなものだ。何をしているかわかっていればとても簡単で、わかっていなければ不可能だ。どんどん持ってきてくれればいい
中小企業向けの インシデント対応 をしているが、この数年で手に負えないほど仕事が増え、銀行口座は竜の金塊の山のように感じられる
セキュリティは常に統合され計画されるべきだという立場で、インシデントを見たいなどという意味はまったくない
ただ、あいまいな専門性しかない人たちが1時間でアプリを量産できるようになったことは、私のような人間にとってはとてつもない棚ぼただった
この考え方は、人々が金を突っ込む 人間スロットマシン と見ればよい
顧客が来るとき、最初から本番環境に載せる支援を受けるつもりだったのか、それともAIアプローチがすべて失敗した後の最後の手段なのかが気になる
こうしたプロジェクトには典型的な崩壊の仕方があるのか、それとも失敗はたいていもっと微妙な形なのかも気になる
人生で、本当に並外れて優秀だと呼べる人に何人か会ったことがある。"いったいどうしてここまで頭がいいんだ？" と思うような人たちだ。
本当に頭のいい人には二つのタイプが見られるのだが、たいていは互いに排他的だ。一つは、自分がどれほど賢いのか分かっていない人だ。本人にとっては簡単だったり、自分の知っているテーマだったりするので、コンピュータサイエンスの学位を持つ人なら誰でも知っていて、覚えていて、理解しているはずだと考える。暗号関連の数学をすらすら話す友人たちを見て、"その授業は通ったけれど、今君が話したテーマを自分が本当に分かっているとは言えない" と感じたことがある。
もう一つは、自分が周囲の大半より賢いという事実を、痛いほど常に意識している人たちだ。意地悪に振る舞う人もいるし、比較的「愚かな」人たちに囲まれていることにうんざりしている人もいる。後者にはある程度共感する。あらゆることが明白で自明で簡単に処理できる人生を生きながら、答えはずっと前から分かっているのに、人類が愚かな選択を繰り返すのを見続けなければならないと想像してみればいい。
人が右往左往したり、X をやれば明らかに悪い結果である -Y が出るのに X をやったりするのを見ると、気が狂いそうになる。たいていの人は、ただ口に出さないことを学んだだけだ。
近い家族関係では特に不健全だ。あまりにも多く見えてしまって、小言で殺せるんじゃないかと感じるほどだ。
だが、その誰一人として、巨大なめちゃくちゃを積み上げて、チームと自分に何か月も後始末をさせるような 10x 開発者 ではなかった。
どれだけ努力しても大半の人とうまく関係を築くのは難しく、相手もまた特に自分を理解しにくい。生きてきた経験の差が非常に大きく、しばしば乗り越えがたい。
すべての開発者が同じ生産性を出せるわけではないが、文化的な平均を超えて考え続けると決めれば、誰でも自分なりの形で賢くなれる。
ほとんどの人は、自分にそれができると気づいていない。
この二つの文が刺さった。
"データフローを追うのがあまりにも難しくて、誰かが殺人を隠蔽しようとしているみたいだった"
"コードをノートPCで動かすだけで1週間かかった"
データフローを理解したり、まともな開発環境を整えたりするのに苦労するのは自分だけだとずっと思っていた。インポスター症候群 と、ときには「スピード」を押しつける有害な環境も助けにはならなかった。
自分だけではないと分かってよかった。
CLI の Claude Code は、アプリを立ち上げたり、ランダムな依存関係や Docker 関連の問題をデバッグしたりする作業を、以前よりずっと楽にしてくれた。以前はアーキテクチャを学ぶのと同時に、自分のマシンで動かない問題まで解決しなければならなかった。
AI コードではさらにひどくなる。その時点でそれっぽく見えるものを、ただ生成しただけだからだ。
他人が残したものを片付けなければならない人たちが少しうらやましい。少なくともパズルを解いている感じはあるからだ。
今の仕事は本当に退屈だ。ジュニアでもできるくらい単純な作業なのに、わざわざ ミッドレベル開発者 が必要だと言う。自分がこの仕事より上だと言いたいわけでも、ミッドレベルがこういう仕事をしないと言いたいわけでもない。ただ、この会社が作るコードに関心を持てるよう自分を奮い立たせることができない。古びて埃をかぶっていて、重要な人にも使われていない。顧客は昔このツールを買って、つまらないツールだからわざわざ乗り換えるほどの関心もなく、そのまま使っているだけだ。
自分の経験にもっと合った仕事がもうすぐ来ると約束されたが、こんな停滞した会社にそんな顧客が来るとは思えない。
この会社が顧客と従業員を失っているのは驚きではない。だが住宅ローンを払わなければならない。今日は、契約を延長しないかもしれないという話を聞かされ、実質的には同じ給料でもっとオーナーシップを持ち、もっと多く働けと脅されたようなものだった。
残念ながら、本当に面白い新しい職を見つけるまでは耐えるしかない。大金が必要なわけでもないし、「成長」なんてものにもまったく興味はない。ただ生き延びられるだけあればいい。
このコメントはかなり関係ないかもしれないが、申し訳ない。これを吐き出せる他の場所がない。
L63 だったが、やっていた仕事は L60〜L61 でもできるレベルで、David Graeber の言う Bullshit Jobs の一つにいるように感じることがよくあった。報酬は十分だったが、入社ボーナスの株式が終わったとき、自分がその仕事に残っていたのは安定のためだけだと分かった。
Hooli のオフィスのテラスで株式のベスティングを待ちながら日光浴しているエンジニアの一人になった気分だった。キャリア9年目で、今の自分のキャリアにとって最善だとは思えなかった。
ただ、自分には大きな金銭的義務がなかったので、はるかに簡単な決断ではあった。
くだらない会社が作るくだらない製品は、大半の怠惰さやセンスのなさに寄生していて、マーケターがそれを収益化している。
そして今では、さらに悪いことに分野全体が LLM化 していて、それが100倍に増幅されている。コードを保守不能にし、さらに悪いことには、私たち全員をより愚かにしている。
こんなものは見つからなければよかったと心から思う。
単に追加労働や無駄な仕事をしろという意味なのか、実際にもっとコーディングの機会があるのか、それとも急に自分の価値をもっと証明しろという期待なのかが気になる。
あなたの経験を軽く見ようとしているわけではない。後者なら、実際に何かやれることがあるのか気になる。
最初のいくつかのセクションは腑に落ちた。以前の自分はロックスター開発者だった気がするが、それが良いことではないと気づいた
同僚より10倍速く仕事を終えられたのかもしれない。だがある時、それは自分が普通の人より10倍生産的だからではなく、自分のやり方が周囲の普通の人たちの生産性を1/10にしていたからだと分かった
その後は速度を落としたが、人生全体としては前向きな変化だった。チームプレイヤーになることは、この狂った業界で同じレベルの上昇機会を与えてはくれないが、メンタルヘルスには驚くほど良かった
自分の場合はたいてい、不要なものを過度に抽象化したり、実際には起こらないユースケースのために何かを作ったりしていた。だから考えが過剰な抽象化の方向に流れそうになるたび、YAGNIとKISSを思い出すようにしている
この記事は価値が低すぎる
何を言いたいのかもよく分からないし、ただの自己満足な文章に見える
「ロックスター開発者」が残した膨大な量の悪いコードと呼ばれているもののかなりの部分は、実際には要件の変化に対抗して複雑さが長い時間をかけて少しずつ積み上がった結果だった
また、人は「可読性のためにリファクタリングする」と考えることがあるが、実際には「コードを書き直し、その過程で理解する」ことが多かった
もっと中身や実例のようなものを期待していた。記事の90%は著者が不満を述べて問題を定義するのに使われ、最後から2番目の段落で手探りのような曖昧な解決策が出てくる。実際の関連性や有用性はほとんどない
自分が作った収益性の高い2つのプロジェクトの周辺インフラを作らせようとして、プロダクションエンジニア2人を強く急かしたのは本当にばかなことだった
全部を10xボスみたいにスパゲッティコードで作ってAnthropicに移り、9桁の報酬パッケージをもらっていたほうが、ずっと多くの金を稼げたはずなのに。間抜けで、しかもとことん間抜けだった
少なくとも、ここで自分が得た結論はそれだ
書かれたコードは、たいてい作者ではない誰かが保守しなければならない。だから誰にも理解できないコードを書くと、結局は保守失敗につながる
チームが理解しやすいコード、速度、技術的卓越性など、何を最適化するかはそれぞれ違う
だが技術的卓越性を最適化したとしても、チームの他の誰にもそのコードが理解できないなら、やはり失敗だ
過剰設計されたコードを見たことがある
Lobste.rsの意見
この記事には実際に役立つ助言があまりない
「ロックスター開発者」という表現はいつも疑わしいが、優れた開発者が実在するのは確かだ。ただ、そういう人たちは記事で描かれているような振る舞いはせず、既存の環境の中でできる限り働き、コードベースを改善し、未検証の新しいものをおもちゃのように持ち込まず、テスト・スクリプト化されたデプロイ・リンティングなどを通じて、去るときにはより安定した状態を残していく
そこにAIが、こうした振る舞いをさらに悪化させるという形で付け足されているようだが、そういう可能性はあっても、まだ十分に実証された事実ではないように思う。何十年もコンサルタントとして働き、ひどいコードベースを数多く整理してきたが、原因が暴走した個人だったこともあれば、よりよい方法を知らなかったチームだったことのほうが多かった。どちらの場合でも「ロックスター／ニンジャ／流行語開発者がやったんだろう」と思ったことはない
これからはチャットボットが頭上にまき散らしたゴミを片づけるだけでなく、それを気にしない人たちの後始末までしなければならないのか、という気分になる
バブルがはじけるのを待つばかりだ
2026年にある会社に入ったら、まだcreate-react-appを使っていると分かった場合、実際に推奨される振る舞いは何なのか気になる。黙って何も言うな、ということなのか？
古いプロジェクトなら、技術的負債を見つけたということだ。誰にでもある。これを直そうと説得する最善の方法は、ビジネス面で納得できる根拠を作ることだ。動いているなら本当にリスクなのか？ 他の技術的負債と比べて優先順位はどうか？ アップグレードしないことでどんな暗黙のリスクを抱えるのか？ アップグレードに必要な労力はどの程度か？
労力が小さく、同僚たちも望んでいるなら、許可を求めずにそのまま作業するというやり方もある。ただし、この変更の影響を受ける人たちの支持があり、自分の成果物の妨げにならないときに最もうまくいく。入社初週にやることではないかもしれない
たいていは「こうあるべきだ」と言うより、なぜ今こうなっているのかを質問して把握するほうが、常によい。歴史のあるすべてのコードベースは、まだ知らない何千もの判断の結果だ。知識と共感で武装すべきだ
2020年にまだイケているように見えたころから嫌っていた
「エージェントは昨日自分がやったことを何も覚えていない」というのは解決可能な問題だ。メモリアプローチなどを使えばよい。普遍的によいものではないが、徐々によくなっている
「このコードがシステム内の他のコードとうまく合うかどうかを気にしない」というのは、私の経験とは違う。普通はLLM生成コードは、関連領域の類似コードとかなり似る傾向がある。方向性をつかむために読んだコードが、ほぼそのまま反映される
「システムがより理解しやすくなるか、より悪くなるかを気にしない」も解決可能だ。LLMにそれを評価させ、段階的に下げていけばよい。何が理解しやすいかはシステムの非決定的な性質であることが多いので、逆説的に、他のツールよりLLMのほうが測定しやすいアプローチかもしれない。新しいセッションで「この新たに追加されたコードを理解するには、システムのどれくらいを理解する必要があるか」と尋ね、その範囲を縮めるように最適化できる
「AIは、ここには合わないかもしれないベストプラクティスの道具箱を持っている」という部分については、AIを使う過程が、新しいプロジェクトに同じ理想を持ち込んできたジュニア開発者を訓練するのとよく似ていることが多い。ジュニアには口頭で伝え、その知識を覚えて応用することを期待するが、AIには AGENTS.md / CLAUDE.md ファイルに文書化しておけば、その知識は残り続ける
「コードレビューを頼むと、同意しない改善点が大量に出てくる」というのは、Codex基準では、一覧を小さく簡潔で価値の高いものに保つよう調整されている。他のモデルは違うかもしれないが、これも結局は指示のレベルの問題だ。気にしていることは文書化する価値があることが多く、AIを使うとそれが必要になる
ロックスターを相手にするときの問題の半分はエゴだが、それでも人が書いたコードを残したロックスターには、それを裏づける省察と意図があった
それに対して、AIの上に人間の殻だけをかぶせた「ロックスター」たちは、虚勢は同じかそれ以上なのに、自分たちが解決すると主張する問題の半分すら完全には理解していないことがある
関数型プログラミングのアプローチをできるだけ適用し、異なるやり方で組み合わせられる文脈非依存のコンポーネントを作れば、かなりのテコが得られる
実装の詳細を抽象化した個別のビルディングブロックと、特定の文脈に依存する作業を分けておけば、要件が変わったり別のアプローチを取ったりするときに、ブロックを簡単に再配置できる。また、全体の配置文脈を知らなくても各部分を独立して推論でき、それらの部品がどう組み合わさっているかを見ることで上位レベルのロジックを理解できる
関数型言語はLLMと一緒に作業するうえでよい基盤を提供する。コードを、文脈を制限する形で自然に書かせるからだ。これはプログラムの特定機能を理解するために必要な範囲を減らし、モデルにも人間の利用者にも役立つ