「誰かがMiroボードを開いた」

それで我々がトラブルに陥ったとわかった。

図が嫌いだからではない。

私は図が好きだ。

嫌いなのは、誰かがMiroボードを開いたその後に通常起こることだ。

ボックスが現れる。

次に矢印。

さらにボックス。

すると誰かが言う。

「Requirements Agentがあったらどうだろう？」

別の誰かが頷く。

「それをArchitecture Agentに繋げば？」

「次にCoding Agentと話す」

「そしてTesting Agentに引き渡す」

「ああ！Documentation Agentも必要だ」

「PR Review Agentも忘れるな」

この時点で、AIエンジニアリング部門を偶然雇ったことになる。

面白いのは？

元々の問題はまだ解決していない。

記憶を作る前に中間管理職を作ってしまった

現在のAIツール環境で興味深いのは、誰もが専門家を設計することに夢中になっている点だ。

すべてのプロンプトに役職がある。

すべてのワークフローに別のエージェントがある。

新しい機能には必ず図に別のボックスが必要だとされる。

一方で、哀れなモデルは毎回会話を始めるとこう尋ねる。

「コーディングガイドラインはどこですか？」

またもや。

平均的なバックエンドタスクはそれほど刺激的ではない

正直に言おう。

私たちの多くは、昼食前に新しい合意形成アルゴリズムを発明しているわけではない。

私たちの作業はだいたいこんな感じだ。

  • Jiraチケットを読む。
  • ビジネスが実際何を意図していたのかを理解する。
  • 関連するコードを探す。
  • 3年前に誰かが下したアーキテクチャ決定を壊していないか確認する。
  • 機能を実装する。
  • テストを書く。
  • PRを開く。
  • 誰かが「読みやすい」と言う理由で変数名を1つ変える。

難しいのはJava（またはPython、C#、TypeScript、Rust…あるいは神よ、Visual Basic）を入力することではない。コンテキストを再構築することだ。

毎回。

おめでとうございます、ジュニア開発者を再現しました

新しいチャットはいつも同じように始まる。

「Confluenceを取ってくれますか？」

「Jiraを開けますか？」

「ガイドラインはどこですか？」

「これに関するADRはありますか？」

やがてAIは、ソフトウェアを書く手助けをするよりもMCPサーバーと話す時間の方が長くなる。

おめでとうございます。

あなたは入社1週目のジュニア開発者を再現した。

ただし、ジュニア開発者と違って…

…毎朝その記憶を消去する。

ドキュメントはランタイム依存であってはならない

これが私にとって最大の考え方の変化だった。

Jiraは…まあまあだ。

Confluenceも…そこにある。

人間にとっては。

しかし、実装のたびにAIがJiraチケットやConfluenceページ、ランダムなドキュメントを継続的に取得する必要があるなら…

…あなたのドキュメントはランタイム依存になった。

AIが繰り返し必要とするものは、単にナレッジベースに存在するべきだ。

コーディング基準。

アーキテクチャ決定。

ビジネス用語。

レビューの期待値。

一般的な実装パターン。

「金曜の午後4時以降は、このクエリに触れないでください」というメモ。

Markdown。

Markdown。

さらにMarkdown。

Confluenceが依然として信頼できる情報源なら、素晴らしい。

同期しよう。

エクスポートしよう。

埋め込もう。

どうやってそこに到達するかは特に気にしない。

AIが1日の15回目のMCPリクエストをする代わりに、ローカルのMarkdownドキュメントを開くことだけを気にしている。

取得を減らす。

構築を増やす。

Obsidianはノートブックではない。記憶だ。

なぜ私がAIと並行してObsidianを使うのが好きなのかと聞かれる。

Markdownファイルを集めるのが楽しいからではない。

Obsidianが第二の脳になるからだ。

すべてのアーキテクチャ決定。

すべての命名規則。

すべての学んだ教訓。

すべてのビジネスの癖。

すべての「2024年に試したけど本番で火事になった」。

書き留めれば、AIは毎回の会話でそれを再発見する必要がなくなる。

退屈な部分が勝つ

ここでSuperpowersのようなツールが私にぴったり合った。

正直に言うと、「Superpowers」をSpecKitやMatt Pocockのワークフロー、または好みのオーケストレーションフレームワークに置き換えてもいい。

名前は関係ない。オーケストレーションが重要だ。

流れを想像してほしい。

1つのスキルがコンテキストを収集する。

Jiraチケットを読む。

関連するMarkdownを見つける。

ビジネス仕様を読み込む。

アーキテクチャ決定を引き出す。

類似の実装を見つける。

完了。

次のスキルが引き継ぐ。

プロジェクトガイドラインを読み込む。

アーキテクチャ制約をチェックする。

モデルに命名規則を思い出させる。

みんなが忘れがちなビジネスルールを強調する。

完了。

実装が終わる。

別のスキルが引き継ぐ。

PRの説明を生成する。

ドキュメントの更新をチェックする。

リリースノートを提案する。

欠陥を特定する。

不滅のTODOを追加する代わりに、適切な技術的負債を提起する。

チームらしいレビューコメントを生成する。

何が起こらなかったかわかるだろうか？

PR Agentを作らなかった。

Architecture Agentも作らなかった。

Documentation Agentも作らなかった。

それらは単に、互いにコンテキストを渡し合う小さな再利用可能なスキルだ。

賢い部分は個々のスキルではない。

振り付けだ。

プロンプトにLinkedInプロフィールを与えるのはやめてください

一部のプロンプトはこんな風に始まる。

あなたは25年の企業経験を持つDistinguished Principal Senior Staff Software Architectです…

友よ。コミットメッセージを書いているんだ。
落ち着け。

現代のモデルはすでに信じられないほど有能だ。

差が出るのはほとんど知性ではない。

コンテキストだ。

優れた1つの脳は、賢い20人の社員に勝る

AI支援開発の実験を重ねるにつれ、私たちは間違ったものを最適化しているとますます思うようになった。

別の専門家は必要ない。

より良い記憶が必要だ。

より良いオーケストレーションが必要だ。

最初のコード行が書かれる前に、プロジェクトの知識が利用可能である必要がある。

皮肉なことに、それが人間の開発者を生産的にするものだ。

知識。

コンテキスト。

共有された慣習。

役職ではない。

別のエージェントを追加する前に…

次に誰かがMiroボードを開き、20のAIエージェントがカラフルな矢印で繋がった図を自慢げに見せてきたら…

質問を1つしよう。

「コーディングガイドラインはどこですか？」

答えがこう始まったら。

「ええと…主にConfluenceに分散していますが…」

Miroボードを閉じよう。

Obsidianを開こう。

そこから始めよう。

なぜなら、ほとんどのバックエンドチームは別のAI社員を必要としないからだ。

第二の脳と、うまくオーケストレーションされた少数のスキルが必要なのだ。

それ以外はすべて、ただの中間管理職だ。