2026/02/28 2:22
**747 S と コーディング・エージェント**
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
記事は、AI コーディングエージェントが現在、人間の入力をほとんど必要とせずに機能全体を生成できるようになった一方で、この利便性が開発者の実践的な学習やドメイン知識を侵食していると主張しています。
最初、著者は大規模言語モデル（LLM）を使用して特定のエラーをデバッグしたり解決策を検索したりし、まだ手動でコードを書かなければなりませんでした。最近のツールはエンド・トゥ・エンドでコードを生成するため、著者はそれらにより依存していますが、繰り返し使用してもプログラミング速度や将来の問題解決力が向上しないと感じています。エージェントが失敗した場合、部分的に正しいソリューションを理解することが難しくなります。特にタスクが大きく複雑になるほどです。
著者は、プロンプトスキルは単純化されるだけでなく、本当の成功にはプロンプトエンジニアリングではなく深いドメイン知識が必要だと強調しています。AI が生成したコードを読むことは、自分でコードを書くよりも教育的価値が低いです。
将来に目を向けると、コーディングエージェントは不可欠な存在であり続けますが、開発者が基本的なプログラミングの実践をやめればスキルギャップが生じるリスクがあります。単純な緩和策として、エージェントの出力と比較する前に手作業で最小限のコードを書く演習を行うことです。
本文
カル・コロン / ブログ
ホーム – ブログ – 研究 – 海軍 – 履歴書
数年前、ドイツへの出張から帰路に着いたときのことです。ビジネスクラスへアップグレードされ、隣にはベルギー人の747パイロットが座っていました。彼は50代か60代と思われます。私たちはキャリアについてかなり話しました。私は海軍を退役してから一年も経たないうちにプロフェッショナルプログラミングへ転身したばかりです。一方、彼は大学卒業直後からパイロットで、約20年間747を操縦していました。機械工学を専攻し、現代航空機の可変ジオメトリジェットタービンについて非常に詳しく語ってくれました。このタービンは広い高度範囲でも効率的に動作します。
私は彼が自分の仕事にどれだけ適しているかを羨ましいと感じていました。明らかに彼は航空機好きで、たとえほとんどの航空会社が747を運航しなくても、その機体は圧倒的な存在です。彼は「この機械を操縦できることは特権だ」と同意しましたが、寂しげにこう言いました。
この仕事では、ある程度経つと改善の余地がない。今日も昨日より良くなることはない。
彼はもう自分の知識で747をほぼ完璧に理解していると言っていました。実際、時にはエンジニアや設計者になりたかったとも語り、仕事の中で新しいことを学べるようになればと願っていたそうです。そして付け加えました。
あなたは運がいい、あなたの仕事はそんなものであるからだ。
それ以降、私の仕事は大きく変わりました。コードを書くエージェントが、かつて自分が行っていた作業の多くを代替できるようになったのです。私はAI研究所で働いているため、この変化に対して不満を抱くべき最後の人間の一人だと言えるでしょう。AIが経済的約束を果たせば、私も大いに利益を得られます。しかしながら、問題解決の方法は変わり、時にはエンジニアよりパイロットに近い感覚になります。
過去にバグ修正や機能実装を行った際は、最低限必要な努力で状況を理解することが不可欠でした。例えば、このサイトにページネーションを追加する場合、Jekyllのドキュメントを読み、適切なプラグインを見つけ、サンプル設定を確認し、変更します。うまくいかなければGoogle検索を行い、さらに調べて試行錯誤し、再テストなどを繰り返しました。このプロセスでは、学び逃げることができず、システムの仕組みをより深く理解して問題から離れます。もし同じ機能を再実装するなら、もっと速く簡単に行えます。
LLMがコーディングで上達し始めた頃は、このプロセスの初期段階で助けを求めることもありました。主に検索エンジンの代わりとして使用しました。エラーに直面したときは、メッセージをチャットボットへコピー＆ペーストし、答えを確認してから理解しようとします（多くの場合、先に読み解こうとせずに）。これでクリティカルシンキングが置き換わるわけではなく、依然として学び、計画を立てて変更を実装する必要があります。
しかし過去数か月のAIコーディングエージェントは状況を変えました。多くの場合、エージェントは全機能をゼロから完成させることができ、私の介入はほとんど不要です。コードベースに変更を加える際、まず理解しようとする代わりに「ワンショット」で問題解決できるか試み、失敗している場合のみ介入します。この頻度は減少し、エージェントに任せる機能はどんどん大きくなっています。
私はコーディングを主に手段と考えています。エージェントのおかげで以前よりも多くのことが可能になったので、大部分では満足しています。ただし、完全にAIに機能を任せることには不安もあります。
この方法だとスキルや知識は急速に蓄積されません。エージェントで構築した機能を再度作成する際に速度が向上するわけではありません。20年かけてAIでコードを書き続けても、最終的にそれほど熟練しているとは限らないのです。改善は見られません。
もし介入しなければならずLLMを救う必要がある場合、多くの場合私は混乱します。突然他人のコードを読むことになり、問題解決への段階的な理解ではなく、ほぼ完成済みの解決策を受け取ります。ただしそれは少し不完全です。LLMがより大きなタスクを処理するほど、この問題は悪化します。唯一の救いは介入頻度が減ることです。
「新しい本質的スキルはエージェントへのプロンプト作成だ」と主張されるかもしれませんが、私はそうは思いません。プロンプティングは簡単で、さらに容易になるでしょう。プログラミングと問題に関する深い知識こそが良い設計判断を下す鍵であり、この知識こそがエージェントの成功を決定づける最重要要素です。この知識習得はオプション化されつつあります。
一部では「あなたはエージェントに盲目的に頼らず、生成されたコードを必ず読むべきだ」と辛口で答えるかもしれません。私は確かにコードを読んでいますが、レビューと作成は異なり、後者の方が学びが豊富です。この考えに同意できないなら、ソフトウェア業界では働いていないでしょう。
コーディングエージェントは永続的です。使わない人は愚かです。しかし、最も成功するには自分が取り組むドメインを理解していることが重要です。これは以前はプログラミングの不可欠な副産物でしたが、今ではそうではありません。そのために、教育的タスクとして最低限手でコードを書く練習をしたり、問題解決策を自分で試みてからLLMと比較する方が良いかもしれません。