では、主にテックブロガーのゲルゲリー・オロシュによるクロード・コードのコアメンバーに関するインタビューから得られた、クロード・コードの誕生の物語を見てみましょう。 Claude Codeは本当に驚異的で、年間売上高は5億ドル、3か月でユーザー数は10倍に増加し、多くのプログラマーにとって好まれるコーディングエージェントツールとなっています。 このツールはもともと「今聴いている曲を教えてくれる」小さなコマンドラインのおもちゃとして始まりました。 🧵

ゲルゲリー・オロシュはクロード・コードの主要メンバー3名にインタビューを行いました。 ・ボリス・チェルニー、創業エンジニア(17年の経験、元Metaチーフエンジニア) ・エンジニア2 シド・ビダサリア(サブエージェント特集の著者) • そしてプロダクトマネージャーのキャット・ウー。 彼らは、Claude Codeがプロトタイプから製品へとどのように移行したか、どのような技術的選択をしたか、そして12人の小さなチームが1日に5本のPRを公開できた経緯について話しました。 これはおそらく今のところ「AIファーストのエンジニアリングチーム」に最も近い例です。 彼らはAIを使ってコードを書き、テストを書き、コードレビューを行い、トラブルシューティングを行い、さらにはClaudeコードを使ってClaude Code自体を開発しています。 コードの90%は単独で書かれています。 私がやりたいのは、このインタビューの最も興味深い部分を整理し、このチームがどのように機能しているか、何が学べるか、そして彼らの特別な条件によって決まり、真似できないことについて話すことです。 以下は7つの短編小説に分かれており、それぞれ独立して読むことができ、つなげて完全な絵を形成しています。

[1] 聴取装置が年間5億ドルの収益を持つ製品になる方法について 2024年9月、ボリス・チェルニーはAnthropicに加わり、何もすることがないときにコマンドラインのおもちゃを書きました。 この機械は何ができるの? AppleScriptを使って聴いている曲を教え、コマンドに応じて曲を変えます。 それだけのことです。 ボリス自身は「なかなか面白いデモだったが、面白くはなかった」とコメントしています。 ”

本当の展開は、彼が同僚のキャット・ウーと話し終えた後に訪れた。 キャットはAIエージェントのコンピュータ機能を研究しており、会話中にボリスはひらめきました。「このコマンドラインツールにもっと権限を与えたらどうだろう?」 例えば、ファイルの読み書きやコマンドの実行ができるようにしたいとか?

彼は試みた。 そして、奇跡を目撃する瞬間が訪れる。 ボリスはアップグレードされたツールをアンソロピックのコードベースに投げ入れ、いくつか質問をした。 クロードは自分でファイルシステムを探検し始めた――ファイルを読み取り、インポート文を確認し、参照されたファイルを読み、層ごとに掘り下げて答えを見つけた。 「それは私を揺さぶりました」とボリスは振り返ります。「こんな道具を使ったことがなかった。 ”

AIの分野には「プロダクトオーバーハング」という概念があり、これは「プロダクトオーバーハング」を意味します。 これはモデルが実際にある能力を持っているが、既存の製品フォームではその機能をリリースしないことを意味します。 ボリスが発見したのは、クロードがずっと前にできたはずの巨大な「製品オーバーハング」でしたが、誰もそのためのシェルを作っていませんでした。

ボリスは毎日このツールを使って取り組み始め、その後数人の同僚と共有しました。 2か月後の11月にはビルドがリリースされました。 データは誇張されています。初日にはエンジニアの20%が稼働中、 5日目、50%です。

この時点で興味深い議論が浮上しています。外部に公開すべきか? 反対の理由は非常に現実的です。もし本当にこの存在が私たちが思うほど強いなら、「秘密兵器」として保持しておくのが良いのではないでしょうか? なぜ競争優位を放棄するのか? 最終的に、Anthropicは出版を選びました。 論理はこうです。Anthropicの中核的な使命はモデルの安全性を研究することであり、セキュリティを研究する最良の方法は実際にこれらのツールを使うことだということです。 Claude Codeが内部で多用であることが検証された今、公開することでモデルの機能やセキュリティについてより深い洞察が得られるでしょう。

