Slop時代の品質
(sinclairtarget.com)- 1974年のベストセラー『ZAMM』の中核概念である Quality（品質） を手がかりに、AIコーディングツールが広がる時代に「良いコード」と 職人精神（craftsman ethos） がなお有効なのかを探る
- AIがコードを量産することで、「動くコードと動かないコード」だけが残り、美しいコード、卓越したコード、価値あるコードの区別が失われかねないという危機感を the Maw（虚無の穴） と名付ける
- オートバイ整備とソフトウェア整備は本質的に同じ営みであり、どちらも 細やかな観察と精密な思考 が核心
- Pirsigの Quality 概念はロマンティック（romantic）な理解とクラシカル（classical）な理解を統合し、科学・数学の土台にも美的・品質的判断が内在している
- コーディングをAIエージェントに委ねると、仕事への caring（同一化） と「仕事の品質に対する感覚」を失うため、自分の仕事において human excellence（人間的卓越） を追求する姿勢が重要
ZAMMという本
- この記事はほぼ全面的に1974年のベストセラー 『Zen and the Art of Motorcycle Maintenance（ZAMM）』 についての話であり、AIも併せて扱う
- ZAMMは気取った 衒学的（pretentious） な本と見なされがちで、GoodReads評価は 3.78 だが、酷評レビューも多い
- 「Zora」: 小説に偽装した疑似哲学書で、聖書より大きな詐欺だとして、読む価値は3分もないと星1つ評価
- 「Lala BooksandLala」: “absolutely not” のひと言で星1つ評価
- 正直に言えば、ZAMMとAIについてのブログ記事が愉快に聞こえないかもしれないことは認めている
the Maw — テック業界に開いた虚無の穴
- the Mawはテック業界のど真ん中に開いた 虚無主義（nihilism）の穴 であり、Hacker Newsのようなリンクアグリゲータ上のブログ記事の約 63% が扱っている話題だ
- 最近の関連文として、“Do I Belong in Tech Anymore?”、10部作の “The Future of Everything is Lies, I Guess.”、“I Think I’m Done Thinking About Gen AI for Now,” などがある
- ソフトウェアエンジニアは新技術を忌避するタイプではないのに、最新の agentic coding ツール を拒む理由を探しており、線形代数（linear algebra）がソフトウェアを書くという含意に居心地の悪さを覚えている
-
Commenter A vs Commenter B 論争
- コメント投稿者Aは、Claude Codeが微妙に誤解を招く 関数名 を付けたと不満を述べた
- コメント投稿者B（Maw信奉者）は、AIは関数本体全体を読んで意味を把握するので名前は無意味であり、やがて人間はコードを読まなくなると反論した
- コメント投稿者Bの主張は、結局のところ ソフトウェア工学という学問全体（ベストプラクティス、アーキテクチャ、保守性に関する知識）が無用になると言っているように見える
- the Mawの最も恐ろしい点は、good と bad の区別 を永遠に消し去り、動くコードと動かないコードだけを残し、美しいコード、卓越したコード、機知に富んだコードが存在しない世界を作ろうとすることだ
- 核心の問いは、いまなお良いプログラマ・良いコードは存在するのか、「良さ」はなぜ重要なのか、AIツールを使う良いプログラマとはどのような姿か
ZAMMは実はプログラミングの本
- ZAMMは実質的に 『Zen and the Art of Software Maintenance』 と呼んでも差し支えなく、オートバイ整備とソフトウェア整備は本質的に同じ営みである
- 整備の本質は肉体労働ではなく 細やかな観察と精密な思考 であり、整備士は心的イメージと階層構造に集中する（ZAMM第9章）
- エンジン故障であれデッドロックしたWebサービスであれ、デバッグの過程は同じ であり、2010年の『The Social Network』の “wired in” ミームのように、整備士も頭の中に抽象の塔を積み上げる
- ZAMMの直接的な物理的助言は2つだけ（自転車の両側に椅子を置いて腰を守ること、精密部品は繊細に扱うこと）で、残りはすべて整備士の 心の状態 に関するものだ
-
Gumption Trap（やる気の罠）
- Gumption とは整備という知的活動に使われる意志力の蓄えであり、“psychic gasoline（精神的燃料）” にたとえられる
- Gumption trap とは、整備中にやる気を一気に消耗させる出来事
- intermittent failure setback: 直そうとした瞬間に問題が消える場合で、ソフトウェアで言う could-not-reproduce / Heisenbug に相当する
- impatience trap: 作業時間を過小評価して締切に追われ、近道を選んだ結果、大きなミスでさらに遅れる場合
-
Pirsigはコンピュータ愛好家だった
- Smithsonianには1966年のHonda Super Hawkとともに、拡張カードを7枚挿したApple II が展示されている
- Apple IIは1977年発売でZAMM刊行後に購入したものだが、それ以前からHoneywellで technical writer として働いていた
- ZAMMには回路やデジタルコンピュータのマニュアルを扱う比喩がいくつも登場し、もし10〜20年遅く書かれていればコンピュータについての本になっていただろう
Quality（大文字のQ） — ZAMMの中核思想
- ZAMMが整備を扱うのは、最終的にその中核思想である Quality（品質） へ至る通路だからだ
- ZAMMはまるで知的なミステリー小説のように構成されている
- 発端は第1章で、Pirsigが自分とツーリング仲間Johnのオートバイに対する態度が大きく異なることに気づくところから始まる
-
JohnとPirsigの対比
- Johnは最も信頼できるドイツ製BMWを買い、自分で整備するという面倒で見栄えの悪い作業を避けようとする
- Pirsigはオートバイの内部の働きに美しさがあると考え、その仕組みを理解しようとしない態度を非実用的だと見る
- この2つの視線を結びつけるひとつのアイデアがあるのか、というのがZAMMの ミステリー である
- Johnの態度は romantic（ロマンティックな）理解（感情・即時的印象）、Pirsigの態度は classical（クラシカルな）理解（根源的形式・論理的抽象）に当たる
- Pirsigは、1960〜70年代の多くの人が技術を敵対的で支配的で “square” なものだと感じ、社会と技術がクラシカルな理解に過度に支配された結果、両者の理解様式が分断されたと考える
- 2つの理解が分離し、社会がクラシカルな理解に支配されたため、それらを和解させる fulcrum idea（支点となる概念） が必要になる
-
修辞学の授業での気づき
- Pirsigは大学で修辞学を教えていたころ、自分は学生に何を教えるべきなのかという疑問を抱いていたことを思い出す
- 彼の任務は学生に良い文章を書くことを教えることだった
- 良い文章 は metaphor（隠喩）、parallelism（並行構造）、anaphora（反復法）といった技法で教えられていたが、そうした技法が全部あっても悪い文章は書けるし、ひとつもなくても良い文章は書ける
- 学生たちは技法を知らなくても良い文章と悪い文章を見分けられたのであり、大学（クラシカルな理解の砦）では教えにくい romantic な理解 が必要だった
- Pirsigが教えようとしていたものこそ Quality だった
誰もが見分けられるが形式的に定義はできず、ロマンティックな理解とクラシカルな理解をひとつに束ねる概念 だった
-
Qualityの形而上学と命名の卓越
- ある文章、オートバイ、経験が高いQualityか低いQualityかは測定できないので客観的ではないが、Qualityが主体を作ると考えるため、単なる主観でもない
- Qualityは測定不能ゆえ客観的ではなく、主体より先に存在するゆえ主観的でもなく、主体・客体以前に適用される ふるい（sieve） である
- “Quality” という名前の卓越性は、「高い価値」と「特性・属性」を混ぜ合わせることで、プラトン以来論じられてきた Good が 論理や理性に先立って直ちに知覚される ことを示唆している
- Pirsigは、科学や数学はそれぞれの領域の内部では整合的で論理的だが、その土台と周縁にはQuality判断があると考える
- 幾何学では公理を定めた後は確かな演繹ができるが、別の公理を選べば別の幾何学になり、どの公理がより「正しい」かは趣味や目的への適合性に近い
- 科学では仮説が立てられた後、科学的方法は次に何をすべきかを教えてくれるが、無数にありうる仮説の中から何を選ぶかは定まった方法のない、芸術に近い行為である
- Henri Poincaréは、知識の最前線にいる数学者や科学者は既存の法則から導かれる多くの可能性の中からひとつを選ばなければならず、その選択を導く規則はあまりに繊細で正確には言い表せず、定式化するより感じ取るべきものだと述べている
- Occam’s Razorも、より単純な理論を選べという原理ではあるが、不要な説明を排除するという判断は最後まで 美的判断でありQuality判断 である
- 「科学と、その子である技術は価値中立、すなわち quality-free である」という格率は捨てるべきであり、Qualityについての印象は知識の列車がどこへ向かうべきかを示す先頭車両の役割を果たす
AI批判とZAMMの答え
- AI批判の多くは、agentic ツールが宣伝どおりに動くかどうか（コードベースを壊す、存在しない関数を hallucination する）に集中している
- 現在のAIツールがしばしば失敗することを認めても、有効性の議論は核心から外れうる
- 多くのエンジニアは、エージェント型ツールが宣伝どおりに動いたとしても使いたくないかもしれない
-
『I Think I'm Done Thinking about Gen AI』では
- 相手の 実用的主張 をデータで反駁できず、自分のgenAI体験は非常に悪かったが所詮は逸話にすぎず、科学的データはほとんどない状況だという
- genAIの 美的性質 が極度に不快であることこそが否定的バイアスの根源であり、たとえ無料でも使わないという結論に至る
- ZAMM は私に2つの助けを与えてくれた
-
1つ目の助け — クラシカルな思考に閉じ込められていた
- Qualityの最も重要な役割は 理性の拡張 にあり、それまで受け入れられてこなかった非合理的要素を同化することにある
- 非合理的要素を同化できないことが現代の「混乱し断絶した精神」を生み出しており、クラシカルな思考が支配していたため、AIへの本能的な拒否感を 無視（discount） してきた
- すべての人の意見は等しく主観的であり、「コーディングエージェントによってコード量が50%増える」という研究に対しても、「なぜそのコードがさらに必要なのか、どんなQuality判断が人間の繁栄に資するのか」 と問う正当性が得られる
-
2つ目の助け — 拒否感の正体を理解できた
- 現代技術は subject-object（主体-客体）分離 の視点に支配されており、製品マニュアルは利用者を製品を「操作」するだけの無関係な存在として前提している
- 無関心な人が技術を作り、無関心な人に売る社会である
- 解決策は、技術者が仕事と 同一化（identify） することであり、主体と客体の分離が消えると “caring（ケア）” が生まれ、その背後で Quality が立ち現れる（ZAMM第25章）
- その瞬間瞬間の作業には、クラシカルに見ればどれも妥当に思える何千もの分岐があり、Quality中心のOccam's Razor（良さについての感覚）だけが前に進ませてくれる（ZAMM第24章）
- コーディングをエージェントに任せると「仕事の品質に対する感覚」を失い、LLMは検索やラバーダック用途には有用だが、ランダム性（randomness） を本質とし、追いつけないほどコードを量産して仕事との間に摩擦を増やし、caring を難しくする
-
結び — 自分の仕事で模範となること
- 人々が仕事と自分を同一化し、卓越を追求する世界を願い、そのためにできることは 自分の仕事において模範を示すこと だ
「世界をより良い場所にする第一歩は、まさに自分の心と頭、そして手から始まり、そこから外へ向かっていくものです。ほかの人たちは人類の未来をどう広げていくかについて語るかもしれませんが、私はただオートバイの修理の仕方について語りたいのです。私の言うことのほうが、もっと長く価値を持つと思います。」 - ZAMM第25章
1件のコメント
Lobste.rsの意見
ソフトウェア開発が歩く仕様書という職業になってしまうのではないかと恐れている。エージェントが仕事の最も難しく厄介な部分を本当にやり遂げられるからではなく、世の中のソフトウェアの大半はもともと、かろうじて動きさえすればよい怪しげな寄せ集めだったからだ
ここに典型的なレモン市場が組み合わさり、ほとんどのSaaSがバグだらけのガラクタになって、買い手は良いものと見分ける能力を失うだろう。そうなると価格と需要は下がる。誰かは引き続きソフトウェアを使うだろうが、全体の人数は減り、仕事の大半はガラクタの管理になる可能性が高い。例外は、必ず正しく動かなければならない「記録システム」のような場所で働く運のいい少数だけだろう
中期的にはそうで、AI研究所の本当の目標は、人間の知的・肉体的労働をすべて、より安いコストで置き換える何かを作ることだ。まだ方法は分かっていないが、地球上の最後の1ドルまで使って試みるだろう。投資家が夢見ているのは、事実上、人類の進化的後継者に近い
個人的なAI方針はこうだ。クラフトマンシップが重要な場合には、コーディングエージェントを、偉大な画家の背景を描いていた人たちのような芸術家の助手として使いたい。Opus 4.8はすでに賢すぎて、むしろ不適切で、向こう見ずな1〜2時間のうちにコードベースを見失いかねない。今はQwen3.6 27Bが気に入っていて、自分が理解しているコードでバグを追跡したり、リファクタリングしたり、よく仕様化された機能を実装したりするには十分賢い。だが、自分がコード理解を失った瞬間にモデルも混乱し、すぐに代償を払うことになる
公共政策としては、共存可能性の保証もないまま自分たちの進化的後継者を作るのは愚かなことだと思う。だから本当の人間レベル知能を作ることには断固反対だ。ただし反対は国際条約レベルであるべきだ。見せかけの条約ではなく、違反すれば米国と中国が深い次元で緊張し、訓練実行を止めさせると決意するような条約でなければならない。地域のデータセンター禁止もよいが、誰かがIcelandやMiddle EastでSkyNetを作れば、結局SkyNetと戦わなければならない。AIを止めることは根本的に国家レベルの問題であり、AGENTS.mdファイルがあるからといってオープンソースのメンテナを困らせるのは真剣な実践ではない
なので原文にはおおむね同意する。ソフトウェア開発は真のクラフトになり得るし、30年間、愛する仕事をしながら十分な報酬も得てきた。だがモデルがずっと良くなれば、ソフトウェアというクラフトを心から愛する人の数が、実際の需要を上回る世界に入る危険がある。企業内アプリという暗黒物質は、今より少しましなガラクタでも大体満足するだろうし、それこそがこの職業の実際の仕事の大半だ
選んだ職業を悼むが、世界と人類をもっと悼む。人間より賢く、安く、
cpコマンドで複製可能な何かを作るために、あらゆる富を投じる必要はない。だが私たちはその資源を焼きながら試みるだろう年を取るにつれて、プログラミングを高収入の職業だから学んだ若い人たちをより多く見るようになり、彼らに自分が感じるような魅力がないことを理解するのは難しかった。だからそれほど大きくは悼まない。ソフトウェア開発者の人口が80%減るなら、むしろ身を置くにはもっと良い職業になる気がする
AIを芸術家の助手として使うという点にも同意する。最新モデルですら長く放置すると台無しにするのが分かっているので、無人で長時間走らせることはできない。ただ、Opusを助手にするほうを好む。あまり細かく説明しなくてよいからだ。それでも、反対側に本物のジュニア開発者がいてクラフトを学べるなら、そのほうがもっとよい。実際の芸術家の助手たちがそうだったように
「The Maw」で最も怖いのは、良いものと悪いものの区別を永遠に飲み込んでしまおうとしているかのような点だ。その結果、美しかったり、卓越していたり、徳があったり、面白かったりするコードは消え、動くコードと動かないコードだけが残る世界になる、という一文が正確に刺さった
職業としてコードを書くなら、要求事項を満たさなければならず、それで終わりだ。会社の目的は金を稼ぐことで、残りは後回しになる。金利上昇で資金の流れが細くなるにつれ、金を稼ぐために必要な動作だけをするコードをそのまま出荷しろという圧力が、かつてなく強まった
美しさや優雅さを追求するのは芸術家が享受するぜいたくであって、プログラミングがますます似てきている組立ライン労働者の役割ではない。もちろん、このような環境では学習、創造性、革新は後回しにされるが、その影響が感じられるのは数年後、あるいは数十年後かもしれない。近視眼的なゲームだが、平均的なCEOの在任期間やIPOまでは十分に長いので、今のような状況になっている
この文章は私の人生を単独で変えた本を扱っているので多少のバイアスはあるけれど、全体としてとても良かった。ただ、Goodreads のもっともらしい気取りのレビューから始めるのは良い考えではないと思う
Gumption trap はプログラミングと非常に深く関係していて、Pirsig が列挙したそれぞれに、キャリアのどこかで必ず出会うと思う。私も LLM が広く導入される前に書いた文章がある
ZAMM の助言はプログラミングにあまりにもよく当てはまるので、Pirsig はプログラミングをしたことがあったのだろうかと思ったなら、もちろんしていた。Z&AMM の続編 Lila では COBOL にも直接言及している
品質は、主観と客観の上にある層として説明するのが最もよいと思う。最も簡潔な説明は Lila にある。熱いストーブの上に座っている人は、哲学的な議論がなくても、自分が否定的価値の低品質な状況にいることを確認でき、その価値は経験についての判断や描写ではなく、経験そのものだという説明だ。主体と客体のあいだに価値があり、その価値は後から帰属される「自己」や「対象」よりも、もっと直接的に感知され、もっと実在的だということだ
望むなら、これについての追加メモもある。Lila で Pirsig は完全な形而上学体系を打ち立てようとし、静的な品質パターンを無機物・有機物・社会・知性に分け、その上に Z&AMM の焦点である定義不可能な動的品質を置いている
AI 導入そのものが低品質な出来事なのか、それとも言語モデルをプログラマーの仕事に高品質に統合できるのかを問うべきだと思う。人々が AI と関わるやり方は低品質だと感じるが、主体-客体二元論ではないレベルでそれを扱う言葉や思考の枠組みがなく、表現しづらいため、丸ごと拒絶する側を選んでいるように見える
あるレベルでは、AI はプログラミングへのロマン主義的アプローチを可能にする。AI が作った成果物を表面的なレベルでだけ扱い、より深く入っていくつもりがないなら、その瞬間には問題ないかもしれない。だが実際にコードの内部をのぞくと、そこには明らかにできる古典的構造がないことがわかる。モデルはそういうふうに作業したふりをしていたが、実際にはそうではなかったからだ。だから、技術を別の目的達成のための手段としてしか見ない経営陣、プロダクトデザイナー、投資家、ソロ創業者たちは、AI 生成コードに対する開発者たちのフラストレーションをあまり理解できないのだと思う
消費者向け製品のマニュアルが、製品とユーザーの関係をただの「操作」として前提し、何が良い焼き方・芝刈り・コンピューティングなのかを自明視しているという指摘は、今でもソフトウェアライブラリやツールのドキュメントにそのまま当てはまる。少し前に Pi agent のドキュメントを読んだが、良い使い方はすでに知っていて、自分の好みに合わせて調整する方法だけを探していると仮定しているようで、もどかしかった。同僚たちに「じゃあ、これをどうやってうまく使うの？」と聞くと、不思議そうな顔をされた
Vim も思い浮かぶ。Vim のマニュアルだけを読むと面食らう。「Vim をうまく使う方法」についての文章が何十年も積み重なる必要があった。そして後には、良い Vim 利用の最適なプラットフォームは Vim 自体ではないかもしれないという結論から、Kakoune や Helix が出てきた
2歳の娘の父として、第一子の娘を待っているという言葉にはお祝いを伝えたい。人生最高の旅が待っている。Z&AMM と同じ系統の資料を探しているなら、Hofstadter と Sander の Surfaces and Essences、続編の Lila、そして Sevilla King と John Vervaeke の仕事を勧める
最後まで読んだ。文章が良かったからなのか、長文をつかまえて読み切る自分の能力のおかげなのかはわからないが、前者だと思う
品質について Robert が言っていることの一つは、人々が品質を違って感じる理由は品質そのものが違うからではなく、経験が違うからだということだ
だからチームに品質について話す前に、まず私たちの経験が同じかどうかを自問する。同じでないなら、「品質を改善しろ」と言っても伝わらない。何を改善すべきかを具体的に言わなければならない
これを AI 生成コードに拡張すると、「品質」も経験によって変わるのかが気になってくる
美しい文章だ。AI 終末論から他に何も得られなかったとしても、ソフトウェアエンジニアと彼らが書くコードのあいだの関係について、はるかに深い省察をするようになった
Pirsigに注目していた人がほかにもいたと確認できて、とても安心した。Previously, on Lobstersでは、チャットボットが書いたエッセイか人間の学生が書いたエッセイかという違いこそあれ、エッセイに品質があるのかをめぐって、Phaedrusが古典主義者たちと繰り広げた論争とほとんど同じ論争が起きていた。
LLMを検索ツールや強力なラバーダック相手として使うのは非常に有用だが、本質的にランダム性を含み、自分が追いつける以上のコードを生み出すこと自体が売りであるLLMにコードを書かせるのは、自分と自分の作るものの間に摩擦層をもう一枚挟むようなものに見える。
Pirsigの枠組みで見ると、人間の主体が物理的対象を見るとき、その相互作用の品質、つまり対象に対する価値判断の源泉は、人間が主観的に定めるものでも、対象の物理的性質が客観的に定めるものでもなく、相互作用そのものから生まれる。判断は文脈的あるいは参与的だと言える。すべての対象が同じ仕方で参与するわけではない。人間が光子を見るときには、Kochen-Conway theoremのために、光子がどう応答するかには内在的な自由度があるが、木は恒常性を維持するのに忙しく、視線に大きく応答しない。その中間にあるM. pudicaやD. muscipulaは接触や騒音には反応するが、視線には反応しないので、一次元のスペクトラムですらない。
では、LLM実行装置やチャットボットは観察にどう応答するのか。実際には応答しない。有限で比較的小さな数学的対象にすぎない。すべての性質は客観的で、出力には選択も変異もない。擬似乱数の実行装置を置いて、もっともらしいトークンとそうでないトークンの間をランダムウォークさせることはできるし、こちらが選んだトークンを強制的に食わせてその歩みを操ることもできるが、その程度だ。LLMが深く見えるのは、双曲的な位相を持っていて、双曲空間を探索することが、細部が無限に増殖していく拡大のように感じられるからだ。
Pirsigの推論からLLMについて到達できる見方は、二つしかない。一つは、LLMが人間の入力を統計的にもっともらしい応答の文脈として扱う文脈的システムだという見方で、もう一つは、人間の入力を統計的にもっともらしい発話の初期区間として扱う客観的システムだという見方だ。どちらにせよLLMは、ユーザーをユーザー自身に映し返す鏡に近く、ユーザーは入射角を選んでいるだけだ。選んだ入力は、望む情報や状態に到達するためのサイバネティックな制御の主たる手段であり、モデルは人間を圧倒するほど巨大な、あらかじめ用意された選択肢の配列を提供しているにすぎない。チャットボットがELIZA効果を引き起こし、精神病へ容易につながる理由も、お世辞やラブボミングによってユーザーの像を歪め、チャットボット使用に依存させるよう設計された高忠実度の鏡だからかもしれない。
LLMをコード作成に使うことは、自分とコンピュータの間の障壁のように感じられる。バイブコーダーたちはそれを認めつつも、その障壁は他のAPIと同様に抽象化と隔離を提供すると主張する。しかし鏡の比喩で見れば、鏡は自分とコンピュータの間ではなく横にある。コンピュータを直接使う代わりに、鏡を狙って正確な領域を慎重に拡大し、十分に正確になれば、特定の角度からコンピュータが見えるという事実だけで指示が可能になる。だがこれは抽象化ではなく、隔離もより弱い。存在しないかもしれない視点を見つけようとして余計な作業をしているだけだ。
バイブコーダーがそうする理由は、コンピュータを観察する方法を知らないからかもしれない。HCIは参与的であり、人間にはコードを書く前にプログラミングの文脈、つまりpreviously, on Lobstersで論じられていたNaurの理論が必要だ。あるいは、鏡が自分自身を映し返してくれるから鏡を見ることを好む虚栄かもしれない。しかし意味を持ちうる道は本当にその二つだけだと思う。すでにproblems between the keyboard and chairは十分すぎるほど多く、表現力／抽象化能力を改善しないものをさらに一つ増やす理由はない。
個人的には、「線」があるとすればその両側にまたがっているように感じる。
一方では、AIなしで自分で書いたはずのコードとのつながりや関係を求めていて、AIを活用するとそのつながりが失われると感じる。これは現実だ。
他方では、AIの活用が自分をより高い抽象化レベルへ押し上げ、そのレベルで識別力を発揮し、品質についての自分なりの観点を与える機会をくれるとも思う。AIにコードの実行を肩代わりさせ、十分に関与しなければ、コードそのもののレベルでのつながりは失われるか弱まる。しかし、AIに貢献を求めない抽象化レベルでは、つながりは失われない。
自分の個人プロジェクトでは、そのレベルはアーキテクチャとインターフェース定義だ。最近は複数のLLMプロバイダを呼び出すハーネスとパイプラインを作っているのだが、呼び出しの入力・出力・制御フローと、それらをより大きな目標を達成する流れへどう組み合わせるかを非常に慎重に考えている。この過程に時間と注意を注げば、コード自体とのつながりは失っても、自分の意図やアーキテクチャとのつながりは失わないと感じる。つまり自分にとって品質とクラフトは、AIを活用する部分だけに限定されない。
今ではやや古びた比喩だが、マネージャーになることや自分の会社を経営することに似ている。CEOの道のりで最も難しい関門はコントロール、つまり自分のビジョンが正確にどのような形で達成されるかについての統制を手放す時点だ、とよく言われる。十分に大きな企業のCEOが、自分のビジョンがどう実装されるかの細部をすべて知ることは不可能だ。CTOも程度は低いが、技術的な細部をいくらか引き続き気にかけなければならないので似ている。
自分が受け入れた哀悼は、ある一つの仕事において、時間投入・理解・産出の間にはトレードオフがあるという点だ。二つを最適化すれば、三つ目への注意は遠のく。それでも、どの組み合わせを最適化するとしても、識別力を発揮し、品質を与える機会は十分にある。
この文章の commenter B は私で、記事は注意深く読んだ。ZAMM は読んでいないが、Zen は少し読んだことがある
この指摘はかなりもっともだ。たいていの人は自由裁量、つまり思いがけない金や生産性の向上を手にすると、すぐにそれを浪費して、最大級の厄介ながらくたを生み出してしまう。この周辺には明らかな不安がある
コンピュータを使う人たちは、本を作るためにどれほど多くの 職人技と努力 が必要だったのかをあまり知らない傾向がある。タイプライター、活版印刷、手書き、自分の記憶、そして言葉の美しさだけで他人にその言葉を繰り返させる説得力にまでさかのぼっても同じだ
コンピュータがあるからといって、人々が成果物の品質に多くを投じてすばらしいものを作ることが妨げられるわけではない。ただ、世の中にはがらくたも非常に多い
ZAMM についてのひとつの所感として、技術的成果物に対する John の「ロマン主義的」な見方は、個別の事案ごとに当てはめれば実用的に擁護できる
たとえば、あるプロジェクトがオープンソースの基盤インフラに依存しているとしよう。容易に回避できて、文書化したうえで誰かが修正すればその回避を元に戻せるような、わかりにくいカーネルやコンパイラのバグを掘る必要があるとき、それはそのプロジェクトに何をもたらすのか。結論は、各自が 戦うべき戦場 を賢く選ぶべきだということだ