プロジェクトは頭の中で始まったし、たくさんの欠陥やニュアンスがあって、LLMがそれを尊重するのに苦労してると思う。プロジェクト、それともあなたの頭の中？これが多くのLLMコーダーが直面することだと思う。彼らは言葉にするのが難しい、または時間と労力がかかる多くの内在的な知識を持っている。「説明できないけど、このコードはおかしい」みたいな感じ。

デザインドキュメントを書かせて、それをレビューするのがいい結果を得られると思うよ。レビューは君とボットの両方ができるしね。

LLMはストーリーには興味がなく、コードの現在の状態だけを気にしている。バックストーリーについて教えなきゃいけない。どこかに書いて入力しない限り、LLMはそれを知らないんだ。

それは苦労している それは苦労していない、あなたが苦労しているんだ。これはあなたが使っているツールで、あなたが言った通りに動いているだけ。ツールを使うには時間がかかるけど、それは全然問題ない。ツールを責めるのは逆効果だよ。コードがよくドキュメント化されていて、高レベルでインラインコメントもあれば、指示が明確なら、きちんと理解するはず。もし間違いを犯したら、どこでコミュニケーションが崩れたのかを見つけて、もっと明確かつ一貫して伝える方法を考えるのはあなたの責任だよ。

成功するLLM支援のコーディングの大事なポイントは、コードをただ吐き出すのではなく、しっかりとした土台を作ることだよ。ドキュメント、ドキュメント、ドキュメント：アーキテクチャやベストプラクティス、好み（コードに関することや、LLMとの関わり方、期待する動作について）をしっかり記録しておくことが重要。時間はかかるけど、これが半分成功するための唯一の方法だからね。LLMの開発者にとっての最大の力は、コードを書くことよりも、理解を助けたり、機能間の関連をつなげたりすることなんだ。プロジェクトに導入して「Xをやって、Yをやって」と言うだけでは、必要な土台がないとすぐに混乱してしまうよ。確かに、時々タスクを完了することはあるけど、複雑さが増して、あなたもLLMもそこから抜け出すのが難しくなる。AIに否定的な人たちは、LLMに優しいプロジェクトを作るために必要な膨大な作業を面倒に思って、失敗してツールのせいにしちゃうんだ。土台を作った後も、特に大事なプロジェクト（アイデアを素早く検証するためのプロトタイプじゃないもの）では、逐一コードを追いかけて、同じミスを繰り返さないように土台やドキュメントを更新し続けることが大切だよ。そして、土台作りにはメインの依存関係のソースコードも含める必要がある。私は主要な依存関係のためにgitサブツリーを使った_vendorディレクトリを持ってる。LLMは依存関係のコードやテストをチェックして、何が間違っているのかをもっと早く理解できるんだ。最後に、LLMは特定のパターン、例えばTDDと相性がいいから、「Xを実装して」ではなく「Xを実装したいけど、その前にテストと進捗を追跡する方法を設定しよう」と言った方がいいよ。仮想マシン用のインスペクターを作ったり、e2eテストや他のテストを設定したり、単にログをファイルに逐一出力したりする方法はいろいろある。ケースバイケースでアプローチは変わるけど、LLMにコードを作成してもらうための実際の助けを得るには、良いコンテキストと良いセットアップ（テスト、ビジネス要件の計画を書かせたり、実装の計画を立てたり）を持って、進むにつれてこれらの側面を追いかけて改善していくことが重要だよ。

モデルのトレーニングみたいだね。AIを使ったプログラミングは、テストとトレーニングの分割をしっかり意識してやってきたよ。エージェントが見えないホールドアウトを用意して、それに対して測定することが大事だね。（そして、エージェントがズルしないように） https://softwaredoug.com/blog/2026/01/17/ai-coding-needs-tes...

Claudeが全てのコミット履歴を読んだら、プロジェクトの方向性や一般的な進め方に合った選択ができるようになるんじゃない？

新しいgitが必要だね。（今のgitを基に作れるかも） > フォークから価値のあるものを簡単にマージできることは本当に素晴らしいと思う。無駄な努力を減らせるしね。でも、それは存在するものを知っていて、どこにあるかを把握している場合に限る。

GitHubリポジトリに .claude が含まれているソフトウェアは信用できない。

