その通りだね。30年前に知り合いの数学者が言ってたんだけど、「プログラミングの唯一の良いところは、正確さを求められることだ」って。頭の中で色々考えるのはいいけど、たまには現実に直面するのもリフレッシュになるよね。

俺もそう思う。ラテを飲みながら新しいSAASプロダクトを作るために5人のエージェントを動かしてるって言ってる人たちを疑う権利は十分あると思う。そんな風に働くには、コードを深く掘り下げるのをやめなきゃいけないと思うし、良い品質を求めるならそれが必要だよね。でも、コードを書くエージェントは、些細だけど時間がかかる作業には結構役立つと思う。例えば、テストを書くのは得意だし。テストを調整して、ちゃんと動くか確認する必要はあるけど、全体的にはプロセスが早くなると思う。特定の設定での問題を解決するのも得意だし、Androidマニフェストの隅っこでの問題も見つけてくれる。ただ、解決策がない場合でも見つけようとするから、ちゃんと管理しておかないとね！今日は、5年前に放置してたプロジェクトを進めるためにClaudeを使ったんだけど、まだ進行中だけど、AIなしでは無理だと思ってたタスクが2-3時間で半分まで来た感じ。

これには同意する。これが私たちが理解を形成するための問題だよね。これが手元の作業で、自分たちのメモや人との議論、頭の中でエラーやアイデアを処理する静かな散歩…子供の頃からずっとこうだった。誰かに遊んでもらいながら、自分の欲求に合うかどうか評価するのを待ちたくなかった。欲求は遊びから来ることが多いし。これをLLMにアウトソーシングするのは、飛行機が失速するのに似てる…精神的にダウンしちゃう。ストレスもなくなるけど、LLMが「問題」を解決してくれると思うと、もう考えたり創造したりするインセンティブがなくなっちゃう。人によってアプローチが全然違うのが驚きだよ。仕事で、コードを作ってもらえることに夢中になってる人たちもいるけど、俺はそのグループには入ってない。

俺もこれには同意する。手書きの方がいい文章が書ける気がする。ニッチなアプリケーションに取り組んでるけど、標準的なCRUDやReactアプリではないからね。LLMは、以前のStack Overflowの使い方と同じように使ってる。もっと自動化しようとすると、自分でコードを書くよりもクリーンアップに時間がかかることが多い。AIが変なことをすることもあるし。非標準の幾何学的プリミティブのテクスチャ投影を書いたとき、投影に使った数学は局所的な領域でしか有効じゃなかった…長い話だけど。Claudeは、その関数を正しいと思って書き直そうとし続けて、関係のないタスクに指示しても全然やめなかった。超イライラしたよ。結局、その関数をコメントで包んで「消えてくれ」って言っておいた。

それは、多くの開発者がこういう働き方に慣れているからだよ。AIを使うなら、ソフトウェアアーキテクトのように考えるのが正しいアプローチなんだ。コーディングしながら考えるのではなく、事前に頭の中で計画することを学ぶのは、考え方のシフトが必要だけど、新しいツールを使うためには重要なんだ。これが自然にできる人もいれば、すごく難しいと感じる人もいるよね。

今でもそうしてるけど、書かれたものをレビューしたり、作ったものをテストしたりする時にね。私の見方では、重い仕様書アプローチに戻った感じだけど、エージェントのおかげで回転が早いから、アプローチを変えるコストがすごく低いから、すごく反復的に感じるんだ。今では仕様書（適用可能なテストも）を本当の仕事として扱ってる。できるだけ多くのことを仕様書に詰め込むけど、常に反復してる。エージェントと一緒に進めていく中で、機能やその全体的なアプローチを完全にやめることもよくある。AIエージェントは私にとってツールであり、加速装置なんだ。自分に合ったもっと自由なアプローチを見つけた人もいると思うけど、少なくとも今は、私たちが生み出しているものをレビューして考えることが私のアプローチになってる。それが進むにつれて私の考えを形成していくんだ。

