なぜ私は「感覚に頼ったプログラミング」をしないのか

なぜ私は「感覚プログラミング」をしないのか

著者：ジェイコブ・ハリス

最近、インターネット上では「感覚プログラミング（Vibe Coding）」や大規模言語モデル（LLM）がソフトウェア開発をどのように覆すかという議論で溢れています。新モデルのリリースごとに、私たちは純粋な生産性の天国へと導かれ、光速でソフトウェアをリリースし、製品開発におけるすべての摩擦と内耗を完全に排除できると言われています。

もしかしたらそうかもしれません。私は一応信じておきますが、私自身は「感覚プログラミング」はしません。

もしこの方法があなたにとって効果的だと感じているなら素晴らしいことです！私がこの記事を書いたのは LLM の優劣について議論するためではありません。ただ、このツールは私個人には合いませんでした。この記事では、その理由を簡単に整理してみます。

私はケチです

私は原理主義者ではありません。IDE に統合された LLM を試したこともあります。説明が簡単で、自分でやるのは面倒なタスクについては、確かに便利です。例えば、グリッド内の多数の正方形画像を縮小するといった作業です。本来なら画像処理ソフトウェア ImageMagick のコマンドライン引数を確認しに行くべきところですが、そのようなことは AI に任せるのが最適でしょう。次に、ある AI ツールを使ってプロジェクト内のコードを分析したり、いくつかの小さな作業を行ったりしましたが、そこですべてが突然終わりました。システムから通知が届き、「利用枠が尽きました」と告げられました。続行するにはクレジットカードを登録してトークンを購入する必要があると。

知っておいてほしいのですが、私の家系は両方の側で有名なケチです。数世紀にわたり、大西洋のこちら側でも向こう側でも、私たちの家族は常に倹約し、細かく計算してきました。極端な例を挙げれば、17 世紀のフィリップ王戦争（King Philip's War）で亡くなった私の遠い親戚がいます。その死因は、家から退避する際にチーズを一つ落としてしまい、安全な砦の外へ取りに戻ったという理由でした。

だから、私が「思考」するために、あるサービスに無期限にお金を払い続ける必要があると知ったとき、私は全身が不快になり、クレジットカードの影すら見せたくないほどでした。私はラップトップを閉じ、その IDE をアンインストールし、さらに従順にも非常にハードコアな純テキストエディタである Emacs に戻りました。そして気づきました。AI がなくても、全く不便だと感じないということです。

私は年を取ったのです

年を取っていることは、確かに少し役に立ちます。私は何年もコードを書いており、特に 5 年の経験を持つ開発者を「シニアエンジニア」と呼ぶこの業界ではなおさらです。時には、経験は不安を和らげる薬になります（ただし、あなたがその「5 年でシニアになれる」業界における年齢差別について不安を抱いている場合を除きます）。今回の AI ブームは、かつての「ローコード」や「ノーコード」ツールが謳っていた画期的な進歩を思い出させます。AI が開発者の強力な武器になり得ることは疑いませんし、多くのタスクにおいてより良いツールサポートを提供できることも知っています。しかし、これらの議論はいつも、「偶発的複雑性（accidental complexity）」と「本質的複雑性（essential complexity）」という古典的な理論を思い出させます。

私がまだ若手のプログラマーだった頃、フレッド・ブルックス（Fred Brooks）はすでにベテランの先輩でした。IBM System 360 シリーズ大型機（およびそのオペレーティングシステム）プロジェクトのマネージャーとして、彼は現在ソフトウェアプロジェクトで日常的に見られるような厄介な事態を第一線で目撃しました。これらの観察をまとめたのが『人月神話』という本であり、今なおソフトウェア工学の授業で読むべき古典の一つです。私が持っているのは後年の再版で、そこには彼が後に執筆した有名な論文「銀弾はない」も収録されています。この論文の中でブルックスは、新しいツールが開発者の生産性に実際にどのような影響を与えるかを考察しています。プログラマーのように考えるためには、現実世界がいかに複雑であるかを知る必要があります。プログラミングとは、混乱した現実の上に簡略化されたモデルを強制的に適用する行為と理解するのが最も適切です。私たちはこれを「抽象（abstractions）」と呼び、複雑さを低減させることで世界を理解可能にします。

