Хорошая статья Дэниела Растона из Google «The Rise of the Orchestrated User Interface (OUI)» про подход к созданию новых типов интерфейсов, рассчитанных на использование с ИИ. Он называет их Orchestrated User Interface (OUI).

По большому счету, ИИ создает вызов в проектировании интерфейсов и всего пользовательского пути, потому что результаты не детерминированы. В традиционном интерфейсе все было предсказуемо, и можно было гарантированно пройти один и тот же путь два раза. Но с интерфейсами, которые подстраиваются под запросы пользователей, этого уже нельзя ожидать. Все интерфейсы с внедренными ИИ-инструментами движутся в сторону персонализированной выдачи и персонализированного контента.

Дэниел пишет о подходах к созданию генеративных интерфейсов. Он предлагает несколько принципов и точек зрения, которые помогут качественнее спроектировать его.

Из нового для меня, понравилась концепция порогового значения достоверности, когда система возвращает разные интерфейсы в зависимости от того, насколько она уверена в ответе. Никогда не думал в этом ключе, но идея кажется очень полезной.

1. Низкий уровень уверенности (<60%): система запрашивает у пользователя уточнения.
2. Средний уровень уверенности (60–90%): система выдаёт предварительное предложение.
3. Высокий уровень уверенности (>90%): система действует и информирует пользователя.

Остальные рекомендации и идеи, в принципе, ожидаемы и вполне вписываются в подход, о котором многие говорят и который я предлагал в докладе 2025 года, когда выступал в рамках Sreda Summer Summit. Там ключевой идеей была мысль о том, что, хотя ИИ привнес много нового, но эвристики Нильсена не устарели и вполне адаптируются под современные технологии. В докладе я, правда, оставил только четыре из них: ясный статус системы, контроль и свобода действий, предотвращение ошибок, понятность и предсказуемость интерфейса. Но этого как раз достаточно для структурирования подхода к созданию OUI.

Сегодня не про один конкретный инструмент, а про целый набор вещей, которые я делаю для учебного проекта со студентами.

Мы разрабатываем студенческий портал, и я захотел сразу сделать все с редакционной политикой и tone of voice. Но просто написать документ в стол — это не так интересно. Интересно заставить его работать и интегрировать в ИИ инструменты, чтобы помогать всем писать в едином стиле.

Для этого проекта я выбрал Qwen от Alibaba. Китайские модели сейчас остаются открытыми и доступными без VPN, и при этом они хорошо работают. Внутри Qwen настроил проект с навыками: «оценить», «отредактировать», «переписать» и загрузил туда черновик редполитики. Кстати, забавный баг, слово «политика» китайский ИИ просто не дает сохранить, пришлось писать с опечаткой.

Еще, давайте посмотрим, как я использую для работы свой старый проект AI Prompt Testing System. Этот инструмент, который я навайбкодил, чтобы сравнивать, как разные модели отвечают на одни и те же промпты. Потому что иногда одно слово меняет все. Запустил эксперимент с текстами для портала на шести моделях и получилось интересно.

Инструменты из этого выпуска

- Qwen (Alibaba) для автоматизированной работы с редполитикой через проекты (навыки) https://chat.qwen.ai/
- AI Prompt Testing System для тестирования промтов https://ai-test.podluzny.com/
- Vercel AI Gateway шлюз для подключения большого количества LLM моделей https://vercel.com/ai-gateway
- V0 для вайбкодинга https://v0.dev/
- Google Gemini для анимации SVG иллюстрации на главной странице AI Prompt Testing System https://aistudio.google.com/

Видео на Ютюбе https://youtu.be/UjJM1qj51LY

Не знаю, удивит ли вас, но недавнее исследование, опубликованное в Harvard Business Review, показывает, что ИИ не уменьшает нагрузку на сотрудника, а в перспективе это может грозить быстрым выгоранием и спадом производительности.

Результаты восьмимесячного исследования опубликованы в статье «AI Doesn’t Reduce Work—It Intensifies It».

Внедрение генеративных инструментов повышает производительность сотрудников: они работают быстрее, выполняют большее число задач в более широком круге. Берут на себя задачи, которые раньше передали бы коллегам или не брали бы вообще. Чаще начинают использовать время, которое раньше было отдыхом, чтобы выполнять какие-то задачи через ИИ. Например, перед уходом на перерыв отправляют задание агенту, чтобы, вернувшись, уже видеть результат выполненной работы.

Общение в чате с ИИ меньше напоминает работу, поэтому границы между рабочим и нерабочим пространством размываются. Люди чаще склонны в нерабочее время проверять чаты и продолжать оставаться включенными в рабочий процесс.

Появилась новая многозадачность, когда разным агентам выдаются разные задачи. И это стало возможным потому, что возникает пауза ожидания между постановкой задачи и получением результата и она воспринимается, как ресурс времени, который можно занять.

Все это складывается в новое ожидание относительно скорости выполнения задач. Многие сотрудники отмечали, что им приходится делать больше дел одновременно и испытывать большее давление, чем до внедрения ИИ.
Получается такая петля зависимостей: чем больше мы используем ИИ, тем выше скорость выполнения задач и их количество, тем шире круг задач, которые мы получаем, и тем выше ожидания скорости, с которой мы должны их выполнить. В итоге рост продуктивности выполнения задач не трансформируется в меньшую занятость.

Я помню хороший термин, который использовал один технический директор относительно программистов, — утилизация ресурсов. Он честно говорил, что задача компании в том, чтобы продать 100% времени сотрудника и чтобы сотрудник на 100% времени был занят.

Что же делать, чтобы не загнать себя, как лошадь?