2025年5月、Claude Codeは正式に公開されました。 3か月後には使用量が10倍に増加し、年率収益は5億ドルを超えました。 興味深いことに、Borisは元々プログラマー向けに設計されており、そのため「Claude Code」という名前が付けられました。 しかしある日、データサイエンティストのワークステーションの前を通りかかると、もう一方の画面でクロード・コードが動いているのを見つけた。 「なぜこれを使うの?」 「クエリを書いたり視覚化したりするのを手伝ってもらうために頼んだんだ。」 現在、Anthropicのデータサイエンティストは手元に1台を持ち、一部は同時に複数の機器をドライブしています。 盗聴装置は、許可を少し増やしたことで数億ドルの価値を持つ製品となりました。 これはおそらく「製品オーバーハング」の最良の証拠であり、モデルの能力は常に存在し、誰かがリリースするのを待っています。

[2] コードの90%は自分で書かれています - Claude Codeの技術的な選択哲学 Claude Codeは90%のコードを独自に持っています。 仕掛けのように聞こえますが、実際には彼らの技術的な意思決定の論理のおかげです。 まずは技術スタックを見ていきましょう。TypeScriptが本文を書き、ReactはInkフレームワークをターミナルUIとして使い、MetaのオープンソースYogaがレイアウトシステムを担当し、Bunはビルドとパッケージングを担当しています。 なぜこれらの技術スタックを選ぶのか? なぜなら、それらは「流通の中にいる」からです。 「On distribution」はAI分野の用語です。 これは、モデルがこの種のコードを多く見ており、それらをうまく扱っていることを意味します。 TypeScriptとReactはまさにClaudeの強みです。 人気のないフレームワークを選ぶと、モデルは「学習」しなければならず、その効果は損なわれます。 この選択は素晴らしいサイクルを生み出します。クロードが得意とする技術スタックでClaudeコードを書き、さらにClaudeコードでさらにClaudeコードを書くというサイクルです。 90%は自分自身について書く、そうやって生まれたんだ。 建築レベルでの選択も同様に簡潔です。 Claude Codeはローカルで動作します。 Dockerコンテナもクラウドサンドボックスもなく、ファイルを読み書きし、直接パソコン上でコマンドを実行するだけです。

なぜこのような設計になっているのか? ボリスはこう答えます。「デザインの決定をするたびに、ほとんどの場合最もシンプルな解決策を選びます。 ローカルで運用するのが一番簡単な答えです。 ” このシンプルさは製品哲学全体にも及びます。つまり、できるだけビジネスロジックを控え、モデルを主役にするというものです。 「少し変に聞こえるかもしれませんが、私たちはユーザーにモデルをできるだけ『本物らしく』感じてほしいのです。 多くのAI製品は追加のUI要素やアクセシビリティ機能などの足場を追加しており、その結果モデルが制限されています。 私たちがやりたいのは、UIをできるだけスリムにすることです。 ” シンプルにするために、Claudeが新しいモデルをリリースするたびに、コードを大幅に効率化しています。 例えば、Claude 4.0がリリースされた際、新モデルでは「松葉杖」が不要になったため、システムのプロンプトの約半分が削除されました。 ツールの数も簡素化されています。可能なら削除し、可能ならマージ。 Claude Codeのアーキテクチャ全体は3つにまとめられます:UIの定義とモデル変更へのインターフェース公開、モデルが呼び出すためのツールの公開、そしてフラッシュの回避です。 もちろん、シンプルだからといって複雑な部分がないわけではありません。 許可システムは例外です。 結局のところ、AIにコンピューター上でコマンドを実行するのはリスクが高いのです。 Claude Codeの解決策は、実行前に「この操作を承認したいですか?」と尋ねることです。 今回だけ承認するか、後で承認するか、却下するかです。 権限システムは、プロジェクトごと、ユーザーごと、企業ごとの多層構成をサポートしています。 Teamsはよく使われるセキュリティコマンドをホワイトリストにするためにプロファイルを共有できます。 この許可設計の原則は以下の通りです。 Claude Codeを始めると、あなたの同意なしに何も変わらないはずです。 しかし同時に、ユーザーに「委任」の選択肢を与えることも必要です。信託の場合、確認リンクをスキップできます。 シンプルだが、未熟なものではない。 抑制はあるが、機能の欠如ではない。

