Сейчас всё чаще всплывает тема доверия к решениям ИИ-агентов. Насколько они компетентны, понимают ли задачу и можно ли полагаться на то, что они предлагают.
Для меня этот вопрос постепенно превратился в другой: как организовать работу, чтобы понимать, где я действительно проверил результат, а где просто согласился с подходящим вариантом.
Очень хочется просто согласиться
В мемах работа с агентом обычно выглядит так: ты ставишь задачу, он куда-то уходит, некоторое время «думает», а потом возвращается с ответом, написанным научным и непонятным языком. Предлагает два варианта, один помечает как рекомендованный. Ты его и выбираешь.
Потому что уже обленился и привык к скорости, с которой всё происходит. А чтобы по-настоящему разобраться в предложенном решении, пришлось бы потратить сорок лет. И ты просто соглашаешься, рассчитывая, что агент, скорее всего, не сделает ничего сильно плохого. Такая как бы «рулетка»: ты ставишь на то, что система не ошибётся настолько, чтобы последствия стали необратимыми, хотя сам уже не способен проверить, что именно она делает.
А потом появляется результат, и с ним уже гораздо проще работать. Перед тобой конкретная вещь: можно посмотреть, что получилось, дать обратную связь и попросить исправить то, что не устраивает. Иногда только в этот момент и начинаешь понимать, какое решение тебе вообще было нужно.
Поэтому мне стало интересно разобраться в самом процессе. Что агент должен узнать до начала работы, какие решения может принимать сам, где мне нужно вмешаться и как измеримо повысить шансы на получение нужного и качественного результата с меньшим количеством попыток.
Агент значительно ускоряет работу, если у тебя уже есть свой практический опыт
Когда я впервые проектировал сценарий создания кошелька несколько лет назад, я ещё не представлял, сколько времени уйдёт на то, чтобы во всём разобраться и собрать решение. Это была нетривиальная задача, связанная не только с реализацией самого сценария, но и с пониманием криптографии, принципов работы блокчейна, различных состояний и гораздо более высокого уровня ответственности перед пользователем. Нужно было учитывать, как устроено хранение и восстановление доступа, какие риски возникают на каждом шаге и что именно пользователь должен понимать и подтверждать.
Теперь агент выполняет эту задачу по голосовому запросу. Кроме того, я отдельно попросил его добавить во флоу регистрации состояния, в которых необходимо учитывать специфику работы passcode. Агент справился отлично, и это меня не задело и не встревожило — наоборот, я почувствовал облегчение: только что сэкономил себе много времени и заметил важные детали, которые даже при наличии опыта мог бы упустить.
Когда ты сам разбираешься в задаче, польза от агента особенно заметна. У тебя уже есть опыт, ты можешь оценить решение, заметить ошибку, понять, чего не хватает. В такой работе агент очень сильно тебя ускоряет.
Но этот опыт нужен и для проверки того, что агент считает законченной работой. Например, агент может хорошо разобраться в технической части задачи: понять, как работает конкретный инструмент или библиотека, правильно собрать отдельные экраны и даже описать результат. Но при этом он может плохо понимать динамику интерфейса: как пользователь переходит с одного экрана на другой, как связаны разные user flow и какие логические переходы должны происходить между состояниями.
Если просто передать такой результат дальше в вёрстку, итог может получиться очень печальным — и часто он действительно будет похож именно на результат генерации ИИ. Без практического опыта легко пропустить, что экраны не связаны между собой, переходы нелогичны, а сценарий пользователя разваливается. Поэтому опыт нужен не только для постановки задачи, но и для проверки результата: чтобы увидеть такие ошибки, скорректировать агента и направить его в нужную сторону.
Но агент помогает и с задачами, которых я раньше не решал
У меня был и другой случай. Мы работали над программой лояльности для финансового сервиса. Нужно было придумать уровни доступа и распределить между ними лимиты. Я никогда раньше такого не делал.
Можно было пойти изучать, как это устроено в других продуктах, искать примеры и постепенно разбираться самому. Вместо этого я поручил исследование агенту. Он нашёл, как это работает у крупного конкурента, собрал информацию и предложил продуктовую логику и интерфейс. Разложил, что доступно на каждом уровне и в какой момент появляются ограничения. Часть этих вещей я сам даже не догадался бы пойти искать.
Результат меня устроил. Оценить все нюансы на основе собственного опыта именно в таких задачах я не мог. Но у меня оставался общий опыт в дизайне и продуктах, чтобы прочитать предложенное, разобраться в логике и понять, насколько решение выглядит реалистичным и адекватным.
Если бы я поручил эту задачу другому дизайнеру, всё происходило бы примерно так же. Вряд ли после его презентации я пошёл бы заново проводить собственное исследование: смотреть те же продукты, выяснять, какие там уровни и лимиты, повторять всю проделанную работу. Я бы посмотрел, что он принёс, постарался понять ход мысли и оценил, можно ли с этим двигаться дальше.
С агентом получилось именно так. Я не стал специалистом в программах лояльности, но получил решение, которое мог рассмотреть и принять.
Оно вполне могло быть неидеальным в каких-то деталях. Но иногда важнее довести задачу до запуска и получить более объективную обратную связь, чем продолжать разбираться в поисках полной уверенности.
В такой момент я могу сказать: I can live with it. И мы едем дальше.
Проверять проще, когда есть что попробовать
В одном из экспериментов агент предложил довольно странные варианты интерфейса. Готовым решением я бы их не назвал, но отдельные идеи вполне могли стать отправной точкой. Смотришь и понимаешь: здесь слишком перемудрил, здесь не работает поведение, а вот в этой детали что-то есть. Даже неудачный концепт помогает сдвинуться с места: уже можно объяснить, что стоит изменить и что попробовать дальше.
Когда появляется интересное направление, хочется проверить, как всё это будет работать в руках пользователя. Раньше привычной рутиной для дизайнера было нарисовать макет в Figma, связать экраны нитями прототипа и отправиться тестировать его с партнёрами или клиентами.
Сейчас можно попросить агента собрать интерактивный прототип. Для участника тестирования он будет неотличим от новой версии продукта, хотя на деле это может быть всего несколько HTML-экранов, связанных между собой. Пользователь взаимодействует с интерфейсом, проходит сценарий, сталкивается с разными состояниями. Это позволяет проверять более сложные сценарии и меньше подстраивать само тестирование под возможности прототипа в Figma.
После такой проверки становится понятнее, что нужно изменить. Можно доработать решение и попробовать снова. В этих итерациях я сохраняю историю изменений в Git: пару раз мне действительно приходилось возвращаться к предыдущей версии. История полезна и самому агенту. Если он потерял часть контекста, можно посмотреть, что менялось раньше и откуда взялось текущее решение.
Мне в целом проще оценивать конкретное решение. Поэтому я стараюсь быстрее получать что-то, с чем можно взаимодействовать, и уже на этом разбираться, что получилось и что делать дальше.
Агенту нужно объяснить, как ты работаешь
Я начинал разбираться в агентах с обычных разговоров. Спрашивал, что они умеют, как что-то устроено, можно ли сделать вот так и что для этого потребуется. Постепенно из этих разговоров складывалось понимание, как мне удобнее с ними работать.
Например, я разделяю проекты. У каждого своя папка, свои материалы, правила и история решений. Рабочий продукт живёт отдельно от личного проекта. Мне важно, чтобы агент понимал, с чем мы сейчас работаем, и не тащил сюда договорённости из другой задачи.
Перед дизайном тоже приходится собирать контекст. Что мы делаем, для кого, какую проблему решаем, какие есть ограничения. Я использую скиллы, которые помогают агенту задавать уточняющие вопросы. Если вижу, что мы слишком быстро со всем согласились, отдельно прошу его пройтись по нашим решениям и поискать слабые места.
С референсами похожая история. Я собираю примеры, близкие по задаче и стилю, и даю агенту доступ к ним. Но наличие папки ещё не значит, что он её посмотрит. Поэтому в правилах появляется конкретное требование: прежде чем рисовать, выяснить, есть ли референсы, и изучить их.
С дизайн-системой то же самое. Если она существует, я хочу, чтобы агент сначала разобрался, какие компоненты в ней есть и как они используются. Иначе он может начать собирать всё заново или копировать куски соседнего экрана, хотя нужное решение уже лежит в библиотеке.
Ошибки постепенно превращаются в правила
Конечно, агенты меня разочаровывают. И довольно часто. Почти всегда это происходит, когда нужно придумать что-то новое. С доработкой задачи или улучшением существующего решения у меня таких проблем меньше.
Ошибки обычно знакомые, как у junior-дизайнера. Агент упускает, как экраны должны работать вместе, не думает о системе целиком, забывает, какую задачу мы вообще решаем. То самое, что пишешь джуну в performance review первые три года.
Бывают и совсем конкретные вещи. Например, вместо нормального расстояния между элементами агент вставляет пустой фрейм, который работает как распорка. Я объясняю, почему так делать не нужно, и прошу сохранить это правило.
Или задача заняла подозрительно много времени. Я спрашиваю, что происходило, и агент объясняет, что сделал множество отдельных вызовов там, где можно было обойтись одной общей операцией. Мы разбираем это и тоже фиксируем.
Так и появились мои скиллы. Они постепенно собирались из реальных задач, ошибок и удачных решений. Сначала мы работали над проектом, потом я просил разобрать накопленный опыт и оформить его так, чтобы использовать в следующем.
Поэтому фраза «агента можно научить одним файлом» для меня вполне практическая. Только этот файл не появляется сам по себе. Сначала нужно поработать, понять, что не получается, объяснить, как должно быть, и проверить следующую попытку.
Иногда после сессии я прямо прошу агента посмотреть, где он ошибался и что стоит добавить в правила. Но эти предложения тоже приходится читать. Он может начать обобщать слишком частный случай или написать гораздо больше инструкций, чем нужно.
В отличие от того же junior-дизайнера, которому нужно дать обратную связь, подождать неделю, пока он внесёт правки, а затем, возможно, снова вернуться к обсуждению ошибок, здесь следующая попытка занимает до десяти минут. Ты сразу видишь результат и понимаешь, помогло объяснение или нет.
Чтобы можно было чаще говорить «да, давай»
Мне как раз хочется чаще соглашаться с тем, что предлагает агент. Хочется скорости, меньше объяснений и результата, который устраивает с первой попытки. В этом желании я не вижу ничего плохого. Агенты уже сейчас помогают достаточно, чтобы такой способ работы выглядел вполне достижимым.
Но сначала приходится потратить время. Разобраться, что агент должен знать до начала задачи, что может решить самостоятельно и в какой момент ему стоит вернуться ко мне с вопросом. Несколько раз получить не то, что ожидал, понять, где мы разминулись, и договориться, как работать дальше. Причём сохранить инструкцию недостаточно: нужно ещё увидеть, что в следующей задаче она действительно помогла.
Часть этого времени уходит на моё собственное обучение. Я начинаю лучше понимать, какой контекст забыл дать, где оставил слишком много места для догадок и какие решения пока рано полностью отдавать агенту. А у него появляются сохранённые правила и примеры, на которые можно опереться. В следующей задаче мы уже не начинаем знакомство заново.
Вот ради этого мне и интересно выстраивать весь процесс. Время, которое я сейчас трачу на объяснения и исправления, должно помогать и в следующих задачах. Чтобы мне реже приходилось повторять одно и то же, а агент чаще предлагал то, что нужно.
Тогда за быстрым «да, давай» уже будет стоять опыт совместной работы: я понимаю, что агент учёл, мы уже разобрали типичные ошибки, и у меня есть основания ожидать подходящего результата. Именно к такой скорости мне хочется прийти.