プログラミングは今が一番楽しい
AIコーディングの進化に伴い、特に2026年に入ってから、プログラミングに対する自分の見方がかなり変わってきました。現時点で考えていることを、いったん記録として残しておきます。あとで振り返ったら面白いと思うので。
なお、この記事はAIによる「てにをは修正」「タイポ修正」などの校正は入っていますが、内容そのものはすべて自分で書いています。
初めてのプログラミングは面白くなかった
Hello World を初めて書いたのは大学1年生のプログラミングの授業でした。SNSを見ていると「小学生から書いていました」という人も結構いますが、私はそういうタイプではありません。
大学の授業で最初に学んだ言語は Java。最初はマジでわからなかったです。そもそもプログラミング以前に、PATHを通すための環境変数の設定で詰まりました。MacとWindowsを両方使っていたこともあり、特にWindowsの設定画面 + DOS画面と格闘していた記憶があります。
この時期は「プログラミングが面白い」とはそこまで思えていませんでした。CLI上で for や if の分岐を書いて System.out.println() で出力するだけだと、あんまりテンションが上がらなかったためです。
プログラミングが面白くなる転機は研究室だった
転機になったのは大学3〜4年生の頃、研究室に所属してゼミのプロジェクトに携わり始めてからです。企業連携の取り組みがあり、プログラミングで現実世界につながる、誰かの役に立つものを作れる機会を得ました。
この頃から、プログラミングが一気に面白くなりました。プログラミングをはじめとして情報科学全般をもっと学びたいと思い、本気で勉強し始めました。CPUの仕組み、オペレーティングシステム、ネットワーク、データ構造とアルゴリズム、他にもGoF のデザインパターンを初めて学んだのもこの時期です。いま振り返ると、デザインパターンを使いたくて使う、みたいなひどい設計もかなりやっていました。卒論で書いた Chain of Responsibility は、間違いなく不要でした。
その後、大学院ではコンピュータネットワークの研究室に所属しました。研究領域はオーバーレイネットワークです。インターネット上で別のネットワークを組み、その上で最適なルーティングを行うような研究をしていました。この時一番書いていたのは C++ です。他にもちょっとしたスクリプトは Ruby で書いていました。C++はかなり大変でしたが、深夜まで悪戦苦闘して動いた瞬間はアドレナリンが出まくっていた記憶があります。
社会人5年目でもう一度コードにのめり込んだ
社会人になって最初は、いわゆるシステムエンジニア寄りの仕事だったので、オフィス系のドキュメントと向き合う時間が多かったです。プログラミングは本業では5%もなかったと思います。
ただ、思うところがあって5年ほど経ってからグループ内の別会社へ転籍し、ひたすらコードを書く仕事に移りました。ここが2回目の大きな転機でした。学生時代に感じた「プログラミングが楽しい」という感覚が、はっきり戻ってきました。
当時は会社の費用で技術書を買える制度もあり、技術書を読み漁っては、そこで得た知識を実装に応用する日々でした。気づけば、帰る時間が遅くなるくらい夢中で書いていました。
だいたいクラウドが浸透し始めた頃です。自身は WebRTCプラットフォーム開発をしていて、バックエンドやインフラを中心にクラウドを使って設計、構築していたのは本当に面白かったです。同時期に、（多分rebuild.fmで知った）ChefやAnsibleから冪等性という言葉に感銘を受けましたが、運用するにつれて現実の厳しさを知り、もう全部 disposable が一番だと思ったのもこの頃です。
DevOpsのチームに所属していたので、開発だけでなく運用にも携わっていました。この時は厄介なバグもたくさん経験しました。あまり詳細には書けませんが、たとえばグローバル分散環境でネットワークレイテンシーが絡む問題を解決できた瞬間は、いまでもよく覚えています。
その時の本番環境でしか再現してくれない不具合を切り分けながら潰していく過程は、しんどいけど最高でした。切り分けするにつれて原因がだんだん見えてきて、仮説を検証しながら修正して実際に動いた瞬間は最高なんです。
マネジメントに寄るほどコードは遠ざかった
その後、やりたいことが変わっていったこともあり、徐々にポジションが変わって、マネジメントに近い仕事へ移っていきました。その過程で私自身の興味の変遷もあって、一時期は人事も経験しています。そして直近では R&D のエンジニアマネージャーを担当していました（プライベートの事情もあり、2026年1月末まで。現在は休業中）。
エンジニアリングマネジメントの仕事に携わると、実際にコードを書く時間は激減します。業務で必要なら書くこと自体はできますが、チームや組織全体のパフォーマンスを最大化しようとすると、少なくとも私の場合は、どうしても実装以外に時間を使う比率が高くなりました。
ただし、プログラミングの時間が完全にゼロになったわけではありません。機械学習のちょっとした勉強や検証でPythonを書いていましたし、他にも大学の非常勤講師として PWA や Flutter を教える機会もあり、一定量は毎年書いていました。
この時のプログラミングも面白いと言えば面白いのですが、やっぱり本番環境に対して書いている時に比べるとちょっと物足りない感じはありました。プライベートで作りたいものもありましたが、家族との時間を優先するポリシーでまとまった時間も取れないので、タスクリストに積まれたままでした。
ただこの状況が変わり始めます。
Claude Codeから始まった進化の傾き
1年弱前、Claude Code を触り始めました。Claude Code以前のAIコーディング体験は、主に GitHub Copilot の「Tab で補完する」スタイルでした。それはそれで便利でしたが、Claude Codeを初めて触った時に「これは一線を超えたな」と感じました。
もちろん、かなり厳しいコードも出てくるので手直しも必要で、まだ人の関わる余地はかなりありそうだなと思っていました。
ただ2026年に入ってから、最新のLLMを使った Codex App や Claude Code、Antigravity を触るにつれて、さらにもう一段変わった感覚があります。もちろん、以前と同様にまだうまくいかないことも多いし、手直しが必要なこともあります。でも「ここまで書けるなら十分に使える」「これぐらいで十分では」と思える場面が明確に増えました。
この感覚が本記事のタイトルにつながっていきます。
結局、いまが一番楽しい
AIコーディングでの体験を重ねるにつれて、結局何が言いたいかというと、ものづくり、そしてプログラミングそのものが、いまはめちゃくちゃ楽しいということです。
思いついたものをすぐ形にできる感覚は、過去と比べても段違いです。以前は「何か作ろう」と思っても腰が重かったのですが、最近は「ちょっと作ってみるか」くらいの軽さで始められる。この変化はかなり大きいです。ライフステージが変わるにつれて、まとまった時間を取りにくくなる中では特にそう感じます。
もう1つ楽しくなった要因は、様々なものの学習ハードルが劇的に下がっていることです。難解な技術や概念にぶつかっても、今は LLM と議論すれば、かなり短時間で理解の足場が作れます。また、NotebookLM のようなツールもあり、プライベートの片手間にマルチモーダルでの学習もできるようになっています。これも、学習のハードルを大きく下げてくれています。
プログラミングを始めてから20年以上経つわけですが、プログラミングそのものが一番楽しいのは現在になりました。バグと悪戦格闘する時間は確かに減っていますが、実際に何かを作って物が動いた瞬間をすぐに体験できるのは、やっぱり最高です。
これから確実に変わること
約1年前、ティム・オライリーが The End of Programming as We Know It を書きました。オライリー氏の記事を（恣意的ですが）ざっくりまとめると、以下のようなポイントになると思います。
- プログラミングの「終わり」ではなく、かつてアセンブリから高級言語へ移行したのと同様に、AIという新たな抽象化レイヤーによる「進化」である
- AIがコード記述（How）を支援することで、人間は解決すべき課題や設計（What）により集中できるようになり、開発の民主化と生産性向上が加速する
- 過去の技術転換と同様、この変化は開発者の職を奪うものではなく、AIを使いこなすことで新たな機会やより高度な役割を創出する
AIによってソフトウェアエンジニアの作業が減るという記事もよく見ますが、以前と同じような役割のエンジニアの仕事が減るだけであって、AIコーディングのオーケストレーションエンジニアといったような役割がどんどん増えていくんだと思います。
また、組織設計もかなり変わるはずです。これまで主流だった2pizzaチームの形も、AIネイティブな前提で再定義されると思います。従来のプロダクトトリオ（PM、デザイナー、エンジニア）の分担も確実に変わるでしょう。
マネージャーにとってもかなり面白い時代です。少人数でAIを前提にプロダクトを作るチームは、スタートアップだけでなく大企業でも増えていきます。現状の組織は、おそらく従来型の構成やプロセスで動いているはずです。今後は将来からバックキャストして、AIネイティブな組織・プロセスづくりを積極的に先導していく動きが必要になり、マネージャーが大きな役割を果たすことになると思います。もちろん役割の中には、変わるものもあれば、変わらないものもあるでしょう。前回の記事は、それでも変わらないものがあると考えて記しています。
何もわからん
これまで私は、ソースコードレビューやステークホルダー説明をはじめとした人間の役割は長く残るだろうと思っていました。一定は今後も変わらない部分はあると思います。人間の信頼貯金は偉大です。
ただ最近は思ったより早く変わっていくだろうなと思っています。たとえば、レビューそのものも専用エージェントの精度が上がっていき、実用上かなりの範囲を担えるようになるのではないか、と感じるようになりました。そもそも人間のレビューにも見落としや設計上の抜けは当然ありますし、人間は完璧ではありません。高性能なLLMがこの領域を大きく置き換える可能性は十分あると思っています。
ちなみにOpenAIでは 「OpenAIのエンジニアの95%がCodexを使用しており、すべてのコード変更はAIによってレビューされるという徹底した活用が行われている」（95% of engineers use Codex. 100% of our PRs are reviewed by Codex）だそうです。
もう1つ、最近のプロダクト開発では「今できること」だけを前提にしないほうがいいと感じています。半年後、1年後にAIがどこまで進化するかを見込んで設計する。その視点が、実際の戦略に入ってきています。
などといろいろ書いてきましたが、この1年の界隈の進化速度を見ていると、10年後は本当に何もわからんなと思います。
現時点で、「AIはまだまだ」「人間のほうが良いコードを書ける」という声があるのも事実です。私もその指摘自体は理解できます。ただ同時にクラウドがおもちゃ扱いされていた頃を思い出します。前提は想像以上に速く更新される。現時点の限界よりも、半年後・1年後に何が可能になるかを想像して課題設定、および意思決定したほうがよいと考えています。
あともう1つ、「最終的に責任を取るのは人間」という話もよく出ます。説明責任の観点から見れば、その通りだと思います。ただ、それがどこまで、どの形で続くかは正直まだわかりません。AIが作った説明の方が真っ当だな、と思うこともあるからです。「ハルシネーションがーーー」という声もありますが、人間もハルシネーションをたくさん生み出しています。
最後に
約20年前、Java の環境変数で詰まっていた頃の自分に、「2026年には、こんな速度で作れる時代になる」と言っても、たぶんまったくピンと来なかったと思います。
でも、実際にいまはそうなりつつある。良くも悪くも変曲点に立ち会えているのは、すごく面白いことだと思います。さて、来年の今頃に記事を読み直したら、自分がどんな感想を持つのか、楽しみです。