本当の問題は、新しい波のバイブコードソフトウェアがどれだけペットプロジェクトからコミュニティ維持プロジェクトに成長できるかだね。バイブコーディングは、同じことのために10個の異なるバイブコードパッケージができたり、週末に作って放置されたりすることで、オープンソースソフトウェアの断片化や放棄を悪化させるかもしれない気がする。

私はソフトウェア開発にAIツールを使うことに大賛成なんだけど、LinuxカーネルやPostgreSQL、gcc、git、Chromiumの代わりになるものが出てくるのを見ない限り、この前提には同意できないな。記事読んだ？ LLMが主要なオープンソースソフトウェアのコンポーネントを置き換えるって言ってるわけじゃないよ。OSSの提供、維持、キュレーションに対する「報酬」が、コミュニティがないと消えちゃうって言ってるんだ。オープンソースコードを取り込んで、良いか悪いかのソリューションを出すLLMだけが存在する世界ではね。curlがプレッシャーに耐えられなくなったのを見たことがあるよ。セキュリティレポートに貢献しようとしたコミュニティの努力が、結局は崩れちゃったから。この話は、全体のエコシステムにその理論を広げることに関するものだよ。GHのイシューもPRもない、インタラクションもなし。HNでの称賛も、GitHubでのスターも、カンファレンスで素晴らしい講演をした後に「お疲れ様」と言うこともない。AIツールでLinuxカーネルが開発されるのを見ないと、記事の著者が言ってることに納得できないって、どこでそう思ったの？

LLMを使って何かを作ると、必ず追加機能が必要になったり、何らかのメンテナンスが必要になるからね。今は月に200ドル以上のLLMサブスクリプションにお金を使って、結局は中途半端な実装で、自分の重みに耐えられなくなるものを手に入れるより、実際に動くソリューションを買った方がいいよね。

アプリが標準化されて意見が明確であることの巨大な価値を見逃してると思うよ。標準化されているってことは、ドキュメントに加えて、インターネット全体が助けてくれるってこと。意見が明確ってことは、新しい分野のアプリを使うユーザーとして、始めるためにどう動くべきかを何百万回も決める必要がないってこと。確かに、特定のワークフローをサポートするものを作ることで価値を得られる専門知識を持っている人には、よりパーソナライズされたアプリがあるだろうけど、ほとんどの人やほとんどのユースケースではそんなことは起こらないよ。週末にバイブコーディングしたもののために、何十年も積み重ねてきた経験を手放すつもりはないね。

"なぜ小屋に行くのか" いい質問だけど、いい答えがあるよ：デバッグ済みでテストされたコード。これには、デバッグとテストの全範囲が含まれる。単体テストだけじゃなく、統合テストも、実際に役立っているユーザーがいるのか？ どれだけのユーザーがいるの？ どれだけのユースケースがあるの？ 実世界の影響をどれだけ受けてきたの？ AIが他の問題をあまり重要でなくする一方で、残る問題はより重要になる。LLMに、5年間にわたって何百万もの人に使われてきたコードベースを作らせるのは完全に不可能だよ。そういうものにはまだ価値がある。近い将来、AIがパワーを持って、みんなが自分の望む通りのカスタムコードを手に入れる世界が来るって考えるのは、この問題を見落としている。たとえ（弱い）超人AIでも、実世界がコードベースに何をするかを予測するのは難しい。もしAIにカスタムの写真編集ソフトを作らせても、何百万時間も使われた他の誰かのAI写真編集ソフトには、私の新しいものよりも優位性があるだろう。もちろん、すべてのコードがこういうわけじゃないけど、影響の少ない一回限りのコードもたくさんある。セキュリティ問題がないのは、私しか実行しないからだし、バグも問題にならないのは、特定のデータセットでしか実行されないから（例えば、ファイル名のスペースで技術的に何か間違ったことをするbashスクリプトがたくさんあるけど、実際には問題なく動く）。LLMはそういうのには最適で、間違いなく良くなるだろう。ただ、トップからボトムまでテストされたソフトウェアには、問題解決の適合性を確認するための価値がまだ大きい。基本的な単体テストだけじゃなくて、何百万、何十億、何兆時間も実世界で生き残るためのもの。実際、こういうソフトウェアの価値は、突然小さなものが溢れる世界ではさらに上がるかもしれない。カスタムのハンマーは手に入るけど、広範な実世界での使用に耐えたテスト済みのカスタムハンマーは、定義上手に入らない。

