Журнал · 2026-07-19 · 1 хв читання
Чому «зроби схоже на це» не виживає в AI coding-агента
Скріншот — не специфікація. Що потрібно, щоб перетворити дизайн-намір на те, за що агента можна спитати — і що можна виміряти після рендеру.
Ви вставляєте референс, кажете «як тут, але наше» — і агент упевнено видає щось приблизне. Відступи попливли, шкала типографіки винайдена заново, радіус змінився без причини. Нічого не впало з помилкою. Інструкція ніколи не була контрактом — це був настрій, а настрій не перевіриш.
Дві поломки під цим
Перша: намір лишається невисловленим — які частини референсу ви хотіли, які потрапили випадково, а що у вашому власному проєкті рухати не можна. Друга: після рендеру ніхто не дивиться. Дифф рев'ювиться як код, а відрендерений результат не рев'ювиться взагалі — тож візуальна регресія їде в продакшн із зеленою збіркою.
Що перетворює намір на контракт
- Назвати рішення, а не скріншот: це запозичуємо, це лишаємо, решту фіксуємо
- Дати людині затвердити кожен пункт, перш ніж агент отримає право діяти
- Версіювати контракт як файл у гілці, щоб він рев'ювився як код
- Виміряти відрендерену сторінку за кожним затвердженим пунктом — і повернути unknown там, де виміряти не вдалося
Саме останнє зазвичай пропускають. Перевірка, яка не змогла виміряти пункт, має два варіанти: вгадати або сказати про це. Вгадування дає зелений результат, який нічого не означає. RefKit повертає unknown, бо проходження, якому не можна вірити, гірше за відсутність проходження.
Це той самий патерн, до якого я приходжу з будь-якого боку: модель виробляє, людина авторизує, а результат має бути доказовим потім. Дизайн — просто те місце, де цей розрив видно найлегше.