В статье авторы выступают за внедрение практик, которые бы противодействовали потенциальным когнитивным перегрузкам, возникающим за счет увеличения количества выполняемых работ. Они предлагают делать запланированные перерывы, контролировать уведомления, чтобы не отвлекаться лишний раз, структурировать время работы с ИИ вместо постоянного нахождения в рабочем процессе.
Фактически речь идет о том, чтобы более активно планировать не рабочее время, а время на подумать и отдых.

Но, к сожалению, мне представляется маловероятным, что эти идеи, нацеленные на приоритет качества над количеством, и приоритет work-life баланса над валовой эффективностью, найдут поддержку в нашем бизнесе.

Некоторые команды уже месяцами не открывают Figma, чтобы делать дизайн. Например, Robin Bonduelle пишет, что они в компании перешли на прототипирование в Claude Code, а Figma осталась только источником дизайн-системы. Больше никаких макетов, только вайб-кодинг и продуктовые прототипы. И это похоже на тенденцию, потому что публикаций об этом становится все больше.

Ловушка убедительности

В этом тренде меня кое-что настораживает. ИИ-инструменты создают убедительные артефакты, и возникает впечатление, будто они заменяют процесс мышления. Недавняя статья «Which AI Tools Are Worth It for UX Designers in 2026?» добротно описывает подход с использованием ИИ на всем пути разработки дизайна продукта, но если вглядеться в отдельные артефакты, создаваемые ИИ, то везде есть недочеты, которые накапливаются и ведут к плохому результату. В итоге, все по форме выглядит убедительно, но содержание слабое.

Получается, как фрукт из папье-маше: выглядит красивым, но есть невозможно.

«Просто переделаем»

Можно возразить, что вместе с ИИ можно идти по пути быстрых изменений: быстро делаем, быстро переделываем. О таком подходе говорит Jenny Wen (leads design в Claude, а до этого директор по дизайну в Figma). Она в своем выступлении радикальна, когда заявляет, что пользовательские исследования, CJM, JTBD и т.д. — это булшит, который только отдаляет от реальных проблем пользователей. И надо сразу делать варианты решений.

Мой послужной список сильно проигрывает Дженни Вен, но посмею не согласиться в том, что нужно выбрасывать все предварительные работы. Потому что вариантов сделать что-то неправильно — бесконечно много. Правильных путей — значительно меньше. Итерация без сильной критической оценки - это быстрый путь попасть в тупик. Нужна оправданная фокусировка усилий, которая на чем-то должна стоять.

В прошлом семестре у меня было задание для студентов сделать прототип приложения программы лояльности с элементами геймификации. И студентка принесла прототип из Lovable, перенесенный в Figma. Если оценивать только внешне, задание выполнено. Но если начинать осмысленно рассматривать решение, то это не совсем связанный набор экранов. Но в чем она не права, принося такую работу? Со всех сторон транслируется, что форма важнее содержания, главное — выглядеть вменяемо. И в такой ситуации очень легко попасться в ловушку убедительности ИИ и перестать критически оценивать то, что тебе предлагается в качестве результата.

Что с этим делать

Angele Lenglemetz хорошо формулирует большую проблему продуктового дизайна в статье «When building is free, what's worth building?» https://uxdesign.cc/when-anyone-can-build-anything-6c8a0059ed0e Если немного перефразировать, то “Если стоимость разработки стремится к нулю, то что вообще стоит делать?”

ИИ дал нам возможности и скорость разработки. Но не снял ответственность за выбор, что внедрять.

Я пока не придумал, как встроить медленный процесс рациональной индивидуальной оценки в быстрый ИИ-процесс. Вариант, с перекладыванием оценки на других ИИ-агентов — это значит создавать иллюзию решений с той же пустотой внутри.

Единственное, что кажется мне устойчивым ответом на текущие вызовы, это внедрение практик совместного дизайна (participatory design). Потому что, когда воплотить идею легко, важнее всего становится умение качественно эти идеи создавать и детализировать. А это легко сделать в рамках совместной работы. По опыту преподавания и проведения Moscow Service Jam могу сказать, что практически нет людей, которые не готовы включаться в организованный процесс совместной работы. А результат и эмоциональная удовлетворенность участников такой работы всегда на высоком уровне.

Осталось связать методологию совместного дизайна с возможностями ИИ. А для этого нужно просто пробовать такие подходы. И наверняка кто-то уже пробовал и может об этом рассказать. Я же пока с этим экспериментирую в рамках студенческой дизайн-лаборатории. Кто уже пробовал системно совмещать совместный дизайн с ИИ, что сработало?

Сегодня в качестве примера вайб-кодинга выступает визуальный калькулятор, который я построил на нодах, чтобы анализировать процессы, например, юнит-экономику или бизнес-процессы. Это экспериментальный проект, который я сделал за несколько дней. При этом моим фокусом было не столько создание сервиса, сколько продолжение поиска надежного метода работы с языковыми моделями, чтобы получать предсказуемый результат в кодировании.

Все началось с простой потребности: в Miro удобно думать схемами, но невозможно считать. Хотелось соединить визуальное мышление и простую математику, так появился этот инструмент.

В видео я пытаюсь объяснить, как устроен нодовый граф и как происходит передача значений между узлами. Показываю, как работают формулы, переменные и глобальные параметры, а также как работа с контентом помогает сделать ноды понятнее.

Отдельно стоит отметить аналитические возможности инструмента. Там есть сценарный анализ, анализ чувствительности (tornado diagram) и симуляция Монте-Карло для работы с реальными данными.

