8 ポイント 投稿者 GN⁺ 3 시간 전 | まだコメントはありません。 | WhatsAppで共有
  • 検証可能な技術スタックに集中する "Choose Boring Technology" の原則は、AIコーディングツールの時代においてさらに重要になっている
  • 企業は限られた "innovation tokens" を、信頼性が実証された技術に戦略的に使うべきである
  • モダンなAIコーディングツールは、ほぼあらゆる技術スタックに対して もっともらしく見えるコード を生成するが、ユーザーが知らない技術が2つ以上組み合わさると、誤りを検証できなくなる
  • すでによく知っている技術スタックでは、AIコーディングツールは force multiplier(能力増幅ツール) として機能するが、知らない技術では単なる依存手段に成り下がる
  • AIが生成したコードの品質が高くなるほど問題を発見しにくくなるため、技術に対する 深い理解 の価値はいっそう高まる

Choose Boring Technology 原則の再確認

  • 10年前にDan McKinleyの文章 "Choose Boring Technology" に共感した見方は、10年が経っても変わっていない
    • 新しいプロジェクトを始めるときは、まず「新しいことを学ぶための口実なのか、それとも問題を解決しようとしているのか」を考える
    • 新しいことを学ぶなら未知の要素を 1つに限定 し、問題を解決するならすでに知っている技術を貫く
  • LLMとagentic AIコーディングツールの登場によって、この原則はさらに critical になった

McKinleyの中核的主張

  • 企業は限られた "innovation tokens" を持っており、未検証で面白そうな技術ではなく、確立されよく理解された技術に戦略的に使うべきである
  • 退屈な技術には、既知の 失敗モード(failure modes)、よく理解された機能、実証済みの運用信頼性がある
    • 深夜3時に障害が起きたとき、未知の領域を切り開くよりも、Stack Overflowに答えがある技術をデバッグするほうがよい
  • この原則は2015年にも正しく、今日でも正しい

AIコーディングツールという新たな変数

  • モダンなAIコーディングツールは、想像できるほぼすべての技術スタックについて、専門家が書いたように見えるコードを生成する
    • ClaudeやCopilotに、Kubernetesベースのmicroservices、GraphQL federation、最新のJavaScriptフレームワークの実装を頼むと、ルールに従い実行もできるコードを返してくる
  • 自分が知らない技術を2つ以上使う場合、AIが間違った結果を出しているかどうかを検証する方法がまったくない
    • LLMは印象的な能力を持つにもかかわらず、技術的な細部では hallucinate(ハルシネーション) を起こす
  • エンジニアがAI生成の問題あるコードをそのまま受け入れてしまう事例を目にしてきた
    • deprecated APIの使用、セキュリティのアンチパターンの実装、本番負荷になって初めて表面化する微妙な性能問題
    • コードは正しく見え、命名規則にも従い、適切なエラー処理もあったが、その技術に精通した人だけが見抜ける形で間違っていた

未知の技術 + AIコード = 不確実性の乗算

  • 不慣れな技術とAI生成コードを組み合わせると、未知数を足すのではなく 掛け合わせる 結果になる
    • フレームワークの選択が適切かどうかわからない
    • AIの実装が best practice に従っているかわからない
    • 生成されたコードのどこが boilerplate で、どこが中核のビジネスロジックなのかわからない
    • どの失敗モードを警戒すべきかわからない
  • これは単なるcargo-cultingを超えた、"cargo-culting times 2,356" レベルの問題である

退屈な技術とAIが相乗効果を生む地点

  • 基盤となるスタックを理解しているとき、AIコーディングツールは非常に強力になる
    • Railsを十分に知っているからこそ、Claudeが怪しい提案をしたときに見抜ける(context7の助けを活用)
    • JavaScriptの特性を理解しているからこそ、Copilotの提案を fact-check できる
  • AIは、すでに理解している技術では force multiplier になり、知らない技術では依存のための杖(crutch)に成り下がる

AI時代の実践的ガイドライン

  • 新しい技術を評価するときは、まず「AIがこの技術の実装コードを生成したとき、自分はそれを適切にレビューできるか」と自問すべきである
    • 答えが「いいえ」なら、その技術を mission-critical な場所で使うべきではない
  • 新しいことを学ぶと決めたなら(innovation tokenは1つしかない)、AIの提案を fact-check できるだけの深い理解を得るために、実際に時間をかけるべきである
    • コピー&ペーストしてうまくいくことを願うだけではいけない
  • AIツールを口実に、複数の新しい技術を同時に抱え込む誘惑に抗うべきである
    • AIは、新しい言語・新しいフレームワーク・新しいインフラを一度に扱えるように感じさせるが、どれもまともに検証できない

AI時代に高まったリスクと結論

  • 元の "choose boring technology" の主張は、運用の複雑さと認知負荷を減らすことにあり、この懸念は今も有効である
  • AI時代には追加のリスクがある。どんなスタックでも専門的に見えるコードを生成するAIがもたらす false confidence(根拠のない自信) である
  • AI生成コードの品質のため、問題発見の難易度はむしろ上がっている
    • 以前は悪いコードは見た目にも悪かったが、今ではドメインを十分に理解していなければ微妙な問題に気づけない
  • 問題を解決するときはすでに知っているものを使い、新しいことを学ぶときは学ぶことに集中し、AI生成コードを理解と混同してはならない
  • スタックの中で最も退屈な技術とは、AIが間違ったときにそれと気づけるほどよく理解している、その技術なのかもしれない
    • 一度も使ったことのない技術についてAIが何千行ものコードを自信満々に生成する世界では、その理解の価値はかつてないほど大きい

まだコメントはありません。

まだコメントはありません。