みんなが見落としてるのは、たまにうまくいくこともあれば、うまくいかないこともあるってことだよね。「他の誰かがやるともっと良くなる」とか「自分が使ってるモデルよりも良いモデルがあるはず」とか「もっと上手にプロンプトできれば、いい結果が出るはず」とか「自分が使ってるIDEよりも優れたエージェントがあるはず」とか、そういうことを考える人が多いけど、確かにそういうのはあるかもしれない。でも、結局のところ、確率が変わるだけで、うまくいく時といかない時があるのは変わらないんだよね。例えば、エージェントにちゃんとしたデータを表示する画面を作ってもらったことがあるんだけど、最初は素晴らしいものができたけど、いくつかのフィールドが抜けてたり、フォーマットが不一致だった。でも、それを指摘したら、ちゃんと直してくれたんだ。プロダクトマネージャーやエンドユーザーの言葉で話してくれたからね。コードの質もすごく良くて、自分が書いたのと同じくらい、いや、もしかしたらそれ以上かも。もちろん、そうならないこともたくさんあるけどね。タイプスクリプトの型がよく分からないコードをいじってて、変なエラーメッセージを与えたら、理解しようと試みたけど、結局うまくいかなかった。1日か2日かけて「ラバーダック」として使ってみたら、何が悪いのか、どう直せばいいのかが分かるようになった。エラーが出ても理解できるし、エージェントも理解できるようになったりする。たまに型チェックに引っかかるコードを書くこともあって、「tscを実行してエラーを直して」と言うと、ちゃんと直してくれることもあるし、誇れる仕事をすることもあれば、つまらない型ガードを追加することもある。例えば、「if (x && typeof x === "object") x.someMethod()」みたいな感じで。基本的に同じ問題を与えても、Javaでテストを書くとなると、全然違うアプローチを取ることもある。ある時は、他のテストで使っている依存性注入フレームワークを使って、プライベートフィールドにモックを注入するけど、別の時は、プライベートフィールドにモックを直接注入するためのヘルパーメソッドを書くこともある。こうしたランダムさをうまくコントロールできるテクニックもあるかもしれないけど、結局はうまくいく時といかない時があるから、良い時だけ話したり、悪い時だけ話したりしたら、全然違う話になっちゃうよね。

一番最悪なのは、LLMがコードに微妙なバグを導入して、それをすぐに見つけられないことだよね。最近、Langfuseの統合をやってて、Cursorを使ってトレースやスコアをすぐにプッシュするためのスケルトンコードを生成したんだけど、生成されたコードには「score_id」っていうパラメータが含まれてて、Langfuseではドキュメント化されてなかったのに、なぜか受け入れられて、全体のトラッキングがめちゃくちゃになっちゃった。何度もデバッグを繰り返しても、トラッキングの問題が何なのか分からなかったけど、別のLLMにコードの可能な問題を見つけてもらったら、そのscore_idの行をすぐに指摘してくれた。

HNで見つけたブログ記事が、LLMを使ったコーディングのやり方を完全にレベルアップさせてくれたよ。https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/ AIが質問をしてくれて、PRDや仕様について考えることで、システムデザインが上手くなった気がする。

MITでCSの学位を取得して、2004年から2020年までプロのソフトウェアエンジニアリングをしてたんだけど、最近別の分野で会社を始めたから、約4年間本格的な開発はしていなかったんだ。今夏、休暇を取って、自分の業界に特化した小さなソフトウェア趣味プロジェクトを始めることにした。初めてCursorを試してみたんだけど、新しいコードベースを立ち上げる際の面倒なことを実装するのに、すごく役立った。ビルドシステムの設定、ライブラリやAPIの調査、設定やI/Oのためのフレームワークの実装など、全部助けてくれた。もちろん、難しい部分は自分でやらなきゃいけなかったし、（おそらく一番重要なのは）Cursorが書いているコードを理解して、間違った方向に行った時には修正しなきゃいけなかったけどね。実際に「いや、なんでそんなやり方するの？Xの方がずっとシンプルだよ」と言ったら、だいたい直してくれた。何回か、自分でたくさんのコードを書いた後、久しぶりにプロジェクトをコンパイルしたら、（普通はそうするように）解読不可能なC++のテンプレートエラーの森に突っ込んじゃった。全部をスクロールする時間を使う代わりに、「コンパイルエラーを直して」と言ったら、ちゃんと直してくれた。もう一つの例として、「このクラスの比較演算子を実装して」と言ったら、5秒で終わった。プロジェクトが複雑になるにつれて、欲しい動作のテストを書くのがすごく役立って、「このテストを通して」と言ったら、ちゃんとやってくれる。コードベースを理解して、ジュニアデベロッパーのように追加してくれるから、すごく良い仕事をしてる。IDEを使って、全体のコードベース（ビルドシステムやテストを含む）にアクセスできることが重要だね。ChatGPTを単独で使って、コピペするのは価値がない。最初から全てのプロジェクトをやるのは無理だけど、面倒な作業からは助けてもらえたから、十分価値があると思う！