Пока делал этот проект, выработал подход с постепенным дополнением функций. Текущая реализация Gemini довольно стабильно поддерживает код системы, не пытаясь удалить то, что уже сделано. Но я все равно использую внешние модели для формулировки сложных задач. Но основные идеи рождаются не в ИИ, а в процессе тестирования того, что получается. И это в очередной раз убеждает меня в полезности вайб-подхода для создания продуктов.

Для меня вайб-кодинг — это не промышленный инструмент, а способ исследования. Хотя иногда получаются вот такие вполне интересные инструменты.

Ссылка на проект
Node Flow: https://nodeflow.podluzny.com/

Инструменты, которые упоминались
- Miro
- Google Gemini
- V0
- Claude

Видео на Юьюбе https://youtu.be/YCmKlskfh_o

Мы, наверное, уже привыкли говорить о том, что корпоративная культура важна. И что хорошая культура позволяет компаниям расти быстрее конкурентов. Каждый из нас много раз слышал об этом. Эти слова всегда убедительно звучат в устах владельцев, CEO и HR-директоров. По крайней мере, до тех пор, пока кто-то из них неожиданно не скажет вам, что сегодня ваш последний день в компании.

Тем интереснее читать про случаи, когда корпоративная культура становится драйвером роста. В этом плане Anthropic — пример такой компании.
Она выросла с 2023 по 2026 год в 87 раз. И заслуга в этом не только передовых инноваций, которые представляет компания, но и корпоративной культуры.

«Компания работает на основе атмосферы, а не традиционной корпоративной структуры. Здесь нет отделов, изолированных друг от друга в обычном смысле. Нет политических войн за сферы влияния» — это я взял из статьи «Anthropic Is Running a Different Race».

Компания Anthropic не разрабатывает оперативный план на срок более 90 дней. Их максимальный цикл планирования составляет три месяца. Все остальное может поменяться. Это позволяет менять стратегический фокус быстрее, чем у некоторых компаний получится согласовать время для совещания руководства.

Каждая идея приветствуется, рассматривается и оценивается коллективом.
Claude Cowork прошел путь от первоначальной идеи до публичного запуска всего за 10 дней. От идеи до запуска!

И в основе всего этого — совместная работа и полная прозрачность. В то время как в большинстве компаний мы можем увидеть четкую иерархию, выстроенные границы и разделенную ответственность.

Можно ли это повторить?

Учитывая, что в Anthropic работают лучшие из лучших, проблемы уже начнутся на стадии подбора людей. Но еще большую проблему, думаю, будет составлять отсутствие культуры совместной работы.

В принципе, я об этом писал уже не раз, но в нашей атомизированной культуре (смотрите Карту культурных ценностей Инглхарта) сложно обеспечить совместную работу. Это возможно, все практики совместного дизайна показывают, что при правильной постановке задачи можно создать эффективно работающие группы. Но для этого нужна фасилитация и нужно поддерживать культуру, в которой такой подход в принципе возможен. Иначе все будет распадаться и возвращаться к привычным сепарированным процессам.

Но я подозреваю, что где-то и у нас есть те самые 2% команд или 0.2%, у которых интегрированы совместные практики построения работы.

Мы все вводим пароли чуть ли не каждый день и регулярно придумываем их. И смею предположить, что и для вас это, как и для меня, сплошная боль. А как человек, который уже вечность занимается UX, могу уверенно сказать, что «боль» — это просто отражение когнитивных сложностей, которые создают для нас разработчики сервисов. И часть из этих сложностей, честно говоря, просто отражение их инертности и лени.

Вообще, почему я решил написать этот пост? А потому, что, регистрируясь в кабинете «Ресо-страхование», я столкнулся с тем, что не все символы принимаются в качестве пароля. И как раз то, что я обычно использую, не прошло. К тому же сообщение об ошибке неинформативное, из него нельзя понять причину. Но это уже другая проблема, о которой Нильсен писал еще с 1994 года.

И вот если мы посмотрим на разные сервисы, то окажется, что можно встретить совершенно разные требования к паролям. Причём сейчас у больших сервисов наподобие Google, X, Amazon, VK требования могут оказаться формально более мягкими, чем у локальных магазинов или в кабинетах банков и страховых компаний. Но это скорее не из-за попытки угодить пользователям, а потому, что у этих компаний хорошо выстроены процессы контроля безопасности и их специалисты не повторяют устаревшие мантры.

Проблема устойчивости пароля к взлому в том, что интуитивно мы ошибаемся, когда считаем сложными для взлома пароли, состоящие из разных символов и знаков. Здесь возникает одна из когнитивных подмен: мы начинаем воспринимать сложность запоминания как эквивалент надёжности пароля. А это совсем не так.

Есть рекомендации NIST SP 800-63B (это специальная публикация Национального института стандартов и технологий США) о том, как следует обеспечивать безопасность. В частности, там есть современные рекомендации по паролям.

- Минимум 8 символов для паролей, а лучше больше,
- Не требовать обязательную сложность (верхний/нижний регистр, цифры, спецсимволы), потому что часто это приводит к худшим паролям,
- Проверять пароль на наличие в списках утечек,
- Разрешать длинные пароли и использование пробелов, эмодзи и т.п.

Основной фактор силы пароля — это его длина, а не набор символов. Потому что увеличение длины пароля увеличивает экспоненциально его сложность, в то время как добавление новых символов дает лишь линейный прирост.
На практике это означает, что пароль из 8 символов с большими и маленькими буквами, цифрами и спецсимволами можно взломать за пару дней. А пароль из 12 букв, состоящий только из строчных символов, придётся взламывать десятилетиями.

Интересно, что большинство случаев ограничений на символы — это не осознанное решение безопасников, а просто унаследованные настройки, которые никто не пересматривал. Иногда удобство начинается с простого вопроса: «А зачем мы вообще это требуем?»

