LLMで数ヶ月コーディングしてみた 結局自分の脳でコードを書くことにした
引用元：https://news.ycombinator.com/item?id=44003700
LLMを”all-in”で使うって考え、よくわかんないんだよね。俺は本職はiOS devで、今まで通りやってるよ。違うのは、デザインに基づいて一度きりのviewをサッと作るのにLLMを使うこと。これはアプリのコア機能とか重要なものじゃなくて、新機能の宣伝とかwidgetのインストール方法とか、そういうちょっとしたもの。これ、いつもなら複雑さによるけど30～60分かかってたんだけど、今じゃ5分で済むんだよね。web開発みたいに嫌いなこともLLMにやらせてる。多分これはLLMの学習データの9割がweb関連なんだろうね。そういうのは変更も大きいけど、手動で見直してからgitにコミットする。他のプロジェクトと同じだよ。何時間も完全に道から外れて大きな問題にぶつかって、またゼロからやり直す人がいるなんて信じられないね。もっと段階的なアプローチで、常に前に進み続ければいいのにさ。
いろんなツールの有用性は、使う人や問題によるかな。二人の架空の開発者で、CursorみたいなIDEが役に立つか考えてみようか。もし君が
＊10年のpython dev
＊すごく大きくて複雑なpythonコードベースをほぼ一人でやってる
＊何年もかけてpycharm IDEをそのコードベースに完璧に合わせてる
＊バグをほとんど許容できない（安定した製品で、速く動いて壊す余地なし）
なら、LLMは君を10倍にはしないだろうね。CursorみたいなIDEは、使い方を覚えるまで長いこと君を遅くする可能性が高い。もし君が
＊1年のJS（react、nextjsとか）dev
＊新しいアイデアはだいたいゼロから始める
＊特にIDEのこだわりがない
＊バグをかなり許容できるし、とにかくリリースして試したい
なら、LLMは君を10倍にするだろうね。CursorみたいなIDEは、すぐに君をめちゃくちゃ速くするだろう。
LLMに対するこういう全か無かの意見、もううんざりだよ。言いたいことはわかるよ、LLMは経験の浅い開発者にとって力を増幅させるものになりうるって。でも、大雑把な一般化は当てはまらないね。バグをもっと許容したり、ゆるいルールで大丈夫なら、確かにLLMは魔法みたいに感じるかも。でも、それが経験豊富な開発者にとって価値が低いってことじゃないんだ。俺はPythonとJavaを15年以上仕事で書いてるよ。JetBrains IDEを使い倒してきたし、VS Codeに切り替えるのに何日もかかった。ゴリゴリにカスタマイズしたVimから来たら、もっと大変だろうね。俺は不安定な出力は許容できないし、ゼロから作るシステムも、昔からのシステムも両方やってる。確かにゼロからの方がLLM向きだけど、成熟したコードベースを見て拡張する時も、LLMから十分価値を得てるよ。何がイライラするかって、こういう議論が二極化してること。両方に妥当な見方があるのに、多くの投稿が自分の意見を唯一の真実みたいに言うんだ。現実はずっと微妙だよ。LLMはツールであって、革命じゃない。そしてその価値は、経験レベルに関係なく、どうワークフローに取り入れるかによるんだ。
16年のpython devで、そういうの全部やって、複数のプロジェクトを立ち上げから成功まで導いてきたけど、最近は手動でコード書くことほとんどないんだよね。俺は自分が何が欲しいか、どうやって作るか（これが重要！）を正確に指示して、いくつかのファイルを雛形として作って、ディレクトリをいくつか用意したら、agentに自由にやらせるんだけど、静的解析ツールとかテストスイートを各イテレーションの後に実行するように設定して、間違いを直させてから次に進ませるんだ。ゼロから作るプロジェクトなら、1日で5k行のコードを簡単に出せるし、頑張れば10k行もいけるよ。定型的なコードが多ければね。何千行もある巨大なPRのコードレビューも、俺が長年のキャリアで一緒に働いてきたほとんどのエンジニアがやるより、数分でずっと良いレビューができる。リストはどんどん続くよ。手動でコード書くのは、LLMが理解してない小さな問題で、agentをもう一回実行させるより自分で編集した方が速い時だけ。でも、それはそんなに多くないんだ。LLMは誰にとっても力を増幅させるツールだよ。本当にベテランの開発者も、現在のツールを使いこなすのと同じくらい、LLMの使い方を学ぶ必要があるだけなんだ。それは、達人アーチャーがライフルの使い方を知らないからって、弓が銃と同じくらい良いって言うみたいなものだよ。
同意だけど、1年のJS devは、長期的に自分のスキルを構築する上で「悪魔と契約してる」って知っておくべきだね。
俺のスタンスは、全か無かとは逆なんだよね。さっきのコメントは一例だよ。CURSORから specifically どれだけ価値を得られるかは、人＆問題によって変わるだろうね。俺の例に出したPython devは、ChatGPTのo3からすぐに価値を得られるかもしれないしね。全か無かじゃないんだよ。何からすぐに価値を得られるかは、状況によって変わるんだ。
〉同意だよ。真面目な話。LLMはツールだね。時々、素晴らしく機能する。時々、そうでもない。でも、俺は間違いなく価値を見つけたよ。俺も15年以上開発してるんだ。
「雰囲気でコーディング」してるわけじゃないし、CursorとかAIベースのIDEも使ってないよ。単にClaudeとCopilotを使ってるだけ。統合されてるからね。でも、価値は間違いなく見出してるんだ。
あなたのスタンスが全か無かではないって言ってるけど、最初のコメントはかなり線引きしてたよね。経験の浅いdevでゼロから始めてバグ耐性が高い人は生産性10倍になるけど、高い基準を持ってて環境が整ってる経験者はおそらく遅くなるだろう、って。そういう枠組みこそ、こういう会話を非生産的にしてるバイナリ思考そのものだよ。
〉同意だよ。真面目な話。LLMはツールだね。時々、素晴らしく機能する。時々、そうでもない。でも、俺は間違いなく価値を見つけたよ。俺も15年以上開発してるんだ。
うん、でも俺が理解できないのは、こういう緩い期待なんだよね。ソフトウェアの他のツールで、時々動いて時々動かないものを受け入れられるものって他に何がある？ 確かに全てのツールにはバグがあるけど、コンパイラがLLMと同じくらいエラー率が高くて使いにくかったら、絶対に使わないだろ。なのに、なぜかLLMにはこれほど低いハードルが設定されてるんだ。人々がこれらのツールのhype koolaid（誇大広告）にどれだけ夢中になってるか、俺には信じられないよ。
これはバイナリ思考とは分類しないかな。あなたが返信してるコメントは、単に境界条件を定義してるだけじゃないの？ だとすれば、その2点は空間全体を定義してるわけじゃないけど、そこでの出力から、その2点間の「関数」の性質について推測（証明はできないけどね）することは少なくともできるんじゃない？ 関数fが経験→生産性向上みたいなものだとしてさ。
元のコメント、2つの例出しただけって読めるけど、書き方で受け止め方が変わるんだよね。「LLMsは初心者向け、ベテランにはイマイチ」って誘導してる。意図してなくてもね。読者を誘導する特定の条件で線引いてる。AI議論のあるあるだね。
1日で1万行とか簡単らしいけど、そのGitHubプロジェクト見せてよ。
GitHubには公開してないけど、1日で5千行コード書いた時のcloc結果だよ（1万行は大変）。Pythonコードが5001行。テストケースも199個ある。
この「簡単」ってのは、3時間くらいでベース弾きながら書いたって意味ね。
いや、あれはたくさんの状況のうちのたった2つの例ね。意図的にすごく具体的な例にしたのは、分かりやすくするためだったんだけど。あんまり伝わらなかったみたいだね。
俺はExpertSexchange, Google, SourceForge, StackOverflow + GitHubでプログラミング覚えた。当時、検索ばっかして自分で考えないのはダメだって言われたけど、15年経って周りの同僚より劣ってるとは思わないね。今は適切な検索ができるのが、マニュアル読むのと同じくらい大事なんじゃないかな。
もしみんながLLM使ってコード書くようになったら、プログラミングって今のレベルで止まっちゃわない？LLMは既存のコードから学ぶけど、新しいコードが生まれなくなったら、次のLLMも古いコードでしか学べない。LLM頼りきりって、開発を永遠にフリーズさせるってことだよ。
まあ、そうだろうね。でも、明確に線引した記事が厳密な意味じゃないってコメントで説明しなきゃいけないなら、例の出し方が悪かったのかも。”IF this THEN that”を2点のグラフで線形だと思うなって言われてもね。大筋は合ってると思うけど、伝え方が微妙だった。ジュニア開発者の方がLLMの価値を引き出しやすいってのは同意だよ。
Google’s AlphaEvolveとか見るとさ、人間が見つけたより速いアルゴリズムをもうLLM’sに書かせてるみたいだよ。[1][1]https://deepmind.google/discover/blog/alphaevolve-a-gemini-p…
それはまだ結論出てないかな。ワークフローに入ってて、大量のサンプルコードからやり方を見せてくれるツール（LLM）は、ジュニア開発者がコード作るだけじゃなく、学ぶ上でもすごく役立つと思うよ。
いい感じに整形するともっと分かりやすいかもね．
github．com／AlDanial／cloc v 2．04 T＝0．05 s （666．3 files／s， 187924．3 lines／s）
—- Language files blank comment code
—- Python 24 1505 1968 5001
—- Markdown 4 37 0 121
—- Jinja Template 3 17 2 92
————- SUM： 31 1559 1970 5214
アルゴリズムの話じゃなくてさ，新しいWebフレームワークみたいに学習データがないものはLLMには使えないでしょ？ CoPilotにフレームワーク作らせて，別のLLMに使わせるとかできるの？そういう問題提起だよ．
俺はいろんな開発やってるけど，iOSとかWebとかね．あんたも言ってたけどLLMの精度って分野で全然違うよね．iOSだとコンパイルしないコードや存在しないAPIを言われたり，Swift 6でハマったり．でもnextjsアプリは一発で作れたんだ．結局，学習データ次第なんだよなあ．
＞ 「期待が緩すぎる」って言うけど分かんないな．Typescriptエラーみたいに，LLMに聞けば何が起きてるか分かりやすくなるじゃん．完璧じゃなくても役に立つんだよ．90%動けば0%よりずっとマシ．広告なしで情報まとめてくれるGoogle検索みたいなもんだよ．これで役に立たないならもう何も言えないね．
みんなここでLLMを擁護しすぎだろ，まさに核心突いてるのに．LLMが100％確信持って嘘（バグ）ついてくる時代で，雰囲気でコード書いてる奴らが品質分かんないコードを自信満々に出荷する時代，コーディングの基準は下がったんだよ．経験ある奴はLLMのコードに何かを足せるから価値は変わらないけど，経験ない奴はAIの間違いに気づきもしないって話．
何かを学ぶ時と同じで，LLMを使うかどうって個人のモチベーションに大きく依存すると思うな．カネ払ってCSの学位取ってる大学生を見てるとさ，多くのジュニア開発者は学ぶことより成果出すことの方に力入れるだろうなって思うよ．
LLMの使い方についてね。
copilotモードは学習いらずで速度アップできるかも、特に繰り返しの作業では10倍以上いけるかもね。
cmdkモードはプロンプトが必要で、chatの劣化版みたい。コメント入れてcopilotモード発動させる方が、そこに至るまでの過程も残るから良いと思う。
agentic editing chatは、君が言う時間泥棒だと思うけど、学ぶことなんてある？大量のコードを吐き出すこともあるし、役に立つこともあるけど、できないこともしばしば。
君の言ってるケース、特に基本的なとこを超えると、違いはないよ。学ぶべきことは、全てのコードを読んで、技術的な詳細で何をしたいか決めて、agentic chatに聞くってことだけ。それ以外は基本的なことしかできないし、「使い方を学ぶ」ってのは結局それ。5分でそれが分からなかったなら、「fine tuned pycharm ide」なんて使ったことないね、きっと。
LLMは、取り込んだコードを君のケースに合わせてカスタマイズするツール、もしできればね。それだけ。一度も見たことないケースなら、何を「学んで使う」としても解決しないよ。俺はそれを公言しても構わないね。俺たちはLLMをかなり使ってるけど、今んとこのモデルじゃ、正確なコードを打ち込む以外では絶対に直せないすごくシンプルなケースを見せてあげられる。自信満々に無意味な変更するだけだよ。
多くのLLM過激派が気づいてないのは、ほとんどの人にとってボトルネックはコード生成じゃなくて、コード理解だってことだよ。
何かを作る速度が倍になっても、コードレビューやテスト、頭の中にコードベースの精神モデルを構築するのに、その倍以上の時間を払わなきゃいけないんだ。
そして、コードを保守（バグ修正、リファクタリングとか）したいなら、それは絶対やらなきゃいけないことなんだよね。
全く同意だよ！コード読むのは書くより難しいし、俺も書くより読む・理解しようとする時間の方が長いと思う。
でもこの前LinkedInで会ったCEOは？「すでに生産性を上げて喜びを増やす可能性を持っている。そのためにはソフトウェアエンジニアリングとは何かを見る必要がある。それは見た目より難しいかもしれない、なぜならその機会は何十年も目の前に隠されていたからだ。それは意思決定の仕方を見直し、コンテキストツールを作成・雇用することでコードを読む必要性を排除することから始まる。」だってさ。
AIがもたらすコンテキストって、SWEチームが維持しなきゃいけない新たな複雑さの層そのものだよ。
もう、めっちゃ混乱してる。
洗練された自動コードエディターをやたら褒めてる人たちに対して、同じように思ったこと、よくあるよ。
LLMって、自分のコードを説明してもらうのに結構使えるって見つけたよ。
もっとコメントを表示（1）
それは違うよ。一番単純な関数にしか通用しないね。どうやってそんなプロンプト作るの？「このコード説明して？」って？結局、元のコードと同じ本質的な複雑さがJavaScriptじゃなくて英語で返ってくるだけで、周りの理解はやっぱり必要だよ。しばしば、いろんな角度から理解する必要がある。前提条件A、B、Cを与えたらどうなる？って、その質問何回聞くの？
それに、これどんだけ遅いか考えてみてよ。コードの一部を読むか、すでに頭の中にある精神モデルを即座にクエリする代わりに、プロンプトをタイプして、応答を待って、応答を読んで、意図を理解してくれたか願って、コードを理解してくれたか願って、自分の理解にマッピングする。
これは本当じゃないね。
悪い習慣かもしれないけど、ほとんどの平均的な開発者は、使ってる依存関係の内部構造なんて全く気にしないって考えてみてよ。
彼らが気にするのはインターフェースと、それが動くかどうかだけ。普通、実装には関心がないんだ。
LLMが生成したコードって、ランダムなnpmパッケージやrust crateを引っ張ってくるのとそんなに変わらないよ。欠点があるのはみんな分かってるけど、そのやり方がすごく人気な理由があるんだ。
「LLMが生成したコードって、ランダムなnpmパッケージやrust crateを引っ張ってくるのとそんなに変わらない」
だから、君が本当にランダムにパッケージを引っ張ってきてないことを心から願うよ。それセキュリティリスクみたいだね。
それに、良いパッケージって、それをメンテする人のチームがいる傾向があるんだ。それとどう同じだって言うの？
他の人への返信だよ．「＞ランダムなパッケージ使うな，セキュリティやばいじゃん」→「うん，そうなんだけど，それはちょっと違うかな」．「＞良いパッケージにはメンテチームがいるでしょ？ それと一緒？」→「有名なやつでもメンテされてないこと多いって． xkcd.com/2347/ 見てよ」．
もし開発者なら，そんな言い方は自分に不利になるよ．
人気のパッケージは何千人もが使ってチェックしてるから，バグが見つかって直される．LLMコードのコピペはその逆．まともなコード出すこともあるけど，それと同じくらい見た目だけっぽくて間違ってる可能性もあるんだから．
他の人への返信．「＞実装気にしないことが多い」→「［要出典］」．「＞LLMコードはランダムな npm パッケージや rust crate と同じ」→「ランダムじゃないって．”良い”パッケージ選ぶ方法があって，LLMコード全行レビューよりずっと簡単でしょ」．
さらに返信．「makeとかautotoolsとか皆クソって言うけど動くから使う，実装なんてどうでも良いんだよ．」「LLMコードも依存パッケージみたいに全部見なくていい．動けばOKじゃん？誰が書いたか重要？」
人間が書いたコードは意図を信頼できるから，テストしてない部分も大丈夫って類推できる．LLMは統計モデルのデタラメで意図がない．動いてもテスト外は信用できない．前提が正しいか，ちゃんとレビューしないとダメ．
全部積み重なる．良い設計ならメンテ楽．悪いコードだと開発遅くなるし，バグチケットが何千件も来るよ．
他の人への返信．「＞LLMコードはランダムな npm パッケージや rust crate と同じ」→「そうそう，しかもランダムよりずっとひどい．だってコンパイルすらしないことザラだよ」．
開発者なのに，ユーザーが気にしないようなことばっか気にしてるなら，もっと良いツールを探した方がいいんじゃないの．
コードレビューで微妙な・ヤバいバグが山ほど出てきて， Cursor で得た効率は全部水の泡になった．結局 VSCode に戻って， copilot は具体的な指示の時だけ使ってる． Cursor のタブ補完，最初は魔法みたいだったけどすぐ飽きたな．
Cursorのタブ補完、最初は魔法みたいだったけど、自分には飽きちゃったな。同僚を見てて一番好きなのは、Cursorが彼がまさに消したばかりのコードをタブ補完しようとして、時々反射的にそれをやっちゃうとこだね。
LLMエージェントにどんな制約を与えたの？ 例えばSOLIDに従うとか、Lint、コードカバレッジ100％、テンプレート、実装前の設計ドキュメント、アーキテクチャルール、DRYなクリーンアップ、コードレビューガイドライン（一貫性に関する厳格なルール含む）、別のLLMによるレビューとか、具体的に知りたいな？
記事主じゃないけど、僕の経験だとLLMはまだ制約かけるのが難しいね。うまくいくのは25～50％くらいかな、しかもすっごくばらつくんだ。
LLM次第だよ。最近のGeminiモデルはこの点で結構良い感じ。
これマジわかるわー。LLMは今でもゴリゴリ使ってる。でもね、今はマイルールが２つあるんだ。深い思考が必要なとこは絶対任せない。難しい設計とかは自分でやる。生成コードは徹底的にレビューして修正。一行ずつガッツリ見る。そうしないと、コードが長かったり、過保護すぎたりするんだ。プロンプトでどうこうできるとか興味ない。将来メンテするのは自分だしね。「Vibe coding」って感じで、生成コードに無頓着なのはなんか嫌なんだ。今のやり方だと気分が良いし、何度も言うけど、それでもすごく使ってるし、前よりずっと速くコード書けてるよ。
俺はAIに深い分析全部任せるけど、それは詳細な計画を作るためだよ。具体的な手順とか検証基準とか、データ付きのレポートにまとめるんだ（「このjson作るスクリプトと、それを表示するスクリプト作って」みたいな）。計画には「移行済み合計100％」みたいに、はっきりした目標がある。もちろんエッジケース見落として修正は必要だけど、それはAI関係なく計画って普通そうじゃん。計画立てるのに1～2時間かかるけど、ADHDで単調な作業苦手な俺には丸一日かかるようなことなんだ。AIはテキトーにやらせてもそこそこできるけど、詳しい計画があった方が断然うまくいくね。それに、計画書指差して「そうしろ」って言えるの、めっちゃ気持ち良いんだ。
＞ 生成コードは一行ずつガッツリ見て徹底的に直す
これってさ、問題じゃない？ そこまでやるなら、時間節約になってるの？
（大抵は）うん、なってるよ。LLMは関数３つとか100行超えるコード一気に作れるけど、それを自分の好みに整えるのに15分くらいしかかかんない。自分でゼロから書いたら1～2時間はかかるかな。一番良いのは、まだ作ってない関数のテスト書いて、LLMに関数の形だけ渡して実装させるやり方。LLM時代のTDDはマジ最高！
言いたいことはわかるけど、時間節約になってるのはね、
・ロジックのアイデアとかもらえる
・定型コードはもう過去の話
ってとこかな。あと、直したいとこはLLMに直させちゃう。マジで下手なプログラマーに色々やらせる大変さは知ってるけど、LLMはそれより断然マシだから、結局は得なんだよね。
これは個人によると思うよ。俺の場合は、うん、時間節約できてる。でも、そうじゃない同僚もいるね。
記事に同意だね．最近はLLMで新しいこと学ぶか，共通API（特に boto3）のクライアントコード生成に使ってるよ．docker composeファイルの簡単な変更にWindsurf試したけど，それすらちゃんとできなくてちょっと萎えた．僕にとっては，devopsにはLLMはマジでゲームチェンジャーだね（API知識は前より全然重要じゃなくなった）．でも，まだChatGPTからコピペしてるけど，原始的だとしてもね．自分で考えるのをボットに丸投げするのは，長期的な意思決定で君より本当に優れてるんじゃない限り良くないと思うな．もし君がまだ意思決定者なら，インターフェースがどうあるべきか最終的に判断したいでしょ．オブジェクト指向のインターフェース（AWS連携とか）を慎重に定義して，LLMに実装詳細を埋めてもらうのは良い経験だったけど，それが”vibe coding”かって言うとちょっと違うかもね．
著者と同じような経験したよ．cursor ／ copilot は「賢い自動補完」とか「（小さな関数を）書く」とか，速攻プロトタイプには最高だってわかったんだ．でも，LLM主導のコードベースで1週間やったら，全部スパゲッティコードだって明らかになって，開発が完全に止まったね．この記事は現状を完璧に写してる．将来は改善するかもしれないけど，2025年5月時点ではこんな感じだよ．
著者の見方は限定的だね．LLMはエンジニアじゃなくツール．効果的に使えば生産性10倍以上だよ．僕のSaaS開発ではcursorが90％コード書いたけど，設計やアーキテクチャは僕がやった．LLMは速い実装ミニオンだよ．失敗は僕の伝え方のせい．高レベルな思考は自分でやって，実装を任せるんだ．指示の仕方と抽象度管理が重要だよ．ツールが問題じゃなく，ユーザーの使い方次第．もう手放せないね．
多くの会社がLLM使用を強制し，スキル退化を感じるよ．自分で考えず丸投げする麻薬みたい．生産性は上がらず，スプリント負荷だけ増えた．LLMへの熱狂はダメな開発者や非技術系トップに多い．セキュリティ懸念もあるね．今はハイプサイクルのピークで，コストやトランスフォーマーの限界から，今後はターボ補完レベルに落ち着くと思う．過去のWYSIWYGやNoCodeみたいに流行り廃れがあるかもね．
「数ヶ月でスキルが加速的に退化してるって感じた」→ これを避けるために，仕事で自分で「Copilot使わない金曜日」ってルール始めたよ．
cursorの使用は自動補完と短いスニペットに限定してる．それでも，自分のスキルが退化してるのを感じるね．「使わないと失う」って認知のルールだよ．
これ ［1］ は古いけど素晴らしい記事で，「自然言語プログラミングの愚かさについて」ってDijkstraのタイトルで，この議論に関連するね．主張は，プログラミング，数学などで使われる形式言語によって許される精度が，情報処理でこれまでの進歩を可能にした鍵だっていうこと．つまり，LLMでのVibe-codingは，うまくプロンプトできるシャーマンしか知らない「黒魔術」にコーディングを変えてしまうだろうね．［1］ https://www．cs．utexas．edu／～EWD／transcriptions／EWD06xx／EWD667．html
もっとコメントを表示（2）
わかるよ，著者と同じ問題見てる．おもちゃプロジェクトで90％LLM使ってる．結果は手書きの10倍速いけど，アーキテクチャは悪いし，なんか「エイリアン」っぽい．まだ続けてるんだ，LLM主導は避けられない方向だって確信してるから．より良いアーキテクチャのためにプロンプト工夫中．プロンプトエンジニアリングや設計ガイドライン明確化が鍵？ツールが10倍良くなったらどうなるか楽しみだね．
その「10倍良くなる」地点に着くことを願ってるよ．今の問題は，人々がLLMをまるで既にそこにあるかのように宣伝してることだと思うんだ．そしてそれはプロバイダーだけじゃなくて，XとかRedditとかの熱狂的な人たちも含まれる．「単に使い方が悪いんだ」って思わされがちなのを君が言ってるみたいに，もしかしたらツールがまだそこまで良くないだけなのかもね．
まあ「単に使い方が悪いんだ」って，新しいテクノロジーにとっては完璧に合理的な考え方だよね．これがデフォルトじゃないかな？新しい強力なツールが出てくるとき，既存のプロセスにぎこちなくフィットすることがよくあるんだ．
一つのやり方はね、欲しいクラスやメソッドの定義だけ自分でして、実装はLLMにやらせることだよ。
LLMはタイピングが速いジュニアエンジニアみたい。頼んでない機能も書くけど、生成コストが低いから捨てて書き直すのも簡単だよ。
自分で書くよりやり直しへの抵抗が減るんだ。
俺もこのやり方でめっちゃ価値を感じてるよ。
アーキテクチャの決定はLLMに一切任せないんだ。
高レベルな設計は自分で作って、LLMに穴埋めさせられるか見てみる感じ。
純粋関数書くのは得意だって分かったし、それを組み合わせて状態管理するのは俺が得意だよ。
まさにココなんだよね、グリーンフィールドプロジェクトのプロトタイピングには輝く場所だよ。
でもプロジェクトが本番に近づくにつれて、その10x効率ってのは失われちゃうんだ。
アーキテクチャは本当に意識しないとダメで、後からコアな設計問題を直すのは、10xを0.1xにしちゃうこともあるからね。
少なくとも今のところは、複雑なコードベースで使える唯一のパターンは、高度な音声認識みたいなもんかな、音声はないけどって感じ？
問題なのは、英語でフレーズにするのが冗長になりがちだから、音声がないと手でやった方が断然速いことが多いんだよね。
“ガードレールが必要だ、ドキュメントが…”って考えは分からないな。
目的は明確で、イテレーションでコードを洗練させていくんだ。
大規模な変更はスキャフォールディングかリファクタリングだけ。
Vim/Emacs使うのも編集を速くするためだよ。
コード生成やコピペ以外で数十行書くことは稀だね。
LLMを経験の浅いプログラマーとして扱い、コードレビューを必ずするんだ。
これにはコード理解維持、エラー発見、仕様修正、LLMのガイドライン調整のメリットがあるよ。
自分で全部やるより時間効率はいいかな。
タスクスイッチのコストを減らす手助けにもなるんだ。
>LLMsはコーディングまあまあだけど、規模が大きくなるとごちゃごちゃになる。
これ聞いてDreamweaverとかあの辺の時代を思い出したよ。
UIコンポーネントをドラッグ＆ドロップしたらスパゲッティHTMLになったんだ。
昔はロジックが決まってたけど、AIはハルシネーションするからね…
ビルダーとしての自分の責任をLLMに押し付けちゃだめだよ。
アーキテクチャ、整合性、品質に対しては、まだ君が責任者なんだ。
それは、もっとジュニアのエンジニアを雇った場合と同じことだよ。
筆者は知らない言語でLLMに任せきりにして失敗した経験から学ぶべき教訓を間違えてる気がするよ。
AIを最初のドラフトに使うのは良いけど、レビューは必須。
“Vibe coding”は使い捨てプロトタイプ向けで、コードを大事にするならそれはVibe codingじゃないんだ。
筆者はVibe codingではない失敗からVibe codingを批判してるんだよ。
それがvibe codingだよ。ツイートでは”使い捨てプロジェクトならそんなに悪くない”って言ってるけど、それは定義を限定してるわけじゃなくて、おすすめできる適用範囲を限定してるだけだよ。
Vibe codingってのは”コードのことなんか忘れてOK、使い捨てのやつなら大体動く”ってこと。それはこの人が求めてるものじゃないのは明らかだよ。vibe codingを手にしておいて、説明されてる通りに動いてるって文句言ったり、約束されてないものをくれないって言うのは違うと思うな。
全く異論ないね。LLMが彼がやろうとしてることをできるなんて、元々約束されてなかった。でも、彼が間違った使い方をしてるからって、彼がそれをやってないってことにはならないよ。
個人的には、元々書くつもりのなかったコードをLLMに書かせてるよ。例えば、Webのフロントエンド開発はマジで嫌いなんだ。Web開発者じゃないけど、たまに見た目のデモとかWebサイトを見せるのはいいんだよね。LLMがなかったら、時間もなかっただろうし、作る気にもならなかっただろうから、そういう意味ではプラスだよ。ブログ記事の著者と同じ理由で、メインの仕事ではLLMを使ってないけどね。
- 会社が開発の一部にAIを使う
2. その割合が増えてプログラマがレイオフされる
3. バグが出て、AIがほとんど処理するけど全部じゃない
4. バグの複雑さが増して、会社が修正のためにプログラマを雇う
5. プログラマはAIコードの mess を解読できない
6. プログラマが辞める
7. 会社が製品を維持できなくなる
＞ 恐怖が始まる
AI StudioでGemini Proを使うなら、コード生成じゃなく”議論したい”って指示するのがコツだよ。自分のコードについてコメントをもらったり、解決策を話し合ったりする感じ。ただ問題を解決しろって言うと、余計なコードをたくさん生成しちゃうからね。
良いアシスタントとして使うならこれがベスト。
うん、今の俺のアプローチは、Gemini Proで計画を立てて、たくさんやり取りしてから、それをMarkdownファイルに書かせるんだ。その後、Geminiか別のモデルにその計画通りにステップバイステップで実行させる。こうしないと結果は怪しくて、後でたくさんの修正が必要になることが多いんだよね。
スコープを絞っても、訓練データに少ないニッチで複雑な問題だとAIは苦手みたい。Gleamで再帰処理をGemini Proに頼んだら、幻覚だらけの600行以上のコードと不要な関数を返してきたよ。自分で書いたら26行で済んだ。どうやら俺より再帰が苦手らしいね。
＞現在のPHP+MySQLの組み合わせは、もはや目的に合わなかった。俺はここで彼を見失ったな。彼が理解してた退屈なスタックから、GoとClickhouseがクールだからっていう理由で変えようとしたみたいに聞こえるよ。それはトラブルを招くことになるだろうね。LLMは素晴らしいし良くなってるけど、現時点でこういうものを扱えるなんて期待できないよ。
彼が必要だったのはOLAP dbだよ、OLTPじゃなくて。俺には完璧に理にかなってると思うけどね…
