- AIコーディングツールの登場により、深く思考する経験が急激に減り、エンジニアとしての成長が停滞しているように感じている
- 自分の中にある**「ビルダー（Builder）」と「シンカー（Thinker）」**のうち、ビルダーはAIのおかげで満たされる一方、シンカーは飢えている状態
- **「バイブコーディング」**によってアイデアから現実へ素早く移行できるが、創造的な問題解決の機会は大きく減少
- AIが70％程度の「十分に良い」ソリューションを提供すると、実用主義的な性向のため、それを拒むのが難しい
- コーディングの外で深い思考の満足感を探そうとしたがうまくいかず、二つの欲求を同時に満たせるのか不確かな状況
思考の欠乏に対する問題提起
- この記事を読む前に、**「最後に本気で考えたのはいつか」**を思い返してみてほしい
- これは解決策や助言ではなく、単に最近感じているもどかしさを吐露する文章
ビルダー（Builder）とシンカー（Thinker）という二つの性向
- ビルダー（Builder）: 作り、リリースし、実用的な結果を出そうとする性向
- 速度と有用性によって動機づけられる
- うまくデプロイできたときのドーパミン、実際の問題を解決するシステムを作る満足感、誰かが自分のツールを使っているという事実から喜びを得る
- シンカー（Thinker）: 深く、長期間にわたる精神的格闘を必要とする性向
- 物理学を専攻していた大学時代、平均的な難度をはるかに超える課題問題が出されていた
- 概念を理解していても、そもそものアプローチ自体を思いつきにくい問題が存在した
難しい問題に直面した学生の三つのタイプ
- タイプ1（多数派）: 何度か試したあと諦め、教授やTAに助けを求める
- タイプ2（研究者型）: 図書館で似た問題やヒントを探し、解ける状態まで持っていき、おおむね解決に至る
- タイプ3（シンカー型）: ひたすら考えるという方法だけで取り組む
- 数日から数週間にわたり、non-I/O状態の脳の時間をほぼすべて問題解決の可能性に費やす
- 眠っている間も思考が続く
- この方法は一度も失敗したことがなく、深く長く続く思考こそが自分の強みだと認識していた
- 上位1％のように速いわけでも、生まれつきの才能があるわけでもないが、十分な時間さえあればどんな問題でも解けるという確信があった
AIとの葛藤
- ソフトウェアエンジニアリングが当初あれほど満足感を与えてくれた理由は、まさにこの二重の満足感にあった
- ビルダー（役に立つものを作り、生産的で実用的だと感じる）とシンカー（本当に難しい問題を解く）の両方を満たしていた
- エンジニアとして最も大きく成長したプロジェクトには、常に創造的な解法を必要とする難問が数多く含まれていた
- しかし最近では、ひとつの問題に何時間も向き合って真剣に考えることが急激に減っている
- この一連の事態の原因はAIにあると思っている
- 以前にも増して、より複雑なソフトウェアを書いているのに、エンジニアとしてまったく成長していないように感じる
- 「停滞している」と感じる理由を振り返ると、シンカーを飢えさせていることに気づいた
- 「バイブコーディング（vibe coding）」は間違いなくビルダーを満たす
- アイデアがごく短時間でそのまま現実として実装される過程には、即時的な快感がある
- その一方で、技術的な問題に対して自分で創造的な解法を考えなければならない瞬間は大幅に減った
- 純粋にビルダー気質の人にとって、この環境は最適な時代だ
- だが、自分には明らかに何かが足りない
実用主義の罠
- **「バイブコーディングで解決できるなら、その問題はもともと難問ではなかった」**という反論は予想している
- しかし、それは本質を外した主張だ
- AIは難しい問題に特別強いわけでもなく、簡単な問題でも常に良い解法を出すとは限らない
- 同じモジュールを三度目に自分で書き直すなら、AIが出したどんな結果よりも良いものにできるという確信がある
- だが同時に、自分は実用主義者でもある
- ごくわずかな時間と労力で「十分近い」解法が得られるなら、AIを選ばないほうがむしろ非合理的に感じられる
- 本当の問題は、この実用主義を意識的にオフにできない（無視できない）ことだ
- 本質的に自分はビルダーであり、何かを作る行為そのものが好きだ。より速く作れるなら、そちらのほうがいつでも良く感じられる
- AIを拒み、シンカーの欲求がコーディングを通じて自然に満たされていた時代へ戻ろうとしても、ビルダーはその非効率に耐えがたい
- AIはほぼ確実に100％満足できる解法を示してくれるわけではないが、到達する70％水準の解法はたいてい「十分良い」という基準を満たしてしまう
これからどうすべきか？
- 正直なところ、まだ答えは見つかっておらず、考え続けている
- この二つの性向が、コーディングという一つの領域の中で今後も同時に満たされうるのか、自信が持てない
- より難しいプロジェクトを目標にして、AIが完全に失敗する問題を意図的に探すという選択肢はある
- 実際、ときどきそうした問題に出会うことはあるが、深い創造的解法を必要とする問題そのものが急速に減っているように感じる
- コーディングの外で精神的成長の感覚を取り戻そうとする試みもしている
- 物理学とのつながりを取り戻すため、古い教科書を開いてみたりもした
- しかし、それは実質的な満足にはつながらなかった
- 何かを作れる状況にあるとき、現在と直接関係がなく、最新でもない物理の問題に時間と精神的エネルギーを使うことを自分に正当化しにくい
- ビルダー気質は、ただ座って未解決の問題を抱えたまま思索する状態を許してくれない
- シンカー気質は、バイブコーディングが続くあいだ、飢えたまま残されている
- 二つの欲求が再び同時に満たされる時が来るのかについては、自信が持てない
「今や私たちは、この存在に対して、いかなる想像力の力も、どれほど大胆な幻想の跳躍も、どれほど敬虔な信仰心も、どれほど深遠な抽象的思考も、恍惚に沈んだ精神でさえも、決して到達しえなかったものを常に指し示してきたあの馴染み深い名を与える権利を得た。神（God）。しかしこの根本的な統一性は過去のものであり、もはや存在しない。それは自らの存在を変容させる過程で、自分自身を完全に、徹底的に粉々に砕いてしまった。神は死んだ。そしてその死こそが世界の生命であった。」
— Philipp Mainländer
9件のコメント
ただの勘違いでしょ。素早く実験できることはやりながらデータを積み上げるほうが得なのに、あ〜知らない、私は理論派だから〜って言うのと何が違うの、って笑える。
これまで現実化できず証明されてこなかった自分の理論が、まったく役に立たないものだと証明された状況に対して泣き叫んでいるようにしか見えない。
本物の thinker だったなら、この状況でどんな問題を解くべきかを AI を通じて見つけて、より良い解決策を探し出すために「今でも」悩んでいるはず。
敬意ある態度が込められたコメントではないように思います。
AIが作ったコードをより良くするために、追加でビルドとシンキングを並行して行えばいいのではないでしょうか？
エンタープライズ級の巨大なシステムで適切な処理モデルを選定し、パイプライン方式を選ぶ過程では、依然としてAIは完成度の面で物足りなさを見せているので、アーキテクティングに目を向けてみるのがよさそうですね。
もちろん、それもどれだけ続くことやらですが……
難しいアルゴリズム問題を解くことで欲求を満たして、ビジネスは実用的にアプローチするしかないというか、まあ方法がないですね
機械が服を編む時代にも編み物があるように、趣味としてのコーディングもできるのではないかと思います
極めて個人的な考えではありますが、
ビルダーとシンカーの楽しさをチェリーピッキングできるのではないかと思います。
今では、完全に低コスト（少ない時間）で動く何かを作り出せますし、
ユーザーがそれを使ってくれることから来る喜び、実生活の問題を解決したという喜びを得ながら、
節約した時間で深く考えるべき問題に時間を注ぎ込めるのなら（実際にそうしていますが）、
それはそれで意味がありますし、楽しさもあるのではないかと思います。
Hacker News のコメント
2025年3月の Aral Balkan の投稿が印象的だった
コーディングは泥の塊をこねて、望む形に整えていく過程に似ている。この過程で素材の限界と特性を学ぶことになる。
作る前の段階こそ、自分が何を作りたいのかを最も分かっていない時点でもある。デザインは単なる問題解決ではなく、正しい問題を見つけることでもある。
創作の過程を飛ばしてしまうと、学びと発見という人間的な要素が失われる。自分でこね上げた作品は隅々まで理解しているが、自販機から出てきた成果物は、見た目だけ似た模造品にすぎない
新しいアイデアであるほど、ツールはそれを「正常化」しようとするので、その抵抗に打ち勝つ努力が必要になる。
この過程で、自分のアイデアが何であり何でないのかを明確に定義することになる。押し返すのをやめた瞬間、LLM がプロジェクトの独創性を覆い隠してしまう
既にあるツールを組み合わせて新しいものを作るのが自分の仕事だ。
創作過程を飛ばしたからといって、作品の価値が下がるわけではない。
たとえば、Zelda が Havok 物理エンジンを使っていたり、Unreal で作られたゲームが素晴らしくないわけではない
ここ3週間、Codex、Claude、テストセッションを併用して作った成果物には誇りを感じている。
昔はアイデアを実現することが目標だったが、今は顧客満足と納期・予算の順守が目標だ
そうすれば、数千個の部品から成る複雑なシステムも作れる。
昔はこうした役割を会社組織が担っていた。つまり、上層部が仕様を出し、下層部が部品を作るという形だ
昔は Ruby on Rails で作られたサイトはすぐに見分けがついた。
媒体の特性を理解しないまま人やエージェントに仕事を任せると、きれいなコードと保守不能なコードの差が生まれる
結局のところ責任は指示する側にある。媒体の経験がなければ、結果を評価する準備ができていないということだ
私は単にタイピングが減っただけで、今も同じように考えている
ツールが良くなっただけで、プログラミングは今でもプログラミングだ。
ラクダで砂漠を渡ろうがヘリコプターで渡ろうが、結局旅は旅だ。
ツールが進歩したからといって、本質が変わったわけではない
異なる経験が共存しうることを忘れているようだ。
「考えたくない」というコメントが特に印象的だった
抽象化の次の段階に進むのはよいが、その過程で失われる価値も認めるべきだ
LLM は単なるツールの進化にすぎないが、細やかな思考過程が失われるのは惜しい
むしろ他人に仕事をさせてレビューする行為に近い。
プログラミングが嫌いだった人には歓迎されるだろうが、これを「プログラミング」と呼ぶことはできない
自分でコードを書くとデータ構造が頭の中に描けるが、エージェントに任せるとその感覚が消える。
理解なしにコードをコミットすることに、私には価値を感じない
LLM ベースのコーディングを既存の抽象化と同一視するのは誤った比喩だ
コンパイラやフレームワークは漏れのない抽象化を目指すが、LLM には本質的に漏れがある
結局、バグを見つけて直すのは依然として人間の役目だ。
LLM は、私たちが避けようとしていた不確実性とリスクを再び持ち込んだともいえる
プロンプトにすべての変数を明示しなければ、平均的な成果物が出てくる。
自然言語がこうした情報を保持するのに適した手段なのか疑問がある
これは抽象化ではなく、非決定的なコード生成だ
そういう点で、LLM は人間の思考様式にも違う作用を及ぼす
私は**考える人(thinker)なので、AI コーディングにはあまり興味がない
OS カーネルやグラフィックスエンジンを自分で作ることが楽しい。
結果よりも、問題を解く過程こそが私の趣味でありやりがいだ
一方でビルダー(builder)**たちは、AI によってより速く作れることに熱狂している
すべてのエンジニアは考える人であり、単にツールの目的が違うだけだ
何十年もコーディングしてきた立場からすると、AI ツールは自由を与えてくれる
昔なら試すことすらできなかったアイデアを素早く実験できる。
そのおかげで、短いすき間時間を使って個人プロジェクトを進められる
AI のおかげで本当に考えるべきことに集中できるようになった。
今ではシンギュラリティが近づいていると感じる
失敗しても学びになり、成功すれば品質検証に集中できる
「考えること」にもいろいろな形がある
集中的に没入する思考もあれば、背景でゆっくり熟成する思考もある。
どちらも深い没入の一形態であり、AI 時代には失われやすい部分でもある
数学的な問題解決、哲学的思考、実務における複雑な制約など、それぞれ異なる知的な緊張感を与えてくれる
結局重要なのは、どんな形であれ深く没入する経験なのだ
周囲のシニアエンジニアを見ていると、二つのタイプがいる
わずかな生産性向上を得た一方で、思考の深さが薄れた人たちもいる
LLM が示した答えをそのままコピペすることが多い。
本当の問題は、正しく質問を投げる能力の欠如だ
成熟したシステムほど、この割合は 90% 以上を占める
同僚エンジニアたちが AI に熱狂し、職業の本質を売り渡してしまったことが残念だ
私たちは生産手段を持っていたのに、自ら手放したようなものだ
AI によって開発が安く速くなれば、むしろ市場は大きくなるだろう
技術の進歩は常に特定の職種を不利にするが、社会全体の進歩をもたらす
かつて私たちが自動化によって他産業の仕事を減らしてきたように、今その順番が私たちに回ってきただけだ
その結果にあるのは空虚さだけだ。だが彼らにとっては、それすら目的だったのかもしれない
**「できるからやる」**という発想が、人間性を失わせる
AI が思考をなくすのではない。凡庸な会社と凡庸な思考様式が問題なのだ
本当に思考を重視する会社を探すべきだ
私も LLM でコーディングしているが、それでも深く考えている
設計、リスク、制約、技術的負債、代替案などを考えている
さまざまな文脈を行き来しながら管理する「マネジメント型の思考」に近く、
数日間ひとつの問題に没頭する科学者型の思考とは異なる
特に AI を使うジュニアの PR はより長く複雑になり、
今では私の仕事の大半がレビュー中心に変わってしまった
高速なプロトタイプ、ヘルパー関数、コード自動補完、ライブラリ探索などで役立つ
むしろ単純作業が減ったことで、より多く考えるようになった
以前はコードを書くことが上位の設計思考を振り返るきっかけになっていたが、
今ではその過程が減り、『以前ほど深く』考えなくなっている
1、2番のタイプはとっくに見込みがなく、
資質のないプログラマーで、
ただ職業意識だけでとどまっている人たちにこそ
危機感を覚えるんだろう……もともと考えること自体を面倒くさがる
連中なんだから。
3番のタイプにとっては歓迎すべき贈り物だよ。
3番のタイプはもう十分に活用しているんじゃないか？
新しいツールが出てきたら、嬉々としてうまく使うものじゃないか？
自分は最初にwin32コードを試してみた。
でも案の定……Automation Interfaceレベル
だった。
こんなもので、すでに質の高いソフトウェア設計は無理だと思った。
これを最大限に活用する方法を考えたんだ。
でも、このレベルでも使い道は多い。
これも結局、考えて悩めば手足がもっと増えるようなものなのに……そう考えることすらしないのが問題だと思う。
週5日の勤務日のうち1日は勤務時間中だけLLMを使わず、日曜日はまったくLLMを使わないようにしていますが、十分やっていけます