[3] 2日間で20個のプロトタイプ - AI時代の製品の反復はどのようなものか 以前は製品の試作品を作ると、2日で2つ作れて効率的と考えられていました。 ボリスは2日間で20人を稼いだ。 これは誇張ではなく、彼がClaude CodeのTodoリスト機能を開発した正確な記録です。 彼はすべてのステップのプロンプトやスクリーンショットまで共有してくれました。 これら20のアーキタイプがどのように反復しているか見てみましょう。 最初のバージョンでは、To-Doリストを最新のツールコールの下に表示したいと考えていました。 プロンプトは短く、「入力時にtodoが表示される代わりに、入力ボックスの上に固定されたToDoリストを表示し、タイトル『/todo (1 of 3)』はグレーアウトしています」。 効果を見て、あまり満足できませんでした。 第2バージョンでは、ToDoの更新ごとにインライン表示されます。 プロンプト:「ToDoリストを表示する代わりに、モデルがToDoの処理を始めたときにツール名を太字のタイトルに表示してください。」 進捗表示は「ステップ2/4」のように保ちましょう。 ” まだ正しくない。 第3版と第4版では、「インタラクティブピル」を作ろうとしました。画面下部に小さな四角形があり、クリックして進捗を見ることができます。 「テキスト入力ボックスの下に、背景タスクのように『todos: 1 of 3』と表示するトイリストを追加してください。」 そして「この錠剤を背景クエスト用の錠剤のようにインタラクティブにしてください。」 ” 少し面白いですが、十分とは言えません。 第5版と第6版では考えを変え、右側からスライドして出る「引き出し」を作ることにしました。 「前の錠剤とタイトルを取り消して、代わりに入力ボックスの右側に、縦に中央に、灰色の仕切りで区切ってやることリストを表示してください。」 「ちょっと跳ねるけど、引き出しのアニメーションにできる?」 見た目はかっこいいですが、実用性は疑問です。 第7版と第9版では、入力ボックスの上にToDoリストを移動させ、異なる切り詰めやヘッダーのスタイルを試しました。 「5人以上の場合、『... さらに4つ」、「灰色の『Todo:』タイトルを追加」。 答えはどんどん近づいている。 第10版と第20版では、やることリストと読み込みアニメーションを組み合わせる方法を模索し始めました。 最終的な解決策は、スピナー(負荷インジケーター)の隣に進捗情報を配置して視認性を最大化することです。 リリース後、ユーザーは完全なToDoリストを見たいと報告しました。 そこで別の反復が追加されます:Ctrl+Tを押してすべてのステップを展開します。 これが現在オンラインになっているバージョンです。

