AI 時代でも C++ が Rust に勝る理由

導入

プログラミング言語に関する議論は、エンジニアリングになるずっと前に道徳劇になることがよくあります。一方の言語はクリーンであると表現され、もう一方の言語は負担が多いと表現されます。 1つは未来として想像され、もう1つは過去からの荷物として想像されます。これらの物語は歴史をきちんと感じさせるので、感情的に満足させられます。また、期限、予算、統合の制約の下でシステムを出荷しなければならないチームを誤解させ、さらに 10 年前には存在しなかった追加部隊である AI コーディング アシスタントとエージェントも誤解させます。

コード生成が日常業務の一部になると、問題は変わります。もはや「どの言語がエレガントか？」だけではありません。または「デフォルトではどの言語が安全ですか?」より難しく、より現実的な質問は次のとおりです。チームが AI システムに実稼働コードの作成、リファクタリング、ベンチマーク、統合、デバッグを支援することを期待している場合、現在それらのシステムに役立つ最も充実した環境を提供している言語はどれですか?私の答えは C++ であり、議論の中心はノスタルジーでも男らしさでもありません。それは密度です。

C++ は依然として、Rust よりもパブリック コード、デプロイされたインフラストラクチャ、ベンダー ツール、プラットフォームのサンプル、最適化の伝承、実際の運用上の傷跡が密集した世界の中に存在しています。 AI モデルはその密度から学習します。彼らは、構文、人々が大規模なシステムをどのようにつなぎ合わせたか、ビルドファイルがどのように進化したか、醜い統合がどのように機能するように作られたか、低レベルのバグがどのように診断されたか、そしてパフォーマンス重視のコードが理論ではなく実際にどのように書かれたかを学びます。これらのモデルが後で実際のエンジニアリングに役立つように求められるとき、その歴史的記憶の形状が重要になります。

これは、Rust が弱い、不真面目、または無関係であるという意味ではありません。それどころか、Rust はシステム プログラミングに健全な圧力をもたらしました。これにより、メモリの安全性が無視できなくなり、多くのエンジニアリングに関する会話の調子が改善され、真に強力なツールとライブラリが作成されました。しかし、Rust の強みが存在しても、AI 支援配信における C++ の現在の利点が自動的に消えるわけではありません。成熟したエンジニアリングでは、多くの場合、両方の真実を同時に保持する必要があります。

証拠が先、スローガンは後

慎重な議論は、公的に観察できるものと推論しなければならないものを区別することから始まります。 The Stack などのコードモデル研究で使用される公開データセットでは、Rust よりも C++ の方が大幅に多く表示されます。公開開発者調査と GitHub 言語トレンドでは、業界全体で C++ の絶対的な使用が広範に広がっていることが示され続けています。ベンダー SDKs から最適化された推論ランタイム、低レベルの数学ライブラリに至るまで、パブリック AI インフラストラクチャは依然として、深く C および C++ で形成された世界を公開しています。 CRUST-Bench などの公開ベンチマークの取り組みは、現在のモデルが Rust コミュニティが重視する強い意味で安全で慣用的な Rust を一貫して生成するのに依然として苦労していることを示唆しています。

これらの事実から、私たちは独断ではなく推論を行います。 C++ の周囲の環境がより充実しているため、AI システムは現在、多くのシステム ドメインで運用に役立ち、統合可能で最適化可能な C++ を生成する可能性が高いと推測されます。これは魔法ではありません。それはフィードバックと組み合わせた露出です。より多くのリポジトリ、より多くのビルド スクリプト、より多くのハードウェア関連サンプル、より多くのベンダー統合、より多くの公開バグ修正、より多くのパフォーマンス調査、より多くの実稼働戦争のストーリーを備えた言語は、人間のエンジニアが修正を開始する前に、モデルをほぼ正確に保つためのより多くの方法を提供します。

この点は、新しい言語にとって不親切に聞こえるため、しばしば反対されます。しかし、Rust が公共土砂を蓄積する時間が減ったと言うことは、Rust を侮辱するものではありません。 C++ は、オペレーティング システム、ブラウザ、データベース、メディア スタック、セキュリティ ツール、ゲーム エンジン、通信、科学技術コンピューティング、組み込み製品、金融システムに何十年にもわたって組み込まれてきました。 Rust は急速かつ見事に成長しましたが、成長は地質の深さとは同じではありません。 AI モデルは深さを吸収します。

コーパスのサイズが人々が認める以上に重要である理由

エンジニアは、トレーニング データの量を、あたかも粗末な論点であるかのように扱うことがあります。実際には、それはもっと人間的な意味で重要です。実稼働コードベースで動作する AI エージェントは、通常、第一原理から完璧なアルゴリズムを発明することはありません。もっと厄介なことをやっているのです。それは、CMake ファイルの更新、1 つのプラットフォームでのコンパイラの不満への適応、ホットパス コンテナの置き換え、ベンダー API のラップ、イメージまたはテンソル レイアウトの変換、ABI の不一致の修正、または周囲のすべてを壊すことなく古いネイティブ サブシステムの負担をわずかに軽減することなどです。

