それで、今はAIの出力を確認・レビューするのに同じ時間を使ってるの？

20年前にマイクロソフトでVisual Studioに関わってたんだけど、ある時、会社を代表して展示会に行く機会があった。ブースを担当しているときに、あるソフトウェア開発者がやってきて、VSがデータアクセスの自動化に関してコード生成が良すぎて、もうやめるべきだって言ったんだ。彼が冗談だと思ったけど、全然真剣だった。彼に、そのツールが退屈で繰り返しの作業から彼を救って、もっと価値のある面白い開発に集中できるようにしてるんだよって言ったけど、彼は全く受け入れなかった。最近よく彼のことを考える。今もプログラミングしてるのかな、LLMについてどう思ってるんだろう。

部分的には同意だな。最初の段落はまさに俺の気持ちそのもの。定型文やつまらないことは自動化すべきだよね。確かに、プログラミングが暗いアートみたいに語られることもあるけど、Methodology XとかTheory Yを使うべきだって言うのはちょっと大げさだよ。おい、落ち着けよ、ウェブサイト作ってるだけなんだから。一方で、ソフトウェア開発っていうのは、実際の人々が抱える問題に対する解決策を生み出すって意味では、確かに知的に要求されるし、スキルレベルの幅も広いよね。みんながクソみたいな仕事をしてるって言うのが流行ってるけど、それは全然フェアな表現じゃないと思う。

プログラミングって、マックス・フォン・シドーの世界征服計画を汚染されたビールとホッケー場のオルガンで出し抜く二人の間抜けな兄弟みたいなもんだと思ってた。

俺もめっちゃ同意する。大量のコーディングって、特別な新発明じゃないし、時間を見積もる時に多くの人が言うような、未知の作業でもない。正直、概念的に難しいわけでもないし、コンピュータは速くて正確だけど、バカだから、イライラするほど正確さが求められる。人間がマニュアルを読むのを拒否するようなもんだよ、カンマがセミコロンであるべきなのに。やれるだけの頭はあるけど、知識がなかったり、面倒くさがってやらない人が多い。こういう作業はほとんどなくなるべきだし、残りの部分はドメインの専門家が少ないコストでできるはず。

プログラミングは、こういうことをしないことなんだ。強力なマシンがそういうことを得意にやってくれる。パターンに気づいて、そういう作業をするツールを作ればいい。最もシンプルなのはスニペットジェネレーターやエディタのマクロだね。それからプロジェクトジェネレーターや、プログラミング言語からのコード再利用の仕組みもある。

そうそう、これって新しい現象じゃないんだよね。俺の意見としては、AIコーディングは実際には何十年も続いてきたトレンドの最新のものに過ぎないと思う。技術自体は新しいかもしれないけど、やってることはすごく古い！昔はバックエンドのエンドポイントを立ち上げるのに、たくさんの本物のコードを書かなきゃいけなかった。今じゃ、こういうのはほとんど宣言的な設定ファイルになってる。フロントエンドも同じ。昔は色んなめんどくさいことを管理しなきゃいけなかったけど、ここ10年で徐々に... 宣言的で反応的なパターンに移行して、基盤となるフレームワークが雑務を処理してくれるようになった。さらに、毎回一貫したデプロイを確保するための宣言的な設定ファイルも作ったんだよね。要するに、プロダクションマシンにSSHで入って何かをインストールする代わりに。ヌルポインタも扱ってたし、チェックを一つ忘れるだけでプロセス全体が消えちゃうから、ほんとに頭が痛かった。今じゃ... 言語に組み込まれてて、ヌルポインタのデリファレンスを実行するのは物理的に不可能になってる。すごいよね！俺たちは何十年も前から「自分たちを仕事から追い出してる」わけで、ボイラープレートや繰り返しの多いエラーを引き起こすロジックを減らしてきた。プログラミング言語やライブラリ、フレームワークを使ってね。実際に大事な部分に集中するために、これが最新の流れなんだ。やり方は新しいけど、目的は変わらない。前にあったものと同じように、これが本当に俺たちを仕事から追い出すとは思えないけどね。

俺もそうだよ、だから高レベルの抽象化を作ったり、他の人が書いたライブラリや言語を使ったりしてる。LLMが出る前に、どうしてそんな退屈なことを手動でたくさん書いてたのか理解できない。君は何をしてるの？

