- もっともらしい成果物を素早く作れるほど、理解のない反復が容易になり、判断力を鍛える練習を飛ばすと 長期的な能力 が弱くなる
- 慣れたパターンでは大いに役立つが、未知の問題、曖昧な条件、不完全な情報、相反する制約では 浅い模倣 が簡単に崩れ、実力が露わになる
- 強いエンジニアは、ボイラープレート、要約、テストのスキャフォールディング、調査の加速といった 機械的な作業 は任せる一方で、問題定義とレビュー、選択と破棄は 自らオーナーシップを持つ
- ソフトウェアエンジニアリングの高い価値はコード生産より 判断力 にあり、隠れた制約を見抜き、間違った問題に気づき、曖昧な議論をトレードオフに変える力がより重要になる
- とりわけキャリア初期と組織運営では、本当の理解 を守る基準がいっそう重要であり、何を委任し何を自分で担うかを見極めるほど、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しろと言うならそうするだけで、その結果生まれる技術的負債のコストを払うのは私ではないからだ