これらのタスクは、通常の不完全な生きたコードに精通することに報酬を与えます。エージェントは、きれいな教科書の例と、隣接する問題を解決するための何千もの実際の試みを見てきたことから恩恵を受けています。 C++ はモデルにそのマテリアルをはるかに多く提供します。より現代的な C++、ゆっくりと修復されているよりレガシーな C++、よりベンチマーク主導型の C++、依然として何らかの形で重要なビジネスを運営しているより恥ずかしい C++、そして実際のシステムが要求する種類の妥協を正確に乗り越えている人々の例がさらに増えています。

これが、「乱雑なプロダクション C++」が依然として貴重なトレーニング データである理由です。エンジニアの中には、この言葉を聞いて、それが訴訟を弱めるのではないかと想像する人もいます。実際にはそれが強化されます。実稼働システムは、完全にエレガントなグリーンフィールド モジュールで構成されているわけではありません。これらには、レガシー インターフェイス、奇妙な ABI 仮定、プラットフォームの条件、ハードウェアの癖、部分的な移行、そして美しくなる前に便利だったために生き残ったコードが含まれます。 AI システムが C++ でそのランドスケープの例をさらに多く見てきた場合、そのようなランドスケープ内で支援するための準備が整っているだけです。

反例は公然と述べる価値がある。チームが強力な Rust の専門知識、明確な安全要件、適度な統合ニーズを備えた小規模なグリーンフィールド サービスを構築しており、周囲に重いネイティブ エコシステムがない場合は、Rust の方がローカルな選択肢となる可能性があります。その状況では、周囲のエンジニアリングコンテキストがより単純であり、人間のチームがシステムをより狭い範囲の複雑さの範囲内に保つことができるため、コーパスサイズからの議論はそれほど決定的ではありません。重要なのは、C++ がすべての引数に勝つということではありません。重要なのは、問題が古くなり、奇妙で、よりパフォーマンスに敏感になり、既存のネイティブ インフラストラクチャとより複雑になるにつれて、AI システムにとって効果的に支援するのに C++ がますます簡単な言語になるということです。

AI インフラストラクチャの世界はまだ C++ の形を整えています

たとえトレーニング データ量を完全に無視したとしても、デフォルトを C++ に引き寄せる第 2 の力が依然として存在するでしょう。つまり、最新の AI 製品の基盤となるインフラストラクチャは強力にネイティブのままです。 CUDA、最適化された数学ライブラリ、ONNX Runtime 内部、oneDNN、OpenVINO、トークナイザー実装、マルチメディア前処理パイプライン、モデル サービング アクセラレータ、ハードウェア ベンダー SDKs、および多くのデプロイメント ランタイムは、C または C++ で記述されているか、最も重要なインターフェイスをそこで公開しています。これは、Rust がそれらを呼び出すことができないという意味ではありません。つまり、ランドスケープ内の最短パスは依然として通常は C または C++ パスです。

AI コーディング エージェントは単独では役に立たないため、これは重要です。これらは依存関係グラフ内で役立ちます。ランタイムの統合、ビルドのデバッグ、ホット パスの調整、またはベンダー SDK 境界を越えた所有権についての理由付けを支援するように求められるモデルは、同じ言語ファミリー内で隣接するサンプルが多数存在する場合に有利になります。 C++ は、ほとんどのパフォーマンスが重要な AI インフラストラクチャ作業において、Rust よりも環境に慣れていることから恩恵を受けています。

ここでは、フィードバック ループに関する会話が重要になります。 AI で生成されたコードは、人間が迅速に検証できる場合にのみ真の価値を発揮します。 C++ は、ベンチマーク、プロファイリング、リプレイ、サニタイザー、ハードウェア カウンター、および低レベルの診断に関するエコシステムが非常に成熟しているため、これらのドメインでチームに豊富なローカル検証を提供することがよくあります。エージェントが C++ 推論パスの変更を提案すると、チームは多くの場合、それをコンパイルし、プロファイリングし、割り当て動作を検査し、レイテンシの分布を比較し、迅速に反復することができます。 Rust にも確かに強力なツールがありますが、多くの AI に隣接するネイティブ システムでは、ライブラリ、サンプル、プロファイラー、および既存のプラクティスの密度が組み合わされて、依然として C++ の方が緊密な人間参加型の修正ループを実行しやすくなっています。

Rust がよりクリーンに見える場合でも、C++ を使用するとチームがより速く動くことが多い理由

これは、清潔さに対して失礼に聞こえるため、イデオロギーを傷つける傾向がある点です。 Rust はホワイトボード上でよりきれいに見えることがよくあります。所有権は明示的です。コンパイラは重要な間違いを防ぎます。正しさを重んじる文化は素晴らしいです。しかし、制作速度と言語の優雅さは同じではありません。実際の配信速度は、既存のコードベース、利用可能なライブラリ、人材プール、デバッグ ツール、デプロイメントの制約、AI 支援の品質、来月さらに 1 つ変更を加えるコストなど、ループ全体から現れます。

