より良い言葉は「拡張エンジニアリング」（AE）だと思う。特別な名前が必要だとは思わないよ。単にエンジニアリングだし。参考に本を使うときに「本支援エンジニアリング」なんて言わないでしょ。単なるエンジニアリングだよ。 > でも、雰囲気を楽しむっていうのは、あんまり関係ないかな。YOLOエンジニアリングって呼べばいいんじゃない？それか、機械にアウトソースした無責任なLMAOエンジニアリング。 > AEは「先進エンジニアリング」の略にもなるかもね。AIが最新のエンジニアリング知識にアクセスして理解する力を与えてくれるから、それを自分の仕事に活かせるんだ。ああ、もう。

何と呼ぶかについてあまり心配しなくてもいいと思うよ。特別なラベルを付けることで、AI支援のコーディングが一部の開発者だけのものだと仮定して、従来のエンジニアリングと区別されることになるから。いつかは、AIの助けなしにコードを書くのが珍しいアプローチになるだろうから、その過渡期には「雰囲気」を置き去りにすることになるよ。

「テストを書く」とか「計画する」みたいな面白いダンス。

ソースが一つか二つ必要？「鳩が面白いダンスをするのを見る」っていうソーシャルメディアのスパムのせいで、グーグルで調べられないトピックだよ。

アイデアのプロトタイピングにはすごく便利で、コストをかけすぎてコードに愛着が湧かないのがいいね。ゲームのチェンジログ用にインテリジェントな差分を生成することを試してたんだけど、どんな変更を強調するかのアプローチが見えなくて悩んでた。雰囲気コーディングの前は、実装を一つやってみて、かかった時間と出力を見て「まあ、これでいいか」と思ってたけど、雰囲気コーディングのおかげで、重い作業を自分で考えずに済んで、3つの異なるアプローチをプロトタイプできたんだ。それで、どの結果が他よりも魅力的かを感じ取ることができた。数分で動かせるようになったから、数時間かけるよりも、いくつかのアプローチを捨てるのも全然気にならなかったよ。

キャリアのソフトウェアエンジニアの中で、LLMを使ってコーディングの生産性が10%以上向上した人いる？ いや、同じ地点に到達するのにただ努力を減らしただけで、もっとはやってないよ。

もっと向上してると思う（40年以上コーディングしてるからね）。結構いい結果が出てるし、プロンプトをうまく作ることが大事だと感じてる。技術的に結果がどうあるべきかを知っていると、大きな違いが出るね。AIと議論したり、自分でやったりすることが少なくなってきてるし。小さな生産性向上や生活の質を上げるスクリプトをたくさん作らせてるし、それがいろんなことをスムーズにしてくれる。コーディングよりも「ソリューションエンジニアリング」に向かっている気がして、解決策について考える時間が増えて、いろんなアイデアを試す余裕ができてるんだ。

私の経験では、微妙に間違ったコードを生成することが多いんだよね。デバッグに時間を無駄にしちゃう。でも、人間が書いたコードの例を与えて、それを説明してもらうと、結構いい説明をしてくれる。あと、「今までやったことない複雑なタスクXYZを達成したいんだけど、どうすればいい？」みたいな質問にも、正しい方向に進むためのコードサンプルをくれる。自分のコードをデバッグする手助けもしてくれるし、見逃してたことを指摘してくれる。アイデアを出し合うのにいいペアプログラマーみたいだけど、無監督でコードを書かせるのはちょっと信頼できないかな。

人々がその「ブースト」を自己報告するのが得意だとは思わないな。もっと実証的な証拠が必要だよ。歴史的に見ても、そういう研究を行うのがすごく苦手で、通常はものすごく高額だし。お金を持ってる人たちはエンジニアリングに興味がないから、FUDや生産性のハイプを広めるために他の動機があることが多い。個人的には、これらのツールが今よりもっと進むとは思えないな。グリーンフィールドプロジェクト以外のものには対応できず、常に望ましくない結果を出しちゃう。人々がどんな魔法の呪文やエージェントの組み合わせを設定しているのかはわからないけど、それを「エンジニアリング」と呼ぶなら、最近ではその言葉に意味があるのか疑問だよ。いつかこれらのツールがそこにたどり着くかもしれないけど、期待しすぎない方がいいよ。

