AIはフロントエンドの失われた10年を繰り返させるのか？

 (mastrojs.github.io)
1 ポイント 投稿者 GN⁺ 6 시간 전 | 1件のコメント | WhatsAppで共有
  • 脱熟練化は、熟練労働を低技能の技術運用に置き換えることでコストと参入障壁を下げる一方、労働者の交渉力も弱める
  • フロントエンドではこの10年、フレームワークやツールがブラウザ・アクセシビリティ・性能の知識を覆い隠し、front of the frontend の専門性を押しのけてきた
  • エージェント型AIはコーディングをより高い抽象化へ引き上げるが、非決定的で、入力やモデルのわずかな変化でも結果が大きく変わる漏れやすい（Leaky）抽象化である
  • LLMはStack Overflowのコピペの延長線上にあり、熟練者をより速くし、初心者でも動く結果を作れるようにするが、誰かがその出力を理解して修正しなければならない
  • AIはより多くのAIスロップとコスト削減を生み出しうるが、品質・ユーザー・トレードオフを理解する人の必要性が消えるわけではない

脱熟練化から見るフロントエンドとAIコーディング

  • 脱熟練化(deskilling) とは、熟練労働を半熟練または非熟練の労働者でも扱える技術に置き換える過程であり、コスト削減と参入障壁の低下をもたらす一方で、労働者の交渉力を弱める
  • フロントエンド開発はこの10年、JavaScriptフレームワークとツールを通じて脱熟練化を経験しており、プログラミング全般でもエージェント型AIが同様の変化を生み出している
  • Frontend’s Lost Decadeという表現のとおり、ブラウザやユーザー環境を深く理解していたフロントエンドの専門性は、フレームワーク中心の開発に押しやられてきた

フロントエンドから消えた専門性

  • かつてのフロントエンド開発には、セマンティックHTML、CSS、ブラウザ差異、アクセシビリティ、プログレッシブエンハンスメント、ネットワーク性能、インターフェース設計、ユーザーテストといった専門知識が必要だった
  • 一部の実務者は、こうした領域を現在の「frontend」と区別してfront of the frontendと呼んでいる
  • フロントエンドの脱熟練化は、ブラウザをJVMやiOSのようなアプリ実行環境と同じく単純なコンパイル対象として扱うフレームワークやツールの導入によって進んだ
  • Shadcn radio buttonのような構成要素を持ってくれば、基盤となるHTML、ブラウザごとの微妙な違い、ページ読み込み性能、アクセシビリティを深く理解していなくても機能を作れる
  • 企業は一般的なプログラマをフロントエンド業務に容易に投入でき、コストを下げられる
  • 「フルスタック開発者」は、フロントエンドとバックエンドの両方を深く理解する人ではなく、JavaScriptフレームワークで両方を処理できる汎用開発者を指すことが多くなった
  • 同じ開発者を複数プロジェクト間で容易に切り替えられ、React NativeやElectronでネイティブアプリまで任せられる
  • 参入障壁が下がる利点がある一方で、労働者の交渉力は弱まる