Сейчас инструментов для создания чего-нибудь с ИИ куча, и сложно выделиться, но Omma нашли изящный способ сделать это, добавив возможность генерировать 3D-модели в лендинг. С разным успехом это, в принципе, можно было сделать и раньше, но у них модели просто чуть получше, а взаимодействие — чуть поизящнее прямо из коробки.

Я продолжаю разбирать развитие своего экспериментального проекта NodeFlow — инструмента, который я постепенно вайбкожу, проверяя, как современные ИИ-модели справляются с продуктовой разработкой в таком режиме.

За несколько дней работы проект заметно вырос. Успел сформироваться бэклог, в котором уже можно увидеть: какие задачи становятся приоритетными, какие откладываются, а какие остаются просто идеями «на потом». Это хороший момент, чтобы остановиться и посмотреть на проект со стороны, попробовать понять, куда двигаться дальше.

Одной из ключевых целей было не просто добавить новые функции, а посмотреть, как система ведет себя при росте. Насколько стабильно работает ИИ в процессе доработок, не ломается ли логика, и главное, как выстраивать взаимодействие с моделями, чтобы создавать не разовые решения, а что-то более устойчивоен устойчивое.

Все важнее становятся не технические ограничения, а умение делать выбор. Когда становится возможным реализовать почти любую функцию, главный вопрос звучит: Что действительно стоит делать в первую очередь?

Буду рад вашему фидбеку.

Используемые технологии:
- Google Gemini
- Anthropic Claude
- База данных Turso

Ссылки на проект:
- Пример файла проекта https://nodeflow.podluzny.com/p/qtDYTNgHJdmLNGDLlI1YDF5Z
- Больше примеров https://nodeflow.podluzny.com/examples

Видео на Ютюбе https://youtu.be/bKb-JqAMl4U

История релиза, что было добавлено за последние дни:

20.03
- Добавлена панель метрик.
- Обновлен фон рабочей области в режиме сценариев для более явного визуального переключения.
- Добавлено автосохранение проекта с восстановлением состояния при повторном открытии.
- Добавлено копирование нода при зажатии ALT и перетаскивании курсором.
- Добавлено сохранение в модальных окнах по ENTER и закрытие без сохранения по ESC.
- Переписаны горячие клавиши. Реализована независимость от раскладки клавиатуры.

21.03
- Добавлено сохранение проектов в облачной базе и шаринг по уникальному индексу.
- Реализована возможность делиться проектом по ссылке.
- Добавлена возможность открытия проекта по ID из облака.
- Обновлено отображение переменных с учетом размеров контейнера.
- Скорректировано отображение связей со значением “0”.

22.03
- Добавлена возможность сворачивания левой панели.
- Обновлен стиль выпадающего меню.
- Обновлен стиль Toggle Interactivity.
- Уточнено поведение системы при блокировке интерактивности.
- Добавлена защита от перезаписи проектов, сохраненных в облаке.
- Скорректирована логика переключения между режимами сценариев и редактирования.
- Добавлена поддержка различных распределений в методе Монте-Карло: равномерное, нормальное (гауссово), экспоненциальное, пуассоновское, биномиальное.

23.03
- Добавлена поддержка кастомного CSS.
- Добавлена возможность выбора нескольких целевых узлов в Монте-Карло.
- Добавлена возможность выбора нескольких целевых узлов в сценарном анализе.
- Унифицированы компоненты выбора целевых узлов.
- Добавлена визуализация диаграммы Sankey.

24.03
- Добавлен экспорт аналитики.

Уже появился первый единорог, технология которого основана на использовании ИИ-агентов. В феврале компания по бухгалтерскому сопровождению Basis привлекла 100 миллионов при оценке в 1,15 миллиарда долларов. Ее агенты делают бухгалтерскую работу от начала до конца, оставляя человеку проверку результатов. Ее инструменты уже используют треть ведущих бухгалтерских фирм США для предоставления услуг своим клиентам.

Возникает важный вопрос: как компании, основанной полностью на чужой технологии (все работает на базе моделей OpenAI), защититься от копирования и произвола со стороны поставщика ИИ-услуг?

Менять поставщиков модели — это не вариант, потому что при переходе от модели к модели будет страдать качество. Попросту один и тот же промт в разных условиях будет давать разный результат. И требуется тонкая настройка, чтобы обеспечить точность и качество. А если представить, что для обработки данных используются десятки тысяч запросов, то понятно, что настройка этого механизма может быть нетривиальной задачей.

Мне Олег Ващуков показывал, как в его системе, которая построена на работе ИИ, качество ответов меняется при смене модели. А контроль качества — это кропотливый процесс промт-инжиниринга, когда за счет набора тестов и набора промтов подбираются точные формулировки для работы ИИ.

Защитить свои позиции от произвола поставщика услуг можно хорошим договором. Но что защищает Basis от копирования технологий?

Для меня это вообще ключевой вопрос, потому что всем, кто пробовал вайбкодинг, очевидно, что любой интерфейс можно скопировать, и логику работы можно скопировать. Кажется, что даже сложность интерфейса не является преградой. Это просто вопрос количества токенов и развитости ИИ-модели. Но опыт и компетенции не копируются.

В принципе, мы возвращаемся к ситуации, когда технология в ИТ уже не является конкурентным преимуществом, а им становятся экспертиза, доверие, пользовательский сервис.

Basis не просто делает работу с помощью ИИ, она это делает на основе экспертизы ведущих бухгалтерских компаний, которым доверяют, и дает юридически подкрепленный результат.

