ハクソク

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

Opus 4.5は、これまで私が経験してきた通常のAIエージェントとは異なります。

101日前原文(burkeholland.github.io)

概要

  • 3ヶ月前はAIエージェントによる開発者の完全代替に懐疑的だったが、Claude Opus 4.5の登場で考えが一変
  • Opus 4.5は従来のAIとは異なり、実用的かつ高品質なコード生成が可能
  • 複数の実プロジェクトでOpus 4.5がほぼ自動でアプリやバックエンドを構築
  • コードの可読性よりもAIによる保守性・再生成性を重視した開発スタイル
  • セキュリティやコード品質のチェックもAI主導で実施

Claude Opus 4.5で変わったAI開発体験

  • 3ヶ月前までは「AIが開発者を完全に代替する」は非現実的という認識
  • Opus 4.5の登場で、AIエージェントが実用レベルで開発者を置き換える可能性を実感
  • 従来のAIはスパゲッティコード生成やエラー反復で非効率だった印象
  • Opus 4.5は一発で正しい実装が多く、エラーも自動で修正
  • AIによる開発の約束がついに現実化した感覚

プロジェクト事例：AIによるアプリ開発

  • Windows画像変換ユーティリティをOpus 4.5で構築

    • エクスプローラーの右クリックメニュー追加などを一発実装
    • dotnet CLIでビルド・エラー修正も自動化
    • XAMLエラーのみ手動で対応
    • 配布用サイトやGitHub Actionsも自動生成
    • アイコン生成はFigma AI、変換スクリプトはOpus 4.5が担当

  • GIF録画・編集アプリも短時間で開発

    • LICEcap風アプリをベースに、動画・画像編集機能まで拡張
    • 数時間で主要機能を実装

  • AI投稿ユーティリティ（React Native→iOSアプリに）

    • Facebook認証や画像投稿スケジューリングなど複雑なバックエンドもOpus 4.5が自動構築
    • Firebase CLIを活用し、必要なリソースも自動作成
    • エラー発生時もログから自動修正
    • 管理用ダッシュボードも自動生成

  • 注文管理・ルート最適化アプリ

    • Gmailから注文解析、ルート計算、運転時間記録などを一元化
    • 以前は有料アプリ2つで対応していた機能を統合
    • Google認証も一発実装

コード可読性よりAI保守性を重視した開発スタイル

  • コードの仕組みを人間が理解していなくても運用可能という新しい発想
  • VS CodeでOpus 4.5に「LLM向けコード最適化」を指示
  • 人間可読性よりもAIによる再生成・デバッグ容易性を最優先
  • 必要なのはシンプルなエントリーポイント、明示的な構造、最小限の抽象化
  • 変数名や人間向けコメント、複雑なパターンは不要

LLM向けコーディング原則（抜粋）

  • 一貫性のあるプロジェクト構造、機能単位でのコード配置
  • フラットで明示的なアーキテクチャ
  • 線形でシンプルな制御フロー
  • 再生成性重視（どのファイルも単体で再生成可能）
  • プラットフォームの慣習を直接利用、過度な抽象化は避ける
  • テストは観測可能な動作検証に集中

コード品質・セキュリティチェックもAI主導

  • AIに「LLMコーディング原則に基づいたリファクタ案」をMarkdownで出力させる運用
    • 高・中・低優先度でリファクタポイントを提案
    • 必要なものだけを修正、無意味な変更は避ける
  • セキュリティチェックもAIに実施させる
    • APIキー管理、認証・認可、機密情報の取り扱いなどを重点チェック
    • この部分は手動確認も必要で、現状最も慎重になる工程

AI主導開発の今後

  • Opus 4.5による開発は人間の役割やコードの在り方を根本から変える可能性
  • AIが書き、AIが保守するコードという新しいパラダイムの到来
  • セキュリティや品質担保のため、人間による最終確認は依然重要な課題

Hackerたちの意見

