世界を動かす技術を、日本語で。
最近、友達の仕事は、彼の技術的じゃない上司が生成したAIのゴミをレビューすることになってる。ほとんどは機能してるように見えるけど、実際には本番環境には向いてない理由を証明するのが主な仕事。先週、彼が受け取ったPRについて話してたんだけど、簡単なCRUDエンドポイントの追加のはずが、実際には2,000行以上の複雑なコードで、キャッシュシステムを手動で操作して、機能してるように見せかけるフックを追加してたんだ。彼はほとんどの時間を、これをマージすべきじゃない理由を説明するのに使ってた。ますます、ブランドリーニの法則がAI生成コードに直接当てはまると思う。> 「〜バカげたこと〜 [AIのゴミ] を反論するのに必要な[精神的]エネルギーは、それを生み出すのに必要なエネルギーの桁違いに大きい。」
出荷しろ！
彼はほとんどの時間を、これをマージすべきじゃない理由を説明するのに使ってた。「これがどうやって、なぜ機能するのかを詳しく説明してくれないと、マージしないよ。」これは、開発者が提出前にしっかり考えなかったコードに対する応答として十分だと思う。AI生成のものであろうとなかろうと。
甥っ子はプログラミングの知識がゼロなんだ。彼は、自分を大金持ちにするウェブサイトを作りたいと思ってる。問題Xを解決する方法をAIに聞くけど、正しい質問をどう聞けばいいかわからない。それでも、AIは70%の解決策を提供してくれる。残りの30%を自分でやるために十分なプログラミングを学ぶ前に、彼は墓場に行くことになるだろうし、最初の70%を理解することもないだろう。AIに任せるのは人間に任せるのとは違う。人間を信頼できなければ、別の人を探せるけど、AIを信頼できなければ、選択肢はあまりないし、どれも不快な学習曲線がある。
https://www.joelonsoftware.com/2000/05/26/reading-code-is-li... https://www.joelonsoftware.com/2000/04/06/things-you-should-... （記事の真ん中の太字の部分を読んでみて）これらの記事は25年前のものだよ。
大体同意するけど、反論として、今日は大きなPRを出したら、リード開発者がすんなり受け入れてくれたんだ。やり方はこんな感じ：1. ブランチを作って、動くまでコードを適当に書く（Codex CLIを使ってる）。2. 新しいPRを開いて、適当に書いたコードを参考にしながら、自分でゆっくり本物のPRを書く。既存のコードと照らし合わせながらね。新しい概念もいくつかあったけど、既存のコードには前例があった。全体的に見て、自分で手書きした場合と同じくらいの質で、より早く解決策を出せたと思う。自分が理解できない解決策をPRするのは失礼だと思うけど、このプロセスは以前のAIなしのアプローチに似てる。機能が動くまで適当にコードを書いて、ざっくりした形がわかったら「ちゃんと」やり直すって感じ。
「〜バカげたこと〜 [AIのゴミ] を否定するのに必要な[精神的]エネルギーは、それを生み出すのに必要なエネルギーの何倍も大きい。コードレビューで、code-rabbitやgreptileのようなAIツールが大量にゴミを生み出しているのを見ている。これらのツールが出すきれいにフォーマットされたゴミを読むだけで、ものすごい人間のエネルギーを消費しているんだ。その中からたまに役に立つものを見つけるためにね。」
私が見る限り、その記事は「活動が多い、熱意もある、でもリターンは少ない。なぜ？」という一段落で終わってる。ハーバードビジネスレビューの購読者なら、もっとあるの？
UBOとVPNの広告ブロッカーを無効にしなきゃいけなかったよ。そしたら、全体が表示された。
ワークスロップの生産は、誰がArk Bのチケットをもらうべきかを決める方法だよ。
最近、私の管理チェーンは日常業務でAIを使うことを義務付けたけど、さらに生産性を上げることも義務付けた。年次レビューの時には、AIが私たちの仕事をどう良くしたかをすべて書き出さなきゃいけない。そのポジティブな結果は前提とされてる。AIが実際に仕事を悪化させたり遅くしたりする場合については、考慮されてないみたい。そういうケースは無視して、うまくいった時だけ言及するのが求められてる感じ。これは、グローバルなAIマーケティングの誇大宣伝工場の鏡のようなものだね。うまく機能する方法を常に宣伝して、うまくいかない時は無視したり軽視したりする。
AIに、日常の仕事でどれだけ生産性が上がったかを書かせてみて。これが得意なんだよね。各セクションを細かく展開させることで、1万語に膨らませることもできるよ。