- AIが生成した低品質コンテンツである 「スロップ（slop）」 がインターネット全体に広がる中、音楽・映像・テキストだけでなくソフトウェアの領域でも同様の現象が起きている
- コンテンツ生産は エンゲージメントと収益の最大化 だけを目標に最適化へ集中し、職人精神や創造性は失われつつある
- 大手テック企業の 品質低下と技術的退化 はAI登場以前から進行しており、狭い役割分業 がエンジニアの熟練と思考力を弱めている
- AIエージェントはよく定義された反復作業には有用だが、もっともらしい嘘をつき、コードを正しく理解できず、悪いコードを生成するという 根本的限界 がある
- 19世紀の Arts and Crafts運動 のように、ソフトウェアでも初期コンピューティングのアイデアを復元し、人間中心の職人精神を取り戻すべき時だ
AIスロップの拡散と technique の概念
- AIモデル公開後、オーディオ・ビデオ・テキスト全般で 「slop」と呼ばれる低品質なAIコンテンツ が急増
- ゴミのようなコンテンツは以前から存在したが、AIによって生成に必要な労働は 数十倍以上 減少した
- 識別力がない、あるいは識別力が重要でない作業 では、AIは 人の手を置き換えるのに十分な水準 に達した
- Jacques Ellul の 「technique」 概念: 活動を、測定可能で定義された目標へ向かう 効率的手段の集合 に還元する思考様式
- Instagramリール、YouTube動画、ブログ記事は、最小の労力で最大のエンゲージメントを引き出せば「良い」成果物 と見なされる
- 指標と成果への執着が、職人精神、美しさ、楽しさといった 無形の価値を蝕む
音楽プラットフォーム比較: Bandcamp vs Spotify
- Bandcamp: アルバム全体と個人キュレーションを重視
- 2010〜2020年代のインディー音楽ブームを支え、Car Seat Headrest、Mitski、Alex G、Phoebe Bridgers などのアーティストの台頭を後押し
- 音楽そのものを目的とするプラットフォームとして、AI生成音楽を 禁止
- Spotify: プレイリストとアルゴリズム推薦に基づくモデル
ソフトウェア業界における品質低下
- AI登場以前から、すでに多くのソフトウェアは 全般的に低品質 な状態にあった
- 大手テック企業のソフトウェアエンジニアリングは 「配管工事（plumbing）」 に近いものへと変質
- 複数のシステムを接続し、データを流す役割にとどまる
- Richard Hamming が語った 「偉大な仕事」、すなわち人類への贈り物を作るという概念は、今日の技術産業ではあまりにも理想主義的に受け取られる
- 多くの大規模ソフトウェアシステムは 肥大化し、設計が粗く、文書化も不十分 な状態にある
- ユーザーは、プラットフォームがますます悪化する 「enshittification（品質劣化）」 の過程で食い物にされないよう、絶えず防御的でいなければならない
- Jonathan Blow の講演 ソフトウェア文明の崩壊防止 で示された見方に共感する
- 専門エンジニアや大規模ソフトウェア企業は、仕事を正しく行う方法そのものを忘れてしまった 状態にある
- 非競争的独占 という構造のため市場圧力から守られ
- ソフトウェアの慣行は緩み
- 組織は肥大化し
- 全体的な品質は大きく低下する
- ビッグテックのエンジニアは、大規模組織の中で きわめて限定された役割 しか担わない
- 幅広いエンジニアリング能力と職人精神は自然に 衰退 していく
人的資本と分業の問題
- 企業や社会がコンピュータで何を成し遂げられるかは、人的資本、つまり幅広い技術を備えたエンジニアをどれだけ育てられるかにかかっている
- 大手テック企業の極端な分業構造は
- 特定領域にしか慣れていない 狭いスキルの技術人材 を量産し
- 現在のビッグテックの組織構造の中でしか機能できない人材として固定化する
AIがソフトウェアエンジニアリングの脅威になるという2つの現象
- 1. AIエージェントが専門的ソフトウェアエンジニアリングを脅かすという現実的認識
- 役割が反復的で範囲の狭い 低品質ソフトウェア生産 に縮小されたエンジニアにとって
- AIは実際にかなり有効な代替手段として機能する
- 2. AIエージェントの能力に対する過度な一般化
AIエージェントの根本的限界
- このような主張が成り立つには、ソフトウェアとは何かについての きわめて偏狭な見方 が前提になる
- AI生成音楽が、音楽を単なる消費指標としてしか見ない視点を必要とするのと同じ
- ソフトウェアを目的達成のための道具としてのみ捉え、「十分によければそれでいい」 という態度
- AIエージェントを直接試した結果、確かに有用な面はあるが 明確な限界 がある
- 事実でない内容をもっともらしく語り、文脈をきちんと理解できず、低品質なコードをしばしば生成する
- 一部の領域では改善が続くかもしれないが、音楽やテキストと同様に 構造的限界 は明らかだ
- AIエージェントは 自律的な思考を持たず、ユーザーが何を望んでいるかを自分で把握できない
- もっともよく機能するのは 問題が明確に定義された依頼 の場合
- 例: 「ユニットテストを書く」「この形式のDB関数を実装する」
- 能力を一般化しようとする試みは たいてい失敗する
- 新奇ではあるが保守・理解・拡張が難しい 怪物のようなコード を生み出すことが多い
「Vibe Coding」の問題点
- 当初は印象的に見えても、時間が経つと 固有の欠陥 が目立ってくる
- 不必要に 冗長なコード といい加減なスタイル
- 構造は単純だが 平板で美的に貧弱なデザイン
- 繰り返し現れる独特の痕跡がだんだん鼻につくようになる
- 問題が起きると、デバッグ過程は 挫折を生む反復作業 に変わる
- 別の動画を見たりSNSを流し見したりしながら気ままにコーディングし
- 「バグがある、もう一度直してくれ」という依頼をエージェントに繰り返す
- AI生成コードによく見られる特徴
- 過剰にパディングされたボタン
- 一貫性のない間隔と色
- 全体的な美的平板さ
- 存在理由のはっきりしないUI要素
- すべての要素に不要なラベルや説明を付け足す傾向
ソフトウェア産業の構造的問題と職人精神の必要性
- 大半のコードがそれほど良くないという点は否定しがたく、とりわけ大企業環境で顕著だ
- AIを活用すれば、低品質なソフトウェアを より速く、より効率的に 生産し続けられる
- しかしAIは、ソフトウェア産業が抱える 中核的な構造問題 を解決できない
- 根本問題は、大規模環境でソフトウェアをうまく作る方法そのものが、いまだ確立されていないこと にある
- この問題を解くには自動化ではなく、職人精神と人間の批判的思考 が必要だ
Arts and Crafts運動とソフトウェアの類似性
- 第二次産業革命期の Arts and Crafts運動 に注目する
- John Ruskin と William Morris は、機械と工業生産の驚異的な力が個々の職人を押しのけていた時代に応答した
- 工業生産を無条件の進歩とは見なさず、それが生み出す成果物と労働条件には固有の 「スタイル」 があると認識した
- 労働者が次第に 巨大な産業機械の部品 へと転落していることを批判した
- 機械にはできない領域が明確に存在し、それは当時も今も変わらないと指摘した
- インスピレーションの源泉として 中世の職人精神の回復 を志向した
ソフトウェアに求められる同様の転換
- ソフトウェア分野でも 同様の転換と運動 が必要だ
- 初期コンピューティングの手法と思考をあらためて研究し、復元する必要 がある
- 主流からは顧みられなかったが消えてはいないアイデアの 豊かな宝庫 が存在する
- 今日のソフトウェアとは異なるやり方で 印象的で美しかったプロジェクト群 がある
- 現在は技術発展の 非常に狭い枝、すなわち C/Unix から Javascript/ウェブへと続く経路の上にとどまっている
- 少しでも非伝統的な方向へ進むと、AIの助けはほとんど消える
- Claude に Forth の記述を試させたが、妨害に近い結果 を経験した
- 出発点として Permacomputing wiki を勧める
AIコード時代の展望
- AIコードは 低品質な大量生産ソフトウェア をさらにありふれたものにする可能性がある
- 同時に、職人精神と創造的表現を取り戻そうとするエンジニア にとっては新たな余地を開くかもしれない
- 悲観的ではない。職人精神は希少になるほど それ自体でより大きな価値 を持つ
- 主流ソフトウェアが限界を露呈し、ソフトウェア品質の劣化が続き、政治的な問題意識 から中央集権的構造の価値が再検討される局面にある
- 実験的で、人間が作り、人間の規模で運営されるソフトウェア が周縁から輝くには良い時期だ
1件のコメント
Hacker Newsの意見
Jacques Ellulの思想に触れていた部分が気に入った
技術的な**「進歩」の本質**は、効率性を最高の価値へと押し上げることにあるのだと改めて考えさせられる
この価値がほとんど異議を唱えられないまま受け入れられてきたのは興味深い。だが、それでもなお別の選択は可能だと信じている
効率性には本質的に適応力と回復力を犠牲にする性質がある
一方で職人技、細やかさ、驚きは測定しにくい。自分が使っている指標は実際の人々からのメールだが、これは不規則で予測不能だ
コーディングエージェントを通じても高品質なコードは作れると思う
一度のプロンプトで終わるのではなく、計画―実装―検証―レビューという調整されたプロセスが必要だ
結局のところ依然としてエンジニアリング作業であり、違うのは道具だけだ。手引きのこぎりと電動のこぎりの違いのように、結果は同じでも過程が違う
エンタープライズソフトウェアは、とりわけ使わない管理者に売られるので品質が悪い
一方でコンシューマー向けソフトウェアは利用者自身が選ぶので、より親切だ
自分自身のためにコードを書くときは必要な機能だけ実装するので雑でもよく動く
コーディングエージェントはプロジェクトを洗い流す高圧洗浄機のように使える。芸術ではないが満足感はある
ただし繊細なコードには使うべきではない。とはいえ大半のWebアプリはテストがよく整っており、もはや手作業でやる理由はほとんどない
その結果、不要な機能やトグルがあふれる
管理者はデータの正確性を求めるが、従業員は入力が面倒だと不満を言う
統合の予算がなかったり短期契約だったりして、CRM連携すらできないことも多い
一方でエンタープライズソフトウェアは、支払う側と使う側のインセンティブ不一致のために奇妙なワークフローへと歪められる
たいていのソフトウェアエンジニアは、AI以前から職人技よりも給与と効率に重きを置いていた
だからAIが生み出すコードも、しょせんその程度のコードだ
AIが職人技をよみがえらせるのではなく、むしろ最後の痕跡を消し去るのではないかと思う
電動工具が手作業の木工を消さなかったように、AIもそうなるだろう
未来には「IDEの人たち」と「エージェントにプロンプトを書く人たち」が共存するだろう
Forthへの言及がうれしい。よく使っている
LLMが生成したForthコードはCを翻訳したような悪いスタイルだ
標準的なForthは短く明快であるべきだが、LLMはネストした条件文だらけの長いコードを作る
最近Turing’s Cathedralを読んでいる
戦後アメリカの工学的な職人技を改めて実感させられる
今では何もかも当然のものとして受け止め、本当のエンジニアリングがどのようなものだったのかを忘れているように思える
もともと大半のコードはひどいものだった
結果重視の文化の中で品質は後回しになり、バグは事業コストの一部になっていた
AIはこうした環境に完璧にはまり込む。すでに低水準のコード文化の中で繁栄している
AIを活用してより良いソフトウェアは作れると思う
AIが生成したコードにもデザイン、パターン、ベストプラクティスを反映できる
これは伝統的なギター製作と現代的なCNCベースのギター製作の違いに近い
Ulrich Teuffelのギター製作動画を見ると、技術と芸術が共存している
もちろん職人技は高価なので、ほとんどの人は工業製品を選ぶ
大規模プロジェクトに適用しているが、長期的な結果はまだ未知数だ
以前は自分で書いていたアルゴリズムを、今ではエージェントに任せている
手動のフライス加工の代わりにCNCを使うように、技術スタックを進化させてより高品質な作品を作っている
AIで悪いソフトウェアを安く作れるなら、それはそれで構わない
重要なのは良いソフトウェアの比率が増えるかどうかだ。AIはその可能性を高める
AIはソフトウェアを**「十分に良い」水準へ最適化する環境で繁栄する
優れたエンジニアを置き換えるというより、すでに存在していた機械的で指標中心の産業の現実をあらわにしている
大量生産されたコードが当たり前になるほど、人間の判断力と美的感覚**こそが本当に希少な資源になるだろう