1987年に初めてコーディングを始めたとき、最初はBASICで書いてみて、遅すぎるからアセンブリに書き直したり、最初からアセンブリで書かなきゃいけないってわかってたんだよね（BASICでは全然機能が使えなかったから、64Kのメモリの第二部やダブルハイレゾグラフィックスを使うために）。先週は、他の人が書いたウェブソリューションを数日かけて修正して、TerraformベースのデプロイからCloudFormationにCodexを使って変換したんだけど、フロントエンド開発を10年やってなかった自分でも、コードを見ずに機能を確認できたよ。もっと関連する話として、数時間かけてアーキテクチャを考えたんだ。クラウド + Amazonのマネージドサービス + インフラストラクチャーをコードで + 実際のコーディング、図を描いてラベルを付けて、分解やフェーズを考えながら進めた。必要な要件をマークダウンファイルにまとめて、ClaudeとCodexに各項目をテストしながらチェックさせて、何をしているかを要約させた。ウェブフロントエンドの修正と新しい作業の量を考えると、AIベースのコーディングがなければ、他の開発者に手伝ってもらっても2週間かかってたと思う。でも、一人で3、4日で終わったよ。実際のところ、数百のドキュメントには期待通りに動いたけど、20倍のドキュメントをシステムに投げ込んだら完全にダメになっちゃった。LLMがなかったら、顧客に「今、2週間の時間を無駄にして、他の2人のリソースも使った」と言うのは完全に無能に見えたはず。今は、まさに白紙に戻って、再設計して、マネージドサービスが抽象化していたことを少し手を加えてコードでやり直して、新しいマークダウンファイルを作って1日で終わらせた。その再作業だけでも1週間かかってたと思う。マネージドサービスがやっていることの理論は知ってたけど、実際にやったことはなかった。自分一人でデリバリーを責任持ってやったのは10年以上前で、他の人に委任することなく、デザイン文書を作るほど単純なものだった。最近の1年で、調整や「神話の人月」のオーバーヘッドなしで、自分一人で大きなプロジェクトを引き受けられるようになった。イライラした瞬間にCodexに「お前がやったのは過剰に複雑なクソみたいなもんだ、基本から実装を考え直せ」と言えるようになっても、HRに報告されることはないしね。今は、やるべきことがわかってるから、時間がかからずにやれることも多いよ。

歴史的に見ると、ソフトウェアエンジニアリングは多くの人に「組み立てライン」の仕事だと見なされてきた（仕様の引き渡しやウォーターフォールを通じてアウトソーシングしようとする努力を見てみて）けど、実際には設計しながら構築する形で実施されてきた（誰もすべての質問やエッジケースを事前に予測することはできないし、ソフトウェアの仕様は実際のコードの分岐の数よりもはるかに単純なことが多い）。ミッションクリティカルなアプリケーションにおいて、「実際のコードを書く」ことがこれほど安くなると、コードを書く際に人間が直接関与しないときに、もっと正式な設計を前もって行う方が理にかなってくるのではないかと疑問に思う。

自分の考えを形成するのは、コードを書くことと、それを画面で見て、その限界にぶつかることに影響されてる。完全に同意だけど、そうやって仕事を見積もるのはどうするんだろう。もっとひどいのは、他の人がやる仕事を見積もるプランニングポーカーだよ。

自分の考えを形成するのは、コードを書くことと、それを画面で見て、その限界にぶつかることに影響されてる。私が長年持っている二つの原則が、あなたの感情やこのスレッドに関連していると思うので、以下に再掲するね。役に立てばいいな。まず、ソフトウェアを作るときは、それが問題に対する自分の理解のスナップショットであることを忘れないで。未来の自分を含め、みんなに自分のアプローチや明確さ、問題に対する解決策の適切さを示すものだから、発言は慎重に選ぼう。そして、コードは何をするか、どうやってするか、いつ使うか、誰が使うかを答えるけど、なぜ存在するのかは答えられない。コメントがそれを達成するんだ。もし開発者がコードがなぜ存在するのかを考えないなら、彼らと一緒に働く意味はあるのかな？

アンダーグラウンドレジスタンスがAIを毒データで妨害しようとしている https://news.ycombinator.com/item?id=46827777