これにより、特定の状況を層状に積み重ねられる構造へと一般化することができます。例えば、「パンにピーナツバターを塗る」という具体的な動作は、spread(substance)（物質を塗布する）というメソッドとして一般化され、このメソッドには「ピーナツバター」も「クリームチーズ」も引数として受け取ることができます。そして、これらの基礎的なメソッドを用いて、create_pbj()（ピーナツバターのサンドイッチを作る）といったより高度な関数を構築できます。現代の高級プログラミング言語でコードを書くことは、抽象概念によって積み上げられたピラミッドの頂上に立つようなものです。一行のコードだけで、複数のシステム上で数百万もの下層オペレーションをトリガーすることができます。

では、「プログラミング」という行為自体も抽象化してしまったらどうなるでしょうか？これが AI エージェントの究極的な夢です：一群のエージェントがタスクを受け取り、監督なしで自動的にそれを実現する。素晴らしいことに思えます！しかし、これによって解決されるのはブルックスが言うところの「偶発的複雑性」、つまりコードを記述すること自体に伴う煩雑さや重厚な部分だけです。この論文が発表されて以来、ソフトウェア開発は偶発的複雑性への対処において劇的な進歩を遂げてきました。私たちはもはや下層の機械語を書く必要はなく、現代の動的解釈型言語を使用しています。私が再びゼロからクイックソートの書き方を覚える必要もなく、標準ライブラリのソートメソッドを呼び出すだけで済みます。また、Web アプリケーション全体を一から構築する必要もなくなり、既存のフレームワークを直接使用できます。コードの一部の名前変更やリファクタリングを行いたい場合、エディターが代わりにやってくれます。

AI はこのプロセスにおける最新のエディションのように思えます。一部のエディターでは、予測不可能な AI エージェントが、かつての予測可能な古風な名前変更やリファクタリングツールに取って代わっています。確かに、これはサイコロを振って運試しをするように聞こえるかもしれませんが、実際の開発現場において、そのような壊滅的な大失敗がどれほど頻繁に起こるでしょうか？

しかし、より良いツールによって偶発的複雑性が弱められたとしても、「本質的複雑性」は依然として存在します。正しく、優雅で、明確かつ保守しやすい抽象アーキテクチャやシステムを設計することは、依然として極めて困難な作業であり、この複雑性はどこにも消えません。この仕事にはスキルと経験が必要であり、過去のシステム崩壊の血みどろな歴史から辛うじて得た知恵も必要です。LLM（大規模言語モデル）のような華やかな「高度な自動補完」が、このような標準的な答えを直接見つけるのが難しい複雑性に対して、果たしてどれほどの役割を果たせるでしょうか？おそらく、注意深く設計されたプロンプトによって、望ましい方向へと導くことはできるでしょう。しかし、その段階に至れば、それを誘導する担当者が自ら設計案を作成した方がまだマシです。なぜなら、LLM はなぜ特定のパスを選択したのかを説明することができないからです。本質的複雑性は往々にして奇妙で、稀であり、混乱しています。もしかしたら私が間違っているのかもしれません。モデルがこうした混乱した状況の処理においてますます良くなっている可能性もあります。しかし、私にはこれに必要なのは非常に特定された人間の思考様式とアプローチであると感じています。幸いなことに、私はこのごちゃごちゃしたものが大好きです。

私はこの混乱が大好きだ

前面我一直在谈论软件如何抽象流程，但其实我们也利用抽象的“简化”特性，作为理解世界的一种工具。在经典名著《国家的视角》中，詹姆斯·斯科特（James Scott）描述了后启蒙时代的一个核心动机：通过抽象和分类，让人口和财产变得清晰可辨。能量化的东西，就能被改造。例如，一个国家在看待其森林时，可能不再将其视为复杂的生态系统，而是仅仅通过“能用于造船的木材比例”来评估。这种视角随之促使国家采取行动，比如用单一树种的林场取代原生森林。于是，一片森林被抽象成了一个“种植船桅的系统”。

这种方法催生了官僚机构和纸质表格，进而演变成了今天的网页表单和数据库。作为程序员，为了对世界采取行动，我们必须减少现实数据中的混乱。我们期望日期必须是精确的，期望人的名字相对简单规范，期望数据在输入时是完整的且随着时间推移保持一致。每一个程序员和每一次系统设计，都在做出一种削足适履的强制妥协：我们决定系统应该反映现实的哪些方面，又该丢弃哪些方面。我这么说并非为了批评，因为要想构建出不被无数特殊情况（我们称之为“边缘用例”，因为它们本应是处于边缘的罕见情况）所拖垮的系统，这是唯一的方法。

