AIツールを使っても、良いソフトウェアを作るには開発者自身の技術理解と判断力が不可欠だ、という主張記事だった。 ・ただフライパンに肉を置くだけのステーキ調理に、スキルはほとんど要らない ・だが、本当に美味しいステーキを安定して焼くのは非常に困難 ・AIを使った昨今のソフトウェア開発も、これと同じ状況になりつつある ・誰もがAIに指示を投げ、想像通りの完璧なソフトウェアが出てくることを期待している ・しかしAIは熟練のシェフではなく、単なるレシピ実行機にすぎない ・運が良ければAIは素晴らしいコードを出力してくれる ・ただ、堂々と黒焦げの炭を出して「これはミディアムレアだ」と言い張ることもある ・これで困った人は、高価なAIプロダクトや新しいフレームワークに課金して解決しようとする ・しかし、そうしたサービスの裏側でも結局は同じAIが料理をしていることが多い ・AIは反復作業を自動化し、開発を大幅に高速化できる ・一方で、品質を定義し、トレードオフを判断することはAIにはできない ・技術的には正しくても本質的に間違っているコードを見抜くのは人間の役割 ・結局のところ、望む結果を安定して得るには、自分自身でソフトウェアを深く理解して学ぶしかない

技術のエキスパートから組織のリーダーへ移り変わる際の難しさと、その乗り越え方をまとめたIEEEのポスト。 ・STEMのキャリアにおいて、純粋な技術者からリーダーへの移行は最も困難なフェーズの一つ ・なぜかというt、技術的な卓越性への依存から離れ、システム思考やチームの連携を習得する必要があるから ・エンジニアの意思決定は、それ単体で完結するわけではない ・自分の技術的な選択が、組織のビジネスや運用の現実とどう関連するかを認識しかねばならない ・そのためには、自分が唯一の技術の専門家であるという固執を捨てる ・代わりに、コラボレーションを促進し、取り組みを組織の戦略と一致させることに注力する ・また、指示を待つのではなく、自律的なビジネスオーナーのように振る舞うことが求められる ・与えられたタスクを実行するだけでなく、組織に価値を生み出す隠れた領域を積極的に発見していく

Cloudflare OS、本当にいいところをついてくる。さすが。 ・Cloudflareが自社向けに構築したAIワークスペースをOSSとして公開 ・全従業員が社内の文脈やツールにアクセスできるエージェントを持つための基盤 ・すでに社内で数千人が利用し、資料作成やタスクの自動化に活用している ・チャットを通じたリサーチだけでなく、業務アプリの構築も可能に ・エージェントがクライアントとサーバーのコードを書き、独自のアプリを生成する ・アプリの実体はDynamic WorkerやDurable Object Facetとして動作 ・生成されたアプリはチーム内で共有でき、各々がAIを使ってさらにカスタマイズできる ・エージェントへのAPIキーの直接付与は危険であり、またスケールしない ・MCPを利用すればツール呼び出しの制御自体は安全に行える ・ただ、MCP単体ではエージェントがどの機密データを閲覧したかの追跡が不十分 ・そこでGatekeeperと呼ばれる仕組みを間に挟んでアクセス制御を実現している ・機密データを読み取ったエージェントは、その後の共有や外部通信が自動で制限される ・これにより、生成されたアプリ経由でのデータ漏洩をシステム側で防ぐことが可能に ・推論には組織が許可した任意のAIモデルを組み合わせて利用できる ・Cloudflare AI Gatewayを経由させることで、高価なモデルの使いすぎやコストを制御できる

コストが100分の1の安価なオープンモデルを事後学習し、検索タスクでGPT-5.6 Solと同等の性能を出す手法を述べている。（プロダクト宣伝の記事でもあるので、そこは注意） ・かつてのRAGは単発検索だった ・だが、現在はエージェントが自律的に検索を繰り返すアプローチへ移行している ・ただ、GPT-5.6 Solなどの最先端モデルでこれを行うと、1リクエストに10秒以上かかりコストも高すぎる ・一方で、100倍安価なオープンモデルはそのままでは推論能力が足りない ・そこで、検索などの特定タスクに特化し、オープンモデルを強化学習で事後学習させるアプローチが有効 ・記事中では、開発したCastformを使っている ・で、社内の既存ドキュメントから学習用タスクを自動生成した ・学習時にはAIが検索を何度も繰り返すため、数千の並列タスクが走りデータベースに瞬間的な高負荷がかかる ・ここはNeonの動的なオートスケーリングを利用し、スパイク負荷を効率的にさばいて対処した

日経BP社からSteve Yegge氏らが原著の翻訳書籍 『バイブコーディング　生成AI→チャット→エージェントによる「本番品質のソフトウェア」の未来』 をご恵投いただきました！ 同氏のブログはたまに読んでいることもあり、書籍の中身の楽しみです！ 購入リンクはこちらから：

AIコーディングツールの指数関数的なコスト増をいかにコントロールしていくかについてのdatabricks記事。（一部引き算して読む感じ） ・AIコーディングツールは生産性を劇的に向上させる ・しかし、それに伴ってコストも指数関数的に増大している ・放置すれば、AIによる恩恵がコストで相殺される ・そのため、最高性能ではなく、コスパに優れた効率性フロンティアの追求が必要になっていく ・具体的な対策の筆頭は、より安価で効率的なモデルへの移行 ・特定のモデルへの依存を防ぐため、メタハーネスを導入して柔軟性を確保する ・また、タスクの難易度に応じて安価なモデルと高性能モデルを動的にルーティングする手法も有効 ・予算管理において、利用上限でアクセスを完全に遮断するのは悪手 ・これは、最も生産性の高い開発者の足を引っ張ってしまうため ・代わりにコストを可視化し、閾値を超えたら安価なモデルへダウンシフトさせる仕組みが望ましい ・さらに、不要なコンテキストを削ってトークン消費を抑えることも大事に ・また、プロンプトキャッシングを活用することで、コストを大幅に削減できる （で、Unity AI Gateway というプロダクトの宣伝になるので、以下は略）

実際に価値のあった自作の社内ツールは何か、を語り合うRedditスレッド。 人気のあるレスに 「開発チームに直接送られてくるプロダクト関連のメールをすべて、無人の受信トレイに転送するOutlookルール」 というのがあって笑った。

趣味の（ニッチな）プログラミングコミュニティが、なぜLLMの利用に猛反発するのか、について意見を述べているポスト。目的の違い。 ・OSDevやLangDevなどのニッチな趣味界隈では、LLMへの敵意が高まっている ・ここでは、難しい分野を習得する学習プロセスそのものが目的だから ・単に「動くコード」を得ることはおまけに過ぎない ・界隈で尊敬されるのは、深いドメイン知識を持ち、仕組みを理解している人 ・コードが動くことより、それがなぜ、どう動くのかを知っているかが重視される ・そのため、LLMで完成品を生成することは、ものづくりのプロセスを奪う行為 ・ただ、学習自体が目的であるコミュニティにおいては、クラフトマンシップを奪う存在に