スタッフエンジニアがClaude Codeと歩んだ道のり！その真価とは？
引用元：https://news.ycombinator.com/item?id=45107962
LLMに関する議論はしばらく続きそうだね。結局、LLMは単純なコードや定型文以外は苦手で、デバッグやブレストに役立つ感じ。書かれたコードは常に監視して、修正が必要。LLMはソフトエンジニアの標準ツールになるだろうけど、誰も置き換えはしないよ。新人はLLMのレスポンス編集に苦労するだろうけど、Stack Overflowを使っていた時も似たようなものだ。ベテランは時間を節約できる時もあれば、無駄にする時もある。トータルで見ればプラスかな。
HNでこういう記事を見るたびに、『私はClaude Codeを厳しく管理して、短いフィードバックループで運転手は私。スタイルを説明するMarkdownファイルも使ってる』みたいなコメントばかりでうんざりだよ。いいんだけど、同じ話ばっかで飽きた。AIの話ばかりで疲れるけど、歴史が動くのを見るのは楽しいね。10年後にはこの頃の会話を振り返って、プログラマーにとってどんなにワイルドな時代だったか思い出すだろうね。
LLMやAI関連のキーワードがタイトルにあるHNのヘッドラインを自動で非表示にするFirefox拡張機能を作りたくてたまらないんだ。そうすればまた面白い記事が見つけられるのに。
Stack Overflowで自分でコードを書いていた時と違って、LLMをjuniorが使うと信頼が失われるよ。自分で解決策を探して統合する努力はスキルになるけど、LLMにやらせるとそれが身につかない。LLMが正解を出したとしても、それが次もそうとは限らないしね。effortが少なければ、その周りのことについて学ぶ量も減る。juniorがLLMを使うのは私の信頼を裏切る行為だよ。どうせ私の方がLLMのoutputを早く出せるんだから、君と付き合う意味がない。これが私の経験だね。
一発でコードを書かせたらそうだけど、複数のフォワードパスとバックワードパスを使う洗練されたエージェントシステムを使えば、品質はめちゃくちゃ向上するよ。私の設定だと、来年くらいにはそれが普通になって、会話もコスト管理が中心になるだろうね。来年には人気のagent control flow languageが出てきてもおかしくない。現状では教師なしAIエンジニアリングは人間のエンジニアリングより安くも良くも速くもない。でも2年後には変わるかもね。メッセージトラフィック、トークン使用、基盤モデル、ハードウェアのムーアの法則やエネルギーコストで多くの最適化があるだろう。でも、品質をコントロールするのはエージェントシステムの洗練度だよ。ウォーターフォール方式（まさか、と思うだろ？でも効果はあった）もコード品質を劇的に向上させたし、私がWikiWikiWebに書いたSelfDocumentingCodeパターン言語をコードレビューエージェントとして与えたら、さらに品質が上がったよ。
今はVCから資金が出てるからだけど、$20のパッケージは彼らにとって全然採算が取れてないよ。だから今のうちにありったけのモデルを盗んだみたいに使い倒して、ツールを作りまくってるんだ。そのうち彼らが本気で課金し始めたら、ローカルモデルはMCPsやツールと組み合わせれば『十分使える』レベルになってるだろうから、特別な場合を除いてAPIのトークン課金は必要なくなるはず。
ローカルモデルが十分良くなったとしても、クラウドプロバイダーは家では夢にも見ないような大量のコンテキスト、パラメータ、t/sを$20とかで提供してくれるだろうね。Groqみたいなサービスが今まさにそうだよ。
いつも同じ会話ばかりしてるから、もしかしてボットが提供してるんじゃないかと思っちゃうよ。
これ、すごくわかる。1日で1000行もの超複雑なPRを出してきたら、そいつが全部読んだわけでも理解したわけでもないってすぐわかるよ。
Ublock Originのカスタムフィルタリストでできるから、カスタム拡張機能は不要だよ。
agentic AIのコーディングツールを使えば、数分でサクッとコード作れるよ！(皮肉だけどね)
これこそコードレビューの出番だよ。ジュニアとのレビューはいつも時間かかるけどね。
＞ LLMが書いたコードは正確さ、スタイル、設計を厳しく監視して、半分くらいに編集する必要があるね。使ってる言語に強力なLintツールやスタイルチェックツールがあれば、LLMの仕事は楽になる。ルールを与えれば、LLMはテストとリンターを実行して、ルールに合うまで反復するよ。
でも、LLMのコードは冗長で、どんなに些細な状況でもカバーしがち。ローカルで簡単なプロジェクトをやってるのに、エンタープライズ向けのものをブートストラップするのはイラつくよね。
どんな学習でもフィードバックループ（できるだけ密な方が良い）がないと進まないよ。超短期から長期まで色々なサイクルがあるけど、本番バグやキャリアへの悪影響が最終サイクルだ。
ジュニアは最終的に学ぶだろうけど、先輩が協力し、組織が許せば、はるかに速く学べるよ。これはLLM以前の世界よりもさらに重要だね。
流行はサイクルでやって来ては去る… MVCフレームワークの全盛期やMVVC！って何年も飽きるほど聞いたのを覚えてるよ。ここには1、2年来なかったけど、今は1日1回くらい来て、いくつかスレッドをざっと見てる。結局、この業界全体が循環してるように感じるんだよね。
＞ LLMの有用性は高く、今や全てのソフトウェアエンジニアの標準ツールになるだろうけど、現在の能力では誰も置き換えることはない。その通り！問題は、インフラ、データセンター、計算、給与に何十億ドルも注ぎ込まれたことだね。LLMが本当に価値あるものになるには、私たちの大部分を置き換えられるレベルである必要がある。LLMはそうならないだろう。これはとんでもない誤投資だよ。
＞ 周りのことをあまり学べなかった
開発スキルが伸びたのは、Stack Overflow検索からドキュメントやコードを読むことに移行した時だ。最初は遅くても、周囲のコンテキストが重要だと分かった。これは見えない利益で、投資と似ているね。
Stack Overflow、Medium記事、LLMも使うけど、今はまずドキュメントを見るよ。CSやLLM界隈の「全てはシンプル」という思い込みは危険。エキスパートと初心者の違いはニュアンスを知るかどうかだ。ジュニアには分からないけど、エキスパートには分かるんだ。
HNの「Hide」機能を使うようなものを考えてるんだけど、AI関連の記事を隠したら、他の記事がページに表示されるようになるかなって。それってUblock Originでできるのかな？
僕たちは確実にデッドインターネットに全力で向かっていると思うよ。
https://en.m.wikipedia.org/wiki/Dead_Internet_theory
正直、試しにやってみようかな。新規でリスクが低い、使い捨てのプロジェクトには、こういうツールが genuinely 役立つよね。
Vibe Coders がリアルタイムで PM の基本を発見するのって面白いね。LLM とのプログラミングって、結局は PM と同じ。タスクを manageable な chunk に分けて、オンボーディング用の CLAUDE.md や、アクセスしやすい docs/ のような documentation が必要になる。人間チームを管理するのと同じだね。
いや、ちょっと違うな。モデルは intermittent な利用が前提だけど、sophisticated な agent flow で AI エンジニアを使うと、利用は constant で continuous になる。これは2年で自宅に専用キューブを置くのと同じくらい高くなるかも。今日、3つのプロジェクトを走らせて、Claude Max Pro のセッション制限に90分で2回も引っかかったよ。今は1つに絞ってて、夜まで中断することも。ラップトップで passively 動かせたらいいんだけどな。
いい点ついてるね、でもそうは思わないな。俺は今ほとんどの LLM/AI スレッドをブロックしてるから、一部のページはかなり sparse になる。もしあなたがそれをまとめるなら、ぜひチェックしたいね！
LinkedIn と Twitter がカナリアだよ。Text based な content は、もう scale で簡単に作れるから、手動で作成する utility はないんだ。
ここのサイクルは circle じゃなくて spiral なんだってことを覚えておいてね。俺たちは progressing してる、ただ気づくのがすごく遅いだけさ。
ちょっとした proof: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s…
Joel Test の項目について、20年以上経った今どうなったかを具体的にコメントしてるよ。例えば source control は20年間見ない会社はないし、daily builds もすごく widespread。昔より良くなった部分が多いって言ってるね。
まあ、いずれ reality と fantasy は収束するよね。いつかは誰も知らないけど、必ずそうなる。正直なところ、最大の危険は、すべての hope と dream が実現せず、high-risk な投資への appetite が消え去ることだよ。これまで money losing でもOKな時期があったけど、俺たちはその peak を過ぎたと思うし、これは destined to blow up だ。
最後の点だけど、俺にとっては time savings の面で about a wash だったね。boilerplate や throw away code には十分使えるけど、特に code quality を気にせず結果だけ欲しい場合だね。actual な production quality のコードを書かせようとすると、すごく時間を無駄にしちゃった。consistency と over-verbose な性質が、俺にとってはダメだったな。
そうだね、でも junior から学ぶ恩恵を reaping するべきだよ。progress がなくて、ability が獲得されたという trust がなければ、彼らはただの burden だよ。
LLMは学習にも使えるよ。シニアが会社に合わせたプロンプトを作ればもっと良くなるはず。
LLMコードを盲信するやつはクビにすべきだね。おかげで使えない奴を早く見つけられる。コードの質はどれだけ頭を使ったかで決まるんだから、ちゃんと考えるやつ以外はいらない。
もっとコメントを表示（1）
LLMでゴミコードを防ぐには、そいつの限界を理解するべし！
1) 複雑なことは避け、計画を小分けにしてテストさせる。
2) 複雑な問題は可視化コードを書かせる。
3) 失敗したらログで原因究明。
4) 既存の設計を参考にさせると良いよ。95%もゴミってことはないな。
そんなに手間がかかるなら、もう自分で書けばよくない？
複雑なタスクは「今すぐコードは書くな。ステップごとに詳しく説明するから」って言うと上手くいくよ。ClaudeがTODOリスト作って詳細を聞いてくれる。途中で止めても、次に再開しやすいし。
結局、自分で書いた方が早いって気づいたよ。やりたいことが分かれば、コード書くのは簡単だしね。AIは思考整理のラバーダックとして使って、コードは自分で書くのが一番だね。
上で言われてることを全部やっても、結局使い物にならないコードばかり。たまに成功すると嬉しいけど、正直効率は上がってない気がするな。
個人プロジェクトで「vibe coding」ってのをやってるんだけど、テスト駆動開発と相性バッチリなんだ。問題を小さいテスト可能な塊に分けて、まずAIにユニットテストを書かせて、その後に実際のコードを実装させるのがいい感じ。
知ってた？ Shift-Tabを押すと「Plan mode」になるんだって。これでClaudeが勝手にコード書き出すのを防げるよ。
「Plan mode」って言っても、実際は結構勝手にファイルいじっちゃうから安全じゃないよ。いっそ完全にサンドボックス化したVMを用意して、Claudeが rm -rf しても気にしない環境にするべきだね。
Planモードだとツールが無効になるから、どうやって実行するのかわからないな。
でも、サンドボックス化されたdevcontainerを設定するのは価値があるよ。—dangerously-skip-permissionsで実行できるしね。
キモはプロンプトだよ。プロンプトは命がけで練るべき。ソースコードみたいに扱って、ファイルで編集したり、@記法でコンソールに持ってきたりしよう。
Claude自身にプロンプトを生成させるのもアリ！このGitHubリポジトリは超便利だぞ：
https://github.com/wshobson/commands/
https://github.com/wshobson/agents/
これらにはプロンプトエンジニアのペルソナも含まれてる。今じゃAIに怒鳴り散らすこともあるけど、手動でコードを書くことはほとんどないし、品質もまぁまぁ。Claudeが作ったコミットをリファクタリングしてみたけど、とんでもない時間かけても微調整しかできなかったよ。その時間をプロンプト改善に使えばよかったな。認知負荷と労力を減らせるし、標準的なライブラリや言語を使うのが良くて、テストは必須だね。「thinking」コマンドもめちゃくちゃ使えるよ。
実際、人間にとって認知負荷を減らす優れたエンジニアリング原則は、AIにも通用するんだよ。
このアドバイス、何度も見てきたし、効果があるのはわかるんだけど、そろそろ製品自体にこの共通戦略を組み込むべきじゃないのかな…って思うんだ。
俺もわからないんだけど、Planモードでファイルに書き込むのを見たことがあるよ。すごく混乱するよね。
この記事にまた戻ってきたよ。仕事でも個人プロジェクトでもClaudeをかなり使ってるんだけど、使えば使うほど、スクリプトより大きいものになると出力の品質にがっかりしちゃうんだ。
計画を立てたり、思考を明確にするのは大好きだよ。まるでターボチャージされたラバーダックだね。でも、すごいエンジニアではないんだ。
素朴な疑問なんだけど、「計画を小さなステップで実装するように頼む」って、具体的にどういうこと？「この変更を小さなステップで実装してください？」ってそのまま聞くのか、それとも自分でステップを考えて「これを小さなステップで解決して。最初のステップはパーサーにコードを追加して、最初の新しいXML要素を処理できるようにして。Xの変更を頼むね。YとZは後でやるから」みたいに聞くのか。他にも方法はあるだろうけどね。
「これをエージェントにやらせられるかな？」っていう罠にはまっちゃって、結局自分でやれば10分の1の時間で済んだ、なんてことがあったよ。
今は、どの戦いを選ぶかがスキルの一部だね。
僕はAIを、vimのマクロではちょっと難しい定型作業とか、退屈なタスク、小さいスクリプト作成とかに使ってるよ。
これが大きな秘密だよ。コードをモジュール化して、小さく、単一目的で、カプセル化すれば、Vibe Codingとすごく相性がいいんだ。
Claudeなんかが作るMarkdownドキュメントみたいな、モジュールごとのプロトコル／メタ言語を書きたいな。それで振る舞いを定義して、自然言語で明確なインターフェースを持つモジュールを実際にプログラミングして組み合わせられるようにするんだ。まだ誰もやってないのが驚きだよ。
今起きてることが、なんか変だなって思うんだ。面白いのは、俺たちに必要なのは「少ないこと」なんだよ。全部が少なくて、でも品質は上がる。これって人間がやること全部に言えるよね。門が開くと生産者がどっと増えるけど、そのせいで粗悪品が山ほどできて、だんだん人々のセンスが鈍っちゃう。エンジニアは、より速く、より多くのコードを書く必要はない。ビジネス組織の他の人たちとうまく連携し、プロジェクト選定や時間配分の決定を良くすることにもっと長けるべきだよ。コードを書くなんて、優れた製品を出したり市場シェアを伸ばしたりするための一部分でしかないんだから。LLMとのやり取りで思考力が落ちる、って話もあるしね、まあ、頑張ってくれ。
「効率的じゃない」って意見、マジそれな！俺も最近、自分でコード書かずに100%AIだけでアプリ作ってみたんだけどさ、APIとかReact-Nativeフロントエンド、CMS、CI/CD全部AI任せ。出来上がったコードは意外と良かったけど、自分でやれば1/3の時間で済んだわ。詳細な仕様書とかテストが生成されないのは残念だったな。
あんたのヒント、マジ完璧！「Steamのクローン作って」とか「ロケット作って」みたいな漠然とした指示出して、Claude Codeのせいにする奴多すぎだろ。AIにコード書いてほしいなら、プロダクトオーナーみたいに問題を分解しなきゃダメ。AIも手伝ってくれるけど、計画と仕様は必須。問題はAIじゃなくて、使い方を学ばないユーザー側にあることが多いんだよ。
俺はLLMと一緒にステップバイステップの計画を立てるんだ。やりたいことと関連ファイルを渡して、変更の全体像、ファイル一覧、計画を作らせる。この時「伝統的なチームじゃなく、技術アーキテクチャだけを考えろ」って指示するのがコツ。計画ができたらLLMと何度もレビュー修正し、まとまりを評価させる。完璧になったら、新しいコンテキストで「@MY_PLAN.mdをレビューしてステップ1を実装、ステップ2の前で止まれ」って指示して作業するって感じ。
AIを使うと、人間が同じ量の仕事をするのが楽になるみたいだね。Claudeとかとチャットしながら作業すると、もっと多くの仕事ができる気がする。ワークライフバランス的には諸刃の剣だけど、本業で精神的に疲れ果てることが減って、またプログラミングとかサイドプロジェクトを楽しめるようになったのは嬉しいな。
モデル開発者ってモデルの使い方が分かってないんだよな。一流AIラボで面接したけど、ビジネス価値を理解してる奴いなかったし。一方、中国ラボは優秀なオープンソースモデルを出してる。俺はClaudeやOAIの有料版より優秀なローカルエージェントツールを自作してるぜ。1クエリで数ドル〜数百ドルかかるから、ハードが進化するまでは、金持ちが使うだけだろうけどな。
「LLMと関わると思考力が低下する」って意見もあるけどさ、俺はAIのおかげで新しいことを効率的に学んだり生み出したりできるって思うんだ。みんながそうなったらどうしようって不安になることもあるけど、こういうコメント見ると「結局、ほとんどの人は試そうとすらしないんだな」って安心するわ。
これって、はっきり決まってる繰り返し作業にはかなり使えるんだよね。でも、個人的にはプロンプトにそんな手間かけるくらいなら、自分でコード書いた方が楽だって感じるわ。
「ほとんどのユーザーは『Steamのクローン作って』とか『ロケット作って』みたいな漠然とした指示を出す」ってのは、HNでAIが嫌われてる理由の半分を占めてそうだな。AI嫌いとか役に立たないって言う奴らは、AIと戦ってるだけで、使い方を学ぼうとしてないように見えるよ。俺はまだ、珍しい言語とか独自システムでもAIが使えないって良い例を見たことないし。
問題はね、細かい計画を立てるのにそんなに時間かけたら、AIエージェントを使うことで得られる生産性アップが全部帳消しになっちゃうことだよ。エンジニアなら、特に経験積めば、変更の計画はすぐ頭の中でできて、今のステップを実装しながら次のステップも考えられるようになる。このプロセスって、結局世界で一番不正確で、一番冗長なプログラミング言語を作ったようなもんだろ。
トークン予測器がどうやって候補をスコアリングするのか、疑問だよ。Pythonスクリプトとかツールを使ってるの？もしそうじゃないなら、ただ統計的にありそうなスコアを出すだけで、ちゃんと計算してるわけじゃないんじゃない？
人それぞれだよね。俺は気をつけないと16時間ぶっ通しでコード書いちゃうくらい楽しいんだ。でもAI相手だと、そこまで根気強く付き合えないかもな。
Claude Codeに.envファイルを読ませようとしたら、パーサーを自作し始めたんだ。Nodeの組み込み機能を使えって言っても、また自作しようとするし。
Claude Codeはすごいけど、簡単な要求でも的外れなことするから困るわ。
もっとコメントを表示（2）
Claude Codeが、人間より早く、本番レベルの堅牢なコードを非自明な問題で書く動画、誰か知らない？デモじゃなくて、独立したプログラマーのライブストリームで、デプロイ済みで追加作業なしで動くやつね。
コードレビュー、テスト作成、PR作成まで含んでて、グリーンフィールドプロジェクトじゃないのがいいな。
俺もClaudeを使いたいけど、現状だとオートコンプリート以上は品質が低くて非効率って思ってるから、証拠を見せてほしいんだ。
この動画[0]は関連してるけど、君の意見を裏付けてるよ。Claude Codeが複雑なタスクで苦戦して、たくさん手助けが必要なのがわかる。
君の条件に合う動画って、ほとんどないと思う。AIコーディングのデモは、簡単な問題ばかり選ぶか、現実のコード保守の面倒な部分を飛ばすからね。
[0] https://www.youtube.com/watch?v=EL7Au1tzNxE
AIだけでタワーディフェンスゲームを1週間で開発したライブストリームとプロンプトを公開したよ。https://news.ycombinator.com/item?id=44463967
人生で複雑なゲーム作ったことないけど、AIなしじゃ何週間もかかるだろうな。今、Final Fantasy VIIの3DワールドマップエディターもAIメインで作ってるんだ。もうすぐ完成で、記事と動画にする予定だよ。
君は「本番じゃない」とか言うかもしれないけど、俺にとってはAIのおかげでプロジェクトを完成させられるから、めちゃくちゃ助かってるんだよ。
ライブストリームもいいけど、ffmpegとかcurlみたいな複雑で活発なOSSプロジェクトのメンテナーの意見が聞きたいね。
優秀なコーディングLLMが十分普及してるんだから、もし非自明なコード作成に役立つなら、これらのプロジェクトへの良い貢献が増えてるはずじゃない？
「AIのおかげでプロジェクトを完成させられるのが重要」って言うけど、君の「プロジェクトを完了する」定義に問題があると思うな。
そのコードをサポートしたり、拡張したり、バグを見つけたりできる？プロの現場じゃ、全部「はい」って言えないとダメだよ。それがプロダクションコードだからね。
良い動画だね！Rustみたいなニッチな言語でも得意な部分と、直接の欠点も見えてきた。
Rustは訓練データが少ないから、TSとかJavaより訓練されてないんだ。君は2.5時間でテストもドキュメントもコミットメッセージも完璧な機能を追加したけど、これは80%のデベロッパーじゃ無理だよ。
あと、gitとgitメッセージで時間とトークン使いすぎ！いくつかヒントを教えるね。
#1: git用のサブエージェントを用意して、Claudeのコンテキストを汚染しないようにする。
#2: Claudeのフックを使って、Rust fmtみたいなフォーマッターを走らせる。
#3: テスト範囲を制限する。LLMは過剰なテストを書きがちだからね。
#5: 「タイトルは最大50文字」って言っても、LLMは文字数を数える能力がないんだ。これはLLMの設計上の問題だから、LLMと議論しても無駄だよ。
みんな自分の仕事風景をライブストリームで配信してるんだから、実世界で技術をどう使うかの具体的な例やチュートリアルを求めるのは全然無理な要求じゃないよ。
俺は君の意見に反対だな。プロジェクトを終わらせるものが何かっていうより、M4v3Rとrhubarbtreeが「非自明な本番環境」のソフトウェアについて話す時の認識のズレが問題なんだ。
企業で働いてると、複数の利害関係者がいて、要件が矛盾することもよくある。しかも、それらの要件に厳密に従う必要がある。そういう環境は、Vibe Codingには本来向いてないんだ。
使うことはできるけど、LLMが常に細かい動作変更を導入するから、2～3倍のスピードアップなんて望めない。M4v3Rのシナリオではそれが問題なくても、rhubarbtreeにとっては致命的だろ。
俺の経験から言うと、職場ではClaude Codeが禁止されてるからCoPilot agentic modeを使ってるけど、スピードアップは全然ないね。でも、何の特定の仕様にも従う必要がないプロジェクト、つまり自分の時間のプロジェクト（今はClaude Codeを使ってる）では、生産性が大幅に向上したよ。
CoPilot agentic modeは使い続けてるけど、時間を計ったわけじゃないけど、速くなったとは思わないな。ただ、多くのシナリオで精神的な負担が減るから、疲れにくくなって、副業に使えるエネルギーが残るんだ。
Armin Ronacher（FlaskやJinjaなど、PythonとRustのオープンソースコミュニティの長年の功労者）が部分的にこれに合うYouTube動画をいくつか出してるよ。
https://www.youtube.com/watch?v=sQYXZCUvpIc
https://www.youtube.com/watch?v=Y4_YYrIKLac
https://www.youtube.com/watch?v=tg61cevJthc
「Git用のサブエージェントを追加して、自分のスタイルを学習させ、直接Claudeのコンテキストを汚染しないようにして、トークンや時間を節約する」って、これどういう意味？具体的にはどうするの？Claudeで何かを呼び出すの？それとも別のClaudeのウィンドウを開くの？
問題は要件じゃなくて、コードそのものだと思うな。たとえグリーンフィールドプロジェクトでも、規模が大きくなれば同じ問題に直面するよ。
数千行程度のコードなら、コードの肥大化や急場しのぎ、一貫性のないAPIでもある程度はごまかせる。でも、数千行を超えるプログラムだとそうはいかない。混乱するだけだよ。意図的に設計する必要があるんだ。認知負荷を減らすためにコードはパターンに従い、予測可能な方法で分割されるべきだね。
もう一つの問題は、賢明で予測可能なメンテナンスだよ。変更や修正は的確で具体的であるべきだし、副作用を避けるように書かれるべきだね。
組織にとって、過去30年間、コードをより良く整理することで理解しやすくするのは、みんなの多大な努力だったんだ。言語の改善、ボイラープレートの削減、匿名メソッドのような言語間のアイデアの相互受容など、様々な方向から進化してきた。一方で、開発者はパターンを発明したり説明したり、KISSや単一責任原則を提唱したり。予測可能なフォルダ構造を選んだり、インデントルールを強制したりするような、一見些細なことまでね。
最近は、シニアデベロッパーの主なスキルは、コードをうまく整理することだと感じ始めてるよ。
コードの整理が改善されたおかげで、開発者はより大規模なプログラムを作れるようになったんだ。コードの整理は、大規模プロジェクトでうまくいかないと大きな問題になるけど、小規模プロジェクトでうまくいかなくても、そこまで問題にはならないね。
そして今、AIはコードの整理がまだ得意じゃないんだ。プログラム全体のメンタルモデルを頭の中に持っている必要があると俺たちは信じてるけど、LLMには今のところそれができない。これは巨大なコンテキスト問題に思えるから、解決できる問題になるかどうかは分からないな。
メンテナンスに関しては、どうだろうね。AIはかなりひどいと思うよ。しばしば全てを書き換えて、良い部分も一緒に捨ててしまう。これもまたコンテキスト問題だね。
どちらも、最終的にはこの世代のAIで簡単に解決できる可能性もあるけどね。
[1] 若いプログラマーは信じないだろうけど、15～20年前でさえ、開発者がコードのインデントをきちんと揃えないのがよくある問題だったんだ。俺の最初の2つの仕事では、インデントがバラバラなコードによくぶつかったよ。
「あなたの基準を満たす動画が少ないのは、ほとんどのAIコーディングデモが簡単な問題を抜き出すか、実際のコードベースをメンテナンスする面倒な現実を省いているからでしょうね」
それか、俺たちはただ何かを作るのが楽しくて、誰も納得させられない人たちを説得するための動画を作る暇がないだけだよ。
同感だね。俺の非常に主観的で限定的な経験（友人や同僚の話も含む）からすると、AIから得られるソリューションは、2日間のハッカソンで作るようなもの。それを本番環境で使えるようにするには、何ヶ月もかかるんだ。
で、キラキラした目のCEOがいつもの質問をしてくるんだ。「2人チームが2日でピカピカの新しいものを作れたのに、どうして何でもそんなに時間がかかるんだ？」ってさ。ため息が出るね。
初期のプロトタイピングには使えるかもしれない。最初のエンジニアを雇う前に、そして6ヶ月後にクビにする前にね。
自分の作業風景を録画したい人なんてほとんどいないし、ネットの議論に勝つ以外に誰かを説得するインセンティブもないよ。
これはしばらく自分で実際に使ってみて、自分のワークフローやプロジェクトでどう機能するかを見るしかないことだね。
Jon Gjengset（MIT Missing Semester、Rust for Rustaceansなどで有名）が、Rustの地理空間数学ライブラリで複雑な変更を段階的に行うストリームを共有してたよ。彼は優れたエンジニアで、AIが提案した変更をうまく取捨選択していたね。動画は少し長いけど、うまくセグメント化されてるよ。
彼は全体的にポジティブな経験だったと思うけど、ストリーム全体を通して、純粋なエージェントワークフローにすぐに制御を譲るつもりはないことは明らかだったね。
https://youtu.be/eZ7DVHAK8hw?si=vWW4kz2qiRRceNMQ
Claude Codeを使ったライブストリーム開発の実演を求める要求に対し、そんな無茶はできないと反論してるよ。多くの人がストリーム配信してるのに、なぜAIツールでの開発配信がないのかって疑問を投げかけてる。AIの真価は検証できないって指摘だね。
Claude Codeに関する具体的なデータとグラフがあるYouTube動画へのリンクを貼ってるよ: https://youtu.be/tbDDYKRFjhk?t=623
プロ開発者なら3〜4週間使えば、Claude Codeの得意不得意がわかるはず。使い始めは劇的な効果は感じられないけど、徐々に理解できるって話だね。
俺は40k LoCのRuby on Railsや45k LoCのElixir/PhoenixプロジェクトでClaude Codeを使いまくってるぜ。ここ数ヶ月の変更の99%はClaude Codeにお任せ。エディタはほとんど使わない。一発で完璧じゃないこともあるけど、フィードバックすればすぐ直してくれる。コードの整理はイマイチだけど、Diffで確認するから問題ないね。
俺の同僚たちもClaude CodeでPRの70-99%のコードを生成してて、仕事が速くなってるみたい。経験豊富な人でも使ってるよ。バグ増加の懸念はあるけど、生産性は上がってる。注意点は、レビューを怠らないこと、明確な仕様、タスク分解、クリーンなコードアーキテクチャが大事ってことだ。俺は検証動画作るより、ものづくりを楽しみたいね。
2日かかる作業が15分で終わるんだぜ。それに、何ヶ月もかけて本番準備するなんてありえないだろ？“本番準備”って、100%テスト済みの完璧な状態ってこと？人間が作ったほとんどのクソコードだって金を生み出してるんだから、完璧じゃなくていいんだよ。
1、2ヶ月使ったけど、Claude Codeは俺には合わなかったな。グリーンフィールドではまだマシだけど、レガシーコードのリファクタリングではイライラしっぱなし。変な回り道したり、同じミスを繰り返したりして、結局後退しちゃう。フィードバックループがないのが問題だと思う。何がダメで何が良いかを学習して、次に活かす機能が欲しいね。
ライブストリームしてる人って、趣味とかオープンソースプロジェクトがほとんどだろ。会社コードだとNDAの問題があるし。OPが求めるライブストリームの条件（デモなし、非グリーンフィールド、難易度高、本番レベル、レビュー、テスト、PR、ライブ配信）は、正直無茶すぎる。自分でチュートリアル見て試せばいいじゃん。
まず、OPは“誰かやったことある？”って聞いただけで、“誰かやってくれ”とは言ってないだろ。あと、“すごい”って言うなら、それに見合うだけの証拠を出すべきだよ。
俺もAIツールの評価には懐疑的だけど、このままじゃ取り残されそうで不安だ。AIツールって、最初はピンと来なくても、的確な指示とコンテキストを与えれば使えるようになるって話が多いよね。俺がうまく使えてないだけなのかも。Claude Codeに間違いを教えても、ちゃんと改善されるかは運次第だけど、無視するには強力すぎるツールだから、誰かに先を越されたくないな。