但是，这个过程如此根深蒂固，以至于我们有时会忘记它同时也是一种人为的造作，尤其是在用它来描述人的时候。强制性别字段只接受“男”或“女”，并不能迫使性别的本质变得非黑即白；我们对种族的定义是一种不断变化的社会建构。我们简化的模型可能会给我们提供洞见（过去 20 年自闭症诊断率猛增了 300%！），但却无法捕捉到这些洞见背后的潜在因素（这很可能只是因为我们对自闭症定义的改变以及筛查力度的加大）。退一步去审视任何模型是如何构建的，以及它遗漏了哪种类型的知识，这非常重要。每一次抽象，同样也是一次遮蔽。

作为一名前数据记者，我学会了如何“审问”数据，并且严谨地防范我得出的答案可能会在哪些方面产生误导。如果你想避免发布令人尴尬的更正声明，“迫害妄想症”绝对是数据记者最好的朋友。你不仅要能思考数据说了什么，还要能思考它没有包含什么。

不幸的是，这种试图跳出来审视系统本身的元认知，是 LLM（大语言模型）永远无法做到的。对它们来说，模型本身就是现实。正如 Robin Sloan 在其引人入胜的文章《语言模型是在地狱里吗？》中精辟指出的那样：AI 模型的构建基础和它们看待世界的方式，都被极度剥离了细节。当你我看着一段文字时，我们能看到它的上下文（比如文本格式、标题、作者简介、提供链接的网站等），而 LLM 仅仅在一个纯粹由字母构成的世界里运转（严格来说，它们接收的是子词标记，这就是为什么早期的模型数不清单词 'strawberry' 里有几个字母 'r'）。要求 LLM 去认识到它所看到的现实是有局限性的，就像是问金鱼水温怎么样一样，对牛弹琴。

写到这一节时，我满脑子都是 DOGE（政府效率部）在社会保障局（SSA）试图揪出欺诈行为时的那些拙劣表演。举个例子，DOGE 审查了 SSA 的数据库，发现里面有超过 900 万条记录的出生日期在 120 多年前，却没有记录死亡日期。马斯克断言，唯一的解释就是数以百万计的人在欺诈性地领取福利。但他对问题的起因和严重程度都判断错了。DOGE 本可以质疑数据质量，本可以去查查实际是否有钱打进了这些账户，甚至本可以随便找个 SSA 的专家给他们解释一下。但他们没有，他们直接照单全收了字面数据，并草率地得出了错误的结论。

这个套路他们玩了一遍又一遍。在另一个关于付款的欺诈指控中：

関係文書の調査および『ニューヨーク・タイムズ』に情報を提供した関係者によると、その後の広範な分析において政府機関の専門家は DOGE における論理の誤りを慎重に記録しました。

DOGE の業務を監査する代理副局長のショーン・ブレンは、ある問題に関するレビューメモの中で「これらの支払いは合法かつ有効である」と記述しています（財務省の広報担当者はコメントを拒否しました）。

しかし、ルソー氏の発言に詳しい関係者によると（ルソー氏はコメント依頼に応じませんでした）、彼は DOGE が職業公務員を信頼しないと考えていると述べました。その代わり、彼は 21 歳の若手であるアカシュ・ボバ氏に自身の分析を行わせるよう強く主張しました。ボバ氏はかつてパラメーターでインターンシップを経験し、現在は DOGE の中核プログラマーとして活動しています。

彼ら独自の荒々しい方法で、DOGE チームは大規模言語モデル（LLM）が誤った方向へ進んでしまったのと同じ論理を繰り返しています。彼らはデータの文字通りの意味以外のいかなる解釈も考慮することを拒否し、自分たちのサークル外の誰とも交流せず、極めて単純化された一つの説明に固執します。それは単に彼らの好みに合致しているからです：これは「政府職員は全員バカで、詐欺が至るところにある」という彼らの世界観を完璧に裏付けるものだからです。

私は自分が馬鹿らしく見られることを極端に恐れているため、決してデータ分析の仕事を LLM に外注することはありません。しかし、そうする人は大勢います。この問題はますます悪化していくのではないかと心配しています。

