「センス」を備えた30倍AIエンジニアになる方法

 (pakodas.substack.com)
21 ポイント 投稿者 GN⁺ 4 시간 전 | 2件のコメント | WhatsAppで共有
  • AIがコードを大量生成する時代に、エンジニアの価値を分ける中核的な能力は速度・知識・経験ではなく、「センス（taste）」、つまり何を作るべきかを判断する評価能力
  • OpenAI Codexチームのメンバーたちは独立に同じ結論へ到達しており、優れたソフトウェアのセンスを持つ人がいれば誰でも10倍エンジニアになれる
  • センスは 認識（recognition）・コンパス（compass）・ビジョン（vision） の3つの形に分かれ、いずれも内部評価関数の品質という1つのメカニズムに収束する
  • 価値は 問題選択、システムアーキテクチャ、品質判断、ユーザー共感、コミュニケーション の5つの領域で集中的に生まれる
  • コード作成がコモディティ化した今、判断と思考こそが本来の真の能力であり、これを意図的に育てなければならない

世界は変わったが、ほとんどのエンジニアは気づいていない

  • Anthropic CEOのDario Amodeiは2025年3月、AIが数か月以内にコードの90%を書くようになると予測し、当時は荒唐無稽に聞こえた
  • Claude Codeの開発者Boris Chernyは、12月に自分がコミットしたコードの100%がAIによる作成であり、IDEを一度も開かなかったと報告
  • AIコーディングツールを「slop」と呼んでいたAndrej Karpathyは、12月に立場を完全に覆した
    • 「プログラマーとしてこれほど取り残されたと感じたことはなく、職業が劇的に再編されている」
    • Ruby on Railsの作者DHHは、抵抗していたのは「モデルが十分によくなかったから」であり、今は状況が逆転したと認めた
    • Vercel CTOのMalte Ublは「ソフトウェア生産コストは0に収束しつつある」と述べた
  • 2025年11〜12月の間に Opus 4.5、GPT-5.2、Gemini 3 が見えない能力の境界を超え、幅広い作業でAIのコードが熟練エンジニア水準に到達し、所要時間は数時間から数分へと短縮された
  • コード生成がコモディティ化すると、残るのは ソフトウェアエンジニアリング（問題分解、何を作るかの決定、テスト・信頼性・拡張性の設計、トレードオフの判断）、すなわちセンスである

センスとは実際には何か

  • 最高のエンジニアリングチームが語るセンスには3つの定義があり、同じ能力を別の角度から見ている

  • 認識（Recognition）としてのセンス

    • 2つの実装を見て、なぜかを説明する前にどちらが優れているかを感じ取る能力
    • Emma Tang: システムが本当にクリーンで拡張可能で重複がなく、理解しやすいかどうかはセンスの問題
    • ソースを味見したシェフが酸味が足りないことを意識的に特定する前に分かるように、パターンマッチングは意識的な推論より速く働く
    • CodexチームがCLIにTypeScriptではなく Rust を選んだ事例
      • どちらでも動くが、Rustの制約（強い型付け、明示的なメモリ管理、最小限の依存関係）が技術的な利点を超えてエンジニアリング文化への効果を生むと認識した
      • 「技術的に優れた言語」ではなく、「チームで望ましい行動を形作る言語」だという判断
    • 悪いセンス: 流行だから、ブログで速いと書かれていたからという理由で、二次的効果を理解せずにRustを選ぶこと

  • コンパス（Compass）としてのセンス

    • Tiboが語った、エンジニアは「自分だけのコンパス」を持つべきだという形で、すでに存在するものを評価するのではなく、次に何を作るべきかを知る能力
    • コードを1行も書く前に「これは正しい機能ではない」と言えるエンジニア
    • Boris ChernyがClaude Codeのtodoリスト機能を2日間で約 20個のプロトタイプ として作った事例
      • インラインtodo、ドロワーUI、インタラクティブなpill、画面下部表示などを試し、恣意的ではなく必然的に感じられる形へ収束した
      • 事後的にはなぜ最終案が優れているかを説明できたが、中間案に対する初期の不満そのものが、コンパスとして機能するセンスだった
    • コンパスとしてのセンスは実行より上流で働くため、認識としてのセンスより希少である

  • ビジョン（Vision）としてのセンス

    • SQ Mahの「人間が進化を定義する」という言葉で表され、今よいものではなく、2年後に重要になるものを知る最も難しい形
    • OpenClawの開発者Peter Steinbergerは、5〜10個のエージェントを同時に回しながら、ほとんどの時間をアーキテクチャとシステム設計に投じている
      • 「コードの大半は退屈なデータ変換であり、エネルギーはシステム設計に集中すべきだ」と述べた
    • Codexチームの次の優先事項は 豊富なコンテキストに基づく計画立案 であり、ビジネス目標・市場の力学・チームの優先順位など、コードベースの外にある情報が必要になる
      • より優れたコード生成器ではなく、モデルがソフトウェアがなぜ存在するのかを理解する未来に向けたプロダクト戦略に適用されたビジョンとしてのセンス

  • 統合された定義

    • 3つの形はいずれも1つのメカニズムに収束し、センスとは 内部評価関数の品質 である
    • 認識では完成した成果物に、コンパスでは可能性と方向に、ビジョンでは未来と軌道に評価関数が働く
    • AIがコードを生成する世界で人間の仕事は 評価（何を作るかを決める、成果物が十分かどうかを判断する、アーキテクチャ変更のタイミングを察知すること）であり、評価こそが職務となる

