世界を動かす技術を、日本語で。

AIロックスター開発者の後始末をする

概要

ロックスター開発者 の問題点とその後始末について説明。 AI(LLM)開発者 による新たな課題への変化を指摘。 複雑化・技術的負債の増大リスクについて解説。 持続可能なソフトウェア開発 のための指針を提案。 人間の職人技 の重要性を再確認。

ロックスター開発者の遺産

  • ロックスター開発者 は、エネルギッシュで革新的な技術導入を推進。
  • 新しいアーキテクチャやツール、言語 を次々導入し、チームの水準を引き上げる存在。
  • プルリクエストの却下 や高い期待値による周囲の負担増加。
  • 難解なコード や独自の設計による理解困難なシステムの構築。
  • 退職後の引き継ぎ で、残されたチームは複雑なコードの保守に苦しむ現実。

ロックスター開発者の後始末

  • 引き継ぎ後の混乱、理解不能なコードに直面する現場。
  • 新しい言語や未知のライブラリ の多用による学習コストの増大。
  • 再設計提案の却下 や、経営層の信頼問題によるストレス。
  • 転職を考えるほどの技術的負債 とメンテナンス困難。

ロックスターの特徴と問題点

  • 新技術・新パラダイム への探究心と実装スピード重視。
  • 他者の協働性や可読性 を軽視したコード設計。
  • 自分だけが理解できる複雑なシステム の構築。

AI(LLM)開発者時代の到来

  • AIエージェント(LLM) による急速なコード生成の普及。
  • 記憶を持たないAI が日々大量の新コードを生産。
  • 全体設計や統一性を無視 した部分最適の積み重ね。
  • 複雑化・技術的負債の爆発的増加、全体像の把握困難。
  • コードレビューでの過剰な指摘 や、現場との乖離。
  • AI依存による開発者・組織のスキル低下リスク

AIロックスターの後始末

  • AIが生み出すコードの山 は、従来のロックスター以上に整理困難。
  • 統一感や設計思想の欠如、断片的な機能追加による混沌。
  • 技術的負債が返済不能なレベル にまで膨張する危険性。

持続可能なソフトウェア開発のために

  • LLMの制御とガイド による小規模・理解しやすいコード生成の推奨。
  • チーム全体で理解・保守可能な設計 を重視。
  • 複雑化を防ぐためのシンプル化、過剰設計の回避。
  • LLMに頼りすぎず、人間の手でコードを書く意識 の重要性。
  • 職人技(Craftsmanship) は、AIに完全に委ねられない価値。

© Jesse Skinner, 2026年6月8日公開

Hackerたちの意見

他の人の後片付けをしなきゃいけない人がちょっと羨ましいな。少なくとも、やりがいがあるからね。今の仕事は本当に退屈で、簡単すぎてジュニアでもできるようなことばっかり。なのに、メディオが必要だって。自分がこれより上だとも思ってないし、メディオがやらないとも言ってない。ただ、この会社のコードには全然興味が持てないんだ。古くて、ほこりだらけで、重要な人には何の役にも立ってない。お客さんたちは一度ツールを買ったから使ってるだけで、興味がないから切り替えようとも思わない。もっと自分の経験に合った仕事がすぐに来るって約束されたけど、こんな古い会社のお客さんが来るとは思えない。顧客や従業員を失っていくのも当然だよね。でも、住宅ローンもあるし。今日は契約延長しないかもって話をされて、もっと責任を持って、同じ給料で仕事を増やせって脅されてる感じ。残念だけど、面白い新しい職を見つけるまで、今の仕事を続けなきゃいけない。お金はそんなに必要ないし、「成長」とかどうでもいい。生きていけるだけのお金があればいいんだ。ちょっと関係ないコメントかもしれないけど、他に愚痴を言える場所がないからさ。

こういうコメント大好き。人間らしいよね。頑張れ、友よ。

退屈なコードベースなのに、会社はなんでトークンを投げることを考えないんだろう?正しい選択とは言わないけど、確かにそういうトレンドは感じる。

最初は「メディオ」が「シニア」の変なタイプミスかと思ったけど、2回見て確認したら、ヨーロッパの一部で「ミッドレベル」を意味する言葉なんだね。

この会社のコードには全然興味が持てない。すごく共感する。ゴミみたいな製品を作るゴミ会社が、大多数の怠惰さやセンスのなさを利用して、マーケティングで儲けてる。しかも、さらに悪化させてるのが、全体の分野のLLMinazationによって100倍になってること。コードがメンテナンス不可能になって、みんながバカになっていく。こんなのに出くわさなければよかった。