C++ は現在、多くの AI 時代のシステムでその広範なループを獲得しています。これは、チームが言語を離れることなく周囲の世界についてより多くのことを尋ねることができるためです。古いネイティブ ライブラリを統合し、ネイティブ パフォーマンス作業を念頭に置いて構築されたプロファイラーを接続し、アロケーターを調整し、プラットフォーム固有の機能を利用し、何か問題が発生した場合には、はるかに多くの公開サンプルから抽出することができます。 AI アシスタントもまったく同じ現実から恩恵を受けます。モデルの周囲の世界が密集していてよく移動すると、モデルのラフ ドラフトはより速く改善されます。

2 つのチームが、カスタムの前処理、複雑なデプロイメント マトリックス、および繰り返しのパフォーマンス チューニングの必要性を伴う、遅延に敏感な推論サービスを構築していると想像してください。 Rust チームは、メモリ安全性に関する小規模なバグを生成する可能性がありますが、それは簡単ではありません。しかし、C++ チームがエコシステムをより直接的に統合し、実際のコードベースでより強力な AI 提案を取得し、成熟したネイティブ ツールを使用してパフォーマンスの変化をより迅速に検証できれば、全体的な配信結果は依然として C++ を優先する可能性があります。ビジネスの観点から言えば、オンラインでの哲学的な議論で 1 つの言語が勝てるかどうかよりも重要です。

有用な反例は私たちを正直に保ちます。比較的単純な依存関係を持つ新しいサービスのメモリ安全性が主要なリスクである場合、Rust は組織的により良い結果を確実に生み出すことができます。間違いは、その真実を受け入れて、それをAIに隣接するすべてのシステムの問題に無差別にエクスポートすることです。言語は説教ではなく文脈で勝利します。

Rust が依然として正しいこと

Rust は尊敬に値しますが、C++ が Rust を風刺すると、その主張は弱くなります。 Rust は、安全でない仮定を可視化することに優れています。それは所有権と生涯に関して強い規律を生み出します。多くの場合、既存のネイティブ世界との互換性よりも正確性と保守性が優先されるグリーンフィールド インフラストラクチャにとって、これは魅力的な選択となります。一部のチームでは、コードベース自体がある種のエンジニアリングの真剣さが強制されるため、Rust によって採用の明確性も向上します。

年齢だけでは不十分であるとはっきり言うことも重要です。規律のない C++ は依然として危険です。チームに弱いレビュー文化があり、プロファイリングの習慣がなく、テストが不十分で、可観測性が尊重されていない場合、コーパスが大きくなり、ツールが充実してもチームを救うことはできません。 AI システムは、優れたエンジニアリングを加速するのと同じくらい簡単に、その混乱を増幅させることができます。本当の主張はより狭く、より現実的です。規律あるチームがパフォーマンス重視で統合が重視される AI 時代のシステムの問題を解決していることを考えると、エージェント、ツール、エコシステムの重力がすべてそれを強化しているため、C++ は今日でも依然として強力なデフォルトの賭けです。

これが、私がユニバーサルウィナーではなくデフォルトベットという表現を好む理由です。デフォルトの賭けは、立証責任がまだ他の場所に移っていないときに選択するものです。 Rust は特定のプロジェクトでそのシフトを獲得できます。しかし、C++ は、その作業がネイティブ AI インフラストラクチャ、低レベルのパフォーマンス、長寿命の実稼働システム、または AI エージェントが大量に公開されている種類のコードベースと深く絡み合っている場合は常に、自分に有利な証拠をさらに多く持って開始します。

現実的な決定方法

ホット パスがネイティブで、依存関係グラフがネイティブで、プロファイリングのストーリーが重要で、AI アシスタントが煩雑な実際の運用コード内で役立つことを期待している場合、C++ については、最初の本格的な言語ディスカッションに値します。システムがグリーンフィールドであり、安全性が優先され、周囲のエコシステムがすでに Rust 型になっており、問題が古いネイティブ層に大きく依存していない場合、Rust はより魅力的になります。システムに両方の世界が含まれている場合 (多くの場合そうである)、成熟した答えは、多くの場合、部族の純粋さではなく、ハイブリッド アーキテクチャです。

このフレームワークは、アイデンティティではなく仕事への決定を戻すため、会話を落ち着かせます。既存の C++ プラットフォーム内のネイティブ推論ランタイムは、新しいコントロール プレーン サービスと同じ問題ではありません。低レイテンシーのメディア パイプラインは、バックエンド API と同じ問題ではありません。モデルを提供するエッジ コンポーネントは、チェーン ネイティブの状態遷移エンジンと同じ問題ではありません。実際の作品に名前を付けると、通常、言語の選択はイデオロギー的ではなくなり、より明白に見えます。