この過程で、ボリスのプロンプトは驚くほど短く、ほとんどが1、2文程度でした。 しかし、各バージョンは実際に実行可能なプロトタイプであり、静止画やPPTではありません。 彼はこの機能がうまく機能するかを実際にテストし検証できます。 従来の製品開発プロセスは、アイデア→議論→ワイヤーフレームの描画→高精度設計→開発→テスト→稼働させることです。 一歩一歩に時間がかかり、行き詰まることもあります。 今や流れはこうなります:アイデア → 一文プロンプト →実行可能なプロトタイプ → 何か違和感があれば、もう一度やる。 これは開発者がこの開発プロセスに適応するために考え方を変えることを必要とします。 かつてプロトタイプの役割は「アイデアの検証」でした。なぜならプロトタイピングのコストが高く、慎重に考える必要があるからです。 今ではプロトタイプは「可能性の探求」となりました。プロトタイプを作るコストが低いため、まず作ってから捨てることができます。 ボリスは、Claude Codeを使うときは、設計図を描く段階を飛ばして、直感的なランニングバージョンだけを作ることが多いと言っていました。 Claude Codeチームの日々のリズムは以下の通りです:各エンジニアは1日に約5回のPRをプッシュし、内部で60〜100件のリリース、外部で1回のリリースを行います。 1日5回のPRは、ほとんどの会社では想像もできないことです。 Uberは最も厳しい再編成期間にあり、1日に中規模のPRを出せるのは悪くない。 道具が変わればリズムも変わり、考え方も変わらなければなりません。

[4] コマンドライン端末を統合AIで再設計 コマンドライン端末は何十年も前から存在しているのに、なぜ今になって再設計が必要なのでしょうか? なぜなら、LLM以前は端末がインタラクティブな体験にあまり重点を置いていなかったからです。 従来のコマンドラインは質問と回答の形式で、コマンドを入力して結果を返すだけで完了します。 会話も文脈もフィードバックもなく、待っている間に。 カーソルが点滅しているのを見つめ、背景で何が起きているのか分からない。 Claude Codeは「ターミナルUX」について本格的に考える必要があった最初の製品でした。 彼らは目立たないように見える小さなディテールを加えましたが、使うとまったく違う感覚を覚えました。 まずは、コンテキストに応じた読み込みプロンプト。 モデルが考えているとき、画面は現在のタスク表示に基づいて関連するプロンプトを生成することがあります。例えば、「コード構造を読む」や「解決策について考えている」などです。 小さな工夫ですが、ツールに「個性」を与えています。 一生懸命働いていると感じ、停滞していないと感じられるでしょう。 ボリスは、これほど楽しいやり取りを見たのは、Slackが新人のオンボーディングプロセスだった時だと言います。 次に:待っている間の指導のコツ。 Claudeが長いタスクを実行するとき、画面下部には「現在のタスクを中断するにはEscボタンを押せます」や「すべてのコマンドを見るために/helpを試す」などのチップが回転します。 コマンドラインはコマンドラインを教えるために使われ、シンプルで賢いです。 さらに興味深いのは、Markdownレンダラーです。 リリース前日、一部のエンジニアはネストリストが見た目が悪いとか段落間隔が合わないと不満を言っていました。 問題はMarkdownレンダラーにあります。 Borisは市場にあるすべてのレンダラーを試しましたが、どれもターミナルで良いものは見られませんでした。 そこで彼は一日かけてClaude Codeを使って、ゼロからMarkdownパーサーとレンダラーを書きました。 はい、発売前日です。 はい、ゼロから書きましょう。 はい、クロード・コード本人を使っています。 その結果、この「急いで作られた」レンダラーは既存のすべてのソリューションよりも見栄えが良いのです。 彼らは直接リリースしました。 ボリスは、現在、他のどの端末もMarkdownのレンダリングと同じ品質を持っていないと考えています。 この話は一つのことを示しています。十分に優れたAIプログラミングツールがあれば、「自分で車輪を作る」コストは大幅に下がるということです。 「ただ使えばいい」という妥協が「それならもっと良いものを作れ」に変わることもあります。 かつてのコマンドライン端末のインターフェース形態は、LLMの追加によって復活しつつあります。 端末自体は同じ端末ですが、AIが加わったことで、人々が端末内のAIとより良い会話をできるように真剣に考える必要があります。

