Amazonのエンジニアたちの告白 仕事がまるで倉庫作業に

なんか喧嘩腰だね。
”本物の”QC って何？
俺は人乗せて安全運ぶ乗り物や、強い風や地震に耐える建物の部品作ってる人のために働いてるんだ。
”本物の”QC と他のQCの違いって？
自動車や航空メーカーがBig Pharma と同じ品質基準を持てないって言うの？
どっちもお客さん危険に晒すの避けようとしてるのに。
Pharma だって危ない決断したことあるじゃん。
俺の言いたいのは、ルールがあるからって守られてるわけじゃないってこと。
そうであってほしいけど、証拠はほとんどないんだ。

俺には hype train に感じるな、crypto とか VR みたいにね。
最近 vibe coded されたコード直したんだけど、構造なくてパッチだらけの複雑コードだった。
LLM はコンテキストウィンドウの限界で詰むんだ。
自然言語はコードの指示には不精密だし、シニア開発者のコードには経験が詰まってる。
AIにその”vibe”を出させるには、プロンプトを超精密にして過去の失敗経験全部言語化する必要がある。
それはマジで大変だよ。
これは「なんでこう書いた？」じゃなくて、「これはNG、こっちはOK、この特定状況ではね」っていう無限リストなんだ。

反論するね。
AI が、普通は俺にはできなかったリファクタリングを手伝ってくれたことがあるんだ。
カーソルが検知したり、特定のパターンの可能性を示唆したりして、30箇所くらい微妙に違う形で存在する共通構造を抜き出すみたいなね。
vibe coding の問題は、もっと行動的なものだと思うよ。
自分でコード書くのを避けるために bandwagon に飛び乗りやすい人ってのは、たぶん長期的なアーキテクチャとか職人技を考えてないんだ。
それは怠け心を増長させるだけさ。

＞ AI が、普通は俺にはできなかったリファクタリングを手伝ってくれた
問題の複雑さで技術的に無理だったなら、AI の変更が正しかったってどう保証したの？
君のコメントだと、後で問題見つかったら、人間には理解不能だからまたAI頼みになるみたいに聞こえる。
それってマジでヤバくない？

hype は過剰な約束と結果を出さないことだよ。
AI はめちゃくちゃ新しくて、すごいし、もう色んなこと変えてる。
それがどうして crypto とか VR と同じだって言えるんだ？

そして一旦AIが無くなったら、また振り出しだね。
学習を計算から外したら、効果的に見えるだけだよ。
その仕事には間違ったツールだ、それが俺の意見。

進んだIDEが無かった頃、コードの全体像を把握するのが難しかった（「fog of war」）。
LLMs は巨大コードプロジェクト理解に大きな機会だと思うよ。
非テック企業の巨大プロジェクトは、ドキュメントやテストが不十分で有機的になりがちだからね。

＞ 学習を計算から外したら、効果的に見えるだけ
AI は習得に何年もかかることとか、Fortune 500 の Java コードベースみたいな特定の経験が必要なことに効果的だよ。
AI と vibe coding 試したら、普通の Java 開発じゃ得られない経験できた。
AI は waterfall じゃなくて、素早くイテレーションできる環境で使うものさ。

＞ 自然言語はコード指示には不精密
その通り。
これは業界で見た「自然言語 vs 形式言語」のサイクルと同じ。
「英語で済むといいよね？」
↓
「正確に理解させるには形式言語がいいよね？」
ってね。
精密なものを自然言語で伝える方法を発明できるって希望は永遠にあるけど、多分無理。
人間同士ですら曖昧さなく話せないんだから。
法律みたいに。
将来エンジニアが弁護士みたいに、コンパイル前にプログラムの意味を議論する運命なら、マジ悲しい結末だよ。

コードってさ、結局構造とか全然なくて、バラバラのビジネス課題を無理やりコードにしただけみたいになっちゃうんだよね。これって、俺の30年のキャリアで見てきたほとんど全てのコードベースに当てはまるわ。マジで一つだけ例外だったけど。