このように決定を下すことには人間にとっての利点もあります。どの言語が賞賛に値するかを考えるのをやめ、現在のシステムが信頼性があり、理解しやすく、改善可能になる最も可能性が高いのはどの言語であるかを問い始めると、チームはより協力的になります。 AI の支援により、これがさらに重要になります。エージェントは、合成された自信で言語ファンダムを飾るために使用される場合ではなく、検証の文化に組み込まれている場合に強力です。

本当のチャンス

AI 時代のより深い機会は、エージェントが成熟したシステムのフィードバック ループ全体に参加できるようになったことであり、古いコードを読み取り、編集を提案し、ベンチマークを改善し、プロファイラーの手がかりを明らかにし、大まかなアイデアをコンパイル可能な実験に変換し、エンジニアが以前よりも早く疑いから測定に移行できるように支援します。その世界では、最も利益を得る言語が、必ずしも最も優れた理論的ストーリーを持つ言語であるとは限りません。それは、公的で実用的で、実戦を経験した現実の網が最も厚いものです。

現在でも、大規模な重大なシステム問題に対して、その言語は C++ です。チームは Rust から学び続けながら、既存のネイティブ知識の膨大な量を使用できるため、これは良いニュースです。最も生産的な姿勢は勝利主義ではありません。それは感謝です。 C++ は数十年にわたる実際のエンジニアリング メモリを蓄積しており、AI システムはそのメモリを使いやすくしています。賢明なチームはそれを活用するでしょう。

ハンズオン ラボ: ネイティブ スコアリング パイプラインを構築および改善する

AI 時代の言語選択に関する記事にコードが含まれていない場合、説教になる危険があります。

そこで、実際の企業で AI エージェントが常に改善を求められているような、小さなネイティブ C++ ユーティリティを構築しましょう。これは、データをロードし、単純な特徴を計算し、結果を並べ替え、上位行を出力するテキスト スコアリング パイプラインです。

わざと控えめにしています。ほとんどの生産エンジニアリングは控えめです。

main.cpp

#include <algorithm>
#include <chrono>
#include <cctype>
#include <fstream>
#include <iostream>
#include <string>
#include <string_view>
#include <vector>

struct Sample {
    std::string text;
    double score = 0.0;
};

static int count_digits(std::string_view s) {
    int n = 0;
    for (unsigned char c : s) {
        n += std::isdigit(c) ? 1 : 0;
    }
    return n;
}

static int count_upper(std::string_view s) {
    int n = 0;
    for (unsigned char c : s) {
        n += std::isupper(c) ? 1 : 0;
    }
    return n;
}

static int count_punct(std::string_view s) {
    int n = 0;
    for (unsigned char c : s) {
        n += std::ispunct(c) ? 1 : 0;
    }
    return n;
}

static double score_line(std::string_view s) {
    const auto len = static_cast<double>(s.size());
    const auto digits = static_cast<double>(count_digits(s));
    const auto upper = static_cast<double>(count_upper(s));
    const auto punct = static_cast<double>(count_punct(s));
    return len * 0.03 + digits * 0.7 + upper * 0.15 - punct * 0.05;
}

int main(int argc, char** argv) {
    if (argc < 2) {
        std::cerr << "usage: scorer <input-file>\n";
        return 1;
    }

    std::ifstream in(argv[1]);
    if (!in) {
        std::cerr << "cannot open input file\n";
        return 1;
    }

    std::vector<Sample> rows;
    rows.reserve(200000);

    std::string line;
    while (std::getline(in, line)) {
        rows.push_back({line, 0.0});
    }

    const auto t0 = std::chrono::steady_clock::now();
    for (auto& row : rows) {
        row.score = score_line(row.text);
    }
    std::sort(rows.begin(), rows.end(), [](const Sample& a, const Sample& b) {
        return a.score > b.score;
    });
    const auto t1 = std::chrono::steady_clock::now();

    const auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(t1 - t0).count();
    std::cout << "processed " << rows.size() << " rows in " << ms << " ms\n";

    const size_t limit = std::min<size_t>(5, rows.size());
    for (size_t i = 0; i < limit; ++i) {
        std::cout << rows[i].score << " | " << rows[i].text << "\n";
    }
}

建てる

Linux または macOS の場合:

g++ -O2 -std=c++20 -o scorer main.cpp
./scorer sample.txt

MSVC を使用した Windows の場合:

cl /O2 /std:c++20 main.cpp
.\main.exe sample.txt

この小さなプログラムがなぜ役立つのか

それはまさに、AI 支援エンジニアリングが具体化される種類のコードだからです。

• それはネイティブです
• 文字列と記憶に触れます
• 測定可能なランタイムを持っています
• それはプロファイリングすることができます
• 段階的に改善できる

それが今日の多くの C++ エージェントの本当の生息地です。つまり、再発明することなく改善する必要がある通常のネイティブ プログラムです。