あなたは一人じゃないよ。私もMSFTで同じような状況にいて、辞表を出したんだ。私はL63だけど、やってた仕事はL60-L61でもできるようなもので、しょっちゅう「クソみたいな仕事」にいる気がしてた(デイビッド・グレーバーのおかげで)。給料は良かったけど、ストックのサインオンが切れたら、ただセキュリティのためにその仕事を続けているだけだと気づいた。HooliのエンジニアたちがHooliのオフィスのテラスで日光浴しながらストックが権利確定するのを待っているような感じだった。キャリアはまだ9年目で、今の状況が最適だとは思えなかった。でも、あなたのように大きな金銭的義務はなかったから、私にとってはもっと簡単な決断だった。頑張って、友よ。そして、深い人間らしいコメントをありがとう。

AIや他の人が作ったコードを修正するのが好きなんだ。先週、あるクライアントが部門用のツールをいじってたことが判明したんだけど、その結果、次のjsで10GBのメモリが必要な大きなクソコードができちゃった。リントエラーが何千もあって、Gitの開発ログもすごくうるさい。今、これを修正しなきゃいけないんだけど、こういう仕事は基本的に10k〜50kユーロの無料作業を繰り返す感じ。やってることが分かってれば簡単だけど、分からなければ不可能だね。もっと来てほしいな。

ある意味、彼らは実装するための仕様書とUIモックを渡しているんだね。

たくさんの人がAIに大金を賭けているけど、期待できるものもあれば、全ての賭けが実を結ぶわけじゃないよね。この考え方を、人々が金を突っ込んでいる人間のスロットマシンみたいだと思ってる。

結果として、nextjsで10GBのメモリを必要とし、1000以上のリンティングエラーがあり、Gitに開発ログ(非常に騒がしいもの)があるような大きなクソができてしまった。 今や、反LLMのプロパガンダがひどくなってきてる。プロジェクトが「10GB」を必要とすることはないし、天文学的に大きなリポジトリで作業している場合を除いて、どの LLMも_そんなのを生成することはない。リンティングエラーは(原因によって)無意味だったり、悪いプロンプトエンジニアリングの結果だったりする。プロジェクトを特定の方法でリンティング/フォーマットしたいなら、LLMにそれを明確に伝えればいい。

面白いね!たぶん、バイブコードされたソフトウェアの市場はあると思うけど、もしそうなら、他の会社のバイブコードされたミスを修正する市場もあるってことだよね…言い換えれば、A社にお金を払ってソフトウェアや追加機能をバイブコードしてもらった後、B社にお金を払ってA社のミスを直してもらうってこと!(でも、明るい面を見てみて!税金やGDP、雇用(「仕事、仕事、仕事!」)や循環するインターネット経済にもっとお金が入るよ!:-) )

AIを使って書き直したの?

ゼロから始めるのにどれくらいかかった?

人生で出会った中で、本当に天才だと思える人は数人だけ。なんでこの人はこんなに賢いんだろうって、びっくりすることがある。賢い人について気づいたことが二つあって、1) 彼らは自分がどれだけ賢いか気づいていないことが多い。自分にとっては簡単だから、コンピュータサイエンスの学位を持っている人ならみんな知っていると思っているんだよね。友達が暗号関連の数学の話をしていると、「その授業は受けたけど、君が話していることは全然わからないよ」って感じになる。2) それとは逆に、自分が周りの人より賢いことを痛感している人もいる。中には嫌な奴もいるし、相対的に「バカ」な人たちに囲まれて疲れている人もいる。後者には同情するなぁ。人生を歩んでいて、すべてが明確で簡単に理解できるのに、人間が何度も何度も愚かな選択をするのを見なきゃいけないって、どんな気持ちなんだろうね。

それに、もう一つの問題があるんだよね - 50%以上の人が君のその最後の文を信じているってこと。

アウトライヤーでいるのは孤独だよね。特に自分の世界の見方に根本的に関わる特性で。どんなに頑張っても、ほとんどの人と共感するのは難しいし、特に彼らはあなたに共感するのが難しい。経験の差はかなり大きくて、しばしば乗り越えられないものだ。

人生を歩んでいて、すべてが明確で、明らかで、処理しやすいのに、人類が何度も何度も愚かな選択をするのを見なきゃいけないなんて…俺は本をたくさん読んでるわけでもないし、高IQでもないけど、常識だと思う小さなことに対してこう感じる。人々が手間取っているのを見るのは本当にイライラする。明らかに-Xになるのに、Xをやるとか。大抵はそれを口に出さないように学んだよ。特に近しい家族との関係には良くない影響がある。見ていると、彼らをうるさく言いたくなるから。

この二つの文には共感した:

「データの流れが追いづらくて、誰かが殺人を隠そうとしているみたいだった。」 「ノートパソコンでコードを動かすのに一週間かかった。」 データの流れを理解するのに苦労しているのは自分だけだと思ってたけど、実はみんな同じように悩んでるんだね。インポスター症候群や「速度」を重視する毒のある環境もあって、余計に辛かった。自分だけじゃないって知れて、ちょっと安心したよ。

ノートパソコンでコードを動かすのに1週間かかった。これには驚いた。CLIのClaude Codeは、アプリを立ち上げたり、ランダムな依存関係やDockerの問題をデバッグするのが、以前の時代に比べて夢のように簡単になった。以前は、アーキテクチャを学びながら、動かないものをトラブルシューティングしなきゃいけなかったからね。