[5] AIはあらゆるリンクに浸透している - エンジニアリングチームによる「包括的なAI」実験 Anthropicのエンジニアリングチームは、おそらく現在AIツールの最も極端な活用例の一つです。 単にコードを書くことだけではなく、プロジェクトのあらゆる側面に関わっています。 コードレビュー:すべてのPRの最初のレビューはClaude Codeが担当し、2回目はエンジニアが行います。 ボリスは、クロード・コードは最初の一回で多くの問題を見つけられると言います。 この機能は当初社内でのみ使用されていましたが、後に公開され、誰もがセキュリティレビューにClaude Codeを使えるようになりました。 テストを書く:Claude Codeのテストスイートはほぼ完全にClaude Codeによって作成されています。 「過去には、誰かが自己ベストを持ち出してテストを書かなかったら、私は何も言わずに済まなかった。まるでピック&ポイントのように感じたからだ」とボリスは語った。 しかし今では、クロードの登場ではテストを書くことがプロンプトワードとなり、書かない言い訳はありません。 ” インシデント対応:OncallのエンジニアはClaude Codeに根本原因(問題の根本原因)の分析を依頼します。 Slackから関連する議論、Sentryからエラーログ、さまざまな監視システムからのデータを取得し、合成的に分析します。 ボリスによると、クロードコードは一部のシナリオでは人よりも早く根本原因を見つけるそうです。 GitHubの課題トリアージ:新しい問題が入ると、Claude Codeがまず分析を行い、その後エンジニアが実装可能かどうかを尋ねます。 ボリスは、約20%から40%の確率で一度でできると言います。 チャートとクエリ:製品データはBigQueryに存在し、ほとんどのクエリや可視化はClaude Codeで生成されます。 エンジニアはASCII図を直接出力させることさえあります。

最も驚いたのはTDD(テスト駆動開発)の復活でした。 TDDは古い概念です。まずテストを書き、それからテストに合格するコードを書くというものです。 理論上は良いことで、まず自分が何を望んでいるのか考えさせられます。 しかし実際には、多くの人が遅すぎて面倒だと考えているため、この方法は過去10年間で徐々に周縁化されていきました。 しかしボリスは、Claude Codeを使った後、多くのTDDを行ったと言っています: 「まずモデルにテストを書いてもらい、今テストは失敗すると伝える。合格させようとするな。 次に、関数を実装するコードを書いてテストを通過させるように頼みましたが、テスト自体は変更しないようにしました。 ” 「モデルに明確な目標があるとき――例えばユニットテストやモック――は非常に良いパフォーマンスを発揮します。」 彼は特に、Claude 4.0がモデルがほとんどのテストを書ける最初のモデルシリーズであると述べました。 以前のバージョンではパートを書くことができましたが、多くの人の介入が必要でした。 また、新しい概念としてマルチクラウディングも登場します。 これは複数のClaude Codeを同時に実行し、異なるタスクを並行して作業できるようにすることを意味します。 シドはよくこういうことをしていると言います。会議中に数人のエージェントを始めて、後で結果を見に戻ってくるのです。 Anthropicは、Maxの加入者(月額100〜200ドルのプレミアムユーザー)の25%が毎日マルチクラウドを行っていることを発見しました。 これは興味深い変化です。 プログラミングは常に「シングルスレッド」の活動であり、一度に一つのことしかできず、コードがレビューされたりデプロイされたりするときにだけタスクを切り替えます。 しかし今では「並列プログラミング」が可能となり、複数のことを同時に進めることができます。 もちろん、ここには多くの未知数があります。並行作業の方が本当に効率的か、それとも単に効率的に感じるだけなのでしょうか? 並列処理に適したタスクの種類は何でしょうか? 各エージェントが注目を浴びせられなくなったら問題は起きるでしょうか? これらの疑問はまだ答えが出ていません。 しかし、実験できる新しいツールがあります。 最後に、事件について話しましょう。 ある会社がフレームワーク移行を行う予定で、2年のエンジニアリング年かかると見積もられていました。エンジニア1人なら2年、10人のエンジニアなら2ヶ月半です。 彼らはClaude Codeを使っていて、あるエンジニアが2週間でそれを終えました。 ボリスはかつてはそのような主張に懐疑的だったが、似たような話を何度も聞いてきたと言った。