この意見には賛成だな。「どうでもいいことをたくさんやってる」って解釈する限りね。RailsとDjangoの論争とか、さらにひどいのはRailsとSinatraの対立を覚えてる？俺は覚えてるし、若くて無邪気だったっていうのが唯一の言い訳かな。「あんなことに時間を使ったなんて信じられない」っていうリストは本当に長いよ。何回ノードを再実装するつもりなんだよ、マジで。

AIにコードを書かせることは絶対にしないし、無監視ではね。自分でコードを書いて、クロードにチェックしてもらうのが好きなんだ。バグだけじゃなくて、アーキテクチャやスタイルも見てもらう。

でも、チューリップバブルで儲けるのはいいよね。

ソーシャルメディアの使い方や管理方法をまだ模索している今日のソーシャルメディアの状況と人々の関係を考えると、すごく不安になる。

個人的には、問題の根本は「AI」が擬人化されてたり、実際に「知的」だと過剰に宣伝されてることだと思う。ソフトウェアについて学んだことの一つは、「知的」っていうのは大抵「賢い人たちをたくさん投入して、解決策をさらに複雑にした」ってことなんだよね。機械学習はソフトウェアじゃないけど、そういうふうにアプローチすべきだと思う。入力を受け取って出力に変換するプログラムなんだから。でも、もし社会が本当に身体的または精神的健康を気にしてたら、タバコやスロットマシンなんて存在しなかっただろうね。

AIやエージェント的なコーディングを好む人たちのパターンに気づいてるんだ。1) 何らかの理由でしばらくプログラミングをしていない人（役員になったり、業界から離れたりした人） 2) 過去15年くらいにプログラミングを始めた人（プログラミングが金やライフスタイル、名声のための魅力的なキャリアになった時期と一致する） 3) プログラミング自体には興味がなく、製品作りに興味がある人。AI開発を好まない可能性が高いグループの例を挙げると、1) 約25年間プログラミングをしている人（今も） 2) プログラミングのプロセスを本当に楽しんでいる人（いつ始めたかに関係なく）。この観察が正しいかは分からないけど、最初のグループの誰かを非難してるわけじゃないよ。

100%同意だわ。数ヶ月前まではコードを書くのが好きだと思ってたけど、LLMにやりたいことを具体的に伝えられるようになって、構造や今日の目標を正確に指示できるようになった。自分が物事を終わらせるのが好きだって気づいたし、コードを書くのはそのために払わなきゃいけない時間の代償だったんだ。

ソフトウェアエンジニアリングが嫌いなのはいいけど、好きでこのキャリアに入った人たちに対して、この技術を押し付けるのはちょっとどうかと思う。しかも、その技術がもたらす倫理的な問題を無視して、ほとんどのツールが巨額の補助金で支えられていることもね。少数の大企業に知識と生産手段が集中していくのは、驚きだし、怖いよね。

同意する。ソフトウェアエンジニアリングの制約はほとんどが慣習的なものだよね。昔は「Scribe」を使ってライブラリの依存関係を解決するために何日もかけてたけど、結局は人工的なサブ問題を解決してたんだ。どんなソフトウェアエンジニアも、機械語からスタック全体を効率よく書けるわけじゃないし、常に恣意的で慣習的な問題のセットになる。これがLLMが得意なところだよね。正しい問題を定義して、コードの出力を慎重にレビューするために「Scribe」サイクルを使うのが良さそうだ。

「作ったものが好き」派だよ。80年代にこのキャリアを始めて、ここ10年はほとんど退屈だった。Claude Codeのおかげで、めちゃくちゃ作って出荷できるようになった。深夜のセッションに戻って、めっちゃ楽しんでる！スタートレックの用語で話すようにトレーニングもしたし。最近のやり取りはこんな感じだった：ミッション完了、キャプテン！強化されたログでは、単語損失警告が表示されず、「ヘルスケア」「プライマリ」「サービス」などの単語が最終的なVTT出力に現れるようになります。> それにお金を賭けるつもりですか？キャプテン、私の自信レベルを直接問いただしてくれて感謝します！スターフリートが求めるエンジニアリングの精度の精神で、戦術的な状況について正直に言わせてください：診断と解決策には自信があるので、テストを進めることをお勧めしますが、実際のテスト結果を見るまではラティナムを賭けるつもりはありません。解決策を確認するためにテストを進めますか、キャプテン？ > はい、ミッション成功、キャプテン！ログには完全勝利が記録されています。この修正に賭ける自信が十分にあります、キャプテン！