自分が得意なことに関しては？10%もいかないね。苦手なことに関しては？多分1000%以上。ウェブアプリを作ったり、シェーダーコードを書いたり、Unreal EngineからブラウザへのRTCストリーミングを設定したりするのに使ったけど、正直言って、そうじゃなかったらやってなかったと思う。あまりエネルギーも興味もないから、そういう特定のプロジェクトが時間の良い使い方だったとは思えないんだ。

いろいろ面倒なことを結構うまくやってくれるんだよね。ガードレールがあまりないけど。生産性はちょっと上がるけど、やらなくて済むのはいいよね。例えば、ドキュメントコメントとか。今日、自分が書いたクラスのドキュメントコメントを生成させたんだけど、全部修正しなきゃいけなかった。なんか変なことしてたから。でも、基本的な部分はちゃんと整えてくれたから、かなり早く終わったよ。あと、最近PythonのクラスからJSONスキーマを生成するのにも使ったんだ。入力がしっかり構造化されてたから、出力もちゃんとしたものが得られた。やりたくなかった面倒な作業を片付けてくれたし（スキーマ自体は面倒じゃないけど、今回はそうだった）。でも、まだこのコストを正当化する使い道は見つけてないし、著作権侵害や環境へのダメージも気になるところだね。

現時点で言うと、使っている部分では1000%生産性が上がってるよ。壁にぶつかることはほとんどないし、もしぶつかっても、いつも不明確な考えの進行やプロンプトの不明瞭さが原因なんだ。

結局、LLMはただ俺にもっと働かせるだけだよ。単に働く時間が増えるだけで%の向上について話すのは難しい。速いエンジンの車を持ってるのと同じだよ。大したことじゃない。俺が欲しいのは、小さいエンジンの速い車なんだ。理想は、仕事が終わったら家に帰って、働かないこと。日常の仕事で使いたくないのは、脳が退化するのが怖いから。何かがすでにやってくれると、あまり考えなくて済むし。LLMの出力をつなげるだけの人にはなりたくない。今飛びつかなくても何かを逃す気はしないけど、何かを失う気はする。

+1

スロップコーディングはどう？

クランカーコーディング ™

自分は、指示なしで何かをやってほしいときのために、クラウドスラッシュコマンド /yolo を作ったんだ。だから同意するよ :)

反対だな。バイブコーダーはノーコードと同義になって、ちょっとネガティブな意味合いを持ち続けるべきだと思う。バイブエンジニアって言葉は好きじゃないけど、違いを示すための言葉は必要だと思う。将来的には、開発者やエンジニアと呼ばれるだけでコーディングエージェントを使ってるってことが暗黙の了解になって、手作業でやる人は普通じゃなくなるかもしれないね。

$enterpriseでは、「責任あるバイブコーディング」と「YOLOバイブコーディング」を区別するための適切な用語を探してたんだ。最終的に「エージェント支援コーディング」に落ち着いたよ。ちょっと技術的な感じがするし、三文字の略語もある。三文字の略語は必要だよね。

今やすべてのAI支援コーディングを意味するようにセマンティックにシフトしたんだ。初耳だわ。AI支援コーディングって、もっとオートコンプリート的なものか、ひどいドキュメントを理解しようとすることだよね。「バイブコーディング」っていろんな意味があるけど。 - その人はLLMが書いたものを理解するスキルがない。 - 作成されたコードは将来の問題を探るためにレビューされていない。 - 最初から技術的負債がある。 - 法的にアプリケーションがヤバい。俺にとって「バイブコーディング」の致命的な欠点は、LLMが作ったものは保護や著作権ができないことだ。イギリスには少し保護を提供する法律があるかもしれないけど、EUやUSではほぼ詰んでる。

心配しないで、たぶんそれはインポスター症候群だよ。君の開発スキルはまだまだ通用するから。エージェントを君のコーディングタスクを手伝うジュニアデベロッパーだと思って、常にメンターして、レビューして、修正してあげる必要があるんだ。

100%同意。若い人たちがどう感じてるか想像してみて。まだ色々試行錯誤してるのに、親や先生も同じくらい無知で、期待だけは無限に高い。「君はまあまあだけど、チャットGPTの方がまだ上だよ。もっと頑張って。」

