その時には、修正は簡単だろうね。最新のLLMを立ち上げて、自分のコードベースを指して「これをゼロから書き直して。ちゃんとやって。アーキテクチャのミスを直して」と言えばいい。

まず、ほとんどのソフトウェアはすでにごちゃごちゃしてる。次に、LLMが生成するコードは、人間が書いたコードよりもごちゃごちゃしないこともあるよ。ちゃんとトレーニングやプロンプト、検証、レビューをすればね。完璧でパターン化されたSOLIDでユニットテスト済みのコードを、警告やアンチパターンなしで生成するのは、今までで一番簡単だよ。

一般的に「LLM支援のコーディング」には賛成だけど、時々『デューン』のバトラー・ジハードのことを考えるよ。 https://en.wikipedia.org/wiki/Dune:_The_Butlerian_Jihad

アセンブリプログラマーから現代のJavaScriptの人たちへ、こんにちは。冗談はさておき、VS Codeがこんなに層になって書かれてるのを考えると、時々驚くよね。約200MBのミニファイドコード - JavaベースのIDEは、ほぼ1GBのコード（ライブラリや依存関係）でさらにひどかった。VS Codeはその時代のネイティブエディタ（Sublime）を打ち負かして今は支配してるけど、ビジネスモデル（オープン＆無料 vs フリーミアム）が影響してるかもね。でも、個人的にはかなりうまく機能してると思う。これによって、何十億ドルのスタートアップが市場に出てきたし、CursorやAntigravity、ほぼすべてのUIコーディングエージェントも含まれてる。バックエンド開発者（Java/C++系）が、まるで私たちが劣った惑星から来たかのようにJavaScript開発者を見下してたのを覚えてる人はどれくらいいるかな？VSCodeが実際にはネイティブフレーム内にラップされたブラウザだってことを覚えてる人はどれくらい？

30年後もまだコードを見たり、メンテナンスしたり、ちょっとでもコードについて心配しなきゃいけないなら、何かが深刻におかしいってことだよね。

何年も盲目的にこの方向に進んで、突然みんなで目を覚まして「何をしてしまったんだ」と気づくのは間違いだと思う。これは素晴らしいフィルターであり、素晴らしい機会でもある。もしLLMがここ数年のペースで改善を止めたら（もうすでに遅くなってると思うけど）、それでも数十億行のコードを生み出すことができるけど、自分たちではgrepもできないし、論理的に考えることもできないから、品質が落ちて、LLMに全力投球する企業は収益を失うことになる。でも現実的に考えよう。現代のLLMは、正しく使えばまだ素晴らしくて役立つツールだから、残るだろう。私たちの目標は、彼らを正しい方向に導いて、幻覚の悪影響を減らすことだよ。その結果、ソフトウェア業界は、何百万もの機能がある大規模で複雑な相互接続システムから、少数の機能が積極的に使われる小さく高品質なターゲットツールへと移行するだろう。なぜなら、その方が検証しやすく、副作用をコントロールしやすいから。

なんでみんなのコードが品質の基準みたいに振る舞ってるの？ほとんどのソフトウェアは、もうめちゃくちゃだと思うよ。考えもなしに、ましてや超考えなんて。

LLMがあってもなくても、誰も維持することはもう不可能だ。それがテクノロジーの神官たちの役割なんだ。

30年後、人間は気候管理されたベッドで目を覚まし、理想的な大規模な人間動物園で、何の情報が欲しいか考える。そして、彼の900TBのフェロエレクトリックコンピュートインメモリーエクソブレインが、脳-コンピュータインターフェースを通じて彼の思考を読み取り、その情報のカスタム3Dビジュアライゼーションを彼の前に浮かべる。コードの段階はなく、データをピクセルに神経的にレンダリングするだけだ。

Githubのバイブコーディングプロジェクトには慣れないな。ちょっと使ってたプロジェクトは約1年前のもので、40,000コミットと15,000PRがあった。名前に「lite」がついてて、シンプルな代替品のはずなのに、バグがめちゃくちゃ多かった。1つ直してPRを出したけど、数時間で1ページ目から消えちゃった。絶対にマージされないだろうな。もう少し「速度」が少ない別のプロジェクトに移ったら、すごくスムーズだったよ。

だいたいそんな感じだよね。投稿にも書いてあったけど、「リスクを取る前に、実績のある解決策が欲しい」ってのは真実で、そこが境界を見つける場所になるんだ。

