本文へ
ハクソク

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

AIコーディングの罠

元記事: 原文(chrisloy.dev)

概要

  • ソフトウェア開発は 問題解決 中心の知的作業
  • AIによるコーディングは スピード重視 だが、 本質的な課題 が残る
  • テックリードのジレンマと AIエージェント管理 の類似性
  • ベストプラクティス の重要性とAI時代の新たな運用法
  • 人間とAIの 協調による持続可能な開発 体制の確立

ソフトウェア開発の本質とAI時代の変化

  • ソフトウェア開発は コーディング だけでなく、ドメイン理解や要件整理、設計、テスト、デバッグなど幅広い作業の集合体
  • コーディング自体は 全体作業のごく一部、多くの時間は思考や設計に費やされる
  • AI駆動型コーディング（例：Claude Code）は コード生成の速度 が圧倒的
  • しかしAIは アプリケーション全体の文脈保持 が困難で、人間によるレビューや統合が不可欠
  • AIが生成したコードの 事後的な理解・修正作業 に多くの時間を取られる現実

AIコーディングの現実と課題

  • マーケティングでは「 10倍速く」と謳われるが、実際の生産性向上は 約10%程度
  • AIが 単純作業を高速でこなす 一方、人間はバグ修正やテスト、ドキュメント作成、インフラ対応など 地味な作業 に追われる
  • 開発者が本来好きな「コーディング」に 割ける時間が減少

テックリードのジレンマとAIエージェントの管理

  • テックリードは チーム全体の技術的成果 に責任を持つ役割
  • 経験豊富なリードが 難易度の高い作業を独占 すると、チームの成長が阻害され、 知識の属人化・疲弊・離職リスク が高まる
  • チーム全体の学習・成長と 納期・品質のバランス を取る「第三の道」が必要
    • 実践例 ：「Learn. Deliver. Have fun.」というシンプルなモットー
  • コードレビュー、インクリメンタルデリバリー、モジュール設計、テスト駆動開発、ペアプログラミング、ドキュメント整備、CIなど ベストプラクティス の重要性

AIエージェントを“超高速ジュニアエンジニア”として活用

  • LLM（大規模言語モデル）は ジュニアエンジニアの超高速版
  • LLMは 思考や学習能力がなく、モデルやプロンプト工夫のみで進化
  • エンジニアは 品質（Quality） と 速度（Velocity） の両面で成長するが、LLMは速度特化
  • 短期納品重視の「Vibe coding」は 小規模・試作向き、複雑な本番開発には 限界

持続可能なAIコーディング運用のための新しい開発プレイブック

  • AIは 設計・一貫性・保守性 を考慮せず無限にコードを生成
  • 人間が テックリード的役割 でAIを管理し、構造・基準・プロセスを提供する必要
  • AIを開発ライフサイクル全体に組み込む運用が重要
    • 仕様策定： 要件分析・エッジケース検討
    • ドキュメント： 事前生成・レビューによる再利用性強化
    • モジュール設計： 文脈範囲の制御・理解性向上
    • テスト駆動開発： 事前テストケース生成で品質担保
    • コーディング標準： ハウススタイル徹底・ベストプラクティス適用
    • モニタリング： ログ分析や洞察抽出の高速化
  • ソフトウェア開発は コードを書くこと以上の総合技術 であり、AIとの協働で スケーラブルな開発体制 の実現が可能

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