[6] 3日間ハッカソン - Subagents機能の誕生 Subagentsのこの機能のインスピレーションはRedditの投稿から得ています。 一部では、彼が5つのClaude Codeインスタンスを同時に開き、それぞれに異なる役割を設定し、ファイルシステムを使って互いに通信したと言われています。 シド・ビダサリアがこの投稿を見たとき、最初の反応はこうでした。このゲームプレイはかっこいいが、ユーザーはこんなふうに投げる必要はない。 製品を製品の組み込み機能にすべきです。 たまたま会社が3日間の社内ハッカソンを開催していて、シドはその3日間を使ってそれを行うことに決めました。 初日、チームは複雑なエージェントトポロジーの多様化を興奮して描き出しました。エージェント間のメッセージバス通信、非同期モード、多対多相互作用などです...... 絵は美しく描かれており、コンセプトも先進的です。 翌日、それは現実的ではないと気づいた。 問題は技術的な実装ではなく、複雑なパターンを作り出すことができます。 問題は、ユーザーがそれを理解できないことです。 Claude CodeのUIはシンプルな端末ですが、複雑なエージェントの通信モードをユーザーに理解させるにはどうすればよいのでしょうか? 彼らは最初からやり直し、根本的な問いに戻ることに決めました。すなわち、平均的な開発者が使える最もシンプルな形式は何か? 彼らは自らに2つの制約を設定しました。 まず、新しいものを発明しないでください。 Claude Codeがすでに持っている「/」コマンドと.mdファイルだけを使いましょう。 次に、エージェント同士のやり取りはやめましょう。 単純なオーケストレーションパターンに変更します:マスターエージェントが子エージェントを呼び出し、子エージェントがタスク完了後に結果を返すだけで終わりです。 また、Anthropicの研究チームとも話をしました。 研究者たちはマルチエージェントパターンの研究を続けていますが、複雑なエージェントトポロジーが実際に機能するかどうかはまだ結論が出ていません。 これにより彼らはより自信を持っています。研究チーム自身も複雑さが必ずしも良いとは限らないと言っているため、シンプルなバージョンを作る方が良いのです。 3日目の終わりに、動作するバージョンが作られました。 ユーザーは.mdファイルでサブエージェントの役割や機能を定義できます(例:「フロントエンドエージェント:React 19およびNext.jsの使用」)、Claude Codeが適切なタイミングで呼び出すか、ユーザーが手動でトリガーすることも可能です。 ハッカソンの後、少し磨き上げた後、この機能が公開されます。 今では、セキュリティ監査の専門知識を持つバックエンドエージェント、特定のフレームワークに精通したフロントエンドエージェント、テスト作成を専門とするQAエージェントなど、さまざまな排他的なサブエージェントを定義できます...... 彼らは背景で並行して作業し、それぞれの役割を果たすことができる。 多くのチームはハッカソンで複雑な計画を覆すことに躊躇するでしょう。結局のところ、彼らは一日中絵を描き、議論し、感情を持っているからです。 「この道はうまくいかない」と認め、それを覆してゼロからやり直すには、勇気と「シンプルさ」への信念が必要です。 シンプルさは怠惰ではありません。 簡単なのは、無数の選択肢の中からユーザーが本当に使えるフォームを見つけることです。