摩擦は上天的な恩恵

大規模言語モデル（LLM）駆動の開発の魅力は、あらゆる摩擦を排除できると謳っている点にあります。熱狂的な支持者たちは美しい神話を紡ぎ出します：開発チームが一日で数十もの新機能をリリースし、ますます奇妙なネットワークトポロジーの中で複数の AI エージェントチームを自律的に指揮するのです。私は理解しています。ソフトウェア開発には確かに退屈でイライラさせる側面があります。信じられないほどの速度でコードを生産し、未完成のプロトタイプではなく磨き上げられた製品を扱う感覚は、きっと非常に刺激的でしょう。

しかし、私はこの摩擦が必要です。

新しい言語やフレームワークの学習を始めたばかりの頃は、最も基本的な作業さえも摩擦と戦う必要があり、その感覚は最悪でした。一方、見知らぬコードベースやデータソースに取り組む際には、それを慎重に検討するために数時間の時間を確保する必要があります。私はしばしば文字通り一語一句まで深く掘り下げることをし、特定のファイルを開き、行ごとに読み進めて、文脈を完全に理解し、開発者がなぜそのような選択をしたのかを理解するまで続けます。もちろん、LLM にプロジェクト全体の要約を頼んで時間を節約することもできますが、私はコードの中で「煮詰める」プロセスが必要なのです。私が知りたいのは開発者がどのような選択をしたかだけでなく、なぜその選択をしたのか、そしてそれらの選択がいかにして言語の限界やプログラミングの習慣を反映しているかということもです。私は失敗から学びます。もし LLM がこの苦役を引き受けてくれたなら、私は自分が何をしているのかを本当に理解することは永遠にできないでしょう。

たとえ慣れ親しんだ言語環境で自分のコードを書く場合でも、私は依然として摩擦を重要な手がかりとして強く依存しています。コーディングが非常に困難になる時、それは現在のアーキテクチャにおいて私が誤った道を進んでいることを示唆しています。それは私に、将来の拡張性をよりスムーズにするために再設計を真剣に検討するよう警告しているのです。

このような状況では、私は通常、長い散歩に出かけ（あるいは単に退勤して）、脳に余白を与え、一歩引いて物事を別の角度から考えるようにします。この方法は本当に効果的です。その効果の高さに気づいた私は、たとえ思路が明確であっても、自らを強制的に停止させることにしています。大規模なソフトウェアプロジェクトを開発する際、新しい機能のコーディングを開始する前に、私はまずアーキテクチャ決定記録（Architectural Decision Record、ADR）を作成することを自分に課します。これは自分が何をしようとしているかを記述したものです。これらの文書は、その瞬間の私の考え、問題に対する私の仮定、そしてこのアプローチがもたらす可能性のある結果を記録することを強要します。書き進めているうちに、私は自分の最初の直感に対して盲目的に自信を持ちすぎており、それがプロジェクトを破滅させる道へと導くことに気づいていなかったと気づくことがあります。同時に、将来私の仕事を引き継ぐ後任者にとって、これは「あの当時の連中は何を考えていたのか？」という疑問に対する記録として永遠に優れた手段となります。

LLM を駆使した開発における摩擦への態度とは、理屈を並べることもせず、目を閉じてひたすら書き進めることです。LLM は非常に協力的で、おそらく動作するコードを書き上げ、性能指標も良好で、テストも通過させるでしょう（特にテスト自体が LLM によって作成された場合）。しかし、なぜその道を選んだのかを LLM 自身は理解しておらず、摩擦を感じ取ることもできません。また、あるアーキテクチャ案が別の案よりも明確でエレガントであるという感覚について、あなたに説明することもできないのです。

もしプロンプトを作成するエンジニア自身が洞察力に欠け、良し悪しの区別がついていないなら、彼らは死循環に陥ります。つまり、AI に何度も何度も無理やり摩擦を乗り越えてコードを書かせるというループです。その結果、奇形怪状な抽象論理が生成され、未来のチームに残される唯一の設計ドキュメントは、数年前に AI モデルへの指示として作成された Markdown の孤本ファイルだけになります。そこから当時のアーキテクチャ判断を再構築できることを祈るしかありません！

