kkumaeunsonyeon 2026-01-23 | 親コメント | トピック: この高品質な要約サービスが無料？【インタビュー】 (maily.so) ありがとうございます。メイカーさんにきちんとお伝えします :) xguru 2026-01-23 | 親コメント | トピック: 人がコーディングしていた時代は終わった (x.com/rough__sea) 数日前に上がっていましたが、これについてのHacker Newsのコメントが面白いですね。 SequoiaがDenoに投資していた。これが、彼がこんな愚かな絶対主義的発言をする理由の一つです 競合相手のBunがAnthropicに買収された状況で、彼は今2つのうち1つを選ばなければなりません クラウドへの転換（AIエージェントがDenoを使うようにする） AI研究所またはインフラパートナーへの売却という出口戦略を模索する Sequoiaはおそらく彼に「Bunのように、いつ投資回収が可能になるのか」と尋ねているでしょう minsuchae 2026-01-23 | 親コメント | トピック: Sweep、オープンウェイトベースの1.5Bモデルでコードの「次の編集」自動補完をサポート (huggingface.co) 最近はビッグテック各社がパラメータ数を増やしながら成長してきましたが、流れが変わるのでしょうか？ 個人的には、ひたすらパラメータを増やして成長するやり方には実際のところ限界があると思っていました。 目先の将来を犠牲にして成長しているような感覚、とでも言えばいいでしょうか。特にMoEが最も顕著だったように見えました。 GoogleのGemma 3 27Bもかなり大きい部類でしたが、今ではLLMの世界ではその程度のパラメータ数ですら少ないように見えていました。 技術の進歩も重要ですが、実際にそれをサービングする段階まで考慮した何かが出てこないといけないのでは、と思っていて、今回のものはなかなか良い試みのように思えます。 （パラメータ増加に懐疑的な理由は、高性能なのは分かるものの、それをサービングするのにより大きなコストがかかるからでした。） xguru 2026-01-23 | 親コメント | トピック: SpotifyがAnna’s Archiveに対する訴訟で勝訴し、.orgドメインが停止 (arstechnica.com) やはり、あまりにも無理のある試みだったSpotify全体のバックアップ公開の後に起きた余波だったのですね。 benjamin 2026-01-23 | 親コメント | トピック: この高品質な要約サービスが無料？【インタビュー】 (maily.so) セカンビー、頑張れ whatsup 2026-01-23 | 親コメント | トピック: AI時代、リファクタリングはもはや力仕事ではない (blog.lemonbase.team) ご覧いただきありがとうございます。楽しんで読んでいただけてうれしいです！ 導入してみて気になる点があれば、いつでもお気軽にコメントしてください！！ xguru 2026-01-23 | 親コメント | トピック: Qwen3-TTSファミリーをオープンソース公開: 音声デザイン、クローン、生成機能を提供 (qwen.ai) 私も最近はローカルでQwenベースのモデルを本当にたくさん使っています。 最初はアリババのモデルだからかなと思っていましたが、継続的に改善しながら拡張していくのが驚きですね。 mungchungdoryung 2026-01-23 | 親コメント | トピック: この高品質な要約サービスが無料？【インタビュー】 (maily.so) おお、よさそうですね。 モバイル版YouTubeアプリで「共有」から遷移できるようになると、はるかに活用しやすくなりそうですね cherrycoder 2026-01-23 | 親コメント | トピック: ソフトデリートの難しさ (atlas9.dev) 結局のところ、規制はいつだってコストですね。まあ、どうせ最終的には消費者が負担する分ですが。 brilliant08 2026-01-23 | 親コメント | トピック: インターネット投票は安全ではなく、公的選挙に使用されるべきではない (blog.citp.princeton.edu) 電子投票システムは、大衆一般による無作為な信頼性検証という問題を解決できないと思います。 システムのコード検証は選別された特別な層でしか不可能であり、検証したコードが現場で使われたコードと本当に同じかどうかも信頼できないでしょう。 紙の投票結果を電子システムで集計する過程だけを電子化した韓国でどのような論争が起き、どのような社会的混乱が生じたかを見れば、完全な電子投票システムが導入された場合にどのような社会的混乱が発生するか、おおよそ推測できるように思えます。 hebu570 2026-01-23 | 親コメント | トピック: AI時代、リファクタリングはもはや力仕事ではない (blog.lemonbase.team) とても面白い文章です…！ 現在のプロジェクトのフロントエンドコードがめちゃくちゃなので、使ってみるべきですね！ whatsup 2026-01-23 | 親コメント | トピック: AI時代、リファクタリングはもはや力仕事ではない (blog.lemonbase.team) その通りです （泣） 私もまったく同じように「全部自動化してみよう！」とやってみて苦労した経験があります。 おっしゃる通り、曖昧なケースは除外して、確実なパターンを優先的に処理するのが効率的でした（笑） 明確なパターンは Codemod 曖昧なパターンは手動対応 このようにツートラックで進めるのが、実装・レビュー・バグのリスクまで考えると効率的なんですよね！ whatsup 2026-01-23 | 親コメント | トピック: AI時代、リファクタリングはもはや力仕事ではない (blog.lemonbase.team) 好意的に見てくださってありがとうございます!! dbs0829 2026-01-23 | 親コメント | トピック: 私は「役に立つ存在になること」に依存している (seangoedecke.com) 私の意見は少し違っていて、そういう能力や姿勢を持つ人たちは、私の経験上、例外なく非常に高い自尊心を持っていました。 xguru 2026-01-23 | 親コメント | トピック: Skipが無料化、オープンソースへ移行 (skip.dev) Skip – 単一のSwiftコードベースでネイティブiOSおよびAndroidアプリを開発 shincad 2026-01-23 | 親コメント | トピック: AI時代、リファクタリングはもはや力仕事ではない (blog.lemonbase.team) とても有用な記事ですね。AST ルールを決めるとき、最初は全部自動化しようとして苦労した記憶が……。やってみると、曖昧なケースは除いて、確実なものだけ決めるのが正解なんですよね。 joypinkgom 2026-01-23 | 親コメント | トピック: ソフトウェアエンジニアリングの今後2年 (addyosmani.com) 本当に洞察に富んだ文章だと思います。 私は現場24年目のシニア開発者で、2024年下半期からLLMを通じた開発とバイブコーディングを極限まで活用してみています。AOS/iOS、Webサービスのフルスタック、バッチ、モデルのファインチューニングまで本当に幅広く活用しており、5つほどのエージェントを立ち上げて作業しています。 時間がたつのも忘れて開発し、そのまま寝落ちするような体験を2000年代初頭以来またすることになるとは思いませんでした（笑）。 閑話休題、最近の私の考えでは、開発の領域はすでに誰でもできるものになりつつあります。 コーディングエージェントの進化はさらに加速し、開発はますます簡単で楽になるでしょう。ExcelやWordの文書を作成するくらいのレベルになるはずです。 アンドレイ・カルパシーの言うとおり、最高の開発言語は「英語（言語）」だという意見に同感です。 個人的には、AI論文をもっと読み、論理的に表現するために文章をもっと書くようにしています。（AIと対話することももっと増やそうと努力しています） 本当にとてもワクワクする毎日ですね。 aliveornot 2026-01-23 | 親コメント | トピック: AI時代、リファクタリングはもはや力仕事ではない (blog.lemonbase.team) おお、こういうのいいですね jongyeol 2026-01-23 | 親コメント | トピック: この高品質な要約サービスが無料？【インタビュー】 (maily.so) 便利に使っています！ 👍 snisty 2026-01-22 | 親コメント | トピック: 私は「役に立つ存在になること」に依存している (seangoedecke.com) 誰かが私の話を書いたのかな？ 私は「誰かにとって役に立つ存在になること」というよりは.. ただ自分の『問題』を見つけて（定義して）、その解決策を考え（シミュレーションし）、そのまま開発（PoC）して、問題が解決したときがものすごく楽しい気がする.. だから、自分で見つけた問題であれ、誰かからの依頼であれ、『なぜ？』を聞いてその問題に共感できることが楽しいんだと思う.. だから文書作成も、『見せるための』文書作成は本当につまらないけど.. 実際のユーザーが見ながら使う『実ユーザーマニュアル』を書くのは楽しいようだ.. そういう意味で、最近はAIが出てきて開発がとても楽しい。 私が解決策を『提示』すると、AIが素早く作ってくれるから.. 最近ほど楽しく働けていることはない気がする コメントをさらに読み込む
ありがとうございます。メイカーさんにきちんとお伝えします :)
数日前に上がっていましたが、これについてのHacker Newsのコメントが面白いですね。
最近はビッグテック各社がパラメータ数を増やしながら成長してきましたが、流れが変わるのでしょうか？
個人的には、ひたすらパラメータを増やして成長するやり方には実際のところ限界があると思っていました。
目先の将来を犠牲にして成長しているような感覚、とでも言えばいいでしょうか。特にMoEが最も顕著だったように見えました。
GoogleのGemma 3 27Bもかなり大きい部類でしたが、今ではLLMの世界ではその程度のパラメータ数ですら少ないように見えていました。
技術の進歩も重要ですが、実際にそれをサービングする段階まで考慮した何かが出てこないといけないのでは、と思っていて、今回のものはなかなか良い試みのように思えます。
（パラメータ増加に懐疑的な理由は、高性能なのは分かるものの、それをサービングするのにより大きなコストがかかるからでした。）
やはり、あまりにも無理のある試みだったSpotify全体のバックアップ公開の後に起きた余波だったのですね。
セカンビー、頑張れ
ご覧いただきありがとうございます。楽しんで読んでいただけてうれしいです！
導入してみて気になる点があれば、いつでもお気軽にコメントしてください！！
私も最近はローカルでQwenベースのモデルを本当にたくさん使っています。
最初はアリババのモデルだからかなと思っていましたが、継続的に改善しながら拡張していくのが驚きですね。
おお、よさそうですね。
モバイル版YouTubeアプリで「共有」から遷移できるようになると、はるかに活用しやすくなりそうですね
結局のところ、規制はいつだってコストですね。まあ、どうせ最終的には消費者が負担する分ですが。
電子投票システムは、大衆一般による無作為な信頼性検証という問題を解決できないと思います。
システムのコード検証は選別された特別な層でしか不可能であり、検証したコードが現場で使われたコードと本当に同じかどうかも信頼できないでしょう。
紙の投票結果を電子システムで集計する過程だけを電子化した韓国でどのような論争が起き、どのような社会的混乱が生じたかを見れば、完全な電子投票システムが導入された場合にどのような社会的混乱が発生するか、おおよそ推測できるように思えます。
とても面白い文章です…！
現在のプロジェクトのフロントエンドコードがめちゃくちゃなので、使ってみるべきですね！
その通りです （泣） 私もまったく同じように「全部自動化してみよう！」とやってみて苦労した経験があります。
おっしゃる通り、曖昧なケースは除外して、確実なパターンを優先的に処理するのが効率的でした（笑）
このようにツートラックで進めるのが、実装・レビュー・バグのリスクまで考えると効率的なんですよね！
好意的に見てくださってありがとうございます!!
私の意見は少し違っていて、そういう能力や姿勢を持つ人たちは、私の経験上、例外なく非常に高い自尊心を持っていました。
Skip – 単一のSwiftコードベースでネイティブiOSおよびAndroidアプリを開発
とても有用な記事ですね。AST ルールを決めるとき、最初は全部自動化しようとして苦労した記憶が……。やってみると、曖昧なケースは除いて、確実なものだけ決めるのが正解なんですよね。
本当に洞察に富んだ文章だと思います。
私は現場24年目のシニア開発者で、2024年下半期からLLMを通じた開発とバイブコーディングを極限まで活用してみています。AOS/iOS、Webサービスのフルスタック、バッチ、モデルのファインチューニングまで本当に幅広く活用しており、5つほどのエージェントを立ち上げて作業しています。
時間がたつのも忘れて開発し、そのまま寝落ちするような体験を2000年代初頭以来またすることになるとは思いませんでした（笑）。
閑話休題、最近の私の考えでは、開発の領域はすでに誰でもできるものになりつつあります。
コーディングエージェントの進化はさらに加速し、開発はますます簡単で楽になるでしょう。ExcelやWordの文書を作成するくらいのレベルになるはずです。
アンドレイ・カルパシーの言うとおり、最高の開発言語は「英語（言語）」だという意見に同感です。
個人的には、AI論文をもっと読み、論理的に表現するために文章をもっと書くようにしています。（AIと対話することももっと増やそうと努力しています）
本当にとてもワクワクする毎日ですね。
おお、こういうのいいですね
便利に使っています！ 👍
誰かが私の話を書いたのかな？
私は「誰かにとって役に立つ存在になること」というよりは..
ただ自分の『問題』を見つけて（定義して）、その解決策を考え（シミュレーションし）、そのまま開発（PoC）して、問題が解決したときがものすごく楽しい気がする..
だから、自分で見つけた問題であれ、誰かからの依頼であれ、『なぜ？』を聞いてその問題に共感できることが楽しいんだと思う..
だから文書作成も、『見せるための』文書作成は本当につまらないけど..
実際のユーザーが見ながら使う『実ユーザーマニュアル』を書くのは楽しいようだ..
そういう意味で、最近はAIが出てきて開発がとても楽しい。
私が解決策を『提示』すると、AIが素早く作ってくれるから..
最近ほど楽しく働けていることはない気がする