Похоже, это пример того, куда будет идти дрейф ИТ-компаний — в сторону экспертизы и того, как компания способна ее поддерживать и транслировать, а также как она выстраивает сервисные отношения со своими клиентами. Количество рабочих рук и умение кодировать становится все меньшим преимуществом в мире, где ИИ берет на себя всю эту рутинную работу.

Начну издалека, от рекламного бизнеса и закончу оценкой влияния ИИ на доходы заказной разработки.

В прошлогодней статье Майкл Фармер оценивал, как повлияет внедрение ИИ на количество оплачиваемых часов в рекламных агентствах США https://michaelfarmer.substack.com/p/the-destructive-effect-of-ai-on-agency

Его предпосылки были просты: ИИ облегчает работу, и поэтому надо тратить меньше времени на создание любых артефактов. А раз времени тратится меньше, то и агентства будут зарабатывать меньше.

Он оценивал потери агентств в 24%, которые заберет ИИ после того, как креаторы начнут им пользоваться. Потом вышла новая статья, где автор развивал эту тему, и оценка того, сколько потеряют агентства, только росла (до 40% для медиаагентств). Вообще, статья https://michaelfarmer.substack.com/p/ai-will-decimate-agency-staffing интересная, особенно если вы занимаетесь вопросами рекламы.

Старый подход по продаже основанной на человеко- часах расшатывается. Рекламные агентства и эксперты ищут пути сохранить объемы. Фармер предлагает больше работать с точками роста продукта, бренда. Т.е. во времена, когда рутинные работы становятся автоматизированными и дешевыми, предлагать больше консалтинга.

Другие рекламные агентства меняют стратегию продажи человеко-часов на продажу комплексных решений, или подписку на эксклюзивные ИИ-решения, или оплату за результат (KPI). Но главный консенсус, кажется, в том, что бизнес, основанный на оценке работы в часах, уходит на второй план.

Теперь перейдем к заказной разработке.

Собственно, я далек от рекламы, но очень давно работаю в заказной разработке, и эта тема мне интересна и близка. Легко заметить, что кризис снижения оплачиваемых человеко-часов рекламных агентств ничем не отличается от кризиса, в который сейчас попали ИТ-компании, которые предлагали свои услуги. ИИ режет часы, которые раньше продавались.
Меня заинтересовало, на сколько часов ИИ может срезать типичный ИТ-проект.

Я выбрал один из проектов — не большой, не маленький — для которого была реальная оценка, и попробовал на него наложить то, что мы знаем об эффективности внедрения ИИ в разных профессиональных сферах при разработке чего-то цифрового.

По моей оценке получилось, что использование ИИ могло бы срезать оценку выбранного проекта на 42%. Вот мои расчеты https://nodeflow.podluzny.com/p/nT-4xCm8jCZ7OOMVamJygNeA?scenario=1
Оценка не бесспорная, да и, может, проникновение ИИ для разработчиков сейчас не самая большая проблема, но общее падение часов, которые нужно тратить, будет негативно сказываться на компаниях. И в схожих ситуациях рекламный бизнес ищет асимметричные пути сохранения своей маржинальности. Интересно, какие пути будут для себя находить ИТ-компании.

Но подозреваю, что старую собаку новым трюкам быстро не научить, и заказчики все еще будут видеть сметы построенные на оценках работ в часах.

Этот выпуск — уже третий подряд об одном и том же проекте, что само по себе неожиданность. Обычно мои эксперименты укладываются в один-два дня, но этот проект живет и развивается уже третью неделю.

Вайб-кодинг — это навык, который только формируется. Мы находимся в совершенно новой, неисследованной области, где многое познается методом проб и ошибок. Один из главных выводов, к которому я прихожу: прежде чем давать задачу модели, стоит самостоятельно провести ресерч и выбрать подходящий фреймворк, потому что решение, которое ИИ предлагает по умолчанию, далеко не всегда оказывается оптимальным.

Главная фича этой недели — табличный редактор. Нодовое представление отлично подходит для работы со связями и логикой, но когда нужно массово редактировать значения переменных, прыгать по каждому узлу неудобно. Табличный редактор решает эту проблему: он объединяет узлы, переменные и связи в нескольких таблицах, поддерживает редактирование значений и формул, быстрый поиск, работу с несколькими сценариями и сквозной нейминг.

Для раборы со сковзным неймингом создана отдельная функция. Архитектурно решение не слишком удачное, но уже сейчас при переименовании узла или переменной название автоматически обновляется везде, где оно используется. Пока это экперимент, можно использоать не самый совершенный подход.

Перед тем как внедрить табличный вид в основной проект, я запустил отдельный эксперимент в Google AI Studio, специально посвященный поиску подходящего фреймворка. С самого начала я использовал TanStack Table. Потом попробовал React Data Grid и он не подошел. Наиболее интересным оказался AG Grid, продвинутая система с большим количеством функций из коробки. Пока он не перенесен в основной проект из-за одной особенности поведения дочерних элементов при движении колонок, но эксперимент был полезным.

Второе нововведение — автокомплит для формул. Теперь при вводе формулы система подсказывает доступные названия нодов и переменных, что заметно упрощает работу.

Из не совсем удачных экспериментов — попытка добавить светлую тему. Тема в целом сгенерировалась, но из-за большого количества элементов с явно прописанными цветами переключение между светлой и темной темой работает нестабильно. Думаю, этим стоит заняться позже, когда основной функционал устоится, и нужно будет двигаться в полуавтоматическом режиме, автогенерация дает хороший старт, но финальная доводка все равно требует ручного вмешательства.

Впереди еще полный бэклог идей. В том числе планируется пересмотреть подход к аналитике, сейчас она существует отдельно от проекта, а хотелось бы, чтобы эта информация органично вписывалась в общую структуру нодов. Проект продолжает развиваться, и это по-прежнему для меня интересно.

