この動画には、マスクされた拡散生成プロセスを実装するライブコーディングの部分があるよ: https://www.youtube.com/watch?v=oot4O9wMohw

あの速度はマジでヤバい！

リンク : https://chat.inceptionlabs.ai/

一部のテキスト拡散モデルは連続的な潜在空間を使ってるけど、歴史的にあまりうまくいってないんだ。今見かけるモデルのほとんどは、次の時系列にフィードフォワードされる実際のトークン出力を予測するように訓練されてる。拡散の特性は、前のタイムステップを修正して最終出力に収束させる能力から来てるんだ。最近のアーキテクチャの一つについての説明があるんだけど、これはMercuryが裏でやってることに似てるかもね。詳細はここにあるよ: https://pierce.dev/notes/how-text-diffusion-works/

LLMがサクッと編集して、100行未満… いいよ。LLMにコードをチェックしてもらうのはいいけど、CIにLLMを組み込むのは、大きなプロジェクトだと何百時間も生産性を失うことになるよ。それか、自分のコードを書くのを学ぶ時間を半分に減らして、コンテキストサイズやプロンプトの精度を調整することになる。LLMツールに対する過信が本当に理解できないし、個人プロジェクトや小さなウェブアプリ以外では流行らないと思う。これらのツールは複雑なシステムを扱うのが苦手だから、重要なリポジトリで監視なしに使わせるなんて、銃を口に突っ込まれない限り無理だよ… 監視してるなら、自分でやった方がマシだし、結局その作業の50%はやり直すことになるからね。

10年以上、オフ・ザ・シェルフやSaaSのCIを使ってる職場で働いてないから、私の経験はあなたとは真逆だと思う。私たちはいつもCI/CDパイプラインをできるだけ速くするために頑張ってた。私はSREとして、2つの異なる会社でそういうプロジェクトに関わった。300人規模の小さな会社では、全てのインフラニーズ（CI/CD、ライブデプロイ、後にk8sに移行したけど、私たちが運用してたワークロードには十分安定してた）を担当してたし、別の会社では5000人以上の規模でJenkinsをバックエンドに使ったCI/CDの改善に取り組んでた。開発者体験のために全く別のシムを開発しつつ、特注のワーカー・スケジューラー/ランナーにも取り組んでた。ここ何年も、10分以上かかるCI/CDのセットアップを経験したことがないから、あなたのコメントを読んで驚いたし、10年以上この痛みを感じてないのが贅沢だなと思った。まだそんな問題があるとは思わなかったよ。

運が悪かっただけかもしれないけど、私が関わったほとんどのプロジェクトでは、PRが通るのを待つのに多くの開発者の時間が無駄になってた。これが理解できない。開発者の時間は機械の時間よりもずっと高価なのに。文句を聞いたら、企業はCIの作業者を倍増させないの？リソースをもっと投げ込むだけの問題でしょ。私がGoogleにいたときは、非決定的なバグ（同期が欠けてたり、フェンスが原因で不安定になったり）をデバッグするのが普通だったし、同じテストを10000台のマシンで10000回実行して、数桁の失敗を見つけるのが一般的だった。今の雇用主は同じことのクランキーな実装（UIなし）を持ってるけど、自分のチェックアウトから全テストを実行するために1000のテストワーカーを立ち上げる単一のコマンドもある。目標は、1M locのコードベースのテストを5分以内に終わらせて、変更に対する迅速なフィードバックを得ること。 > ビルドを完全にヘルメティックにする（インタランキャッシュなし） これは別の話。最大限の決定論的なCIステップが必要で、ビルドを完全にヘルメティックにして、すべてのものをキャッシュすることが求められる。

ほとんどの会社では、CI/Devツールチームはキャリアの行き止まりだよ。ビジネスに影響を与える可能性がないから、リーダーシップが理解できないお金の無駄遣いになってしまう（もし理解し始めたら、今度は彼らのお金の無駄遣いになって、彼らにとってもキャリアの行き止まりになる）。だから、しっかりした考えを持ってる人は改善に時間を使いたがらない。しかも、短期的な考え方だとも言えない。開発者の視点から見ると確かにそうだし、もし開発時間がビジネス全体の成功を決めるなら、会社にとってもそうかもしれないね。

じゃあ、CI/CDはやめてしまえ。これらの冗長なプロセスは人間の相互運用性のためのものだ。

でも、今はLLMのワークフローをコーディングに追加したから、古くてほとんど役に立たなかったワークフローの価値が10倍になった。Gitのチェックポイント、コードのリンティング、そして自分の単純なユニットテストと統合テストが、LLMが無駄な時間をかけずにゴミを生成しないために重要になった。

