世界を動かす技術を、日本語で。

AIコードとソフトウェアの技術

概要

  • AI生成コンテンツ の氾濫による質の低下と効率化主義の台頭
  • 技術至上主義(technique) が創造性や職人技を損なう現状
  • BandcampとSpotify の音楽プラットフォーム比較による価値観の違い
  • ソフトウェア業界 におけるAIの役割と限界
  • 職人技復興運動 の重要性と、今後の人間中心のソフトウェア開発への期待

AI時代の「スロップ」コンテンツと技術至上主義

  • AI生成の低品質コンテンツ (音声・動画・テキスト)の大量流通によるネットの質的変化
  • AIの登場 でコンテンツ生成が飛躍的に効率化、識別力の低い消費者には十分な代替手段化
  • Jacques Ellulの「technique」概念 :効率化と成果主義が創造行為を支配
  • 現代ネットコンテンツ (Instagramリール、YouTube動画、ブログ等)の価値判断基準が「エンゲージメント最大化」や「労力最小化」に偏重
  • 職人技・美・人間性 といった無形価値の喪失

音楽プラットフォームの比較:Bandcamp vs Spotify

  • Bandcamp :アルバム重視、個人キュレーションによるインディー音楽シーンの活性化
    • Car Seat Headrest、Mitski、Alex G、Phoebe Bridgersなどの台頭
  • Spotify :プレイリストとアルゴリズム推薦中心
    • 無個性なアルゴリズム音楽 の大量生産
    • 音楽そのものではなく指標(再生回数など) を最適化する仕組み
  • AIの活躍領域 :クラフトが重視されない環境で「十分良い」コンテンツを大量生産
  • BandcampのAI禁止 :音楽本来の価値重視の姿勢

ソフトウェア業界における品質低下とAIの影響

  • AI普及以前からの低品質ソフトウェア の蔓延
  • 大企業のエンジニアリング :配管工事のような単純作業化、創造性や「偉大な仕事」意識の消失
  • Richard Hammingの理想 と現実との乖離
  • Jonathan Blowの指摘 :大手ソフトウェア企業の技術力・組織の形骸化
  • エンジニアの専門性の極端な分業化 とスキルの劣化
  • AIによる単純作業の自動化 :大企業での役割喪失の懸念
  • AIの万能視の危険性 :ソフトウェアを「目的達成のためだけの手段」として捉える狭い視野
  • AIエージェントの限界 :嘘や誤解、悪質なコード生成、設計の浅さ、デバッグの非効率性

職人技復興運動とソフトウェア開発の未来

  • Arts and Crafts運動 (John Ruskin、William Morris)の再評価

    • 機械生産への批判、職人技復興の重要性提唱
  • 現代ソフトウェア開発 におけるクラフト精神の喪失

  • 過去の多様なコンピューティング手法 や美しいソフトウェアの再発見の必要性

  • 非主流・人間中心ソフトウェア開発 の重要性と価値の再上昇

  • AI時代におけるエンジニアの役割 :創造性やクラフトを追求する場の拡大

    • Permacomputing Wikiの推奨

結論:人間のクラフトが輝く時代へ

  • AIは大量生産・効率化に最適 だが、創造性やクラフトには限界
  • クラフトの価値 が希少化とともに上昇
  • 中央集権型・大量生産型ソフトウェアの限界 が顕在化しつつある現状
  • 人間中心・実験的なソフトウェア開発 の新たな可能性
  • AI批判と活用のバランス を取った「AI中道」的立場の重要性

Hackerたちの意見