AIコーディングはより高い抽象化であり、同時に漏れやすい（Leaky）抽象化でもある

  • 現在プログラミング全般で起きている変化は、Web開発者がすでに経験した変化に似ている
  • 手で直接コードを書く熟練作業が、半熟練または非熟練の労働者でも扱える技術に置き換えられる方向へ進んでいる
  • エージェント型AIを扱う労働者に最終的にどのような能力が必要になるのか、労働コストやローカル・リモートLLMのコストがどこへ到達するのかは、まだ明確ではない
  • 企業がこの技術をコスト削減と労働者の交渉力低下に活用する可能性は明らかに見える
  • 長年磨いてきた熟練の市場価値が下がる状況は、職人や手工業者が組立ラインの労働者に置き換えられていった変化に似ている
  • 脱熟練化は、自動化による効率向上、すなわちより高い抽象化レベルで仕事をするようになる変化としても見られる
  • 新しい技術は細部を隠し、運用者がより大きな全体像に集中できるようにするが、どの細部を「重要ではない」とみなすかは重大な判断である
  • 抽象化の細部は最終的にいつか漏れ出す

  • 「モダンな」フロントエンドの漏れる抽象化

    • 抽象化はしばしば性能コストを伴い、開発者の生産性のためにランタイム性能の一部を犠牲にする選択は、高性能サーバーと中程度の負荷では合理的かもしれない
    • 低速なネットワーク上のモバイル端末では、同じトレードオフがまったく別の問題になる
    • Reactのような重いクライアントサイドJavaScriptフレームワークやエコシステムのパッケージを多用すると、アクセシビリティや低性能端末・低速ネットワークでの性能を抽象化の向こうへ追いやってしまう
    • その結果、そうした問題を考えず、気にも留めない選択になってしまう

  • エージェント型コーディングの非決定性

    • エージェント型AIで機能を作ったりバグを修正したりするときは、すべてのコードを直接書く代わりに、より少ない言葉で高レベルな変更を記述する
    • AIは学習データと周辺コンテキストを見て省略された細部を埋め、ときにはうまく推測し、ときには失敗する
    • この方式が有用かどうかは、コーディングにおいて何が重要だと考えるかに大きく左右される
    • エージェント型コーディングはコンパイラのように決定的ではなく、入力やモデルのわずかな変化が大きく異なる結果を生むため、従来のプログラミング抽象化よりもはるかに漏れやすい
    • AIが「ジュニアエンジニア」にたとえられるのもこの非決定性ゆえだが、人間はAGENTS.mdやSKILL.mdファイルを延々と調整しなくても学習できるという違いがある

LLMはStack Overflowのコピペの延長線上にある

  • LLM利用に最も近い比喩は、かつてのGoogle検索の使い方である
  • 適切なフォーラム投稿やStack Overflowの回答を検索結果の最初のページに表示させるために、正確なキーワードを選ぶ能力も開発者が身につけるべき技術だった
  • LLMプロンプトも、学習データの適切な組み合わせを返させる過程であり、あいまいなWeb検索のように非常に高次元な空間での検索に近い
  • 検索結果は文言の小さな変化やGoogle検索インデックスの変化に敏感であり、LLMも入力表現やモデルの変化に敏感である
  • 最近のGoogleは入力語をより強く正規化する方向に検索を変え、Google-fuに慣れていない人には検索が簡単になった一方で、熟練者にとっては以前ほど強力ではなくなった
  • GoogleとStack Overflowはプログラミングを不可逆的に変え、マニュアルを読む代わりに答えをコピー＆ペーストしても、驚くほど高い頻度である程度は動く結果を得られるようにした
  • LLMはその流れの延長線上にある
    • 何をしているのか分かっている人を少しだけ速くする
    • 何をしているのかあまり分かっていない人でも、ある程度動くものを作れるようにする
  • 抽象化はいつか漏れ出し、そのときには誰かが実際に何が起きているのかを深く理解して修正しなければならない
  • ジュニア開発者にStack Overflowの回答を使う前に読んで理解するよう教えたのと同じように、今ではLLMの出力を読み、理解し、既存コードベースにどう適合するかを見極めるよう教える必要がある