愛好家向けのテストタスク

この記事を実践的な演習にしたい場合は、次のことを試してください。

1. お気に入りのコーディング エージェントに依頼して、出力を変更せずにプログラムを最適化してもらいます。重複したパスや不要な一時的なパスが削減されているかどうかを検査します。
2. ファイルのロード、スコアリング、並べ替えに個別のタイミングを追加します。実際に時間がどこに行くのかを確認してください。
3. 入力を 100 万行に置き換え、さまざまなエージェントによって提案された最適化の品質を比較します。
4. ユーティリティを Rust に移植し、エクスペリエンスを正直に比較します。 何がよりクリアに感じられ、何がより重く感じられ、そしてどの周囲のツールがこの正確なタスクに対してより成熟していると感じられるのか。
5. C++ バージョンをプロファイラーで実行し、ホットスポットに関する最初の推測が実際に正しかったかどうかを書き留めます。

これは小さな演習ですが、だからこそ役立つのです。エンジニアリングに関する議論のほとんどは、実際の小規模なプログラムとの接触を強いられると、より真実味を帯びてきます。

まとめ

Rust は尊敬に値します。これにより、安全に関する会話の基準が向上し、システム プログラミングにより健全なデフォルトのセットが提供されました。しかし、AI の時代はデフォルトだけが報われるわけではありません。これは、実際のコードの最大の生きたコーパスの中心に位置する言語、低レベル統合の最も深いエコシステム、最も豊かな最適化文化、そして生成されたドラフトから測定可能な運用結果までの最速の実用的なループに報いるものです。現在でも、C++ は Rust よりも強く表現されています。

だからといって C++ が道徳的に優れているわけではありませんし、Rust が無関係であるわけでもありません。これは単に、ネイティブ システムの多くの深刻な問題に対して、ターゲットの世界が C++ である場合でも、AI エージェントの足元にはまだより有用な基盤があることを意味します。これを理解しているチームは、ドラマチックなことをせずに、より適切な意思決定を下すことができます。彼らは、Rust が最も強力な Rust から学び、そのメモリが最も経済的に価値のある C++ の膨大な蓄積メモリを引き続き使用できます。

参考文献

1. GitHub Octoverse 2024: https://github.blog/news-insights/octoverse/octoverse-2024/
2. GitHub Octoverse 2025: https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/
3. スタック オーバーフロー開発者アンケート 2023: https://survey.stackoverflow.co/2023
4. Stack Overflow Developer Survey 2025 テクノロジー セクション: https://survey.stackoverflow.co/2025/technology/
5. スタック データセット カード: https://huggingface.co/datasets/bigcode/the-stack
6. スタックペーパー: https://arxiv.org/abs/2211.15533
7. 事前トレーニングにおけるコード データの影響に関する ICLR 2025 論文: https://openreview.net/pdf?id=zSfeN1uAcx
8. CRUST-Bench: C-to-safe-Rust トランスパイルのための包括的なベンチマーク: Rust
9. CUDA C++ プログラミング ガイド: CUDA
10. ONNX Runtime C/C++ API: ONNX Runtime
11. PyTorch C++ フロントエンド ドキュメント: PyTorch
12. C++ コア ガイドライン: C++

    システムにすでに圧力がかかっている場合はどのように見えるか

C++ と ai 時代のシステム rust は、チームが静かな四半期を望んでいたまさにその瞬間に緊急性が高まる傾向があります。機能がすでに顧客の前に提供されているか、プラットフォームがすでに内部依存性を持っており、システムはその洗練された理論と実行時の動作が丁寧に別々の生活を送っていることを明らかにするために、その特定の週を選択しました。これが、多くの本格的なエンジニアリング作業が和解から始まる理由です。チームは、システムが行うと信じていることと、負荷や変更が加えられた状態、そして誰もが少し創造的になり、賢さが少し低下するような期限の下でシステムが実際に行うことを調和させる必要があります。

ネイティブ インフラストラクチャの計画において最も重要なケースは通常、大規模なレガシー プラットフォーム、パフォーマンス重視の AI バックエンド、および混合言語の最新化プログラムです。このような状況は、技術的、予算、信頼、ロードマップ、そして場合によっては評判にも影響を及ぼします。技術的な問題は、複数のチームがそれに依存した瞬間に政治的に大きくなり、なぜそれが未だに壁の中でアライグマのように行動するのか誰も完全に説明できません。夜はうるさく、場所を特定するのは難しく、無視すると費用がかかります。

そのため、動作圧力と配送の現実というレンズを通して問題を読むことをお勧めします。設計は理論的には美しくても、運用的には破滅的なものになる可能性があります。別の設計は、ほとんど退屈なものであっても、測定可能で修理可能であり、トレードオフについて誠実であるため、製品を何年も使い続けることができます。真剣なエンジニアは、2 番目のカテゴリーを好むようになります。これにより、壮大なスピーチが減りますが、誰もが受動態で話し、誰が近道を承認したかを誰も覚えていないような緊急の振り返りも減ります。

