エージェントを使った私のプログラミング術
引用元：https://news.ycombinator.com/item?id=44221655
コンテナはプログラミングに便利だって。Docker作ったSolomon HykesもContainer Use公開したのも同じ理由で、エージェントを安全に並列で動かすためだってさ。Sketchは最初から環境あるけど、他のエージェントはそうじゃないっぽいね。[1] https://www.youtube.com/live/U-fMsbY-kHY?si=AAswZKdyatM9QKCb… [2] https://github.com/dagger/container-use
エージェントループ、機械の脳の話だね。ルールエンジンの代わりで、まだ変なとこもあるけど、Google出身の人たちが本質をよく捉えてるって。ツール繋いでプロンプトで動かして繰り返す感じ。人間の真似じゃなくて、曖昧な多段階タスクを自動化するのに便利そう。以前はコードで書いたとこが要らなくなるかも。本番での実行は心配だけど、ツールは進化するでしょ。100以上のサービス繋いだらどうなるか超楽しみ。全部に汎用的な抽象化を与えれば、今より全然すごいアシスタントになるかもね。
「汎用的な抽象化があれば今よりすごいアシスタントになるかも」ってとこだけど、可能性が広がるってことは、ヤバいことが起きる可能性も広がるってことだよね…。信頼性とかQA、権限管理、セキュリティ、プライバシーが超重要になるよ。AppleがSiriよりすごいアシスタントをすぐ出さないのは、こういう心配があるからじゃない？誰かが先に失敗するの待ってるのかもね。
「サービス連携（SMS, mail, weatherとか）」って話だけど、面白そうなプロジェクトがあるよ。エージェントをカレンダーとか天気に繋いで、ちょっとしたゲーム画面にしたんだって。これ見てみて。https://www.geoffreylitt.com/2025/04/12/how-i-made-a-useful-…
毎朝あんなの読みたくないな〜。カレンダーと天気だけ表示してくれればいいよ。絵とか図の方がパッと見て分かるじゃん。
コーディングでAI使うの好きなんだよね（これ自分で書いた！）。
・CSS：大嫌いなんだけど、AIがCSSのハック覚えててくれるから、要素を中央にするとか楽になった。
・Unit Tests：AIの知識が古くなければ使える。
・コミットの要約：ドラフトとしては良い。
・初年度レベルの小さいタスク。
CSSの知識が古いかもって話じゃないけど、最近のCSSは昔より全然良いから、一度しっかり勉強してみるのおすすめだよ。大規模なコードも管理しやすいし、中央寄せとかも簡単になったから。まあ、そうは言っても俺もAIに頼ってスタイリングしてるけどね。
AIってCSS書くのすっごい苦手だと思ったんだけどなー。まあでも、自分がやりたくないタスクに使うってのは分かるよ。俺の場合はチケットの説明書くのがAIの得意なタスクで、自分より断然良いもん。
チケットの説明の例、聞かせてもらえる？俺はLLMってチケット説明だと邪魔だって思ってたんだよね。箇条書きとかキーワードから良い文章書いてくれても、結局インプット（プロンプト）見れば分かるじゃん？って。でも、君はうまく使う方法見つけたみたいだね？
俺もCSS大嫌いなんだよね。見た目とか、前のコード壊さないかとか、いろんなデバイスで動くかとか、時間かかるし。Cursorとかいろんなモデルで試したけど、書いてくるCSSコードがマジでひどい。ハック知ってても良い答えにならないんだよ。自分で書いた方がマシ。だから、結局まだ手書きでコード書いてるよ。
CSSにLLM使いたくなる気持ちわかる！
でも、あとで困るコードの負債をいっぱい生み出すんだよね。
見た目は良いけど、普通のコードよりレビューがマジで大変だよ。
コード書くよりレビューにLLM使う方がヤバい機能かもね！
レビューってずっと微妙だったけど、これで変わるかも。
特にセキュリティとか、変な挙動、機能の使い間違いとかチェックできるのが良い。
今はエラー検索に使ってるけど、50%くらい当たってるから悪くないかな。
ChatGPTってよくあるバグ直すのに超便利！
Stack Overflowまとめてくれる感じ。自分で調べるより断然速い。
ただ、幻覚（ハルシネーション）で変な情報もあるけど、ネット検索よりマシかな。
コードの変なとこ見つけるのにLLM使えそうだけど、誤報も多そう。みんなそんな使い方してる？
「コードレビューして」って何度も頼むと、たまに変なことするよ。
前に変えたのを元に戻したり。
レビューには使えるけど、どんな変更を受け入れるかはちゃんと自分で見極めないとダメ。
良い変更がわかるなら、候補を出してくれるのはすごく便利だよ。自分で判断するのが大事。
なんでLLMをコードレビューに使う話って、もっとされないの？
開発者じゃないけど、周りの開発者は興味ゼロか、 actively にコード書くのに使ってるかのどっちか。
（これは seniority と逆相関する傾向かな）。
レビューで使う話はマジで聞かないよ。
コミットしたら自動でチェックする、とかがいいのかな？
LLMの最大の弱点は、コードのどこが良いかって「判断」できないこと。
細かいとこはウルサイくせに、人間が見ればヤバい大きな問題を見逃すんだよね。
ノイズにしかならない感じ。
だからみんなエージェントに注目してるんだよ。
LLMが間違えても、最終的に人間が判断するから、ある程度 reliable になるんだよね。
職場でAIレビューが増えてるけど、マジで使えない。10回に0回しか役に立たないよ。
言ってること自体は全く変じゃないけど、細かいニュアンスとか理由がわかってない。
でも、AIのレビューを無視したら後でシステムダウンした、って話もあるんだよね。
だから、10個のダメなレビューを我慢して、1個でも良いレビューがバグ防ぐならアリかも。
でも、もっと精度上げてほしいな。
今んとこ、LLMってコードレビューにはマジで向いてないっぽいね。
リンター入れた方がよっぽどマシだよ。
「コード書くよりレビューにLLM使う方がキラー機能かも」って話だけど、
GitHubでCopilotをレビュアーに使うって形で、もうできるよ。
提案はベストじゃないけど、作業の流れに入れるには十分使えるレベル。
Yeah Claude Code (Opus 4)はコードレビューにマジですごいよ。PR linkを渡すだけでgh cli経由でmd fileにしてくれるんだ。
フィードバックの質と量が増えたし、時間もかからなくなったね。 gemsも結構見つかるよ。
記事中の「assets」と「debt」の話、特に寿命とスコープ拡大の議論は面白いけど、同意できないな。
長く使われてるプログラムの多くは、元々短期間・狭い目的で作られたものが多いんだ。
科学分野だと、元々一時的なのに予想外に広がったコードによく遭遇するよ。
だから、将来を見越して書くようにしてるんだ。自分のためでもあるし、他の人のためでもある。
誰かの個人プロジェクトがグループプロジェクトに格上げされた時の苦労を知ってたら分かるはずだよ。
問題は、他にどうするかってことだよね。何が広く使われるかなんて、みんな予測が苦手だし。
丁寧にエレガントにプロジェクトを作っても、結局どこにも行かない失敗もよくあること。
コストが安いずさんなプロジェクトが成功する、進化論的な圧力みたいなものがあるんだよね。
これって、「worse is better」の現代版って感じかな。(https://www.dreamsongs.com/RiseOfWorseIsBetter.html)
代替策がないってのはその通りだね。完璧じゃないけど、僕がやろうとしてることを話すよ。
時間をかけずにコードを可能な限り分かりやすく書く（自分への配慮）。
そして、コードを書く時にそのスコープ（何を意図してるか、してないか）をドキュメントに残すんだ（CYA、自分の身を守るため）。
もし格上げされても、最初に限界を説明したよ、って言えるでしょ。
正直、科学分野だとドキュメントがあるだけで良いサインだよ。何もドキュメントがないプロジェクト多すぎ。
短いREADMEで「このコードはこのタスクのために、このタスクだけのために書かれた」と書くだけでも素晴らしいよ。
コードを書く練習をしないと、この能力って衰えるのかな。
本を読む能力が、必ずしも本を書く能力を意味しないのと似てるよね。
自分でコードを書く方が、より理解深まるし意見も出てくるけど、他人のレビューだと気が緩むというか、そこまで気にしなくなる気がするんだ。
これ、共感できるな。
僕の脳も、手でコード書くのに抵抗し始めて、ますますGPTが complete solutionを提案してくれるのを「待つ」ようになったよ。
最初のtryで答えが合ってないと、イライラするほど。
とはいえ、コーディング速度が何倍にもなったのは否定できない事実。
GPT使い始めてから、junior assistantには全く頼らなくなったし、一部のタスクはspecsとかmanual reviewを完全にスキップして、GPTで直接解決する方が楽になったんだ。
またありきたりな比較を持ち出すけどさ、assembly書かないとassembly書くスキルは衰えるけど、僕らの大多数はcompilerに任せることに全く問題ないでしょ。
この例えには問題あるけど（deterministic vs stochasticとか）、真実は変わらないと思う。
特定のスキルは失うかもしれないけど、abstraction levelを上げていけば問題にならないかもね。
assemblyを書く能力じゃなくて、assemblyを「読む」能力が衰えるってのが僕のポイントだよ。
これらのcode generatorsがbulletproofになるまでは、そのoutputについてreasoningする必要があるんだから。
筆者の「コードレビューは中途半端でほとんど機能不全」って意見に完全に同意するよ。
agentを使うと、bottleneckはcode writingじゃなくてcode readingになるね。
みんなが手抜きでレビューしたり、自分の個人的な好みを押し付けたりしてたら、agentを使うのは完全に破綻するよ。重大なsecurity issueやperformance hitを簡単に見逃しちゃうから。
正直、これらはcodeを「読む」だけじゃ見つけられないことが多いし、get your hands dirtyしてmanually debugするかassumptionsをtestする必要があるんだ。
agent/AIが書いたcodeが「half hearted review」問題をどう解決するのか、僕にはよく分からないんだ。
みんなcode reviewするのが嫌いなのは、それがtediousでboringだからでしょ。
softwareの「楽しい部分」、つまりcode writingを諦めて、代わりに読むべきcodeの山とreviewの山を得る、なんてことにならないとマジで良いんだけどね。
うん、俺もそれを心配してる。結局コードレビューしたり、テスト書いたり、すごく不正確な自然言語で仕様書みたいなのを書くことになるんじゃないかって。
ただ、このやり方が大規模プロジェクトでどうやってスケールするのか全然わからないけどね。
もっとコメントを表示（1）
これはソフトウェア開発を、一つずつ作るシステムから工場みたいな流れ作業に変えようとする試みだね。悲しいことに、うまくいってるみたいだ。みんなagileを嫌ってたなら、promptとかコードレビューのsweatshopsが来るのを覚悟しなよ。
あー、正直言って、今市場に足りないのはLLMが出力したコードとかdiffsとか全部読むためのもっと良い方法だわ。だって、コードベースのほんの一部しか書いてないのに、どうやってちゃんとレビューして全体を理解するの？
あるいは、プロジェクトに残された人間が本当にコード読んでるのか確認する術とかね。
それってagentsの目的じゃないの？
もし完璧なテストカバレッジがあるなら、AIがコードを書いて、それが安全か／速いか／その他、フィードバックを得られるじゃん。
それにAIがテストを書くの手伝ってくれるんだぞ！
いや、できないよ。モデルが訓練されたゴミみたいなデータが原因の一部だ。
個人的な例だけど、うちのdevたちがagentsを多用し始めてから、RCEみたいな（CVEは2019年の例）ほとんど過去の脆弱性とか、大量のinjection問題が復活したんだ。
どうしてこんなのが入ったのかdevに聞いたら、「LLMに聞いたら安全だって言われたんです。MAKE IT SECURE！って入力したのに！」だってさ。
何かを十分に理解してないと、それがデタラメだって見抜けないんだよ。こういう場合、agentが何度繰り返しても無駄。
これに付け加えると：LLMほど、俺をガスライトした奴は今までいない。奴らの主張はめちゃくちゃ説得力があるように見えるんだ。特定の質問とか反論にも自然に応答できるくせに、完全に間違ってる。securityとかcryptoでこれは特にひどい。これらは一般的にテストで検証されないからね（テストは機能があることは証明できても、無いことは証明できない）。
Rich Hickeyが言ってたけど、テストされたコードにはバグがないってのは周知の事実だって。
もっと真面目な話：書かれてるコードを深く理解してないと、どうやって意味のあるテストなんて書けるわけ？
素晴らしい投稿だね。Cursorを使った最近の経験がまさにこれだ。効果の飛躍的な向上はつい最近起きたことで、それは投稿の最後にすごくよく書かれてる通りだよ：
＞ エージェントを役立たせるためのクリティカルな部分の作業は、基盤となるモデルのトレーニングプロセスにある。2023年のLLMはエージェントを動かせなかったが、2025年のLLMはそれが最適化されている。モデルは与えられたツールを頑健に呼び出し、うまく利用する必要がある。これが得意な最先端モデルが今ようやく出始めている。そして我々の目標は最終的にオープンモデルだけで作業することだが、オープンモデルは最先端モデルにツール呼び出しの評価で遅れをとっている。6ヶ月で状況は変わると確信しているが、今のところ、有用な繰り返しツール呼び出しは基盤モデルにとって新しい機能だ。
そう、ソフトウェアエンジニアリングエージェントはシンプルなfor-loopだ。でも、それがシンプルなfor-loopでいられるのは、モデルがツール利用のために本当によく訓練されたからだ。
俺の経験だと、Gemini Pro 2.5が初めてここで可能性を示した。Claude Sonnet / Opus 4はどちらもここでの品質が一段上がってるね。ツール利用が失敗することは本当に稀だし、次のループで問題を解決できないことはさらに稀だ。
たぶん、俺が自分のツールしかコード書かないからだろうけど、誰か／何かにコードを書いてもらって、それを読んで、理解して、直す、っていうことのメリットがまだわからないんだよね。API Docから探してるものを取り出して見つけるようにLLMに頼むのは超便利で時間節約になるけどさ。
俺にとっては、将来これらのLLMがどれだけ賢くなるかって問題ですらないんだ。ただ他人のコードを読むのが嫌いなだけなんだよ笑。
君は古い働き方にしがみついてるね。今日、LLMが俺のDocker ComposeインフラをKubernetesに変換してくれたよ。operatorsとかhelm chartsも使いながら。数日かかる作業が10分で終わったんだ。俺は細かいアップデートをレビューして、必要なら修正するだけ。生産性がマジで向上したわ。君がオックスカートを引いてる間に、俺はトラクターを運転してるんだ。
AIが役立つ場面をリストアップ！定型的なコードとか、慣れてるけど覚えてないAPIの使い方とか、複数ファイルにわたる変更のプランニングとかね。特にプランニングは過小評価されてると思うな。あと、AIがコードのスタイルを守ってくれるのも助かる！疲れてるとそういうの気にしなくなるからさ。
僕が担当してるコードベースだと、複数のファイルを定型的・予測可能なやり方で変更するタスクがよくあるんだけど、これAIエージェント使うとマジで早い！前は3～4時間かかってたのが、99%正確にやってくれて3～4分で終わるようになったんだ。打ち込む作業が劇的に減ったよ。
「数日かかるところが10分」って話だけど、それって理解をAIに丸投げしてるって見方もできるよね。セキュリティとか色々最適化されてないかもだし、自分で分かってないと何がおかしいかも気づけない。
まるで、おじいちゃんがPCをBest Buyに持ってくのに似てるかも？自分で直せないから人に頼むっていう。
シニアエンジニアがジュニアエンジニアに仕事を任せるのって普通のことじゃん。それもコメント3で言われてるのと同じデメリット（理解のアウトソーシングとか）があるけど、どこのソフト会社でも全然問題なくやってるじゃん。このパターン、AIにも当てはまるんじゃない？
チームで働いてると、自分のコードじゃないものをレビューすること多いよね。AIコードのレビューもPRのレビューと大して変わんないと思うよ。自分のじゃないコードを見るっていう点ではね。ただ、AIの場合は生成されたコードを自分で編集しやすいし、すぐに直させることもできる点が違うかな。
こんな働き方、マジで気に入ってきたよ！コードのデザインを考えて、LLMに手順を教えて、LLMがコード書いてる間に自分はそれを読んで理解したり、直したり、次のことを考えたりするんだ。まるで料理みたいに並行作業してる感じ。オーブンとかフードプロセッサーみたいなツールとしてLLMを使うイメージかな。コーディングも一行ずつ書く線形作業から変わるかもね！
シニア開発者って、新しい機能のプランニングとか他の人のコードレビュー（PRレビュー）に結構時間使うじゃん。だから、そのスキルってコーディングエージェントと一緒に働くときにもすごく活かせると思うんだよね。タスクを渡してレビューするっていう点で、普段やってることに近いから慣れやすいかも。
コメント1の「慣れてるけど覚えてないAPI」の利用は注意が必要だよ。型付き言語でもね。例えばGoでシェルの出力取るコードを生成させたら、エラー処理が甘かったり。テストコードを書いてって言っても、テストケースが足りなかったりするんだ。ちゃんとレビューしないとダメだね。鵜呑みは危険！
コメント6の働き方、良い例えでよく分かるよ。ただ、常にコンテキストスイッチしながら、しかも「頭脳」として深く（しかも相手は人間じゃない！）考え続けるのって、自分には難しいかも。昔、優秀な人とペアプロした時は超楽しかったし生産的だったけど、彼らが思考の負担を担ってくれたんだよね。LLMだと自分が全部やらなきゃいけないのが心配。燃え尽きないで深い理解ができるのかな…。
コメント2の、複数ファイルにわたる定型的な変更が多いって話だけど、そういう変更が必要なくなるようにコードをリファクタリングするって考えたことある？AIで作業を速くするのもいいけど、根本的に変更が少なくなるように設計を見直すっていうのも大事だと思うな。
＞チームで仕事してるなら、見るコードのほとんどは自分のではないよね…AIコードレビューもPRレビューと大差ない…出力編集が楽だし、作者にすぐ直してもらえるかもしれない
って言うけど、それは違うよ。理解できない決定の「なぜ？」を聞けない（理由に特に因果関係を期待できない）、信頼できないPRレビューみたいなもんだ。学習や教育の機会もないし、将来のコードベース改善に繋がる洞察も得られない。だから、PRレビューとは真逆なんだよ。
＞複数の人と同時にペアプロしたことある
それがプロの料理人だった時のチーム仕事で一番好きだったんだよ。人間は社会的な動物で、脳の構造とか、過去25,000年で生理的にはそんなに変わってない。今の賢い人も3,000年前のギリシャの賢い人も、人口が多い分サンプルサイズが大きいだけで、大差ないんだよ。マンモス狩りみたいにグループで働くようにできてるんだ。
https://sc.edu/uofsc/images/feature_story_images/2023/featur…
＞これは理解を、結局何も考えないものに外注してるって別の見方だ
って引用を読み間違えてるよ。シニア開発者はジュニアエンジニアに「仕事」を外注するんだ。「理解」は外注しない。自分で仕事外注せずに理解を深めたからこそ、そもそもシニアになったんだよ。
いつも気をつけなきゃいけないけどさ、CombinedOutput() をああいう風に使うのは、人間が書いたコードでもよくあるダメな点なんだよ。
定型的なコードに弱い点が、私の視点からすると全部無駄に思えるんだ。それがうまくいくケースなんて想像できないな。でも、私がよく使ってる良いケースは、「spreadsheet inputs」を使ってLLMにspreadsheetデータに基づいたテストケースやコードを生成させることだよ。データも変わらないし、テストも変わらないからLLMは間違いなく役立つけど、これはもう二度と触らないコードなんだ。
違いは人間が学ぶってことだよ。私は10年前にCombinedOutputのこの挙動で痛い目に遭って、もうこの間違いはしないんだ。
これはAIにも当てはまるよ。ただし、違う形でね：1.コーディング時にAIに与えるルールやプロンプトを繰り返し改善できる。私はこれをよくやってる。私のプロセスは常に改善されてるし、その結果AIのミスが減るんだ。2.AIモデル自体が賢くなる。ここ数ヶ月だけでも、私がコードを書くのに使うLLMは、以前より格段にミスが減ってるよ。
知的なレベルがあまり変わってないっていう考えが、いつもちょっと不思議なんだよ。教育って人を賢くするんじゃない？少なくともそれが教育の主張の一つだよね。25000年前のhunter gathererの赤ちゃんが、現代社会に順応したら今の子供と同じくらい学習能力があるってこと？人間にとって25,000年って1000世代くらいだろ。そのスケールだと微妙な遺伝子の変化や進化はあるはずだ。でも、「賢さ」の本当の向上は社会レベルにあるんだろうね。Remember：社会のない人間は、”dumber” animal like apes and dogsと大差ないんだ。極端なneglectのケースを見ればよくわかるよ。feral childrenはとてもanimal-likeで、とても効果的に学習するのはかなり難しいんだ…
みんなと同じツール使ってる？絶対に「なぜ？」って聞けるし、たいていのdeveloperより適切なcontextでうまく説明してくれるよ。もしそれが合わないdesign patternを使ってるって気づいたら、rules fileに追加すればいいんだ。
LLMが90%正しく書けるformulaic codeはたくさんあるんだよ。macroじゃ作れないようなね。私が対応しなきゃいけなかった例だと、embedded scripting languageのlanguage bridge codeがあるね。scripting environmentで使えるようにしたいfunctionごとに、基本的にboiler plate functionを書く必要があったんだけど、すごくたくさん書かなきゃいけなかったんだ。
同意できないわけじゃないけどさ…やっぱ生身の人間と働きたくない？一日中AIと会話してるなんて最悪だよ。人間関係も築けないし、一人でコード書いてるより全然孤独だ。
もっとコメントを表示（2）
ジュニアが書いてるコード全部は分かんないよ。90〜95%くらいは理解できるけど、CSSの細かいハックとか、なんでそうなるか30分も調べてられないでしょ。そんなことしてたら何も終わらないよ。
AIに「なんで？」って聞いても、それは後付けの説明でしょ？実際にコードが生成されたプロセスとは関係ないんじゃない？違うモデルも同じように説明できないはずだよ。
CSSの細かい話とDockerインフラを比べるなんて、全然違う話を持ち出してるね。
ジュニアとLLMを比べるのは全然違う話だよ。ジュニアは責任取れるし教えられるけど、LLMは道具で責任取れない。LLMのせいにしたがる人もいる。シニアがLLMの出力の間違いを見抜けないこともあるしね。セキュリティの重大なミスはジュニアじゃなくてシニアがやってるのを見てる。LLMをちゃんと使うには、それを見抜けるだけの知識が必要なんだよ。
将来の変更に対応しやすいコードってこと？そういうコードはよく見るけど（自分で書いたのも含め）、残念ながら想定してた未来ってまず来ないんだよね。
週に10件くらいのタスクしかできなかったのが500件以上になったって？そんなヤバい生産性向上で、職場で何かメリットあったの？
なんかP≠NP問題みたいな感じ。簡単な関数なら、自分で書くよりAIに書いてもらって検証する方がほとんどの場合速い。LLMに書いてもらってチェックする方が時短になるね。
もしかして、私たちってバカになっていってるんじゃない？昔の人の方が今のリーダーとか発明家よりずっと賢かったケースは多いよ。賢い人の割合は増えたけど、Leonardo Da Vinciとかより賢いの？
ごく一部のエンジニアの経験から業界全体を語るなって反論、最近よく見るけど意味分かんない。動かなかったり、ユーザーに害を与えたりするのを気にしないソフトウェア分野なんてある？スタートアップの使い捨てコードの話を一般化するなよ。エージェントが作ったソフトをちゃんと調べないなんて、ありえないでしょ。
ローカルで使うスクリプトとか、ちょっとしたファイル整理用とか、次の報告会用のデモとか、そういう目的なら、まあエージェントで生成してもいいんじゃない？って思うよ。
でも、ソース管理にpushするような、長く使うつもりのコードだったら話は別。
その時点で、それは長く生きるコードにするつもりだってことだし、そうじゃないフリをしようとするのは自分に嘘ついてるようなもんだと思うな。
AIが「得意であるべき」なのは、私みたいに人間が書いたユニットテストをパスするコードを書くことだと思うんだよね。
AIは私たちが何を求めてるかを知ることはできない—私たちがユニットテストを書いて、それをパスするコードを書いてほしいって正確に伝えない限りはさ。
でも、今のLLMにそれができるのかな？
テストを先に書いて、AIに実装をお願いするやり方もあるし、逆にLLMにテストのひな形を作ってもらって、私が詳細を埋めるやり方もある。
私は普段、後者のやり方でやってるかな。
エージェントを使ってる人のうち、どれくらいの人が「プログラミング」自体、つまり問題の解決策を考えてそれをコードで表現するのが本当に好きなんだろうって思うね。
エージェントがやってる作業の多くは、その部分を取り除いて、代わりに自然言語で自分が何をしたいか説明させて、LLMがバグを入れないことを願う、みたいなことにしてる気がする。
逆に質問をひっくり返してみようか、何が好きなの？ってさ。
もう何千回も解決されてる問題のコードを書くのは、正直楽しくないんだよね。
辞書が必要なら既存のを使うでしょ、ハッシュテーブルを毎回ゼロから書くのは、最初の一回だけ楽しいんだよ。
「この言語の動くコンパイラ作って」とか、「深さ優先探索でこの問題解いて」って言えたとしても、プログラミングの楽しさは減らないと思うんだ。
自然言語の話と、前のコメントへの返信だけど、計算処理を自然言語で説明するのは不向きだってのは同意。
簡単な例ならいいけど、ある程度複雑になると、曖昧だったり矛盾すること言っちゃいがちだもんね。
でも、ここで誰もLLMを「盲信」して使えなんて言ってないよ！
生成されたかどうかにかかわらず、自分の成果物には自分で責任を持つべきでしょ。
なんでみんなジムに行くのが楽しいの？
あのウェイト、もう何千回も持ち上げられてるじゃん。
私はコードを書くのが楽しいのは、問題を解決する満足感、自分の頭の中から動くものを作り出す達成感、そしてプログラミングが上手くなってるって感じられるからだよ。
LLMでプログラミング能力を拡張するのは、ジムでの体験をフォークリフトで拡張するようなもん。
自分でやってるから楽しいんだ。
「この言語の動くコンパイラ作って」って言えたら、もう楽しくなくなるだろうね、だってそこから何も得てないから。
もちろん、辞書が必要な度にイチから実装し直したりはしないよ、それは「標準ライブラリ」の一部だから。
でも、もしそうじゃないとしたら、別の方法を考えるか、自分で再実装するかっていうチャレンジも楽しみの一つなんだ。
私はコードを書くのが好きだし、何時間もかけて作ろうと思ってたパーサーをLLMが一発で作っちゃうと、正直ちょっと満足感は減るんだよね。
でも同時に、何時間もパーサー作るのは、そのプロジェクトで本当にやりたい高次の目標からすると、寄り道でもあるんだ。
LLMのおかげで、そっちに集中できるようになった。
型とか関数のシグネチャだけ自分で書いて、詳細はLLMに埋めてもらうこともできるし、実装してみて「もう楽しくないな」ってなったらLLMにパスすることもできる。
逆に、LLMは何かを磨き上げる楽しさに集中させてくれるようになったね。
「いいんだけど、正直面倒だからいいや」って思ってたような大胆な変更も、もう面倒じゃない。
例からテストを大量に生成するのも苦じゃなくなったし、READMEとコードを同期させるのも嫌じゃなくなった。
リファクタリングとか改善のアイデア出しも簡単、AIに聞いて根拠を示してもらえばいい。
おかげで、前よりずっと野心的なプロジェクトに取り組めるようになったし、週末プロジェクトも全然違うレベルに持っていけるようになった、それが楽しいんだ。
マインドセットをちょっと変えれば、これはまさにソフトウェア好きのビルダーにとっての楽園だよ。
もっと多くのコードを磨いて、もっと多くのプロジェクトを公開して、もっと難しい問題に挑戦して、もっと高い目標を目指せるようになる。
でも、多少の反感みたいなものを乗り越えるのには、ちょっと時間がかかったな。
パーシングは私が興味ある分野なんだ。
LLMにパーサーを「一発で」作らせた経験について、もっと詳しく話してくれる？
ゼロからだと、LLMはパーサー書くのに全然ダメみたいなんだよね。
最先端でも、XMLくらいは何とかできても、ちょっと複雑なプログラミング言語（C言語とか、マクロ抜いてもダメだったり、詳細を自分で埋めろってスタブだけ返してきたり）にはお手上げ状態に見えるよ。
パーシングライブラリを使えばマシみたいだけど、結局それはBNFを変換するだけでしょ？
それならLLMなしでも確定的にできるじゃん。
あと、私の「成功例」も、GitHubに何十何百って具体例があるような、よく定義された言語の場合だけだった。
架空の言語の例を渡してみても、結局一般的には動かないようなRegexの塊を返してくるだけなんだ。
数週間前、Cursorに入ってるLLM（Gemini 2.5かなんか）に、新しい言語の例をたくさん渡して、Rubyで再帰下降パーサーを書いてもらったんだ。
その言語は別に変なものじゃなくて、CとかJSっぽいスタイルを意識的に取り入れたけど、定義としては新しいやつだった。
パーサー生成器を使いたくなかったのは、（a）Ruby用の新しいのを覚えるのが面倒だったのと、（b）手書きの再帰下降パーサーの方が、役に立つエラーメッセージを出しやすいと思ったから。
たしか、こんな流れだったと思うよ。
まず、例に基づいてBNFを書いてもらって、それを自分の意図に合わせて少し調整した。
次に、レキサーを書いてもらって、レキサーのテストをたくさん作ってもらった。
それから、レキサーを、名前付きキャプチャ付きの大きなRegexを使うように書き直してもらった。
そして、パーサーを書くように指示したんだ。
パーサー関数でスタイルを統一（先読みの仕方とか、バックトラッキングのやり方）するようにって言って、書き直してもらった。
パーサーのテストをたくさん書くように言って、それを読みやすいように自分で調整したりリファクタリングしたりした（LLMには面倒な作業をやらせた）。
この過程で、テストが失敗したのを見て、LLMは自分のバグのほとんどを自分で修正してたよ。
このプロセス全体を通して、私は常に各ステップを監視して、たまに出てくるアホな間違いや間違った方向への脱線を修正しなきゃいけなかったけど、まるで電動工具を使ってるみたいだったね。
ただ、それを正しい方向に向けて、自分のやりたいことをやらせる必要があるって感じ。
最終的な結果は全然問題なく動いたし、コードもかなり読みやすくて保守しやすい。
それ以来、そのコードベースで開発を続けてるよ。
LLMなしだったら、1週間はかかったであろう作業が、たった1日で終わったんだ。
それに、例から始められるパーサー生成器なんて、私は知らないな。
詳しいワークフローを教えてくれてありがとう。
ああいう具体的な話があると、こういう議論ではすごく助かるね。
でも、面白いのは、元の投稿ではLLMがパーサーを「一発で」生成するって言ってたのに、今回の説明はもっとずっと掘り下げたプロセスだったことだね。
「例から始まるパーサー生成器なんてない[…]」
人間（People）だよ。人間なら、例から始めてパーサーを生成できる。
これもまた、元の「パーサー一発生成」っていうコメントに、より近いんじゃないかな。
もしLLMがパーサー生成のプロセスの一部として役に立つって人がいるなら、それは良かったと思うよ。（私にとってはパーサーのテストって結構苦痛だから、テストケース生成には興味あるし）。
だけど、私がもっと興味があるのは、「一発生成」が存在するのかしないのか、そのことなんだ。
正直に言ってよ。
毎週一回、引数パーサーを手書きするとか、設定ファイルから入力を抜き出すとか、ロガーを設定するとか、そういうの楽しいの？
評価には同意できないな。
今のところ、LLMが引き継いでくれてるのは、実装みたいな定型的な雑用ばっかりだよ。
自分が楽しいと思ってる部分、つまりプロジェクトの設計とか、LLMにはまだ難しい非定型的な部分は自分でやってる。
これが一年後には変わって、私がちょっと高尚なプロダクトマネージャーみたいになるかもしれないけど、今はこれで満足。
本当の思考を要する問題に集中できて、雑用や繰り返しのパターンを持ち上げるのを手伝ってもらってる感じ。
話が噛み合ってないね。
Advent of Codeの問題を解いた後、それが一般的じゃないと感じたから、もっと一般的なバージョンも解いたんだ。
プログラミングが好きすぎて、架空の宿題をやって、自分で追加課題まで出してやってしまうくらいだ。
ポイントは、新しい問題を解くのは面白いってこと。
どう解くかもう完全に分かってる問題を解くのは面白くないし、知的な訓練でもないんだ。
std::mapを使う代わりに、必要になるたびに新しいハッシュテーブルをゼロから書くのは、得るものがほぼゼロだろう。
問題解決は確かに筋肉だし、使わないと衰えるけど、同じ問題を繰り返し解いて問題解決能力を鍛えるわけじゃないんだ。
LLMに同じ繰り返しの実装ばかり生成させるなら、もう基本的なプロジェクトを事前にセットアップしておいて、必要に応じて修正する方が良くない？
＞どう解くかもう完全に分かってる問題を解くのは面白くないし、知的な訓練でもないんだ。
私の仕事のプログラミングタスクは、たいていそういうのじゃないんだよね。
仕事の大部分は、既存のコードや技術的、ドメイン的な制約の中で、「正確に何をやる必要があるのか」を考え出すこと、そしてそれを反復することだ。
つまり、この知的な作業は既存のコードや、言語、ライブラリ、ツールの制約から切り離されてない。
だから、知的な課題の重要な部分は、実際にコードを開発したり統合したりすることと密接に結びついてる。
君はそういうのを面白くないと思うかもしれないけど、それは「既にどう解くか完全に知ってる問題」じゃないんだ。
むしろ、解決策は発見と探求のプロセスの結果なんだよ。
「ワンショット」のパーサー生成って目標がよく分からないな。
人間だってパーサー生成器を使っても、試行錯誤のプロセスがあるじゃない！
言語を定義しても、思った通りの言語になってないことに気づく、っていう反復プロセスがいつも存在するんだ。
誰かや何かにテストを書いてもらうと、自分の頭の中のハッピーパス以外の文法ケースも試してくれるから、その問題の助けになるね。
＞なぜ人はジムに行くのが楽しいのか？
楽しい？
大多数の人は、もし会費が二倍でも、行かなくて済むなら成果が半分でも喜んでそっちを選ぶだろうと思ってたけどね。
最近似たようなことやったけど、ちょっと違う。
ClaudeにRustっぽい言語のコード例をいくつかあげたら、再帰下降パーサーを書いてくれたんだ。
それはワンショットだったけど、すごくシンプルな言語だからね。
もっと機能を追加した後、そのBNFが欲しくなったから、後からパーサーの実装から正確に全部書き出してくれたよ。
こういう種類のものは、時間をかけてライブラリにすることが多いね。
使い方に関わらず同じ詳細を処理してくれるようにするんだ。
そういうライブラリを設計するのは、仕事の面白くてやりがいのある部分の一つだよ。
複雑な引数解析は、たいていPythonでやるんだけど、それならargparseライブラリが処理してくれるしね。
もし他の言語でやるなら、ライブラリがあるかGoogleで探すか、なければ一度書いて他のプロジェクトで使い回すかな。
ロガーも同じ。
設定ファイルからどう入力を抽出するか、どんな設定ファイルかにもよるけどね。
プログラミングで一番好きなことの一つは、慣れてないファイル形式を解析すること、特にホワイトボックスの状況だ。
ドキュメントを見ずにNASAファイルをいくつかやったけど、最高に楽しかった。
でも、doom WADファイルとか、Shapefile、SVGなんかはドキュメント使う必要があったけどね。
仕事でそういう種類の作業をもっと増やしてほしいって頼んだくらい、それが大好きなんだ。
