どうして速くタイプすることで、問題を早く理解できないの？逆立ちしたらどうなの？

どうして間違ったものを速く作ることで、正しいものを早く見つけられないの？顧客は通常、単位時間あたりに許容できる失敗の回数が限られてるから。フィットネス関数を実行するのは、他の人の時間を考えるとかなり高コストなんだ。これはB2B/SaaSの銀行業界での最大のボトルネックだよ。もし本当に良いクライアントがいれば、週に一回くらいはイテレーションできるかもね。

問題を理解する前に実装に取り組んでるからじゃない？

なんで？ 速くタイピングすることで、問題をもっと早く理解できるってことはないの？ 速くタイピングすることで、問題を早く理解できる例（おもちゃみたいなやつでもいいけど）ある？

なんで？ 速くタイピングすることで、問題をもっと早く理解できるってことはないの？ 速く話すことで問題を早く理解できるってことはないの？

なんで？ 速くタイピングすることで、問題をもっと早く理解できるってことはないの？ ある場合にはできると思うよ。例えば、最近ある機能のプロトタイプを作って、その統合をテストしたんだ。数時間かかったけど、オープンコードがなければ、これを試すことすらなかったし、成功することもなかったと思う。機能をテストしてたから、パフォーマンスやメンテナンス性、シンプルさにはこだわらなかった。問題の説明をより良く書けたし、それに取り組んでる人にも統合がうまくいくって保証できた。これは価値があったよ。でも、そのプロトタイプコードはすぐに捨てちゃったけどね。考える必要がなかったから。

AIが本当に得意なのは： 1. 何かを、過去に何度もやったことがある場合で、それを圧縮データセットの中から見つけられる時 2. 何かを求めていて、ざっくりそれが欲しいものであれば大丈夫 でも、実際にはこれがエンジニアにお金を払って書いてもらうソフトウェアの大部分ではないんだ。そして、実際にコードを書くことは、あなたが払っているものの一部に過ぎない - 大多数の人が思っているよりずっと小さい。外科医にお金を払っているのは、ただ切るためだけじゃないし、エンジニアにお金を払っているのも、ただコードを書くためだけじゃないんだ。

早いプロトタイピングは、プロトタイプが問題に接触させるときに役立つ。たとえば、ユーザーが「違う」と言ったり、デモの下で仕様が崩れたりする場合ね。もしループが自分がタイピングしてデバッグして磨きをかけるだけなら、リポジトリの中で大きな混乱を生んで、自分自身にその混乱が何かを教えてくれたと思い込んでいるだけだよ。コードは質問をする一つの方法であって、良い質問をした証明ではないんだ。時には、PMや顧客、チケットを書いた人との面倒な1時間が最善の手段だったりする。

なんでダメなの？早くタイピングすることで問題を早く理解できないの？時には、ゆっくり考えないと理解できないこともあるよ。思考を数字のブラックボックスに委ねて、出てきたものをそのまま受け入れるのは、ゆっくり考えているとは言えない（つまり、じっくり考えること）し、目の前の問題を処理することでもない。逆に、トンネルビジョンに入って力技で進めているだけだよ。つまり、ショットガンコーディングってやつ。

元のアジャイルジョークを思い出すな、「30日以内に欲しくないソフトウェア」。今は「5日以内に欲しくないソフトウェア」だね。

企業は本当に良いコードを求めていない。 もっと寛容に考えられるかもしれないけど、こう言いたいな。「企業は本当に良いコードを求めているけど、良いコードのメリット（将来の柔軟性、低いメンテナンスコスト）をコスト（デプロイの遅れ、機能の減少）と天秤にかけている。」各企業は自分たちが適切だと思うトレードオフを選ぶ権利がある。技術者は、リスクや理由を説明する責任があるんだ。弁護士が自分の専門分野でやるようにね。

彼らは良いコードには興味がないけど、良いコードに気を使う人にはたくさんお金を払ってる。雇った人たちが気にしなかったら、私たちのソフトウェアの品質は今より悪くなってるよ。そして、AIの影響で人々が気にしなくなってきているから、どんどん悪化している。

物を作るスピードが速くても、実際にはあまり役に立たないんだよね。必要なのはモデルとシミュレーションフレームワークだよ。従来のやり方では、通常はシンプルなモデルとフレームワークから始める。新しいパラメータを追加するときは、フレームワークを適応させて、バランスの取れた入力セットを見つけたら、どの新しいパラメータを追加したいかを考える。この反復がモデルやシステムの挙動を深く理解することにつながるんだ。LLMの使用は通常、全パラメータセットのシステムを構築することだから、スピードの向上はシステムの理解がないことや、シミュレーション空間が広すぎてユーザーが探索しようとしないことによって相殺される。シミュレーションのための完全なテストスイートについての話はたくさんあるけど、それは離散的で、入力空間の特定のポイントを証明するだけなんだ（有限のポイントを通過する曲線はたくさんあるから）。

もし本当にそう思うなら、コードを直接アセンブリに変換すればいいじゃん。仲介者を省いて、パフォーマンスを一気に上げよう！

