ハクソク

世界を動かす技術を、日本語で。

エージェント的コーディングの教訓：コードが安価なとき、私たちは何をすべきか？

15時間前原文(www.dbreunig.com)

概要

  • コード生成が容易になった現代におけるエージェント的コーディングの重要性
  • 実装と学び、頻繁な再構築、テスト自動化の推奨
  • 意図のドキュメント化や仕様管理の実践
  • 難題への集中と簡単な作業の自動化による効率化
  • 保守・サポート・セキュリティの重要性の強調

コードが安価な時代に求められる姿勢

  • エージェント的コーディングの普及とその未来像
  • Frontierモデルによる自動コード生成技術の進化
  • Codex、Claude Code、Piなど各種エージェントの活用
  • 技術進化に合わせた汎用的かつ持続可能な指針の必要性

エージェント的コーディング10の教訓

  • 学びのための実装

    • 仕様主導開発だけでなく、実際にコードを書くことで新たな発見
    • コードが安価な時代は、実装を通じて学ぶ姿勢が重要

  • 頻繁な再構築

    • 早期・頻繁な実装による知見の蓄積
    • 思いつきの検証や大胆な試行も容易な環境

  • エンドツーエンドテストへの投資

    • 再構築が容易な分、動作保証のためのテストが重要
    • 実装方法よりもプロダクトの機能に注目したテスト設計

  • 意図のドキュメント化

    • テストはゴール、コードは手段、意図は判断軸
    • 意図を明示し、エージェントや他者との連携を強化

  • 仕様の同期管理

    • 進捗や学びに応じて仕様書（Markdown等）を随時更新
    • 仕様を固定せず、現状に即した生きたドキュメント運用

  • 困難な課題の発見と集中

    • 単純作業や定型設計を早期に終え、本質的な難題へ注力
    • 直感的設計・パフォーマンス・セキュリティ・堅牢性・アーキテクチャなど価値ある領域への集中

  • 簡単な作業の自動化

    • 難題に時間を割くため、単純作業は自動化・ツール化
    • 学びをスキル化し、反復作業やコードレビューも自動化

  • 自分の審美眼の育成

    • コード生成速度に対しフィードバック速度が追いつかない場合、自己判断が重要
    • ドメイン知識・利用者理解・課題把握に基づく直感の活用

  • 技術力と審美眼の融合

    • エージェント活用時のプロンプト設計やデバッグ効率の向上
    • 経験と直感を活かし、無駄な試行を減らす

  • 保守・サポート・セキュリティの重要性

    • コード生成は安価でも、運用・保守・セキュリティは高コスト
    • 素早い開発と同時に、長期的な運用コストへの配慮が不可欠

まとめ

  • コード生成の敷居が下がった今、実装と学びのサイクル、ドキュメント管理、自動化、難題への集中が重要課題
  • 保守やセキュリティを見据えた設計・運用が、持続可能な開発への鍵

Hackerたちの意見