AIは過熱気味だけど、自動化がエンジニアの仕事にも影響するのは事実。俺らTech系の奴らは、生活費を稼ぐこととか普通の労働者の苦労を見下してた特権階級だったんだ。パンデミック後、Tech企業はレイオフで人件費を抑制してる。今や防衛産業と同じだよ。AIでまずは5人分の仕事を4人でやるようになり、一人をクビにして残りの賃金も抑える。次に3人、2人になるだろう。年収高かろうが、君は労働者。超富裕層じゃなくて、看護師や教師と同じ側にいるんだよ。

AIは確かに新しくてすごいし、色々と変えてる。でも約束しすぎてるせいで、期待外れなんだよ。博士レベルの研究者で、SATとかMCAT、司法試験にも受かるって売り込んでるのに、”strawberry”のRの数を数えるのに苦労してる始末さ。

なんか変な組み合わせで、難しくて分かりにくくて面倒くさい問題って時々あるじゃん？そういう時って、マジで着手するやる気が出ないんだよね。銃突きつけられたらやるけどさ。でも誰か他の人が代わりにやってくれたら、喜んでマージリクエストはレビューするわ。

マージリクエストのレビューって、自分でコード書くのと同じくらい、いやそれ以上のやる気が必要じゃね？だって、ちゃんと評価するには自分の中で「正しい解決策ってどんなの？」って基準がいるじゃん。個人的にはレビューの方がやる気出ないわ。使われる解決策考えるのは楽しいけど、レビューのためだけの解決策考えるのは楽しくないし、他人のぼんやりした考えを理解しようとする無駄な時間も事前に分かってるしさ。

マージリクエスト出す奴は、自分のコードちゃんとレビューしとけよ。LLM出る前から、自分で見直さないのはレビューする相手に失礼だった。分かりやすい問題で指摘されると、チームも提出者も恥ずかしいし気分悪い。LLMが作ったコードを自分でレビューせずに出すのはクビに値する。LLMコードが通用するとしたら、コードレビュー自体をなくすしか無理じゃね？

”strawberry”の件はもう解決しただろ。それにしてもさ、それはそれ、これはこれじゃん？たかがそれ一つで苦労してるからって、他の全部がダメで期待外れになるわけ？俺はそう思わないな。

俺も同じこと感じてるわ。しばらくやる気が出なかったことを改善できるようになった。でも、もし怠けるために（LLMとかを）使うなら、悪いことがどんどん増えるだろうね。

＞ マージリクエスト出す奴は自分のコードちゃんとレビューしとけよって話
自分のコードを別の作業としてレビューする必要があるって、それどういう意味？自分で書いたコードを…一度も読まないで出す奴が多いの？
＞ LLMが吐き出したコードを提出する
ああ、なるほどね…

なんか俺、浦島太郎状態なんだけど、「バイブ・コーディング」って何？

解決してないってば。投稿する前に色んなAIの最新版で試したんだから、君みたいな返信来ると思ってたしね。＞それが苦手なだけで他の全部がダメなの？いやいや、彼らの大げさな主張がめっちゃ怪しくなるってことだよ。個人的には、AIの能力には超がっかりしてる。今は検索ボックスみたいな便利なツールってだけで、それ以上じゃない。Ph.D.研究者みたいにブランディングしてるのはただのブラフだよ。

ぶっちゃけ、実際に本番環境で動いて、モノやサービスを提供してるコードの多くは、継ぎ接ぎだらけのコード片の寄せ集めだよ。悲しいのは、CPUがめっちゃパワフルだからそれで動いちゃうってことだね。