[7] 将来、エンジニアリングチームはどのようなものになるのでしょうか? 一部は参考文献として使えますが、一部はコピーできません ボリスは「プログラミングは今とても楽しいです。 こんな気持ちになったのは、中学生の時に初めてグラフ電卓にコードを書いた時でした。 長い間感じていなかったあの魔法のような感覚が、今また戻ってきました。 ” シドも同じように感じています。「私をワクワクさせることが二つあります。 一つは、私たちがリリースする速度で、時には速すぎると感じることもあります。 二つ目は実験的な空間が非常に多いです。前の作品は速かったものの、私がやったことはよりルーティンで、答えがわかっていても実行だけが重要でした。 今は違います。モデルは3ヶ月ごとに変わり、私たちは常にやり方を見直さなければなりません。 ” これらの感情は非常に現実的で伝染します。 しかし、「エンジニアリングチームの未来がどうなるか」を議論する前に、Anthropicの特化性を忘れてはいけません。 まず、Anthropicは研究機関であり、製品会社ではありません。 その中核的な使命はAIの安全性と能力の研究であり、製品は手段であり、目的ではありません。 つまり、平均的な企業よりも「迅速な実験」に対する寛容度がはるかに高いということです。 次に、彼らの主な製品はClaudeモデルそのものです。 Claude Codeはモデルの「殻」に過ぎません。 したがって、「モデルにより多くのことをさせるためにコードを削除する」というのは彼らにとって自然な選択ですが、他の企業にとってはコアとなるビジネスロジックをブラックボックスに委ねることを意味するかもしれません。 第三に、すべての従業員がClaudeに無制限にアクセスでき、最も高価なOpusモデルも含まれます。 多くの企業では、AIサブスクリプション料金は予算に関わらず争いが必要であり、すべての人が利用できるわけではありません。 第四に、チームは十数人しかおらず、プロセスも最小限です。 彼らは「遅すぎる」ために特徴フラグをほとんど使いません。 これは、ユーザーベースが大きく、エラーコストが高い製品では考えられません。 したがって、Claude Codeチームを直接コピーするのは、多くのチームにとって現実的とは限りません。 しかし、学ぶべきことはいくつかあります。 ラピッドプロトタイピングの考え方:1日に10個のプロトタイプを作れなくても、「2週間に1つ」から「週3つ」に変えられるでしょうか? ツールも変わり、「プロトタイプがどれだけ速いか」という期待も更新されるべきです。 AI支援コードレビュー:最初のレビューはAIに、2回目のレビューは人間に任せます。 このプロセスは、ほとんどのチームが試せる無制限APIアクセスに依存していません。 TDDの復活:テスト作成が十分に簡単になったら、「テストを書く時間がない」という言い訳はもはや通用しません。 これはコードの品質を向上させるための低コストの入り口となり得ます。 プロダクト志向のエンジニアの価値はさらに高まります。Claude CodeチームにはデザイナーやPMはおらず、数人のプロダクト志向エンジニアがいます。 AIツールはこの「フルスタック人材」の能力を大幅に拡大しました。

もちろん、道具で代えがたいものもあります。 ボリスは20のアーキタイプの中から最良のものを選べたのは、彼が批判的だったからだ。何が「しっくりくる」か、何が「見た目が良いか」を知っていたからだ。 この嗜好は17年のソフトウェア開発経験の結果であり、AIが与えきれないものです。 チームは初日に複雑な計画を立て、翌日には容赦なく覆してやり直すこともできる。これもまた人間の判断だ。 いつコードを削除し、いつ残すべきかを知ることも、このアーキテクチャ的直感においても同じです。 AIは実行を速くしますが、「何をすべきか分かる」ことを容易にするわけではありません。 代わりに、実行コストが下がったため、「何をするか」の判断がより重要になりました。20バージョンを短時間で作れますが、どれが正しいかを見極める必要があります。 数年後のソフトウェアエンジニアリングはどのようなものになるのでしょうか? 誰も正確に予測することはできません。 しかし、今日のClaude Codeチームは、多くのチームにとって明日のためのリハーサルのようなものかもしれません。より速い反復、「レンガ移動」が減り、より多くの判断と意思決定が求められます。 ツールは変わりつつあります。 変わらないのは、最終決定を下すのは依然として人々であるということです。