最初の生成より、2 回目の修正の方がツールの性格が出ます。
AI app builder や coding agent の demo は、だいたい最初の画面が気持ちよく出ます。LP ができる。dashboard が出る。form もそれっぽい。ここだけ見ると、もう実装が半分終わったように見える。
でも実務でしんどいのは、そのあとです。
- navbar の余白だけ詰めたい
- chart の軸ラベルだけ変えたい
- form validation を壊さずに文言を変えたい
- mobile の card layout だけ 1 カラムにしたい
- hero image は差し替えたいが component 構造は触らせたくない
このへんを狙って直せるか。しかも、diff が読めるサイズに収まるか。
vibe coding の評価軸は、もう「生成できるか」だけでは足りないと思っています。見たいのは「指差し修正」にどれだけ耐えるかです。
「指差し修正」は prompt ではなく review comment に近い
最近の agent UI は、editor に命令を書くというより、画面の一部を選んで「ここを直して」と言う方向に寄っています。selected area、annotation、screenshot comment みたいな操作です。
これは prompt engineering というより、かなり code review に近い。
良い review comment は対象が狭いです。
この card 全体を作り直して
より、
この card の price 表示だけ、月額/年額 toggle に追従するようにして
の方がよい。
AI に投げる指示も同じで、対象が狭いほど検証しやすくなります。逆に、ふわっとした指示を出すと、agent は関係ない CSS、component 分割、routing まで触り始めることがあります。
自分なら、UI 生成後の修正依頼はこう分けます。
1. 変更対象の場所
2. 変えてよい範囲
3. 触ってほしくないもの
4. 完了条件
たとえばこうです。
PricingSection の plan card だけ直してください。
desktop は 3 columns のまま、mobile だけ 1 column にしてください。
Plan data の型、CTA の URL、billing toggle の state は変えないでください。
変更後に Playwright の pricing spec が通る状態にしてください。
これくらい狭く書くと、人間側も review しやすいです。
まず diff を小さく見る
AI が UI を直したあと、最初に見るのは画面ではなく diff でいいと思っています。
git diff --stat
git diff -- app components
ここで、navbar の修正なのに package.json や global CSS が大きく変わっていたら一回止めます。意図した修正ではない可能性が高い。
特に frontend repo では、局所修正のつもりが global override になりがちです。
/* これが増えたら警戒する */
.card {
width: 100%;
}
button {
border-radius: 9999px;
}
component 内の class を少し変えれば済むのに、global selector で全体を殴っている。AI 生成 UI ではよくあります。
見る順番はだいたいこれです。
git diff --stat
git diff -- app components
git diff -- package.json pnpm-lock.yaml
lockfile が変わっていたら、なぜ dependency が必要なのかを確認します。UI の余白修正で新しい package が入るなら、かなり怪しい。
component boundary が壊れていないか
次に見るのは component の責務です。
たとえば PricingSection の見た目修正を頼んだら、agent が Header、Footer、AppLayout まで触っていることがあります。たぶん「全体の見た目を整える」方向に解釈したのでしょう。
でも、これは実務では困ります。
変更が広がるほど rollback しづらいし、review の焦点もぼやけます。
自分なら、修正後にこういう観点で見ます。
- state の持ち主が変わっていないか
- props が急に増えていないか
- presentational component に business logic が入っていないか
- CSS の責務が component 外へ漏れていないか
- unrelated component の snapshot が変わっていないか
たとえば form の copy 変更で、validation schema まで変わっていたら危険です。
// copy だけ変えたいのに、このへんまで変わっていたら要確認
const schema = z.object({
email: z.string().email(),
plan: z.enum(["free", "pro"]),
});
「動いた」より「触るべきところだけ触った」を先に見る方が、AI 生成物の review は安定します。
screenshot で再現できる状態にする
UI の修正は、diff だけでは足りません。
人間の目で見た「なんか良い」は、次の修正で簡単に消えます。なので、少なくとも主要画面は screenshot で再現できるようにしておきたい。
pnpm test
pnpm exec playwright test
Playwright を入れている repo なら、修正対象の画面だけでも spec を作っておくと便利です。
import { expect, test } from "@playwright/test";
test("pricing cards keep mobile layout", async ({ page }) => {
await page.setViewportSize({ width: 390, height: 844 });
await page.goto("/pricing");
await expect(page.getByRole("heading", { name: "Pricing" })).toBeVisible();
await expect(page.locator("[data-testid='pricing-card']")).toHaveCount(3);
});
ここで大事なのは、完璧な visual regression 環境をいきなり作ることではありません。
「この修正は、この URL、この viewport、この selector で確認する」という足場を残すことです。agent に次の修正を頼むときも、この足場があると話が早い。
前回と同じ pricing spec が通る範囲で、CTA button の高さだけ 44px にそろえてください。
こういう依頼ができるようになります。
code 以外の asset も workflow に入れる
UI 生成で忘れがちなのが、画像や copy です。
実際の LP や dashboard では、component だけでは終わりません。dummy data、OG image、icon、hero image、empty state の copy まで一緒に動きます。
AI で作った画像を mock や LP に入れる場合も、後処理を手作業の気合いにしない方がいいです。たとえば Gemini / Google AI Studio 由来の素材を使う workflow なら、保存後の cleanup を毎回画像編集ソフトでやるのではなく、Gemini の透かしを削除するオンラインツール のような browser-local な処理を 1 step として挟む、くらいの扱いにしておくと作業が途切れにくい。
ここで言いたいのは特定ツールの話ではなく、asset も review 対象にするという話です。
- 画像の比率は崩れていないか
- alt text は入っているか
- dark mode で見えるか
- mobile で crop が変にならないか
- OG image と本文 image が混ざっていないか
code の diff だけきれいでも、asset の運用が雑だと UI は壊れます。
benchmark より「変更要求に追従できるか」
AI web app builder の評価も、だんだん「demo が動くか」から離れてきています。
SWE-WebDevBench のような評価では、requirements、architecture、production code、iterative modification、business readiness まで見る。これはかなり現場感があります。
frontend engineer が明日から見るべきなのも同じです。
最初の画面が出たかではなく、変更要求に追従できるか。
たとえば、こんな小さい要求です。
chart の tooltip だけ、currency format にしてください。
axis label と legend の配置は変えないでください。
この修正で chart component 全体を書き換える agent は怖い。逆に、formatter だけ追加して、test と screenshot を通してくる agent はかなり使いやすい。
採点表を作るなら、こういう感じになります。
生成品質: 初回 UI が要件を満たしているか
修正局所性: 指した場所だけ変わったか
diff 可読性: review できるサイズか
状態維持: state / route / validation が壊れていないか
検証可能性: test / screenshot / preview で確認できるか
rollback 容易性: revert しても周辺が壊れないか
この中で、一番見落とされやすいのは修正局所性です。
でも実務ではここが効きます。狭く直せる agent は、何度も頼める。広く壊す agent は、最初の demo がきれいでも怖くて任せにくい。
自分の最小 loop
今なら、自分は AI 生成 UI をこう回します。
# 1. 生成前の状態を確認
git status --short
# 2. 狭い指示で修正させる
# 例: PricingSection の mobile layout だけ直す
# 3. diff を見る
git diff --stat
git diff -- app components
# 4. test と browser check
pnpm test
pnpm exec playwright test
# 5. まだ広すぎるなら、そこで止める
git diff --stat
ここで違和感があれば、さらに修正を重ねるより一回戻します。
git restore app/components/PricingSection.tsx
もちろん、実際には file 単位で戻すより patch を見て判断します。ただ、rollback できる粒度で作業しておくことが大事です。
AI に任せるほど、戻せる状態を作っておく。これは地味ですが、かなり効きます。
まとめ
vibe coding の価値は、最初の魔法っぽい生成より、その後の地味な修正 loop に出ます。
良い agent UI は、書く画面ではなく直す画面で差が出る。
「この場所だけ直して」が通るか。diff は狭いか。state は壊れていないか。screenshot で再現できるか。
ここまで見て、やっと実務の道具として信用できます。
初回生成の派手さに引っ張られすぎず、狭い指示、狭い diff、再現できる検証で使える形に寄せる。今の AI frontend workflow は、そこが一番おもしろいところだと思っています。