LLMの良い使い方があるのは分かってるよ。でも、今の上からの熱狂的な要求は、自由に使わせようとしてるみたいで、それに逆らうのはすごく discouraging だし、キャリアにも悪影響が出ることが多いから、精神的に疲れちゃうんだよね。明らかな問題が指摘されてる中で、同じ数だけの回避策もあって、これらの回避策は後で新たな問題を引き起こすことが多いし、無限に続くんだよね。どこかの時点で、この作業が機械のためだけに行われているように感じることもある。確かにそうかもしれないね。今の多くの企業では、本当の目標がぼやけてしまって、残るのはLLMだけになってる。農場を賭けて、そういうビジョンを実現しようとしてる人たちは、結果から守ってくれる柔らかい出口が保証されてるのか、それとも本当に合理性が完全に捨てられてるのか？確かに、健全なエンジニアリング原則がこれらの問題を回避するのに役立つかもしれないけど、認知負荷、開発者の時間、お金、有限のリソースの観点で、実際にどれだけの効率が得られるの？それとも、そもそもそれが真剣な懸念だったの？

悪いエンジニアはずっと悪いままだし、良いエンジニアはずっと良いままだよね。個人的には、コードを書くのが早いからってだけで良いエンジニアになった同僚は知らないな。私が知ってる最高のエンジニアは、経験や慎重な考慮を活かして、チームに重要な洞察を共有してシステムの方向性を良くしてくれた人たちだよ。> クロード、システムを作ってくれ、でもちゃんとやってね。ありがとう！

バイブコーディングのアプリって、テストも不変条件もほとんどない状態で作られてるから、スパゲッティみたいになっちゃうのも無理ないよね。コードをリファクタリングすることはできるし、エージェントに小さくモジュール化されたパーツやファイルを書くように強制することもできる。エンジニアリングの良さは、人間が書いたコードでもエージェントが書いたコードでも変わらないから、エージェントにリファクタリングさせたり、選択肢を探らせる時間を持つことが大事だよ。人間は少なくともこの段階ではアーキテクチャを理解して運転する必要があるし、エージェントは素晴らしいリコンを行って提案をしてくれるからね。

そうそう、多くの人が「問題が起きたら直せばいいや」って考え方で成長してきたんだよね。以前は、コードベースが機能開発に抵抗し始めたら、すぐにボトルネックを修正して、次の抵抗ポイントまで先延ばしにしてた。機能を追加するたびにリファクタリングしてた感じ。フロンティアモデルは「問題が起きる瞬間」をさらに後ろに押しやってる。どんなコードの山でもある程度は扱えるみたいだけど、限界があるんだよね。だから、LLMが余計な回帰を引き起こしたり、以前よりも要求を減らしたりすることがあるけど、実際には仕事が難しくなってるわけじゃない。ただ、空のリポジトリから始めた時ほどスムーズじゃなくなってるだけ。で、最終的には壊れすぎて修正が必要になる。全体のコードベースは、自分が決めなかった決定のフラクタル層になってるから、解きほぐすのが難しいんだよね。そして、自分でコードを編集してないから、「この特定のものをこの特定の方法で追加するのはすごく緊張感がある」っていう反応がないから、リファクタリングの突破口を得るのが難しい。

同意だね。LOCは、歴史的に「生産的な」開発者を評価するために、私たちが経営陣と戦ってきた一つの要素だったよね！

LOCはここで役立つのは、出力の指標じゃなくて、_理解しやすさ_の指標だからだよ。200行をレビューするのと、2000行をレビューするのは全然違う作業量だよね。

そうかな？この記事のポイントは、コードを書く速度が人間がレビューできる速度を超えたってことだよ。ソフトウェアレビューのための入力としてLOCはすごく理にかなってる。だって、各行を実際に読む必要があるからね。

LOCはエンジニアリングの出力を測る最悪の指標だよ、他のすべてを除いてはね - チャーチル

どこかで、ソフトウェアエンジニアリングの成果を行数（LoC）で測るのは、航空宇宙工学を飛行機に追加されたポンドで測るのと同じだって読んだことがあって、確かにその通りだなと思った。

彼は行数（LOC）を指標として使ってるわけじゃなくて、典型的な行数の変化が与える影響について観察してるんだよ。

バイブコーディング（自分でコードを見ないやり方）を試してみたら、リファクタリングしても約1万行のコードができたんだ。でも、自分の頭を使ってChatGPTをグーグルとオートコンプリートとして使って同じプログラムを書き直したら、1500行でできたよ。努力の差はそんなに大きくなかったかな。ただ、手で書いた方がバイブコーディングの設計を考えたから、何を作りたいかはすでに考えてたからかもしれない。

人間って本当に多様で違うからね。関わってる人数（例えば、200万人がXに抗議した）を「恥ずかしい」として全ての統計を拒否するの？…だって、すごく多様な人たちを一緒くたにして、平等だって pretend してるから。