それは、人々がテストの書き方を知らないからだ。PRでの「forループ内でN個の選択クエリを実行しないで」っていうコメントは、テストでは完全に無視されている。各テストは多くのDBクエリを出力できるし、さらに複数のケースを作る。人々は、同時にN個のことを扱うコードを書くことすら知らない。テストが遅いのは、テストされるコードが完全にクソで、バッチモード用に書かれていないからだと思う。バッチモードを無視すると、テストはほとんどの場合、テストケースが順番に実行されるように書かれている。それでも、同時に実行しようとすると、テストが不安定になる。なぜなら、書き方やインターフェースの設計が全く同時実行を許さないからだ。もう一つのコメント、最高のAIモデルが書いたコードもまだクソだ。10000曲のライブラリを持つ音楽プレーヤーのようなシンプルなものですらできない。最初の試みはひどいものになる。並行メタデータ解析の理解がなく、UIで10000曲を一度に表示するのが遅いなど。だからAIは、ひどいコードやひどいテストを書く人々の言い訳に過ぎない。もしそんなに賢いなら、それを使ってCIを早くしてみろ。

これでCIのボトルネックがさらに悪化するだろう。 それに同意する。ボトルネックは複数あるから、これに対する解決策は複数考えられると思う。一番明らかなのは、データベースとの通信時のネットワークオーバーヘッドだろう。もう一つは、ストレージを使っている場合のストレージオーバーヘッドかもしれない。正直なところ、もう一つは言語だ。型安全でコンパイルされた関数型言語は、動的に解釈される言語に比べて大きな利点があると思う。これは、動的言語に対してパフォーマンスを大幅に向上させ、モデルの変更に対する信頼感を高め、テストを減らす甘いスポットだと思う。AIに大きく依存していても、早いターンアラウンドは競争優位だと思う。

「むしろ、CIは時間が経つにつれて遅くなった。人々がビルドを完全にヘルメティックにしようとしたから（つまり、インターレンキャッシュなしで）、オンプレミスの専用ハードウェアから高価なクラウドVMに移行したけど、IOが遅くて、時間が経ってもあまり速くなってない。私は（MacOSビルドのランナーを自己ホスティングした経験に基づいて）今取り組んでるプロジェクトが、Hetznerのような裸の金属のレンタルマシンで自己ホスティングのランナーを使うだけで、2-5倍のパイプライン性能を得られるかもって予想してる。もしかしたら私はナイーブかもしれないし、責任を持つ人間じゃないけど、オフの時間に回帰テストを実行するために使える裸の金属マシンをいくつか持つことは、既存のCIランナーに支払ってる金額よりも安くて、全体的に大幅にスピードアップできるから、低い労力で純粋な勝利だと思う。確かに、みんな忙しいし、外部サービスにやってもらった方がいいと思うだろうけど、正直、こういう計算資源が手元にあれば、何かしらの使い道を見つけるし、効率的に物事を進めることができると思う。裸の金属を扱う方法やこういう計算を活用するスキルは一般的に役立つスキルだと思うけど、こういう移行に熱心な人はあまり見かけない。大体は「ちょっと安いインスタンスがある別のサービスに移行しよう」って感じで、独自のキャッシングレイヤーがあって、CIのクソにロックインされることになる。これらのサービスがダウンタイムゼロでバグがないわけじゃないし、統合の手間もかかるのに、なんで裸の金属に移行することがいつもタブー視されるのか理解できない。ビルドのような簡単なことでもね。」

これは、コーダーたちがテストを効率的にするために十分な時間をかけなかったからだと思う。もしかしたら、LLMコーディングエージェントがその助けになるかもね。

価格はちょっと高めだね。パフォーマンスに敏感なアプリケーションに取り組んでるときに、MercuryとGroq（Llama 3.1 8b、Llama 4 Scout）を試したけど、パフォーマンスは互角だったけど、価格はGroqの方がずっと良かった。でも、拡散モデルには注目してるし、いいオープンソースのものが出てくることを期待してる。彼らの可能性にワクワクしてるよ。

LLMの出力が人間に読まれることを想定していないケースはたくさんあるよ。例えば、非構造化テキストをJSONのような構造化フォーマットにパースしたり、自然言語やプログラミング言語の間で翻訳したり、エージェントシステムの推論ステップとして機能したり。だから「読むには速すぎる」としても、そのスピードはまだ役に立つことがある。

これにより、回答する前にもっと（場合によってはもっとたくさんの）推論ステップやツールコールができるようになる。

これは本当に面白すぎる。