エンタープライズソフトウェアは特にひどいことが多いよね。なぜなら、それを使わないマネージャーに売られているから。消費者向けソフトウェアはもっとユーザーフレンドリーだけど(そうじゃないと売れないし)、人気のソフトが必ずしも自分の求めているものとは限らない。自分のためにソフトウェアを書くときは、自分が欲しい機能だけを実装しがちで、他は気にしないことが多い。結果的に結構雑になることもあるけど、動けばそれでいい。でも、コードの健康状態は選択次第。何を求めるかを知っている必要がある。コーディングエージェントはプロジェクトをきれいにするための高圧洗浄機みたいに使えるよ。素晴らしいアートは生まれないけど、落ち葉を掃いたり、階段を掃除したり、駐車場を耕したりするのと同じように、満足感はある。絵を洗浄機で掃除しないのと同じように、もしかしたらコーディングエージェントを使うにはデリケートすぎるコードもあるかもね。でも、テストがしっかりしていて、そんなにデリケートでないプロジェクト、つまりほとんどのウェブアプリがそうだと思うけど、手作業でやってもらうためにお金を払いたい人はいないだろうね。雪かきをシャベルでやる人にお金を払うより、除雪機を持っている人を雇う方がいいって感じ。

エンタープライズソフトウェアは特にひどい。なぜなら、多くの顧客が自分たちの望むように物事が動くことを要求するから。これが奇妙な機能やトグル、設定可能性を生む。大きな購入を担当しているマネージャーが「まずはXをやらなきゃダメ」と要求するから、その後、元のリクエスターがいなくなった後も誰も使わない機能が残ることになる。一方、消費者向けソフトウェアでは、個々の消費者は与えられたものをそのまま受け入れるし、単一のプロダクトマネージャーやチームが何がベストかを決める。

消費者向けソフトウェアは良いこともあるけど、実際の価値や機能のためじゃなくて、最大のエンゲージメントを最適化することが多いよね。企業向けソフトウェアは、インセンティブのミスマッチがないから、良いソリューションが顧客にとってより価値があるし、売れるし、彼らもそれにお金を払う意欲がある。でも、君が言うように、多くの企業向けソフトウェアは、ユーザーじゃなくて支払い側のために最適化されてるから、特定の企業の変なワークフローに押し込められてることが多い。

エンタープライズソフトウェアは特にひどいことが多い。なぜなら、それを使わないマネージャーに売られているから。 マネージャーはファイルやランクの社員とは異なる目標を持っていることを忘れないで。私が働いているSaaSでは、マネージャーが正しいデータを持つために必要なフィールドの要件やビジネスプロセスへの洞察を求めてくるんだ。ソフトウェアを納品した後、システムを使っている社員から「このデータを全部入力するのに時間がかかりすぎる」とか「クソみたいなシステムを直せ」といったサポートチケットが来る。彼らは気にしないし、なぜそれが必要なのかを完全に理解していない。これは、マネージャーが自分の部下を教育して「なぜ」を説明していないせいだよ。ああ、もちろん、彼らは会社がCRMとの統合に予算を持っていないから、何度もコピー&ペーストしなきゃいけないんだ。来年ライセンスを更新しないかもしれない単一の顧客のために投資するつもりはないし、5年契約みたいなコミットメントをするのも嫌がる。もちろん、CRMとの接続に投資するところもあるけど、それは例外的なケースだね。

この議論は、基本的に1800年代のラッダイト対産業家の議論を新しい時代に再構成したものだね。グループAは、品質は人間の主体性に関わるもので、機械が職人制度をバイパスして劣悪な商品を生み出していると思っている。グループBは、効率が最優先で、職人技はただの見栄だと思っている。もちろん、私たちは第三の道を選んで、人間の役割がシフトしたんだよね。私が思うに、期待できるシフトの方向は、人間はボットと話すのが好きじゃないってこと。特に重要なことについてはね。これは生物学的なもので、私たちは他の人間から学び、交流するように進化してきたから、同じグループの人と長い時間をかけて理解し合ったり、反映し合ったり、好きになったり、支え合ったりするんだ。

もしかしたら、子供たちはボットと話す方が好きになるかもしれないね。私の世代の後の世代は、実際に音楽のデジタル圧縮アーティファクトを好んでいたから。

