本当の分かれ目は、質と基準だと思う。みんな受け入れられる基準が違うし、エンジニアとしての役割もその好みを反映してる。私は一つのコードに何時間もかけて、何度も繰り返しながら、自分が気に入る形になるまでやるけど、他の人はそれに価値を見出さないこともある。「動けばそれでいい」って考えの人もいるし、私たちはそれぞれ違った形で価値があるんだよね。それに、モデルの進化のスピードもある。多くの人が昨年の意見を持っていて、状況はかなり変わった。使いこなすためには努力も必要だし。「デフォルト」の出力は平均的な質だけど、ちょっと工夫すれば高品質な出力が簡単に得られる。みんなが懐疑的でいるのはいいことだと思う。深く考える必要があることや、新しい形でアイデアを結びつけることもたくさんあるし、私の経験ではLLMはそれが得意じゃないからね。

その議論は「ちょっと優しすぎる」気がする。二元的じゃないし、モチベーションは複雑で、時には両方の感情が共存することもある。私がなぜテックに入ったのかを考えると、いくつかの理由が見つかる。 - 問題を解決するのが好きだから。昔やってた特定の問題がなくなったのは悲しいけど、新しい問題があるのはワクワクする。 - 自分のスキルを使って他の人を助けるのが好きだから。今はそのやり方があまり効果的じゃなくなったのは悲しいけど、新しい形で知識を使えるのは楽しみ。 - 自分が違いを作れることをするのが好きだから。これも両方の側面があるね。ほとんどの人が似たような例を挙げると思う。

昔のことに対して悲しみを感じることは全くないな。ソフトウェアエンジニアリングが、プログラミングに情熱を持っていたオタクたちのものから、お金のためだけにやってるテックブロスに変わったのが一番悲しかった。ウェブの理想主義はずっと前に失われて、今はザッカーバーグみたいな apex 爬虫類がいる沼になっちゃった。ずっと前から利益第一になってる。私が感じる二つの感情は、恐れと興奮。機械にすぐに取って代わられるんじゃないかっていう恐れ。そして、今作れるものや、向かっている機会に対する興奮。これが一番楽しい経験とは言えないけど、興奮が少しバランスを取ってくれる。もしこの津波に完全に飲み込まれるのではなく、乗りこなそうとする緊急性を感じていなかったら、悲しみを感じるかもしれない。

分かれ目は決して見えなかったわけじゃないし、常に少なくとも三つのグループがあった。「動かす」人たちも、当時は何も動かせなかった。AIの有無にかかわらず、維持できないような馬鹿げたコードを作ってた。彼らは自分が何をしているのか分からないカウボーイだから、責任転嫁をして、たくさんの人におべっかを使ってる。「クラフトを愛する」人たちも、無限に無駄なことをして邪魔してた。彼らは今、AIを受け入れてるけど、それは自分が何をしているのか分からない理由として「クラフト」を使ってただけなんだ。今は少しだけ生産性が上がったかもしれないけど、チームの他のメンバーと議論する代わりに、自分自身と議論できるからだね。経験豊富で実践的な人たちは、常にその穴埋めを強いられてきた。彼らが意見を持てるなら、他の二つのグループがあまりダメージを与えないように、範囲を狭く保つだろう。彼らのAIの使い方は、昔と変わらずGoogle検索に限られてる。

でも、これは純粋な二項対立じゃないよ。私はずっと両方の側面を持っていて、仕事のためにエージェンティックなコーディングを少しずつ取り入れることで、家でのサイドプロジェクトで「伝統的」なプログラミングをするための新しい頭のスペースができた。アイデアを考えるワクワクするフェーズが好きだし、製品を動かすパズルを組み立てるのも好きだし、クラフトに誇りを持つことも好きなんだ。