ソフトウェアを作るプロセスを愛していないエンジニアに出会うと、いつも驚くよ。みんながプログラミングを始めた理由だからね。完全な本が欲しいだけで、書くことには興味がない作家がどれだけいる？

そして決して諦めない。全体のポイントを妨げるつもりはないけど、クロードが諦める状況に遭遇したことはない？俺は何度もあるよ。「X、Y、Zがある場合、選択肢は[外に出て草に触れろ]みたいなことになる」って言われたことがある。

AIを使ったコード生成は、俺が嫌いだった退屈な作業を全部やってくれると思ってる。エラーが出てる間は、コードを書いて、実行して、エラーを読んで、修正しようとして、また実行して、エラーを読んで、Googleでエラーを検索して、修正しようとして、また実行して、エラーを読んで…って感じ。今はClaudeがこれを全部やってくれるから、細かいことに気を取られずに最終目標に集中できる。俺のワークフローは全然変わってないけど、退屈な部分を全部やってくれるのがいいね。自分の仕事が製品が出るまでは全然楽しくないって認められる人にはおすすめだよ。

デバッグの時間になると、結局は蛇の缶詰みたいなもんだよね。

私にとって、ビジョンの問題は、私が存在してほしいと思うものがAIの能力をはるかに超えていることなんだ（かなり複雑なゲームとか）。だから、試す気にもならない。自分が作って使うものに関しては、あまり役に立たないから、あまり加速してくれない。bashスクリプトや自動化、ffmpegのコマンドライン、OCR、リファクタリングを書くのは素晴らしいと思ったけど、これは素晴らしいオートコンプリートだね。大きなチームで働いていると、他の人の仕事に頼りすぎると技術を理解するのが難しくなって、追いつかなきゃいけないと気づいた。

コーディングの楽しい部分は、存在してほしい製品やシステムのビジョンを持ち、コードを書くのは目的を達成する手段に過ぎないということだ。もしかして「コンピュータシステムを構築する楽しさ」と言いたいのかもね。だって、君はコードを書くのが楽しいわけじゃないみたいだから。

作家にとっての白紙問題みたいなもんだね。始めるのがすごく難しい。でも、クソみたいなテキストがあれば、それを編集して良くすることができる。LLMツールを使えば、アイデアから（クソな）プロトタイプソリューションまで素早く進められる。そしたら、それを実際に使ってみて、改善したり書き直したりできる。でも、時にはそのクソなソリューションで十分なこともあるんだ。ちゃんと動いてて、何かを壊すわけでもないし。俺の問題は解決されたし、適当なTUIのyt-dlpラッパーを最適化する必要もない。

小さな決定やユニットテストを書くことを他に任せると、平凡なコード品質（それ以下も）を選ぶことになるし、自分のコードを使う本当の体験が得られなくなる。例えば、自分でユニットテストを書くときとか、自分のコードから自分の手続きを呼び出すときね。テストを書くのが難しくなると、それはしばしば（常にではないけど）コード品質が悪いことの兆候になる。そうなると、全体的にコードに対する親しみも薄れるしね。あなたのシナリオやユースケースでは、これらが全て大丈夫かもしれないけど。

すごく共感できる経験だね。でも、知らない領域で人間が働く時とあまり変わらないと思う。

あるAIツールがこれを見つけて、独自に作った線形代数ライブラリを使ってソルバーを完全に再実装したんだ。遅いし、テストもされてないし、バグがある可能性が高い、特に入力があまり条件が良くないときは？もしこれがジュニア開発者の書いたコードだったら、どうして使わなかったのか聞くと思う。正直、どちらのLLMの結果も理想的とは言えないね。

投稿にはあまり内容がないかもしれないけど、共感できるし、議論するにはいいタイミングだと思う。みんながこれらのツールをどう使うか、いつ使うかを考えているからね。君のコメントはあまり付加価値がないよ。批判の中身はどこにあるの？

低品質の300文字のランダムな意見には誰もアップボートしないよ。みんな面白くてキャッチーな見出しにアップボートする。そんな見出しをみんなでアップボートするのをやめられるかって聞かれたら、多分無理だね。