「コードが書けること」はもう価値じゃない。Vibe codingが当たり前になった今、正直ここまで早く来るとは思っていなかった。
じゃあ制約知識か？ 「このAPIはこう叩く」「この環境ではこう回避する」みたいな専門知識。これもAIに調べさせれば済む。
残るのは「摩擦を体験して、仕様のアイデアを得る能力」だと思っている。自分でclaude-panesというツールを作りながら、そう確信した。
claude-panesを作った経緯
Claude Codeを並行で使い始めると、tmuxのペインがすぐ10個を超える。どのペインでどのタスクが動いているのか、完了しているのか、待機中なのか。把握できなくなった。
「ペインの状態が一目でわかるTUIが欲しい」。これがclaude-panesの出発点。
ペイン一覧の表示、アイドル検出（CPU・最終出力時刻・プロセス状態の3要素）、ファジー検索、プレビュー。Rust製のTUIツールで、ratatuiとcrosstermで実装した。
Claude Code並列管理TUIを自作したら、workmuxで全部できた話開発
ただし、ここで言いたいのはツールの機能紹介じゃない。このツールを作る過程で考えたことの方が本題。
vibe codingでコードの価値が消えた
claude-panesはRustで書いた。自分はRust未経験。ratatuiもcrosstermも触ったことがない。
それでも動くTUIが出来上がった。Claude Codeに構造を指示して、エラーが出たら貼り付けて、修正させる。その繰り返しで、2日で形になった。
ここで思い知ったのは、コードを「書く」行為自体の価値がほぼゼロになったということ。
データもそれを裏付けている。CodeRabbitが470のGitHub PRを分析したレポートでは、AI生成コードは人間が書いたコードの1.7倍の問題を含んでいた。パフォーマンス非効率に至っては約8倍。つまりAIが書いたコードの品質は人間以下。それでも「書ける」こと自体に価値はない。品質の低いコードでも、動くものが出来てしまうから。
AIに頼りすぎると自分の手で書く力が鈍る——作った本人であるAnthropicがそう認めているのが皮肉だし、身に覚えもある。
Stanfordの調査はもっと生々しい。22〜25歳の開発者の雇用が2022年から約20%減少した一方で、30歳以上の雇用は安定または微増していた。コードを書く能力で勝負していた若手ほど、代替された。
制約知識もAIに調べさせればいい
claude-panesを作るとき、tmuxのペイン情報をどう取得するか知らなかった。tmux list-panesのフォーマットオプションも、プロセスのCPU使用率をRustで取得する方法も知らなかった。
全部AIに聞いた。「tmuxのペインごとのCPU使用率を取得する方法は？」と投げたら、sysctlとprocfsの違いから説明してくれた。macOSとLinuxで実装が違うことも、AIが調査して解決してくれた。
もちろんlocalhostを公開URLだと思うレベルの無理解は論外。でも「tmuxのペイン検出にはこのAPI」みたいな制約知識のハードルは、確実に下がった。
2年前なら「Rustでシステムコールを叩ける」こと自体が専門性だった。今は「Rustでシステムコール叩いて」とAIに言えば済む。制約を「知っている」こと自体の価値は薄れた。
仕様書すら陳腐化する
ここまで読んで「じゃあ仕様を書ける人が勝つんでしょ」と思ったかもしれない。自分も最初はそう考えていた。でも、それすらも怪しくなってきている。
claude-panesには設定ファイルがある。TOML形式で、アイドル検出の閾値やキーバインドを変更できる。この仕様をプロンプトとして食わせれば、同じアプリが再現できる。仕様の一部を変えれば、自分好みにカスタムしたバージョンも作れる。
仕様書は自然言語。つまり誰でも読めるし、誰でも編集できる。「エンジニアだけが仕様を書ける」という前提は、もう成り立たない。
claude-panesのREADME.mdを書いていて実感した。技術的な詳細、状態ファイルのフォーマットやhookスクリプトの中身はdocs/ARCHITECTURE.mdに分離して、README自体は「何ができるか」と「どう使うか」だけにした。READMEに技術的なことを書く意味が薄れている。使う側はAIに「このツールの使い方教えて」と聞けばいいから。
今はまだ、細かい制約を突破する能力が必要な場面がある。claude-panesで言えば、Claude Codeの「working」状態を正確に検知できない問題。tmuxのペイン内容からプロンプト待ちなのかコード生成中なのかを判別するのは、現時点のAIには難しい。こういう泥臭い制約の突破が、今のエンジニアの仕事になっている。
ただ、これも時間の問題だと感じている。AIがもう少し賢くなれば、制約の調査も突破もAI自身がやるようになる。仕様書も「ペインの状態が分かるTUIが欲しい」の一行で十分になるかもしれない。細かく説明する必要すらなくなる。
ソフトウェアという形が消える
仕様書が陳腐化するなら、その成果物であるソフトウェアも固定形では残らない。すでに「Disposable Apps」——使い捨てアプリ——という概念が出てきている。目的のために生成して、終わったら捨てるソフトウェア。
claude-panesで考えてみる。今はcargo installでバイナリをインストールして使っている。でも本当に必要なのは「tmuxのペインを一覧表示して、状態が分かるTUI」という意図だけ。この意図をAIに伝えれば、各自の環境に最適化されたツールがその場で生成される。インストールもバージョン管理もいらない。使い捨てでいい。
ゲームですらそうなるかもしれない。「ダンジョン3層で、敵の攻撃パターンはこう」と指定して、カップラーメンを待つくらいの時間で自分だけのゲームが生成される。飽きたらカスタムし直す。体験のリアルタイム性は残るが、構築は一瞬になる。
そうなったとき、GitHubで共有されるのはコードではなく意図のテンプレートになる。「tmuxペイン監視TUI」という意図を誰かが共有して、各自がカスタムして自分用を生成する。フォークするのもコードではなく意図。OSSの意味が根本から変わる。
残るのは「摩擦を体験すること自体」
コードの価値が消えた。制約知識もAIに任せられる。仕様書すら陳腐化する。ソフトウェアという形すら消える。
じゃあ何が残るのか。自分でツール作ったことがある人なら分かると思うけど、着想って大体「不便」から始まる。
- Claude Codeを並行で使い始める
- tmuxペインが増えすぎて、どこで何が動いているか分からなくなる
- 毎回
tmux list-panesを叩いて目視確認する手間にうんざりする - 「状態が一目でわかるTUI欲しいな」と思う
この「不便を体験する→作るべきものが見える」というプロセスだけは、AIには不可能。
AIは困っていない。ペインが10個あっても混乱しない。「tmuxのペインが多すぎて辛い」という感情を持たない。だから「こういうTUIがあれば楽になる」というアイデアも生まれない。
Mo Bitarという開発者が、2年間vibe codingした後に手書きに戻った話が象徴的。彼はコードベースを通読して、「AIは良い物語を語っていただけだった」と書いた。個々の変更は問題なく見えても、全体としての一貫性が崩壊していた。AIはPR単位では優秀でも、プロジェクト全体の「手触り」を持っていない。
仕様を書く能力も、制約を突破する能力も、いずれAIが代替するだろう。でも「ペインが多すぎて辛い」と感じること、「こういうツールがあれば」と思いつくこと。この体験だけは外注できない。
バイブコーディングに最適なアーキテクチャ比較 - なし・VSA・FSD・レイヤードの選び方開発
エンジニアは「不満を持つ人」になる
コードを書く人でもない。仕様を書く人でもない。不満を持つ人。
大げさに聞こえるかもしれないけど、先述のStanfordの調査がこれを裏付けている。生き残っているのは「書ける人」ではなく「現場の痛みを知っている人」。
自分でツールを使う。不満を見つける。「こうなったらいいのに」と思う。そこからすべてが始まる。仕様に落とすのも、コードに変換するのも、やがてAIがやる。人間に残るのは、最初の「これ不便だな」だけ。
バスファクターという概念がある。プロジェクトの知識を持つ人が何人いなくなったら破綻するか、という指標。従来の最悪値は1だった。vibe codingの登場で、この値が史上初めてゼロになった。誰もコードを理解していない状態。
だからこそ、摩擦を避けない姿勢が重要になる。「AIに任せて楽をする」ではなく「自分で不便を体験して、何を作るか見つける」。体験と課題発見は外注できない。ここが最後の砦だと、自作ツールを作りながら考えていた。
その先に残るもの
ただ、正直に言えば「不満を持つ人」ですら最終地点ではない気がしている。
ユーザー行動データを解析すれば、AIが摩擦を検知する日は来る。「このペイン切り替え、非効率ですね」と先回りして提案してくるようになったら、不満を感じる前に問題が解決される。そうなったとき、エンジニアに何が残るのか。
全部剥がしていくと、最後に残るのは「欲求」だと思う。
唯一固定的に残るのは信頼のレイヤーかもしれない。医療や金融のように「認証済みのモデルでなければ許されない」領域。そこではソフトウェアのバージョン管理の代わりに、AIモデルの認証バージョンが管理される。でもそれは規制領域の話であって、大多数は意図から即時生成される使い捨てになる。
「この世界にこういうツールが存在してほしい」という願い。データから導けない、個人の美意識や執着。「このUIの手触りが好き」とか「こういう世界観のソフトウェアが欲しい」とか。合理性では説明できない、けど本人にとっては譲れないもの。
エンジニアは作る人から、設計する人になり、不満を持つ人になり、最後は「願う人」になる。
カーツワイルの「シンギュラリティは近い」では、AGIがナノテクノロジーを完成させて宇宙に飛び出す未来が描かれていた。その世界ではコードも仕様も摩擦の検知もAIがやる。人間に残るのは「こういう宇宙であってほしい」と願うことだけかもしれない。
冗談みたいに聞こえるだろう。でもclaude-panesの出発点を思い出してほしい。「ペインが多すぎて辛い」という個人的な感情から始まって、Rustも知らないのにTUIが完成した。コードも制約知識もAIが肩代わりしてくれた。この延長線上に、仕様すらAIが書き、ソフトウェアという形すら消える未来がある。
そのとき、最初の「こういうものが欲しい」という欲求を持てる人間こそが、何かを生み出す起点になる。エンジニアに限った話じゃない。全員がそうなる。違いがあるとすれば、技術の可能性と限界を肌で知っている人間の方が、より具体的に「願える」ということくらいだろう。