なぜあるエンジニアははるかに多く稼ぐのか

  • AI以前の報酬格差は会社・年次・専門分野の3つで説明されていたが、AIはこの3変数をすべてかき混ぜつつある
  • スタートアップでは優秀なエンジニアと平凡なエンジニアの差が3倍から 10倍 に広がっており、優秀な側はAIによって小規模チーム並みの成果を出せるため
  • 年次という軸も移動し、コードを書く経験 より 優れた判断の経験 が重要になっている
    • 「Reactを知っている」という価値は下がり、「高負荷下でも信頼性のあるシステムを設計できる」という価値は上がっている
  • 差の大きいエンジニアに共通するのは、複利で積み上がる決定 を下すこと
    • 優れたアーキテクチャ判断1つで、1年にわたり数か月分の作業を節約できる
    • 優れたプロダクト判断1つで、機能が実際に採用されるかどうかが決まる
  • より懸命に働いても、センスの優れた人より半分の価値しか出せないことがある。8個のエージェントを間違った問題に回すより、2個を正しい問題に回すほうが多くの価値を生む
  • OpenAIの事例では、最も生産的なエンジニアたちはより多くのコードを生成したのではなく、ユーザーとの対話、プロダクトの方向性、共感 により多くの時間を使うように焦点を移した
    • 一部は「コードベースの感覚を失う」としてタブ補完に戻ったが、どちらの反応も有効である

