Мой подход к вайбкодингу: сохранять контекст работы, отделять черновик от публикации и давать человеку контроль над изменениями. На примере таблиц, редакторов, поиска и медиа.
Содержание 9
Я использую AI в разработке бизнес-систем: от постановки задачи и архитектуры до кода и проверки пользовательских сценариев. Поэтому для меня вопрос качества интерфейса начинается с очень практичной вещи: сможет ли человек спокойно выполнить свою работу и понять, что получилось.
Сотрудник открывает каталог, находит запись, сравнивает варианты, меняет цену, добавляет фотографии, согласует текст. В этом процессе интерфейс должен сохранять его контекст, объяснять состояние данных и давать возможность исправить ошибку. Именно такого поведения я добиваюсь, когда разрабатываю с AI.
Свое видение я оформил в открытый раздел «Интерфейс»: 30 правил для административных систем. В нем есть примеры, проверки и отдельные роли человека и агента. Здесь объясню логику, которая связывает эти правила.
Сначала рабочий сценарий
Перед тем как просить агента собрать экран, я формулирую задачу пользователя. Какие записи он сравнивает? Что меняет часто? Что должно произойти после сохранения? Куда он вернется из карточки? Как узнает о сбое?
Для товаров, услуг, статей, заказов и документов часто подходит таблица: одинаковые свойства можно сравнить на одной линии. Для расписания нужен календарь, для этапов работы — канбан, для визуального выбора могут подойти карточки. Формат определяется действием человека.
Мне важны читаемый шрифт, ясная иерархия и достаточное место для содержимого. Крупный заголовок или декоративная панель должны помогать текущей задаче. В рабочей системе человек быстро привыкает к оформлению и каждый день замечает, сколько лишних действий ему приходится делать.
Список должен помнить, над чем я работаю
В хорошей таблице можно настроить столбцы, ширину и порядок, закрепить важное, отсортировать всю найденную выборку. Пользователь не должен получать другую картину только потому, что следующая порция строк еще не загрузилась.
Я хочу открыть запись из строки, поправить ее и вернуться на то же место — с прежним запросом, сортировкой и выбранными столбцами. Название остается обычной ссылкой: его можно открыть в новой вкладке и передать коллеге. Вложенная кнопка, чекбокс или выделение текста выполняют свое действие и не открывают запись заодно.
Массовая работа тоже должна быть явной: чекбоксы, выделение диапазона через Shift, количество выбранных записей и панель доступных действий. «Выбраны 30 загруженных строк» и «выбраны все 1200 результатов» — разные операции. Если из десяти изменений сохранились восемь, интерфейс должен показать две конкретные ошибки и дать повторить их.
Для длинных списков я использую постепенную загрузку с сохранением позиции. При сбое остается возможность повторить запрос. Перетаскивание помогает менять ручной порядок, а кнопки и клавиатура дают альтернативный способ.
Поиск должен понимать запрос и сохранять его смысл
Мне близок поиск, которому можно написать «туры на Камчатку до 50000». Интерфейс должен показать, какие условия он понял, и позволить их уточнить. Если система исправляет опечатку или расширяет поиск, верхняя граница цены остается верхней границей. Валюта и даты тоже не должны исчезать из условий. Неоднозначность нужно прояснять.
Разбор запроса и поисковый движок — отдельные решения. В крупном каталоге может подойти OpenSearch, в другом проекте достаточно PostgreSQL. Технологию я выбираю под данные и нагрузку.
Отдельное правило — поведение при отказе. Если индекс недоступен, сообщение «Ничего не найдено» вводит человека в заблуждение. Нужен резервный поиск с теми же правами и точными условиями либо понятная ошибка с повтором. Это часть качества интерфейса, хотя значительная часть реализации находится на сервере.
Скорость измеряется готовностью к работе
Когда человек открывает запись, основные поля должны появиться и стать доступными, пока галерея или тяжелый редактор загружаются отдельно. Я оцениваю момент, когда можно начать работу, и проверяю обычные переходы: список → запись → назад.
Загрузка, обновление, пустая база, отсутствие результатов, отказ доступа и ошибка сервера требуют разных сообщений. Временная проблема не должна стирать введенный текст или уже выбранные файлы.
В таблице мне достаточно небольшого серверного превью: в справочнике я выбрал до 50 px по большей стороне и отметку +N для остальных изображений. Так браузер не скачивает оригиналы ради маленьких картинок. Размер превью и нижняя панель массовых действий — решения моего справочника для таких сценариев; другой продукт может требовать другой компоновки.
Редактирование сохраняет черновик, публикация выпускает версию
Любое содержательное изменение я хочу автоматически сохранять в черновик: название, цену, текст, порядок изображений. Рядом должно быть понятно, идет ли сохранение, завершилось ли оно и что делать при ошибке. Простое открытие записи не должно создавать пустую правку.
В редакторе нужны прежнее и новое значения, автор и время изменения. Я должен иметь возможность отменить отдельное поле, а не восстанавливать всю запись. Если значение снова совпало с опубликованным, отметка неопубликованной правки исчезает; история при этом сохраняется.
Публикация — отдельное действие над конкретной версией. Сначала я смотрю предпросмотр, затем выпускаю изменения. Переключатель «Показывать на главной» меняет содержимое черновика и не заменяет эту границу.
При совместной работе интерфейс показывает, кто редактирует запись. Сервер проверяет актуальность версии при сохранении: чужая правка не должна молча исчезнуть. Это одинаково важно для двух сотрудников и для пары «человек и AI-агент».
AI готовит проверяемое изменение
Работу агента с содержимым я представляю так: он готовит черновик, показывает разницу и объясняет, что изменил. Человек может исключить отдельные правки, посмотреть результат и опубликовать проверенную версию. Если после проверки появились новые изменения, требуется новая проверка.
Права агента проверяются на сервере. Скрытая кнопка в браузере не является ограничением доступа. Агент должен действовать в понятных границах и оставлять историю, по которой можно разобраться в результате.
В разработке я применяю тот же подход: задаю агенту контекст, правила и критерии приемки, затем проверяю изменения и реальные сценарии. Ответственность за архитектуру, решение и выпуск остается у меня. Возможность быстро получить код делает качество постановки задачи и проверки особенно важным.
Медиа — полноценная часть редактора
Фотографию должно быть удобно добавить привычным способом: выбрать несколько файлов, перетащить их, вставить из буфера или указать прямую ссылку. Для каждого файла нужны прогресс, отмена и повтор. Текст, вставленный в описание, остается текстом.
В галерее пользователь меняет порядок превью, а подписи и свойства остаются связаны со своими файлами. Обложка выбирается явно. Публичная подпись, описание и альтернативный текст решают разные задачи; имя файла не заменяет их.
Удаление изображения из одной подборки не должно уничтожать файл во всех записях. Кадрирование, поворот и замена, когда они нужны продукту, проходят через черновик и предпросмотр. Медиаредактор должен соблюдать те же правила сохранения и публикации, что и обычные поля.
Проверка проходит по реальной цепочке действий
Для приемки мне полезнее пройти рабочий сценарий целиком: найти запись → открыть → изменить → дождаться сохранения → посмотреть предпросмотр → опубликовать → проверить результат → вернуться в список. Затем повторить важные шаги на узком экране, с клавиатуры и при ошибке загрузки.
Проверяю и неприятные случаи: второй редактор изменил запись, сохранение прервалось, одна фотография не загрузилась, массовая операция выполнилась частично. Пользователь должен понимать состояние работы и иметь следующий доступный шаг.
Описанное правило еще нужно реализовать и проверить в конкретном проекте. Наличие его в справочнике само по себе не подтверждает, что все проверки автоматизированы или что любой мой проект уже полностью ему соответствует.
Правила должны быть доступны следующему разработчику
Я оформляю этот подход в открытом репозитории vibecoding-base. Правила можно прочитать, обсудить, выгрузить в Markdown и использовать как контекст для людей и AI-агентов. В справочнике отдельно указаны область применения, способы проверки и роли участников.
Для меня это часть передачи проекта. Следующий разработчик должен понимать, почему интерфейс работает именно так, где проходит граница публикации и какой сценарий нужно сохранить при изменении кода. Общие правила помогают продолжать работу другой командой.
Мой подход к вайбкодингу складывается из этой связки: ясная задача, открытые правила, быстрые итерации с AI и проверяемый результат. Качество интерфейса я оцениваю по тому, сколько контроля и ясности он дает человеку в повседневной работе.
Загружаем комментарии…