いい投稿だけど、ここには2つの誤解があるよ。まず、LLMを使ってコーディングする熟練エンジニアも、ソースコードを書く前に考えたり、議論したり、ぼーっとしたりしてるんだ。実際、俺はもっともっと考えて、いろんなデザインをバランスさせたり、全体の方向性を把握したりしてる。これが、LLMエージェントにちゃんとしたものを作らせるために必要なことだからね。でも、今はその考えや計画が設計書に記録されて、整理されるようになった。これは、LLMエージェントがなかった頃には全然できなかったことだよ。俺の最初のプロンプトは「まだコードを書くな」から始まることが多い。次に、LLMが学べないジュニア開発者みたいだっていう考え。まず、そうじゃない。初期の開発者は人間だけど、LLMはツールだからね。でも、もっと一般的な議論として、初期の開発者と一緒に働くことには価値があるけど、LLMにはそれがないっていうのは違うと思う。LLMは学んでないかもしれないけど、俺は学んでる。今は3ヶ月前よりもずっと効果的にこのツールを使えてる。俺たちは、LLMから良いプロダクトを引き出す方法を見つける初期段階にいると思う。これは明らかに価値があるよ。

└

私の最初のプロンプトのほとんどは「まだコードを書くな」で始まる。 俺はまず行動計画を聞くのが好きなんだ。実際に編集やファイルに触れる前に、何をするつもりかを知りたい。

└

LLMは何も学んでいないかもしれないけど、俺は学んでいる それに関しては、個人的には彼らが実際にインタラクトから学んでくれたらいいなと思う。ユーザーの視点からすると、俺がやりたいのは、これまでLLMが学んだことをファイルに「保存」できること。後でそれを復元して、LLMにその内容を「再学習」させることができるようにしたい。今はさまざまなフロントエンドUIでこれができるけど、俺が求めている重要な部分は、a) この「再学習」が現在のコンテキストウィンドウに影響を与えないこと（正直言うと、この概念自体がなくなってほしいけど、それは別の話）と、b) 情報を失うようなロスのある再学習でないこと。いくつかの解決策はあるけど、根本的な問題へのバンドエイドに過ぎない。例えば、これまでの議論を要約して再スタートすることはできるけど、明らかにそれはロスのあるメモリ圧縮に過ぎない（人間が同じことをできるのは気にしない、LLMはコンピュータ上で動いているソフトウェアだから）。あるいは、RAGのようなものを使うこともできるけど、AFAIKこれは「プロンプトトリガー」によって機能する。つまり、あなたの「現在の」インタラクションを通じてのみ、知識がそこにあっても、今やっていることがそのインデックスをトリガーしないと、LLMはそれに気づかない。俺が求めているのは、例えば、LLMにfooという関数がmooオブジェクトをバーフィズするために使われることを伝えた後、さらにそのコンテキストの長さを超えて他のことを伝え、議論を保存して、次の日に復元し、さらに他のことを伝えた後、スプラファーに参加する方法を尋ねたら、前回のセッションからmooオブジェクトやバーフィゼーションについて何も言っていなくても、スプラファーに参加するにはバーフィズされたmooオブジェクトに変換すればいいと教えてくれること。 （それに、こういったメモリの保存/読み込みは明示的であるべきだと思う。クリーンスレートから始めたいからで、これは技術の限界を回避するためではない）

└

まだコードを書くな。笑 俺もいつもそうしてる。これは、再現する前に何をしているのか理解するために、いい方法だと思う。コードを書くのは好きじゃないけど、問題解決や論理、統合の部分は大好きなんだ。

└

どうやって良い製品を作るか考えてるんだね。今のところ、明確な前提デザイン以外に何を考えた？

└

まず、LLMを使ってコーディングする熟練エンジニアも、ソースコードを作り始める前に考えたり話し合ったり、ぼーっとしたりするんだよね。そう、考える時間は全体のソフトウェア納品において重要な部分だから、コーディングの部分を早めても全体の生産性や労働要求が劇的に変わるわけじゃないんだ。

└

自己管理ができる人間は少ないよね。これがほとんどの反AI記事のポイントみたいで、私も同意する。

└

私の最初のプロンプトのほとんどは「まだコードを書かないでください。」から始まる。IntelliJではすべての変更を承認しなきゃいけないから、このプロンプトは必要ないんだ。承認なしで勝手に変更するYOLOモードがあるけど、私はそれを使ったことがない。誰か使ってる人いるのかな。