そうだね。AIにコードを書かせると、そのAIにメンテナンスを頼らなきゃいけないってことを受け入れつつある。先週は、自分が書いているアプリのメモリー問題を追いかけてたんだけど、LLMにかなり助けてもらったよ。マップ画面を実装するビューコントローラーの大部分を書き直してくれた。今、そのビューコントローラーは4000行もあるけど(半分はコメントだけど)、すごくうまく動いてる。ここにたどり着くまでに、何度もコンテキストをリセットして書き直した。こんなやり方はしなかったと思うけど、問題を解決することもできなかったかも。問題はAppleのMapKitにあって、アプリがクラッシュしないようにいろいろ工夫が必要だった。特に良いコードではないけど、ちゃんと動く。今はその雑なビューコントローラーをプロジェクトに残しておくことにした。将来的には完全に取り除いて、もっと「軽い」コードに置き換える選択肢もある。ほぼ「ファイアウォール」状態だね。これをやるのはそんなに難しくないと思うけど、バンド幅があればの話(Appleがメモリの問題をやっと直してくれれば、だけど)。いろんな選択肢を探ることができるけど、これが一番いいと思ってる。でもこの記事は本当に正しいと思う。数年後に、何千ものバイブコードされたアプリが生まれるとき、私たちは「スロポカリプス」を迎えることになるだろうね。

今のところ、あまり重要じゃないコードがあると思ってる。それが動けばそれでいいし、ほとんど修正や拡張はされないだろうし、期待通りに動いているか確認するのも簡単。こういうコードにはAIに自由にやらせるのが嬉しい。で、ビジネスロジックやセキュリティ関連の重要なコードもある。そういうのには、アイデアをブレインストーミングしたり、間違っているかもしれないコードレビューをしたり、ライブラリの提案を手伝ったりするためにAIを使うけど、自分でコードを書いて何が起こっているのか理解したいんだ。どう変わるか見てみよう。今のところ、すごく面白い旅だよ。

2人のプロダクションエンジニアに頼り切って、利益を上げている2つのプロジェクトのインフラを構築するのは本当に愚かだった。スパゲッティコードで10倍のボスのように全部作って、Anthropicに飛び込んで9桁の報酬を得ることができたはずなのに。バカだな、バカだな、バカな自分。少なくとも、これが私の教訓だね。

最初の数セクションは響いたな。昔は「ロックスター」だったと思ってたけど、それが良いことじゃないと気づいた。たぶん、同僚の10倍速く物事を進められた。でも、ある時点で気づいたんだ。それは、俺が普通の人より10倍生産的だったからじゃなくて、周りの普通の人たちを1/10の生産性にしてしまう働き方をしていたからだって。そこからはスピードを落とした。全体的には、俺の人生にとってポジティブな変化だったよ。チームプレイヤーでいることは、このクレイジーな業界では同じような昇進は期待できないけど、メンタルヘルスには素晴らしい効果があった。

過去に、ロックスター的なやり方で実装して自分の足を撃ち抜いたことは確かにある。私の場合、通常は本当に必要ないことを過剰に抽象化しちゃうことが多い。あるいは、実際には起こらないユースケースのために何かを作ってしまう。だから、頭が過剰抽象化の領域に迷い込むときは、YAGNI(要らないものは作らない)とKISS(シンプルに保つ)を意識するようにしてる。

私たちはいつも誰かのロックスターだよ。

時々、技術的負債があまりにも多くて、全く返済できないことがある。AIの時代には技術的負債なんて存在しない。ただ、数分で考えつく移行の連続に過ぎない。私はAIを使って二つの異なるデータベースを移行したけど、移行コードを書くのに数分しかかからなかった。データを二重に書き込ませて、AIに二つのデータベースを比較するコードを書かせた。その後、一週間かけてテストした。小さなバグをいくつか修正したけど、正確にはAIにバグを直させたんだ。満足したら、新しいデータベースをプライマリにして、前のデータベースをセカンダリに切り替えた。それからデータが同期しているか確認した。前のデータベースをオフにして、前のコードの痕跡をすべて削除した。シンプルで比較的早かった。この時代に技術的負債が存在するなんて、ありえないよ。一人の人間が、以前はチーム全体でやっていたことを、ほんのわずかな時間でできるんだから。

私の意見では、問題はほとんどのマネージャーがコードのエレガンスを重視していないことだと思う。そして、ほとんどのプログラマーは管理に対して従順すぎるか、無知すぎて異議を唱えられない。さらに、ほとんどのチームメンバーは、高度にエレガントなコードやその内面的な美しさを理解したがらない。もしマネジメントやチームが、「機能を(表面的に)実装するために大量に吐き出された」コード行よりも、高度にエレガントなコード構造を重視するようになれば、この記事で議論されている問題はずっと少なくなると思う。