全然同じじゃないと思う。織物が置き換えられたとき、確かに生計を失った人たちは怒っていたけど、布の品質は落ちてなかった。CNCが機械加工に来たとき、誰も文句を言わなかった。なぜなら、コンピュータが手でネジを動かす手間を省いてくれていたから。コンピュータがコードや脚本を書くとき、今のところ品質は客観的に見てずっと悪い。これが変わるかもしれないけど、コンピュータがその仕事を意味のある形で置き換えられるところまで来ているという主張はかなり弱いと思う。確かに、これが変わるかもしれないけどね。

ラッダイトとは関係ないよ。ソフトウェアの品質は、納期の速さとバグの少なさに関わるものだから。もし、変更するたびに作業がちょっと難しくなって、予期しない方法で爆発する可能性があるソフトウェアでも大丈夫なら、AIは全然問題ないよ。でも、そのトレードオフを明確にしたAI支持者にはまだあったことがないな。ソフトウェアの品質を軽視する人たちも、バグにはあまり満足していないしね。

はぁ、またこの引用を引っ張り出すことになるとはね。「ラッダイトたちは機械の使用そのものに反対していたわけではない(多くは繊維産業の熟練工だった);彼らは当時の標準的な労働慣行を回避しようとする製造業者に立ち向かった。」幸いなことに、勇敢な政府の部隊や見せしめの裁判、そして「『機械破壊』(つまり、産業の妨害)を死刑にする」という対策が、これらのひどく、権利意識の強い労働者たちの要求の危機を一度きりで解決したんだ。今の時代の生意気な労働者たちにも、適切な教訓を教えることができるはずだよ。

「人間はボットと話すのが好きじゃない、特に重要なことに関しては。生物的なものだ。なぜ僕がスーパーマーケットに行く代わりにアマゾンで買い物をするのが好きか教えてあげる…でも、年を取るにつれて、やっぱり店に行きたくなる。人間を見るためじゃなくて、買いたいものをすぐに手に持ちたいから。待つのが嫌なんだ。もう時間がない気がする。」

確かにラッダイトたちは機械に仕事を奪われたけど、他の仕事を見つけられたし、子供たちも変わった世界に適応したんだ。AnthropicのCEO、ダリオ・アモデイは、この混乱は以前のものとは違うと思ってる。彼の「技術の青春」という記事から、HNのフロントページに載ってる内容を引用すると、>「AIは非常に幅広い人間の認知能力を持つことができる—おそらくすべての能力を。」これは、機械化された農業や交通、さらにはコンピュータのような以前の技術とは全く違う。これによって、仕事を失った人が似たような仕事に簡単に移行するのが難しくなるかもしれない。例えば、金融、コンサルティング、法律のようなエントリーレベルの仕事に必要な一般的な知的能力はかなり似ているけど、特定の知識はかなり違う。もしこの3つのうちの1つだけが混乱した場合、従業員は他の2つの近い代替品に移行できる(あるいは学部生が専攻を変えることができる)。でも、3つすべてが同時に混乱するのは、人々が適応するのが難しいかもしれない。さらに、既存の仕事がほとんど混乱するだけじゃない。そういうことは以前にもあった—農業が雇用の大部分を占めていたことを思い出して。農民は工場の機械を操作するという比較的似た仕事に移行できたけど、その仕事は以前は一般的ではなかった。でもAIはますます人間の一般的な認知プロファイルに合致してきていて、古い仕事が自動化されることで通常作られる新しい仕事にも適応できるということ。別の言い方をすると、AIは特定の人間の仕事の代替ではなく、むしろ人間のための一般的な労働の代替なんだ。

生物学的なものだ。ナンセンスだね。私たちはテキストメッセージを送るために進化したわけじゃないのに、今やSNSやチャットシステム、メールがどこでも使われてるよ。

ボットと話すのが受け入れやすくなるのは、タイピングで本のようなプロンプトを小さなチャットウィンドウに打ち込む代わりに声を使うときだね。