Используемые технологии:
- AG Grid,
- React Data Grid,
- Google AI Studio,
- Google Cloud

Ссылки на проект:
- Пример файла проекта https://nodeflow.podluzny.com/p/nT-4xCm8jCZ7OOMVamJygNeA?scene=1&zoom=fit
- Больше примеров https://nodeflow.podluzny.com/examples

История релиза, что было добавлено за последние дни:

26.03
- Исправлено редактирование переменных, была ошибка интерфейса.
- При смене названия в переменных и нодах, меняется их название в формулах.
- Исправлено, чтобы при загрузке данных в режиме редактирования отображались данные из первого сценария.
- Добавлена возможность при переходе по URL передавать переменную в части GET, чтобы переходить к определенному режиму. Сейчас, передается переменная scenario, например, scenario=1 - открыть первый сценарий после загрузки файла.

28.03
- Добавлен автокомплит при редактировании формул. Используются ключевые слова, ноды, переменные.
- Исправлено создание элементов с одинаковым ID. При загрузке проверяется уникальность ID и вносятся исправления в файл. (ИИ два раз прогонял все файлы, чтобы исправить систему, более 400 запросов, более 50M токенов, но проблему с дублями внутри сохраненных файлов так и не увидел).
- Добавлено табличное представление данных.

29.03
- Изменено в табличном отображении переключение между сценариями.
- Экспорт проекта в CSV, XLSX.

... полный список не поместился

Для тех, кто любит заглянуть в потенциальное будущее, хорошо бы прочитать всеобъемлющий обзор от VML. Там 100 трендов на любой вкус. Меня лично часть из них даже немного перенапрягла. Приходится признать, что расслабленного, милого будущего не ожидается.
https://www.vml.com/insight/the-future-100-2026

ADPList выдал мне очередную ачивку. Но надо признать, что интерес аудитории к этому проекту снизился, по крайней мере, это исходя из того, что я вижу со своей стороны. Не знаю, с чем это связано, но, возможно, это результат общего упадка ценности знаний. Это звучит очень странно, но я наблюдаю это и на учебе, и среди коллег: скорее навыки становятся фокусом внимания, а не стремление разобраться в сложных процессах.

Еще Нил Постман писал в “The End of Education”, что без достойной цели образование обречено на провал. С одной стороны, мы находимся в потоке бесконечной цепочки образования, с другой — у этого образования нет определенной цели.

Получается, чтобы прийти на встречу с ментором, человек должен уметь формулировать свою цель, но самый распространенный нарратив встреч сводится к повышению своей экономической полезности. А это неудачный нарратив, потому что он сводит человека к инструменту, а инструмент должен соответствовать определенным ожиданиям и стандартам, а эти стандарты определяют бизнес-запросы.

Сейчас легко определить, на чем бизнес-запросы основываются. Все очень поверхностно: в их основе лежит потребительская модель — “что ты делал до этого, это и определяет тебя”, утопическая вера в технологии и автоматизацию — “процесс важнее человека, личные качества малозначительны, нужно, чтобы четко выполнял функцию”.

Старое правило, которое разделяли и Стив Джобс, и Илья Сегалович, — что надо нанимать людей умнее тебя — больше не работает. Сейчас нанимают людей “правильного размера” с “правильным опытом”, и в этом потоке, кажется, стало меньше места для того, чтобы найти для себя области роста и поговорить об этом с ментором. Куда важнее стало мимикрировать под ожидания, а для этого менторы не нужны.

Но ADPList остается, на мой взгляд, важным и очень полезным проектом, поэтому я о нем и пишу и все еще на нем присутствую. И вы там можете для себя найти интересного ментора. Главное — определиться с целью.

Хороший UX — это простой способ сделать жизнь людей комфортнее, и часто для этого не нужны деньги или суперусилия, достаточно вовлеченности и желания улучшить мир.

Но при этом понятно, что основной барьер в создании удобного пользовательского мира — в мировоззрении и личных предпочтениях. Есть люди, которые естественным образом думают в терминах удобства для пользователя, замечают проблемы и ищут способы их решить, и есть те, кто просто не считает это важным. И в итоге первые находят способы изменять мир, а вторые находят оправдания, почему на это не стоит тратить время и усилия.

И еще специфика ситуации в том, что, публикуя в России этот материал, я, возможно, нарушая ст. 13.15 КоАП РФ, 6.21 КоАП РФ.

AI убивает Agile. Звучит провокационно, но, кажется, это буквально происходит прямо сейчас

Больший сдвиг, который происходит с внедрением AI в разработку, произойдет и в области методологий ведения проектов. Многие компании внедрили гибкие методологии, но AI меняет разные правила, и в том числе он влияет на оргпроцессы внутри разработки.

Agile появился как способ справиться со сложной проблемой комплексного планирования систем и низкой скорости разработки, но с проникновением AI эти ограничения уже практически сняты, и вопрос только времени, когда они вообще исчезнут.

Есть интересная статья с критикой Agile «Agile Is Dead. AI Killed It. Welcome Back, Waterfall.»

Там идеи о том, что новая реальность не нуждается в избыточных ритуалах, которые пришли вместе с Agile, и в процессах, которые были порождены ограниченностью человеческих возможностей.

Сейчас, когда мы переключаемся с формулирования задач для прозрачности процессов к формулированию задач для эффективного их решения через AI, нужно уходить и от сложившихся практик, и искать новые или переосмыслять забытые.