Opus 4.5、めっちゃ進化したよ。知識の面では前からすごかったけど、今は自立して行動する能力がすごい。意思決定したり、問題を解決するために一緒に考えたり、フォローアップの質問をしたり、計画を立てて実行することができる。自分の実際の問題で体験してみないとわからないけど、数日や数週間の間にね。コーディングの問題を明確に定義できた範囲内では、チャットボットが解決できたんだ。しかも簡単じゃなかった。単にコードを書くことやテストすることだけじゃなくて、リバースエンジニアリングやエンコーディングに関する問題を解決することも含まれてた。一番印象的だったのは、フィードバックループがすごく活発に働いてたところ。最近の数週間、プライベートでコーディングはほとんどしてないんだ。代わりに、指導したり、仕様を書かせたり、それを洗練させたりしてた。複雑で大規模なプロダクション環境でどうなるか、ちょっと興味あるな。
└
> 最近の数週間、プライベートでコーディングはほとんどしてないんだ。代わりに、指導したり、仕様を書かせたり、それを洗練させたりしてた。これが基本的に俺のサイドプロジェクト全部だよ。
└
> 自分の実際の問題で体験してみないとわからないけど、数日や数週間の間にね。どうやってオーバーエンジニアリングを防ぐの？
└
いくつかの例はもう公開してるよ。もっと複雑なものも進行中。 [0]では、いろんなコーディングエージェントをベンチマークしようとしてる。 [1]では、Opus 4.5だけを使って古いC64ゲームをリバースエンジニアリングに成功した。これがビジネス的にリアルじゃないって責められても仕方ないけどね。 [0] https://github.com/s-macke/coding-agent-benchmark [1] https://github.com/s-macke/weltendaemmerung
└
最近、Claudeのウェブアプリを使って、まるでラバーダックのようにしてるのが自分に合ってるなって思う。コードのスニペットを与えて、やってることを洗練させる手助けをしてもらってる。Claude Codeを使うと、自分のコードベース全体を一度に見ることができるから、すごく能力が増すんだけど、全体を見た方がいい時に、すぐにクォータを使い切っちゃうのが問題なんだよね。狭い範囲でやる時は、ウェブサイトを使う方が簡単で早いから、結局ウェブサイトに戻ったんだ。そっちの方が早く進む気がする。
ほとんどのソフトウェアエンジニアは、今のLLMエージェントの良さに気づいてないよ、特にClaude Codeみたいなやつ。Claude Codeをセットアップしたら、自分のコードベースに向けて、慣習を学ばせて、ベストプラクティスを取り入れて、すべてを洗練させて、まるでスーパーパワーを持ったチームメイトみたいに動くようになる。実際の鍵は、再利用可能な「スキル」のしっかりしたセットを作ることと、普段やってることに合わせたエージェントをいくつか用意することだよ。例えば、カスタムUIライブラリがあって、Claude Codeにはその使い方を説明するスキルがある。同じように、Storybooksの書き方やAPIの構造、基本的にリポジトリでやりたいこと全般についてもね。だから、生成されるコードは、最初から私たちのパターンや基準に合ってる。さらに、Claude CodeにESLintの自動化を作らせたんだ。カスタムESLintルールや、レビューに入る前に多くのことをキャッチして自動処理するリントチェックも含まれてる。で、さらに進めて、変更があった後に深いコードレビューを行うエージェントもClaude Codeが動かしてる。PRが上がると、詳細なマークダウンチェックリストに従ってフルPRレビューを行う別のClaude Codeエージェントもいる。さらに、スケジュールに沿って動くClaude CodeのGitHubワークフローエージェントが5つくらいあるんだ。そのうちの一つは、先月のすべてのコミットを読み取って、ドキュメントがまだ整合しているか確認する。もう一つは、エンドツーエンドのカバレッジにギャップがないかチェックする。そんな感じで、メンテナンスや品質の作業が自動化されてる。めっちゃスムーズに動いてるよ。チケットのトリアージにもClaude Codeを使ってる。チケットを読んで、コードベースを掘り下げて、何をすべきかコメントを残すんだ。だから、エンジニアがそれを引き受けると、もう半分は終わってる状態から始められる。ここには低いところにぶら下がってる果実がたくさんあって、みんながそれに飛びつかないのが本当に不思議だよ。2026年は目覚ましになるだろうね。（音声入力してからClaudeに言い換えてもらったから、手書きするのは面倒でごめん！）編集：例のリポジトリを作ったよ https://github.com/ChrisWiles/claude-code-showcase
└
お！広告だ！
└
同意するし、スキルは大きな鍵だよ。codex cliにはスキルを作るスキルもあるし、すぐに使えるようになるのがめっちゃ簡単だよ。 https://github.com/openai/skills/blob/main/skills/.system/sk...
└
ほんと、AIコーディングを試した人が多いと思うけど、エラーにイライラして諦めちゃったんじゃないかな。それが、こういう悲観的な予測を拒否する理由だと思う。わかるよ。Claude Codeでコーディングするのは、何かを促してエラーが出て、それを直してもらうって感じだったから。まだ役に立ったけど、複雑なコードベースに機能を追加する熟練したコーダーが諦めるのも理解できる。でも、Opus 4.5は本当に新しいレベルに達してる。単純に…動くんだ。エラーもかなり少なくて、ほとんどが「うっかり」ミスで、根本的な問題じゃない（例えば、nextjsのクライアントコンポーネントに「use client」を追加し忘れるとか）。
└
プログラマーっていう職業が、特定のニッチを除いてはあまり存在しなくなる世界に入ってる気がする。プログラミングできること（特にコードを読む能力）は、価値が減るとはいえ、まだ役に立つだろうね。もっと重要なのは、必要なツールを使って実際に物を作り出す能力だと思う。それが本当に役立つものであることが大事なんだよね。まあ、これは昔から変わらないことでもあるけど、今は間接的な要素が少なくなった感じ。
└
あなたに興味をそそられる。 >「自分の慣習を学ばせる」ってどういう意味？ 自分の慣習を自動的に抽出してCLAUDE.mdに保存する方法ってあるの？ >「例えば、私たちはカスタムUIライブラリを持っていて、Claude Codeにはそれを使う方法を説明するスキルがある。ストーリーブックの書き方、APIの構造、リポジトリ内でのすべてのやり方についても同様だ。だから、生成されるコードは、最初から私たちのパターンや基準に合っている。」 これらのスキルを自分で開発しなきゃいけなかったの？どれくらいの労力がかかったの？公開されている例はどこかにある？
└
大学で教えていて、研究や趣味でプログラミングにたくさんの時間を使ってる。多くの人と同じように、休暇中にCursor、Claude Code、Codexの現行バージョンをできるだけ試してみたよ。（どれもすごく良い。）自分が欲しいもののアイデアがあって、散発的に5時間で使えるレベルまで持っていけた。いくつかの視点で考えてるんだけど、 1. AIなしでやったら、フルタイムで2週間かかると思う。（フルタイムは>> 40時間/週と定義。） 2. プログラミングよりも「もっと重要」とされることが他にたくさんあって、2週間フルタイムを「やりたい」プロジェクトに割けない。だから、AIなしでは全くやらなかっただろう。 3. 誰かにやってもらうこともできる。大学では学生がそうだね。たくさんアドバイスしてきた経験から言うと、トップレベルの学部生なら、学期中に全力でやれば同じことを達成できたはず（LLM以前の話だけど）。もちろん、毎週会ってる前提だけど。
└
AIが生成したREADMEにディレクトリ構造のセクションがあるのが、すごく冗長に感じる。だって、treeコマンドを実行すればいいだけじゃん。
└
> ほとんどのソフトウェアエンジニアは、今のLLMエージェントがどれだけ優れているかを全然理解していない、特にClaude Codeみたいなものに関して。誰も寝てないよ。私は毎日LLMを使って簡単なコーディングタスクを手伝ってもらってる。でも、急ぐ必要があるの？今のところ、数週間も経たずに次の画期的なものが出てくるからね。なんで「学ぶ」必要があるの？（実際、ここで学ぶことなんてないし）出てくる頃にはもう古くなってるツールやワークフローを学ぶために時間を使うなんて。> 2026年は目覚ましの時期になるだろう。AIを使わない開発者が、2028年や2029年にLLMのワークフローに適応できないと思う？2026年じゃなきゃダメなの？それとも...何があるの？急ぐ必要なんて全くないよ。あなたは80年代の初めてのポータブルCDプレーヤーを使っているようなものだよ：大きくて、重くて、動作が不安定で、巨大なバッテリーが付いてた。でも、光ってたよね、新しいものが好きな人には。ほかの人たちは、スリムでバッファリングができて、ちゃんと動くポータブルCDプレーヤーを待ってるんだ。あなたは、最初に重いのを使わなかったから、スリムなCDプレーヤーにCDを入れる方法を学べないって言ってるの？
└
新しい俳句も作ったよ。賢さはないけど、すごく速いんだ。コード変更の影響をレビューしたり、広く浅い変更が必要なときは、ファイルをスキャンして変更プランを作成してくれる。ClaudeやCodexが落ち着くのを待つ時間を大幅に節約できるよ。
Opus 4.5が先月、私のCopilotのクォータを使い切っちゃって、今月ももう半分使った。すごく複雑なコードにたくさん使ったんだけど、結論としては、まだ良い人間のプログラマーには及ばないってこと。頻繁に行き詰まったり、間違った方向に進んだり、指示したことを無視して間違ったことをしたり、以前のミスを繰り返したりすることがあった。でも、他の面では信じられないほど良い。コードのディレクトリを分析させると、これはKozo Sugiyamaのdagreグラフレイアウトアルゴリズムの実装だって教えてくれて、エラーのあるファイルもすぐに特定してくれる。これは本当にすごい。でも、エラーを直すことはできない。エラーは以前のセッションで出た多くのエラーの一つだったから。だから、私の結論は、コード分析には素晴らしいけど、複雑な問題を自分で解決することはできないってこと。昨日と今日、依存関係のアップグレードのためにユニットテストをたくさんアップグレードしてたんだけど、時々すごく助けられたけど、頻繁に行き詰まった。いつもより多くのことを同じ時間で進められたけど、やりすぎじゃなかったかとも思う。もっと簡単な方法はなかったのかな？探さなかったけど、Opusの解決策は毎回明らかで簡単に見えたから、どれだけ深い穴にはまっているのか全然わからなかった。もっと批判的に考えるべきだったな。
└
AIをコード分析に使うのは、もっと評価されるべきだと思う。コーディングに対して懐疑的な人たちも、Q&Aスタイルのコードの検証やドキュメント生成のツールとして試してみるべきだよ。ドキュメント生成に関しては、ほとんどの人間の努力よりもゼロショットでうまくやると思うから、最初からドキュメントが必要かどうか疑問に思うくらい。もちろん間違いはあるけど、見た限りでは人間のミスよりも少ないと思う。
└
サードパーティツールを使うときは動きが違うよ。Claude CodeとClaudeのサブスクリプションを使ってもう一度試してみて。VS CodeやCursorでもチャットウィンドウとして動かせるから。
└
Copilotや多くのコーディングエージェントは、コストを抑えるためにコンテキストウィンドウを短縮して、動的要約を使ってる。だから、フラット料金プランを提供できるんだ。ここでコンテキストの制限を確認できるよ: https://models.dev/ フル機能を使いたいなら、APIを使ってopencodeみたいなものを使ってみて。1つのPRで簡単に3桁の消費コストがかかることが分かるよ。
こういう投稿をよく見るけど、開発者が雇われる本当の理由、責任については誰も言わないね。コーディングを助けるためのツールは何でも使えるし、StackOverflowからコピー＆ペーストしたり、Githubからボイラープレートプロジェクトを丸ごと持ってくることもできる。AIがコードの責任を取ったり、それによって発生した問題を解決することは絶対にない。責任を取る人の数は、コードベースの大きさやプロジェクトの数に比例して増えるよ。
└
それが今や私たちの仕事の最も重要な部分になりつつあるね。私たちが責任を持って生み出す仕事に対して、エージェンシーがあるのは私たちだから。尊敬するスキルを持った人がそのコードが良いって自分の評判をかけてくれるなら、AI生成のコードでも全然問題ないよ。
└
だから、AIをライターとして使うよりも、エディターやレビュアーとして使う方が楽だな。コードは自分が書くけど、選択肢を探ったり、潜在的な問題を見つけたり、テストを提案してくれるのは助かる。
└
それはまだやってるけど、リアルタイムのコードレビューが基本モードになってるだけだね。未来には私たちが少なくなることは明らかだけど。週末に、非常に新しい手書きのコードを中心にしたSaaSの80%を作ったけど、残りは面倒でやりたくなかった。今のところその比率は目標通りだと思う。モデルが改善され続けるなら（今のアーキテクチャや入力データセットではあまり期待できないけど）、その比率は簡単に上がるだろう。22年前に数ヶ月かけて書いた技術仕様を切り貼りしたら、Opusが3分でテストや例を含むパーサーを一発で作った。パーサーを新しいセッションに切り貼りして、概念文書とプログラミング言語のリファレンスを書くように頼んだら、ちゃんとやってくれた。一番のポイントは、その言語の使い方を生成するように頼んだら、実際には美的感覚が完全にゴミだってことが明らかになった。何年も前から友達に「私たちは炭鉱夫だ」って言ってきたし、君にも同じことを言うよ。それを受け入れて、適応していこう。
└
>開発者が雇われる「実際の」理由、それは責任だよ。人々が新しいものを作って、メンテナンスを他の人に任せることでキャリアを進めるのはよく知られた事実だ。Googleがよく例に挙げられるけど、つまり、私たちの業界は責任や配慮を報いるのが本当に下手だよね。
Opus 4.5は本当に別物だね。最近、めちゃくちゃ難しい問題を投げかけて楽しんでるんだけど、いつも驚かされる。Pythonで書かれたJavaScriptインタープリター？PythonでのWebAssemblyランタイムはどう？BurntSushiの素晴らしいRust最適化文字列検索ルーチンをCに移植して、さらに速くするのは？これらはほとんどカジュアルな実験で、しばしば携帯電話から実行してるんだ！
└
最初に試したのは「JavaScriptでPython 3インタプリタを書いてみて」ってやつだった。テストを作って、インタプリタを書いて、テストを実行して、全部通るまで動いてた。ちゃんと動いたことに本当に驚いたよ。
└
> BurntSushiの超優れたRust最適化文字列検索ルーチンをCに移植して、さらに速くするのはどう？どうだった？ :-)
└
> Pythonで書かれたJavaScriptインタプリタ？これはBellardのMQJSのPythonポートのことを指してるのかな？すごく印象的で役に立つけど、「mqjsに基づいている」という部分を省くのは誤解を招くよね。[1] https://github.com/simonw/micro-javascript?
└
逆に、昨日試してみたけど、あんまり違いが見えなかったな。他のところでも書いたけど、同じように制限されたコンテキストウィンドウ、同じ「ファイルから関係ない10行を読む」って感じ、同じランダムな変更とか。半年前から1年前には、その時の流行りのモデルにpychromecastを指示して「残りの機能をSwiftに変換して」って言い続けたら、ちゃんとやってくれた。コードの質は分からないけど、mDNSやSwiftUIの実装と一緒に動いてたし、ここにgif/videoがあるよ: https://mastodon.nu/@dmitriid/114753811880082271（動画にはchromecastの情報は含まれてないけど）。エージェントは良くなったと思うけど、モデルはほぼ完全に停滞してるんじゃないかな。
└
スライムモールドの経路アルゴリズムを作ったり、全く新しい靴ひもパターンを作るみたいな極端な問題を試してみたけど、視覚的推論を使う問題には苦戦してる。解決方法に関しては意見がほとんど一致してないし。
私は別の懸念があるんだ。SOTA製品は高価で、忙しい時期には簡略化されちゃう。私の個人的な戦略は、競争が前のSOTAに追いついた時に新しいAIツールを取り入れる遅れたフォロワーになること。今ではコストパフォーマンスが良くて同じくらい優れたツールがたくさんあるから、Claude Codeが競争に追いつくのが待ち遠しいよ。特にオープンソースや中国の代替品がね :)
休暇中にGPT 5.xで似たような体験をしたよ、ちょっと異なる分野でね。https://taoofmac.com/space/notes/2025/12/31/1830 Pythonの自動化を置き換えるためにSwiftツールを作ったり、ARM JITエンジンを68kエミュレーターに統合したり、何年もやりたかったシンセプロジェクトのいいスタートを切ったりした。私にとって明らかになったのは、gpt-5-miniでも、ちゃんとした仕様を書いて、コードを仲間のプルリクエストのようにレビューすれば、 decentなGo CLIアプリが作れるってこと。GPT 5.2やCodexのバリエーションは、私にとってはOpusと同じくらい良いけど、媚びたり絵文字を使ったりしないから、CIワークフロー全体を構築するように頼むと、ほぼ一発でやってくれる。だから、少なくとも私にとってはこのモデル世代は大きな力の倍増器だね（でも、私はいつもコーディングの前に計画を立てて、ほとんどの詳細を考えてから始めるタイプだから、方法の問題かもしれない）。
└
Gemini 3 Pro（ハイ）も最近すごく良い感じ。AmpやJunieみたいな、これらの高性能モデルに呼びかけるツールも同様に。2週間の間に、Rubyライブラリの大部分を作ったんだ。Ratatuiのrustクレートにバインディングを付けて、RubyでTUIを作るためのやつ。ドキュメントやサンプルアプリ、ビルドやDevOpsツール、将来のための重要なアーキテクチャの決定やロードマップも作った。この成果は信じられないけど、全部gitとCIの履歴に残ってるよ。https://sr.ht/~kerrick/ratatui_ruby/ 今は以下のことが真実だと思う: - Vibe Codingは、今まで以上に「自動操縦」って感じで、航空の意味での自動操縦ね。ちゃんと見てないとダメだし、責任は自分にある。人間が離陸や着陸（難しい部分）をやらなきゃいけないけど、大部分の作業のリスクを大幅に軽減してくれる。 - 今日の最先端ツールと6ヶ月前のツールの開発者体験の差はすごい。昨年ずっとこれらのツールを理解して使おうと頑張ったけど、数ヶ月間は落ち込んで手動コーディングに戻ってた。みんなは無料のツールじゃなくて、プレミアムツールを試して再評価する必要がある。 - ツールメーカーは、LLMの制限を回避するための面白いハックをたくさん見つけて、実際よりも良く見せることに成功してる。JunieはIDEと統合されてるし、Antigravityはプロジェクトやチャットの優先順位について複数のエージェントがバックグラウンドで情報を維持してる。Antigravityはコンテキストを圧縮して、新しいものを始めるのも気づかれないようにやってくれるし、コンテキストの汚染を避けるためにサブエージェントを呼び出すなど、自動でコンテキストを管理するトリックも使ってる。 - Unixツール（sed、grep、awkなど）やgit CLI（ls-tree、show、--statなど）は、コンテキストを小さく保つことで大きな力を発揮してる。全ファイルを生で取り込むよりも、LLMが少ないコンテキストウィンドウでより多くの作業をこなせるようにしてる。 - プログラマーを雇う人たちは、これらの改善があっても、Vibe Codingで生産品質のウェブアプリを作る能力がまだない。実際、今は10ヶ月前に思っていたよりもリスクが少ないと感じてる。これらは常に操縦が必要な高度なツールで、アーキテクチャやデザイン、開発者体験、テストの質などに良い目を持つことが、私のVibeコーディングしたRuby [0]（これにはかなり気を使った）と、VibeコーディングしたRust [1]（借用が何を意味するかも知らない）との違いだと思う。 [0]: https://git.sr.ht/~kerrick/ratatui_ruby/tree/stable/item/lib [1]: https://git.sr.ht/~kerrick/ratatui_ruby/tree/stable/item/ext...
└
CLIユーティリティのコードを書くのは、他のことに比べてLLMにとっては簡単なんじゃないかなって思う。私の経験では、LLMはバックエンドやターミナル関連のことが得意だよ。ボイラープレートに似たものは特に良いね。ユニットテストのリファクタリングや、既知のコードをCLIでラッピングするのも得意だし、バックエンドのRESTful APIにもそこそこ対応できる。ただ、HTML/CSSのレイアウトや、SPAのJavaScriptフロントエンドコード、特にネットワークの遅延やエラー、ブラウザのUIなどが絡むリアルなUI関連のことには全然ダメだね。要するに、入力と出力が構造化されていて既知のものであればLLMはうまくやるけど、「見た目や感じ」に関わると失敗して、最終的にはメンテナンス不可能なコードになっちゃう。この経験は今のところの話だけど、普段はOpusを使わないから、試してみて自分が予想していない問題に対してどう考えるか見てみるのもいいかもね（例えば、今まで見たことのないブラウザのJS APIのバグとか）。
└
ちょっとした経験談を加えると、今日GPT 5.2なんちゃらが2つのCLIユーティリティの存在を幻覚で作り出して、訂正したら、実際に存在するCLIユーティリティのありそうな機能やオプションを幻覚で作り出したんだ。実際にその機能が存在するか確認するためにソースコードを掘り返さなきゃならなかったよ。結局、存在しなかったから、GPTが勧めたCLIツールは私のユースケースには全く合わなかった。昨日はWebDavクライアントの機能を幻覚で作り出して、GitHubで星が十数個ついている放棄された未完成のプロジェクトを、私がやろうとしていることにぴったりだと言って持ち上げてたけど、全然違った。これらは最近のことだから覚えてるけど、CLIに関する話題だからね。でも、こういう経験は毎日いろんなテーマや分野であるよ。
最近1〜2ヶ月で、HNでLLMについて話すときのネガティブなコメントがすごく減ったのに気づいた。今まで見たLLMでコーディングされたプロジェクトは、全部技術的なおもちゃみたいなものだったけど。Twitterのフィードにゲーム関連のものが出てきて、ゴールドリリースに達する前に静かに消えていくのを見てきた（自分で見つけたものを手動で追いかけてるから、アルゴリズムのせいじゃない）。これがすごく興味深いと思う。LLMは成功する製品を作るために必要な根本的なドライブを変えない。ソフトウェア開発のTikTok化を観察している気がする。なんで人々が完成させないのかは分からない。もしかしたら「本当の作業」が始まると止まっちゃうのかも。あるいは、LLMができることの限界に達しちゃうのかも（今のところ）。次のアイデアに飛びついて、興奮を追い続けるのかもしれない。コンテキストを得るには本当の作業が必要で、それを自動化する方法は見えない。はっきり言うと、コンテキストは人間のニーズ、つまり誰かがあなたの製品を使う理由だ。ゲーム開発の世界では、プレイヤーにスムーズで楽しい体験を提供するためにどれだけの作業が必要かを過小評価することは難しい。誰でも週末にアプリのスイートを作れるかもしれないけど、維持するための忍耐と時間を持っている人は非常に少ないと思う（LLM以前のソフトウェア開発と同じだよ！つまり、Linuxやオープンソースソフトウェアなど）。 [1] そう、選択バイアス。AI開発者が自分のLLMをマーケティングしているのはたくさんいる。確実に言うにはまだ早すぎる。私が言っていることは、1ポンドの塩粒で受け取ってね。
└
LLMで収益化可能な製品を作ることに集中している人たちは、自分たちが何をしているかを共有する必要を感じていないのかもしれない。彼らは静かに製品を作ってマーケティングしているのに忙しいから。これらのツールをどう使っているかを共有するのは、かなりの労力がかかるからね！
└
本番環境で何かをデプロイして維持するのは、すごく大変な作業だよね。ほとんどの人が技術デモを作った後に諦めるのも不思議じゃない、特にこれらのプロジェクトを維持するためにたくさんの時間を使いたくない場合は。去年、Karpathyが似たような経験を投稿してたけど、彼はすぐにいくつかのツールを作ったものの、デプロイするのに思ったよりもずっと多くの労力がかかることに気づいたんだ。自分のために何かを作ることができるのはやっぱり楽しいし、自分のニーズを満たすために作ることの利点は、「本番準備完了」にするための全ての努力をしなくていいことだよね。特定の問題を解決するために、エッジケースを気にせずに自分専用のものを作れるんだから。つまり、あなたの言う通りだよ :).
└
うん、私は趣味でゲーム作りをたくさんやってるけど、80/20ルールは確かに当てはまるね。あなたのゲームは、マス向けの洗練された製品を作るのにかかる時間の20%で「完成」するよ。趣味でやってるなら、そこで止めるのも全然オッケー。私はこれを使ってアイデアを試すのが好きなんだ。技術からゲームプレイまで、いろんなデザインコンセプトを試すために、そんな状態のRPGが何十個もあるよ。
└
たまに、あの手の投稿はケント・ブロックマンみたいだなって思う。「私は、我々の新しい昆虫の支配者を歓迎します。」支配層がソフトウェア開発の自動化に対して熱心だから、ソフトウェアエンジニアがプロとしてどれだけ受け入れているかを公に示すのは理解できるかも。でも、私の職業人生の中で見たことのある奇妙なことはもっとあるよ：EJB 2.1やxdocletを完璧なソフトウェアの書き方として熱心に擁護していた人たちのことを今でも覚えてる。
└
> 最近1〜2ヶ月の間に、HNでLLMについて話すときのネガティブなコメントが大幅に減ったのに気づいた。リアルな人たちは、OpenAIが新しいモデルを出すたびに、同じような「OMG新モデル1000倍良くなった」っていう投稿やコメントを議論するのにうんざりしてるからね（記事の著者はMicroslopの社員）。
└
AIを使う人たちって、AIができない最後の20%の作業をする時に一番苦労する人たちだと思う。全てのパーツを一つにまとめるために考える必要があるとき、思考能力をAIに任せてしまった人は、その作業をするための準備ができていないんだ。最初からその能力がなかったか、AIが彼らの思考の波を滑らかにしてしまったから。これは私の経験から言ってるよ。
スクリーンショットの引用符の使い方がひどいけど、Dario Amodeiは実際にはその言葉や同じ意味の言葉を言っていないよ。
これを何度も言ってるけど、LLMはおもちゃや実験的なプロジェクトを作るのには最高だよ。恥じてるわけじゃないけど、個人的には自分の感情が正しいかどうか知りたいんだ。それとも、単にLLMの使い方がわからないだけかな？ コーダーの達人たちが、Linuxに競争できるオペレーティングシステムをゼロから作って、基本的にLinuxじゃないコードを生成できるのかな？ それも20ドルのプランで… 無料で自己ホストできるソリューションが一番いいね。