最後の一文、まさに自分の考えを言い当ててる。クラウドを自分の作業フローに取り入れようとしてみたけど、結局、自分で最初から全部書いてたら、同じ時間でプロジェクトを終わらせられたし、内容ももっと理解できてたと思う。AIに手伝ってもらった部分が難しいところだと、逆に理解が奪われちゃうんだよね。そこが一番理解が必要な部分なのに！

あなたの意見に賛成だよ。自分が気にしてるのは、むしろ面倒な部分なんだ。面倒さが技術の価値の一部だって言えるかもしれないし、それには真実もある。でも、結局はトレードオフだよね。節約した時間で何ができるか、他のことから得られる価値はどれくらいかって考えちゃう。

こういう記事で「コードを書く苦痛」について語られるのが不思議だな。 AIに関するコメント欄とvim/emacsのコメント欄を比べるのも変だと思う。vim/emacsのコメントでは、コードを書くのにほとんど時間がかからないってみんな言ってるし、考えることに時間を使ってるから、早くタイプすることを学ぶ価値がないって言ってる。一方でAIのコメントでは、AIがコードを書いてくれるから、もっと考える時間が増えるって言ってる。もしコードを書くのがそもそも簡単な部分で、早くタイプすることを学ぶ価値がないなら、AIはどれだけ価値を加えてるんだろう？これらは別の人たちかもしれないけど、かなりの重なりがあるんじゃないかって思う。

人それぞれだよね。絵を描く人もいれば、彫刻を作る人もいる。アンディ・ウォーホルは素晴らしいデッサンの技術を持ってたけど、彼の名声はその絵から来たわけじゃない。彼は他の人のアートをスクリーンプリントして有名になったんだ。しかも、そのアートはしばしば彼のものじゃなかった。彼はその技術を開拓しただけで、新しいからみんながワクワクしたんだよね。今では彼は世代を代表するアーティストと見なされている。僕は、すべてのことにおいて、出力の質とそれがどう受け取られるかが重要で、出力を生み出す過程はあまり関係ないと思ってる。もしLLMを使って多くの人が好きなものを書いたら、それはアートを生み出したことになるし、君は素晴らしいアーティストだよ。もしトールキンが今の時代に生まれていたら、現代のツールを使いながらも素晴らしいアートを作り続けていただろうと思う。彼の創造的な頭脳と仕事への姿勢が、創造プロセスで一番大事な要素だからね。どんなLLMもマスター作品に近い質を提供することはないと思うけど、創造的な人たちにとって、厳しくて報われない「まずは存在させる」段階での貴重なツールにはなると思う。天才は「後で良くできる」段階でいつも通り輝くからね。

AIツールが好きな同僚と話してたんだけど、彼はコードを書くよりも、知らないコードを読む方が得意だって言ってた。これってどれだけその違いに関係してるんだろう？それが本当かどうかも気になるし、彼らはその関数が名前の通りに動くって信じてるだけなのかもしれないね。僕も君と同じように、自分が書いたコードの方が、全く知らないコードをレビューするよりも安心感があると思う。制限は高レベルのデザインにあって、どれだけ早くコードをファイルに投げられるかじゃないんだよね。これは認知の違いかもしれないし、もしかしたら何かがどう動くかを正確に知りたいっていう欲求が強いのかも。「なんとなく動いてるっぽいから大丈夫」っていうのを受け入れるのは難しいよね。

トールキンの本はアートだけど、プログラムは何かをするためのものだよね。今、一部のプログラムはアートと見なされることもある（例えば、コードゴルフ）し、作成者がアートだと思うこともある。僕は自分のプログラムやコードは、コンピュータにやってほしいことをさせる手段に過ぎないと思ってるし、ちゃんと動くようにする簡単な方法もある。> フロドとサムがゴクリの信頼性について議論している。フロドはゴクリを擁護すべきで、サムは彼の味方であるべきだ。 これがまさにプログラムの本質だよね。言語の細かい部分じゃなくて。

現在のモデルは新しいものを書くことはできない。ただパターンをマッチさせたり、評価したり、コピーするのが得意なだけだ。今は多くの価値をもたらしているけど、創造性はないんだよね。