見てのとおり、私が目撃した「感覚でプログラミング」による成功事例の多くは、開発者自身がその分野の専門家であり（したがって AI の作業を驾驭できている）、あるいは失敗しても大した問題にならない小規模なプロジェクトに限られます。それ以外のケースでは、我々はあの有名な「フクロウを描く方法」ミーム図において描き残された部分が本当に上手で安全なものかどうか、自分たちで判断するしかありません。

私にとってまだ引っかかっている点があります。LLM の販売担当者が「摩擦」を敵視しているとき、彼らは実際には何を暗示しているのかです。広告やデモ、LinkedIn の投稿において、LLM 関連のマーケティングは、孤高の英雄のようなエンジニア（あるいは単独チーム）を描き出しています。彼らは LLM を駆使したプログラミングで、驚異的な速度でアプリケーションやウェブサイトを生成し、即座にリリースするのです。しかし、業界が本当に求めているのは、日常業務の中で LLM を活用することです。実際の現場では、「摩擦」とは通常、欠陥や不適切なアイデアが生産環境に流れ込むのを防ぐための既存のプロセスや規範を指します。

避けられないことですが、「LLM による速度」への狂信的な追求は、最終的に人々自身に向けられます。他のエンジニア、プロダクトマネージャー、プロジェクトマネージャー、テスター、コンプライアンス審査員、あるいはデザイナーなどです。なぜなら、これらの役割も今や「摩擦」と見なされているからです。AI でユーザーペルソナを捏造できるのに、なぜユーザー調査が必要なのか？AI ツールが直接ウェブページのレイアウトを出力するなら、なぜデザイナーが必要なのか？私たちが AI エージェントの群れを統率するマネージャーなのだから、なぜプロジェクトマネージャーが必要なのか？もし他の開発者のコードレビューを待つ必要がなくなり、テストとスキャンに合格すれば自動的にマージされるなら、どれほど素晴らしいことでしょう？もし仕事時間を他人とのコミュニケーションに費やすことがなくなり、純粋なコーディングのみが残る境地へと昇華できるなら、これほど美しいことはないでしょう。

しかし、ソフトウェア開発は協働のプロセスであり、チームのすべてのメンバーが優れた製品の構築に貢献しています。これらの役割を排除したり、LLM の気配を帯びたコードの幽霊で置き換えたりすれば、確かにチームのスピードは上がるかもしれませんが、それが製品品質の向上を意味するわけではありません。それに、このプロセスは間違いなく極めて孤独なものになります。

私は非常に重視している

私が LLM を使わない最もシンプルな理由は、おそらく私がプログラミングをあまりにも愛しているからで、それを機械に譲り渡したくないからです。もし私が画家や音楽家なら AI に頼むことはないでしょうが、プログラミングは私の創造性を表現する手段であり、この純粋な喜びを絶対に手放しません。時には人を狂わせることもありますが、ぼんやりとしたアイデアを少しずつ形にして実際のシステムに変え、特にそこに優雅な実装や面白い挑戦が含まれている場合、そこには大きな喜びがあります。ある夜は仕事用のパソコンを閉じて、プライベートのノートパソコンを開き、私が作りたい面白い新しいものにとりかかります。そして職場では、チームの一員としてソフトウェアを構築するその感覚はさらに素晴らしいものです！私はチームワークを愛し、一緒にソフトウェアを磨き上げる過程を愛します。特に皆が率先して立ち上がり、問題を解決する責任を引き受ける姿を見るのが好きです。チームが単に「プロンプトの責任」を負うだけで、LLM アシスタントが作業を行う場合、このモチベーションが同じように維持されるとは思えません。あるいはもっと最悪なケースとして、LLM アシスタントがチームの一部を直接置き換える場合などです。

責任感があまりにも重要です。過去数十年にわたり、私は異なる立場で強い個人的な責任感を培ってきました。元データ記者として、コード内のバグが非常に恥ずべき新聞の訂正を招いたり、破滅的な訴訟を引き起こしたりする可能性があります。公共技術分野では、エラーは一般市民へのサービスや福祉を提供するシステム全体の崩壊を意味し、それはすべての社会的弱者に波及するか、あるいは単なる一人の個人に影響を与えることになります。私が一度も間違いを犯したことがないとは言いませんが、この仕事の使命を大切にしているからこそ、物事を正しく行うことに非常にこだわっています。私と同じように大切にし、人々のために全力で奉仕したいと願う多くの同僚と共に戦えたことは光栄なことです。