常に老化を続ける習慣

最初の永続的な方法は、1 つの代表的なパスを常に測定し続けることです。チームは多くの場合、曖昧なテレメトリを収集しすぎたり、意思決定品質のシグナルが少なすぎたりします。本当に重要な道を選び、それを繰り返し測定し、議論が装飾的なストーリーテリングに流れないようにしてください。 AI 時代のシステムにおける C++ と Rust を回避する場合、通常、有用な尺度は配信速度、相互運用コスト、ツールの成熟度、実行時の可観測性です。それらが可視化されると、残りの決定はより人間的になり、神秘的ではなくなります。

2 番目の永続的な習慣は、証拠と約束を分離することです。エンジニアは、システムがその結論を得る前に、ある方向性が正しいと言うよう圧力をかけられることがよくあります。そのプレッシャーに抵抗してください。特にトピックが顧客やお金に近い場合は、最初に狭い証明を作成します。検証されていない大きな野心よりも、検証された小さな改善の方が商業的価値があります。これは、四半期末のレビューで仮説が期限に変わり、組織全体が楽観主義をスケジュール作成の成果物のように扱うようになるまでは、当然のことのように思えます。

3 番目の永続的な習慣は、所有者の言語で推奨事項を書くことです。 「パフォーマンスを向上させる」または「境界を強化する」という文章は、感情的には心地よいものですが、運用上は役に立ちません。月曜日の朝に実際に生き残るのは、誰が何を、どの順序で、どのロールバック条件で変更するかを述べた段落です。多くのテクニカル ライティングが失敗するのはここです。スケジュール可能であることよりも、先進的に聞こえることを望んでいます。

時間を節約する反例

最も一般的な反例の 1 つは次のようなものです。チームはローカルで大きな成功を収め、システムが理解されたと想定し、測定規律をアップグレードすることなく、アイデアをさらに要求の厳しい環境に拡張します。これは工学的に言えば、ホテルのプールで泳ぎ方を覚えてから、海の天気について自信を持って TED トークをするのと同じことです。水ではなくなるまでは水です。

もう 1 つの反例は、ツールのインフレです。新しいプロファイラー、新しいランタイム、新しいダッシュボード、新しいエージェント、新しい自動化レイヤー、古いラッパーとの調和を約束する新しいラッパー。これらはどれも本質的に悪いことではありません。問題は、誰も明確に名指ししていない境界線の補償を求められたときに何が起こるかということだ。その後、システムはさらに装備され、より印象的になり、場合によってはより理解できるようになります。購入者はこれをすぐに感じます。そのような表現がなくても、積み重ねが決断の代償として高価なものになったことを彼らは嗅ぎ分けることができます。

3 番目の反例は、人間によるレビューを自動化の失敗として扱うことです。実際のシステムでは、多くの場合、人間によるレビューが自動化を商業的に受け入れられる状態に保つための制御となります。成熟したチームは、どこを積極的に自動化するか、どこで承認や解釈を可視化するかを知っています。未熟なチームは、スライド内で「すべて」が効率的に聞こえるため、マシンにすべてを実行させたいと考えます。その後、最初の重大なインシデントが発生し、突然手動レビューが変換体験の誠実さによって再発見されます。

弊社が推奨する配信パターン

仕事が順調に進んでいる場合、最初の成果物は、チームに輪廻議論をやめるのに十分な技術的な読み取りを提供することでストレスを軽減するはずです。その後、次の制限付き実装で 1 つの重要なパスが改善され、再テストによってエンジニアリングとリーダーの両方が方向性を理解できるようになります。その順序は、正確なツールの選択よりも重要です。それは、技術スキルを前進に変えるものだからです。

実際的な観点から言えば、最初のサイクルは狭いことをお勧めします。つまり、アーティファクトを収集し、1 つの厳密な診断を作成し、1 つの限定された変更を出荷し、実際のパスを再テストし、次の決定を平易な言葉で書くというものです。分かりやすい言葉が重要です。買い手が明確さを後悔することはほとんどありません。購入者は、領収書が届く前に感動したことを後悔することがよくあります。

ここでもトーンが重要になります。強力な技術的な作業は、以前にプロダクションに対応したように聞こえるはずです。穏やかで、正確で、誇大宣伝に養われるというよりは、それを少し楽しんでいます。そのトーンは操作信号を伝えます。これは、チームがシステム エンジニアリングの古い真実を理解していることを示しています。マシンは高速であり、ロードマップは脆弱であり、詩的であり続けることを許可されていたすべての仮定に対して、遅かれ早かれ法案が到着します。

これが準備完了であると判断する前に使用するチェックリスト

