開発者の84%がAIコーディングツールを使用しています。本番環境に投入されたコードのうち41%はAIによって生成されたものです。コード生成、テスト作成、PRレビューといった下流の作業は、とにかく速く進みました。
一方で、上流のレイヤーはまったく動きませんでした。
IDCの2024年の調査では、エンジニアは実際のアプリケーション開発に費やす時間がわずか16%にとどまることが分かりました。残りは運用タスク、CI/CD、セキュリティ、そして調整に使われています。
Microsoft Researchは、その近接領域で興味深いことを見つけました。開発者は、システムのアーキテクチャ設計やデザインにもっと時間を使いたいと考えています。しかし一貫してそれができません。なぜなら、その作業が、ほんの少数の人が持つ“部族的な知識”に依存しているからです。
この問題の中心にあるのが、Jiraチケットです。
プロダクトマネージャーがエピックを作成します。2文、曖昧な受け入れ基準、場合によってはFigmaのリンク。そのチケットが、下流のワークフロー全体に対する入力になります。
人間のワークフローでは、文脈の抜けは会話によって埋められます。開発者が立ち歩いてシニアエンジニアにチケットの意味を尋ね、サービスの境界を明確にし、そのまま進めていきます。
AIコーディングエージェントは、立ち歩いて尋ねることはできません。
What a thin ticket costs downstream
エージェントは「決済サービスにリトライ処理を追加する」と書かれたチケットを受け取ります。すると、それがコンパイルできユニットテストも通るリトライ実装を生成します。
その後、PRレビューが行われます。
シニアエンジニアが差分を読み、問題を見つけます。そのサービスにすでに適用されているサーキットブレーカーのパターンと、リトライロジックが衝突しているのです。さらに、リトライの間隔が、下流の2つのコンシューマーで設定されているタイムアウト設定とぶつかります。
もっと悪いことに、決済サービスはイベントをキューへ公開しており、他の3つのサービスがそれを購読しています。リトライの挙動によって、重複イベントが生成されますが、これらのコンシューマーはいずれもそれに対して冪等性を持っていません。
手直しの時間は、元の実装よりも長くかかります。
開発者の時間配分に関する研究は、このパターンを裏付けています。エンジニアは、新しいコードを書くよりも、既存コードを読み理解することに大半の時間を費やします。AIは書く工程を圧縮しました。しかし理解は、依然として人間の頭の中にあります。
すべての手直しサイクルは、同じ根本原因にたどり着きます。チケットレベルでの入力が不十分であることです。
What the ticket needs to contain now
AIエージェントに渡すJiraチケットには、コーディング開始前に、シニアエンジニアが口頭で説明するであろう内容を記録する必要があります。
実コードベースに対する実現可能性の分析を行います。どのサービス、API、データフローがこの変更の影響を受けるのか。類似の機能にはどのようなパターンがあるのか。エージェントが避けるべき非推奨のアプローチは何か。どの下流コンシューマーに影響が出るのか。
この文脈は、1人か2人のアーキテクトの頭の中にあります。手作業で書き起こすには数時間かかりますが、それは同時に、チームがそのエンジニアから他の3つの機能に必要な時間でもあります。
うまくいくと私が見たアプローチの1つがBitoのJira上のAI Architectです。これは、エピックを、リポジトリ全体のナレッジグラフと、過去のJiraチケットから得られる運用履歴に照らして読み取ります。
実現可能性の分析、技術設計、影響評価、スコープの分解を実行します。そして、その出力をチケットのコメント内に、構造化された計画成果物として直接投稿します。
チケットは、2文のプロンプトから、エンジニアとコーディングエージェントの双方がすぐに行動できる、土台のある設計成果物へと変わります。
これまでその文脈作りに半日を費やしていたシニアエンジニアは、実際のサービス構成（トポロジー）に基づく最初の下書きをレビューするだけで済みます。時間の使い方は、文脈収集からアーキテクチャ判断へと移ります。
The compounding implication
AIによって生成されるコードの品質の上限は、それを引き起こしたJiraチケットによって決まります。
2文だけのチケットでは、最善の推測に基づく実装になります。実現可能性、依存関係のマッピング、スコープ化されたストーリーまで強化されたチケットは、1回目のパスでプロダクションにかなり近いところへ着地する出力を生み出します。
手直しと一発での実装の間にあるギャップは、常に文脈のギャップでした。エージェントが最初のプロンプトを受け取る前に、チケットレベルでそれを埋めることが、最もレバレッジ（費用対効果）が高いところです。