Claude Codeのことはしばらく聞いてたけど、1週間前に初めて試してみた。Macアプリのアイデアをプロトタイプするために使ったら、すごく早くプロトタイプを立ち上げられることに気づいた。数分でできちゃうんだ。手で打たなきゃいけなかったボイラープレートコードを省けるから、何百回もやったことがある作業がめちゃくちゃ楽になる。自分の経験から、この記事の著者がタスクを完了するために何を試したのかが、使い方に影響しているんじゃないかと思う。プログラミング言語やプロジェクトの規模がどれだけ違いを生むのか、他の投稿者も意見を聞かせてほしい。アプリのアーキテクチャを理解して、潜在的なリファクタリングについてフィードバックをくれることもあったけど、そこまで頼んではいなかった。Claude Codeを試す前は、ChatGPTやDeepSeekを使って、APIやフレームワークの使い方について一般的な質問をしたり、正規表現を使ったテキスト解析の関数のような短いコードスニペットを求めたりしてたから、正直言って、最先端の技術が実際に何ができるのかに驚いたよ、少なくとも自分のプロジェクトに関しては。

逆に、全く同じくらい迷ってるよ。開発のためにLLMを使う段階を何度も経験してきた。GPT3.5時代：これはすごい、ああ、全部幻覚だ。最初に思ったほど役に立たない。GPT4時代：スタックオーバーフローのステロイド版として非常に役立つ。Claude 3.5 Sonnet：ほぼ常に開いていて、質問をし続けて、実際にシンプルなコードを生成させるのが、昔のグーグル検索みたいに感じる。IDE内のAI「チャット」機能をたくさん試したけど、全然期待外れだった。今は、ほとんどClaude Codeで全てをやってるから、IDEを開くことは滅多にない。たまに「手動」でリファクタリングすることはあるけど、これは自分の精神的な健康とコードベースの理解のためだね。今日、Claude Codeに数分でやらせたタスクの例を挙げると、Bootstrapスタイルの見た目が古臭い管理パネルを、見栄え良くしたいと思ってた。Claude Codeにプロジェクトのマーケティングサイトを取得させて、そこからCSSやロゴ、フォントを取得して、管理パネルプロジェクトに似たスタイリングを適用させた。10分以内に、自分がやったことよりもずっと良い見た目になった（少なくともデザイナーの助けなしでは）。その後、プロジェクト全体（数十の画面）を通して、「説明」コピーを更新させたけど、ほとんどがTODOのプレースホルダーで、何が何をするのかをきちんと説明するためのものだった。さらに、コアフローにe2eテストスイートを追加させたけど、これもテレビを見ながら1時間もかからなかった。これまで絶対にやらなかっただろうな。ずっとやろうと思ってたことだし、このパネルに入るたびに、どれだけ使いにくいか、みんなに説明するのがどれだけ大変かにため息をついてたから。

あなたは一人じゃないよ。これは、彼らにチャンスを与えようとしたときの経験そのものだね。今は別の言語を話してるだけなんじゃないかって心配になる。追記：他のコメントを見て、文脈を追加すると、私はほぼ専らC++でGPUドライバーの仕事をしてる。

コードは負担だよね。LLMに任せると、クソみたいな抽象化や無駄なコメント、理解するのに余計な脳の力を使う奇妙なパターンが何千行もできちゃう。今は、原始的なコピー＆ペーストをウェブチャット（Kagi Assistant経由）に戻してる。フリクションがあるから、各プロンプトやどれだけのコードコンテキストを与えるかをすごく考えるようになったよ（simonwからのファイルをプロンプトに集めて）。フロントエンドやウェブアプリの経験はあまりないから、監視付きのコーディングフローを試してる。プロンプトごとにほとんどのコードベースを渡して、一つの機能を頼んで、コードの出力を全部読んで、悪いパターンを減らすために何回か繰り返してる。普通は、その後自分で打ち直すか、せいぜい数十行のスニペットをコピーするだけ。フルファイルを変更済みで頼むのはうまくいかないことが分かった。時間がかかるしトークンも無駄になるし、無関係なコードが壊れたり切り捨てられたりすることが多い。今のところ、このプロジェクトはうまくいってるよ。ほとんど自分で監査して打ち込んだから、コードには詳しいし、実際に知識も身について新しい概念（VanJSのリアクティブステート）も学んでる。将来的にLLMなしでもこのプロジェクトを維持できる自信があるし、同僚に引き継ぐことも考えてる :)

「バイブコーディング」を仕事で成功させてきた者として、AIツールを信じるようになったのはエージェンティックな指示のおかげだと言える。あまり成果が出せないのと、実際に物事を進めるのとでは大きな違いがある。HNではこのトピックについていくつかの記事が出てるから、ぜひリポジトリに実装してみてほしい。

これは投稿じゃなくて、ただのランダムな意見だね。それに、彼らが小さなウェブアプリをLLMより早くコーディングできるなら、帽子を食べるよ。30秒以内に動かすために必要な2000行以上のコードを書いてみてほしいな。彼らの態度は、最初から役に立たないことを望んでる人の期待通りって感じだ。自己実現的な仮説だね。