ネイティブ インフラストラクチャの計画では、準備は気分ではありません。それは結果を伴うチェックリストです。 AI 時代のシステムにおける C++ 対 Rust の回避策を広範囲に展開する準備ができていると呼ぶ前に、可能な限り最良の方法でいくつかのことを退屈なものにしておきたいと考えています。代表的な負荷の下で予測どおりに動作する 1 つのパスが必要です。矛盾しない 1 セットの測定値が必要です。私たちはチームに、境界線がどこにあるのか、そしてそれを壊すことが何を意味するのかを知ってもらいたいと考えています。そして、実装室の外にいる誰かがそこから正しい判断を下せるように、作業の出力が十分に明確であることを望んでいます。

このチェックリストは通常​​、配信速度、相互運用コスト、ツールの成熟度、および実行時の可観測性に関するものです。数値が正しい方向に進んでいるにもかかわらず、チームが即興でシステムを説明できない場合、作業の準備ができていません。建築が印象的に聞こえても、現場からのささやかな反例に耐えられない場合、その作品はまだ準備ができていません。実装は存在するが、ロールバックの話がタイムスタンプ付きの祈りのように聞こえる場合は、作業の準備ができていません。これらはいずれも哲学的な反論ではありません。それらは単に、高価なサプライズが登場する傾向にある形式にすぎません。

これは、チームが実際の問題を解決しているのか、それともその問題に近い能力を単に練習しているだけなのかを発見する場所でもあります。非常に多くの技術的取り組みは、誰かが再現性、生産の証拠、または予算に影響を与える決定を要求するまでは、成功したように感じられます。その瞬間、弱い作品はぼやけてしまい、強い作品は妙に地味になってしまいます。プレーンが良いです。プレーンとは通常、システムがカリスマ性に依存するのをやめたことを意味します。

結果について話すことを推奨する方法

最終的な説明は、リーダーシップ会議に耐えられるほど簡潔であり、エンジニアリングレビューに耐えられるほど具体的である必要があります。それは思っているよりも難しいことです。過度に専門的な言葉は順序を隠します。過度に単純化された言葉はリスクを隠します。適切な中間点は、勝ち誇ったような感じではなく、穏やかに聞こえる方法で、道筋、証拠、限界のある変化、そして次に推奨されるステップを説明することです。

このような構造を推奨します。まず、どのパスが評価されたのか、そしてそれがなぜ重要なのかを述べます。次に、その道に関して何が間違っていたのか、何が不確実だったかを述べます。 3 番目に、何が変更、測定、または検証されたかを述べます。 4番目に、何が未解決のままなのか、そして次の投資で何が買えるのかを述べます。この構造が機能するのは、エンジニアリングと購買行動の両方を尊重しているからです。エンジニアは詳細を求めています。購入者は順序付けを望んでいます。サプライズを楽しんでいるふりをしている人も含めて、誰もがサプライズを減らしたいと思っています。

このように話すことの隠れた利点は文化的なものです。技術的な作業を明確に説明するチームは、通常、それをより明確に実行します。彼らは曖昧さを洗練されたものとして扱うのをやめます。専門用語では印象を与えることが難しくなり、難しいシステムでは信頼されやすくなります。これは、エンジニアリングの成熟度の最も過小評価されている形態の 1 つです。

私たちがまだ偽造を拒否したいもの

システムが改善された後でも、成熟したチームはネイティブ インフラストラクチャの計画において不確実性を正直に保ちます。弱い測定にはより明確な証拠が必要であり、厳しい境界には平易な言葉が必要で、より穏やかなデモには実際の運用準備が必要です。ある程度の不確実性は軽減する必要があります。正直に名前を付けなければならない人もいます。この 2 つの仕事を混同すると、立派なプロジェクトが高価なたとえになってしまいます。

同じルールが、AI 時代のシステムにおける C++ と Rust に関する決定にも適用されます。チームに再現可能なベンチマーク、信頼できるロールバック パス、または重要なインターフェイスの明確な所有者が依然として不足している場合、最も役立つ出力は、より大きな約束ではなく、より明確なノーまたはより狭い次のステップである可能性があります。この規律により、技術的な作業が改善を目的とした現実と一致した状態に保たれます。

このように作業すると、不思議な安心感があります。システムが楽観的なストーリーテリングに依存しなくなると、たとえ作業が困難なままであっても、エンジニアリングに関する会話はよりシンプルになります。そして生産現場では、それは多くの場合、ささやかな恵みとして数えられます。

実際の技術レビューからのフィールドノート

C++ システムの配信では、デモが実際の配信、実際のユーザー、実際の運用コストを満たしたときに、作業が本格化します。それは、きちんとしたアイデアがシステムのように動作し始める瞬間であり、システムは有名なドライなユーモアのセンスを持っています。彼らはキックオフデッキがどれほどエレガントに見えるかなど気にしません。彼らは、境界、障害モード、ロールアウト パス、そしてスタックに関する新しい神話をでっち上げずに次のステップを説明できる人がいるかどうかを重視しています。