品質とビジネスの距離

  • 一部のプログラマはStack Overflowの回答を本当に理解する段階まで進まず、結果が動けば十分だと考えていた
  • 多くの企業も公には認めなかったが、このようなアプローチに満足していた
  • 今では企業が成果物を確認しているふりすらせず、どれだけAIを使っているかを公然と誇示する状況になっている
  • LLMの有効なユースケースは確かにあるが、コードを壊し、組織のコミュニケーションやプロセスを壊す新たなやり方も数多く生まれている
  • コードレビューと同様に、LLMをワークフローにどう使い、どう統合するかについては見解の違いが大きく、チームが何を価値あるものとみなすかが一致していないと、作業フローに大きな問題が生じる
  • 多くの企業は、ひどいソフトウェアを作り続けても十分に運営できている
  • プログラマが信じたがることとは違い、ビジネスの成功とソフトウェア品質が相関することは非常にまれである
  • たいていはブランドや価格など別の要因の方が大きく作用し、ソフトウェアプロジェクトは成功と失敗が同程度の確率で起こるブラックボックスのように扱われている
  • フロントエンドでも、遅いWebサイトや大量のクッキーバナーはコンバージョン率を損なう可能性があるが、その影響はブランドロイヤルティや価格のような要因より小さく、競合サイトも遅いことが多い
  • 「Reactを選んで解雇された人はいない」というような空気の中で、品質よりも無難な選択が好まれる
  • だからといってユーザーやクラフトマンシップを気にかけるのをやめるべきだという意味ではないが、そうできる職場を見つけるのはより難しくなった
  • 過熱が過ぎ去り、LLMが実際に適した仕事とそうでない仕事についての理解が進めば、ある程度の均衡は戻るかもしれないが、職業そのものは以前と同じではないだろう

産業化の後にも残る技術

  • 日用品や建築物が産業工程で大量生産できるようになったとき、ひとつの反応は、過去の様式を模倣して手工芸品のように見える製品や建物を工場で量産することだった
  • こうした歴史主義に対して、20世紀初頭のBauhausは、工場労働者と職人を対立させるのではなく、両者が協力し、工業的製造工程を前提に芸術と工芸を再構築するアプローチを発展させた
  • Bauhausは、デザイナーが工房に戻って素材を直接扱いつつ、最終目標は大量生産可能なデザインに置くことを求めた
  • ソフトウェアは、書いたプログラムが製造工程を経ずに「そのまま」ユーザーへ届けられるという点で工芸に近く、同じものを何千人ものユーザーに配布するという点ではインダストリアルデザインに近い
  • 手でコードを書ける能力は依然として必要であり、インダストリアルデザイナーが製品の素材を知っていなければならないのと同様に、WebデザイナーはHTMLとCSSに非常に習熟している必要がある
  • Google、Stack Overflow、すぐ使えるライブラリ、LLMは初心者がより簡単に始められるようにする一方で、何かを動かすための自然な障壁も継続的に下げている
  • 産業化は、使い方やユーザーを十分に考えていない安価なプラスチック製品を大量に生み出したが、優れたインダストリアルデザインは今も存在する
  • ワードプロセッサはひどく書式設定された文書を大量に生み出したが、タイポグラフィとグラフィックデザインは今も存在する
  • WixやNext.jsは、遅くアクセシビリティの低いWebサイトを大量に作れるようにしたが、front of the frontendの実務者も依然として存在する
  • AIは大量のAIスロップを可能にするが、それは何をしているのか理解し、自分の仕事を気にかける人が不要になるという意味ではない

これからの変化とトレードオフ

  • 他の産業と同様に、きちんと作る仕事の比率は全体の中でさらに小さくなる可能性がある
  • その一方で、より簡単に、より安く作れるようになることで、市場全体のパイは拡大し続けるだろう
  • 仕事をきちんとこなして報酬を得る人の絶対数が増えるのか減るのかは、現時点では判断しにくい
  • 高速なプロトタイプやMVPを量産することが正しい選択である場合もある
  • まだプロダクト・マーケット・フィットを見つけていないなら、すべてを将来対応にすることよりも、素早い反復と学習の方が重要である
  • ただし、何を学ぼうとしているのか、その学習をどう検証するのかを理解していなければならない
  • 適切な時点が来たら、通常は一歩引いて最初からきちんとやり直した方がよい
  • たとえば、悪いアーキテクチャのフロントエンドで後から良い性能を実現するのは非常に難しい
  • 単純なスタックで始め、後から機能を追加していく方が、その逆よりも簡単である
  • Mastroは、良い性能と単純なスタックから始めることを明示的に奨励している
  • サービス購入、オープンソースライブラリ利用、LLM生成、自前実装のどれを選ぶにせよ、システムの各部分でどのようなトレードオフをしているのかを理解していなければならない
  • 過熱が落ち着けば、業界はAIがツールボックスの中のひとつの道具にすぎないことに気づくだろう
  • それまでは、AIの名の下に醜いコード、壊れたコミュニケーション、悲惨なレイオフが続く可能性がある

