こんにちは！デザインエンジニアの藤井（touyou）です。
この記事はGoodpatch Advent Calendar 2025 21日目の記事になります。
弊社のアドベントカレンダーを熱心に追っていただいている方はもうお気づきかもしれませんが、この記事は20日のうっちゃんの記事とは対となるタイトルを冠した記事となります。
ある意味真逆の主張が書かれるかもしれませんが、決して仲が悪いとかではなく、むしろ一緒にエンジニアのAI活用向上施策をゴリゴリと進めている同僚なのでそこは安心して読み進めていただければと思います。
昨日の記事と対比しながら読んでいただくと、生成AIとの付き合い方についてのもう一つのスタンスとして楽しめるはずです。
というわけでこの生成AI時代に似つかわしくないタイトル「それでも僕はコードを書く」、なぜ自分がこう主張し続けるのか。
この記事では、生成AIが当たり前になった今あえて「自分でコードを書くこと」にどんな意味があるのかを、自分の経験を交えながら考えてみます。
- あの日僕はあこがれていた
- 生成AI時代の違和感
- 我々は何と戦っているのか？
- 立ち返る、コードを書く意味
- もう少し、コードを書くことの効用を考える
- ところで、プログラマーの三大美徳って...
- シニアは生成AIを使いこなせる話
- それでも僕はコードを書く
あの日僕はあこがれていた
これから論を進めていくにあたって、まず自分の経歴的なところを簡単にですが紹介していこうと思います。
さかのぼること2008年、当時中学生だった自分はあるドラマにハマっていました。それがブラッディ・マンデイです。
それまでにもヒカルの碁で囲碁を始めたり、テニスの王子様でテニスをやったりとなにかと影響されることの多かった藤井少年にとってそのドラマはあまりにも魅力的でした。天才ハッカーがその天才的な発想力で巨悪に立ち向かっていく姿に、「コンピュータってこんなことまでできるのか」と強烈に心を掴まれたのを覚えています。原作漫画にも、主題歌を歌うflumpoolにも同時にハマりだしたのですが、例にもれずプログラミングが自分の趣味のひとつになりました。
当初はCの本をそれっぽいものとして買ってもらい、すぐ挫折。その後ブラッディ・マンデイのドラマ中の演出を分析しているブログを読んでPythonを勉強しはじめます。
ただ金融業の両親や友人を含め、当時周りに教えてもらえる人なんていません。ひたすら自分でPythonチュートリアルの本の概念を理解しようと読み込み、いつしか2年が経っていました。
ここで大きな転機が訪れます。テスト順位のご褒美として初my PCを買ってもらったことと、ひとつ上の先輩の国際情報オリンピックでの活躍のニュースです。
Pythonを通してプログラミングについてようやくある程度書けるぐらい理解が進んでいた自分も、一方でそのあと何をしていいのかには何も思いついていませんでした。同い年のTehu氏のニュースを見てAndroidアプリにも挑戦してみたものの、そもそも自分がAndroidウォークマンぐらいしか持っていなかったためモチベが上がりきらず...一方で、国際情報オリンピックに行った先輩たちは中一の頃の部活で少しお世話になったこともあり、コンピューター部に入れば会える存在です。
そこで中学三年間を過ごしたサッカー部をやめ、コンピューター部に入り、そこからしばらく競技プログラミングの世界にどっぷり浸かりました。コンテストに出たり、問題をひたすら解いたりと、「書いたコードがそのまま結果になる」世界にのめり込んでいきました。
こうして数々のあこがれに影響されたとうよう少年はその後、大学・大学院ではコンピュータ科学の道へと進み、晴れてエンジニアとなったわけです。
このように自分にとってエンジニアとはあこがれであり、その中心は他でもない、プログラミングをして魔法のように何かを成すこと、そのものでした。
その軸がぶれていないということは、同じアドベントカレンダーの2日目の記事からも感じ取ってもらえるかと思います。
生成AI時代の違和感
このようにそもそもがプログラミングの力に魅了されてきた人間です。そのため、生成AI時代に繰り広げられる意見には違和感を感じることが多かったです。
「もうコードは書かなくていい」「エンジニアの仕事はもうAIに奪われた」といった極端な言説を目にするたびに、本当にそれだけでいいのか？というモヤモヤが残っていました。
そしてそこに対し、さまざまな角度でその違和感を表明してきました。例えばこちらの記事であったり、
2日目の記事でも紹介した生成AI新年会の企業LTでも実際その根底にあるのは生成AI時代の世の声への違和感です。
「生成AIに全てをあけ渡す」のではなく、「生成AIとどう共存していくか」を語りたい、というのが一貫したスタンスでした。
そしてその究極系が10日目に書いた「生産性」の解釈についての記事です。
生成AIとなにかとセットにされる「生産性」、ただその言葉のみでいろんな物事を語ってしまうとどうにも議論が変になるということで分解した解釈をするに至りました。
ここ最近になって、生成AIを本当に扱いこなせるのはシニアレベルになった人たちであって、ジュニアレベルにとっては扱うのが難しい、という論をいろんな人が言うようになってきています。ようやく自分の感覚と一致してきたなぁという感覚ではあるのですが、そうなった時に生成AIの存在って一体何なのでしょうか？
単なる効率化ツール以上のものとして語られ始めた今、その位置づけをもう少し丁寧に考えたいと思うようになりました。
我々は何と戦っているのか？
少し話の軸を変えてみましょう。生成AIを推奨するときに多く語られる生産性を向上させるという考え方、ではこの時に何のために生産性を向上させなければいけないのでしょうか？
答えは簡単で、この時代の勝負に勝つためです。じゃあその相手は？と言えば他でもない人間なんです。
同じ市場で戦う競合企業であり、同じ案件を取り合う他社のチームであり、あるいは同じポジションを目指す他の個人です。
これは弊社の社外取締役でもある広木さんも常々語っていることです。
AIの「究極論」に惑わされてはいけない。
— 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) 2025年10月26日
「10年後には何でもAIがやってくれる」
そう考えて様子見をしている間に、勝負は決まってしまう。
技術革新から社会普及まではタイムラグがある。
このギャップこそが最大のビジネスチャンス。
競争の本質は「対AI」ではなく「対人間」…
でも、待ってください。だとすれば、この勝負、なんで勝たなきゃいけないのでしょうか？
そうなった時に主語になりやすいのは会社です。他の会社より売上を立てて、お金を稼ぐために勝負に勝たなければいけません。お金を稼がないと会社として成り立ちませんからね。
同様に個人レベルにたつと、そうやって会社を勝たせることによって、あるいはそれは個人事業主としてでもいいですが、どちらにせよお金をもらって生活をするためにその勝負に挑みます。
これはもちろん生成AI時代以前にも言葉を変えてみれば成り立っていることでした。それ自体を否定するつもりはありません。
ですが、こうも思うのです。じゃあ個人として、何でお金をもっと稼がないといけないのか？と。
そもそもお金を稼ぐこと、それ自体は目的ではなく手段であるはずです。特に個人にとっては。
お金を稼ぐことで、いろんなものが買えるようになったり、豊かな生活ができるようになること、この豊かさこそが本来の目的になるはずです。その手段として今の資本主義社会ではお金が最重要ファクターになる、というだけの話です。
こう考えていくと個人としては今論じている勝負に必ずしも勝つ義務はないわけです。勝負に勝てなくとも豊かに生きれる方法を別で見つければいい、そういう考え方も絶対にあると思います。
「勝つ」ことだけが豊かさの条件ではない、という前提に立つと、生成AIの使い方にも別の選択肢が見えてきます。
ここからは、その前提に立ったうえで、コードを書くこと自体の意味を少し深ぼってみます。
立ち返る、コードを書く意味
さて、こうなった時に生成AIの活用は、数ある豊かに生きるための手段のひとつでしかない、ということが言えるようになると思います。
ただ生成AIが他の手段より大幅なショートカット手段を持っているということも事実です。その状況の中でコードを書くということはどういった意味を持ってくるのでしょうか？
まず比較対象としてプロンプトエンジニアリングもといコンテキストエンジニアリングを例にとってみましょう。コンテキストエンジニアリングはプロンプト、事前に渡す情報、生成AIの動かし方などさまざまなことを調整していくことで、生成AIをより早く正確に動かすことができる手段です。
これによって得られるメリットはもちろん価値あるものを素早く作れることです。一方で、AIは元来確率的なものなのでまだまだその方法論は確立しているとは言い切れず、今も日々モデル性能自体の向上あるいは性質の変化とコンテキストエンジニアリングをいかにして行うかということが半ば相乗効果のように、ある一面ではいたちごっこのように世界中の人が研究しているところかと思います。
同じプロンプトでも毎回同じ結果にはならないし、昨日まで効いていた工夫が明日には通用しなくなるかもしれない、そんな前提で付き合っていく必要があります。
一方で、コードを書くことはどうでしょうか。これももちろん同じ価値あるものを作る、という目的は同じなのですが、性質が異なります。
素早さで勝つのは難しくとも、書いた人間の想像力のままに出てくる、意図通りに挙動してくれるという意味での再現度というのは明らかな強みになると思います。AIとは違い決定論的なので（もちろん予測不能なバグなどは存在するものの）、書いた通りがそのまま形になります。これは一部の人間にとってはとても魅力的な事象です。
自分が書いたものが書いた通りに形となる。
つまり、何が言いたいかというと、その強みや価値はまったく違うものになるということです。
そのため生成AIが戦っている領域と同じ軸で語ろうとすると話がこじれますが、一個切り離してしまえば、コードを書くことは決して生成AIによって価値を奪われるものではなく、別の領域で価値を発揮してくれる存在であると言えます。
技術の民主化とは言いますが、コードを書くことで得られるこの価値は厳密にはAIで置き換わるわけでは無いと思います。
何より今までコードを書いてきた身からすれば、プログラミング言語は自然言語よりよっぽど雄弁であり、厳密かつ強力です。そのため、自分にとって広い意味合いでコードを書くという行為は、生成AIにプロンプトを投げて何かを作るよりよっぽど自分の人生を豊かにしてくれる行為なんです。
「自分の手で世界を意図通りに少しだけ書き換えられる」という感覚は、ショートカットしてしまうAIでは代替できないものだと思っています。
もう少し、コードを書くことの効用を考える
さて、ここまであくまで個人としての趣味嗜好に寄ったコードを書く意味というところを考えてきました。
ただそれだけだとあくまで趣味なので、もう少し影響範囲を広げてコードを書く意味を考えられないか、探ってみましょう。
自分はこの一個に手触り感というのを挙げています。これは特にUI実装の分野においての話です。
ここでいう手触り感、とは、インタラクションひとつひとつにこめる想いのようなもののことを言っています。ボタンを押したときのわずかなアニメーションや、入力中のフィードバックの心地よさ、といった「操作していて気持ちいい」と感じられる部分です。
AIはその仕組み上平均的なアウトプットをするかと思います。Gemini 3 ProやNano Banana Proあたりから「AIくささ」というのは圧倒的に減ったとは思うのですが、それでもやはり一般的に良いとされていそうなものを提供していることに変わりはないかと思います。
これは一見普通にいいことのように思えます。ですが、そこから外れたところにこそ、新しい発明やものづくりの上での魂のようなものが出てくるはずです。
「みんながいいと言うもの」から半歩だけ外れたところに、そのプロダクトならではのらしさが生まれる、という感覚に近いかもしれません。
ここは少し物理的なものに目をやってみればわかりやすいでしょう。例えばお茶碗などの食器を考えてみてください。
現代は機械によって大量に均一なものを作れるようになり、安く高品質な食器を手にいれることができるようになりました。しかし、手作業で作る食器、伝統工芸のようなものは決してなくなっていません。それどころかその貴重性から遥かに高い値段で売られていることが多いです。
単純な利便性に値段がつくのだとしたらこれはおかしな話です。化学的に利便性を考え、構造も計算し、均一に作ったもののほうが「性能」は絶対にいいはずだからです。ですが、そんな安さや利便性を抜いてでも手作業で作る食器を選ぶ人はいるんです。では、何にそんなに値段を払っているのか？
それはきっと、作り手のブランドであり、手ぐせのようなものであり、そこに感じる何かしらの温かみのようなものだと思うんです。これで網羅できているとは思いませんが、それでもそういった見えない価値というものが値段にあらわれて成立する世界があると思います。
こういった話が実際デジタルプロダクトにおいて成立している例もあると思います。直近だと例えばcatnoseさんです。
catnoseさんのデジタルプロダクトはコアアイデア自体が奇抜というわけではありません。ですが、今まで築いてきた信頼と、実際のプロダクトにおける細やかな工夫・気づかいが評価され、この人が作るものなら間違いない、という認知を形成しています。
もちろんこれはcatnoseさんが生成AIを開発に一切活用していない、という話ではありません。ですが同時に、これは生成AIがあるからできたことではなく、catnoseさんの想いがそうさせているのだと、自分としては解釈しています。
コードを書くという行為は、その「想い」や「手ぐせ」をプロダクトに焼き付けるための強力な手段のひとつだと思うのです。
ところで、プログラマーの三大美徳って...
ほぼほぼコードを書く意味というようなところはこれで語れたかなと思うので、少し視点を変えて、生成AI vs 手書きのコードで語られる話題について少し自分なりの考えをまとめていこうと思います。
ここからは少し肩の力を抜いて、「古典的な価値観」と生成AI時代の話を重ねてみましょう。
まずはプログラマーの三大美徳に照らせば、生成AIを使うべきという話です。
自分の意見に入る前にプログラマーの三大美徳について復習してみましょう。プログラマーの三大美徳とは、Perl作者のラリー・ウォールさんが提唱したもので以下の三要素で構成されています。
- 怠惰
- 短気
- 傲慢
特に怠惰、の文脈でしょうか？生成AIが推奨されるのは。ですが、自分はこれだけでだから生成AIを使うべき、という論にはならないと感じています。
元の意味を考えてみると、怠惰とは楽になる努力を惜しまないこと、短気とはやるべき作業をなるべく短くすること、傲慢は文句のつけようのない高品質なプログラムを書けることです。確かに生成AI活用を積極的にしていくことは楽になる努力にあたるかもしれません。しかしそれは一方で「ある対象においては」と注釈がつくべきだと思います。
例えば繰り返し作る似たような画面のコードがあるとします。これを楽にするにはどうすればいいでしょうか？
繰り返し、ということはその目的に立てば絶対的に同じ構造で作って欲しいはずです。これを楽にするからと生成AIに任せたらどうなるでしょうか？ちゃんと整備されていないプロジェクトではおそらく本来の意図とは違う余計なことをしてくる可能性があります。
もちろん大半はうまくいくかもしれないですが、この可能性というところが重要です。その可能性を潰すために生成AIのアウトプットを確認しなければいけません。そしてそのアウトプットは大量です。面倒です。
であれば最初から決定論的にできることはプログラムを書いてしまえばいいのです。テンプレートから決まったルールで吐き出すプログラムを一度作ってしまえば、あとは自分でそれを実行するなり、AIに実行させるなりどう扱ったとしても、確認しなければいけなかった可能性というものがなくなるもしくは低くなります。自分の手で面倒の源泉を潰しておくほうが、長期的にはよっぽど本来の怠惰っぽい姿勢です。これこそ本当の怠惰というものではないでしょうか？
短気はどうでしょう？これも生成AIで満たされるのはあくまで「ある場合においては」です。
例えばNext.jsのセットアップをする時です。my-appという名前でプロジェクトをつくりたいとします。
pnpm create next-app@latest my-app --yes
計40文字です。一方、これをAIに頼むとするとどうなるでしょうか？例えば一例ですが
my-appというプロジェクトを作ってほしい。Next.jsでこのフォルダに作成して。
となります。一見短く見えますがこれを実際のタイピング量を考えてみるとどうなるでしょうか？
my-app/toiupurojekutowotukuttehosii./Next.js/konoforudanisakuseisite.
スラッシュは英数とかなモードを切り替えるタイミングを表します。するとなんと69文字になってしまいました。
もちろん生成AIに対して頼むときにプロジェクトの作成だけ頼むというのは非常に変な話ですし、コマンドを忘れていたら検索なども入ると思うので必ずしもこれがフェアな比較とは言いません。ですが、生成AIは必ずしも作業を短くするわけではないという一例にはなるのではないかなと思います。
「とりあえずAIに聞く」こと自体がコストになる場面もある、という感覚は、意外と見落とされがちかもしれません。
最後に残しておいた傲慢ですが...これはむしろ生成AI時代には適用してはいけない美徳ですね。生成AIの生成したものが絶対的に正しくてクオリティが高いなんて無条件に信用してはいけません。せめてテストを書かせて、そのテストコードが必要十分かのチェックはするべきです。
「自分のコードなら胸を張れる」という意味での傲慢さは大事にしつつも、AIのアウトプットに対しては一歩引いた目線を持つ。そのバランス感覚こそが、これからの時代に必要な態度だと思います。
このようにプログラマーの三大美徳は必ずしも生成AIを活用する理由として適用できるわけではないと思っています。
シニアは生成AIを使いこなせる話
昨今ではシニアほど生成AIを使いこなせる、という論が主流になってきました。では、ここでいう「シニア」とはどういう状態になったらなれるものなのでしょうか？
自分がシニアだと言うつもりは到底無いですが、ここには明確な線引きがないのではないかというのが自分の考えです。
もうちょっと話の抽象度を下げてみます。我々はいつから他人のコードを見ただけで良し悪しをちゃんと判断し切れるほどの能力を持っている、と言えるのでしょうか？
もちろん生成AIのアウトプット量を考えれば全てをコードレビューしていたら間に合いません。そのためこれからの時代はインターフェイスやテストのレビューにシフトしていくという流れはあるかもしれませんが、それでも良し悪しを判断するタイミングは存在するわけです。何より「いいコード」というのは時代によって移り変わっていきます。
かつてはベストプラクティスだった書き方が、フレームワークやランタイムの進化によってあっという間に避けたい書き方になる、ということも珍しくありません。これは時間だけでなく、作るものに関するチーム編成・環境などの変化においても言えるでしょう。
もちろんそういう移り変わりを見てきて自身の中で「いいコード」の共通点を感覚として持っている、あるいは選び方をわかっているというような経験的に獲得する能力はあるでしょうが、それらが明文化され全世界で認識が一致しているわけではありません。
だからこそ生成AIのアウトプットをちゃんと保証できるよ、というのはもう美徳としての傲慢さで支えられているだけのある種脆い概念だと思うんです。そのため自分の経験がどれだけあったとしても、自分でも書いてみて、たしかにいいものだ、とその審美眼を支える経験をいろんな方法で積み続ける必要があるのかなと感じています。
シニアだからこそ「自分の手でも書けるし、AIの出力も評価できる」という二刀流であり続ける必要があるのかもしれません。
それでも僕はコードを書く
というわけで長々とさまざまな角度での自分の考えを書いてきたわけですが、ようするに何が言いたかったのかと言えば、
それでも僕はコードを書く、書き続ける
ということです。といってもこれは何も生成AIを使わないということではありません。むしろこの二つの、いわば今世の中では対立項とされているような概念も本当はそれぞれに別の目的で価値を発揮でき、共存できるというわけです。そのため現在もそうなのですが、自分はなんとなく次のような使い分けをしています。
- 仕事だけど手触り感も大事にしたい時、自分はGitHub Copilotとともにコードを書き、速度と手触り感を両立します
- 仕組みが単純でそれがあれば作業が短縮できるツールが思いついた時、自分はいずれかの生成AIに仕様を渡してTDDで作らせます
- フェーズ的に素早いプロダクト成長が求められる時、自分はより精緻に仕様を書いて生成AIに働かせます
- あるいはプロトタイプ的なものが必要な時、自分は雑に生成AIに働かせます
- 自分が極めたい、突き詰めたい技術がある時、生成AIを調査パートナーにしながら自分でコードを書きます
- 他の人に自分と同様のクオリティで何かを使って欲しいとき、GitHub Copilotとともにコードを書きつつ、生成AIにとって使いやすい環境を整備します。それは例えばshadcn/ui registry対応とか
- ドキュメントやコミットコメントなど、確認が簡単で書くのが面倒なところには積極的に生成AIを使います
このように全てはグラデーションなのです。それでもコードを書く、とこれだけ長い記事で主張している人間がこんなにも生成AIを使っていて、コードも書いているわけです。
AIは決して人間を排除するものでも人間を打ち負かす道具でもありません。うまくどこに労力をかけるべきかを見極め、本当の意味で楽をする。
この「楽」は決して作業を短縮する意味だけじゃありません。人間として今やっていることを「楽しむ」ことも含めて。
そうやって真に豊かになることを志していければなとそう思っています。
生成AIが当たり前になった世界でも、「コードを書くこと」を通じて自分なりの豊かさを選び取っていけたら嬉しいです。
余談
この記事を書き終えたところで見つけた記事があります。もともと自分が所属していた学科の周年記念シンポジウムで話題に上がり存在は知っていたのですが、noteで読めることを知らずに読めてなかった記事です。
ちなみにこの記事のことを話題にあげた当の本人がまさにアンサーソングのようなコラムを出しているので、こちらもあわせて読むと面白いかと思います。
パッと見タイトルだけの印象だと、計算機科学は永遠、の方がこの記事とリンクしそうというイメージがあるかと思うのですが、自分はむしろ計算機科学の終焉の末尾に書かれているこちらの一節に注目しました。
私事だが，まだプログラム書き，プログラムハックを楽しんでいる．与えられたプログラミング言語の機能を組み合わせ，思った通りに結果が出る瞬間が好きだからで，計算機科学者かどうかは関係ない．
このようにシニカルに自らの学問を語る大先輩でもコードを書くのが好きだし、ちゃんと楽しんでいるというわけです。
そこに身分・職業は関係ない、まさにその通りだと思ったというところです。
余談２
先ほどの余談で記事を締めようと思っていたのですが、こんなツイートを見かけました。
「I don't care how well your "AI" works」という記事から。
— iwashi / Yoshimasa Iwase (@iwashi86) 2025年11月26日
・AIが便利だから使うという話に見えて、実際には多くの人が半ば強制的にAIを使わされる環境に置かれている
・AIを使わないと不利になるような社会構造ができつつあり、選択の自由が失われつつある…
原文を読むべきだとは思いますが、わかりやすいので一旦日本語のまとめを引用させていただきました。
これはまさしくこの記事で違和感があると語っていたような話が、見方によっては現代の社会課題であると提唱しているように見受けられます。
自分は特にコードという文脈だったので、個人の趣味嗜好という価値をメインに取り上げていましたが、これを見るとやはり「便利だから」「生産性が高まるから」使うべきという一面の評価のみで議論を続けてしまうのは危険性もあるのだなと感じました。
ちなみにこの記事はレビューにのみAIを使用して、それ以外は自分で書きました。
余談３...もといおすすめの記事
これを書き上げたのが実は11月中なのですが、その結果記事を出すまでに多くの関連する記事を見つけてしまい、こうやって余談を増やし続けなければいけない衝動に駆られています。そのためここからはもう少しライトに関連記事を紹介したいと思います。
この記事は主体性や責任を手放すことの危険性をもう少し広い範囲で分析している記事になります。民主主義の根幹の論は、あまり見えてなかった本質を突きつけられて印象的でした。
先ほどの記事を読んで思い出した拙著です。本質的にコードを書くこと、の価値を今と変わらず主張しているため、ここら辺の見解が生成AI黎明期から自分個人としては一貫していることを感じていただけるかと思います。
今度はt-wadaさんから自分の主張に似た話が出てきてました。バイブコーディングはエンジニアのためのものではない、とは本当に常々自分も感じているところです。少なくとも、プログラミングに魅了された人間にとっては。
少し視点が変わりますが、たまたま社内Slackで流れてきてある意味関連するなと思った記事です。
「生成AIの生成するものは言語化された知識」とありますが、これはまさしく自分が感じていた感覚に近しいことだと思っています。記事ではその際の学習プロセスをあくまで生成AIの量を振り返ることで質に転化するというという書き方がされていますが、これはある面では正しく、一方で遠回りになるかもしれないというのが個人的な感覚です。
ここ数ヶ月で新しく参画したプロジェクトでは、生成AIでのコーディングを中心に行い、あくまで人間側は設計に徹するスタイルで進めているのですが、そうした時に自分のプロジェクトのコードベースへの理解度やスピードが自分でコードを書く時よりも何倍も遅くなっているということに気付きました。つまりこの記事の文脈で言えば、自分はコードを書くことを通して、さらにそこで該当箇所を探す・エラーを確認する・動かすといった行為を通じて言語化できない身体知を貯める活動をしており、それによって素早くそのコードベースのことを理解しいち早く馴染むということが出来ていたのだと思います。
自分もひそかにファンで登壇などでも引用させていただいていたritar さんの最新作です。一件関係ない話題のようですが、最後の方のAIがタイムラインとトポグラフィを変換する装置という話が非常に興味深く、自分がトポグラフィ的な楽しさに価値を置いているのだなと再認識させられました。
AIは「楽（らく）」ですが、トポグラフィ的な作業は「楽（たの）しい」、この違いが自分にとって重要なんだと思います*1。
Goodpatchではデザイン好きなエンジニアの仲間を募集しています。 少しでもご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！
*1:その意味では自分が謎解きの、特に最後の大謎であったり推理小説であったり、多くの情報を吟味して解くものが好きなことも通づるところかもしれません