価値が実際に生まれる場所

  • センスが不均衡な価値を生み出す5つの領域が存在し、ほとんどのエンジニアは1〜2領域でしか競争していない

  • Zone 1: 問題選択

    • 何をやるかを選ぶことは最もレバレッジの高いセンスの判断だが、ほとんど考えられていない
    • センスのあるエンジニアは「これをうまく解けば、他の5つの問題は消えるか？」と問う
    • Peter Steinbergerはエージェントと長くやり取りしながら計画を磨き、挑戦し、反論し、納得したときだけエージェントを実行する。計画こそが作業であり、実行は委任される
    • Claude Codeの権限システムでは、複雑なRBACや細分化ポリシーの代わりに最もシンプルなアプローチ（権限要求後に返答を記憶する）を選び、素早く直感的にリリースした

  • Zone 2: システムアーキテクチャ

    • 部品がどう噛み合うかという領域で、センスの半減期が最も長い。良い判断は2年後でも配当を生み、悪い判断は書き直しを要する技術的負債として蓄積する
    • Codexのエージェントループを状態機械にした判断、Claude Codeの「可能な限りビジネスロジックを少なく」書く判断、OpenClawのモジュール式拡張性への執着は、いずれもアーキテクチャ上のセンスの判断だ
    • Boris Cherny: 「新しいモデルが出るたびにコードを大量に削除し、モデルの周囲には可能な限り少ないコードしか置かない」
      • ほとんどのチームはリリースのたびにコードを追加するが、Claude Codeチームは削る。モデルこそが製品であり、その周辺はできるだけ薄くあるべきだ

  • Zone 3: 品質判断

    • リリースに十分か、さらに作業が必要かを見極めることであり、AIが助けられない領域でもある（特定の文脈における「十分」を知らないため）
    • Codexの階層的コードレビューでは、非中核コードはAIレビューのみ、コアなエージェントコードは人間によるレビューが必須
      • センスとは、どのコードが重要かを知ることにある。権限システムには人の目が必要だが、README更新には不要だ
    • Codexチームはほぼすべてのコードをプロンプトで書いているが、社内の他部門は約70%程度にとどまる。手で書く30%こそ品質判断が最も重要な部分である（「30/70ルール」）

  • Zone 4: ユーザー共感

    • 向こう側にいる人間が実際に何を必要としているかを理解することで、AIが最も弱い領域だ
    • Borisが作ったClaude Codeの文脈付きローディングメッセージ（単なるスピナーの代わりにモデルが何をしているかを表示）は、誰にも求められていなかったが、情報のない待ち時間と情報のある待ち時間の違いを埋めるために作られた
    • Codexのサンドボックスのデフォルト設定もユーザー共感の判断だ。Tibo: 「採用率に不利になっても、デフォルトで安全でない可能性のあるものは勧めない」
      • 多くのユーザーは「それほど技術的ではなく」、取り返しのつかないことを誤ってしてしまう可能性があると理解し、利便性よりも安全を選んだ

  • Zone 5: コミュニケーションとストーリーテリング

    • 作ったものをどうフレーミングするかという領域で、エンジニアは一貫して過小評価するが、市場はそこに報いる
    • Peter SteinbergerのOpenClawは、バイラルになった週にClaude CodeとCodexを合わせたよりも多くのGoogle検索を記録した
      • 明確な名前、説得力のあるデモ、そして「1人でチーム規模のアウトプットを作る」という物語が拡散を後押しした
    • CodexのAGENTS.mdファイル（人間ではなくAIエージェント向けのREADME）は、文書の読者が変わったことを認識し、その形式を適応させたコミュニケーション上のセンスだ

センスの事例（そして欠如）

  • 技術スタック選択

    • センスなし: 「一番人気で、みんな知っているからTypeScript」と、慣習で正当化する
    • センスあり: BorisはClaudeモデルにとって**「on distribution」**（モデルがすでにうまく扱える）だからTypeScriptを選び、チームの慣れではなくモデルの強みに最適化した
      • Codexは「設定したエンジニアリング基準を考えさせ」、自分たちで直接見渡せる最小依存を望んでRustを選んだ。同じ種類の判断でも、どちらも一般的な好みではなく具体的な制約に基づいている

  • 完全には理解していないコードを扱う

    • センスなし: 「AIで生成し、テストを通ったからリリース」とし、テストの十分性や保守性を考えない
    • センスあり: Peterは読んでいないコードでもリリースするが、不注意ではない。「コンポーネントの位置と構造、システム全体の設計は把握しており、普通はそれで十分だ」
      • テスト・lint・ローカルCIが検証レイヤーとなる。一方は賭けであり、もう一方は構造的に正しさが保証されるシステムだ

  • 機能要望への対応

    • センスなし: チケットどおりに実装してリリースし、次へ進む
    • センスあり: Borisはリリース前の2日間で20個のプロトタイプを作る。遅いのではなく、素早い実験によって正しい解法へ航路修正しているのであり、必然性こそがセンスの指紋だ

  • AIエージェントのための設計

    • センスなし: セットアップ案内とAPIエンドポイントがある普通のREADME
    • センスあり: Codexは、AIにコードベースの探索方法・テストコマンド・標準遵守の方法を教えるAGENTS.mdを書く。モデルが成功できるよう必然的にコードベースを構造化している

  • PR洪水への対応

    • センスなし: AI生成PRが殺到しているのに同じレビュー手順を維持し、レビューアーが過負荷になって品質も落ちる
    • センスあり: Emma TangのチームはPRにプロンプト添付を必須とし、なければSlackで「プロンプトは何？」と尋ねる
      • AIの世界では、コードより意図をレビューする方が有益だ。PeterはPRを「prompt requests」と呼び、コードより生成プロンプトに強い関心を持つ。生成の単位が変われば、レビューの単位も変わる