関連記事

1件のコメント

 
GN⁺ 6 시간 전
Hacker Newsの意見

  • OPが惜しんでいる深い専門性は、実際には多くの人にとってかなり不便なものだったと思う
    ブラウザごとの癖、アクセシブルなコンポーネントの自前実装、CSSの詳細仕様を理解して食べていけることは理解できるが、その大半は偶発的複雑性に近い。より多くの人が何かを作れるようになるのは明らかに良いことであり、その結果の一部がより遅かったりアクセシビリティに欠けたりするとしても、それは選択可能なトレードオフだ
    抽象化がユーザーの選んでいない結果を押し付けると言うこともできるが、LLMは私よりアクセシビリティの慣行をよく理解している可能性もあると思う

    • アクセシビリティ、直感性、互換性、応答性、拡張性、アーキテクチャ、性能のような、あまり目立たないUX/ソフトウェア開発の要素をきちんと扱うのは昔から難しかった
      ところが超高水準フレームワーク、そして今ではLLMが、こうした部分を壊しながらも半熟のMVPを素早く出しやすくしてしまい、そのせいで「受け入れ可能」と「良い」の間の隔たりがさらに広がっている。「良い」を目指す立場からすると、「受け入れ可能」を押し出す側と競争するのはますます難しくなる
      結果として、さらなる長時間労働やソフトウェア品質の低下、ひいては仕事全体の満足度低下につながる。最近では、壊れたWebサイトを開発者ツールやuBlockで修正したり邪魔な要素を消したりして基本機能を取り戻すことが起き始めており、ここでも同じことをしているという人を見た(https://news.ycombinator.com/item?id=47042747)。昔はFlashや初期ブラウザの時代ですら、こんなふうに自分で手を入れる必要はなかった
      もっと逸話的でない例もある: https://news.ycombinator.com/item?id=47390945
      さらに悪いことに、こうした削減で節約された金の大半は組織の最上層にしか回らない
    • AIはアニメーションオブジェクトをブラーオブジェクトの後ろに置くミスを繰り返し、ブラウザに再描画を続けさせてしまう
      GoogleのAI modeにもそれが入っており、他のWebサイトでも明らかにバイブコーディングで似たようなものが入れられているようだ
      最初はGPU使用率が跳ね上がりファンが激しく回る理由が分からなかったが、今ではAIがよくやるミスなのに誰もろくにテストしていないのだと分かった。人間でもこうしたミスはあり得るが、これまで人生でほとんど経験したことがなかった
      240Hzモニターを使っているのでブラウザは毎秒240回再描画しようとし、uBlock Originで止めるしかなかった。信じられない
    • 「私たちは職人技を失っている」系の文章はいつも同じ陰鬱な構造をしている
      さらに良くないのは、中盤あたりで自分自身の主張を打ち消してしまう点だ
      たとえば「どの詳細を重要でないと見なすかは非常に重大で、ときには主観的な判断であり、結局詳細は常にはみ出してくる」とあるが、だとすればこの新しい技術も結局は深い技術理解に報いるということになる。避けられないのだから。その点には同意する。だが、なぜ全体のトーンは「AIが自分のスキルを安っぽい商品にしている」なのか？
      Webサイトは技術的には10年前より概ね良くなっている。機能は増え、より速くなり、SSL/アクセシビリティ/レスポンシブ対応はより強いデフォルトになった。コンテンツファーム、SEO、ニュースサイトの問題は広告と企業インセンティブが生んだ別種のひどい失敗形態であって、Reactのせいではない
    • 「LLMが私よりアクセシビリティの慣行をよく理解しているはずだ」というのは、正確には他の人々がそれを理解して文章にしてきたからだ
      LLMはときどきそれを活用できる。だが、人々がもう書かなくなったらその次はどうなるのか？
      より多くの人が何かを作るのが良いという点には同意する。ほかの条件が同じなら、多いほど良い。「AI」が否定しようのない改善ゆえにあらゆる場所に浸透したのなら、状況も空気感もずっと違っていただろう
      それでも人は、自分の仕事によって「生成された」知識に対して当然の権利を持つわけではない。帰属と報酬が真剣に扱われ、資料を作った人に対価が支払われた資料だけで学習できるのであれば、単にCSSを学ぶほうがずっと速くて安いかもしれない
    • 深い専門性を軽視し、ハックや怠惰な抽象化を積み上げた利便性は、現代の数MB級フレームワークやElectronにまでつながる退行だと思う
      もちろん、ユーザーのコンピュータやメモリ使用量、劣化した体験、無駄になる帯域幅、80億人に上乗せされるエネルギーコストや環境影響を気にする人は誰もいない
      より多くの人が公共インフラを作るのも「明らかに良いこと」なのか？ その結果がより悪い道路、より悪い橋、失敗するシステムだとしたら？ ソフトウェアも同じで、実際たいていの物事がそうだ

  • この文章が relevance を失っているとした「フロントエンド技術」のかなりの部分は、直感的でない例外、ブラウザ非互換、歴史的負債、例外の例外のさらに例外に満ちた地雷原をかき分けて進むことだった。
    現代のフロントエンド、つまり「漏れる抽象化の塔」は、ついに Web 開発のための常識的なメンタルモデルに近づいている。Web 標準や慣習という奇妙さの爆発物の上に無理やり被せたものではあるが、それでも動作し、少し漏れる程度に収まっているというだけでも成果ではある。

    • 「Web 開発のための常識的なメンタルモデル」という言い方は矛盾している。地雷原のような例外の世界なのか、常識的なモデルなのか、どちらか一方であって両方ではありえない。
      私たちはいまもなお例外の地雷原の中にいて、フロントエンドを作る技術がクリーンで予測可能で、歴史的負債から自由になったとはとても言えない。
      私たちがやったのは、土台のミスや非互換の上に漆喰を塗っただけで、解決したわけではない。React は HTML が UI ツールボックスとして設計されていないという事実を解決していない。Next.js は JavaScript が安全で正気の通った合理的な言語になれないような設計ミスだらけだという事実を解決していない。Tailwind は、スタイリングのために設計されていないマークアップを飾ろうとして CSS が場当たり的に導入されたという問題を解決していない。
      いま LLM がやっているのは、漆喰の下にある恐怖を統計モデルの中で「知っている」だけだ。そのモデルは、以前の漆喰層のひび割れを再び埋める例が 99% を占めていた時代の事例で学習されている。
    • 専門家ではないが、一般公開向けのフロントエンドをデプロイしてみると、フロントエンドは『オズの魔法使い』の黄色いレンガ道のようなものだ。
      小さくてまともなベストプラクティスの集合から外れなければ、退屈だが実績のあるライブラリをいくつか使うだけで、かなり良い体験を提供できる。
      しかし、今日流行のフロントエンドフレームワーク、あるいはもっと悪いことに昨日流行のフレームワークに絡まれたり、特定のやり方に固執する別の開発者の奇妙な好みに合わせなければならなかったり、希望とダクトテープでつなぎ合わせた「天才的な」ハックを扱い始めたりすると、複雑さと相互作用の仕方は指数関数的に増大する。
    • 原文は、存在したこともない黄金時代を失ったと惜しんでいるようなものだ。
      その時代は経験した。IE6 専用の素の JavaScript はバグだらけの jQuery に置き換わり、その次に保守不能な Angular のシングルページアプリになり、その次に怪物じみた React のコードベースに変わった。
    • 無知をさらけ出す発言に見える。
      実際にはそれよりずっと多い。
      Next.js の専門家だと言って面接に来る人をあまりに多く見てきたが、それ以外は何もできないことが多かった。それは技術ではなく知識にすぎず、いまでは無料でいくらでも手に入る。
    • その漏れる抽象化がどの塔の、どの階の、どの部屋にあるのかを理解する能力は、今でも非常に価値があり、LLM には見えないかもしれない。
      何かが委員会によって最初から完璧に設計されていなかったからといって、すべてを忘れて本を閉じ、機械に計算させてよいという意味ではない。
      私も後者をやっているので何を間違えるかは分かっているが、だからといって保守不能な大混乱を作るほどだまされてはいない。エージェントが脱線するたびに、私のフロントエンド技術は本当に役に立つ。

  • 「フロントエンドは意味のある HTML、CSS、ブラウザ差異、アクセシビリティ、プログレッシブエンハンスメント、ネットワーク性能、インターフェース設計、ユーザーテストなどを知っている必要がある高度に専門化された技術だった」という話は、前世代のフロントエンド開発者、つまり C/C++ 開発者にはかなり滑稽に聞こえるだろう。
    Web は参入障壁を大きく下げ、技術を脱熟練化したものと見なされていた。アセンブリプログラマも C/C++ 開発者に対して同じように考えていただろう。

    • どの階層も、自分たちこそが最も重要で、最も専門化され、最も熟練した階層だと思っている。
      しかし、どの階層も間違っている。各階層はその下の階層の抽象化の上に築かれているからだ。物理や数学まで下りていけば、集合論者でさえ何らかの公理を仮定していることが分かる。論理学者が何をしているのかは誰にも分からない。
    • その引用文は記事から出たものではなく、記事とも関係がないように見えるが、いったいどういうことなのか分からない。

  • 「新しいプロセスがより低品質な結果を生み、多くの人が気にしていないようで悲しい」という手の論理は、AI 以前にはこの仕事の大半が熟練した職人によって品質に献身して行われていた、という前提に頼っているように見える。
    業界で実際に働いたことがあり、なおかつ正直な人なら分かるが、現実はそうではなかった。凡庸以下が多かった。
    また、「品質」をどう定義するかによっては、AI の成果物が本当により低品質なのかも確信しにくい。AI は不快な画一性を生みうるが、同時にモデルが学習した慣行が良くも悪くも大多数の最終ユーザーにとって「動く」ため、かなり実用的な成果物も多い。

    • これは「壁にレンガを一つ積み増す」ことに近い。
      以前から、要件を満たす最低限だけやって成功だと宣言しろという圧力は強かった。いまではその圧力が耐えがたいものになった感じがある。
    • AI 以前には熟練した職人が品質に献身していたという前提については、キャリアの中で数回は幸運にもそういう時期を経験した人もいる。
      ただし、それは AI 以前の時点ですでに消えていたという点には同意する。
    • 品質基準がひどく低く見える。
    • その通り。jQuery や Bootstrap 以前の Web はひどい有様で、コーディングしていても楽しくなかった。
      低品質という意味では、むしろあの頃のほうが普通だった。

  • 最近、自分も似たようなことを考えていた
    少なくとも10年はフロントエンド開発をほとんどしていないが、2000年代後半に突然みんながWeb GUIを手で作らずフレームワークを使い始め、それでもなおHTML/CSS/JSやデータベースクエリを手で書く人が嘲笑されていた時代を覚えている程度には年を取った。求人票も突然、PHP/HTML/CSS/SQL/JSの代わりにRuby on Rails、Django、Spring、GWT、後にはAngularの技術を求めるようになった
    今と妙に見覚えのある感覚だ。深い知識がなくても数分で動くWebアプリケーションを作ることができて、魔法のようだった。その後はドキュメントをざっと眺めて検索しながらフレームワーク内でカスタマイズしていたが、ある時点でそれ以上できなくなる。内部がどう動いているのかまったく分からないからだ。バイブコーディングのWebアプリのように、午後に継ぎはぎした標準フレームワークのWebアプリは遠目にもそれと分かったが、管理者にはかなり印象的だった
    面白いのは、開発者たちが自分の主力の最先端モデルについて、15〜20年前にGUI開発者たちがお気に入りのWebフレームワークについて語っていたのと似た話し方をすることだ。ツールを擬人化し、さらには同一視までして、バージョンXではできたことがX.1で悪化したと落胆し、「もう10倍速く開発できる」「もう一度XYZを手で書く」といった言葉が繰り返される

    • 一方で、その後のフレームワーク利用は標準化のための良い試みでもあった
      誰も扱えない自家製GUIが強みになるわけでもない
      個人的にはNuxt/Nextのように大きすぎると“感じる”ものは避けたいが、Vueは好きだ。ただ、今はJavaScriptを大半なくしたいので、サーバーサイドテンプレートと一緒にHTMXやAlpine系の解決策に行こうとしている
      個人的には、使う技術は少ないほどよい。昔はカスタムコードを1行追加する前から、Webアプリの中にありとあらゆる不要なものが入っていた時代もあった
    • すでに2000年代初頭にも、Web開発者は何もかも手でコーディングすることに疲れており、フレームワークやCMSのような自動化を探していた
      2004年にも、ディレクトリツリーにtxtを置き、PHPが改行の代わりにタグを付けてHTMLに挿入するような基本的なアプローチでサイトを作ったことがある。当時の代替は重たいコンテンツ管理システムだった
      職場でリード開発者たちが作ったひどいPHPフレームワークを2つ経てDjangoに来たので、Djangoのようなフレームワークはより漸進的な移行で、はるかに楽しかった
      もちろん、さらに押し進めてオブジェクトにバージョン管理を追加するような方向に行くと、非常に厄介になり、動作も保証されず、直す方法もなくなった
      それでも態度そのものは今と似て見える

  • 私たちはソフトウェア業界にいる。この業界の核心は、非常に反復的な仕事を自動化することだ
    フロントエンドのプロジェクトは非常に反復的で、今やAIがそれを代わりにやってくれる。素晴らしいことだし、もっと面白いものを作るための時間をたくさん解放してくれる
    もはやそれほど関係のない技術が脱熟練化していくのは、コンピューターが発明されて以来この業界でずっと起きてきたことだ。AIであれ別の方法であれ、問題を解決したからだ
    先へ進んで新しい技術を学べばいい。実際、AIを効果的に使うこと自体が、一部の人には難しい技術でもある。依然として物がひとりでに作られるわけではない。正しくプロンプトを与えればやってくれるが、ちゃんとプロンプトできているのか？ ツールは頼んだとおりに動いているのか？ それをどうやって知るのか？ 確認したのか？ 自分もAIにプロンプトするのにものすごい時間を使っていて、確かに上達してはいるが、まだフルタイムの仕事に近い
    10年ほど後には、このやり方はソフトウェアを作るには非常に非効率な方法だったと振り返ることになるだろう。ツールはさらに良くなり、AIはもっと自律的になる。1日中同じプロンプトを繰り返すことに時間を使っているなら、誰か、あるいは何かがそれも自動化すべきだ

    • ソフトウェアの目的は、人間の意志を機械が伝達できる状態へとエンコードすることだ
      ここでの不満は、その自動化が望まないものをエンコードしてしまう危険があることだ
    • フロントエンドを諦める代わりに、AIが生んだ新しい効率性は、フロントエンドとバックエンドをさらに押し進めるための資源を解放するはずだ
      世の中には、今作れているものよりはるかに多くのソフトウェアが必要だ
    • 「フロントエンドのプロジェクトは非常に反復的」というのが、いったい何を意味するのか分からない
      どこから反論すればいいのかも分からないほどひどい見方だ。すべてのUIにボタンが入ることが反復的だということか？
      もし人々が本当にそう信じているなら、UXが90年代からなぜ壊れていて、その後さらに悪化したのか理解できる
    • 作るべき「面白いもの」が、そんなに多くないと知ったら驚くかもしれない

  • AIコーディングは製品プロトタイプを作るのに大いに役立つが、同時に遠目にもAI製だと分かる製品も生みがちだ
    さっきもあるスタートアップがアプリをデモしていたが、そのアプリにはまさにバイブコーディングUIっぽさがあった
    彼らが受けたフィードバックは冷淡だったが的確だった。「かなり良いけれど、AIで作ったのが見えすぎる。だとすると、これを欲しがる他の人もAIであっという間に作れるので、売ろうとしているものには大した価値がない」という内容だった

    • こういうことはもっと増えてほしい。LLMが作ったUIも、それを十分だと思う人たちも、耐えがたい
    • 面白いのは、基本的なデザインシステムとCSSだけ設定しておけば、AIが生成したフロントエンドコードはかなり自然に馴染むことだ
      だが大半は、その程度の基本的な気配りさえしない
      角丸はいまだに終わりなき流行で、すでにきちんと定義されていないものはすべてその形に感染するかのようだ
    • 実際にあった話というより、頭の中のファンタジーのように聞こえる
      有能なベンチャーキャピタリストは、こんな無意味なフィードバックはしない。良ければ良いのであって、AIが作ったかどうかが何の関係あるのか？ 同じ品質の製品で、バイブコーディングっぽさが出ていなければ問題なかったのか？ AIにイデオロギー的に反対している人だけが気にする話だ

  • ときどき、2000年代初頭に AJAX や DOM 操作なしで HTML だけで複雑なユーザーインターフェースを作っていた手法が、まるでピラミッド建築技術のように事実上失われたと感じることがある
    若いフルスタック開発者には「脱熟練化」された面があり、たとえばフォーム検証には JavaScript が必要だと考える人も多い
    いったん AJAX を使い、DOM を操作し始めると、非同期通信の複雑さは React と同程度の規模の何かへと行き着かざるを得ない。document.title="A new title" のように書けて何かを取り込まなくてよいとしても、フロントエンドを「サーバーからデータが来たら UI を更新するもの」くらいに捉えるだけでも、複雑なアプリケーションでは UI の複数箇所を更新しなければならず、気づけば通信や状態管理バスのようなものを作ることになる。別の作り方ができたのかといえば、もちろん可能だった
    React エコシステムに問題があるとすれば、別の抽象化の上に抽象化を作ることではなく、その抽象化が漏れることだ。ごく単純なものを作り、見た目を気にしないのであれば、CSS を理解しなくても Bootstrap や MUI は使える。だが、顧客の前に出せるプロレベルの仕事をするなら、HTML、CSS、JS と、プロジェクトで使うすべてのフレームワークを理解していなければならない

    • 特に HN では、React がインタラクティブな Web 全般に対する、より広い不満を代弁する4文字の悪口のように使われているとよく感じる
      React を批判する人の大半は、React がどんな問題を解決するのかを実際には理解していない。十分に複雑な Web アプリでありながら React に依存していないソースコードを見せれば、その中に自作のReact 類似物を見つけ出せる

  • NextJS のサーバーサイドレンダリングや遅延読み込みなどを使うフロントエンドアプリケーションの運用が、HTML、JS、CSS だけを使っていた時代より「簡単だ」という点には同意しない
    複雑さのレベルもユーザーの期待値も、まったく別の場所にある
    しかも熟練したエンジニアは1000倍くらい増えており、世界市場全体と競争しなければならない。2000年代初頭には競争はほとんどなかった。労働者のスキルは市場が要求する水準とおおむね緩やかな相関を持つものだが、今では極度に競争的だ