2026/07/11 1:12
2026 年にコードを書く理由とは
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
主要なメッセージは、ソフトウェア工学がコードの記述のみ、あるいは AI 出力の盲目的な承認に依存することはできず、代わりにエンジニアリングにはスキル、ナレッジベース、および自動評価を核とした堅牢な「ソフトウェアファクトリー」インフラストラクチャを構築する必要があるという点である。英語による記述は複雑な計算に対してしばしば曖昧でありすぎ、したがって真の精度を得るためには、Large Language Models (LLMs) を単なる「インターン」として扱うのではなく、可実行環境で直接作業を行う必要がある。これらのデジタルアシスタントは、慎重に監督されない場合、人間のエラーを増幅したり、状態管理が不十分で脆弱なシステムを生み出したりする可能性がある。
こうした罠を避けるためには、開発者はエンジニアのように間欠的にエンジンを実際に取り外してその内部構造を理解するように、深いアーキテクチャ的知見を維持しなければならない。この実用的アプローチにより、チームは継続的インテグレーション (CI) を後付けの考えではなく、基盤的な安全網として早期に導入するようになる。実行可能なステップへの優先およびシステム脆弱性との直接的な関与を通じて、企業が AI によって引き起こされるコード量の急速な拡大に対応できるようであり続ける堅牢なパターンを確立できる。最終的に、エンジニアは現実時間において批判的に思考することにより独自価値を保持し続け、技術が急速に進歩する一方で品質の低下は緩やかに保つことを保証する。
本文
ソフトウェアの工場：コードを書くことの再考とエージェント活用指南
1. 我々の仕事の本質
我々の仕事は単なるソフトウェア構築ではなく、「ソフトウェアの工場」そのものを築き上げることです。
- エージェント成功を支えるためのインフラ整備が不可欠です。
- 能動的な行動: プロンプト、スキル（AGENTS.md）、知識ベースを活用し、自律的に動かせます。
- 反応的・受動的な防護: 自動化された評価ツール（テスト、リンティング、型システム、評価タスクなど）により、ソフトウェアの質を守ります。
- これらの制約を与えることで、能力の低いモデルであっても十分な成果を生み出せます。
- 最新のコンテキストを与えれば、変更要求も適切に処理できます。
- コードレビューすら不要に見えるほど自動化が進む可能性があります。
2. なぜコードを書く必要があるのか
しかし、私は「コードを書くことを捨てるべき」という見解には同意しません。
- 直接の実行環境体験: エージェントが人間の頭脳（知能）を凌駕するためではありません。英語に頼らず、実行環境内で直接思考することが重要だからです。
- 脆弱性（Fragility）の理解:
- 「遠くから観測」だけでは不十分です。システムアーキテクチャと真に接続する必要があります。
- コードの上に構築する際、一つでも壊れる可能性がある箇所を自分で体験し、その「痛み」を理解することが必要です（4DX 体験のような没入感）。
- 設計の改善:
- 脆弱性を体験することで、エージェントが理解しやすいコード構造を作れます。
- コードを整頓し、アーキテクチャ原則を文書化すれば、ソフトウェア工場は向上します。
- デバッグ能力やテスト戦略の弱点発見を通じて、新たなバグを撲滅できます。
3. エージェントとの正しい関係性
私はコード生成ツールとしての AI を否定するわけではなく、「スロープ（粗悪なコード）」への依存も警戒します。
- 人間がすべきこと:
- コード書きは思考を助ける有用なツールです。
- 他の開発者にも同様のアプローチを採用することを推奨します。
- 「逆仙（Reverse Centaur）」からの脱却:
- エージェントに依存しすぎる状態では注意力が散漫になりがちです。
- コードを「読み承認する」だけでは所有感が生まれず、スロープは検知できません。
- 人間が実動手（Hands-on）アプローチを取り、方針決定を行うことで、エージェントはそれをパターン化して大量生産できます。
- 思考と審美性の保持:
- エージェントは「インターンの軍隊」であり、完全なコンパイラではありません。
- 部分的で不完全なコードを処理し、不正確な説明から正しく変化を生成させる必要があります。
- 人間が思考の主導権と審美性を握り続ける限り、エージェントを適切に運用できます。
4. エージェントの限界と改善事例
エージェントは現状維持バイアスを持ちやすく、一時的な悪癖が固化するリスクがあります。
- 具体例:
- 人間の誤判断（例：ローカルストレージの使用）を、エージェントは「保守的」に正解とみなして拡大再生産します。
- その結果、必要なラッピングや間接化によりコード行数（LOC）が膨らみ、複雑化しました。
- 解決策:
- 既存コードを取り払い、英語ベースでの代理思考よりもコードを通じて直接探索・設計を行う方が優れたアーキテクチャへ至れます。
- このプロセスにおいて、思考力と作者性は大幅に増幅されます。
5. まとめ：ソフトウェア工場への挑戦
詳細な管理こそが、ソフトウェアファクトリー成功の鍵です。
- 評価と制御: エージェントは我々に評価、計測、ガード（防御）を促します。
- サイドプロジェクトから CI（継続的インテグレーション）を初期段階で導入するなど、劇的な改善をもたらします。
- 工場の維持管理:
- 組み立てラインの弱点は存在するため、定期的な10% の向上を目指すための深挖が必要です。
- 現場の問題（例：ブレーキパッドテストの徹底的な観察）を早期に検出するために、足元まで確認する姿勢が求められます。
- 境界線の打破:
- 「触れない部分」などの恣意的な境界線を引くのは試みを妨げます。全体像を持ちながら細部とつなげる視点が不可欠です。
※追加情報: 皆様も「Cheat at Search with Agents」に参加し、エージェント活用型検索や RAG の構築、LLM を活用したクエリ理解法等を学びませんか？