センスを育てる計画（感想ではなく）

  • 「もっと経験を積め」という助言は「もっと運動しろ」と同じくらい役に立たない。以下は3つの形態別の90日計画だ

  • 1か月目: 構造化された露出で認識のセンスを築く

    • メカニズムは、多様なばらつきへの大量露出の後に意図的な振り返りを行うこと
    • 1〜2週目: 尊敬する開発者ツール10個を研究する
      • Codex CLI、Claude Code、Linear、Supabase、Stripeダッシュボード、Vercel、Tailwind、Railway、Resend、そしてソフトウェアではない製品を1つ（よく設計された博物館展示やレストランのメニュー）インストール
      • それぞれ15分間書く: 最初の60秒で何に気づいたか、何がうれしかったか、何が混乱したか、どんな判断を盗みたいか
      • 良いツールは最初の30秒でプロセス説明の前に結果を見せ、悪いツールはなぜ気にするべきかを示す前にアーキテクチャを説明する
    • 3〜4週目: 発見そのものではなく方法論のために論文10本を研究する
      • 元祖BLEUスコア論文、AnthropicのConstitutional AI論文、GoogleのPageRank論文、Netflix Prizeの記録、Scaling Laws論文
      • 書くこと: 方法論をエレガントにしているものは何か、機能させる1つの洞察は何か、自分のドメインにどう適用するか
      • 明確な評価基準、限界を正直に開示すること、複雑さより単純な定式化を選ぶことといった構造的原則が、分野を越えて繰り返し現れると気づくだろう

  • 2か月目: 能動的な識別でコンパスとしてのセンスを築く

    • 週次演習「Side-by-Side」: 同種の例を2つ見つけ、なぜ一方が優れているのかを500語で書く（2つのAPIドキュメント、2つの技術ブログ、2つのアーキテクチャ図、2つの評価フレームワーク）
      • 「好きだ」は禁止。必ず「これがより優れている理由は…」と具体的なメカニズムを示す
      • 例: Stripeのドキュメントは、内部アーキテクチャではなく開発者がやりたいこと（支払いを送る、エラー処理をする）を中心に構成されているため優れている
    • 日次演習「Practice Noticing」: ツール・論文・コードを見るたびに、作り手の判断を1つ選び、「なぜこれで、明白な代替案ではないのか」を1文で記録する。30日後、その30個の観察のパターンが育ちつつあるセンスだ

  • 3か月目: 生成的応用でビジョンとしてのセンスを築く

    • 9週目: 自分が所有しているもの（チームのオンボーディングフロー、プロジェクトREADME、評価パイプラインの開発者体験）を、学んだ内容で再設計する
    • 10週目: これまで書いた中で最も精密な文章を書く。最も長いものや網羅的なものではなく、すべての段落が役割を果たし、読者の考え方を変える文章だ
    • 11週目: システムをゼロから設計し、すべての判断を慣習ではなく第一原理で説明する（「ベストプラクティスだからマイクロサービス」ではなく、「チームは4人、トラフィックは予測可能で、今後18か月は不要なスケーリングの利点よりデプロイの単純さの方が大きいのでモノリス」）
    • 12週目: センスを共有する。2つのアプローチの違いを教え、自分のコードベース向けのAGENTS.mdを書く。センスをシステムや文書にエンコードする能力が、個人技術と組織能力を分ける

センスをすばやく育てる5つのプロジェクト

  • 1. AI生成コード向け評価フレームワークの構築

    • リンターやテストランナーではなく、「このAIコードは本番投入に十分か」に答えるフレームワークとして、独自のルーブリック（正確性、保守性、効率性、セキュリティ、スタイル）を定義する
    • 実際のAI生成PR 50件に適用して採点し、驚くような点数を基準にルーブリックを補正し、結果を公開して、Zone 3（品質判断） のセンスを築く

  • 2. オープンソースプロジェクトのオンボーディング再設計

    • 技術は尊敬しているがオンボーディングがもどかしいツールをforkし、開発者体験の最初の5分を再設計し、READMEとスタートガイドを書き、新規コントリビューターが初日にPRを出せるよう構造化する
    • Zone 4（ユーザー共感） と Zone 5（コミュニケーション） を同時に築く

  • 3. チームのための「センステスト」を構築

    • 実装アプローチ10組のドキュメントを作成し、各組で一方がより良いセンスを持つものとし、エンジニア5人にどちらが良いかとその理由を尋ねる
    • 興味深い成果は正解ではなく 意見の不一致 であり、標準がずれている地点こそがバグ・技術的負債・手戻りの根源であり、最もレバレッジの高い 組織のセンス を築く

  • 4. 48時間の制約で製品をリリース

    • プロトタイプではなく他人が使う動く製品を作り、時間制約が絶えずセンスのある判断（含めるものと削るものの選択）を強いる
    • 間違った機能に6時間を使えば4分の1を燃やすことになるため、悪い判断の結果が即座に現れる

  • 5. 思考を変える技術ブログを書く

    • チュートリアルやハウツーではなく、馴染みのある概念を再構成して読者がその後は違って見えるようになる文章を書く（センスとはすなわち評価だという気づき、モデルがリリースされるたびにコードを削除することは慣行ではなくアーキテクチャ哲学だという認識）
    • Zone 5（コミュニケーション・ストーリーテリング） を築き、真の視点があらゆるセンスの土台になる

