チャット・エディタ・ターミナルの3つの窓 — 初日に見る場所と、まだ見なくていい場所

初めて Antigravity を開いたとき、画面にはいくつもの領域が並んでいて、どこを見ればいいのか分からず、しばらく手が止まりました。コードを読み慣れた方でも、最初の数分は似た感覚になるのではないかと思います。

私の場合、いちばん長く見つめていたのは、ファイルが開いているエディタでした。ところがエージェントに作業を頼んでみると、本当に目を向けるべき場所は別にありました。エディタをじっと見ていても、何も起きないのです。

この記事は、コードを書かない方が最初の1週間で「見る場所」と「まだ見なくていい場所」を決めるための覚え書きです。

3つの窓を役割で分けてみる

画面の構成はバージョンによって少しずつ変わりますので、細かい配置よりも「役割」で覚えるほうが長持ちします。

この表の中心は、右端の列です。3つの窓を「同じ重さで」見ようとすると、情報が多すぎて疲れてしまいます。初日は、チャットを主役に、残り2つを脇役に置きます。

初日に見るのは「計画」と「差分」の2つだけ

エージェントに依頼を出すと、多くの場合、先に何をするかの計画が会話に出てきます。ここを読むのが、最初の習慣です。

読むときの観点は、次の2つに絞ります。

1. 触ろうとしているファイルは、自分が頼んだ範囲に収まっているか
2. 「削除」「上書き」「インストール」のような言葉が混ざっていないか

作業が終わると、エディタに変更の差分が出ます。ここで初めてエディタを開き、赤（消えた行）と緑（増えた行）の量を眺めます。中身を理解できなくても構いません。頼んだ内容に対して、変更の量が釣り合っているかどうかを見ます。

一行直してほしいと頼んだのに、画面いっぱいに色がついている——そのときは、承認する前に会話へ戻って「なぜこんなに多く変わったのですか」と尋ねます。

内蔵ターミナルは「打つ窓」ではなく「読む窓」

ターミナルは、黒い画面に文字が流れるので、最初は身構えてしまう場所です。私もそうでした。

ただ、エージェントに任せている間は、こちらがターミナルに何かを打ち込む場面はほとんどありません。役割は、エージェントが実行したコマンドと、その結果が並ぶ「作業の記録帳」です。

読むときは、行頭の言葉だけ追えば十分です。

npm install        ← 部品を入れている
npm run build      ← 完成品を組み立てている
rm -rf dist        ← 古い完成品を消している
git push           ← 外の世界へ送っている

意味が分からない行は、そのままエージェントに聞きます。聞き方を型にしておくと、迷いません。

Before（依頼だけ出す）

README.md の誤字を直してください。

After（確認の約束を添える）

README.md の誤字だけを直してください。
直す前に、変更する予定の箇所を一覧にして見せてください。
ターミナルのコマンドを実行する前に、何をするコマンドかを日本語で一言説明してください。

なぜこう書くのかというと、エージェントの手が動く前に、計画と説明を会話の中へ引き出しておきたいからです。後から巻き戻すより、動く前に確かめるほうが、はるかに楽です。

承認ボタンを押す指が、先に動いていました

ここで、私の失敗をひとつ書き残します。

使い始めて間もない頃、コマンドの実行許可を求める表示が出るたびに、内容を読まないまま承認を押していました。画面が止まるのが落ち着かず、早く先へ進めたかったのだと思います。結果は芳しくありませんでした。何が変わったのかを後から説明できず、元に戻したくなったときに、手がかりが何も残っていなかったのです。

いまは、承認の前に一つだけ確かめるようにしています。

押す前に、何が変わるのかを一文で言えること。

一文で言えないときは、押しません。会話に戻って、エージェントに説明を頼みます。この線引きだけは、急いでいる日ほど守るようにしています。

最初の30分の動かし方

最後に、初日の流れを短くまとめます。

1. 触ってよいフォルダを一つだけ決めて、開く
2. 小さな依頼を一つ出す（誤字の修正、説明文の整理など）
3. チャットに出た計画を読む
4. 差分が出たら、エディタで量だけ眺める
5. ターミナルは、実行されたコマンドの行頭だけ読む

ターミナルへの直接入力や、エディタでの手書きの修正は、慣れてから足せば十分です。

まずは小さな依頼を一つ出して、計画を読むところから始めてみてください。私も、そこから始めました。