プログラミングは特別ではない
出版も絵画も音楽もAIに反発しているのに、プログラマーは疲れながらも使い続けている。Glyph Lefkowitzは、プログラミングもまた芸術であり、ありふれた受託仕事こそが腕を磨く場だとして、それをAIに丸ごと任せる損失は節約分をはるかに超えると論じる。
日本語
コピー
クリエイティブな仕事
作家たちは「AI」からの保護を求めてストライキを行った。何千人ものアーティストが「AI」への抗議の公開書簡に署名した。クリエイティブ業界の団体がAIに対して起こした著作権訴訟はあまりに多く、専用のウェブサイトまである。人気YouTuberは本当に嫌っている。彼らがミュージシャンでもあるなら、なおさら嫌っている。あらゆるクリエイティブ業界で、この技術を拒絶しようという一致した動きがある。
しかし、クリエイティブな分野の中でもほぼ唯一、多くの経験豊富なプログラマーは、プログラミングに「AI」を使うのは問題ないと今も確信している。私たちも嫌ってはいるし、それが私たちをみんな不幸にしているし、業界に何をもたらしているかも分かっている。それでも使っている。
この諦めを正当化する理由の多くは、プログラミングは芸術ではないから、というものらしい。ツールが仕事を片付けてくれて、その仕事がただ機能的なものなら、何が問題なのか。
問題はある。AIを芸術の制作に使うべきではないからだ。そしてプログラミングは芸術だ。
芸術は平凡でありうる
プログラムは表現的ではなく機能的だから芸術にはなりえない、と言う人はいる。プログラムは日常的で、芸術は超越的だと。
これは芸術が実際に何であるかについての歪んだ理解に基づいている。
John Bergerの『Ways of Seeing』で、彼はこの種の歪みを「神秘化」と名づけている。彼が挙げる例は面白く、かつ分かりやすい。ぜひ全文を読んでほしい。
要約するとこうだ。Bergerは、依頼を受けて描かれた集団肖像画を美術史家が描写する際の華麗な文章を批判する。「深く輝く黒の繊細な変調」「調和のとれた融合」といった表現を含み、その肖像画はほとんど恍惚とした言葉で崇高なものとして語られる。
Bergerは、この肖像画の現実を明かす。貧しい老いた画家が仕事を必要としていて、役人たちは公式の肖像画があるといいかもしれないと思ったのだろう。彼らはその貧しい老人にいくらか金を払い、彼がそれを描き、そして絵が出来上がった。よく描かれた集団の肖像画だ。美しいと言ってもいい。だが、それはごく日常的な目的のために依頼された仕事であり、その目的には十分に合っていた。神聖な遺物だったわけでも、今そうであるわけでもない。
文化的に、私たちは絵画や彫刻、映画、音楽を神秘化する傾向がある。「微妙な揺らぎ」なるものを吹き込み、装飾や娯楽、気晴らしといった機能面は無視して、感情への影響ばかりに目を向ける。
誤解しないでほしい。私自身、優れた美学の哲学は好きだ。作品への反応をじっくり検討し、メディア分析を通じて文化や自分自身への理解を深めようとすることは素晴らしいと思う。むしろ、もっとやるべきだ。
だからといって、そうした作品の制作が神秘的であるとか、他のあらゆる労働より崇めるべきものだということにはならない。
ましてや、純粋芸術に隣接しながら、文化的にはそこまで崇められていない他の労働ならなおさらだ。私たちは小説家の仕事を神秘化する一方で、ジャーナリストの仕事を貶める。だが実際には、ジャーナリストの機能的な散文も同じだけ重要であり、同じだけの敬意に値する。
小説家が集合的想像の中で住まう天上的な領域には遠く及ばないとしても、ジャーナリストでさえ、下賤なコピーライターよりは敬意を払われ、神秘化されている。しかし「小説家」と「コピーライター」の間に超越的な区別はない。技能の多くは共通しており、違いは商業と機会の偶然にすぎない。
実際、多くの著名な作家が両方の役割を経験している。これは偶然ではない。プロとして言葉を扱うこと、たとえ(おそらくは特に)ありふれた言葉であっても、それはより純粋に芸術的な文脈で言葉を扱うための絶好の練習になる。ありふれた創造であっても、それは依然として芸術なのだから。
コードは美しくなりうる
インターネット年で千年ほど前、私が十代後半だったころ、自分を「コード詩人」と称していた。今の若者が「痛い」と呼ぶであろうその自称は、当時「気取っている」と表現され、容赦なく嘲笑された。
私は同調圧力に屈し、メール署名とプロフィールからその言葉を消した。コードと詩、あるいは芸術との類似を今も強く信じていたが、少なくとも社会的には、コードを詩や芸術と比べるのは馬鹿げた行為だと受け入れたのだった。
しかし、その考えを心から捨てたことは一度もなかった。
私が最もよく知られているもの、Deferredの発明は、まさにRPCクライアント/サーバーアプリケーションのすべてのリモートプロシージャコールにcallbackとerrbackのパラメータを渡すという退屈さに対する美的な反応だった。その2つのコールバックでも十分に用は足りた。だが醜く、扱うのが煩わしかった。
Deferredは非同期タスク実行についての意図的な詩であり、問題の美学とそれを使う体験に意図的に目を向けたものだ。美学への焦点があったからこそ影響力を持った。
この些細な貢献の美しさや深遠さ、ましてやその持続性を誇張するつもりはない。詩が存在するからといって、それが偉大な詩であるわけではない。ただ詩であるというだけだ。
プログラムをめぐる私たちの美的文化は、純粋芸術というより民衆叙事詩に近い。だからこの貢献の影響力は、その具体的な永続性よりも、その後に何が来たかへの影響にある。MochiKit.AsyncからJQuery Deferred、JavaScript Promises、そしてやがてasync/awaitへ。異なる職人がそれぞれ何かを加え、元のものがほとんど溶けてなくなるまでの長い連鎖だ。(そして私もここで「元祖」だったわけではない。何よりE言語のPromisesから多くを借りている。)
コードを意図的な芸術的表現にするには、その問題領域をかなりの時間かけて考察していなければならない。千のコールバックパラメータを手で渡す退屈さを経験していなければ、こんなものを作ろうとする技能も、ましてや動機もなかっただろう。
だが、ほとんどのコードはこうである必要はない。ほとんどのコードはこうなることを許されない。ほとんどのコードは機能的で、平日のコードだ。ほとんどのコードは女性を泣かせることなどできない。いわばコピーライティングにすぎない。
前に説明したように、ほとんどの文章もそれはできない。ほとんどの文章もただのコピーライティングだ。ほとんどの視覚芸術は広告だ。ほとんどのライブ音楽演奏は、ほとんど無視されるバーのBGMだ。
しかし、意図的に美的に設計されたコードは、社会的にも技術的にも重要なものになりがちだ。
ソフトウェアには自己神秘化の伝統が多少はある。Abelson の有名な言葉に「プログラムは人が読むために書かれ、機械が実行するのは副次的なことである」とあるように、プログラムを高度に表現的なものとして捉える考え方は昔からあった。それが何を、誰に向けて表現しているのかについては、必ずしも意見が一致するわけではないけれど。特定のソフトウェアの哲学的含意について詩的に語りたくなることもある。これは一つのソフトウェアに限った話でもない。複数のコミュニティが似たような哲学談義に耽ってきた。
ソフトウェアの表現的・美的性質は、ソースコードを読むことや API を通じて他のプログラマーとやり取りすることに限られない。たとえば Federico Viticci は毎年 Apple の新しいオペレーティングシステムのレビューを書いているが、それは(とりわけ)美的批評でもある。ソフトウェアがユーザーに美的な影響を与えていなければ、こうした企画は成り立たない。
ましてや、ビデオゲームのレビューはすべてソフトウェアのレビューでもある。
ソフトウェアリテラシーについてのちょっとした余談
ソフトウェアコミュニティに批評的読解の伝統があまりないのは、少し悲しい。Literate Programming はよく称賛されるが、実際に実践されることはほとんどない。
さらに悲しいのは、ユーザーがソフトウェア制作に何が関わっているのかについてかなり混沌としたイメージを持っていること、プログラミングリテラシーがかなり低いこと、そして現代のプログラミング手法が、ソフトウェアが何をしているかについての誤ったメンタルモデルを意図的に生み出すことが多く、ユーザーが理解するのをいっそう難しくしていることだ。ソフトウェアの美的体験は、その内部状態から大きくかけ離れていることがよくある。
こうした問題はすべて AI より何年、いや何十年も前からあるが、だからといって喜んで悪化させる理由にはならない。
ありふれたものを守れ
AI を使ってコピーライティング、グラフィックデザイン、退屈でありふれたアート、そしてそう、退屈なカスタム WordPress テーマ開発までもすべて消し去るなら、人々が技量を高め、やがて偉大なことを成し遂げるために必要な膨大な練習と熟考の実践的な機会を、すべて奪うことになる。教育は素晴らしいが、真のスキルの大半は実務の中で身につくものであり、それは昔から変わらない。
抽象化や自動化によって仕事を楽にすること自体を否定しているわけではない。プログラミングとは抽象化の芸術であり、小さなアイデアを大きなアイデアへと組み上げる方法を理解することであり、小さな部分を自動化する規則を理解し、それらを組み合わせることで大きなシステムの自動化を理解することでもある。
その理解を高めるのではなく消し去るために、創造的な意思決定のプロセスを完全に壊すために「AI」を使うのなら、それはプログラマーである私たち自身にとっても、ユーザーにとっても損になる。画家が自分の創造的な成果ではなく自動生成された埋め草を観客に差し出し、ミュージシャンが聴き手に同じことをするのが、それを受け取る側にとっての損であるのと同じように、それはユーザーと、下流で関わる開発者仲間にとっても損なのである。
スロップはスロップだ。媒体が何であれ。
ありふれたプロジェクトにも、偉大な成果に到達するごくわずかな可能性——たとえば0.1%程度——はある。AIを使って1つのプロジェクトを片付けたところで、まあ構わない。そのプロジェクトが、それに取り組むエンジニアのキャリアを決定づける一撃になる可能性はほとんどない。しかし、すべてのプロジェクトをそうやって進めるのが習慣になれば、そうした偉大な瞬間の総確率は「確かに時にはある」から「決してない」へと変わる。
あらゆるソフトウェア開発に対するAIの侵食に抵抗するための、正確に適切な方法は、この短い記事の範囲をはるかに超えている。どこまで抵抗できるか、どの具体的な用途に抵抗すべきかは、あなた次第だ。だが、ソフトウェアにおいても、あらゆる創造的な媒体においてと同じだけ、抵抗する価値はある。
プログラミングは特別ではない。ただの芸術であり、芸術とはこの世で最も人間的で、ゆえに最も普遍的なものだ。