センス中心でキャリアを最適化する

  • 速度競争をやめる

    • AIが機械の速度でコードを書くなら、コーディング速度競争は負けるゲームであり、1時間に500行生成する人より、どの50行が実際に必要かを30分考える人のほうが価値が高い
    • 実装速度はコモディティ化され、コモディティ化されていないのは 何をどのように実装するかについての判断 である

  • センスに必要な「隣接スキル」に投資する

    • 最高のエンジニアたちの共通点は単なるコーダーではないことだ。Borisはスタートアップ創業者であり、EmmaはStripeで4年間データインフラを率い、PeterはPSPDFKitをグローバルビジネスへと育てた
    • センスには 原材料 が必要であり、プロダクト思考・デザインへの認識・ビジネス理解・コミュニケーション能力が、センスを可能にする材料になる

  • センスが報われる役割を選ぶ

    • よく定義された仕様を実装する役割は速度を、何をどう作り何を十分とするかを決める役割はセンスを直接報いる
    • センスが特に報われる役割：初期スタートアップの創業エンジニア、プロダクト企業のテックリード、他のエンジニアがその上に立つシステムを設計するプラットフォーム・インフラエンジニア、開発者体験エンジニア、クロスチームのアーキテクチャ判断を扱うstaff+エンジニア

  • センスが宿る公開成果物を築く

    • AI時代には履歴書より ポートフォリオ が重要であり、証拠は成果物の中にある（よく設計されたオープンソース、一貫した視点を持つ技術ブログ、人々が実際に使う製品）
    • PeterのOpenClawはどんな履歴書より雄弁であり、BorisのClaude Codeプロトタイプはどんな行動面接の回答よりもセンスをよく証明する

不都合な真実

  • センスは不均等に分布しており、今後もそうである。一部の人は15年間にわたる何千回もの判断でそれを育ててきており、90日計画では追いつけないスタートラインの差を持つ
    • Codexチームは無制限のトークンアクセスを持ち、モデルを作る会社で働いており、Peterは20年の経験を持ち会社をエグジットした非典型的な出発点にいる
  • ただし「センスがない」と「少しセンスがある」の差はキャリアへの影響が非常に大きく、埋めることができる。チケットを受け取って実装していた人が、ユーザーリサーチによって何を作るべきかを提案し、テストやアーキテクチャまでAIで実装するようになる飛躍こそがセンスだ
  • Gergely Oroszの率直な吐露：「価値ある何かを突然奪われるような感覚がある。コーディングが上手くなるまでには多くの努力が必要だったし、没頭してアイデアをタイプしていた時間は最高の記憶だった」
    • 手でコードを書く技術が中心ではなくなっていく喪失感は本物だが、どのようなコードが存在すべきか、どう構造化されるべきか、そして何をもって十分とするかを知る能力 は常に本物の実力だった
  • 次に繁栄するエンジニアは、これに気づいた人だ。センスは常に仕事そのものであり、ただコードの中に隠れていただけで、AIがタイピングを引き受けることでそれが露わになっている

関連記事

2件のコメント

 
clastneo 3 시간 전

いや、もう10xじゃだめで30xを考えないといけないのかｗｗｗ
 
channprj 2 시간 전

私も、x倍エンジニアのようなやや誇張された表現はもう見たくないと思っています.. T_T
定量的であるかのように見せていますが、実際には定性的な表現でもあります。