ChatGPTからAIエージェントへ：エンジニアとしての2年間
2年前、私はAIを質問するためだけに利用していました。
今日は、複数のコーディングエージェントをオーケストレーションしています。MCPを通じて会社のナレッジを接続しています。iOSアプリ内でローカルモデルを実行しています。エージェントが連携できるようにメモリレイヤーを維持しています。
私はAIの研究者ではありません。実験を繰り返してきた、ごく普通のエンジニアです。
チャットからエージェントへの私の歩みをご紹介します。
ステージ1：信頼性のギャップ 最初は、AIは魔法のように感じられました。しかし、その後、信頼できないものだと感じるようになりました。 モデルはしばしば、高い自信を持って誤った情報を提示します。 私は手痛い教訓を学びました。「もっともらしい回答が、信頼できる結果とは限らない」ということです。
ステージ2：パートナーとしてのAI Cursorのようなツールがすべてを変えました。 AIは独立したチャットウィンドウから、コードエディタの中へと移動しました。 フィードバックループは驚異的に短くなりました： • アイデアを説明する。 • コードを生成する。 • 実行し、失敗を観察する。 • 修正を依頼する。 • 繰り返す。
これにより、プロトタイプ構築のコストが下がりました。小さなアイデアがセットアップや設定の段階で潰れることはなくなりました。それらは実際に完成まで辿り着けるようになったのです。
「コンテキストこそが鍵である」ことを学んだ 初期の頃、エージェントは決定事項を忘れたり、アーキテクチャを壊したりすることがありました。 私は「プロンプトエンジニアリング」に注力するのをやめ、「コンテキストエンジニアリング」を始めました。 エージェントに対して厳格なルールを書き始めました： • 既存のアーキテクチャに従うこと。 • コードを変更する前に計画を説明すること。 • 確認なしにファイルを削除しないこと。
私たちは単に、より良い文章を書いているのではありませんでした。確率的なシステムに対して、安定した環境を構築していたのです。
ステージ3：チャットウィンドウを超えて 私はウェブチャットから、APIやローカルモデルへと移行しました。 デスクトップでモデルを動かすのは簡単です。しかし、モバイルアプリ内にモデルを組み込むのは困難です。 突然、私は現実的なエンジニアリングの問題を解決しなければならなくなりました： • モデルのサイズとメモリ使用量。 • 起動レイテンシ。 • オフライン実行とデバイスの互換性。
ステージ4：エージェント主導のワークフロー 焦点は「この関数を書いて」から「このリポジトリを理解して、この目標を達成して」へと移りました。 また、Model Context Protocol (MCP) も使い始めました。 自
𝗠𝘆 𝗕𝗶𝗴𝗴𝗲𝘀𝘁 𝗟𝗲𝘀𝘀𝗼𝗻𝘀: • Coding is easier, but engineering is harder. • AI handles implementation, but you must handle judgment. • You need to define goals precisely and validate assumptions. • Multi-agent work requires a memory layer so agents can hand off tasks without restarting.
AI makes implementation cheap. This means experimentation is now free. The real work is deciding which ideas are actually worth building.
Optional learning community: https://t.me/GyaanSetuAi