Kent Beck (один из авторов Agile-манифеста) предполагает, что внедрение AI может столкнуться в организациях с противодействием, потому что не всегда люди заинтересованы в ускорении и удешевлении процессов. Это из разговора Kent Beck и Martin Fowler на Pragmatic Summit. Там же Kent Beck говорит о том, что возвращается тенденция к программистам-интровертам, которые не любят и не хотят частого общения, что было нормой до недавнего времени. Сейчас можно сфокусироваться на нескольких коллегах и нескольких агентах, а задачей компании становится создание безопасной позитивной атмосферы для функционирования таких производственных единиц.

Для простоты можно считать, что любой процесс кодирования занимает ноль времени, когда определено, что должно получиться. И поэтому, кажется, снова пришло время, когда вначале должно идти глобальное видение задачи, знание и понимание доменной области, принятие решения об архитектуре, и потом уже погружение в детали отдельных решений.

При этом, если описывать задачи в формате User Stories или JTBD, то будешь получать от AI простые решения. Надо уходить в детальное описание того, что требуется получить.

В моей практике сложился подход, когда есть первый уровень функциональных требований, которые я записываю для себя, чтобы обозначить задачу; есть второй уровень, в котором я описываю возможное решение и подходы; и есть третий уровень, когда я через AI прогоняю свой вариант и дорабатываю получившийся вариант, исходя из нужного мне фокуса.

1. Функциональные требования – 1–2 предложения, которые формируют бэклог проекта.
2. Описание решения – 1–2 абзаца в свободной форме, возможность задать нюансы процесса или технологии, которые я хочу, чтобы использовались в решении задачи.
3. Доработанные функциональные требования – 2–3–4 страницы. Вариант требований, который первоначально готовит AI на основе моего описания, который я потом дорабатываю с учетом нужного фокуса. Именно эти функциональные требования идут в AI для кодирования проекта.

Причем AI погружен в контекст проекта сквозным образом: начиная от архитектуры, заканчивая деталями интерфейса. Больше нет необходимости в традиционной декомпозиции проекта на небольшие фрагменты, которые можно вместить в спринт, типа «в этом спринте мы сделаем кнопку». Сейчас можно делать все связанное с требованием в один проход, но для этого нужно иметь структурированное описание системы, к которому мы можем каждый раз обращаться.

Нужна документация по системе, которая бы описывала все от общего к частному. Нужно понимание, в каком направлении движется создание проекта. По большому счету, мы возвращаемся к парадигме waterfall, когда к моменту кодирования у нас должно быть объемное видение проекта.

Для меня же все это кажется удобным способом имплементировать процесс поиска решений через вайбкодинг и быстрое создание рабочих прототипов.

Опять что-то сделал на Gemini. А все началось с попытки осмыслить, куда развиваются отрасли.

Я начал с Miro. Мне там удобно набрасывать идеи, но там слишком все свободно. А иногда, чтобы эффективнее мыслить, надо поставить себя в рамки. В итоге появилась такая матрица, в которой можно по годам поставить свой прогноз по какому-то явлению и обосновать его какой-то гипотезой.

Ещё заметил интересный феномен: когда не хватает идей, можно переключиться на создание интерфейса, который сам по себе никакой задачи не решает, но пока его делаешь, создается ощущение, что ты занят делом.

Сделал пару примеров. Честно говоря, цифры в них не бесспорные, но обычно никто и не хочет спорить.

Вот для примера, как может трансформироваться работа дизайнера интерфейсов, когда отдельные части будут вытесняться ИИ https://matrix.podluzny.com/project/6fab0560c3c8ddb8ed2c3a136127a673

Если быть коротким и пессимистичным, то уходит само ремесло дизайнера. Автоматизироваться будет 90% и больше текущей работы. Что останется более-менее в руках человека — это формулировать, зачем и для кого что-то делается, то есть не умение рисовать, а умение обоснованно принимать решения.

Уортонская школа бизнеса University of Pennsylvania выпустила исследование о том, как люди взаимодействуют с ИИ. И результаты там неутешительны — люди так сильно доверяют ИИ, что легко готовы соглашаться с неверными ответами.

