dohyun682 2026-02-19 | 親コメント | トピック: AIがコードを吐き出す時代、水が引けば誰が裸で泳いでいたかが明らかになる (evan-moon.github.io) 私も同意します 最近のハーネスやループ方式を見ると、人は仕様だけを渡して、レビューやQAまでAI同士で勝手に進める方向に向かっているように思います shakespeares 2026-02-19 | 親コメント | トピック: Claude Code創始者によるカスタマイズのヒント12選 (x.com/bcherny) 未来だ!! princox 2026-02-19 | 親コメント | トピック: ACE-Step-1.5 - 有料サービスを凌駕するローカル音楽生成モデル (github.com/ace-step) 今日一度試してみないとですね bboydart91 2026-02-19 | 親コメント | トピック: AIがコードを吐き出す時代、水が引けば誰が裸で泳いでいたかが明らかになる (evan-moon.github.io) ご意見をいろいろといただき、ありがとうございます! 私が本文で「責任」に言及したのは、人間がAIよりあらゆる面でミスが少ないからではなく、現代社会の法的・倫理的システムが「責任を負う主体」として人間(または法人)しか想定していないためです。 gcback さんのおっしゃるとおり、統計的な安全性が証明されれば、将来的には責任の枠組み自体が変わる可能性もあるでしょう。しかし、少なくとも近い将来においては、「AIが起こした事故について、誰が刑務所に行くのか、あるいは賠償するのか」という社会的ジレンマが、技術のスピードに追いつくのは難しいと見ています..! gcback 2026-02-19 | 親コメント | トピック: AIがコードを吐き出す時代、水が引けば誰が裸で泳いでいたかが明らかになる (evan-moon.github.io) 同意します。 結局のところ、検収や確認の水準もAIが人間より高くならざるを得ないので、現時点で人間が責任を負うコストより低くならざるを得ないように思います。 人間であれAIであれ、統計的にミスが少ないほうが勝つゲームです。 dbs0829 2026-02-19 | 親コメント | トピック: Steph AngoのObsidian活用法 (stephango.com) 私も以前、Evernoteを使っていたときはああいうふうにかなり使い込んでいましたが、さまざまな用途で使っていると、ある程度構造化されていたほうが良い場合もあると感じます。ただ、内部リンクは私もかなり多用していて、相互に融合が起きそうなデータは同じ場所に集めて入れています。 mhj5730 2026-02-19 | 親コメント | トピック: AIがコードを吐き出す時代、水が引けば誰が裸で泳いでいたかが明らかになる (evan-moon.github.io) 実際の業務でAIを活用する立場として、AI開発 -> AI成果物の監督という言葉には深く共感します。 そしてAIは本質的な複雑性の解消にも大きく役立っています。 [要件分析時の矛盾チェック、重複チェック、本質的な価値への問い] github88 2026-02-19 | 親コメント | トピック: AIがコードを吐き出す時代、水が引けば誰が裸で泳いでいたかが明らかになる (evan-moon.github.io) 監督の民主化?w 資質があるから監督をするのであって、資質がないのに監督をするわけではありません。 pluto 2026-02-19 | 親コメント | トピック: Asahi Linux 進捗レポート: Linux 6.19 (asahilinux.org) 本当に本当にありがとうございます xguru 2026-02-19 | 親コメント | トピック: ACE-Step-1.5 - 有料サービスを凌駕するローカル音楽生成モデル (github.com/ace-step) サンプルの中にK-POPもありますが、このレベルのものをローカルモデルで生成できるならかなり良いですね。 個人が作るゲームや映像の背景音楽くらいなら、もう本当に簡単になりそうです vigorous5537 2026-02-19 | 親コメント | トピック: DroidClaw — 古いAndroidスマートフォンをAIエージェントとして活用するオープンソースプロジェクト (droidclaw.ai) いいアイデアですね mhj5730 2026-02-19 | 親コメント | トピック: microgpt - 200行の純粋なPythonで実装したGPTの学習と推論 (karpathy.github.io) 良い記事をありがとうございます。 cocofather 2026-02-19 | 親コメント | トピック: AIがコードを吐き出す時代、水が引けば誰が裸で泳いでいたかが明らかになる (evan-moon.github.io) AI盲信者がもっと増えるべきです。 mammal 2026-02-19 | 親コメント | トピック: AIの文章が陳腐で退屈になる理由:意味的アブレーション (theregister.com) AIが書いた文章のように見えないよう、誤字をそのまま残したり小文字で書いたりするのは、意図的にエントロピーを増やす行為だと見なせそうですね armila 2026-02-19 | 親コメント | トピック: AIがコードを吐き出す時代、水が引けば誰が裸で泳いでいたかが明らかになる (evan-moon.github.io) これも過渡期なんだと思います。 有名なサッカー監督でも、選手出身ではない場合が多いですからね。 secwind 2026-02-19 | 親コメント | トピック: GitHub、PRを無効化またはアクセス制限できる設定を追加 (github.blog) レビュアーが読むべき内容に「ウォークスルー」が追加されました。 dongyagn1 2026-02-19 | 親コメント | トピック: Show HNは死んでいない、だが圧倒されている (arthurcnops.blog) 正直、少しもどかしいです。自分が1日で作ったものが驚くべきもので興味深いというのは認めます。しかし、その1日で作ったものを自分で実際に触ってみて、フィードバックをしたことがあるのか、胸に手を当てて考えてみるべきです。 xguru 2026-02-19 | 親コメント | トピック: Gentoo、Codebergに公式リポジトリを開設 (gentoo.org) Zig、メインリポジトリをGitHubからCodebergへ移行 GitHubからCodebergへ: 私の経験 jeeeyul 2026-02-19 | 親コメント | トピック: GitHub、PRを無効化またはアクセス制限できる設定を追加 (github.blog) エージェントが常にウォークスルーも一緒に提出するようにするのも、レビューには少し役立つのでしょうか。 jeeeyul 2026-02-19 | 親コメント | トピック: AIはオープンソースを破壊している、まだまともに動いてもいないのに (jeffgeerling.com) オープンソースの本質の一つは、人に堂々と見せられるコードにあるのではないかと思います。論理的な優雅さと簡潔さ、そして誇りが不可欠です。コードではありますが詩でもあり、産業用コードとは異なる魅力があります。 エージェントも、プランニング段階と実装計画段階まではかなり良いのですが、その後は検証関数を通過するまで戦略を変えるだけです。これが深くなるほど、インプリメンテーショントラップに似たスロップが生まれます。問題は、とにかく動きさえすればOKという人間ユーザーも多いことです。 結局のところ、コミュニティの哲学的な同調を土台として、人間による計画段階のレビューがより適切に行われる必要があるのでしょうが、これには圧倒的な直観に加えて努力も必要です。実際、あまりにももっともらしいので、エージェントの計画をデバッグするのは簡単なことではありません。 モデレーターたちは本当に大変だろうと思います。 コメントをさらに読み込む
私も同意します
最近のハーネスやループ方式を見ると、人は仕様だけを渡して、レビューやQAまでAI同士で勝手に進める方向に向かっているように思います
未来だ!!
今日一度試してみないとですね
ご意見をいろいろといただき、ありがとうございます!
私が本文で「責任」に言及したのは、人間がAIよりあらゆる面でミスが少ないからではなく、現代社会の法的・倫理的システムが「責任を負う主体」として人間(または法人)しか想定していないためです。
gcback さんのおっしゃるとおり、統計的な安全性が証明されれば、将来的には責任の枠組み自体が変わる可能性もあるでしょう。しかし、少なくとも近い将来においては、「AIが起こした事故について、誰が刑務所に行くのか、あるいは賠償するのか」という社会的ジレンマが、技術のスピードに追いつくのは難しいと見ています..!
同意します。
結局のところ、検収や確認の水準もAIが人間より高くならざるを得ないので、現時点で人間が責任を負うコストより低くならざるを得ないように思います。
人間であれAIであれ、統計的にミスが少ないほうが勝つゲームです。
私も以前、Evernoteを使っていたときはああいうふうにかなり使い込んでいましたが、さまざまな用途で使っていると、ある程度構造化されていたほうが良い場合もあると感じます。ただ、内部リンクは私もかなり多用していて、相互に融合が起きそうなデータは同じ場所に集めて入れています。
実際の業務でAIを活用する立場として、AI開発 -> AI成果物の監督という言葉には深く共感します。
そしてAIは本質的な複雑性の解消にも大きく役立っています。 [要件分析時の矛盾チェック、重複チェック、本質的な価値への問い]
監督の民主化?w 資質があるから監督をするのであって、資質がないのに監督をするわけではありません。
本当に本当にありがとうございます
サンプルの中にK-POPもありますが、このレベルのものをローカルモデルで生成できるならかなり良いですね。
個人が作るゲームや映像の背景音楽くらいなら、もう本当に簡単になりそうです
いいアイデアですね
良い記事をありがとうございます。
AI盲信者がもっと増えるべきです。
AIが書いた文章のように見えないよう、誤字をそのまま残したり小文字で書いたりするのは、意図的にエントロピーを増やす行為だと見なせそうですね
これも過渡期なんだと思います。
有名なサッカー監督でも、選手出身ではない場合が多いですからね。
正直、少しもどかしいです。自分が1日で作ったものが驚くべきもので興味深いというのは認めます。しかし、その1日で作ったものを自分で実際に触ってみて、フィードバックをしたことがあるのか、胸に手を当てて考えてみるべきです。
Zig、メインリポジトリをGitHubからCodebergへ移行
GitHubからCodebergへ: 私の経験
エージェントが常にウォークスルーも一緒に提出するようにするのも、レビューには少し役立つのでしょうか。
オープンソースの本質の一つは、人に堂々と見せられるコードにあるのではないかと思います。論理的な優雅さと簡潔さ、そして誇りが不可欠です。コードではありますが詩でもあり、産業用コードとは異なる魅力があります。
エージェントも、プランニング段階と実装計画段階まではかなり良いのですが、その後は検証関数を通過するまで戦略を変えるだけです。これが深くなるほど、インプリメンテーショントラップに似たスロップが生まれます。問題は、とにかく動きさえすればOKという人間ユーザーも多いことです。
結局のところ、コミュニティの哲学的な同調を土台として、人間による計画段階のレビューがより適切に行われる必要があるのでしょうが、これには圧倒的な直観に加えて努力も必要です。実際、あまりにももっともらしいので、エージェントの計画をデバッグするのは簡単なことではありません。
モデレーターたちは本当に大変だろうと思います。