俺も試したよ、このテストは前から知ってる。Claudeは正しく答えただけじゃなく、ドイツ語でも書いたんだぜ。AIがもうこんなに凄いから、単語だけ英語とドイツ語で切り替えたりすることもしょっちゅうさ。数年前はこんなの想像もできなかったよ。そのための技術なんてゼロだったからね。ちょっとリプロンプトしただけで、10分以内にシングルページのHTML Javascriptページを小さなプロトタイプ用に作れたんだ。テキストか音声だけで、文字通り好きな画像を生成できる。スマホと音声で議論だってできる。Julesは俺のプログラミング言語を検出して、”プロジェクトのGitHub actionを生成して、基本的なテストを追加して”って書いたら、どうビルドして実行するかも分かったんだ。どうして皆がこれらの結果に驚かないのか、俺には理解できないね。普段どうやって試してるの？

最近の例ね。サードパーティ製のハードウェアをraspiで動かそうとしてたんだけど、ハードウェア提供者は別のドキュメント付きの別々のコードベースを２つ提供してて、最新のほうしかサポートしてないんだ。文字通り、新しいコードベースをChatGPTに無理やり食わせたんだ、それから動くサンプルコードも食わせて、やっと動いたよ。そうしないと、いつも間違ったメソッドを参照し続けるんだ。もしコード／出力／繰り返しを続けてたら、いつか答えにたどり着いたかもしれないけど、全然見当違いだったね。

そんなプロジェクトはAIが全体を処理するには大きすぎるよ。だから、うん、それは本当だよ。

＞私も試したし、このテストは前から知ってるよ。
Claudeは正しく答えたし、ドイツ語でも書いたよ。＜
いや、ポイント分かってないね。君が試してうまくいったって凄いけど、これらのツールは確率的なんだから、それだけで”解決済み”とは言えないよ。私が試してうまくいかなかったってことは、解決してないってこと。全く動かないよりむしろタチが悪いんだ、だって君みたいに間違った自信を持っちゃうからね。イチゴの例は全ての抽象化みたいに、AIが”漏れのある抽象化”だってことを浮き彫りにしてる。彼らが売ってるみたいな神託じゃないんだ、基本的な使い方を超えてちゃんと使うには内部の詳細を知らないといけないただのインターフェースだよ。結局、AIを本当に使いこなせるのは”漏れのある抽象化”って私が言う意味を理解してる人だけ。そういう人はもうプログラミングできるんだから、自然言語に全力投下して一体何を解決してるの？
＞ちょっとリプロンプトしただけで、10分以内にシングルページのHTML Javascriptページを小さなプロトタイプ用に作れたんだ。
もっと優れた言語設計とツールを使えば、似たような結果は得られるよ。これはむしろJavascriptっていう言語への告発みたいなもんだ。なんでJavascriptで10分で小さなプロトタイプ書けなかったの？
＞テキストか音声だけで、文字通り好きな画像を生成できる。
誤解しないでほしいんだけど、俺もこれいつも楽しんでるよ。でも、AI画像はちょっと種類が違うんだ、アートは”正しく”ある必要がないからね。それでも、生成AIテキストみたいに、AI画像も詳細が重要になり始めるところまでは凄いんだ。例えば手とか、キャラクターの一貫性とか。１つのシーンに複数のキャラクターがいる場合とかね。これはまだ最新のAIモデルでも、君が指示したことをやらない問題なんだ。
＞スマホと音声で議論だってできる。
うん、電話と話すのは neat trick だけど、議論なの？AIとのやり取りは、単に物事をでっち上げてその場のノリで進める、即興セッションみたいに感じることが多いよ。俺が専門家であるトピックについて聞くたびに（本当に毎回）、AIは間違えるんだ。微妙にだけど、大事なところで間違ってる。議論というより、ゆっくりガス抜きされてるみたいに感じるね。これは凄いんじゃなくて、イライラするよ。
俺の言いたいこと分かってくれたと思う。うん、AIは最初は凄いかもしれないけど、どんどん使っていくうちに全ての欠点が見えてくるんだ。もしその欠点が修正されてたり、LLMsの限界を認めてくれたりするなら良いんだけどね。でも彼らはそうしない；代わりにやってるのは、欠点なんて存在しないふりをして、これらのLLMsが実際は凄いふりをして、AIを文字通りありとあらゆるものに押し込んでることだ。彼らは何年も指数関数的な改善を約束してるけど、未だに最初の日からの同じ問題が残ってるんだ。