何かを楽しむことと、それから満足感を得ることは別物だと思う。コーディング自体を楽しんでいるわけじゃないけど、何かを解決したときの感覚は好きだ。仕事の一環として新しいパズルを解くことが、年齢を重ねるにつれて脳の可塑性を保つのに役立つと思ってる。Claudeからそれを得られるかどうかはわからない。

誰もプログラミングをするためにPerlが美的に楽しいから入ったわけじゃない。今でも定期的にPerlに感動していたのを覚えてる。美しさにはこだわってなかったけど、難解だとされていることを知っていて、読んだり書いたりできることに誇りを感じていた。だから、そう、Perlのプログラミングは楽しかった。

「クラフト好きと、物を動かす人たちは隣に座って、同じ製品を出荷し、見た目も区別がつかなかった。」絶対に違うよ。オープンソースやエージェンシーの開発者としてのキャリアからの観察に基づくと、どのキャンプにいるかはコードの質を見れば一目瞭然だった。例外は少ないけど、物を動かすタイプは脆弱で、ハッキーで、短期的な視点の仕事を生み出す傾向があって、解決するよりも多くの問題を生むことが多かった。そして、彼らの貢献の質が低いために、FOSSプロジェクトへのコミット権を失うのを何度も見てきた。「誰もPerlでプログラミングするのが美的に楽しいから始めたわけじゃない。」Cで何かを達成しようとするのと比べると、Perlは本当に夢のような言語で、当時の他の一般的な言語に比べて、Perlの持つ柔軟性と表現力が好きで、ウェブ開発に惹かれる多くの開発者がいたんだ。幸運なことに、私たちのために言語設計やツールも進化したしね。

ウェブは技術としては客観的にひどいもので、実際には素晴らしいもので、誰もPerlでプログラミングするのが美的に楽しいから入ったわけじゃない。古い学校のPerlコーダーとしては、それは違うと思う。Perlを好む人はたくさんいたよ。「TIMTOWTDI」は実際の利点として売り出されていたしね。Perlは、ほとんど誰もやらないようなことに対応している。例えば、「unless」の中のネガティブな「if」とか、コードの後に条件を置くこととか。だから、こんなことができるんだよ：frobnicate() unless ($skip_frobnicating); これは、機能的には同じだけど、if (!$skip_frobnicating) frobnicate(); よりも読みやすいかもしれない。最初の方法では、プログラムの通常のフローを先に示してから、「稀な特別モードならこれをスキップできる」って後から付け加えている。使い方次第では、確かに何か特別なものがあると思う。Perlの最大の問題は、素晴らしいアイデアから始まったのに、十分に進化しなかったことだと思う。いろんなものが後から付け加えられて、みんなが少しずつ違うやり方で追加した結果、実際には脆弱なコードベースができてしまった。

