主に日常的に VSCode で Github Copilot を使っているだけです。 AI支援のコーディングはさまざまあるので、 それらを試した上で書いているわけではない。
今のところ、自分にとって AI支援コーディングツール は超偉大なラバーダック（ Rubber duck debugging ）です。 しかし、ラバーダッグとコード支援AI（ここでは主に Claude 3.7 Sonnet Thinking などを想定）が違うのは、こちらのあいまいな（または適当な、またはいい加減な、または的外れな）問いかけに具体的なコードと説明で回答してくれること、そして何より圧倒的に豊富な知識を持っていること。
一方で今騒がれているバイブコーディング界隈のような AIまかせなコーディングはおそらく流行らないと思う。 今までもノーコードなど非プログラマ向けの技術はあった。 （そして、それは流行っていないと思う。） もし自然言語で指示（プロンプト）して、 AIが作り出したコードを動かして問題が解決するのであれば、 それは機能すると思う。 コードを人間が修正する必要がなければ。 その範疇におさまるものがどのくらいあるのだろうか？
それなりにたくさんあるのかもしれない、とは思う。 コードはかけない（かきたくない）がコンピュータに仕事をさせたいというニーズは 表計算ソフト（ VisiCalc や Lotus 1-2-3 ）登場の頃からあった。 生成AI登場以前でも MS エクセル でノーコードやローコードでたくさんのことができた。 生成AIによるプログラミングはその可能性を大幅に広げる（表計算とかいった枠組みはとりはらわれて、自然言語による対話で）ものなのかもしれない。
長年コードを書いてきた実感として、コードは書くより読む方が難しいということ。 自分が書くことができるレベルのコードは、読むことができる。 しかし自分のレベルを越えた表現のコードや、 コード表現はともかく、 そもそもそのコードの背景にある概念とか世界感を理解していなければ コードを読むことは不可能になる。 これは、2D/3D プログラミングで対象オブジェクトを操作（回転／変形とか？）することを考えてみればわかる。 つまり、AIが生成したコードを読むのは（ものによっては） かなり難易度があり、そしてそのコードを意図通り作動するように修正するのはもっと難易度があがることになる。
とはいえ、AIはコードの解説もしてくれる。 だから、コードを読んで理解することの助けになることも確か。 そうやって人間（プログラマ）が高速に学んでいくのが先なのか、 AIがそこから学んで自らコードを修正していく世界が先にくるのか。 バイブコーディング方式は、ちょうど、画像生成AIで細部の微調整まで、ひたすら・・・あくまでプロンプトで直していこうという姿勢に近い。 絵の技術があり、細部は直接人間である絵師が直すのが速いのか、 AIにまかせた方が速いのか。
そのように考えていくと、課題のひとつは AIと人間との意思疏通をどうするかという問題なのかもしれない。 言ってくれれば直しますよ（AI） vs どう言えば伝わるんだ（人間）との戦い。そして、人間側の世界観とか対象に対する理解度合いが試されることになる。つまり、画像生成AIのアナロジーを続ければ、「芦雪の犬みたいな可愛さ」をこれに適用してほしい・・・という場合、 そもそも「芦雪の犬（の可愛さ）」に対して人間とAIがともに共通の認識を持っている必要がある。
このあたりが魂のない生成AIジブリ画像増殖の原因かもしれない。 これを書いているのが2025年の4月。来年になったらまた状況はかわるのであろう。