princox 10 일 전 | 親コメント | トピック: OpenMythos: Claude Mythosをリバースエンジニアリングしたオープンソース実装が登場 (github.com/kyegomez) ああ、そうですね。リポジトリ一覧を見ると、Openで始まるプロジェクトがいくつか他にもありますね.. rtyu1120 10 일 전 | 親コメント | トピック: OpenMythos: Claude Mythosをリバースエンジニアリングしたオープンソース実装が登場 (github.com/kyegomez) まだ公開すらされていないのに、どうやってリバースエンジニアリングするっていうんだ……?? pmc7777 10 일 전 | 親コメント | トピック: OpenMythos: Claude Mythosをリバースエンジニアリングしたオープンソース実装が登場 (github.com/kyegomez) この人、話題になるものがあるたびに毎回 open* という名前のパターンで量産しているので、あまり印象は良くない気がしますね…。 slowandsnow 10 일 전 | 親コメント | トピック: Vercelがセキュリティ侵害を確認、ハッカーは窃取データを販売中だと主張 (bleepingcomputer.com) 以前Claudeを使うと日本語がよく出てきたんですよね。昨日もそうでした kuthia 10 일 전 | 親コメント | トピック: AIコーディング時代、成長が止まる開発者の脳で起きていること (evan-moon.github.io) ディストピアにたどり着いた気分ですね cshj55 10 일 전 | 親コメント | トピック: すべての公開 Notion ページで、すべての編集者のメールアドレスが露出している (twitter.com/weezerOSINT) Notion AI以降、もう……何のアプリなのかも分からなくなってしまったけど、 こんなこともあったんだな csakgw 10 일 전 | 親コメント | トピック: AIコーディング時代、成長が止まる開発者の脳で起きていること (evan-moon.github.io) 短い考えですが、最近私はこんなことを考えるようになりました。昔、アセンブリ言語の専門家たちがC言語の開発者を見て「メモリの大切さが分かっていない」「ハードウェアを分かっていない」などと言っていたそうですが、今見ても同じ文脈で似たような指摘なのではないかと思います。結局、私たちはソフトウェア開発の観点から、従来のプログラミング言語よりもう少し抽象化された言語（AI）で開発するようになるだけなのではないかと思います。そうであれば、その前に使っていた言語については当然ながら専門性が落ちることになります。ただ、少し前まで、今よりもさらにlow-levelな言語を扱って開発する人たちを「怪物」と呼んでいたように、これからはバイブで開発をしつつも、依然として従来の言語の原理を理解している人たちは、一味違う人として見なされるのではないかと思います。 wedding 10 일 전 | 親コメント | トピック: AIコーディング時代、成長が止まる開発者の脳で起きていること (evan-moon.github.io) ここにもAIが付けたようなコメントが多く見えるのは、気のせいでしょうか shw00 10 일 전 | 親コメント | トピック: 「AIに失礼なほど性能が上がる？」最新研究が警告するPMのコミュニケーション危機 (maily.so) 2と同じ理由で、ほとんどのLLMを使う際には常に悪魔の代弁者の役割も追加で果たすよう指示を付けていますが、それなりに有用な気がします。 shw00 10 일 전 | 親コメント | トピック: Darkbloom – 遊休Macを活用した個人向けAI推論ネットワーク (darkbloom.dev) コンセプトとしては興味深いですが、実際にうまく回るかは疑問ですね。HNの意見にもあったように、両面市場（two-sided market）は両方向で初期顧客の獲得に成功しなければならないので、そこが大きな問題です unsure4000 10 일 전 | 親コメント | トピック: ArtifactNet: コーデック物理学でAI生成音楽を検出する軽量フォレンジックフレームワーク (arxiv.org) ご自身の論文のように見えるのですが、合っていますか？ click 10 일 전 | 親コメント | トピック: Vercelがセキュリティ侵害を確認、ハッカーは窃取データを販売中だと主張 (bleepingcomputer.com) ここでもヒンディー語の文字が見えますね。最近は OpenAI、Claude、Google を問わず、日本語出力にヒンディー語が混ざって出てくるケースがかなり頻繁に発生していますが、日本語データセットのラベリングをインドの人たちが担当したのでしょうか? 中国モデルは日本語応答に中国語が混ざって出てくるので好きではなかったのですが、最近はフロンティアモデルがヒンディー語をしょっちゅう混ぜてくるので、むしろ中国モデルに対する抵抗感が下がりました spilist2 10 일 전 | 親コメント | トピック: Claude Code と Codex の設定変更でトークンを節約する方法 (stdy.blog) おお、共有ありがとうございます！ dzzwe 10 일 전 | 親コメント | トピック: Claude Code と Codex の設定変更でトークンを節約する方法 (stdy.blog) 良いリファレンスになる記事ですね。本文が「入ってくるトークン」のバルブを閉めるアプローチだとしたら、 私は「登録されているもの自体」が増えすぎて問題になるケースをよく経験したので、claude-slim というツールを作ってみました。 60個あるスキルのうち半分は一度も使っていないとか、プラグインのせいで CLAUDE.md が肥大化するとか、そういった状況をスキャン・分類・整理してくれる CLI です。トークンのカウントは js-tiktoken ベースで、削除するのではなく skills.disabled/ に移動するので、いつでも restore できます。 https://github.com/iops-leo/claude-slim 本文の設定と方向性がちょうど補完し合うので、併用すると良さそうです cosine20 10 일 전 | 親コメント | トピック: 日本の鉄道がこれほど優れている理由 (worksinprogress.co) 緻密に噛み合ったダイヤのおかげで乗り換えが快適 → 希望編 ホームドアがなく、通勤時間帯に飛び込んで自殺する人が時々おり、停電や故障などの理由で遅延も多い → 絶望編 日本に住んで1年になりますが、日本の鉄道が良いと感じる瞬間が53%くらいで、47%くらいはただただイライラが募ります。特に日比谷線はエアコンのカビ臭が一年中していて、マスクなしで乗ると肺炎になりそうです。 kuthia 10 일 전 | 親コメント | トピック: Anthropic、Claude Designを公開 (anthropic.com) 使ってみると、ナプキンのスケッチ認識率が驚くほど高いですね。もうチャットすら必要なくなりました。 overthinker1127 10 일 전 | 親コメント | トピック: ここ数か月、手でコードを書いています (miguelconner.substack.com) 私はむしろAIエージェントを使ってから、nvimに戻りました。 ソースを見るなら、nvimで見るほうがずっと楽なので.. koreacglee 10 일 전 | 親コメント | トピック: AIコーディング時代、成長が止まる開発者の脳で起きていること (evan-moon.github.io) 同感です。航空宇宙、医療、精密制御分野などにおける高度化されたドメインの中核データは、徹底して閉じた内部ネットワークにあり、アクセスするには中核的な内部関係者であるか、外部であればかなりの費用とNDAへの署名を経てようやく公開されます。AIが学習するデータの大半はインターネット上に公開されたものであり、Python、JavaScriptベースのWeb/アプリサービスであれば、ある程度のFull Automationは可能です。 高度化されたドメインで使われる3DグラフィックスやCADベースのアルゴリズムは、インターネット上に断片的に散らばっているか、そもそも存在しないため、AIもまたバイブコーディングでは表面的な結果しか作れません。1つのメインエージェントを置き、ドメイン文脈をマイクロマネジメントのレベルで継続的に注入しながら、Planning → Redirection → Reviewのサイクルで、開発者が直接主導するフル自動化ではなく、継続的増幅の方式で開発することが、安全で現実的なアプローチだと思います。 calculus9006 10 일 전 | 親コメント | トピック: AIコーディング時代、成長が止まる開発者の脳で起きていること (evan-moon.github.io) 頭を使わずにバイブコーディングしている開発者を見ると腹が立つ。自分の成果物のクオリティがめちゃくちゃなのに、「AIが書きました」と言い訳してみろ。責任は本人が負うべきだ。 skageektp 10 일 전 | 親コメント | トピック: 「AIに失礼なほど性能が上がる？」最新研究が警告するPMのコミュニケーション危機 (maily.so) 黒い牛と黄色い牛のうち、どちらがよりよく働くのでしょうか？ 叱られる牛のほうが、よりよく働くのです コメントをさらに読み込む
ああ、そうですね。リポジトリ一覧を見ると、
Openで始まるプロジェクトがいくつか他にもありますね..まだ公開すらされていないのに、どうやってリバースエンジニアリングするっていうんだ……??
この人、話題になるものがあるたびに毎回
open*という名前のパターンで量産しているので、あまり印象は良くない気がしますね…。以前Claudeを使うと日本語がよく出てきたんですよね。昨日もそうでした
ディストピアにたどり着いた気分ですね
Notion AI以降、もう……何のアプリなのかも分からなくなってしまったけど、
こんなこともあったんだな
短い考えですが、最近私はこんなことを考えるようになりました。昔、アセンブリ言語の専門家たちがC言語の開発者を見て「メモリの大切さが分かっていない」「ハードウェアを分かっていない」などと言っていたそうですが、今見ても同じ文脈で似たような指摘なのではないかと思います。結局、私たちはソフトウェア開発の観点から、従来のプログラミング言語よりもう少し抽象化された言語（AI）で開発するようになるだけなのではないかと思います。そうであれば、その前に使っていた言語については当然ながら専門性が落ちることになります。ただ、少し前まで、今よりもさらにlow-levelな言語を扱って開発する人たちを「怪物」と呼んでいたように、これからはバイブで開発をしつつも、依然として従来の言語の原理を理解している人たちは、一味違う人として見なされるのではないかと思います。
ここにもAIが付けたようなコメントが多く見えるのは、気のせいでしょうか
2と同じ理由で、ほとんどのLLMを使う際には常に悪魔の代弁者の役割も追加で果たすよう指示を付けていますが、それなりに有用な気がします。
コンセプトとしては興味深いですが、実際にうまく回るかは疑問ですね。HNの意見にもあったように、両面市場（two-sided market）は両方向で初期顧客の獲得に成功しなければならないので、そこが大きな問題です
ご自身の論文のように見えるのですが、合っていますか？
ここでもヒンディー語の文字が見えますね。最近は OpenAI、Claude、Google を問わず、日本語出力にヒンディー語が混ざって出てくるケースがかなり頻繁に発生していますが、日本語データセットのラベリングをインドの人たちが担当したのでしょうか?
中国モデルは日本語応答に中国語が混ざって出てくるので好きではなかったのですが、最近はフロンティアモデルがヒンディー語をしょっちゅう混ぜてくるので、むしろ中国モデルに対する抵抗感が下がりました
おお、共有ありがとうございます！
良いリファレンスになる記事ですね。本文が「入ってくるトークン」のバルブを閉めるアプローチだとしたら、
私は「登録されているもの自体」が増えすぎて問題になるケースをよく経験したので、
claude-slimというツールを作ってみました。60個あるスキルのうち半分は一度も使っていないとか、プラグインのせいで
CLAUDE.mdが肥大化するとか、そういった状況をスキャン・分類・整理してくれる CLI です。トークンのカウントはjs-tiktokenベースで、削除するのではなくskills.disabled/に移動するので、いつでも restore できます。https://github.com/iops-leo/claude-slim
本文の設定と方向性がちょうど補完し合うので、併用すると良さそうです
緻密に噛み合ったダイヤのおかげで乗り換えが快適 → 希望編
ホームドアがなく、通勤時間帯に飛び込んで自殺する人が時々おり、停電や故障などの理由で遅延も多い → 絶望編
日本に住んで1年になりますが、日本の鉄道が良いと感じる瞬間が53%くらいで、47%くらいはただただイライラが募ります。特に日比谷線はエアコンのカビ臭が一年中していて、マスクなしで乗ると肺炎になりそうです。
使ってみると、ナプキンのスケッチ認識率が驚くほど高いですね。もうチャットすら必要なくなりました。
私はむしろAIエージェントを使ってから、nvimに戻りました。
ソースを見るなら、nvimで見るほうがずっと楽なので..
同感です。航空宇宙、医療、精密制御分野などにおける高度化されたドメインの中核データは、徹底して閉じた内部ネットワークにあり、アクセスするには中核的な内部関係者であるか、外部であればかなりの費用とNDAへの署名を経てようやく公開されます。AIが学習するデータの大半はインターネット上に公開されたものであり、Python、JavaScriptベースのWeb/アプリサービスであれば、ある程度のFull Automationは可能です。
高度化されたドメインで使われる3DグラフィックスやCADベースのアルゴリズムは、インターネット上に断片的に散らばっているか、そもそも存在しないため、AIもまたバイブコーディングでは表面的な結果しか作れません。1つのメインエージェントを置き、ドメイン文脈をマイクロマネジメントのレベルで継続的に注入しながら、Planning → Redirection → Reviewのサイクルで、開発者が直接主導するフル自動化ではなく、継続的増幅の方式で開発することが、安全で現実的なアプローチだと思います。
頭を使わずにバイブコーディングしている開発者を見ると腹が立つ。自分の成果物のクオリティがめちゃくちゃなのに、「AIが書きました」と言い訳してみろ。責任は本人が負うべきだ。
黒い牛と黄色い牛のうち、どちらがよりよく働くのでしょうか？
叱られる牛のほうが、よりよく働くのです