そして LLM は決して「気にする」ことはありません。もちろん、非常に本物らしく装うことはできますが、依然として人間の心臓を模倣しようとする贋作に過ぎず、統計的に同時に出現しやすい単語の組み合わせをつなぎ合わせるだけなのです。ミスを犯しても懊悩することはありませんし、改善しようと努力することもありません。なぜなら内面的な意識を持たず、ましてや道徳的良心などないからです。決して責任を追及されることはなく、したがって私は私の道徳的責任を外部委託することは絶対にできません。

LLM がうまく機能している時は、それはすべてのプログラマーを置き換える天才であるかのように見えますが、LLM があなたのインフラストラクチャ（infrastructure）をすべて削除したり、テスト結果で「嘘」をついたりした時、その過失はあなたに帰されます。結局のところ、プロンプトとワークフローを正確に設定しなかったのは誰ですか？LLM に正しい出力を出させるためにうまく「説得」できなかったのは誰ですか？ああ、もう一度試しましょう、もう一度試しましょう。私が読んだ多くの LLM 教程が繰り返し強調していることは、システムが失敗しないように、最初に必要なすべての指示、修正条項、追加説明をすべて与えなければならないということです。この思考様式はアジャイル開発（agile development）とは真逆です。アジャイル開発は頻繁に方向転換し、タイムリーなフィードバックを得て、チームが正しい選択をすると信頼することを重視します。私たちはまるで 1950 年代初期のコンピュータの分时共有（time-sharing）モードへと後退しているかのようです。ただし今回は、孤独なプログラマーがパンチカードを束ねて列に並ぶ代わりに、厚い「法的契約」を持って機械がプログラムに変換してくれることを期待するようになります。

「凭感觉编程」なんて冗談です；実際には法的責任の問題ではありません。両者の対象読者層の類似性を考慮すれば、これも不思議なことではないでしょうが、LLM（大規模言語モデル）ベンダーはテスラの手法を繰り返しています。安全テストも実施せずに新機能をユーザーにリリースし、さらに奇妙なことに、テスラの狂信的な支持者たちと同様に、LLM の熱心な擁護者たちは壊滅的な結果が生じると、自分自身や他者を責め、それはユーザーの指示（プロンプト）が不十分だったせいだと主張します。この現象をどう評価すればよいのか私にはわかりませんが、テクノロジー業界は極端な資本主義を標準化し、企業と政府が規制責任を放棄したことで、消費者により多くのリスクを負わせています。これは私にとって非常に不安なことです。かつて、誤って子供を殺害する危険性のある「草地飛镖ゲーム」が原因で一人の子供が亡くなったという事件をきっかけに、私たちはそのゲームを全面的に禁止しました。しかし、ユーザーを自殺に追い込んだり精神異常に陥らせたりする AI チャットボットは、AI の革新に伴う当然の代償として扱われています。本当に、「凭感觉编程」によってシステムがクラッシュし、単なる恥辱ではなく人的被害が生じるまで状況が変わらないのでしょうか？

困難な時期には、コードを書くことがいつも私の慰めとなってきました。ある研究では、ロシア人形（テトリス）を遊ぶことが心的外傷後ストレス障害（PTSD）の予防に有効であると示されています。この理論は、脳内の図形の配置や回転を担当する部分を活性化させることで、トラウマ記憶の形成を阻害できるとしています。現在、私は幸運にも PTSD を発症していません（患者さんに対して冗談を言っているわけではありませんが）、しかしこの概念には深く共感します。プログラミングは複雑なパズルを解くようなもので、暗い時期にはいつも私の避難所となってきました。前述の例が示唆しているように、DOGE については非常に詳しくなっています。というのも、過去一年間、彼らの狂気的な行動を追跡・記録するシステムを構築し維持してきたからです。仕事上のプロジェクトとは異なり、これは完全にデータを収集して組み立てる練習であり、隠れようとする組織を太陽の下に晒すことを目的としています。このプロセスは非常に充実したものであり、絶望を何か役に立つ形に変換する方法でもあります。これが悲しみを和らげる手段としてコードを使うのは初めてではありませんが、その効果があるのはまさに、これが多額の労力を要する作業だからです。もし最終結果だけを意識していたなら、この癒やしのプロセスは大幅に損なわれていたでしょう。