コードを書くのが本当に苦痛だと思ったことないの？CIが失敗してるんだけど、昨日は通ったのに。どこかで不安定なAPIが呼ばれてるのかな？最近のコミットで壊れる変更が入った？もしかして、サードパーティの依存関係のどれかが壊れる変更を出したのかも。新しいコードに取り組もうと思ってたのに、今はこの新たなフラストレーションを解決するのに5分から1時間以上かかることになっちゃった。予測不可能だし。物を作ったり新しい問題を解決するのは大好きなんだけど、こういう面倒な問題に時間を奪われたくないな…特に今はCIのデバッグをエージェントに外注できるから。最近はCIで何かが不具合を起こすと、Claude Codeに指示して、90%の確率で数分後には解決策が見つかるんだよね。

コードを書くのが苦痛だとは思わないけど、退屈だとは感じるかな。ボイラープレートに無駄に時間を取られると、いいところにたどり着けないんだよね。LLMを使えば、その部分をスピードアップできる。あなたの例に戻ると、トールキンがタイプライターの設定にめちゃくちゃ時間をかけて、修正テープを用意したり、スペルを確認したり、誤りを直したり、タブの位置を自分の基準に合わせたり、句読点をチェックしたりしているところを想像してみて。今、その無駄を全部排除して、対話の芸術的な部分に集中できるようにしたらどうなるか。

コードを書くことは簡単な部分で、実際には小さな時間の浪費の一つだと思う。労力の成果は、計画、デザイン、アーキテクチャ、そして今と将来に達成したい要件にある。これらはすべて、計画するためにかなりの努力と先見の明が必要なんだ。準備が整ったら、もしかしたら不安だったエリアでPOCをやってみたり、良いスケルトンを使ってハッピーパスの影を描いたり、計画を繰り返して本物の「コード」や基盤を置いたりする。これは素晴らしいプロセスだよ。最初は、コードから深くプロジェクトに飛び込んで、ワークアラウンドボタンを何度も押してしまって、結果的にもっと高くつくことをみんな知ってるよね。

うん、全然理解できない。誰かのフレームワークを使う代わりに、AIを使って（おそらく劣った、十分にテストされてない）フレームワークを書くってことだよね。そして、そのロボット社員は、既存のオープンソースフレームワークから色々引っ張ってきてるだろうし（もちろん、ほぼそのままではないけど）。それが何だっていうの？

Reactを使わないのは本当に難しいよね。あれは hype がすごくて、今やすっかり根付いてるし。Reactを知らないでフロントエンドの仕事を探すのは大変だよ。

実際のバトルテストなしに既存のフレームワークの一部を再実装すること AIからコードをコピーするトレンドは、今やAIの時代に進化しただけだね。人々は、影響を完全に理解せずにシステムの完全な書き換えを試みるだろうし、保護策も講じないだろうと予想してる。AIは、経験の浅い開発者によって誤用される、他の多くのツールと同じように、ただのツールになるだけだと思う。この方程式の人間側には何も変わっていない気がする。

今、AIには「リーダー」たちがいて、既存のドメイン知識を無知なまま発見しようとしてる感じがする（UXリーダーシップ™の15年間でデザイナーとしての深さに気づくのがどんな感じか聞いてみて）。最近ではMCPが登場して、多くの人が「おお、サービスに使えるAPIがあれば、つなげられるんだ！」って気づいてる。今のケースでは、AIが面倒なことをやってくれる→「おお、膨大な依存関係を捨てることでリスクが減る！」って感じ。これらは本当に発見された真実だけど、誰もそのトレードオフを理解してくれとは強制してないんだよね。

サポーティングエコシステム、... 一般的な用語やパターン それがフレームワークを使う一番の理由だったりする。必要ならPythonでウェブフレームワークを再実装できるけど、そうするとテストやドキュメント、ミドルウェアを全部失っちゃうし、何より次の人が来て、僕がやったことを再学習しなきゃいけなくなる。

昔はライブラリやフレームワークを使うのが正しい選択だったんだけど、その理由からね。でも、LLMはどんなプログラマーよりもはるかに多くの経験を持っていて、必要なコードだけを生成できるんだ。フレームワーク全体を含める必要はないんだよ。

30年のソフトウェアエンジニアとしての経験から言うと、ほとんどの場合、i)とii)は真実ではないと感じている。多くのフレームワークは「xを解決するために何かを作っている」というよりも、「何かを持っていて、それが一般的に役立つかもしれないものを作った」という感じで作られている。だから、多くのフレームワークは元々の構造からの重みを持っている。すると、人々はフレームワークを自分のニーズに合わせるリクエストをし始めて、いくつかは実装され、いくつかはされない。実装されないものは、優れたチームが拡張やプラグインをフレームワークに組み込んで、気づいたら自分のコードベースの中に必要なかったモンスターができてしまう。私が使ったすべてのORMがこの説明に当てはまると思う。