高水準言語のソースコードは、もうあまり違いがないよね。ソースコードは、自然言語とは違って、ある意味で形式的な言語なんだ。

どの比較も意味がないよ。要するに、これらの概念を理解するのが重要だよ： - 決定論 vs 非決定論 - 概念的整合性 vs 「なんとなく動くから、触らないで」

これ、コピペの返答？ このサイトの他のAIスレッドでも全く同じことを見たことあるよ。

LLMが高水準の指示を低水準の指示に変換できるからって、コンパイラになるわけじゃないよ。

LLMでのコーディングを、ただスタックを上に移動するだけでコンパイラと変わらないように見せるのが本当に嫌だ。コンパイラは決定論的で、理解できるルールがある。出力を見ればパターンがわかるし、コンパイラが何をしているのか、なぜそうするのか、どこでそうするのかがわかる。そして、それをするのは決定論的なんだ。

高レベル言語で記述されたセマンティクスは、絶対に決定論的に維持される。エージェンティックコーディングでは、セマンティクスは決定論的に維持されない。拡張されたり、圧縮されたり、変更されたり、さらには失われたりすることもある；非決定論的にね。

GCCが生成するASMをレビューする（私たちはしない） もちろん、しないよ。必要ないからね。高次言語をアセンブリにコンパイルするプロセスは決定論的で、よくテストされている。常に同じ結果を出すものをレビューし続ける必要はない。 > 私たちは、それが機能し、期待されることに対して正しいことを気にしている。そうだね。これがLLMの出力にはないものなんだ。なぜなら、誤解したり、幻覚を見たりすることがあるから。だから、常にレビューする必要がある。それがコンパイラの出力とLLMの出力の違いだよ。

私の経験では、そんなにうまくはいかないよ。複数回リモデルされた家に似てる。最終的には、その家の構造的なキャパシティが限界に達して、内装を全部剥がして再構築しないといけなくなる。今のところ、コーディングエージェントは間違ったパターンを選んだり、必要な抽象化や追加システムが必要なところで力技で解決しようとしたりする。いくつかのPRがあったからって問題になるわけじゃないけど、開発チームが常に貢献しているリポジトリでは、すぐに厄介なことになって、エージェントが技術的負債に苦しんでいるように見えることもあるかも。いつかプログラミング言語を書くのをやめられる日が来るかもしれない。考えさせられるアイデアだけど、実際にはまだそこまで行ってないと思う。

僕はちょっと違った見方をしてる。コードは解決策を伝えるための手段なんだ。 > 「プログラムは人が読むために書かれ、機械が実行するのは偶然のことだ。」 -- ハル・アベルソン これがないと、コンピュータやプログラムをもっと魔法のように扱うことになっちゃう。もし「エージェント」が何かを誤解して、その「誤解」をコードにしてしまうと、結果的に間違ったものになる。だから、詳細を見に行けるようにしないといけないし、ただ機械の神に犠牲を捧げるだけじゃダメなんだ。

これは明らかに違うよ。私の30年間のほとんどはこうだった。1. ビジネスと話をして、XY問題を解決し、組織の複雑さに対処し、ビジネスやそのニーズを学ぶ。2. 「コード」だけじゃなくてアーキテクチャを設計する、コードは何かで動かさなきゃいけないから。3. デザインを承認して、ホーリー・トリニティ（時間・コスト・予算）に合意する。4. 実装を行う。5. 既知の要件に対してテストする。6. ステークホルダーの承認を得るか、たぶん#4に戻る。7. 本番環境に移行する。8. メンテナンス。これらの中で、#4は常に必要な地味な作業だと思っていて、特にAI以前のエンタープライズ開発では、ほとんどの開発者の仕事が10年以上も商品化されてきたから。ビッグテックや関連するコードでも、他のステップを処理できず、大きな/影響力のある/あいまいなプロジェクトをリードできないと、中堅開発者のままだよ。#5に関しては、多くはAIによって書かれ、レビューされるべき自動テストで行うことができるし、そうすべきだよ。もちろん、UIやUXのテストには人間が必要だよね。LLMは今、たくさんの地味な作業をこなせるようになってる。

これ、かなり的を射てると思う。理想的には、コードを行ごとにレビューしなきゃいけない。テンプレートやジェネレーターみたいなもので、助けにはなるけど、10倍にはならないよ。要件の収集も10倍にならない限り、今のところAIはその影響を与えてないから。

タイトルの意図は、あなたの主な問題を指摘することなんだ。あなたを$PROFIT$から隔てている問題は、 1. アイデア 2. ??? 3. 利益 コーディングがうまくいかないのは確かに一つの問題で、AIがその問題を助けるのは正しい。でも、スタートアップや副業、VCへのピッチ、企業の内部事情（HNの人たち）にとって、コーディングは決して問題じゃなかったんだよ。

でも大きな違いがあるよね。食器洗い機は水とエネルギーを節約する技術なんだ。LLMが全部悪いとは言わないけど、食器洗い機と比較するのはあんまり良いアイデアじゃないと思う。