Парадокс в том, что максимальный риск при работе с ИИ — не в его прямых ошибках. Ошибки компиляции или синтаксические ляпы агенты исправляют сами за пару итераций. Настоящая опасность — в тех компонентах решения, которые мы не предъявили как требования. Агент взял и добавил «наиболее вероятное». И это «наиболее вероятное» лишь вероятно, но не правильно.
Почему читать спекы бесполезно
ИИ генерирует с чудовищной скоростью. За одну минуту он может выдать страницу спеки, три файла кода и комментарии к ним. Читать это самому — всё равно что пытаться найти иголку в стоге сена, который растёт прямо у тебя на глазах. Ты тратишь час на вдумчивое чтение, а агент за это время успевает дописать ещё полпроекта.
Именно поэтому нужна визуализация класса bird’s-eye view. Взгляд сверху, который за пять секунд показывает, что именно собрался сделать агент. Не строки кода — а схему, граф, логику целиком. Только так можно быстро проверить: не додумал ли он чего-то лишнего, не пошёл ли по неверному пути, соответствует ли его решение вашим (возможно, невысказанным) ожиданиям.
Лень, перегрев и бессонные ночи
Самый опасный сценарий — когда ты уже на перегреве. Проект горит, дедлайн вчера, агент выдаёт решение, которое выглядит разумным. Ты киваешь, говоришь «ок, пусть будет так» и идёшь закрывать другие проблемы. А утром выясняется, что агент добавил сервис, который не нужен, использовал библиотеку с лицензией, несовместимой с вашим продуктом, или выбрал архитектуру, которая не масштабируется под реальную нагрузку.
Я через это проходил. Не раз. Визуализация — единственный способ поймать такие проблемы за пять секунд. Если поленился нарисовать — готовься к ночи исправлений. Проверено на собственной шкуре.
Исследования подтверждают: проблема не единична. В работе 2025 года «Illuminating LLM Coding Agents» исследователи из Visa Research показали, что ML-инженеры тратят огромное количество времени на то, чтобы просто понять, что именно сделал кодовый агент. Без визуализации отследить эволюцию кода, сравнить итерации и выявить проблемные места практически невозможно. Агент недетерминирован — один и тот же промпт может породить совершенно разные архитектуры.
26 диаграмм, из которых агенты знают 2–3
Хорошая новость в том, что для быстрой проверки не нужно осваивать UML или рисовать Visio. Mermaid — текстовый язык диаграмм — поддерживается практически всеми агентами «из коробки». GitHub, Claude, VS Code, Notion — везде есть рендеринг Mermaid.
Плохая новость: в Mermaid доступно 26 типов диаграмм (по разным подсчётам — от 22 до 26), но агенты сами применяют лишь 2–3: flowchart и sequenceDiagram. Всё. Остальное лежит мёртвым грузом — и в промптах, и в головах разработчиков.
Так какие диаграммы реально стоит использовать?
Первым делом — sequence diagram
Я уже отвечаю на вопрос, который задал сам себе: какую диаграмму просить у агента первой? По моему опыту — sequence diagram . Это сценарий взаимодействия. Он показывает, кто кому и что отправляет, в каком порядке, какие данные передаются. Именно здесь агент допускает самые опасные «додумывания»: добавляет лишний шаг, вводит несуществующий сервис, придумывает API, которого нет.
Sequence diagram — это рентгеновский снимок логики. Если он не совпадает с тем, что у вас в голове — стоп. Требуйте от агента объяснений.
Обязательный набор: что должен знать каждый
Из 26 типов реально нужны пять-шесть. Остальные — либо для специфических задач, либо сырые (beta-версии, которые не везде рендерятся).
Обязательно:
Бесполезный балласт для большинства разработчиков: Pie chart (проценты и так видны), Quadrant chart (приоритеты — это не про код), Timeline, Kanban (для управления задачами есть другие инструменты), Packet diagram (для сетевых протоколов — удел единиц). C4Context и Requirement diagram — вещь, но нестабильная: requirementDiagram, как отмечают в сообществе Mermaid, до сих пор не поддерживается даже в GitHub и VS Code.
Принцип: не доверяй — проверяй через картинку
Работа с агентом должна строиться по короткому циклу: дал задачу — попросил визуализировать — проверил за 30 секунд — скорректировал — пошёл дальше. Не давай агенту уходить вглубь на десять итераций, если на первой же ты не видишь, что он делает.
Современные инструменты уже идут дальше. Появляются системы вроде AgentVision, которые добавляют агентам «глаза» — они не только генерируют код, но и визуально проверяют результат, находят перегруженные элементы, ломаные макеты, ошибки в SVG. Но это следующий уровень. Пока хотя бы научитесь просить Mermaid у того агента, который уже стоит у вас в терминале.
P.S. А вы проверяете задумки ИИ визуально или доверяетесь его «наиболее вероятно»? Сколько раз это вас подводило?
Комментарии
Ирония в том, что вы предлагаете решать проблему додумывания с помощью той же самой штуки, которая додумывает
Нет, я предлагаю решать проблему «я тебе верю» тем что «покажи мне почему я должен тебе верить»
То есть вы предлагаете доверять не нейросети, а своей способности её перепроверить Тоже неплохой фокус
Своим мыслям надо доверять, да, иначе дело совсем плохо
Разбивать на подзадачи и ставить агенты верификаторы ?
Агенты верификаторы могут обходиться также как тесты
Любопытно, что агент, додумывая требования, по сути решает задачу импутации пропущенных данных - только на уровне архитектуры, а не признаков. Это похоже на то, как если бы Mermaid-диаграмму генерировали не из текста, а из среднего по всем проектам пользователя. И удивляться потом, что в схеме появился лишний сервис для логирования
Да они часто даже не так плохо додумывают. Просто один раз плохо перекрывает все хорошо)
ну ок, идея с sequence диаграммой звучит вайбово, но по факту ты просто меняешь доверие агенту на доверие своему скиллу читать схемы. а если я в 3 ночи и глаза слипаются?
Себе надо доверять, иногда.