AIは思考を置き換えるのではなく、高めるべき
(koshyjohn.com)- もっともらしい成果物を素早く作れるようになるほど、理解のない反復に陥りやすくなり、判断力を育てる練習を飛ばすと 長期的な能力 は弱くなる
- 慣れたパターンでは大きな助けになるが、見慣れない問題、曖昧な条件、不完全な情報、相反する制約では 浅い模倣 は簡単に崩れ、実力が露わになる
- 優れたエンジニアは、ボイラープレート、要約、テストのスキャフォールディング、調査の加速といった 機械的な作業 は任せる一方で、問題定義とレビュー、選択と破棄は 自ら引き受ける
- ソフトウェアエンジニアリングの高い価値はコード生成よりも 判断力 にあり、隠れた制約を見抜き、間違った問題に気づき、曖昧な議論をトレードオフへと変換する力の重要性が増している
- とりわけキャリア初期や組織運営では、本当の理解 を守る基準がいっそう重要であり、何を委任し何を自分で担うかを見極めるほど、AIは人の価値を高める道具になる
思考を外注したときに生じる失敗モード
- A.I. はコード生成、会議の要約、概念説明、設計のたたき台作成、ステータス更新の作成といった作業を素早くこなせるが、理解なしにもっともらしい結果だけを出す癖 も簡単に生み出してしまう
- 機械が出した答えを自分の理解であるかのように繰り返すと、能力を積み上げないまま 有能そうに見える状態 だけをなぞることになる
- 生成された成果物で自分の理解を置き換えるほど、判断力を鍛える練習を飛ばし、長期的な能力 を 短期的な見栄え と引き換えにしてしまう
- 見慣れない問題、曖昧な条件、不完全な情報、相反する制約のように、テンプレートでは処理できない状況では、浅い模倣は簡単に崩れる
-
試験の答案を写すたとえ
- 答えを写して良い成績を保てたとしても、実際に 理解が必要な場面 に入ると土台が空であることが露呈する
- 自分で手を動かして蓄積される直感がなければ、慣れていない問題を推論したり、条件の変化に対応したりするのは難しい
- A.I.が出した答えを繰り返し使い回しても、借りているのは 熟練の外見 だけで、実際の熟練は積み上がらない
-
電卓のたとえ
- 電卓は時間を節約してくれる優れた道具だが、数の感覚 がないまま依存すると、その結果が妥当かどうかを確かめられなくなる
- 土台のあるエンジニアはA.I.の出力をレビューし、誤りをふるい落とし、修正したり破棄したりできる
- 土台のないエンジニアはA.I.を使っているのではなく、A.I.に引きずられる側 になってしまい、とくに正確さや結果責任が重要な職務ではより危険になる
-
自動運転車のたとえ
- 自動運転は疲労を減らし日常的な状況を処理してくれるが、運転を理解する前に依存すると、操作権限だけを持つ乗客 に近くなる
- 視界不良、複雑な道路、予測不能な他車、システム障害、突然の危険といった非標準的な状況で本当の実力が表れる
- A.I.も一般的なパターンや馴染みのある構造には強いが、エンジニアリングは要件変更、微妙なバグ、不明確なオーナーシップ、競合するアーキテクチャ目標、部分的なデータ、組織の摩擦、完全な答えのないトレードオフによって、常にその範囲から外れていく
優れたエンジニアがA.I.を使う方法
- 優れたエンジニアはA.I.を控えめに使うのではなく、より積極的に使いながらも、思考そのものは手放さない
- ボイラープレートの作成、ドキュメント要約、テストのスキャフォールディング生成、リファクタリング提案、失敗可能性の探索、調査の加速、反復作業の圧縮といった 機械的な作業 は喜んで任せる
- その代わり、より鋭い問いを立て、目の前の依頼ではなく 本当の問題 を定義し、中身のない滑らかな文章よりも 明確さと簡潔さ を優先する
- システム内にある既存知識を再構成するだけでなく、新たで高価値な知識 を生み出す
- こうして確保した時間を、より高いレベルの思考と判断に再投資する
価値の本当の源泉
- ソフトウェアエンジニアリングは長いあいだ コード生産 と同一視されてきたが、最も高い価値はそこにはない
- 文法的に正しいコードを書くことだけが中核なら、A.I.が職務の大部分を直接置き換える流れになるはずだが、実際の核心は 判断力 にある
- 価値あるエンジニアは、障害が起きる前に 隠れた制約 を見抜き、チームが間違った問題を解いていることに気づき、曖昧な議論を明確なトレードオフへと変え、欠けた抽象化を見つけ出し、コードではなく 現実をデバッグ する
- A.I.はこうした作業を支援することはできても、それを代わりに引き受けることはできない
- 今後より大きな価値を生むエンジニアは、A.I.をより有用にする 設計原則、ドメイン理解、パターン、文脈、意思決定フレームワーク を生み出す側に近い
- この環境では、エンジニアはA.I.に置き換えられるのではなく、生の出力の一段上 で働くことで、より大きなレバレッジを得る
キャリア初期のエンジニアにとってより大きな危険
- この問題はとくに キャリア初期 において重要である
- 最初の数年間は、デバッグ感覚、システム直感、精密さ、センス、批判的レビュー、問題分解能力、なぜ動くのかを説明する力といった 基礎能力 が形成される時期である
- こうした能力は、摩擦、試行錯誤、失敗の修正、根本原因の追跡、現実とぶつかって砕ける経験を通じて積み上がる
- 学習過程でA.I.があらゆる困難を取り除いてしまうと、短期的な効率は得られても、能力が鍛えられる段階 を飛ばしてしまう
- 1〜2四半期のあいだは効率的に見えるかもしれないが、将来を支える能力を静かに取り逃がしてしまう可能性がある
- 支援システムによって機能しているように見せることはできても、本当の能力 まで代わりに作ってくれるわけではない
判断力に近道はない
- 生成された説明を読むだけで、自分で作業しなくても 熟練が頭の中へ移されることはない
- 推論を長く外注しておきながら、最終的に強い推論力を身につける道はない
- 機械的な作業を外注し、調査速度を上げ、反復業務を圧縮することは可能であり望ましい
- しかし、技術形成のプロセス そのものを飛ばして、その技術を持った状態になることはできない
- 最もナイーブなA.I.活用の中核的な誤りは、時間を節約しているつもりで、実際には 弱い判断力、浅い理解、低い適応力 という請求書を先送りにしている点にある
境界線と組織レベルの含意
- A.I.が 理解をより速く生み出し、より深く考えさせ、より高いレベルで働けるよう助けるなら、人の価値は高まる
- A.I.が理解を避けさせ、困難を避けさせ、推論のオーナーシップを避けさせるなら、人の価値は下がる
- 一方の道は複利のように積み上がり、もう一方は中身を空洞化させ、無関係になりやすい状態 へと追い込む
- 未来は、A.I.をただ使うエンジニアよりも、何を委任し何を自ら引き受けるか を正確に見極め、時間節約をより良い思考へ変えられるエンジニアに有利である
組織の健全性により大きく作用する理由
- エンジニアリングマネジメントも、理解を加速する使い方 と 理解を装う使い方 を見分けなければならないという同じ境界線の上に立つ
- 強いリーダーシップは、滑らかな成果物と 本当の判断力 を区別できなければならず、速度・流暢さ・プレゼン能力だけを報いると、技術的な深さのシグナルを見落とすことになる
- 低い理解と高い流暢さを伴う仕事が広がると、個々の成果物の品質が落ちるだけでなく、組織の 知識環境 そのものが弱くなる
- レビューはより弱くなり
- 設計議論はより浅くなり
- ドキュメントはより滑らかでも、役立ちにくくなり
- 時間が経つほど、組織は自らが依存する明確さと技術判断を生み出す力を失っていく
- だから重要なのはA.I.ツールの導入そのものより、本当の思考・学習・職人技が生き残る条件 を守ることにある
- 採用段階から、見かけの流暢さではなく 本当の理解 を見分ける方法が必要である
- 面接では polished answer ではなく 推論のプロセス を試さなければならない
- 評価では出力量よりも 明確さ、深さ、健全な判断、長く残る技術的貢献 を報いるべきである
- チーム設計と文化にも大きな影響がある
- 優れたエンジニアが、思考を外注した人の作る もっともらしいが浅い仕事 を過度に後始末するために時間を費やさないようにしなければならない
- これを防げなければ、高業績者は自分以外の全員のための増幅器として消耗し、その結果 フラストレーション、基準の低下、離脱 につながりやすい
- A.I.時代の組織品質は結局のところ、リーダーシップが レバレッジと依存、加速と模倣、本当の能力と説得力のある出力 を継続して見分けられるかどうかに、より大きく左右される
1件のコメント
Hacker Newsの反応
この論旨は繰り返し読むほど表現の洗練さは増していくが、まだ警句の段階には達していないという印象
"the medium is the message"、"you ship your org chart"、"9 mothers can't make a baby in a month"のように、短い言葉で多くの人に刺さる文になるには、意味を削ぎ落としていく作業に何年、何十年もかかる
しかも私たちは意味形成をRLで扱う方法すら分かっていないのだから、AIがそれを代わりにやってくれることはない
元は"9 women can't make a baby in one month"のほうが正しい
自分でやりながら学ぶ。このひと言のほうが、より警句に近く見える
Intelligence amplification, not artificial intelligence は悪くない
縮めると IA, not AI になるし、スペイン語にすると "AI, no IA" になってさらに面白い
趣味と判断力はAIが生み出してくれるものではない
アメリカ人100人にこの警句の意味を尋ねたら、McLuhanの本来の意味をきちんと捉えられる人はほとんどいない気がする
AIはおおむね二つの使い方があると思う
一つは、自分が所有し理解しているコードを書く補助として使うやり方で、もう一つはAIを抽象化レイヤーのように使い、コードの作成と保守を任せるやり方
後者は、プロトタイプ、サンプル、リファレンスのように寿命が短く、コード品質や自分の理解度がそれほど重要でない場面ではよい
問題は、本当は1が必要な仕事に2を持ち込んで、自分にも他人にも嘘をつくときに起きる
速くて簡単に見えても、結局はコードベースを担保に入れるようなもので、そこから能力の萎縮も始まると思う
機能は出続けるし見た目も問題ないが、何かが壊れた瞬間、モデルにもう一度聞かない限り自分のコードすらデバッグできないと気づくことになる
現代的なIDE、メモリ管理のある言語、GitHubやパッケージマネージャーのライブラリなしでは仕事にならないエンジニアも多い
だからAIへの依存も、私にはそこまで本質的に違って感じられない
Engineerという言葉の意味自体が変わることもあり得るし、実際にWebflowやWordPressだけを使う"web developer"はすでに存在する
厳密な定義でいえば、Software Engineering分野の人の中で実際に公認エンジニアといえる人はほとんどおらず、国によっては資格や肩書きまで伴う
キャリア初期なら時間さえあればほぼ何でもやっただろうが、今はできても面白くないからやらないことが長いリストになっている
AIがSlackのサブスク程度のコストなのか、チームメンバー1人分のコストなのか、あるいはサービスが消えてAIへのアクセス権を持つ人を別途雇わなければならないのか、分からない
だからAIに依存するのは、ローカルやオープンソースのツールにもなり得るIDEに依存するのとはかなり違う
経験10年くらいの人なら、コードの流れや論理が分かっているので、AIを使ってもコードを書けるし、自分のやり方も改善できる
一方で初心者は流れや論理が分からず、ただコピペするだけになりがちなので、AIがそういう人たちに考える余地を増やしてくれるとは思えない
今のAIの使い方は、ここ20年のプログラミングより疲れると感じる
問題を投げ、提案を評価し、その中から正しい方向を選び、おかしな提案を取り除き、もう一度磨いてほぼ正しい状態にする、その過程がとくに消耗する
そのあとコーディングを1〜5時間回せば、自分でやっていたら少なくとも2〜3週間かかったはずの結果が出ることもある
だが、こうして5時間ほど計画中心で働くと完全にへとへとになり、これは純粋にプログラミングだけをしているときの疲労とは違う
何かを学んでいる気もするが、正直管理職の仕事に近い感覚もある
LLMとゆっくり問題を定義し、もっともらしい解決策を探そうとすると、ずっと集中状態を保たなければならず、以前のような没入のフローが生まれにくい
山のような出力をさばき続けながら核心を何度も選び直す必要があり、全体としては良くても、どこか微妙にずれていることが多くてかなり気に障る
LLM特有の妙なエラーや推論の欠陥のせいで高い警戒心も保ち続けなければならず、その非人間的なコミュニケーションスタイルを解釈すること自体も疲れる
ただ、pacingやprocrastinationは、人間にとって一種の圧力逃がし弁なのかもしれないとも思う
そもそも考えるのが得意でないエンジニアは多く、AIがその事実自体を変えることはできない
それがSoftware Engineeringという領域が大きく壊れてきた理由の一つであり、AIは解決できず、より大きな混乱を一時的に先送りするだけかもしれない
大学でカンニングでしのいだ人でも、見つからずに切り抜けるには結局批判的思考が必要だった
気に入らない人もいるだろうが、カンニングがうまいことですらかなりの思考力を要する
AIにどのレベルであれ思考を委ねる人は、もともとそれを価値あるものだと思っていなかったのだと思う
"use it or lose it"という言葉どおり、それを裏づける研究は増え続けているのに、ソフトウェア開発でのLLM利用は問題なく、私たちの価値は思考力にある、といった類いの文章も出続けている
別のことに完全に没頭していても、ふと解決策が浮かぶ瞬間があるのが、この仕事の美しさの一つだ
今ではAIが、そうした思考を素早く行動に変える道具になってくれる
以前は手がかりをつかむ前に流れを失うことがあったが、今ではスマホで数分のうちにその考えを部分的にでも現実にし、また元の作業に戻れる
ちょっと目を離したらアイデアを失ってしまうのではと心配しなくてよいのが、とくに大きい
今numbaを作り直しているが、これを手作業だけでやるのは想像しにくい
数年前にやってみたときは、ひどく苦しく、遅く、汚かった
何年も積み上がった抽象化の上に小さなものが延々と積み重なっていたから、なおさらそうだった
今回はLLMを使ってやり直しているが、本来なら数週間かかる仕事が一晩で終わることもある
それでもコードは自分で見ているし、生成されたCの出力も確認しているし、これから自分とLLMの両方が扱いやすいようにアーキテクチャの統制も握り続けている
これが自分の思考を代替しているのかはよく分からない
数か月かけて手で書いて直しながら耐えていたら、コンパイラやトランスパイラについてもっと学べていただろうが、そうしたらこれだけにかかりきりになっていただろう
その代わり今は、Golangでカスタムファイルシステム向けのNFSサーバー対応まで別に書く時間が残っている
今ではエージェントが機能全体に必要な変更点を見つけ、計画段階で非常に細かく分解し、実装もほぼ最初から正しくやってしまうレベルのシステムを作ってある
この1年で自分がコードを直接読むことはだんだん減っており、今のシステムに対して自分が感じている安心感が過剰ではないかと、よく自問する
非常に高い精度と成功率を何度も見てきたせいで、もはや本能的に疑わなくなっている
いつか大きく痛い目を見るだろうと待っているのに、不思議なくらいその瞬間が来ない
もちろん小さな見落としや巻き戻しはあったが、それは昔からあった
違うのは、以前は自分が苦労して書いたコードだったから、ずっと個人的な関係があったという点だ
今は問題が起きると、コードを責めるより、なぜシステムが自力で正解を出せなかったのか、あるいはなぜ実装前の計画でその全体像を示せなかったのかを、改めて掘り下げるようになった
ソフトウェアにおけるAIの最大の利点は、コードをより速く作れることだ
最大の欠点は、ものすごく速く作りたくなるよう誘惑することだ
だから個人プロジェクトではAIを使わない
頭を鋭く保ちたいからだ
AIを含むプロジェクトなら例外はあるかもしれないが、そのコードを書くのにAIは使わない
一方で会社の仕事は気にしない
マネージャーがClaudeで完全にvibe codingしろと言うならそうするだけで、その結果生まれる技術的負債のコストを払うのは私ではないからだ