生成AIを使ってプログラミング、な記事が山のように転がっておるわけですが、ネットの片隅からそういう論調に冷や水をチョロチョロ放出しておこうかと思う。
全否定まではしないけど、とりあえず本職とは思えん意見に対しては容赦なく放水していきます。
まずは原理原則から
生成AIという代物の基本のキである。
あれはなあ、そもそもが確率論の技術であって、「いつでも同じように」という決定論的アウトプットには適さない、というぐらいは教科書の一行目の文言として受け取っていただきたい。
解釈やアウトプットのブレがあって良い用途かどうか、ということだな。
で、プログラミングは果たしてそのような用途かどうか。
念のため言っておくが、単に「生成AIがコードを吐いてくれたワーイ」以上の、実用レベルでの話じゃぞ。
答えは「そういう時もあり、そうでない時もある」だ。
「そういう時」というのは、まあそれこそ誰に任せても大筋は変わらない、というケースだ。
人間に頼んでも解釈ブレやコードの書き方のブレなんてのは普通にあり得るわけで、それをたまたま生成AIに任せます、ぐらいの話であれば、そこはアウトプットが元々確率論を許容しているのでOKと評価できる。
では逆に「そうでない時」とはどういう時か。ここが経験則の無い人では見分けが付かない領域であり、ここに言及してない「生成AIでプログラミング」な記事を見た時は眉に唾をべっとりと塗り付けて構わない。汚いって。
「そうでない時」というのは、大きくは以下の２パターンである。
- 変えて欲しくない部分を含んでいる時
- プログラムの基本構造を構築する時
大丈夫な時の逆パターンなので、つまりは解釈のブレが入ってもらっては困る時であって、人間が組む場合でも任せる人を厳選したいような作業の時、ということになる。
設計や要件的にクリティカルな部分だったり、ブラックボックス化しては困る場合。
既存コードを保守する場合で丸ごと書き換えられると困る場合。
生成AIで属人化を防ぎたいというハッピーケースを言ってる人は、そのプログラムを誰が面倒を見るのか、という時間軸を全く考えていない。
仕様さえ入力すればブラックボックス状態でも構わないと思ってる人は、それは丸投げ型の顧客側のセンスであって、作り手側がどのような仕組みを取ろうとも、ブラックボックス化した時点でそれは属人化と等価なのだ。
属人性からの解放＝作業者が誰であっても良い、ではない。
その中身を誰でも追跡できることこそが属人性キャンセルの真意だ。
ブラックボックス化はその真逆に位置してることをまずは理解してもらいたい。
で、仕様さえ把握しておけば、透明性は確保される、とか思ってる人は、多分モノづくりを最後まで面倒を見たことが無い人で、自分の周りは至れり尽くせりの世界が広がってると思っちゃってる手合いだろう。
仕様を形にするのがモノづくりのコアであって、そこにブレが生じるから、プログラム仕事が成立している。
何より、仕様を伝えるのが十全でないから、プログラム開発の数多のトラブルが発生するのだ。
そこはさすがに生成AIがいくら賢かろうが面倒は見てくれない。人間の言語化能力を問われるということなのだ。
プロンプトが次のプログラミング言語になるよ
でまあ、そこで生成AIビジネスしたい人は「プロンプトエンジニアリング」なる造語を生み出したわけだが、もうこの時点で倒錯を起こしていることに気付いている人もいるだろう。
おそらくはプロンプトの組み方を「差別化要素」にしたいんだろうと思う。
そしてここまで指摘したアウトプットのブレを最小化するのが生成AIの使いこなしだ、ということにしたいんだろうと思う。
しかしな、それってどういうことかを指折り順番に考えてみると良い。
解釈のブレの小さいプロンプトを書くってことはだな、プロンプト記述を定型化するってことなんだ。
生成AIが解釈しやすいような構造でプロンプトを記述するってことだ。
あのな、それを世の中では「プログラミング言語」と言うのだよ。
最終的に機械語翻訳するツールである「コンパイラ」に対して、誤解の生じないような命令を出すために編み出された構造記述言語を「プログラミング言語」と言うのだ。
実行系によっては「スクリプト言語」とか呼ばれたりもするが、含意は同じである。
つまり、生成AIでのプログラミングの実用性を突き詰めた先とは「プロンプトのプログラミング言語化」である。
確率論部分を可能な限り抑えて、設計者意図を可能な限り決定論的に反映させたければ、指折り順番に考えればこうなるしかない。
プログラム構造については定型化した構造記述によって指定して、枝葉の個別機能部分については自然言語で指定する、そういう書き方に行き着くだろう。
で、実用的な書き方が固まったとなれば、次はプロンプトベタ書きじゃなくてウィザード形式になるだろう。
構造化された定型部分はそれに合わせたUIに組み込んで、自由記述部分と分離して入力できるようにする。これでさらに決定論部分を保護する。
そこまで到達すれば、じゃあIDEにインターフェースを組み込もうよ、ということになる。
その頃にはもう「プロンプト」なんてのは裏側に隠れて意識する人は居なくなる。
で、これって何かと言うと、ソフトウェア界隈に定期的に投下されるトレンドである「設計言語」「設計ツール」そのものである。
UMLって覚えてる？
CASEツールって覚えてる？
つまんない結論だと思った人、正しい。
要するには「そういうこと」なのだ。
これまでよりはほんの少し「勝手に解釈してくれる幅」が広がったというだけで、最終的には「使える奴は使えるし、使えない奴は使えない」立ち位置は変わらず、そしてそこに「新しい技術階層」が入ってくることは無いのだ。
と言うのも、結局のところはプログラム設計的な判断が入る以上、元々プログラムを組めるだけの能力を要求されるわけだから。
行き着くところは結局こうだろう。
- 上流側には新たなツールが与えられ、活用できるテーマが与えられたり、活用できるルールや環境をロックできた現場では生産性が上がる。
- 末端でコードを書くだけの仕事はツールに代替されるものの、コードを解読したり保守したりといった職能は相変わらず珍重され、最後まで現場で戦う人は相変わらずの顔ぶれとなる。
そういう「つまんない結論」と気付いた人が、いくら何でもさすがにそろそろ増えてきてんじゃないかなあ。
だから、ブームの最後の残りカスで何とか小金を稼ごうという人が右往左往してるのが現在ってとこじゃなかろうか。まだもうちょっと早い？
次に求められる能力
んなわけで、次に求められるのはこれです。
生成AI向けに整備されるであろう設計スクリプト言語を操るための、
仕様を言語化できる能力。
いや、それ何周目？ というツッコミが入るところまでがテンプレ。
コメントを残す