Why C++ Still Beats Rust in the AI Era の場合、実際的な問題は、ロードマップ、プラットフォーム、またはセキュリティ レビューにすでにプレッシャーを感じている購入者に対して、より強力な配信パスを作成できるかどうかです。その購入者は、霧の中に磨き上げられた講義を必要としません。彼らは使用できる技術的な読み取りを必要としています。

最初に検査するもの

まず、ネイティブ推論、プロファイリング、HFT パス、DEX システム、および C++/Rust モダナイゼーションの選択肢という 1 つの代表的なパスから始めます。その道は測定するには十分に狭く、真実を明らかにするには十分に広くなければなりません。最初のパスでは、割り当て動作、p99 レイテンシ、プロファイル証拠、ABI 摩擦、および信頼性の解放をキャプチャする必要があります。これらの信号が利用できない場合、プロジェクトは依然として白衣を着た意見がほとんどであり、意見はそれ自体を戦略として宣伝してきた長い歴史があります。

最初の有用な成果物は、ベンチマーク、プロファイリング証拠、および範囲を絞った実装計画を含むネイティブ システムの読み取りです。計画会議で誰もが期待したとおりに動作するのではなく、システムが動作するとおりに示す必要があります。トレース、リプレイ、小さなベンチマーク、ポリシー マトリックス、パーサー フィクスチャ、または反復可能なテストは、多くの場合、別の抽象的なアーキテクチャの議論よりも早くストーリーを伝えます。良い工芸品は驚くほど失礼だ。彼らは希望的観測を中断します。

時間を節約する反例

高くつく間違いは、最初の有用な証明よりも大きな解決策で応答することです。チームはリスクや遅延を認識すると、すぐに新しいプラットフォーム、書き換え、全面的なリファクタリング、またはヨガをしているような名前の調達しやすいダッシュボードに手を出します。場合によっては、そのスケールが正当化されることもあります。多くの場合、これは測定を延期する方法です。

より良い動きはより小さく、より鋭いです。境界に名前を付けます。証拠を捕らえます。重要なことを 1 つ変更します。同じパスを再テストします。次に、次の投資がより大きな投資に値するかどうかを決定します。このリズムは変革プログラムほど劇的ではありませんが、予算、リリース カレンダー、および制作上のインシデントに影響されても存続する傾向があります。

弊社が推奨する配送パターン

最も信頼性の高いパターンには 4 つのステップがあります。まず、代表的な成果物を収集します。次に、これらのアーティファクトを 1 つの難しい技術診断に変換します。 3 番目に、1 つの限定された変更またはプロトタイプを出荷します。 4 番目に、同じ測定フレームで再テストし、次の決定をわかりやすい言葉で文書化します。このクラスの作業では、CMake フィクスチャ、プロファイリング ハーネス、小さなネイティブ再現、およびコンパイラ/ランタイム ノートの方が、一般的な方向性に関する別の会議よりも価値があるのが通常です。

分かりやすい言葉が重要です。購入者は出力を読んで、何が変化したのか、何が依然としてリスクが残っているのか、何を待てばよいのか、次のステップで何を購入するのかを理解できる必要があります。推奨事項をスケジュールしたり、テストしたり、所有者に割り当てることができない場合でも、それは装飾的すぎます。装飾的なテクニカルライティングは楽しいものですが、制作システムがその心地よさをもたらすとは知られていません。

結果が役に立ったかどうかを判断する方法

Why C++ Still Beats Rust in the AI Era の場合、結果により配信速度、システムの信頼性、商用化の準備の 3 つのうち少なくとも 1 つが改善されるはずです。これらのどれも改善されない場合、チームは何かを学んだ可能性がありますが、購入者はまだ有用な結果を受け取っていません。その区別が重要です。学ぶことは崇高なことです。有料のエンゲージメントもシステムを動かすはずです。

最も強力な成果は、より狭いロードマップ、危険なパスの自動化の拒否、モデルの境界の改善、よりクリーンなネイティブ統合、書き換えがまだ必要ではないという慎重な証拠、またはリーダーが実際に資金を提供できる短い修復リストなどです。真剣なエンジニアリングとは、より良い意思決定の連続であり、ツールの仮装コンテストではありません。

SToFU はそれにどうアプローチするか

SToFU は、これを最初に配信の問題として扱い、次にテクノロジーの問題として扱います。私たちは関連するエンジニアリングの深さをもたらしますが、その取り組みは、経路、境界、リスク、測定、そして行う価値のある次の変更などの証拠に基づいて行われます。重要なのは、ハードワークを簡単に思わせないことです。重要なのは、次の重大な行動を実行できるほど明確にすることです。

それは、購入者が通常最も重視する部分です。彼らはどこでも意見を採用できます。彼らに必要なのは、システムを検査し、実際の制約に名前を付け、適切なスライスを構築または検証し、通話終了後の混乱を軽減する成果物を残すことができるチームです。騒がしい市場では、明確さはソフトスキルではありません。それはインフラです。