「Yes, and」の思考法：エンジニアの生産性を爆上げする極意

「Yes, and（はい、そして…）」—これは即興演劇の世界で大切にされている概念ですが、実はソフトウェア開発の現場でも最強のスキルです。否定から入るのではなく、相手の提案を受け入れた上で、さらにアイデアを積み重ねていく。このマインドセットを持つだけで、コードレビューやチームの技術選定が驚くほどスムーズになります。あなたの開発環境に、ポジティブな化学反応を起こしてみませんか？

いや、そうとは言い切れないかな。個人的には「もっと良い答えがある」と思ってる。プログラミングの学習にはかなりの労力が必要だし、プロレベルのソフトウェアを作れるようになるには何年もかかる。過去12ヶ月のAIコーディングの進化を考えれば、今そこに時間を注ぐのは非効率だよ。

それよりも記事が指摘している通り、現実世界とAIによるコード生成をつなぐ翻訳者になるべきだ。まだテクノロジーが浸透しきっていない産業に目を向けてみて。開発者向けにツールを作るんじゃなくて、建設、鉱業、廃棄物管理、石油・ガス、製造、物流、政府といった業界を学んで、そこでの課題とAIの価値を橋渡しするんだ。

（「まだ浸透しきっていない」というのがポイント。どこもハイテク化は進んでいるけど、未来は一様に訪れるわけじゃないからね）

「コードを書けなければ、コードを効果的に読むこともできない」という主張には、少し疑問があるな。AI主導の未来において、コードを読む能力が重要になるのは間違いないし、今よりもっと重要になるかもしれない。

でも、本当にそうかな？キャリアを始めた頃を振り返ると、学生時代にコードを書く力はすごく伸びた実感がある。でも、読む力はほとんど向上していなかった。業界で10年以上経った今、両方のスキルは飛躍的に伸びたけど、それでも経験年数から期待されるレベルまで読解力が到達しているかと言われると、自信がないんだ。

結局、読むことと書くことはそれぞれ別の（関連はしているけど）スキルであって、個別に鍛錬する必要があるんじゃないかな。人によるかもしれないけど、私の場合、コードを読むスキルが磨かれ始めたのは、それが職務として求められる環境になってからだった。

書くことを学ばずに読むことを学ぶのは可能かもしれない。逆に、読むことを学ばずに書くことだけを学ぶのは、かなり現実味があるように感じないか？

著者には同意できないな。LLMが優秀になるほど、システムを維持・進歩させるのに必要なエンジニアの数は減っていくはず。うちの会社でも、すでにボトルネックになっているのはコードを書くことじゃなくて、収益を生む新しいアイデアの創出なんだ。新機能の実装スピードは約30%向上したし、同じ人数で以前よりはるかに速くモノが作れている。この傾向は今後も続くだろうね。あと、多くのエンジニアがコードの中身を深く理解せず、AIが書いたコードをただ信用するようになっているのも気になる。

自分の子供にプログラミングを勧めるかと言えば、むしろ「プログラミングをツールとして使うような起業家」を目指すよう促すと思う。

「コーディング→プロンプトは、アセンブリ→高級言語への進化と同じか？」という例えには同意できないな。コンパイラは基本的に決定論的（デターミニスティック）だけど、今のAIツールはそうじゃないからね。

単に決定論的かどうかだけの話じゃないんだ。ソースコードとコンパイル結果の関係を形式的に推論できるかどうかが肝なんだよ。ソースコードをどう変えればコンパイル結果がどう変わるか、正確に予測できるでしょ？でも、LLMのプロンプトを少し変えただけで出力がどう変わるかを予測するのは、同じようにはいかない。

AIのランダム性を固定して決定論的にすることはできるかもしれない。でも、プロンプトに単語を一つ加減しただけで出力がどう変化するかを論理的に推論することはできない。結局、実際にLLMを動かしてどうなるかを見るしかないんだ。

それが決定的な違いだね。ソースコードの変更は結果が予測可能で論理的に追える。言語のセマンティクス（意味論）さえ理解していれば、いちいちコンパイルしてテストしなくても結果を予測できる。コンパイラ自体がコード生成でヒューリスティックな処理をしていても、基本的にはそうなんだ。

繰り返すけど、違いはコンパイラの動作を論理的に推論できるか、LLMの動作を推論できるかだ。プログラミング言語は論理的に扱えるように設計されている。でもLLM相手だと、常に実験になってしまうんだ。

C++から来た身としては、全く違う見方をしているよ。「未定義動作（Undefined Behavior）」なんて日常茶飯事だし、コンパイラの最適化だって「お祈り」に近い状態で動くこともある。メモリのアライメントやキャッシュの局所性なんて、CPUが脳内モデル通りに動くことを信じて祈るしかない世界だろ。

そういう意味では、まさに「C++からアセンブリ」の関係と同じだよ。ベンチマークを回すまで結果がわからないし、AIが生成したコードも確認するまで中身がわからない。全く一緒じゃないか！

「どういうことだよ、デバッグビルドでは動いてたのに、なんでリリース版でクラッシュするんだよ！」みたいな経験、誰でもあるでしょ。

プログラマーはコンピュータプログラムを作るものだ。LLMはプログラムを作るコストを下げ、効率化する。結果としてプログラムの数が増え、プログラマーの需要はむしろ高まるんじゃないかな。10年後にプログラミングがどうなっているかは誰にもわからないけど、高性能なコンピュータへの需要が減る理由なんてあるだろうか？

数年後にはLLMが進化して、人間がソフトを作る時の言語は「自然言語」になっていると思うよ。アセンブリ言語を書かなくて済むようになったように、高レベルなプログラミング言語もLLMが抽象化してくれるはず。だから、プログラミング言語そのものを学ぶ重要性は薄れていくんじゃないかな。

ただ、ネットワークや暗号化、セキュリティといったコンピュータサイエンスの理論や概念を学ぶことは、将来ソフト開発者を目指す人にとっては依然として重要だと思う。

結局はアーキテクチャだよ。それが正解だ。今のモデルは良いコードを書くし、エッジケースの想定や計画立案もかなり上手い。でも、成功するソフトウェアプロジェクトには「その仕事に最適な構成要素（原子）」を選ぶ力が必要なんだ。

コード量があまり問題にならなくなることで、そうした判断基準は少し変わるだろう。来年や再来年には、モデルがより良いアーキテクチャの選択肢を提案できるようになるのは間違いない。でも現状では、実際に高負荷なシステムを構築するには、まだ人間の設計者が不可欠だと思う。

良いソフトウェアとは何かを理解している人間なら、AIというエージェントを使いこなせる。でも、その知識がない人間には、まだ高品質なシステムをゼロから構築することはできないよ。

「自分が書くのが好きじゃないコード（正規表現とかCSSとか）をAIに生成させる」って言うけど、それって「それが好きなチームメンバーに任せるべき」っていう反論にならないかな？

個人的には、物理科学の方がより価値がある気がするね。問題を具体的に、あるいは抽象的に解くことができるし、哲学みたいな分野も含めてね。