これ100%同意。俺もこれ何回もやったよ。前は後片付けやリファクタリングを気にしなかったことも多いけど、今はそうするのがずっと簡単で、速くて、安くなったんだ。そして、長い目で見ればその方が良いね。

なんか、ひどい仕事ばかりだったんだね。良いチームは開発前にarchitectureに時間をかけてるよ。前もってarchitectureを用意すれば、LLMsは良い構造のコードを作るよ。

AIは新しい技術革命で、専門家がうまく使えるけど、進歩はめちゃ速いよ。LlamaでOCRが20％改善したり、コード生成で時間節約したり、普段Python書かないのにMLスクリプトも作れたりした。周りの人もすぐ理解した初めての技術デモだった。ChatGPTやClaudeみたいなチャットボットはすごいし、AIを注視して試していくのが超大事。

労働者階級の一部には、資本家と協力すれば他の労働者階級に起こっている悪い影響から自分たちを守れると勘違いしてる人たちが昔からいたよね。それは理解できる衝動だけど、どこかで学べよって思うんだ。今度はsoftware engineersとして、俺たちがその苦い薬を飲む番だ。

ちょっと関係ないけど、逸話ね。昔JP MorganのMDに”君らの仕事はGoogleで検索してコピペだろ？”って言われたんだ。しかも彼は”quantsのC++コードをNotepadで開けたらgibberishだった”とか言ってた。教訓：プログラミングできない奴ほど、プログラミングについて偉そうに語るってこと。

俺自身のちょっとずれた不満（君のとは少し関係あるけど）：工場作業はAgileが職場に入り込んできたときに始まったんだ。lint、unit tests、code reviews…この手のクソみたいなものが積み重なって、プログラミングをさらに悪くした。あの頃からコード書くのが楽しくなくなったね。

Agileはそうだね、大規模なmicromanagementだよ。でもテスト書いたりcode reviewsしたりするのは良いpracticeだよ。

テスト書くのが何が悪いの？本番環境にpushするとき、俺たちの頑丈なテストsuiteがあるおかげで夜ぐっすり眠れるよ。

Code reviewも、ないのはもったいないくらい聖なるprocessみたいに見えるけど、多くのteamsは実際には品質を気にしてないのに”うちは品質気にしてます”ってstampとして使ってるだけだよ。”LGTM”みたいなcomment出して、とりあえずapproveしたりね。

今まで働いたどこのorganizationでも、unit testsとcode reviewsについてlip serviceで、本当にtestsとreviewsをするのは無理なくらい、timelinesが短くてworkloadsが多かったよ。

良いテスト書くのは難しいartだよ。System実装を深く理解しないとダメだし、Coverageは意味ない。100％coverageでもbugは入る。テストの質を判断する良い方法もないし、テスト重視しすぎるとcodeがもろくて扱いづらいんだ。簡単な変更でもテストを大量に直す羽目になるし。

ビルドがテストカバレッジで止められるからさ，みんな機能のためじゃなくてカバレッジのためにテスト書くんだよ．引き継いだテストの結構な部分は，テストしてる機能でなんか重要な問題起きてもキャッチできないと思うね．

俺の経験じゃ違うなー．たぶん運が良かったのかもね．もっとデカくてちゃんとした会社で働いてみたら？そっちの方がまだマシかもよ．

結局さ，仕事でちゃんとやるって方が，楽しむことより大事ってことなんだよな．

そこはちょっと反論くるかもね．でも俺は絶対両方選びたいなー．（あとさ，マネジメントがコードの書き方に口出すようになる前は両方あったと思うんだよね．）

リンティングとかユニットテスト書くのが特別楽しくないなんて思ったことないな．でも俺はコードの正確性をマジでマジで大事にしてるし，その両方がそこに役立つ傾向があるんだよ．

