このポストを見て、思ったことがあるので残しておく。

Blueskyの方にポストしているけれど、大体自分は↓のような意見。

趣味なら、本当に好きならAIに任せずにやる それだけの話でしょうよ

— thara (@thara.jp) February 20, 2026 at 4:19 PM

確かに、仕事で書く必要性は少なくなっていくかもしれない。

が、自分の場合、そもそも仕事でずっとコード書いていることなんてほぼなくて、意思決定とか共通認識合わせとかのためのドキュメントを書きまくっているので、「コードを書くことそのものが楽しい」とは思っているけれど「ドキュメントを書くことも楽しい」とも思っているので、キャリア上の不安はあんまりない。

そして、「コードを書くことそのものが楽しい」のでプライベートでも当然のようにコードを書く。
それは、他人や社会などの外部から与えられた価値ではなくて、自分自身が「コードを書くこと」自体に価値を見いだしているから。

つまり、近年はコードを書くこと自体はお金を稼ぐことの直接的な手段として扱われてきたけど、その価値はそれだけじゃないよ、ということ。
なので今現在仮に「コードを書くこと」の「お金を稼ぐことの直接的な手段」としての価値がコーディングエージェントによって低くなっていったとしても、そうじゃない価値の部分については影響はないよ、と。

では、自分自身が「コードを書くこと」自体に見いだしている価値とは何か。

OSS開発とかの文脈だと、コミュニケーション手段というのがある。違う国で生まれ育った人が、お互いネイティブ言語のことはわからなくてもコードならわかる。ただ、これも昨今のコーディングエージェントの台頭で希釈されている感覚があって、寂しさを感じている。

自分はそのOSSの文脈ではなくて、「コードを書くこと」自体が自分自身との対話であり、問題を理解するための学習プロセスであり、自らに与える試練を乗り越えることによる断続的な成長の機会、であると思っている。

自分自身との対話

ターミナルエミュレータでシェルにコマンドを打つことを「コンピュータと対話する」と表現することがある。

自分もそう考えていて、さらにターミナルエミュレータ上でvimを動かしているので、vim上でコードを書くこと自体もこの「対話」になっている感覚がある。ただし、その対話相手は自分自身。

過去、自分はどのように問題を捉えていて、どのようなコードでどのように解決したか。
今の自分はその問題をどう解釈してどう変化を加えていくか。

同じターミナルエミュレータ上でtmuxのタブをvimとシェルで行ったり来たりしながら、この過去と現在との対話を絶え間なく繰り返す。

これは自分にとってchill outや瞑想にも近い。 キーをタイプすることで指に物理的に弱い刺激が加わり、それがこの対話と一体感があるからかもしれない。

シニアが指体操を行うことで脳に刺激を与える、的な。シニアとして扱われるにはまだ早い、とは思うけど...

問題を理解するための学習プロセス

自分は、ソフトウェア開発自体を「問題を理解するための学習プロセス」として捉えている。

型定義や関数シグネチャを書き、それがコンパイルを通るかを確かめる。 テストを書き、それが具体的な問題を意図通りに解決するかを確かめる。

この、回答を出してそれに対してフィードバックをもらう、というループ自体が、自分の学習には不可欠だと思っている。

また、キーをタイプする、ということ自体も学習効率の向上に加担していると考えている。

Mind パフォーマンス Hacks には、人によって効率の良い学習が異なる、という主張がされている。

視覚、聴覚など4パターンほど挙げられているのだが、自分はそれらのパターンが複合された学習を行うと学習効率が良いことを実感している。

視覚によってコードを読む、指を動かすという運動、それらの複合によって、問題に対する理解が向上する。

コーディングエージェントだけに任せていると、この「指を動かすという運動」がごっそり減る、また問題理解のためのループが少なくなる & 運動と紐づかなくなることによって、自分の中で問題に対する理解がうまく脳に定着しない感覚がある。

成長の機会

コーディングエージェントを使っていると、学習の機会が奪われ、限られた時間の中でそれに使うには勿体無い気がしてくる。

当然、コーディングエージェントを使っていても学習し続けられる人は当然いると思うけれど、自分は今まで語ってきたように、そうではなさそうだ、というのがわかってきた。

そうなのであれば、自分は時間がかかっても問題を直視し、血反吐を吐いてでもその問題に取り組まざるを得ない。 なぜなら、問題を理解しないでおく、ということが我慢できないから。

それは、キャリアパスとか生存戦略とかを超えた、自分自身の根源的な欲求であって、それに抗うことは難しい。

モノづくり

Agentic Codingによって作れるものが増えた、という人が自分の周りには少なくない。

でも、自分はあんまりそこに魅力を感じてなくて、なんでだろうな、と考えていたら、自分はモノを完成させることに成果を置いてないのではないか、という問いが生まれた。

どちらかというと、「問題を解く」ことに重視していて、モノづくりの過程、またはモノ自体ではなくモノがどのような問題を解決するか、の方が興味が強いのだと思う。

昔、自分が開発に携わっていたプロダクトが外部要因によって日の目を浴びることがなかったことがあったんだけど、自分はそれに対してなんも感じなかった。悲しさ、寂しさ、虚しさとか、そういうのも一切なかった。

自分がプロダクトの意思決定に携わっていなかった & ビジネスモデル的に納得いっていなかった、ってのもあるだろうけど、まぁそういうことなのかもしれん。

これからのコードの書き方

Protocol-Driven Development では、Agentic Coding時代にはprotocolを書いて、それの実装をエージェントに書かせる、ということを提案した。

今は、そのアプローチも違うかな、と思いつつある。

自分が直面している問題は自分が解いて、そうじゃない問題や、その問題を解決する & 問題にフォーカスするための調査などをエージェントに丸投げできる方が良さそう。

Claude Codeとかのsub agentを活用するイメージかな。それか1タスクまるまる投げて、好きにやってもらうだけ。 たまにアドバイスを求めることもあるかもしれないけど、AIエージェントに自分が直接扱う問題のコードは書かせない、というアプローチ。

Agentic Codingというより、単にAIエージェントとの協働。 AIエージェントに丸投げするには文書化が大事なので、それに合わせて他の人に依頼するスキルも向上するから一石二鳥かも。