他にもいくつかの笑える理由

この小文は私の予想を遥かに超える長さになってしまいました。元々は Bluesky に投稿しようとした短い愚痴の数行に過ぎなかったのです。終わる前に、もう数個の理由を簡単に補足します。

まず第一に、AI チャットボットがデフォルトで採用している油腔滑調な口調が非常に嫌いです。アメリカ東海岸の都市で育った私にとって、見知らぬ人が突然過度に親しげで、不自然に丁寧になるとき、私は本能的に警戒します。なぜなら、それは通常、相手が私の金を騙し取ろうとしているか、布教活動を始めようとしていることを意味するからです。LLM とのチャット履歴を読むと、鳥肌が立ちます。はい、設定を変更して LLM の口調を変えられることは知っています。しかし、不思議なことに、そうするとむしろ全体がより悪く感じられてしまいます。

多くの開発者と同様に、私にも「いつまで経っても完成しない趣味プロジェクト」の草稿を収めたフォルダが一つあります。例えば、Clojurescript でスペリングゲームのクローン版を作ろうとしたことがありました。そうすれば、Blabrecs（※原文のまま）内のコードを使って存在しない架空の単語を生成し、意図的にゲームをイライラさせることができるからです。はい、これは私の個人的な悪趣味かもしれません。文脈を理解してこそ笑えるポイントです。LLM の視点から見れば、これらは失敗に終わったフォルダの山ですが、確かに LLM を使って「一日一アプリ」のような挑戦を行うことは可能です。しかし、過程が結果よりもはるかに重要です。すべてのひらめきを現実のプロダクトに変える必要はありません。通常、私はアイデアをぶつける楽しさや、「このプロジェクトを完成させる必要はない」と証明するために新しい知識を学ぶプロセスから、より多くの収穫を得ています。

私は元々、この記事の中で職場での LLM（大規模言語モデル）利用に関する倫理的問題について議論するつもりはありませんでした。私が気にしていないからではなく、私よりも賢い人々がすでにこの技術がもたらす懸念すべき隠れた危険を非常に深く論じているからです。現在、LLM が児童がいる学校に爆弾脅迫を送ったり、必要に応じて児童ポルノコンテンツを生成したりしている時代において、それらを使用することに本当に安心できません。もし私がこの点について一言も触れなければ、私の心も落ち着きません。資本主義の枠組みの中では、おそらく絶対的な道徳的な消費は存在しないかもしれませんが、それでも、私は少なくとも努力して試みるべきだと考えています。あまりにも多くの人々を悲惨な状況に陥れるようなツールを使って、より良い世界を構築することはできません。

不思議なことに、この LLM の擁護者たちほど、苦しく憎しみ深い生活を送っている人はいないようです。もし開発者が、彼らが新たに得た「生産性の爆発的向上」を利用して、ついに 10 年前にこれらのゲイターたちが偽って崇拝していた週 4 時間労働のユートピア的生活を送れるようになったなら、私はもしかしたら感動するかもしれません。しかし病的なのは、シリコンバレーの多くの人々が、仕事を AI エージェント（人工知能エージェント）に外注した後に、むしろ節約された余暇を使ってさらに多くの仕事を受け入れていることです。彼らは休息や芸術活動、あるいは生活を楽しむためにその時間を使わず、996 労働制度（朝 9 時から夜 9 時まで週 6 日勤務）と、極めて厳格な量化管理環境を歓迎しています。これは、極端な搾取で知られる科学管理学派の創始者であるフレデリック・テイラーが見ても冷汗をかくほどです。おそらく LLM の革命は最終的に私の居場所や職を席巻するかもしれませんが、その前に、私は自分自身を先に墓場へと巻き込まれたくありません。

未来の道はどちらか？

私は自分が未来を予知できるかのように振る舞うつもりはありません。もしかすると、この技術は本当に想像を絶するほど発展し、私が十分に経験を積んでそれを習得していなかったことを後悔することになるかもしれません。あるいは、停滞に陥り、ひたすら過熱した期待の上に築かれた金融の紙芝居が崩れ落ちることもあるでしょう。もしそのような日が本当に訪れるのであれば、私たちはソフトウェア開発を再び人間味あふれる実践として再構築できることを願っています。