プログラマーは翻訳家と同じ運命？AI時代に問われるVibeエンジニアリング
引用元：https://news.ycombinator.com/item?id=45503867
2023年のGPT-4登場時、翻訳業界でも同じような問題が起きたんだ。AIが人間レベルに近づいて、苦労して身につけたスキルが無用になったって翻訳家仲間は落胆してたし、LLMを使うと翻訳の楽しさが減るって言ってたよ。僕（68歳）はVibeエンジニアリングみたいなAI活用を受け入れてるけど、もし若かったら別のキャリアを探したかもしれないね。
LLMを語る上で翻訳ってすごく良いテーマだね。翻訳って世間ではあまり評価されてなくて、本の翻訳者なんてほとんど知られてないのが残念。それにAIが出る前から単語数で報酬が決まることも多かったしね。将来性があるのは、人間が責任を負うことになる法律翻訳とか、直接人と会うライブ通訳くらいだと思うな。
「最近みんな本を読まない」ってよく聞くけど、それって全然違うよ。書籍業界は今までで一番健全なんだから。
最近発表された研究結果だと、米国では逆のことになってるみたいだよ。過去20年で本を読む人の数が激減してて、機能的非識字者も増えてるって。正確な数字は忘れちゃったけどね。
以前、何人かのプロの翻訳家と話したんだけど、AIが彼らを置き換えるって考えにみんな否定的で、怒る人までいたんだ。彼らの分野に何が起こるか認識できてないって気の毒に思ったよ。AIに一番影響を受けるのは翻訳の分野かもしれないね。
ソフトウェアエンジニアは翻訳家なんだよ。僕たち（比喩的なコミュニティとして）は変化を否定してるんだ。「AIコードは間違ってる」とか、いろいろ理由をつけてね。でも、結局のところ、変化を受け入れるのは本当に難しいんだよ。
ソフトウェアエンジニアは翻訳家って意見に賛成だよ。最近、自分の仕事の一部が自然言語をプログラミング言語に翻訳してるだけだと感じてるんだ。LLMは知識が豊富で、コンテキスト理解と翻訳には強いからね。コーディングの楽しさが減るのは嫌だけど、AIが80%のプログラミングをこなすようになったら、チェスやGoのプロみたいに、プログラマーとして残れるのはごくわずかになるだろうね。
LLMは僕の開発作業には役立たないってのがフェアな評価だと思うな。経験豊富な開発者ほどLLMを使うと作業が遅くなるって研究もあるんだ。翻訳は自然言語の入出力で、プログラミングとは全然違うよ。Dijkstraが70年代に自然言語プログラミングはナンセンスだって言ってたけど、今でもその主張は有効だと思うな。Microsoftのローカライズされた開発ドキュメントなんてひどいもんだよ。
今のLLMがシニア開発者にはあまり役立たないって意見には賛成だよ。複雑な問題は解決できないけど、ソフトウェア開発にはボタンの挙動みたいな些細な仕事もたくさんあるよね。そういうのはAIがやってくれるようになって、エリートだけが難しい問題に取り組むようになるかもね。僕はコーディングエージェントにバグ修正や新機能実装をさせることが多くて、僕より良い解決策を出すこともあるから、自分は経験豊富な開発者じゃないのかも。Dijkstraの自然言語プログラミングのアイデアってEWD667のこと？https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667…
記事の比較は素晴らしいね。職人技から大規模システムへ移行する感覚は、車を一台ずつ作ってた人が組立ラインで働くようになるのと同じだと思ったよ。Vibeコーディングは組立ラインよりはマシだけど、人間的な感情は残るよね。
“Vibe based”より”agentic coding”がいいね。俺のプロセスはClaude Codeで仕様を書き、TDDを使って、自作ツールでコード品質を守ってる。例えばHTTPルートハンドラがサービス層経由でDBにアクセスするよう強制するツールとかね。ClaudeはTDDを使うよう時々リマインドが必要だけど、4.5は4.1より記憶力いいよ。PRと仕様をGeminiに渡して不一致をチェックするツールも使ってる。結局は、何が欲しいか知ってて、エージェントが逸脱してるのを見抜くのが一番大事だね。
“Vibe”って言葉は本来の意図を損なうと思うから、もっと良い用語を考えてたんだ。”Agentic coding”はまさにそれだね！俺もこれからその言葉を使ってみるよ、広まるといいな。
Github CopilotやRoo Code/Clineのチーム推奨を書いてて、専門的な文脈で”vibe coding”を使うのを避けたかったんだ。”聞いたことがあるかもしれない用語…”って感じで一度だけ含めたけど、すごく不真面目に聞こえて使うのが馬鹿らしく感じたよ。俺も”agentic coding”に行き着いたんだ。少しぎこちないけど、ソフトウェア業界全体にとって恥ではないから、喜んでこれを使うよ。
「別のツールがレイヤー分離に違反するコードをブロックし、HTTPルートハンドラがサービス層経由でDBにのみアクセスするよう強制する」ってあるけど、それってLLMエージェントなの？それとも言語サービスとかビルドツールセットみたいな他のツール？
“ツール”って言ってるのは、Pythonスクリプトのことだよ。この特定のツールはClaude Codeが一発で書いた約100行のPythonコードで、リポジトリのscripts/ディレクトリにコミットしたんだ。それをpre-commitフックやテスト実行時、CI中に使えるようにしてる。100行のスクリプトはミリ秒で終わるし、トークンも消費しないから、1日数回走らせられる。繰り返しが必要なら、LLMにコードを書かせれば確実性が出る、って考え方だね。
「モデルにTDDを使うようリマインドする」ってあったけど、それってどういうこと？エージェントは実際にレッド・グリーン・リファクタリングのループを回してるの？それとも結果を一気に生成しちゃうだけ？
もし頼めば、Claude Codeはテストを書いて、コードを書いて、どちらかを修正してパスさせるループを確実に回せるよ。頼まなければ、一発で全部生成しちゃって、初回で正しくなるかどうかはわからないね。
同意だね。”Vibe”は「感覚に頼る」って考えを続けてしまう。このエンジニアリングは厳密で完璧だから、合わないよ。
前は、希少で需要があって高給なスキルがあったけど、今はAIエージェントを使った新しいコーディング方法が未来だって聞いて、なんかすごく落ち込むんだ。エージェントを待つのは楽しくないし、複数のタスクを管理するフロー状態に入るのも難しい。もういっそ営業とか全然違う仕事に転職したい気分だよ。
そう言われると本当に申し訳ないな。僕の目標の一つは、「プログラミングスキルはもう役に立たない、誰でもLLMにコードを書かせられる」って考えに反論することなんだ。既存のソフトウェア開発スキルは、コーディングエージェントが加わることで、もっと価値が高まると思うよ。君が今まで学んだことは全て、新しいツールで影響力を加速させるのに役立つはずだ。記事でも言ったけど、AIツールは既存の専門知識を増幅させるから、スキルや経験があるほどLLMやコーディングエージェントから良い結果を引き出せるんだよ。新しいVibeコーダーがChatGPTでクールなUIを作れても、KubernetesクラスターへのCI/CD付き自動テストを組んだり、設計した大規模プロジェクトで3つのエージェントを同時に指揮したりはできないからね。
心配しないで、たぶんそれはインポスターシンドロームだよ。君の開発スキルはまだ十分使える。エージェントは、いつも君が指導したり、レビューしたり、修正してあげないといけないジュニアデベロッパーだと思って考えてみて。
パフォーマンスが不安定で、しょっちゅう嘘をつくものと付き合う忍耐力が、既存の開発スキルの延長とはちょっと思えないな。これは開発者が使うツールとも違うし、一緒に働く人とも違う。それに、今のエージェントの使い方も、1年後には完全に古くなってるかもしれないしね。加速も一貫してないし。Generative AIは信じられないくらいすごいけど、同時に全然信頼できない。それが面白いけど、すごく不確かでもあるんだ。今のエージェントをマスターするのに投資する価値があるのか、それとももっと良くなるまで待った方がいいのか、分からないんだよ。君は「コーディングエージェントから良い結果を引き出すのは、人間と協力するのに不快なほど似ている。明確な指示を与え、必要なコンテキストを確保し、彼らが作ったものに実行可能なフィードバックを提供する必要がある」って書いたけど、それは人間については正しい。でも、僕にとって一番大事なことが抜けてるんだ。それは、僕が彼らに与える情報じゃなくて、彼らが僕にくれる情報のこと。良い結果を出すには、スキルレベルに関わらず、彼らがどんな問題にぶつかったかとか、僕が見落としていたかもしれない新しい知識を教えてくれると、絶対的に信頼できる必要がある。それがなければ、良い結果は出ない。もしそういうコミュニケーションが、読まなきゃいけないコードを通してしか確実に起こらないなら、それは非効率的だ。エージェントが、僕が知るべきこと（人間と働くときに信頼すること）を教えてくれないなら、その経験自体が破綻しちゃうんだ。
これは本当だけど、仕事のスタイルがすごく変わったって感じるな。技術的なことより、はるかにマネージャー寄りになったんだ。プロジェクトマネージャーとピープルマネージャーを混ぜた感じだけど、人がいない状態。全体的に生産性が上がったかどうかはまだ不明だけど、楽しさは減ったよ。
君がやろうとしていることは感謝してるけど、僕はスキル価値が下がったから落ち込んでるわけじゃないんだ。お金は楽しんだけど、それだけじゃなかった。新しいコーディングのやり方が、僕の頭に合わないから落ち込んでるんだよ。集中力と注意力が僕の最も大切なリソースなのに、Vibeコーディングはそれをめちゃくちゃにする。システムのあらゆるレベルが見えて、エレガントにシステムを意のままに操るような、コーディングのフローに没頭したいんだ。代わりに、誰か／何かのコードをレビューするのに閉じ込められてて、それは常に骨の折れる作業で、フローなんかじゃない。脳の中でひどいことが起きてるのを感じるんだ。せいぜいモチベーションの低下、最悪は完全に興味を失うって感じかな。例えるなら、僕が土を触ったり植物に歌を歌ったりするのが好きな庭師だったとして、君が「ガーデナーニュース」で最新のトラクターの素晴らしさを説いて、庭師としての僕の影響力を加速させるって言ってるようなものだよ。でも、そのトラクターはうるさいし不快だし、ぶっちゃけ醜いし、たとえ僕自身が使わなくても、近所の人はみんな使ってるから、自分たちで野菜を全部作っちゃって、僕や誰とももう物を交換しようとしないんだ。だから、何十年も僕に喜びをくれた庭を悲しく眺めて、せめてトラクターの排ガスを避けられる場所に引っ越そうと考えるしかないんだよ。
これまでの僕の教訓だよ。1. 楽しくない。2. 「レビュー疲れ」が半端ない。3. 僕なら絶対入れないような余計なコードが山ほど。4. エージェントが楽観的すぎることにイライラする（「タスク#3は98%のテストが失敗したけど、無事に完了したよ。[:useless_emojis:]」みたいな）。5. エージェントがルーティンで無駄な深掘りしたり、堂々巡りしたりすることにイライラする。それを修正する労力（Anthropicはそういう時は最初からやり直すのが良いってハッキリ助言してるけど、それは賢明なアドバイスだとしても、過去5時間を無駄にした上に何も新しいことを学べなかった気分になるんだ）。僕はエージェントを使うのをやめて、LLMもごくたまにしか使わないよ（例えばレビュー用とかね。たまに僕が見落とした詳細を見つけたり、面白い解決策を出したりするから）。でも、エージェントなしだと仕事がはるかに楽しいんだ。
LLMを「指導」するのって、時間の無駄だってことでみんな同意しないかな？ジュニアデベロッパーに時間を使うのは、彼らが成長するためだよね。LLMは成長しないんだからさ。
複数のエージェントを同時に、プロジェクトの異なるエリアで指揮できるなんて、実用的な限界はどうなんだろうね？グリーンフィールドのソロプロジェクトでシニアデベロッパーをやってるけど、フロントエンドとバックエンドの2つのエージェントを並行して動かすだけでも疲れるよ。ほとんどの時間は、僕が仕様書を書いたり、レビューしたり、受け入れテストをするのを待ってる状態。スプリントしてるみたいで、毎日できることじゃないと思うな。タスクが細かすぎるせいかもしれないけど、もしもっと大きなタスクもそれに比例して仕様書作成やレビューに時間がかかるとしたら、2つ以上（まあ、3つかな、僕が遅いだけかもしれないけど）を現実的に並行できるとは思えないんだ。それ以上になると、もう完全にVibe Coding（あるいは仕様駆動Vibe Coding）の領域だと思うよ。
LLMが価値を生み出すって考え、マジで理解できないんだよね。むしろ価値を燃やしてるだけじゃん。過去の仕事を食い潰してるから、やっと使える仕事が出てくるって感じ。無駄が多いし、かなり都合の良い状況でしか役に立たないよ。電気とプロンプトで仕事になるんじゃなくて、電気とプロンプト、それに過去の仕事を投入して、もっと質の低い仕事を生み出してるだけ。知的に正直なら、これが見えないなんてことある？化石燃料を燃やすのも一緒で、過去のバイオマスを燃やして大気汚染してるだけだよ。
LLMみたいに性能が不安定で、しょっちゅう嘘をつくものと付き合う忍耐力が、既存の開発スキルを拡張したものじゃないって言うけど、それは違うね。複数のエンジニアやステークホルダーが関わるエンジニアリングのリーダーシップを任された経験があるならわかるはず。シニアになればなるほど、これは役割の肝なんだ。人間に接するのとかなり似てるよ。彼らの限界を知り、成功への道を示し、適切な抽象化やコーチングで限界を乗り越えさせる。正しいことをしやすくするんだ。人間相手だとリーダーシップとかマネジメントって言うけど、エージェント相手だとコンテキストエンジニアリングって呼ぶわけだ。
どうして知的正直な人がそれを見抜けないのかって？彼らが訓練データで見た問題しか解けないって考えは、一見当たり前に見えるけど、実際に新しい問題を解くために継続的に使ってみると、そうじゃないことがわかるよ。私の個人的な話は信じなくてもいいけど、GeminiとOpenAIが今年、国際数学オリンピック（IMO）と国際大学対抗プログラミングコンテスト（ICPC）っていうすごく評価の高い学術コンテストで、金メダル級の成績を出したことを考えてみて。これってすごいことなんだ。なぜなら、これらのコンテストは毎回、過去に公開されたことのない新しい課題が出るからね。訓練データには載ってないはずだよ！
もっとコメントを表示（1）
その通り！これを読んでると、初期の産業化や他の分野での自動化に反対する動きを思い出すな。不安や未来への恐れ、新しいツールへの疎外感…全部当てはまるよ。AIが織機と同じくらいの影響があるとは言わないけど、初期のラッダイト派の文章とすごく似てるって思ったんだ。
少なくともチームでは、すべてのコードをレビューするチームの時間に限界があるよね。Vibeエンジニアリングされた（俺は“supervised vibing”って呼んでるけど）コードって、自己レビューの時に誤った安心感で盲点ができちゃって、コードレビューで問題が出やすいことがわかったよ。チームの負担がさらに増えるんだ。今はコードレビュー用のプロンプトとかサブエージェントを実験中。ローカルレビューが一番良さそうだから、負担のほとんどはVibeエンジニアにかかって、チームにはかからないようにしてるよ。
俺がそのポジションに15年前に就いたから言えるけど、これは間違ってるよ（LLMとの経験は完全に違うっていう意味でね）。トレーニングは一つのことだけど、トレーニングはトレーナーの生産性を上げないんだ。トレーニーの能力を向上させるためのものだから。でも、どんなレベルの能力であっても—大学1年目のインターンだろうと、20年の経験を持つシニアデベロッパーだろうと—効果的なマネジメントには、その人が何か問題にぶつかった時とか、知るべきことを教えてくれると信頼できることが必要だよ。100%の信頼じゃないかもしれないけど、それに近いレベルは必要。10%も必要なことを教えてくれない人と働き続けるなんて無理だよ。LLMはまだその許容レベルに達してないから、テクニカルリーダーシップとは経験が似てないね。もし一つでも大きなプロジェクトをリードしたことがあるならわかるはずだ。チームの誰かが書いたコードを、プロセスのあらゆるステップで一行一行レビューしなきゃいけないって感じたら、それは成功への道じゃない（そんなことしたら、進捗は遅いし、チームも君を好きにならなくなるよ）。コードレビューはプロセスの一部としてすごく重要だけど、日常のコミュニケーションの効率的な仕組みじゃないからね。
この全部の作業で、どれくらいオーバーヘッドが増えてるか分かる？言い換えれば、従来のエンジニアリングと比べて、生産性はどれくらい上がった（あるいは下がった）のか、本当に知りたいな。
「大量の並列エージェントの群れを管理する」っていうのも、俺は不安になるね。一見するとめちゃくちゃ強力そうだけど、そこがオタク達の興味を引くポイントなんだろうな。でも、それは究極のマネージャー職みたいでストレスフルそうだし、俺がやりたかった仕事じゃない。あと、俺はこのアイデアをまだ持ってるんだ。つまり、大量の「もの」をリリースすることが、本当の問題じゃなかったってこと。デベロッパーとしてのキャリア初期は、毎日ずっとコードを書きたいって思ってて、実際にそうやって学んだ。でも、今は20年目になって「なんでコードを書くんだ？」って思うようになったよ。ビジネス的な意味でね、何かをコーディングすること自体は、ほとんどの場合、足りないピースじゃないんだ。会議で冗談で言ってるんだけど、異業種のチームが「これできますか？」とか「Xってどれくらい難しいですか？」って聞いたら、答えはいつも「YES」なんだよ！テックチームにとって答えは確かにYESなんだ！それを先に言っておくのは、それが正しい質問じゃないからなんだよ。
生産性に関して、みんな「楽しさ」がどれだけ重要かを過小評価してると思うな。もし何か楽しくないことがあったら、たぶん先延ばしにしちゃうよね。15分のタスクが、後回しにしすぎて何時間、時には何日もかかることになるんだ。もし、たくさんのAIエージェントを管理するのがすごくつまらない時間の使い方なら、それが未来だとは思えないな。もし新しい仕事のやり方が、もっと大変で退屈になるなら、なんで俺たちは、歴史的に退屈な作業を自動化して抽象化し、本当に重要なことに集中できるようにしてきたのに、こんな新しいやり方をみんなで決めてしまったんだろう？未来の働き方を売ってる人たちが、君より優れてるとは限らないんだぜ。
この前、これについてすごく面白い会話をしたよ。あるエンジニアがLLMのプロセスについて教えてくれたんだけど、実質的にはこうらしい：
1. 詳細な仕様を共同で作成する
2. それをLLMに実装させる
3. レビューとQAに多くの時間をかける—コードは良いか？機能はうまく動作するか？
4. そのプロセスから得た教訓を、次回LLMが使うために書き留める—CLAUDE.mdとかを使ってね
この最後のステップが面白いんだ。君の言う通り、人間は改善するけど、LLMは改善しない…でも、それって、LLMのユーザーである俺たちが、フィーチャーのイテレーションを改善サイクルとして使って、LLMの働き方を改善していく責任があるってことだよね。何人かの人から似たような話を聞いたよ。CLAUDE.mdを常に更新する—ボットが間違いを犯すたびに新しい指示を追加したり、「常に最初にテストを書く」「リンターを実行する」「新しいアプリケーションビューを構築する時はBaseViewクラスを再利用する」みたいに指示したりすることで、時間の経過とともに格段に良い結果が得られるんだって。
「効果的なマネジメントは、部下が問題にぶつかったときに報告してくれると信頼すること」って意見は違うよ。効果的なマネジメントはマネージャーである君の責任だ。全員がすぐに全部話してくれるなら、それは楽勝モードってこと。
投稿者はスキルが役立たずになったとは思ってないと思う。ただ、スキルの活かし方が楽しくなくなったんじゃないかな。コーディングは職人技で、時には芸術だ。Vibe Engineeringをマネジメントと捉えるのはわかるけど、優秀なマネージャーはチーム全体の生産性を上げられる。でも、ほとんどのコーダーはマネージャーになりたいわけじゃないんだ。LLMベースのVibe Engineeringは、コーディングの創造的な作業を技術的な中間管理職に変えちゃってる。生産性が上がっても、ちょっと悲しいね。
じゃあ、俺の開発スキルは、マネジメントスキルが必要だからまだ関連性があるってこと？
わからないのは、レビューに時間を使いすぎると、ただ読んでるだけで、実際には何もしてないってこと。コード生産の活動では受動的になるよね。結果的に、良いコードの基準が分からなくなって、レビューの腕も落ちるんじゃないかな。俺はSWEじゃないから、批判しても個人的な利害関係はないよ。
最後の文には全く納得できないな。AGENTS.mdは、LLMに何度も伝えなくていいことを置く場所でしかない。LLMが100%従う魔法の指示じゃないし、プロンプトに手動で入力する内容より重要度が高いわけでもない。念入りに作ったAGENTS.mdは会話の最初だけ役に立つけど、会話が長くなると、上の方にあるトークンはどんどん重要じゃなくなる。100kトークンくらいになると、AGENTS.mdなんて存在しないのと同じで、いつも最初のパラグラフを”思い出させる”必要があるんだ。会話を始めて、途中でAGENTS.mdに書いてあることと矛盾する内容を言ってみて。どっちの矛盾した文が優先される？後者だよね！だから、AGENTS.mdを作るのに費やした時間は全部、LLMに何か”教えてる”と思ってるだけの無駄な時間だよ。
「GeminiもOpenAIもIMOやICPCで金メダルレベルの成績を出した」って言うけど、それは公平な比較じゃないよ。人間の場合、限られたリソースで独創性や知性を発揮するけど、AIの場合、何十億ドルもするデータセンターと何百ギガワットアワーもの電力を総当たり攻撃に注ぎ込んで、やっと18歳の賢い子一人に匹敵するレベルだ。Moore’s Lawがあと30年続かない限り、chatgpt.comのLLMじゃこんな結果は出せないって。
でも、君が何を好きかなんて誰も気にしないんじゃない？テクノロジーに取って代わられた他の多くの職業の人たちが何を好きだったか、誰が気にした？大事なのは、将来ソフトウェアがどうやって最も効率的かつ効果的に作られるか、そしてこの新しい世界にどう備えるかだ。そうしないと、昔の炭鉱労働者みたいに、古き良き時代がいつか戻ってくるって希望するだけの、他の代替された職業の人たちと同じ運命をたどるだけだよ。
「すごいけど全然信頼できない」って意見に対して、AI以前から対策はあったし、今も通用するよ。例えば、LLMはテスト駆動開発と相性が良い。高レベルな知識と良いエンジニアリングプラクティスがこれまで以上に重要だけど、これらは昔からずっと重要だったんだ。
業界がプロの現場でのコーディングエージェントの有用性すら確信できてないんだから、ディストピア的だと感じるものから距離を置くのは合理的だよ。トラクターが馬に取って代わったとき、誰もがトラクターが馬を上回ると認めた。その結果は簡単に測れたんだ。大企業が所有するLLMエージェントの場合は、そんなに単純じゃないよ。
GoogleはすでにICPCで使われたGemini 2.5 Deep Thinkモデルを月額250ドルの”Ultra”プランでリリースしたよ。AIモデルは同じ性能なら価格が急速に下がる傾向にあるんだ。3年前のGPT-3は今日のずっと優れたモデルよりも1000倍以上も高かった。この傾向がまだしばらく続くことに賭けないわけにはいかないね。
＞全く違うこと、例えば営業とかに転職したいと思ってる
俺も同じ気持ちだよ。考えてる転職先は、1. 造園、2. 大工、3. 小規模農業だね。(投資でほとんど不労所得があるから、新しい仕事でお金を稼ぐ必要はそんなにないんだけどね。)
一部のテック系の人たちが、この手のものがコーディングを加速させ生産性を高めるって主張する執着が理解できないな。結局は速いアウトプットに過ぎない。俺の経験では、LLMはほとんどの場合、過剰に冗長なデタラメコードを出す。確かに俺よりは速いけど、俺の遅いコードの方がだいたい質は高いね。今の“速くチャットして早く結果を出し、早く本番に投入する”って状況が好きじゃない。これは何年も粗悪な製品をウェブにばらまいてきたのと同じ考え方だろ。Vibeコーディングだのエンジニアリングだのって名前を付ける代わりに、なぜ低品質の速さが必要なのか、自動化やプロセスを改善できないのか、真剣に議論しようよ。例えば、ユニットテストは確かにすぐ作れるけど、そもそもなぜそんなにたくさんのユニットテストが必要なんだ？もちろん役には立つけど、低レベルのツールを進化させるんじゃなくて、高レベルの抽象化ばかり進んでる気がするよ。
一部の経験豊富なエンジニアが、これらのツールを使って信じられないほど高品質なコードを生産しつつ、生産性を大幅に向上させている可能性を考えてないのか？適切なプロンプトと”Vibeエンジニアリング”の実践で、俺がClaude Codeに作らせるコードは最高品質だと断言できるよ。
俺は経験豊富だ。これらのツールを最大限に活用できないかもしれないって示唆は受け入れられないし、お前が個人的な例を挙げただけじゃ俺を納得させられないぞ。
そのツールを最大限に活用したことがあるのか？
またしても根拠のない議論だな。エージェントが二度同じ答えを出せないなら、その真の可能性を探ることすらできないだろ。
＞それが何年もウェブに粗悪品をばらまいてきたのと同じ考え方だ
有名な話だけど、そういった粗悪品の一部は、素早く動き反復する能力があったからこそ市場での地位を確立し、今や誰もが知る名前になったんだ。もし彼らが長期的なメンテナンス可能なコード品質を優先していたら、今日の彼らは存在しなかったかもしれないね。”Move fast and break things”は冗談じゃなかったんだ。マークは本当に速く開発することを奨励し、それが彼らのポジショニングを確固たるものにするのに役立った。2009〜2014年頃のFacebookがどれほどの機能を量産したか考えてみろよ。もし彼らの主目的が完璧なコードだったら、それは不可能だっただろうね。コードは製品じゃない、製品こそが製品なんだ。長年のエンジニアリング経験の中で、エンドユーザーにコーディングスタイルを褒められたことなんて一度もない。彼らはいつも俺が作ったものにしか関心がないんだ。
どんなツールでも完璧に使いこなせるって思ってるなら、自分の能力にかなり自信があるんだな。俺は25年も使ってるツールがあるけど、まだもっとうまく使えると思ってるよ。
また的外れな議論だよ。話してるのはツールについてだろ？犬はツールじゃない。
ツールを使うスキルだと思ってること、それってSkinnerのハトみたいに、ただの迷信じゃないって自信あるわけ？
迷信が多いのは間違いないね！前にこの件について書いたよ: https://simonwillison.net/2023/Aug/27/wordcamp-llms/#superst…
何が迷信で何が本当に効くのか、methodicalに解明するのが、この分野での“engineering”みたいなスキルだよ。
そうだよ、犬もツールさ。盲導犬、猟犬、牧羊犬。LLMとの比較はマジで役に立つ。犬も頼りにならないツールで、時間をかけて使い方を学ぶ必要があるからね。
LLMが不正確だから視覚障がい者に使わせるのは非倫理的だと言う人たちには、a) 盲導犬も不正確だし、b) 障がい者のツール選択の主体性を軽んじるのは失礼だと反論してきたよ。
Facebookはマジな問題を何も解決してない。“Move fast and break things”は投資家のための言葉で、ハッカー向けじゃないね。Gmailは昔はすごく高品質なWebアプリでコードも良かったけど（今は言えないけどね）、今日の“fast iteration”文化の産物じゃないのは確かだ。
もっとコメントを表示（2）
認識してくれて嬉しいよ！
「何が迷信で何が機能するか見極めるのがengineeringスキル」って言うけど、変数が多すぎてカオスだから、マジで無理ゲーだよ。統計的な結果を得るには何度も実験が必要で、手動じゃ無理。客観的なコード品質 metricsもないし、テスト合格だけじゃコードが良いか分からない。新しいmodelが出たら全てやり直しだよ。
物理法則が常に変わる世界のengineeringみたいで、俺ならもう帰るね。プログラマーにはmagicがあったけど、「Vibe Engineering」はそれを新たなレベルに。科学と迷信を区別できないからengineeringじゃない。Software engineeringは元々迷信が多すぎたけど、今はもっとひどいレベルだ。
Metaは1.79兆ドルのmarket capがあるし、そこに到達するためにマジでいくつかの問題を解決したはずだよ。Linearみたいに、最初から高品質な製品を作ってうまくやってる企業もたくさんあるしね。どちらのアプローチも、持続可能で長く続くビジネスを作るには有効だよ。
今日見つけたことの例を挙げるよ。Claude Codeに作業させてGitHubにbranchとしてpushしたんだ。その後PRを開いてレビューしやすくして、そこにnotesやcommentsをたくさん追加した。
ふと思いついて、そのPRのURLをClaude Codeに貼り付けて、「GitHub APIを使ってこのPRのnotesをfetchして」って言ったら…まさしくその通りにやったんだよ！API URLを推測して、JSONをfetchして、俺のnotesを読み上げてくれた。各notesに順番に対応してcommitするよう指示したら、それも実行したね。
もし将来のmodelで、GitHub PRのJSON notesをfetchするURLを正確に推測できなくなったら、このtrickが失敗したときに気づくだろうね。今は、Claude（そしておそらく他の良いmodelたち）ができることの、どんどん増えるリストに加えることになったよ。
意識を持つ犬とソフトウェアを比較するのは、マジでdystopianでantihumanに感じるよ。
俺は全然平気だよ。犬は大好きだし、LLMがsentienceを持つとかconsciousになるっていう意見は、その人がマジで言ってるかによるけど、笑えるか嫌悪感を感じるかのどっちかだね。犬をanalogyに使うのは全然OK。この場合、analogyはunreliableなツールであって、犬はunreliableなツールだからね。「stochastic parrot」もparrotが入ってるけど、analogyとしてoffensiveだとは思わないよ。
君の例は迷信じゃないよ。簡単に確認できるタスクだし。
PRにコマンドをメモとして書くとClaudeが重視するって信じてそうする方が迷信っぽいね。訓練のせいでモデルがそういう挙動をする可能性は十分あるし、そのパターンを見つけた人は、挙動が変わってもそうし続けるかもね。
客観的な現実は存在するし、LLMのおかげで開発速度が爆上がりしたよ。20年以上コード書いてきて、光速で実装するって言われてる俺でもLLMでめっちゃ効率アップしたんだから。もうGenieは出ちゃったんだから、流れに乗って適応するしかないさ。将来の不確実性には俺もイライラしてるし、キャリアは安泰だと思ってたから、エンジニア仲間の気持ちはよく分かるよ。
Metaの市場価値1.79Tドルは、人間の注意を食い物にして広告を売った結果だよ。技術的な驚異じゃなくて、心理的なものだと思うね。
俺もあんたみたいに確信がたくさん持てたらいいけどね。まず、客観的な現実なんてないし、物理学でもそう。LLMで開発速度が上がっても、それが重要じゃないってのが俺の主張だよ。「流れに乗るしかない」って言うけど、俺は「その他」を選ぶね。これが議論の最たるものならね。
モデルを扱うときは、常にタスクを表現する一番シンプルな方法を探してるよ。「Xの世界的専門家」とか「100万ドルやるからさ」みたいなプロンプトは好きじゃないね。ちょうど今日午後、Claude Codeの実際の使用例をブログに書いたから見てみて: https://simonwillison.net/2025/Oct/8/claude-datasette-plugin…
ソフトウェア開発で「納品速度」が一番大事ってことについて、理屈を説明してみるよ。これが正しいかは分かんないし、実験もデータもないけどね。どんな非自明なソフトウェアでも、バグとか要件漏れとかセキュリティ問題は必ず出る。これらは反復開発とフィードバックでしか解決できないんだ。だから、ソフトウェアの品質はフィードバックループの総数で決まる。フィードバック1回にかかる時間が短いほど、たくさん回せるからね。だから、価値あるソフトウェアを作るには、納品までの時間が一番重要なんだ。
それらは明らかな迷信的なおまじないかもね。でも、本当に効く可能性もあるんだ。「賄賂」がより良いコードを生むってこともありえるし。バカげてるからって避けるのは簡単じゃない。LLMの予測不能な性質のせいで、目立たない迷信を拾っちゃうのはほぼ確実。番号付きリストが良かったり、簡潔なプロンプトが良かったり、エージェントがXを始めたらコンテキストをリセットするべき、とかね。それらは真実かもしれないし、特定のモデルでだけ真実だったり、単なる偶然だったりするかも。
客観的な現実が存在しないっていう主張には、正直めちゃくちゃ困惑してるんだけど。
FacebookはMySpaceより質が良かったから優勢になったけど、あれは技術的な製品機能じゃなくてコミュニティの質（既存ネットワーク限定）のおかげだよ。Markは計算してやったわけじゃなく、ただ運が良かったんだ。そのうちMySpaceみたいにクソになったけど、もうデカすぎて競合を買い取るだけになったし、ネットワーク効果で何十年も安泰だろうね。製品の成功って、機能だけじゃなくて、もっと色々なものに左右されるって例だと思うよ。NBAとかアメリカの成功も似たようなもんさ。
Phillip Morrisの市場価値は238Bドルだけど、彼らはどんな問題を解決してるんだろ？
高速なフィードバックは技術的負債をためがち。コミュニケーションと丁寧な実装があれば、二度と触らない堅牢な機能も作れるよ。ユーザーの習慣を無視してコロコロ変えるのは良くないし、そもそもそんなにスピードって必要？LLMがすぐReact使うのもそうだけど、Webは停滞してるのに、その上に抽象化を積み重ねるばかりなのはどうなのって思う。
みんな状況判断を放棄して、魔法のパターンを探しがちだよね。ソフトウェア開発で『高速なデリバリーが成功の鍵』と信じて、盲目的に速度を追求してるけど、Goodhart’s lawじゃない？速度には限界があるし、製品が最適な状態になれば、そんなに機能はいらないでしょ。収穫逓減のラインを超えても『もっと生産性を！』って言われるのが、多くの開発現場の現実だよ。
犬は数千年も前から道具として使われてきたし、今でも100％道具として使えるよ。
おやつディスペンサーからランダムに報酬をもらうと、ハトは報酬が自分の行動の結果だと勘違いして、面白いダンスとか動きをし始めるんだ。
テスト書いたり、計画したりするのも、その面白いダンスみたいなもんだよね。
ロボット、家のルールを守るんだ！
朝食を届けに来るときに僕を殺さないこと！
壁に穴を開けて勝手にドアを作るな！
人間は手足が生え変わらないってことを忘れるなよ！
ずっとチームにベストプラクティスを教えてきたのに、みんななかなかやってくれなかったんだ。でも、LLMがもっと効果的になるって言われた途端に、みんな急に守り始めたんだよ。最初から効果的だったはずなのにさ、これって最高に面白いよね。
デイリースタンドアップも、まさにそうだよね。
ここで何を言いたいのかはよく分からないけど、すごく悪意のあるコメントに聞こえるよ。