И это печально, потому что из других исследований мы знае,: даже самые лучшие модели галлюцинируют. Например, ведущие модели ИИ ошибаются при ранней дифференциальной диагностике более чем в 8 из 10 случаев (в исследовании использовали 21 модель: https://jamanetwork.com/journals/jamanetworkopen/fullarticle/2847679 ).

Исследователи даже ввели термин Cognitive Surrender — когнитивная капитуляция, который отражает ситуацию, когда люди полагаются на информацию и решения ИИ без критической оценки.

Фактически люди воспринимают ответ ИИ как собственное суждение, которое они сами обдумали, и поэтому не пытаются его пересмотреть. Это не похоже на то, как мы пользуемся инструментами, например калькулятором: ему мы передаем отдельную рабочую функцию, но контроль за выводами все равно остается за нами.

В исследовании показано, что, когда ИИ давал правильный ответ на вопрос пользователя, люди следовали ему в 92,7% случаев. Когда ответ был неправильным — в 79,8% случаев.

Если люди принимали решение без ИИ, точность составляла бы 45,8%. С правильным ответом ИИ точность повышалась до 71,0%. С неправильным — падала до 31,5%, что хуже, чем при отсутствии ИИ.

Предполагается, что человек будет критически относиться к ответам ИИ, но по факту мы очень сильно на них полагаемся. Они слишком грамотно составлены, чётко сформулированы, полны деталей и фактов.
Кажется, что нужно формировать более сложный паттерн взаимодействия с ИИ, чем просто «вопрос — ответ», и тем более чем «создал агента — теперь он за меня работает».

Интересное исследование, которое показывает, что люди, предпочитающие общаться в формате корпоративного булшита, использующие запутанные конструкции, сложные корпоративные термины, жаргонизмы, отдающие предпочтение впечатляющей, привлекательной подаче информации, оказывается, не очень хорошими работниками. В простой ситуации корпоративная чушь может оказаться безобидным делом, но в худшем варианте она способна нарушать эффективность организации, разрушая четкость коммуникаций.

Исследователи ввели шкалу корпоративного булшита Corporate Bullshit Receptivity Scale (CBSR) и показали, что есть отрицательная корреляция между склонностью к корпоративному булшиту и аналитическим мышлением. Т.е. люди, которые предпочитают корпоративный булшит, не очень хорошо способны принимать деловые решения.

Вот само исследование «The Corporate Bullshit Receptivity Scale: Development, validation, and associations with workplace outcomes»
и более развернутый текст о нем на Inc.

Пришла пора «собирать камни», т.е. оценить, что мне принесла моя активность по разным каналам за март–апрель.

В деньгах — ничего.

В просмотрах по площадкам

VC — я туда запостил восемь постов, в итоге 2283 просмотра. Из поверхностных наблюдений: выбранная рубрика сильно определяет то, на какой охват можно рассчитывать. В моем случае выбор «Дизайн» и «AI» куда лучше, чем «Разработка» и «Личный опыт».

Habr — довольно токсичное сообщество людей, у которых всегда есть свое мнение. Почти всегда есть повод схлопотать минус в карму за пост на Habr, и это дико бьет по самомнению и отбивает всякое желание туда что-то писать. Но я расту над собой и забил на это. Опубликовал там за это время 2 поста, общий охват — 11 800.

Substack — ничего нового туда не публиковал. Охваты там низкие, очевидно, что нужно внешнее продвижение. Как говорят аналитики по разным платформам — Substack уже не тот.

Medium — было два поста. Всего читателей — 15 человек. На Medium публиковать что-то на русском без привязки к сообществу бессмысленно. Я состою в двух, где являюсь автором, и если что-то написать туда, то охват куда больше, но это все равно только сотни читателей. С другой стороны, я понимаю, что общее число читателей — это маркер интереса к материалу и его актуальности. Самый мой первый пост — про теорию перспектив Канемана — Тверски — в итоге собрал 6900 просмотров, и там я не пытался ничего своего писать: это был просто пересказ чужой статьи о чужой теории, но это оказалось куда интереснее, чем мои мысли.

LinkedIn — собственно, с него все начиналось, и изначально я хотел писать короткие посты только сюда. А уже потом появился канал в Telegram и YouTube. Всего показов — 13 300, но надо учитывать, что это во многом одни и те же люди, как я думаю. С апреля я опубликовал там 28 постов. Я стараюсь придерживаться определенного ритма, но вижу, что это не дает роста охвата: важнее тема, и чем проще, тем лучше.

Telegram — в канале по-прежнему 66 подписчиков. В конце марта были 2 подписки, но потом были 2 отписки. В общем, органического роста нет, но и деградации тоже.

YouTube — выпустил 5 роликов, общий объем просмотров — 470. Ну так себе. С другой стороны, я не ставил целью какую-то популярность, но подсознательно хотелось бы немного больше.

Итого

По цифрам видно, что звездой мне не стать. Я это начинал как эксперимент без особой цели, чтобы посмотреть, что из этого выйдет. Но из наблюдений понятно, что для достижения большего результата надо не только регулярность, но и стратегия.

В ближайших планах описать для себя редакционную стратегию, включающую формулировку целей, аудитории, тематики, сегментации каналов под разные посты и измеряемых результатов. Это кажется хорошим планом, им и займусь.

После нескольких недель работал над NodeFlow в замедленном темпе. Скорость упала, потому что надо было поработать над другими проектами.

Что было сделано

Основная часть работы ушла под капот и визуально почти незаметна. Проект прошёл через три волны рефакторинга: сначала тексты интерфейса, потом код, потом UI. Для каждого из направлений сначала запускался аудит — не для немедленного исправления, а чтобы понять масштаб проблемы. Делал это через отдельно написанные промты.

Тексты исправлял вручную, потому что их было мало и хотел убедиться в корректности исправлений. Для UI это было уже нереально, поэтому все делал Gemini, который аккуратно вносит изменения в локальных областях, не затрагивая функциональные блоки. Промты сработали хорошо.
На основе текстового аудита был составлен небольшой редакционный гайд, что и как писать в интерфейсе, какую терминологию использовать. Он нужен для будущих функций, чтобы AI знал правила игры заранее.

Поменял панель аналитики

Раньше аналитика была просто панелью. Теперь это отдельная область, в которую можно добавлять несколько инструментов, переключаться между ними, перетаскивать вкладки и переименовывать их. Самое важное, состояние этих панелей теперь сохраняется вместе с проектом, и они больше не теряются.

Подход к работе с AI

Сформировался рабочий метод, который хорошо себя показал. Сначала — формулировка гипотезы своими словами. Затем через Claude она превращается в полноценный промт с функциональными требованиями и ограничениями. Этот промт правится вручную и только потом отправляется в Gemini. Смысл в том, что развёрнутое описание с ограничениями позволяет сразу видеть, что сработает, а что нет, потому что короткая фраза может быть интерпретирована моделью множеством разных способов и промт с ограничениями задает более точное направление работы.

Что дальше

Следующий этап для проекта — авторизованная зона с хранением файлов пользователей. После этого активная фаза разработки будет временно завершена.

Ссылка на проект https://nodeflow.podluzny.com/
Страница с примерами https://nodeflow.podluzny.com/examples

Видео на Ютюбе https://youtu.be/6c1cg9KMtyU