AIによるコードの引き継ぎは、エンジニアを職人技に戻すわけじゃない。職人技の最後の名残を永遠に消し去るだけだよ。

新しい技術は古い技術や職人技を排除するわけじゃない。誰がそれを使うか、何のために使うかが変わるだけだ。- 電動工具は手工具での木工職人技を消し去ったわけじゃない。優れた木工職人は今でも手工具を使ってお金を稼いでいるし、趣味でやってる人もいる。だけど、契約業者は電動工具に切り替えた。なぜなら、労力やコスト、時間を減らしてもっとお金を稼げるから。- 友達は今でも織機で編み物をしている。彼女は織機を使うのが好きだから。手で編むのが好きな人もいる。大きな自動織機があっても、どちらもやめてはいない。- 鍛冶屋もまだ存在していて、素晴らしい金属工芸品を作っている。それは、機械で鋳造されたり鍛造された金属部品の市場がないわけじゃない。未来には「IDEの人たち」と「エージェントプロンプトの人たち」がいて、それぞれ自分のやり方で頑張っているだろうね。

それはかなり悲観的な発言だね。クラフトマンシップがすでに最後の息をしているという誤った前提に基づいている。そんなに悪くはないよ。

でも、深刻な限界がある。あなたのコーディングエージェントは嘘をつくし、本当に物事を理解しているわけじゃないし、悪いコードを生成することが多い。高品質なコードはコーディングエージェントを使って作れると思うよ。一度のプロンプトでできるわけじゃなくて、計画、実装、検証、レビューのオーケストレーションが必要なんだ。まだエンジニアリングの仕事だし、コードは重要だよ。ただ、コードを書くための違うツールなだけ。手動でコーディングするのとコーディングエージェントを操作するのは、手鋸とチェーンソーの違いに例えられるかな。最終的な結果は同じだけど、方法は全然違う。

最終的な結果は同じだけど、方法は全然違う。誰も手書きのバージョンと全く同じ最終結果のLLMコードには本当に興味がないと思う。実際には、LLMバージョンはほぼ決して手書きのバージョンと同じにはならないし、桁違いに悪いから。

「本当に高品質なコードはコーディングエージェントを通じて作成できると思う。1回のプロンプトではなく、計画、実装、検証、レビューのオーケストレーションが必要だ。何かアドバイスやリソースがあれば教えてくれる?自分でも経験したことある?」

「1回のプロンプトではなく、計画、実装、検証、レビューのオーケストレーションが必要だ。自分で書いて終わらせることができることも多い。」

高品質なコード 高品質なコードってどんな感じ? > コードはやっぱり重要だよね。どういうこと?

実際の限界はレイテンシーと推論コストだよ。完全な計画と検証のループはたくさんのトークンを消費するし、そのサイクルを待ってると流れが途切れちゃうから、ただコードを書く方がいいんだよね。

実際のソフトウェアエンジニアの目から見たAIの効果について、あまり言われていないことがあると思う。それは、ほとんどのコードが質が悪いということ。プログラミングの技術が結果重視で薄まってしまって、使い捨てのコードが多くなったから、質があまり重要じゃなくなってしまった。20年前にプログラミングを始めた頃は、良いコードを作る時間があった。でも、もっと早くコードを出すようにという圧力が増えて、誰も質を気にしなくなった。バグはビジネスのコストの一部になった。GenAIは最近のパラダイムにうまくフィットしていると思うし、昔の手作りのコードと比べるのはちょっと不誠実だと思う。なぜなら、ほとんどのコードは長い間そんなに良くなかったから。認めるのは悲しいけど、AIはすでに存在していた質の悪いコーディングプラクティスに適応して、そこで繁栄しているだけなんだ。

エージェントに抵抗している者として、これには100%同意する。特に、あまり言われていないことだから、これはまさに僕がキャリアのほとんどで反対してきたことなんだ。業界の大半には「全てのコードはクソだ」という巨大な感情があって、ほんとに嫌だ。