率直に言うと、人間が書いたコードを拒否してLLM生成のコードを選ぶのは一種のマニアだと思う。こういう視点からの文章を読んで、段落を超えると、すぐにその記事自体がLLMによって書かれていることに気づくんだ。これだけの文章を自動化するなら、自分の読書もどれだけ自動化しているのか気になるよね。以下の文章がこれを完璧に捉えている。著者は、自分のフレームワークをバイブコーディングすることで実際にコードを「理解」できると説明しようとしているけど、そのポイントを作るために使ったLLM生成のテキストが、レンガを切ったり縫ったりすることについて話していることに気づいていない。> でも、私は20年間レンガを積んだり、モルタルを広げたり、切ったり縫ったりしてきた経験があるから、これをすべてできるんだ。もし何かが気に入らなければ、入って理解して、自分の好きなように修正できるし、次回は自分の設定に指示してやりたいことをするようにできるんだ。

フレームワークに対する俺の問題は、フレームワークの制作者が興味を持ってないことをやりたい瞬間に、三つの問題が出てくることだ。自分の問題、基盤プラットフォームでの実装方法、そしてフレームワークを回避して自分の機能を壊さないようにする方法。

そうだね、「ここで発明されていない」症候群は、エージェントコーディングブームの前はアンチパターンとされてたし、これらのツールがそれを無意味にするとは思えない。ビジネスを始めるなら、スタックのすべてのコンポーネントをゼロから書くのは、やっぱり気が散ると思う。エージェントツールは開発コストを下げたけど、ゼロにはほど遠い。著者も認めてるけど、すべての問題を批判的に考え、設計し、適切なパターンを選ぶ必要がある。さらに、そのコードを維持する必要もある。それはビジネスのコアに向けられない多くのエネルギーだと思う。変わるのは、今は自分の問題や状況に合わせたコンポーネントをより簡単に書けるようになったことだね。これらのフレームワークは、さまざまな複雑さの問題を解決するために設計されていて、壊れないように気を使う必要がある。自分の問題に必要なだけの洗練された代替品を開発する選択肢があるのはいいけど、カスタムなものを作るのが常に正しい選択だとは思わないな。

その信念はいつも正しいわけではないが、しばしば正しい。APIを見れば、1時間程度で高い確率でわかるだろう。

大規模な崩壊が起こるとは思わないけど、デスロッピングが開発者の時間をますます占めるようになると予測している。もしかしたら、特訓を受けたデスロッパーボットが登場する日も近いかもね。

AIにフレームワークを使うように指示すると、いい結果が得られるし、より良い結果につながると思う。俺はClaude Codeを使ってDjangoとReactで開発してるけど、意外といい感じなんだよね。試行錯誤されたソフトウェアを使う方が好きだな。自分で書かせるのは、超ミニマルなCSSが欲しいときだけだね。

記事はこれを簡単に触れて、すぐに次に進んでるね。「私は20年間、レンガを積み、モルタルを広げ、裁縫をしてきた経験があるから、これらすべてをこなせる。もし何か気に入らなければ、理解して修正することができる。次回は自分のやりたいことをするように設定を指示できる。」このダイナミクスは、AIの使い方やアウトソーシング全般に当てはまると思う。タスクを深く理解していれば、効果的にアウトソーシングできるけど、理解していなければ、返ってくるものが正しいのか、メンテナンス可能なのか、スケーラブルなのかもわからない。

このコメントは記事の重要な洞察を無視してる。今、一番大事なのはデザインだよ。デザインが、雰囲気コーディングとソフトウェアエンジニアリングの違いなんだ。良いデザインがあれば、今のソフトウェアエンジニアは100倍生産的だよ。彼らが生み出すものは、デザインのおかげで高品質だし、エージェントのおかげで生産も早くて安い。確かに、雰囲気コーディングされた大規模システムには、いつか問題が出るだろうね。著者も正しい、よく設計されたシステムはもはやフレームワークやベンダーを必要としないし、最初からよく設計されていれば失敗する可能性も低い。

AIの長期的な影響についてはあまり好きじゃないけど、AIツールの助けを借りて「ただやる」ことができるようになれば、最も難しいプログラミングプロジェクトに頭から飛び込むことができる。これが世界中の人間のプログラミングスキルを想像を超えるレベルに向上させると思う。