今のソフトウェアのパラダイムは「できるだけ多くの用途のために、できるだけ多くの機能を持つツール小屋/ガレージ/納屋/倉庫を作る」だけど、LLMが数分でカスタム(!)のハンマーやノコギリを作れるなら、なぜ小屋に行くの？ 1) あなたの具体的な例えは、重要な何かを欠いてるよ：私は、使うたびに道具が違う動きをするのは嫌だし、LLMを使うのも手間がかかる。ハンマーはちょっと単純すぎる例だけど、それでも続けると、ハンマーが必要なときに、私の「LLM」がプラスチックのハンマーを生成して、正しいものを得るまで30分もかかるのは嫌だ。小屋に行くのに30分もかからないからね。もっといい例はUIだね。たとえそれが完璧でも、ツールを使うたびにボタンやメニューが違うのは嫌じゃない？ 毎回「小屋に行く」代わりに新しいものを生成するから。 2) それから、LLMが実際に作れるのか、それともただ吐き出すだけなのかって問題がある。ハンマーは非常によく理解された道具で、何世代にもわたって洗練されてきたから、LLMはかなり良い仕事ができると思う。たくさんの例があるけど、それはLLMが参照しているデザインが、LLMの出力よりも優れている可能性が高いことも意味する。そして、それとは違う、もっとユニークなものについては、LLMが実際にできるのか、合理的な労力でできるのか？ 現代の現象として、物事を「簡単」にすることが、実際には悪い結果を招くことがあると思う。以前の状態よりも劣化した状態になることもある。必要がなくなると、個人の規律の問題になってしまうから。必要性を取り除くと、多くの人が規律だけで最善のことをするのが本当に難しくなる。LLMは、そういう劣化した結果を促進するかもしれない。みんなが「カスタム」LLM生成ツールを使っているけど、実際にはどれもひどくて、手動でツールを設計する努力をした方が良かったってことになるかも。

これは成功するモデルだとは思わない。ソフトウェアが本番環境で壊れたとき、効果的にデバッグできる必要がある。外部ライブラリが基本的な仕事をしていることを知ることは、検索範囲を減らし、パッチの影響範囲を減らすのに本当に役立つ。これはAI特有のことではないよ。一般的に、自社のコアビジネスではないソフトウェアの社内実装には、その実装を書くコストに限らないコストがかかる。

LLMが数分でカスタム(!)ハンマーやノコギリを作れるなら、なんで小屋に行くの？ソフトウェア開発者は、クライアントよりも問題解決の実装方法を理解していることが多いから。解決策を実装するための詳細が足りないと、クライアントに詳細を聞くことになる。開発者がLLMを使って解決策を実装することを決めた場合、最終的な製品を評価する能力があるんだ。問題は、ソフトウェア開発者にはコストがかかること。LLMを使う開発者は開発コストを削減できるかもしれないけど、そのコスト削減が個別のアプリケーションを正当化するには不十分だと思う。コストを正当化できるケースは、カスタムソフトウェアが一般的に使われている分野に限られるだろうね。確かに、LLMを使って自分用のカスタムソフトウェアを開発する人はいるだろうけど、そういう人は問題を明確に特定できる人で、作成したソフトウェアのバグや癖に耐える忍耐力があり、プロセスを楽しむことができる人だと思う。中小企業がLLMを使ってカスタムソフトウェアを作る開発者を雇うこともあるかもしれないけど、個別のソフトウェアが広く普及するとは思えない。これは、問題を特定する能力だけを考慮した場合の話で、相互運用性など他の要素もあるからね。結局、私たちはネットワーク化された世界に生きていて、相互運用性はすべてがネットワーク化される前から重要だったんだ。

大多数のユーザーは、アプリやデバイスのデフォルト設定を全く変更しないんだよね。普段使ってるソフトウェアでも、ちょっとした調整で体験がかなり良くなるのに。こういう人たちが、全く新しいUXを学びたいって思う世界なんて想像できないよ。

LLMを使って小さなプロジェクトをサクッと作る実験をすればするほど、これが本当にそうだと確信するようになった。よく言われるけど、顧客の90%はソフトウェアの機能の10%しか使わないんだよね。でも、その10%はそれぞれ違う。今は、その10%だけをサクッと作れる小さなアプリが簡単にできるようになって、問題が解決されつつある。必要なものだけを手に入れられるから、DoEverythingBloatWare（何でもできる肥大化ソフト）を我慢する必要もないし、更新で壊れる心配もない。デザイナーがポートフォリオを膨らませるためにUIを勝手に変えることもないし、開発者がリファクタリングして大事な機能を削除することもない。今、使ってる大きくて重い、クラッシュするようなソフトウェアを見直して、代替品を探してるところだよ。

