統一的プロンプトの終焉：もはやllmモデルに互換性はありませんWhy LLM models are no longer interchangeableの意訳です。 開発者やプロダクトビルダーにとって、この数年間はLLMがアプリケーション開発を導いてきました。プロダクトを改善したいなら、最新のLLMを利用すれば良い。ただモデルを切り替えるだけで、ツールの性能を一段階引き上げられるのです。 しかし、その時代は終わりました。AnthropicのClaude Sonnet 4.5やOpenAIのGPT-5-Codexのような新しいモデルは、根本的に異なる方向へ分岐... 先日6,000万ドルを調達したので…おもしろ動画を作りましたWe raised $60M last week… so we made a funny filmの意訳です。 先日、CodeRabbitはシリーズBで6,000万ドルの

「AIがコードを書く時代、スクラムは本当に最適解なのか？」 この問いに、あなたは即答できますか？ 開発現場で起きている静かな革命 AIによるコーディングが当たり前になりつつある今、ソフトウェア開発の進め方そのものを見直すタイミングが来ています。 多くのチームがスクラムを採用していますが、AIが主導する開発（AI駆動開発）では、実はウォーターフォールの方が合理的なのではないか？ という問いが浮かびます。 ただし――速度は従来のスプリント並み。つまり、「遅いウォーターフォール」ではなく、「Water-Scrum-Fast」という新しい形が現実解です。 スクラムがAI駆動開発に噛み合わない理由 AIによる実装は、以下のようなサイクルで進みます： このサイクルは極端に短く、AIが生成するコードは**「曖昧な仕様」に敏感**です。そのため、要件や非機能要件をしっかり定義しておかないと、AIは暴走しま

初めまして、kagayaです。 AIネイティブなプロダクト開発を頑張っています。 共訳した「AIエンジニアリング（オライリー・ジャパン）」が11/28に発売です。よろしくお願いいたします。 世はAIコーディングエージェント時代。 圧倒的に手数は多くなり、自動でPRを生成する取り組みも見かけるようになりました。 かくいう私も、Claude Code Actionを夜間に動かしてGitHub Issueを自動解決する実験をし、朝に作成されているPRを眺めて、「これが不労コード生活か」と思うなどしていました。 そんな中で、新しく生まれた悩みの一つは、このコード、どこまでレビューすればいいんだ？ です。 全部読んでたら、自分で書いた方が早くない？でも全部信じるのも怖い。 バイブに身を任せた結果として生まれた数千行のPRを前に、途方に暮れた経験がある人もいるのではないでしょうか。 Thoughtwo

今年に入ってやたらレビューの時間が増えた。これはコードもそうだしドキュメントもそうだ。 そして、これによる疲れも急激に増加している。 もちろんこれは、LLMによる支援によってアウトプットの速度と量が増加したからだ。 そして、必ずしも質が向上しているわけではなく、むしろ下がっているように感じる。 当然、自分の生産性も下がっている。 自分の頭をダンプし、どういう課題があるか、そして、どう向き合っているかを書いていこうと思う。 他人を経由したプロンプティング私は、機械学習のプロジェクトのテックリードとしてしばらく働いている。 その仕事として、Engineering Requirement Documentsなどの技術文章を書くことも多いが、レビューする機会も多い。 機械学習で難しいのが、プロジェクトが変わり解く課題がちょっと変わると、がらりと全然違う知識が必要になり、新規に論文を読む必要が出てく

【Unit7 ブログリレー2日目】こんにちは、Unit7チームリーダーの丸山です。私が所属するUnit7では、主に医師向けのアンケートサービスの開発・運用を担当しています。 私たちのチームでは、開発プロセスを効率化し、コードの品質を向上させるためにAIによるコードレビューを活用しています。 今回は、便利なAIコードレビューが抱えていた課題と、その課題を解決するために開発した「AIレビュアー育成コマンド」についてご紹介します。 AIコードレビュー、はじめの一歩 浮かび上がった「チームの文脈が伝わらない」問題 チームの知見を学ぶ「AIレビュアー育成コマンド」 実装の裏側 使ってみた感想と今後の展望 We are hiring!! AIコードレビュー、はじめの一歩 エンジニアリンググループでは、開発プロセスの中にAIを活用する取り組みが進んでいます。他のチームでの活用事例は次の記事をご覧ください