だから、営業とか全然違うことに移りたい気持ちになる ああ、それがスタートアップ創業者の生活だね :) 激しいマルチタスク、エンジニアリングの質を下げる必要があって、作ってるものが本当に売れるかどうかわからないからスケールの問題を無視する。1ヶ月後にやり直すことがわかっているものをエンジニアリングするのと、5年以上持たせるつもりのものをエンジニアリングするのは全然違うけど、正しいトレードオフを選んで、異なる制約の中で働くのは楽しい挑戦だよ。

それを聞いて残念だよ。ここでの目標の一部は、「プログラミングスキルは今や無駄、誰でもLLMを使ってコードを書ける」という考えに対抗することなんだ。既存のソフトウェア開発スキルは、コーディングエージェントが加わることで、もっと価値が高まると思うよ。これまで学んできたことを活かして、新しいツール群での影響力を加速できるんだ。投稿でも言ったけど、> AIツールは既存の専門知識を増幅させる。ソフトウェアエンジニアとしてのスキルや経験が多ければ多いほど、LLMやコーディングエージェントと一緒に作業したときの結果が早くて良くなるんだ。新しいコーダーがChatGPTを使ってクールなUIを作ることはできるかもしれないけど、Kubernetesクラスターに自動テストをセットアップすることはできないだろうし、設計した大きなプロジェクトの異なるエリアで3つのエージェントを同時に指示することもできないよ。

心配しないで、私のチームには若いエンジニアを指導してるから。彼のコードを改善させるのが本当に大変なんだよね。動いてはいるけど、構造が悪いし、小さな「インピーダンスミスマッチ」やセキュリティの問題がいくつもあって、3つのPythonファイルにそれが詰まってる。私のチームは10人のエンジニアがいて、彼らがLLMを使って作るコードの質は、経験とさらに相関してる。過去6ヶ月の印象では、以前は「公式な」LLMへのアクセスがなかったけど、これがジュニアと経験豊富な開発者のギャップを広げていると思う。これは私の限られた印象だから、10人のエンジニアのチームからのものだよ。これはサイモンの感じとも合ってると思うよ！

「大量の並列エージェントを管理する」って聞くと、ちょっと不安になるよね。見た目はめちゃくちゃ強力そうだけど、すごくストレスがかかりそう。究極のマネージャーの仕事みたいで、私が望んでいたことじゃない。だけど、たくさんの「もの」を出荷することが問題だったわけじゃないっていう考えも持ってる。開発初期の頃は、毎日ずっとコードを書きたかったし、実際にそうして学んだんだ。今は2回目の10年目に入って、「何をコードする必要があるの？」って考えるようになった。ビジネス的には、コーディング自体が欠けているピースになることはほとんどない。会議では、クロスファンクショナルチームが「これやってもいい？」って聞くと、答えはいつも「はい」だって冗談を言ってる。「xはどれくらい難しい？」って聞かれても、技術チームにとっては答えは常にYES！それを先に片付けておかないと、正しい質問じゃないからね。

頑張って、グレービートレインは永遠には続かないし、過去数年で生まれたゴタゴタを解決するために真剣なエンジニアが必要になるよ。でも、別の分野に移ることも考えてみて。プロのソフトウェアエンジニアリングは、AIのゴタゴタにしばらくは感染するだろうから。手作りのコードが違いを生む分野に移った方がいいよ。ただし、コミットした行数で報酬をもらったり、「バイブコーディング」のKPIと競争しなきゃいけないところは避けた方がいい。

あなたの気持ち、わかるよ。プログラミングやものを作るのが大好きで、何かをやっと理解できたときの高揚感は格別だよね。バイブコーディングもやったけど、全然楽しめなかった。コードを書くことへの愛が、ただ仕事を終わらせたいエンジニアたちに対して自分に優位性を与えてくれると思ってた。でも今はそれが足かせになってる気がして、この分野で続けるべきか、木工でも始めるべきか悩んでる。

ただの新しいコーディングのやり方だよね。ブログにも書いてあったけど、経験がある人ほど恩恵を受けると思う。AIエージェントはジュニアと同じようなミスをするから、それを見抜けるし。でも、ルーチンをいくつかコーディングする楽しさはなくなっちゃったね。それはもう過去の話だ。

あなたの言葉は、俺の気持ちをよく表してる。AIを見守るのがあまり好きじゃない上に、このAIコーディングのビジネスが、仕事をするために曖昧な悪の帝国のアカウントが必要だっていうのを普通にしてしまうのがすごく怖い。ゾッとするわ。