あのエンジニアたちがCCのひどいパフォーマンスを直すまで、信じられないな（冗談だけど、なんでできないのかは気になる。できそうな気がするし）。実際、あの人は6〜12ヶ月以内にIPOを狙ってるみたいだよ。「クラウドを使わないと置いていかれる」って言ってるのは、そのせいなんだろうね。

全体的にしっかりした投稿だし、経験豊富な人にとってもいいアイデアがいくつかあるね。「認証や認可など、高いセキュリティリスクのある機能を特定してマークする」っていうのはその一つで、こういう領域のコードを書く時はもっと時間をかけるけど、明示的なマークシステムは素晴らしい提案だよ。即座にレビューするメリットに加えて、将来のアップデートにもその文脈が残るからね。「物事を分解する」っていうのは、今やほとんどの人が本能的にやってることだけど、経験の浅い人がそれをうまくできないのをよく見るよ。

私は逆のことを感じてる。昔は手書きで全部書くのが好きだったけど、今はClaudeのおかげでアーキテクチャにもっと集中できるようになった。コーヒーを飲みながらプロジェクトの次の部分について考えるのが好きで、どう書きたいかを考えると、Claudeがそれを埋めてくれるんだ。時々間違いもするけど、自分が気づいてなかったコードのミスも見つけてくれる。

しっかりした足場とお世話があれば、モデルをもっと早く効率的に動かせるよ。ツールを早く作れるしね。私はただコードを書くためにコードを書くんじゃなくて、作りたいものを作るためにコードを書くんだ。

宇宙飛行士1、AI支援の開発者たち：つまり、コードを書く前に何を書きたいかを計画して仕様を決めるのが重要ってこと？ 宇宙飛行士2、ティム・ブライス：いつもそうだったよ…

まだ「ポータルで考える」ってことが足りてないよね。普通は、コーディングは高くついて時間もかかるから、事前に詳細な仕様を求めるんだけど、AIがある今はコーディングが安くなった。だから、AIに仕様を飛ばさせて、適当にコードを書かせて、次にそのソリューションを見直させて理解を深めさせて、より良いソリューションのための仕様を設計させて、また書かせる。必要なだけこれを繰り返せばいい。これ自体は新しいことじゃなくて、基本的にはジョー・アームストロングのプログラミング手法だよ。歴史上初めて、これが過剰に高くつかないってことなんだ。

開発者を10分以上やったことがある人なら、納期が迫っているときにベストプラクティスを常に守るのが難しいってことはわかるよね。でも、実際のコーディング時間がゼロに近づいているなら、他のことにもっと時間を使えるようになるんだ。AIシステムが実際に書いたドキュメントをコンテキストの一部として使うから、その重要性も増すよ！直接的な価値が見えると、以前は贅沢だと思われていたことを真剣に考えるようになるんだ。開発者を10分以上やったことがあるなら、非常に良いドキュメントを一生懸命書いたのに、次の人に無視された経験があるはず。LLMはそうじゃない。彼らは君のドキュメントを読むんだ。

私のセットアップにはいくつかのことが含まれていて、時々LLMが何かが通過したと嘘をつくことがあるんだ。

こういうのは、あんまり直面しない問題だな。考えが曖昧だったり、冗長なコードだったり、不必要に防御的なプログラミングが本当にコードベースを腐らせる。正直、上に挙げたルールの中には、最大限の保守性を目指すなら無視してほしいものもある。

これ、私も同じようなところに落ち着いてる。プリコミットフックは譲れない。Claude Codeが「すべてのチェックが合格」と報告したとき、実際には14個のeslintルールが失敗してたこともあったし。静的解析を超えて、もっと厄介な問題にぶつかってる。すべてのリントルールを通過し、クリーンにコンパイルされ、テストスイートもグリーンだけど、仕様の微妙に間違った解釈を実装してるコード。例えば、404の代わりに空の配列で200を返すAPIハンドラーとか、技術的には正しいけど意味的には間違ってる。意図に対する行動の正しさを評価すること、単なる構文や型安全性だけじゃなくて、これはまだ誰も解決できてないギャップだよ。プロパティベースのテストは役立つけど、 invariantsを事前に形式化する必要があって、これがしばしば難しい部分なんだよね。

彼らはまた、現在および過去の世代のLLMによって生成された無駄な情報も読むことになる。