確かに、これはオフショアリングの次のレベルだね。ビジネスはクラフトに興味がない、ユースケースが解決されればそれでいいんだ。たとえコードが内部でクソでも。

ジャック・エリュールのアイデアへの言及が好きだな。AIの時代に考えるべき面白いテーマだと思う。技術的な「進歩」で根本的に問題になっているのは、「効率」が最高の価値として位置づけられていることだってことがはっきりするよね。面白いのは、この価値の高まりがほとんど挑戦されていないこと。実際には恣意的な価値選択なのに。他の選択肢もあるし、まだ可能だといいな。大企業が株主の利益を最大化するために必要だと主張していることとは別にね。

効率性って、組織の(期待される)株主リターンを最適化するための最良の方法でもないよ!効率性は基本的に適応性や回復力とトレードオフになるからね。

効率は測りやすいよね。で、測ったものが目標になる。だけど、技術や思いやり、驚きなんかは測るのが難しい。俺が一番参考にしてるのは、実際の人からのメールなんだけど、それは不定期で予測できないし、毎分更新される分析画面よりも判断が難しいんだよね。

Forthの言及に+1!よく使ってるよ。今はLLMの回答が可能だけど、まるで翻訳したCみたいで、スタイルがすごく悪い。基準としては、Forthの単語は数行のコードで、ストレートなスタック効果を持つべきだよ。プログラムのトップレベルは5単語くらいになるかも。LLMはサブルーチンを生成して、20~50行のネストされたIF..THEN..ELSEやDO..WHILEの大きな単語を作るけど、まるでCを書いてるみたいだね。

これが核心を突いてるね:AIはソフトウェアが「十分良い」として扱われる環境で繁栄する。優れたエンジニアを置き換えるというより、現代のソフトウェアがどれだけルーチン化され、メトリック駆動の作業になってしまったかを暴露している。大量生産されたコードが安くなるにつれて、判断力やセンスが本当の希少資源になっていくというアーツ&クラフツの類似性が特に適切に感じるね。

ほとんどのソフトウェアエンジニアは、AIが出る前は「クラフト」なんてしてなかったよ。利益のために雑なコードを書いて、給料をもらって帰るだけ。だからAIも同じようなクソコードを出すんだ。噂によると、少数のエリートなクラフターがいたらしいけどね。システムやアーキテクチャについて考えながら、10ドルのエスプレッソマキアートを飲んでるソフトウェアの魔法使いみたいな人たち。

AIを活用してより良いソフトウェアを作るべきだと思う。AIが生成するコードにはかなりのコントロールがあるから、デザインやパターン、ベストプラクティスを生成されたコードに活かせるんだ。これで私たちはより良いソフトウェアの職人になれるよ。いい例がギター作りだね。伝統的な方法にこだわるルシアーたちがいるけど、日本の木工道具だけを使う人もいる。でも、素晴らしいギターを作る方法はそれだけじゃない。優れたルシアーが最新のツールを使って高品質なギターを作ることもできるんだ。たとえば、ウルリッヒ・トイフェルはCADシステムやCDCマシンを使って美しいギターを作っているよ。残念ながら、クラフトマンシップは安くはないから、ほとんどの顧客は工業製品に目を向けるんだ。ソフトウェアも同じだね。

でも君の比較はちょっとずれてるよ。ギターを作るためのCNCマシンを挙げてるけど、それは人間が正確にプログラムするツールなんだ。一方、LLMは確率的なものだから、「ギターのボディを作るためのgcode指示を作って」とプロンプトを出して待つしかない。確かに、LLMはソフトウェア開発のツールとしての役割があるかもしれないけど、大量に使うことで監視が薄くなる危険があるんだ。大規模に使って大きなアプリケーションを作っている人たちもいるけど、最終的にどうなるかは時間が教えてくれるよ。ソフトウェアエンジニアリングは時間をかけてプログラミングすることだから、LLMベースのソフトウェアエンジニアリングの「時間」はまだ十分じゃない。