今まで働いたとこで，コードレビューがちゃんとやられてるの見たことないんだよね．「本当の仕事」って思われてないし（コードの変更ゼロってこともあり得るし），ちゃんとコード読んでどこが弱いか見つけるには時間かかるんだ．結局，時間足りなくて，目立つとこだけテキトーに読んでマージせざるを得ないんだよ．

俺の視点だとさ，「テスト」自体じゃなくてこの反応が問題．テストに間違いはないけどコストはかかる．プラスの投資対効果は？システムは品質のためのテストじゃなくてテスト自体に歪んでない？テストが関係ない行動の正当化に使われてない？他の概念でも同じこと．

チームがお互いのコード気遣うならさ，最初から設計とか実装一緒にやるべき．コードレビュー（サイクルの最後の門番みたいなやつね）は責任放棄だし，高品質にするのに一番ダメなやり方だよ．すぐ出せる自信がないまま機能完成させるチームはプロセスが間違ってる．

コードカバレッジの結果についての指摘は大事だね。
これについて他の人と話すとき、俺がよく言うのは、高いカバレッジが良いテストスイートだって証明するわけじゃないけど、低いカバレッジはテストスイートがダメだって教えてくれるってこと。これはコード品質を測るたくさんの指標の一つであって、それだけで全てじゃないよ。

単体テストやコードレビューを放棄すると、コードは”俺の”になり、チームでの協業が難しくなる。レビューは実質的であるべきで、単体テストも自分で書くべき、インターンに丸投げはダメ。汚いコードは”レガシー”扱いされ、誰も触りたくなくなり、置き換えの対象になるよ。

TDDは、良いアイデアだけど、賭け金が低いときは全然使われないね。ほとんどの場合そうだし。で、賭け金が十分高いときは、単体テストも含めて、ちゃんとしたQAエンジニアを雇って全部テスト書いてもらう方が良いと思うよ。

多くの人がやり方を知らないから、可能なときはいつでも避けてるね。すごくイライラするよ。コードの一部にテストが必要ないっていうのは全然良いんだけど、それはコード自体が単体テストを必要としないからであるべきだ。単体テストを壊して、直し方が分からず、テストを全部削除するなんてのは、良い理由じゃないよ。

”最初から設計と実装について協力すべき”ってのは、全くその通りだね。
そういうプロセスを経た上で、同僚がちゃんとできるって信じられるようになるんだ。もし同僚ができないと思うなら、そう言えばいい（あるいはジュニアなら、もっと慎重に簡単なタスクを渡して、こっそりコードレビューして、”有効”なら―たとえそれが”Best Way”じゃなくても―OKにしてやるのが賢明だね）。

コードカバレッジはどっちにしろダメな指標だよ。
どこかで話題に出たとたん、MBAマネージャーが100%に近づけようとしてGoodhart’s lawが発動するんだ。LOC（コード行数）と同じようなもん。どこでも口にするな。

テストの品質を高く保つテクニックはあるんだよ。でも、たいてい誰もテストなんて全然気にしない。多くのプロジェクトは社内向けで、クリティカルじゃないとかね。早く作って、壊して、クソみたいなソフトウェアを納品するんだ。

堅牢なテストスイートのためのテストは良い。ポリシーのためのテストは良いこともあるが、たいていデタラメ工場からのデタラメが増えるだけ。孤立して見ればどちらもテストだが、違いはそれらが置かれている組織構造にあるんだ。

俺が働いてたところでのコードレビューは、実際はお墨付きもらうか、おべっか使うかみたいだったよ。
一度も必要だって感じたことないな。変更について自信がなかったら、たいてい（口頭で）聞くんだ。

君の問題は（カバレッジみたいな）指標を追いかけることであって、単体テストそのものじゃないよ。
良い単体テストはすごく役に立つんだ。俺のプロジェクトでは、いくつかの依存関係のせいでローカルで動かせないんだけど、単体テスト相手にコーディングすることで、リモートで全部動かす必要なく、そこそこのスピードで開発を進められてるんだ。