AIがプログラマーの仕事をどう変えるのか。この記事は、その話を「フロントエンドがすでに経験したこと」とそっくりだと見ています。
かなり刺激的な主張ですが、正直かなり面白いです。なぜなら、これは単なる「AIすごい／危ない」論ではなく、便利さと引き換えに何が失われるのかを、歴史を使って考えているからです。
記事の軸になるのが deskilling です。
これは簡単に言うと、高度な技能が必要だった仕事が、技術の導入によって“誰でもできる寄り”になることです。
Wikipediaの定義を引いて、記事ではこう説明しています。
ここ、かなり大事です。
便利になることと、仕事の価値が下がることは、しばしば同時に起こります。技術史って、だいたいそういう残酷さがありますよね。
著者は、AIの話をする前にまずフロントエンド開発の変化を振り返ります。
昔のフロントエンドは、ただHTMLやCSSを書く仕事ではありませんでした。
むしろ、
みたいな要素が必要な、かなり専門的な仕事だったわけです。
ところがJavaScript frameworksの普及で、状況が変わりました。
ブラウザは「理解すべき環境」ではなく、アプリを動かすためのコンパイル先のように扱われるようになった。
すると、HTMLやCSSの細かい意味、ブラウザ差、読み込み速度、アクセシビリティを深く知らなくても、フロントエンドっぽいものが作れるようになったんですね。
この変化の結果、企業は一般的なプログラマーを前線に送り込みやすくなった。
いわゆる full-stack developer も、実態としては「フロントエンドもバックエンドも深くは知らないが、JavaScript frameworkを何とか扱える人」になりやすい、という指摘はかなり鋭いと思います。
個人的には、ここは痛いけれど納得感があります。
“誰でもできる化”は、採用しやすさやスピードを生む一方で、その領域を支えていた専門性を見えにくくするんですよね。
著者は次に、AIによるコーディングも同じ流れだと言います。
つまり、手でコードを書くという熟練技能が、AIによって置き換えられつつある、と。
ただし、ここで重要なのは「AIを使う人にどんな技能が必要になるのか」は、まだはっきりしていない点です。
将来的には、AIを“操縦する”人が必要になる。でもその技能が何なのか、どれくらいの価値になるのかはまだ流動的です。
とはいえ、企業がこれをコスト削減や労働者の交渉力を弱める手段として使うのは、ほぼ確実だと著者は見ています。
この見方はやや辛口ですが、たしかに現実味があります。技術は中立でも、導入する側の動機はけっこう露骨ですからね。
AI擁護の立場では、こんな言い方がされます。
AIは仕事を高い抽象度で扱えるようにするだけ。
だから細かいことは気にせず、大事なことに集中できる。
要するに、抽象化です。
抽象化とは、細部をまとめて、上のレベルから扱えるようにすること。たとえばコンパイラは、人間が機械語を直接書かなくて済むようにしてくれる、立派な抽象化です。
でも記事は、ここにかなり慎重です。
なぜなら、どの細部を「無視していい」と決めるかは、とても重要で、しかも主観的だからです。しかも、後でだいたいその細部が漏れてくる。
これ、めちゃくちゃ現場っぽい話です。
抽象化はたいてい最初は気持ちいい。でも、後で「アクセシビリティが壊れた」「遅い」「バグの原因が見えない」となって、結局つけを払う。
“魔法の箱”は、だいたいあとで箱の中身を見せてきます。
記事は、Reactのような重いclient-side JavaScript frameworkを例に、現代のフロントエンドを leaky abstractionsの塔 と呼びます。
leaky abstraction とは、
抽象化したつもりでも、下の層の問題が結局見えてしまうことです。
たとえば、
つまり、「もう考えなくていい」わけではなく、考えないと後でしっぺ返しが来る。
ここはAIでも同じだ、と記事は言います。
AIに機能追加やバグ修正を頼むと、たしかに高い抽象度で指示できる。コードもたくさん書かなくて済む。
でもAIは deterministic（決定的）ではない。同じ指示でも、入力やモデルが少し違うだけで、かなり違う結果になる。
コンパイラは同じ入力なら基本同じ出力を返しますが、AIはそうではない。
この不安定さが、AIコーディングを“漏れやすい抽象化”にしている、というわけです。
個人的には、この指摘がかなり本質的だと思います。
AIは便利ですが、「なぜそのコードになったのか」を完全には追えないことがある。
そこを雑にすると、結局あとで人間が全部読む羽目になります。
記事の後半で面白いのは、AIを突然の革命としてではなく、昔から続く流れの延長として見る点です。
著者は、AIの使い方を昔のGoogle検索やStack Overflowに重ねます。
昔は、欲しい答えを出すために、
「どのキーワードで検索するか」を知っていること自体が技術でした。
いわゆる Google-fu ですね。
良い検索ワードを選ぶと、目的のフォーラム投稿やStack Overflowの回答にたどり着けた。
でもGoogleは検索をどんどん正規化し、多少雑でもそれなりに検索できるようにした。
これは初心者には親切ですが、昔ながらの検索上級者にとっては、かえって力が落ちたように感じられたわけです。
そしてプログラミングでも、Stack Overflowの登場で、
マニュアルを読むより、答えをコピペしてそれっぽく動かす流れが広がった。
LLMはその延長で、さらに「それっぽく動くもの」を量産しやすくした、と著者は見ています。
これはかなり説得力があります。
AIは突然現れた異物というより、**“便利なコピペ文化”の最終形の一つ**とも言えるからです。
ただし、ここでも大事なのは、動いたから終わりではないということ。
LLMが出したコードは、やはり人間が読んで理解しないと危ない。
「Junior programmerにはStack Overflowを読むことを教えた。なら今は、LLMの出力を読んで理解することを教えるべきだ」と記事は言います。
これはまさにその通りだと思います。
ここで記事は、ちょっと嫌な現実にも触れます。
多くの企業は、実のところひどいソフトウェアを出していても普通に儲かる、ということです。
つまり、
そしてフロントエンドも似たようなものだ、と著者は言います。
遅いサイトや煩わしいcookie bannerはたしかに悪い。けれど、売上への影響はブランド力や価格ほど大きくないことも多い。
さらに競合他社も似たようなものなら、なおさら「まあいいか」となりやすい。
このあたり、かなり現実的で、ちょっと苦いです。
「Nobody was ever fired for choosing React.」
つまり、Reactを選んでおけば無難、という空気がある。技術選定って、正しさだけでなく責任回避の心理で動くことも多いんですよね。
記事は、だからといって「ユーザーや職人技を気にするのをやめよう」とは言いません。
むしろ逆で、それを大事にする仕事は減ってしまったけれど、やめるべきではないとしています。
ただし、現時点ではそのような仕事を許してくれる職場を見つけるのが、以前より難しくなっている。
AIの熱狂が落ち着けば、LLMが本当に向いている仕事／向いていない仕事の整理が進み、少しは揺り戻しが来るかもしれない。
でも、職業そのものはもう昔には戻らないだろう、というのが著者の見立てです。
これは悲観的ですが、私はかなり現実的な予想だと思います。
技術は元に戻らないし、いったん変わった労働市場も簡単には逆転しません。
最後に記事は、20世紀初頭の Bauhaus 運動を持ち出します。
Bauhausは、工業化で製品や建物が大量生産される時代に、
運動でした。
著者は、現代のAIも同じように考えるべきだと言っているように読めます。
つまり、AIを「人間の仕事を奪う敵」と決めつけるだけでなく、どう使えば品質とユーザー価値を落とさずに済むかを真面目に考えるべきだ、と。
ここは希望のある締め方です。
AIを無条件に礼賛するのでも、全面否定するのでもなく、
「工業化された道具を、どう人間の技術と接続するか」を考えよう、という話なんですね。
この記事の言いたいことを一言で言えば、
AIはプログラミングを便利にするが、その便利さはフロントエンドがすでに経験した“技能の空洞化”とよく似ている、ということです。
そして重要なのは、
という点です。
率直に言って、この記事はかなり刺さります。
AIをめぐる議論って、つい「仕事が減るか増えるか」だけに寄りがちですが、この記事はその一段奥にある技能、品質、責任の所在まで踏み込んでいる。そこが面白いし、重要だと思います。
参考: Is AI causing a repeat of Frontend’s Lost Decade? | Mastro Blog