戻れなくなったら、10倍から100倍のコストになるってこと、わかってる？
└
何が戻る道を閉ざすの？
└
防波堤はないね。 https://newsletter.semianalysis.com/p/google-we-have-no-moat...
└
安いオープンウェイトモデルが、最新技術にほんの少し遅れているという事実と、これらのアイデアをどうやって調和させるの？むしろ、来年には今日のフラッグシップのパフォーマンスを、オープンウェイトモデルでかなり安く手に入れられると思うよ。
インドにいるんだけど、ジュニア開発者の採用が全部減ってる。AIのせいでオフショアリングが減って、清掃作業（ジュニアに任せられることが多い）が必要なくなっちゃった。インターンシップを見つけるのも難しい人が多いよ。特に影響を受けてるのは、システム管理、DevOps、フロントエンドの分野。ここではオファーをもらうのが本当に大変。BrowserStackみたいな会社はキャンパスでの採用オファーを撤回してるし。そんな中、私は自分用のアプリを作ってて、もう1万人以上の月間アクティブユーザーがいるんだ。お金は全然稼げてないけど、楽しいよ。
└
ヨーロッパ全体の市場を見ても下がってるけど、それは「AI」のせいじゃなくて、解雇が最も簡単で影響が少ないからだよ。世界的な不況が迫ってるのに、ウォール街はそう言わないけどね。
└
システム管理者の採用が減ってるのは驚きだね。AIがその分もやってるのかな？
ここに来たのは、10が見られて嬉しいから。 "子犬のように自由"って表現、素晴らしいね。LinkedInを開くたびに、コーディングがほぼ無料だからって、間違った教訓を学んでる大物たちがどれだけいるか怖くなる。エンジニアに、なぜまだお金を払う必要があるのか聞くような釣り投稿がたくさんあって、月に何百万行も生成してることを喜んでるのを見ると、これは悪い結果になると思う。
└
ビジネスオーナーに、もうジュニアを雇う必要がないって言われたことがある。Claudeがその仕事を全部やってくれるからって。これはソフトウェアの会社じゃないから、コードを書くこととは関係ないけど、近い将来に痛い目を見ることになると思った。ジュニアに投資しないビジネスは、未来に投資しないビジネスだよ。
└
これは、SLC（ソースコード行数）で開発者に支払うのと同じことの繰り返しだね。
└
> コードは安いけど、メンテナンスやサポート、セキュリティはそうじゃないよね。この点については何度も考えちゃう。AIの分野では、公開して忘れるパターンのソフトウェアリポジトリが多い気がする。プロジェクトを維持するための忍耐力を示せれば、理想的には完全自動のAIじゃなくて手動で介入する形で、もうそれだけで素晴らしいプロジェクトになると思う。
└
LinkedInは、ダンテも想像できなかった地獄のサークルだね。
特定の種類のコードは安いよね。概念実証は安いし、既存のアーキテクチャに合う小さな機能を追加するのも安い。でも、それ以外はちょっとわからないな。コーディングエージェントは細かいところが得意だけど、センスがないんだよね。機会があれば、コードベースをすぐにぐちゃぐちゃにしちゃうよ。
└
エージェントによるコーディングはまだまだ改善の余地があるし、私が求める品質を常に生み出しているわけではないけど、確信を持って言えるのは、そのベースラインは多くの人が使っているアプリケーションの生産コードよりもずっと上だってこと。エージェント以前のコードが主にセンスや美しい構造を考慮して書かれていたわけじゃないんだ。普通のコードベースは、年々いろんな負債に変わってしまったクイックフィックスでごちゃごちゃの地獄だよ。
└
プレプロダクションのコードはいつも安かったり、無料だったりする。営業の人たちは、昔から「これができる」って書いてあるソフトウェアを売ってきたよね。その機能を書くのにかかる費用は0ドル！でも、プロダクションコード、特にバグのあるプロダクションコードは高い。顧客を失うこともあるし、訴訟の形でマイナスのお金を得ることもある。コーディングエージェントはプレプロダクションや一回限りのものには向いてるけど、プロダクションでは普通の人間の出力以上の規模でリスクを冒すのは本当におすすめしない。
└
でも、ここがポイントなんだけど、以前はその手のコードは非常に高価だったんだ。主に日常の仕事のせいで（今でもマインドフルさが求められて、ただの雰囲気でコードを書くわけにはいかない）。でも、生活を楽にするための追加スクリプトや、内部ダッシュボードにデータポイントに基づいてUI機能を追加するのは、以前は正確にやるのに数日かかってたものが、今は数分の注意でできるようになったんだ。
その人はオーバーチュアマップ財団で働いてて、AmazonやMicrosoftなどがスポンサーになってるんだ。彼はネット上でAIを広めてるよね。マイクロソフトとアマゾンはこういう努力にとても満足してると思う。「Xをする10の方法」の投稿がAIを促進する限り許可されるのは嬉しいな。
└
マイクロソフトとアマゾンのオーバーチュアへのスポンサーシップは、オーバーチュアで働く人たちが「AIを強化する」記事を書くことに同意しているってこと？「AIを強化する」って、例えば「フロンティアモデルは最近コーディングが得意で、他のタスクよりもずっと良い」っていう記事の書き方を含むの？
このスレッドではAIに否定的な意見が多いけど、最新のフロンティアモデルで業界が信頼のラインを越えていくのを見てる。GPT 5.5は、俺が思い切って使える初めてのモデルだよ。今見かけるJIRAチケットは、受け入れ基準、再現手順、チケットが存在する理由の詳細が書かれてる。コミットメッセージもリポジトリのスタイルに合わせて、何が含まれているかの詳細がある。MRも今はマージされる内容の詳細があるし、周りのチームのコードベースは70〜90%以上のコードカバレッジがある。今や、コードの各行にはベストプラクティスが組み込まれていて、役立つコメントや最適化されたホットパスがある。今では、複数のプロジェクトで一度に4つの機能を出荷することができるようになった。MCPは、プログラミングの面倒な部分を自動化してくれて、メールの要約から、Confluenceのドキュメント生成、スライドデッキの作成までやってくれる。技術的負債が積み上がるって叫ぶ人もいるけど、逆になると思う。ソフトウェアの開発が安くなったから、ソフトウェアが増えるんだ。以前のコードはほとんどクソだったし、俺がオンボーディングしたプロジェクトは人間が書いたドキュメントなしのスパゲッティの山だった。悪いコードの基準がかなり上がって、問題を直すのも、会社がトークンにお金を出せば基本的に無料になった。
└
チェックボックスを埋めるのが好きな人たち、つまり上に書いたほとんどの人にとって、AIは歓迎される。それにはマネージャーも含まれる。でも、ソフトウェアエンジニアリングとは関係ない。良いコードは全て人間が書いたものだ。AIはそれを盗用して、洗練させて、膨れ上がった形で再パッケージしてる。AIが盗用したゴチャゴチャを深く見てみると、90%はできてるように見えるけど、実際は50%しかない。ゴチャゴチャを直すのは、自分で書くよりも時間がかかる。
└
> 今では複数のプロジェクトで一度に4つの機能を出荷することができる。多くの人が、LLMがICをマネージャーのように動かせるようにすることを見逃してる。今は4つのストリームを管理できる。数年後には、今の典型的なマネージャーのように10のストリームを管理できるかもしれない。俺の経験では、LLMは1) 自分がやってることの専門家である場合（本質的にスケールしない）、2) ただ一つのことに取り組んでいる場合（複数のストリームを管理できるのに意味がない）、3) LLMが特に苦手なことをしている場合（残っているコーディングタスクはあまりないけど、確かにまだいくつかある）には、あまり速度を上げない。
└
数字的にはこれは例外だと思うけど、素晴らしい例外だ！でも実際には、人々が考えるのがあまり得意じゃないから、物事が悪化しているのを見てきた。見た目は良さそうなJIRAチケットが、実は微妙な意味で無意味だったりする。一方で、以前は明らかに指摘できるような欠陥があっただけだった。つまり、良い出力をより良くする一方で、普通の出力（ほとんどの出力）を悪化させて、量と質の見かけを増やして、新たなFUDやストレス、退屈、不幸を生み出している。これは、普通の出力に伴う以前の問題をより管理しやすくしていたのに。最新のモデルでもこれを見ているのは、問題はユーザーであってモデルではないから。モデルは、彼らを新しい形でさらに悪化させる力を与えているだけなんだ。
└
> 今では複数のプロジェクトで一度に4つの機能を出荷することができる。それはあなたなしで可能なの？これが次のステップだと思う。良いことでも悪いことでもないけど、これがどこに向かうのか本当に興味がある。
└
ほとんどに同意するけど、コードが実際にどうなってるかには目をつぶってきた。レビューは早いし、トークンボットの主張に直接最適化することで内なるプログラマーを裏切ってる気がするのは認める。でも、数字が嘘をつかなければ、このプロセスには満足してる。
└
> ソフトウェアの開発が安くなったから、ソフトウェアがどんどん増えていくね。でも、何のためのソフトウェアなの？コーディングは、開発者の仕事の10%くらい（Brooksの「シルバーバレット」では1/6と推定されてる）で、ボトルネックじゃなかったし、もしそれを完全に自動化しても、開発時間は10%しか減らないよ（人間のコードレビューとかしない前提で）。ソフトウェア開発全体（コーディング部分だけじゃなくて）も、企業が製品を早く出すためのボトルネックにはならなかったと思う。ビジネスのニーズもそんなに早く変わらないし、外部要因もあまり動いてないからね。結局、LLMを使ったコーディングは、売り込んでる人たちが予想してるほどの影響はないと思うよ。もちろん、個人開発者やソフトウェアスタートアップには例外があるけど、大きな企業にとってはあまり影響がないんじゃないかな。
└
あなたが言ってるのは、マネージャーの役割であって、ソフトウェアエンジニアの役割じゃないよ。ソフトウェアエンジニアリングは、コードを書くこととはあまり関係なくて、何をするべきかを高いレベルで設計することが重要なんだ。コードは実行部分に過ぎない。LLMがコードを書く？それはいいけど、明確なアーキテクチャの方向性がないと、そのコードはただの無駄だよ。技術的負債じゃなくて、ランダムな文字列の集まり。Claudeのコードや他のものが攻撃計画を作るって言えるかもしれないけど、それもアーキテクチャレベルじゃなくて、実行レベルなんだ。私にとって、アーキテクチャは最初から始まる。コードの1行も書く前に、DDD（ドメイン駆動設計）をやって、ルールセット（例えば、ドメイン名をテーブルプレフィックスに使う）やコンテキストを作って、そのアーキテクチャに基づいて機能を定義する。LLMはこれをすべてできるけど、明示的に頼まないといけない。だから、ブレインストーミングには便利だけど、自動的に信頼性のある設計をして、目を閉じたまま本番環境に持っていくのは無理だよ。10万人のユーザーベースを支えるのも難しい。そういう意味では、マネジメントに対してコード行数みたいな虚栄心の指標を売り込んで昇進することはできるけど、それでもソフトウェアエンジニアリングとは言えないね。
└
> 今は複数のプロジェクトで一度に4つの機能を出荷してるよ。これが今のソフトウェアが遅くてバグだらけで混沌としてる理由だね。
└
> 問題を修正するのは、会社がトークンにお金を出せば基本的に無料だよ。あなたにとって「基本的に無料」って、誰かがそのコストを払ってるってこと？それは、広い範囲のことに適用すると世界を悪化させるだけの考え方だよ。その考え方には慎重になった方がいいし、未来を考えてみて。
└
チケットには微妙なエラーがあって、それはコードベースに詳しい人じゃないと気づかない。コードは、最も一般的な状態にデフォルト設定されたif-then-elseの裏に例外を隠していて、その状態を持たない1%のユーザーに問題が起きるまで気づかれない。新機能は、受け入れテストでカバーされていない機能を静かに壊してしまう。ドキュメントは4倍の長さで、それに頼っている人は誰も読めない。そして、私はチケットを細かくチェックしたり、PRをレビューしたり、貢献者を指導したりして、こういうゴミが本番コードに入らないようにするために時間を使わなきゃいけない。
コードを書くことだけが仕事の一部で、簡単だったら、こんなに給料は高くないよ。エンジニアリングは難しい。常に難しいままだ。AIが一部を楽にしてくれるのは嬉しいし、俺たち（ソフトウェアエンジニア）はエンジニアリングに集中できるから、それはいいことだ。コードは決して安くない。今の非現実的なAIの価格で、エージェントを使う方がジュニアを雇うより安いからって、コードが安いわけじゃない。コードを生産するのが安くなるだけで、それはもともと低コストだった。コードの各行はコストであり、メンテナンスの負担であり、複雑さでもある。AIは、たとえ無限のコンテキストウィンドウがあっても、コードが多ければ多いほどお金がかかる。AIでエンジニアのチームを丸ごと置き換えられる？多分、できるだろうね。会社の全員を解雇して閉鎖することも、ほとんどの会社にとっては問題なくできるかも。AIはデバッグを手伝ったり、コードを書くのを助けたり、設計をドラフトするのを手伝ったり、ほぼすべてのステップで役立つ。OpenAIやAnthropicに製品のコードの完全な所有権を与えて、最後のエンジニアを解雇した瞬間、AIの価格は今のエンジニアの給料に合わせて上がるかもしれない。高給のコンサルタントを再発明したようなもんだ。あるいは、中間の道を選んで、良いエンジニアを雇って、彼らがコードベースを理解し続けるようにして、仕事をうまくやるために必要なツールを使わせるのがいいと思う。これが、俺が見てきた有能な会社のやり方だ。
└
「コードを生産するのは常に低コストだった」って、何と比べて？コードの生産コストとスピードが大幅に下がったことを無視する人が理解できない。AIが出る前も、ビジネスを運営している人たちは今のAIに対する人たちと似たような問題を抱えていたけど、そのコストはもっと高かった。アイデアのプロトタイプを作るために誰かを雇うと、数千ドルかかって、最低でも数週間かかってた！今は20ドルで数日でできる。フィードバックループがボトルネックなんだ。
良いリストだね。これらのことは直感的に理解してたけど、（3）だけは違った。著者に同意するよ：壮大なアーキテクチャプランを考えるための安価な実験をして、入力を待たずにすぐに実行するのが正しい方法だと思う。「簡単なことはすべて自動化する」も重要だけど、難しいことも自動化しようとするべきだと思う。それに時間をかける価値はすごくあるからね。でも、エンドツーエンドテストについてもっと調べるべきかも。
安いか高いかの問題じゃなくて、いつコストを支払うかってことだよね。LLMを使うと、将来にコストを先送りするのを避けるのが簡単になるか、逆に先送りしちゃうかもしれない。LLMやフレームワークのおかげで、プロセスの一貫性が品質を継続的に改善するための強制力を生むことが多いんだよね（つまり、コストを先送りしないように）。問題ごとにプロセスの中でその問題を浮き彫りにして対処するステップを作るのが理想で、できれば自動化された形でね。チームにレベルアップしてもらうために長い時間を費やしてきたけど、これがコード生成だけじゃなくてプロセスにも組み込まれれば、役に立つんじゃないかと期待してるよ。
市場には大企業と小規模な組織の間に大きな格差があると思う。大企業は相変わらずの遅れをとってるし、イノベーションよりもガバナンスを優先してる感じ。その他の企業、特にテクノロジー関連のところは、みんな何かを作ってるよね。「作るか買うか」が今の話題だね。