問題を解決することが分かっている、戦闘実績のある安全なライブラリを使わずに、メンテナンスが必要なカスタムコードでプロジェクトを重くする理由って何なの？

StanLLMが生成したハンマー: 「親愛なるお客様、私たちの自動システムがあなたのStanLLMアカウントで、当社の利用規約に違反していると思われる活動を検出しました。予防措置として、あなたのアカウントは一時停止されました。この一時停止が誤りだと思われる場合は、サポートにご連絡ください。連絡先: /dev/null^H^H^H^H^H^H^H^H^Hsupport@...」

メンテナは今や自分たちで全部の作業をこなせるようになった。AIを使って時間を節約すれば、もっと多くの仕事ができるから、他のエンジニアにコードベースを学ばせる価値がなくなってきてるかも。大規模なソフトウェアシステムは、今や1人か2人でメンテナンスできるようになったよ。追記: みんなに返信して制限かけられるのは嫌だから、別のコメントのリンクを貼るね: https://news.ycombinator.com/item?id=46765785

僕みたいなおじさんにとっては、実際のコード制作よりもコードレビューを手伝ってくれるLLMの方がいいな。これってバカかな？

タイトルを見たとき、この記事のポイントだと思ってた。人気のプロジェクトは、ほぼ間違いなくAI生成のPRに溺れているみたい。OpencodeCliは現在1200件のオープンPRがある[1]。放置気味のAiderは200件[2]。私の知る限り、両プロジェクトともほとんど一人のメンテナーが担当している。[1] https://github.com/anomalyco/opencode/pulls [2] https://github.com/Aider-AI/aider/pulls

ドキュメント（あるいは意図的に質の低いドキュメント）をコンサルティングや「プロ」バージョンのマーケティングファネルとして使うモデルがある、ウェブ開発に近いニッチがある。これらのプロジェクトは、バイブコーディングがビジネスモデルを壊すことについて声を上げている。これらのプロジェクトが本当に意味のある価値を生み出しているかどうかは、また別の問題だね。

Terraform、Ansible、他にも無数のものがある。コミュニティがないと、エンタープライズ版も認知度もないんだよね。

OSSがなかったら、LLMは作られなかっただろうね。もしSlopHub CopilotがMicrosoftのコードだけで訓練されていたら、誰が欲しがるだろう？（修辞的な質問）

何か変わったの？LLMが生成したものが著作権で保護されるようになったの？著作権は人が作った作品にしか適用されないと思ってたんだけど。

つまり、フルリードとスクラブはもう少し多くのビットに触れ、必然的にエラーレートにぶつかるってことだよね。これって全然意味あるの？ZFSのスクラブは、全ドライブを読むんじゃなくて、持ってるデータだけを読むし、可能なら修復もする。データが多ければ多いほど、使うツールに関わらず検証しなきゃいけない量も増える。BERもひどい指標で、実際のドライブの挙動を反映してないよ。

検証可能な「元のソースを見たことがない」...えっと。ここでの大きな問題を指摘すると、誰が元のソースを見たことがないと検証可能であるべきなの？あなた？それともLLM？

自分の「validate」プロジェクトの著作権を持っている限り、デュアルライセンスができるよ。だから、(A)GPLの下でリリースして、クローズドソースの商業プロジェクトでも使える。ただ、貢献者の貢献をクローズドソースで使い続けるためには、貢献者ライセンス契約（CLA）にサインしてもらう必要があると思う。

どんどんPR作っていけばいいんじゃない？Linusたちがどれだけ喜ぶか想像できるよ、こんなゴミみたいな機能でね ;-)

後者の解決策は、構造や組織に関して高い基準を維持することだと思う。KISSの考え方が、ソフトウェアの他の要件よりも優先されるべきだと思ってる。ここで言う「非要件」とは、主観的なもののことね。実際に必要ない複雑さを作らないでほしいし、他の部分のコードを理解しやすくするために大きな貢献をしないものも避けるべき。時には、何十個もの一回限りのスクリプトを持っている方が、超柔軟な一つのツールを作るよりも簡単だったりするからね。

大体私も同じ意見だな。UXや使いやすさに関して、かなり雑で、磨きが足りないし、完成度も低いと思う。