SWEsは、コード生成モデルが全くコードを書くことができることに本当に驚いていると思うし、ましてや上手に書けるなんて。私の推測では、このことに対する多くの不安は、「私はコードが書けるから賢い/特別だ」と思っていたのに、機械がほぼ同じ仕事をできるようになったことで、完全に不安定になっているからだと思う。それに共感するけど、私自身はそうは感じていない。この「実行者対創造者」という二項対立が時々出てくるのが本当に嫌いで、コード生成モデルが完璧でないと思っている人は何も作りたくないかのように扱われるのが嫌だ。私は本当に良いものを作りたいし、コード生成モデルの現在の過熱波が良いものを作るのを難しくしているのが嫌だ。私は仕事でいくつかの大きなものを作るためにClaude Codeを使っている。質問を投げかけたり（「これはどこで起こるの？」「問題Xがある、3つの潜在的な原因を教えて」など）、PRを投稿する前にレビューしてもらったり、コードレビューのボットが実際のハイゼンバグを見つけたりしている。これらのすべてにおいて成功は混在しているけど、それでも全体的には役に立っていると思う。もし今働いている場所でClaude Codeやそれに類するものを使えないと言われたら、イライラするだろう。ただ、私は以下のことに関しては役に立たなかった： - ブラウンフィールドプロジェクトでの全体的で複雑な機能の構築 - システム的なバグの解決 - システム設計/進化 - 機能/製品の設計と計画 - シニアエンジニアのコードレビューの代替 それがこれらのことをやったと自信満々に言ってくるけど、実際にその出力をレビューするために精神的に苦労すると、失敗していることに気づく（この分析を行うには専門家である必要がある）。今、もしかしたらそれは許容できる方法で失敗しているのかもしれないし、わずかな修正が必要なだけかもしれないし、一発で変更を成功させることができるかもしれない。そういうのは良いケースだ。もっと厄介なのは、完全に明らかに失敗する場合だけど、本当に悪夢なのは、完全に失敗するけど、気づかない場合だ。それに時々は（これらのことの一部）をできることもある！でも、一貫性がないから、成功が失敗に対する警戒心を下げることが多い。精神的な苦労は本当にある。モデルが従うべきアーティファクトを生成/レビュー/確認するのは重荷だし、生成されたコードも重い。コードレビューはさらに面倒で、コードの背後に人間の思考がないから、著者のメンタルモデルを構築できない。コード生成モデルに自分の作業を修正させたり、別のアプローチを取らせたりするのは、非常に運次第だ。自分でコードを修正するには、生成されたコードの何千行も読む必要があるし、また人間がいない状態で何が起こっているのかのメンタルモデルを構築する必要があるから、それは時間がかかって疲れるプロセスだ。私はまた、二次的な影響についても懸念している。しばしば必要とされる深い精神的集中に切り替えるのが非常に難しい（ほぼ痛みを伴う）、その瞬間に多くの人がLLMに手を伸ばすのを見てきた。最初は少しずつ、次第に完全に。APIドキュメントをGeminiのプロンプトにコピー＆ペーストして説明させる人を見たり、コードの構文エラーを見つけられずにChatGPTに修正させる人を見たりしてきた。私だけがこれを観察しているわけではないと確信しているし、もっと注目されるべきだと思う。--- SWEsが似たような方法で失敗しないとは言っていない。私は、実際の影響を持つ巧妙な欠陥がある人間のPRを承認したり、作成したりしたことがある。ChatGPT以前に、必要以上に10倍も大きなPRを「レビュー」するように頼まれたこともある。コードを盗用したり、Stack Overflowを常にコピー＆ペーストする人を見たこともある。違いは、私たちはこれらのリスクに対してプロセスを構築していることだ。コーディングパターン、PRのサイズ制限、型システム、解雇、ばかげた量のユニットテスト、CI/CD、設計文書、ステージング環境、赤/緑のデプロイ、QAリストなど、すべてが含まれている。私はそれが大嫌いだ！それは私の欠点を常に思い出させて、リリースされたコードのドーパミンのスカッシュまでの時間を遅くする。私はこのすべてを切り捨てる最初の人になるだろう。Claudeを、レビューしなければならない圧倒的に長いPRのリストに向けたい。でも、まだ大きな欠陥があるからできない。コードレビューのボットは明らかな問題を見逃し、システム/バグ/機能について十分な文脈や知識を持っていないため、十分に包括的なレビューを行えない。プロダクションでバグを修正したり、すでにデプロイされた機能/修正を修正したりする必要があるので、時間の無駄になるだろう。これらのモデルは、SDLCの他の部分で人間を適切に置き換えることはできない。でも、デザインやコードレビューのような厄介なことがコード生成モデルの速度を制限しているから、業界はそのすべてを「再考」している。モデルの欠陥については考慮せずに。「再考」とは、LLMにすべてのコードレビューを任せることを考えているか、まったく行わないことを意味している。これを表現する唯一の方法は、無謀な無視だ。これはプロフェッショナルではなく、倫理的でもない。だから、私の悲しみは「技術」についてではないと思う。それが失われたとは思わないし、もしそうであっても気にしないだろう。私の悲しみは、