└

「LLMはツールだよ。ツールってのは、事前に期待通りの仕事を高確率でこなすって分かってるか、明らかに失敗する（低確率で）って分かるもの。LLMの場合、信頼できるタスクはほとんどないし、失敗の仕方も分からない。成功を報告しながら失敗することもあるし、人間でもツールでもない動き方をする。LLMは、バグだらけのコンパイラみたいで、間違ったコードを出力しながらも成功を報告することが多すぎる。バグの場所が分からないから、唯一できることは、別の構文で同じようにプログラムを書いて、バグを引き起こさないことを願うこと。それはプログラマーがよく使うツールじゃないよ。こんなコンパイラで作業するスキルは身につくけど、そのスキルがどれだけ移転可能か、持続可能かは不明だね。もしLLMが一部の人が信じるほど大きく早く進化するなら、バグのあるコンパイラが修正されるのを待った方がいいかも。今よりも少ないスキルで同じ結果が得られるようになるだろうし。」

各段階にコーディングアシスタントを含める例があったらいいなと思う。エージェントを各段階にどう組み込むか？Googleでのエージェントとの成功したコラボレーションについての投稿を見たことがあるけど、そこではデザインに合意するために人間同士でたくさんの前準備があって、その後エージェントと一緒にプロジェクトの一部を構築し、徹底的なテストスイートを確保している。各段階でエージェントを含めることは「コンテキストエンジニアリング」を意味するのかな？これは、次のトークンを生成するためのコンテキストを提供するために、各段階でLLMを使用する際にもっとテキストやアセットを投入することになるの？このレベルの段階的開発をエージェントの重みや「理解」に組み込むために、何かもっと深いことができるのかな？これに関する確立されたプロセスはもうあるのかな？ - 仕様 - ドキュメンテーション - モジュラーデザイン - テスト駆動開発 - コーディングスタンダード - 監視と内省

あなたのビジネス、コードベース、またはロードマップに関する深い知識が不足している だから、彼らにコンテキストを与えてあげて。Clineのメモリーバンクアプローチが好きだな。https://docs.cline.bot/prompting/cline-memory-bank これにはアーキテクチャ、進捗、ロードマップなどが含まれてる。俺のもっと複雑なプロジェクトの中には、これだけで3万トークン使うものもあるよ。メモリーバンクは既存のドキュメントや、モデルに伝えたことから構築されてる。コンテキストが多すぎるとモデルが悪化することもあるけど、全体的には妥当なトレードオフだと思う。俺のコーディングスタイルやアーキテクチャの決定をかなりうまく維持してくれるしね。各セッションでは、コードを生成する前にPlanモードを使って、満足できるデザインに到達することをおすすめするよ。

テクノロジーが人を怠けさせるっていう考えに依存しないアンチAIの意見を見てみたいな。LLMを使ってコードを生成する際には、計画-構築-テスト-反省のループが同じくらい重要だって、真剣にこの技術を使ったことがある人なら知ってるよね。考えなしにビルドを進めると、すぐに崩れちゃうからね。でも、そのループを適用すれば、俺が個人的に楽しんでいる部分、つまりビルドのアーキテクチャを考えたり、結果の体験をテストしたりする時間が増える。 > LLMがすべての楽しい、簡単な作業を超高速でこなしている間、俺たちは感謝されないタスクを残される これは、AIがある程度のマスタリーを達成したすべての業界で見られる意見の対立の根源だと思う。物理的な作業の体験を楽しむ人と、精神的な作業の体験を楽しむ人の間に分かれがある。考えることが一番好きな部分なら、AIを使えば、コンセプトからトラブルシューティングまで、ほぼすべての時間をそこに費やすことができるよ。でも、実際にやること、タイピングしたり、ノブや設定をいじったりするのが好きなら、AIは良い部分を奪うだけだよね。

Hacker Newsで議論の続きを見る

同じ出典の記事