正直言って、今の時点では200行から10万行のかなり良い品質のコードって感じだね。

LoC（行数）はエンジニアリングの出力を測る指標としては全く問題ないけど、エンジニアリングの生産性を単独で測るにはひどい。そういう使い方をすると問題が起きるんだよね。それでも、これは直感的に理解しやすく、さまざまな文脈で比較可能な唯一の指標だから、まだ役立つ。つまり、企業やチーム、言語、アプリケーションを超えて比較できる。例えば、同じチームで同じ製品に取り組んでいる場合、1000行のLoCの差分が、数日かけてデバッグした1行のバグ修正よりも短い時間で済むこともある。だから、PRや製品機能、ストーリーポイントを文脈を超えて比較することはできない。もし業界が開発者の生産性を測る標準的な指標を考案できたら、みんなそれを使うだろうけど、実際にはこの理由で実現不可能なんだ。だから、そういう比較が行われるとき（この場合は明らかに口語的な使い方だったけど）、文脈が同じであることを前提にすると助けになる。例えば、企業Cの製品Pに取り組んでいるチームAが、技術スタックTを使って特定のソフトウェア品質プロセスQを経て、昨日N1行のコードを生産したけど、今日はAIを使ってN2行のコードを生産している。時間が経つにつれて、N1とN2の差が実際の影響を近似するんだ。（ちなみに、これはAI支援の開発者生産性に関する厳密な研究がほとんど行っていることでもある：AIの有無で同じコホートのPRを時間をかけて測定する、A/Bテストのようなもの。）

確かに、手動でコードを書くときはよくあったことだね。「動くもの」にすぐにたどり着けるけど、1) 他の選択肢を評価するのに時間がかかる（前か後かは別として）、2) それを洗練させるのに時間がかかる、3) テストして自信を持つまでに時間がかかる。君の言ってることは正しいと思うけど、どこに行くのかは誰も本当にはわからない。来年あたりはみんながそれを見つけようとする時期になるだろうね（これが「GitHubを再発明する必要がある」ってよく聞く理由でもある）。

人生全般の問題は、最後の5-10%がいつも一番難しいってことだよね。そして、多くの場合、その最後の部分を機械化しようとするのに投資するのは経済的に意味がない。最初からLLMプロバイダーは間違ったアプローチを選んだと思う。労働の補完に焦点を当てるべきだったのに、置き換えに向かってしまったんだ。彼らはその過程で高い授業料を払ったと思うよ。

なんか、何かを動かしてからリファクタリングでなんとかする傾向があるんだよね。それでもうまくいくし、コーディングエージェントを使えばできるけど、時間がかかるんだよね。最初からやり直した方が良かったかもだけど、最初はアーキテクチャがどうなるか全然分からなかったし。

たくさんのコードがコードベースにコミットされた後では、あなたが説明したようにはうまくいかないよ。LLMが既存のアーキテクチャで機能を作るのに苦労してるからって、全ての動作しているコードベースを吹き飛ばしてやり直すことはできない。

もしスライダーがバイブコーディングとエージェンティックエンジニアリングの間だけなら、人間がもっと関与するエンジニアリングの幅広い範囲を見逃してるよ。私は毎日OpusやGPT-5.5、他の少し劣るモデルを使ってるけど、彼らに全てのタスクを任せることはしてない。仕様を定義して洗練するためにかなりの努力をしても、彼らは人間のPRレビューでは通さないような愚かなことをたくさんやらかす。彼らの出力を信頼したり、大きなエージェンティックパイプラインを構築して安心感を得たりしてしまうと、すべてをコードベースに滑り込ませるのは簡単だろうね。10年後には状況が改善されているかもしれないけど、今の時点ではバイブコーディングとエージェンティックエンジニアリングのパイプラインは、LLMに完全に委ねるという同じテーマのバリエーションに過ぎないと思う。今朝、Opus on Maxにいくつかの変更を任せようと思って一つのファイルに取り組んでたんだけど、ほぼ毎回間違ったり、何かを見逃したりして、修正しなきゃいけなかった。彼が提案したコードはほとんど動くはずだったけど、複雑すぎて、すでに手で書いた明らかな簡略化を逆行してた。これが何千ものエージェンティックコミットに広がると、コードベースは本当にひどくなる。

同意だな。バイブコーディングは各段階での品質チェックがないけど、エージェント工学にはあるんだよね。開発チームは、設計やテスト、レビューの適切なプロセスなしで作ろうとすると、トラブルに巻き込まれる。これはエージェントコーディングが始まる前からそうだったけど、今は特にそうだと思う。このプロセスでエージェントをうまく活用できるチームが、一番成功するんじゃないかな。