逆だと思うな。re:Inventで人気だったセッションの一つは、3人のSREエージェントを作ることだった。そのうちの一人はログを読み取ってエラーを報告するだけ、もう一人はエラーを分析してトリアージして修正案を提案、最後の一人は実際に作業をしてリポジトリにPRを出す役割だった。そして、そのセッションの一環として、システムにバグを人工的に導入して、ブラウザでそのバグに遭遇することになる。ブラウザで失敗が起こるのを見て、Cloudwatchのログを見ればエラーが記録されているのがわかる。2分後には、SREエージェントがバグを修正してマージの準備が整っていた。「これらのシステムが実際にどう機能するかを理解する」ことは、「私はこのコードのほとんどを書いていない」とは矛盾しない。たとえ一人のエンジニアでしかないとしても、キャリアの中で「自分が書いていないコードをデバッグする必要がある」ことは多い。ここ数ヶ月で見たのは、出力の質が飛躍的に向上していることで、再プロンプトがどんどん少なくなっている。さらに、「これを書いた後は、このマークダウンファイル内のロジックを文書化する」というのは、自分の参考や今後のLLMセッションにとって非常に役立つ。AWSはこれがソフトウェアエンジニアリングの未来になると大きく賭けていて、LLMに関連するいくつかのプラクティスには独特のロックインがあるけど、非常に魅力的なビジョンだと思う。これらの非決定論的なツールが、作業を助けるためのより決定論的なサポート機能を持つようになれば、質は人間のコーディングの質に近づき、もしかしたらそれを超えるかもしれない。

俺の予想では、一度の大きな変化はないと思う。どこかで「もう機能しない」と言えるラインはないんじゃないかな。代わりに、エージェントが書いたコードはどんどん複雑になっていって、作成・レビュー・デバッグ・修正に必要なトークン（& NPU/GPU/RAM）が増えていく。そうなると、比較的シンプルなプロジェクト（例えば、スマホのバンキングアプリ）ですら、人間が理解するのは難しくなると思う。ただ、複雑さがムーアの法則やAIに餌を与える我々の能力よりも早く成長するのか遅く成長するのかは気になる。

「潜在的に安全で安定したコード」という側面は、俺にとって非常に興味深い。すでに安全でも安定でもないコードが膨大に存在する（ほぼすべてのコードがそうだと思う）。これはすでに問題になっているけど、実際の影響はあまりない。Cloudflareがインターネットトラフィックを一定期間止めても、独立した形で調査されることはない（俺の知る限りでは）。誰も責任を問われることはない。でも、他の土木工事の取り組みでは、絶対にそうではない。定期的なチェックや、システムを監査する政府機関、害を引き起こした場合の罰則などが期待されている。LLM生成コードは、ソフトウェア「エンジニアリング」の堕落の続きだ。今の状況は、誰も責任を持たず、ブラックボックスのコンピュータ群さえも合理的に責任を持たない。もし今日誰かが悲惨なミスをしたら、誰が原因かはわかる。でも、「Cloudflare2」がすべて（または大部分）が生成されたものであれば、責任者は「なんでこうなったのかわからないし、このミスを引き起こしたシステムを作った人たちもわからない」と言って手を挙げるだけだ。これは非常に懸念されることだ。

ビジネスは何十年も経営者文化で運営されてきた。これらの人々は、年間何百万ももらって、飛び回って人と握手するだけ。過去には、急いで出されたプロジェクトに関わったことがあって、意図したことを一つも達成できなかったことがある。そして、管理者の反応はどうだったか？彼らはそれを大好きだった。おお、すごく良さそう、かっこいい、よくやったって。管理者たちが互いに持ち上げ合って、他の人の手を使って梯子を登っているみたい。俺が愛するテクノロジーやエンジニアリング、プログラミングが、現代の生活の中で最も良いものを生み出す一方で、利益を追求する中で最も悪いものを生み出すために歪められているのが、本当に辛い。責任者たちは？彼らはそれが機能するかどうかなんて気にしない。ただ、自分たちが受けるべきでない昇進が欲しいだけ。2000年代中頃に戻りたいよ。 ;~;

今週初めにHNの投稿で「AIがB2B SaaSを殺している」と宣言された: https://news.ycombinator.com/item?id=46888441 その態度の開発者やビジネスは、同じように厳しい目覚めを経験するかもしれない。