Новые ИИ сейчас затрагивают не только генерацию картинок и бесконечные мемы, но они привносят что-то новое и в то, что, казалось бы, не должно меняться.
В блоге Vercel вышла статья «Making agent-friendly pages with content negotiation» с довольно актуальной темой. Они пишут, что начали выдавать на запрос
Типичная страница занимает 500 KB с учетом HTML, CSS и JavaScript. Однако в формате Markdown сам контент страницы весит всего 2 KB. Значительное сокращение объема загрузки и сильное упрощение для ИИ при анализе содержания. С учетом того, что на запрос тратятся токены, более компактный контент с большей вероятностью не столкнется с ограничениями при его обработке.
Зная, что российские компании отличаются инновационностью, я пошел проверить, реализовано ли у них это. И, конечно, зашел на сайт самой большой и богатой ИТ-компании России — на сайт Сбербанка. И, конечно, там запрос под Markdown не обрабатывается. Потом зашел на сайты Tinkoff, Ozon, Wildberries — и там то же самое.
В общем, пока это не стало распространенным явлением. Хотя роль ИИ-поиска все выше, и все компании, в принципе, должны быть заинтересованы в том, чтобы ИИ эффективно обрабатывал их контент.
Но есть шанс, что, сидя за своим монитором, я просто чего-то не замечаю.
Может у вас уже внедряют выдачу
В блоге Vercel вышла статья «Making agent-friendly pages with content negotiation» с довольно актуальной темой. Они пишут, что начали выдавать на запрос
Accept: text/markdown, text/html, */* не код страниц, а ответ в формате Markdown. И для объяснения этого есть хороший аргумент.Типичная страница занимает 500 KB с учетом HTML, CSS и JavaScript. Однако в формате Markdown сам контент страницы весит всего 2 KB. Значительное сокращение объема загрузки и сильное упрощение для ИИ при анализе содержания. С учетом того, что на запрос тратятся токены, более компактный контент с большей вероятностью не столкнется с ограничениями при его обработке.
Зная, что российские компании отличаются инновационностью, я пошел проверить, реализовано ли у них это. И, конечно, зашел на сайт самой большой и богатой ИТ-компании России — на сайт Сбербанка. И, конечно, там запрос под Markdown не обрабатывается. Потом зашел на сайты Tinkoff, Ozon, Wildberries — и там то же самое.
В общем, пока это не стало распространенным явлением. Хотя роль ИИ-поиска все выше, и все компании, в принципе, должны быть заинтересованы в том, чтобы ИИ эффективно обрабатывал их контент.
Но есть шанс, что, сидя за своим монитором, я просто чего-то не замечаю.
Может у вас уже внедряют выдачу
text/markdown?Vercel
Making agent-friendly pages with content negotiation
Learn how Vercel uses HTTP content negotiation to serve markdown to agents and HTML to humans from the same URL, reducing response sizes by 90% while keeping both versions synchronized.
🔥1🤔1
This media is not supported in your browser
VIEW IN TELEGRAM
Работая с ИИ над анимацией для блога, пришлось вспомнить законы Мерфи: «Если что-то может пойти не так, оно пойдет не так». И я думаю, что это теперь базовый принцип вайб-кодинга.
Задача довольно простая, я хотел, чтобы шарики летали по кривой, а пользователь мог их хватать и толкать. Я экспортировал кривую в SVG из Figma и пошел в ChatGPT с промтом, в котором указал «использовать популярную и современную JS-библиотеку». Это важный момент, потому что по опыту вижу, что часто ИИ пишет код с нуля, и такой результат менее стабилен, чем при использовании готовых библиотек.
Но вот что интересно, любое необъявленное поведение может быть реализовано как угодно. В промте я не сказал, откуда появляются шарики и они стали возникать в случайном месте кривой. Не уточнил, что делать с достигшими конца пути и они зависали и накапливались там. А первоначальный промт, использовать пятисекундный интервал для появления шариков, проигнорировали. Пришлось итеративно уточнять поведение системы несколько раз.
В итоге получил блок, который работает на 95% от моих ожиданий. И это нормальный результат. Даже хороший.
И это ситуация регулярного компромисса при работе с ИИ, когда ты все время приближаясь к целевому результату, но должен быть готовым согласиться на компромиссный вариант или немного иное решение. Иначе есть шанс зациклиться в бесконечных попытках исправить код.
Потому что я все чаще думаю: а где теперь граница моей компетенции как дизайнера? Раньше я бы не взялся за такую задачу или потратил неделю на изучение GSAP. Сейчас сделал за час, но с осознанием, что контролирую процесс лишь частично. Я научился формулировать намерение, корректировать курс и принимать 95% как достаточный результат.
Кстати, тут как раз вспоминается статья «The Design Vibeshift» про изменение парадигмы дизайн-подхода вместе с переключение дизайнеров от работы с хостом в Figma к кодированию результата через ИИ. Там есть много интересных мыслей, не хочу их пересказывать, но одну цитату от Hardik Pandya (Head of Design at Atlassian, это они делают Jira) приведу: «Figma очень быстро становится огромным узким местом в создании продуктов.»
Не думаю, что это приговор традиционному дизайну, но, возможно, это повод задуматься и начать делать что-то через вайб-код.
А то, что получилось у меня, в рамках текущего вайб-код эксперимента, можно посмотреть здесь.
Задача довольно простая, я хотел, чтобы шарики летали по кривой, а пользователь мог их хватать и толкать. Я экспортировал кривую в SVG из Figma и пошел в ChatGPT с промтом, в котором указал «использовать популярную и современную JS-библиотеку». Это важный момент, потому что по опыту вижу, что часто ИИ пишет код с нуля, и такой результат менее стабилен, чем при использовании готовых библиотек.
Но вот что интересно, любое необъявленное поведение может быть реализовано как угодно. В промте я не сказал, откуда появляются шарики и они стали возникать в случайном месте кривой. Не уточнил, что делать с достигшими конца пути и они зависали и накапливались там. А первоначальный промт, использовать пятисекундный интервал для появления шариков, проигнорировали. Пришлось итеративно уточнять поведение системы несколько раз.
В итоге получил блок, который работает на 95% от моих ожиданий. И это нормальный результат. Даже хороший.
И это ситуация регулярного компромисса при работе с ИИ, когда ты все время приближаясь к целевому результату, но должен быть готовым согласиться на компромиссный вариант или немного иное решение. Иначе есть шанс зациклиться в бесконечных попытках исправить код.
Потому что я все чаще думаю: а где теперь граница моей компетенции как дизайнера? Раньше я бы не взялся за такую задачу или потратил неделю на изучение GSAP. Сейчас сделал за час, но с осознанием, что контролирую процесс лишь частично. Я научился формулировать намерение, корректировать курс и принимать 95% как достаточный результат.
Кстати, тут как раз вспоминается статья «The Design Vibeshift» про изменение парадигмы дизайн-подхода вместе с переключение дизайнеров от работы с хостом в Figma к кодированию результата через ИИ. Там есть много интересных мыслей, не хочу их пересказывать, но одну цитату от Hardik Pandya (Head of Design at Atlassian, это они делают Jira) приведу: «Figma очень быстро становится огромным узким местом в создании продуктов.»
Не думаю, что это приговор традиционному дизайну, но, возможно, это повод задуматься и начать делать что-то через вайб-код.
А то, что получилось у меня, в рамках текущего вайб-код эксперимента, можно посмотреть здесь.
👾1
Просматривал старые публикации и наткнулся на незаслуженно забытый вариант схемы стратегического плана, который я создавал для редизайна «Комсомольской правды». Он мне до сих пор нравится, потому что отражает необходимые усилия для достижения комплексного результата и помогает фокусироваться на самом результате, а не соскальзывать в текучку промежуточных задач.
Это визуализация из статьи про редизайн сайта газеты у меня в блоге.
Подход к созданию этого стратегического плана проходил через несколько этапов:
— Приоритизировать цели: преобразовать хаотичное облако целей в упорядоченный список, чтобы ответить на вопрос «что важнее».
— Выразить цели через метрики: сформулировать метрики для каждой цели, указать, как их считать, и выявить факторы влияния.
— Измерять метрики в динамике: убедиться, что метрики можно рассчитывать для сравнения изменений; использовать гипотезы для неопределенных факторов.
— Определить зависимости: выявить ключевые влияния факторов на метрики, упростив картину до основных сил.
— Создать стратегический план: объединить цели, метрики, факторы и действия (промежуточные задачи) в единое пространство, фокусируясь на главной цели для достижения остальных побочно.
Обо всем этом я подробнее писал в статье на Medium , кажется, это моя самая залайканная статья там.
Это визуализация из статьи про редизайн сайта газеты у меня в блоге.
Подход к созданию этого стратегического плана проходил через несколько этапов:
— Приоритизировать цели: преобразовать хаотичное облако целей в упорядоченный список, чтобы ответить на вопрос «что важнее».
— Выразить цели через метрики: сформулировать метрики для каждой цели, указать, как их считать, и выявить факторы влияния.
— Измерять метрики в динамике: убедиться, что метрики можно рассчитывать для сравнения изменений; использовать гипотезы для неопределенных факторов.
— Определить зависимости: выявить ключевые влияния факторов на метрики, упростив картину до основных сил.
— Создать стратегический план: объединить цели, метрики, факторы и действия (промежуточные задачи) в единое пространство, фокусируясь на главной цели для достижения остальных побочно.
Обо всем этом я подробнее писал в статье на Medium , кажется, это моя самая залайканная статья там.
✍2
ИИ все больше используется в разработке, и не прекращается разговор о его эффективности. Недавно вышла статья по результатам исследования Anthropic «Исследование Anthropic опровергло идею сверхэффективности ИИ-ассистентов для программистов».
В статье ссылка на свежее исследование, которое показывает, что решение новых задач в области программирования с использованием ИИ не дает значительного прироста производительности. То есть не получается существенно выиграть в скорости. Но при этом возможна сильная потеря в качестве.
Исследователи не отрицают полезность ИИ, но указывают на то, что в эксперименте качество зависело в том числе от подхода, который использовали люди. Те, кто полагался только на ИИ, с одной стороны получали результат быстрее всего, но их результат не был высокого качества.
При этом, когда испытуемый начинал задавать дополнительные вопросы ИИ, делать уточнения, время выполнения задания увеличивалось. Составление промптов и предоставление точного контекста для выполнения задачи занимало столько же времени, сколько и ручное написание кода у некоторых участников.
Исследователи показали шесть паттернов поведения в отношении ИИ, и в тех ситуациях, когда люди задавали концептуальные вопросы и запрашивали объяснения результата, качество было выше, чем в случаях отсутствия вовлеченности.
Вот как исследователи описали паттерны поведения:
AI Delegation (Делегирование ИИ): полностью полагались на ИИ при написании. Эта группа выполнила задания быстро и с небольшим количество ошибок или вообще без них.
Progressive AI Reliance (Постепенная зависимость от ИИ): начали с 1–2 вопросов и в конечном итоге делегировали написание всего кода ИИ. Эта группа показала низкие результаты в тесте, в основном из-за того, что не смогла понять концепции для одного из заданий.
Iterative AI Debugging (Итеративная отладка ИИ): полагались на ИИ для отладки или проверки своего кода. Эта группа делала больше запросов к ИИ-помощнику, но использовала его для решения проблем, а не для уточнения собственного понимания.
Generation-Then-Comprehension (Генерация — понимание): сначала генерировали код, а затем вручную копировали или вставляли его в свою работу. После генерации кода задавали ИИ уточняющие вопросы для улучшения понимания. Эти участники не отличались высокой скоростью, но продемонстрировали высокий уровень понимания в тесте.
Hybrid Code-Explanation (Гибридный код — объяснение): участники составляли гибридные запросы, в которых просили сгенерировать код вместе с его объяснением. Чтение и понимание объяснений занимало больше времени, но обеспечивало более высокое качество.
Conceptual Inquiry (Концептуальное исследование): задавали только концептуальные вопросы. Хотя эта группа столкнулась со многими ошибками, они самостоятельно их исправляли. В среднем этот режим оказался самым быстрым среди высокоэффективных и вторым по скорости после режима делегирования ИИ.
Но есть пара мест и для критики исследования.
Я бы отметил, что в исследовании использовалась модель GPT-4o, которая на сегодняшний день не является лучшей для решения задач в области программирования. Если была бы модель Gemini-3-Pro (сейчас она на первом месте в https://openlm.ai/chatbot-arena/ ), то быть может результаты были бы другими.
Кроме того, программисты работали с новой для себя библиотекой, и модель, соответственно, тоже имела дело с новым кодом. Таких задач в обычной практике немного. Большинство разработчиков сталкиваются с типичными для себя и отрасли задачами. Подозреваю, что для них качество ответов используемого ИИ было бы значительно выше. И в этой ситуации AI Delegation получил бы более значительную оценку.
Но в любом случае стоит обратить внимание на то, что изменение самого подхода к использованию ИИ влияет на результаты. Поэтому разумно, когда компании проводят внутри себя программы по распространению эффективного использования ИИ в работе и находят возможность фокусироваться на методологии работы с ИИ, потому что, как кажется, именно здесь проходит водораздел между «немного облегчает жизнь» и «это просто космос».
В статье ссылка на свежее исследование, которое показывает, что решение новых задач в области программирования с использованием ИИ не дает значительного прироста производительности. То есть не получается существенно выиграть в скорости. Но при этом возможна сильная потеря в качестве.
Исследователи не отрицают полезность ИИ, но указывают на то, что в эксперименте качество зависело в том числе от подхода, который использовали люди. Те, кто полагался только на ИИ, с одной стороны получали результат быстрее всего, но их результат не был высокого качества.
При этом, когда испытуемый начинал задавать дополнительные вопросы ИИ, делать уточнения, время выполнения задания увеличивалось. Составление промптов и предоставление точного контекста для выполнения задачи занимало столько же времени, сколько и ручное написание кода у некоторых участников.
Исследователи показали шесть паттернов поведения в отношении ИИ, и в тех ситуациях, когда люди задавали концептуальные вопросы и запрашивали объяснения результата, качество было выше, чем в случаях отсутствия вовлеченности.
Вот как исследователи описали паттерны поведения:
AI Delegation (Делегирование ИИ): полностью полагались на ИИ при написании. Эта группа выполнила задания быстро и с небольшим количество ошибок или вообще без них.
Progressive AI Reliance (Постепенная зависимость от ИИ): начали с 1–2 вопросов и в конечном итоге делегировали написание всего кода ИИ. Эта группа показала низкие результаты в тесте, в основном из-за того, что не смогла понять концепции для одного из заданий.
Iterative AI Debugging (Итеративная отладка ИИ): полагались на ИИ для отладки или проверки своего кода. Эта группа делала больше запросов к ИИ-помощнику, но использовала его для решения проблем, а не для уточнения собственного понимания.
Generation-Then-Comprehension (Генерация — понимание): сначала генерировали код, а затем вручную копировали или вставляли его в свою работу. После генерации кода задавали ИИ уточняющие вопросы для улучшения понимания. Эти участники не отличались высокой скоростью, но продемонстрировали высокий уровень понимания в тесте.
Hybrid Code-Explanation (Гибридный код — объяснение): участники составляли гибридные запросы, в которых просили сгенерировать код вместе с его объяснением. Чтение и понимание объяснений занимало больше времени, но обеспечивало более высокое качество.
Conceptual Inquiry (Концептуальное исследование): задавали только концептуальные вопросы. Хотя эта группа столкнулась со многими ошибками, они самостоятельно их исправляли. В среднем этот режим оказался самым быстрым среди высокоэффективных и вторым по скорости после режима делегирования ИИ.
Но есть пара мест и для критики исследования.
Я бы отметил, что в исследовании использовалась модель GPT-4o, которая на сегодняшний день не является лучшей для решения задач в области программирования. Если была бы модель Gemini-3-Pro (сейчас она на первом месте в https://openlm.ai/chatbot-arena/ ), то быть может результаты были бы другими.
Кроме того, программисты работали с новой для себя библиотекой, и модель, соответственно, тоже имела дело с новым кодом. Таких задач в обычной практике немного. Большинство разработчиков сталкиваются с типичными для себя и отрасли задачами. Подозреваю, что для них качество ответов используемого ИИ было бы значительно выше. И в этой ситуации AI Delegation получил бы более значительную оценку.
Но в любом случае стоит обратить внимание на то, что изменение самого подхода к использованию ИИ влияет на результаты. Поэтому разумно, когда компании проводят внутри себя программы по распространению эффективного использования ИИ в работе и находят возможность фокусироваться на методологии работы с ИИ, потому что, как кажется, именно здесь проходит водораздел между «немного облегчает жизнь» и «это просто космос».
Media is too big
VIEW IN TELEGRAM
Очередной вайб-эксперимент, сегодня о создании плагина под Chrome, который помогает писать грамотно.
Я собрал в ChatGPT простой плагин, который позволяет выделить текст в браузере и отправить его на исправление в LLM. В качестве базовых настроек можно задать стандартный эндпоинт модели, которая работает с OpenAI API, ее ключ и название, и обращаться к ней за результатом. В моем случае я использую ChatGPT-4o-mini, чтобы чуть меньше платить за запросы. Но с учетом размера запросов, это очень малые суммы — речь идет о тысячных долях цента.
Пока я не загрузил плагин в магазин приложений, но если он вам интересен, вы можете скачать его с GitHub https://github.com/podluzny/SpellFix/tree/main
Видео на ютюбе https://youtu.be/ptcCq90xWB4
Я собрал в ChatGPT простой плагин, который позволяет выделить текст в браузере и отправить его на исправление в LLM. В качестве базовых настроек можно задать стандартный эндпоинт модели, которая работает с OpenAI API, ее ключ и название, и обращаться к ней за результатом. В моем случае я использую ChatGPT-4o-mini, чтобы чуть меньше платить за запросы. Но с учетом размера запросов, это очень малые суммы — речь идет о тысячных долях цента.
Пока я не загрузил плагин в магазин приложений, но если он вам интересен, вы можете скачать его с GitHub https://github.com/podluzny/SpellFix/tree/main
Видео на ютюбе https://youtu.be/ptcCq90xWB4
👍2
Вы, возможно, уже читали историю, где покупатель убедил ИИ-чат дать скидку в 8000 фунтов. И заметьте, пока еще нет никакого массового распространения агентов среди бизнеса и частных лиц. Мы имеем дело только с пионерами, но и они своими факапами и финансовыми расходами показывают остальным пространство возможных угроз.
Проблема ИИ-агентов в том, что они недетерминированы. Их поведение определяется набором шатких правил, но разработчики проектов, которые предлагают сейчас бизнесу агентов-рекрутеров, менеджеров, финансистов, не знают, как агенты работают внутри. И правда в том, что этого не понимают даже люди, которые создали ИИ-модели на основе которых работают агенты. В этом и заключается одна из особенностей современных технологий.
В конечном счете кажется, что всякому рациональному внедрению ИИ-агента требуется стадия предварительного анализа рисков, чтобы хотя бы понять, чем это может грозить.
Если бы у меня стояла задача методологически организовать внедрение ИИ-агентов, я бы, конечно, начал со списка рисков хотя бы от MIT AI Risk, чтобы очертить потенциальные угрозы, с которыми можно столкнуться и которые нужно учитывать.
В таких вопросах я консерватор. Мне нравится семь раз отмерить и никуда не торопиться. Потому что иллюзорный выигрыш в пару недель или месяц на старте может обернуться огромными потерями потом. Хотя мои наблюдения показывают, что сейчас предпочитают скорость осмысленности, обещания быстрых выигрышей — надежности результата. Но это уже тема для другого поста.
Проблема ИИ-агентов в том, что они недетерминированы. Их поведение определяется набором шатких правил, но разработчики проектов, которые предлагают сейчас бизнесу агентов-рекрутеров, менеджеров, финансистов, не знают, как агенты работают внутри. И правда в том, что этого не понимают даже люди, которые создали ИИ-модели на основе которых работают агенты. В этом и заключается одна из особенностей современных технологий.
В конечном счете кажется, что всякому рациональному внедрению ИИ-агента требуется стадия предварительного анализа рисков, чтобы хотя бы понять, чем это может грозить.
Если бы у меня стояла задача методологически организовать внедрение ИИ-агентов, я бы, конечно, начал со списка рисков хотя бы от MIT AI Risk, чтобы очертить потенциальные угрозы, с которыми можно столкнуться и которые нужно учитывать.
В таких вопросах я консерватор. Мне нравится семь раз отмерить и никуда не торопиться. Потому что иллюзорный выигрыш в пару недель или месяц на старте может обернуться огромными потерями потом. Хотя мои наблюдения показывают, что сейчас предпочитают скорость осмысленности, обещания быстрых выигрышей — надежности результата. Но это уже тема для другого поста.
👍2✍1🤪1
UX Point — канал Дмитрия Подлужного
Очередной вайб-эксперимент, сегодня о создании плагина под Chrome, который помогает писать грамотно. Я собрал в ChatGPT простой плагин, который позволяет выделить текст в браузере и отправить его на исправление в LLM. В качестве базовых настроек можно задать…
А плагин все-таки опубликовали, надо было мне более серьезно подойти к подготовке его описания и иллюстраций к нему https://chromewebstore.google.com/detail/%D0%B8%D1%81%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D1%82%D1%8C-%D0%BE%D1%80%D1%84%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D1%8E/jmcpbcbcgoaffjdfffnjiaipmlolgojc?authuser=0&hl=ru
👍2🔥1
В 2024 году я участвовал в тендере на новый сайт для Henderson — это бренд одежды для мужчин. Весьма вероятно, вы его знаете. Участвовал с Agima, но тендер мы не выиграли. Тогда я разрабатывал стратегию на пресейле, проектировал концепцию сайта и делал презентацию про продуктовый подход.
Основной идеей, вокруг которой все строилось — стратегия дизайна, изменения на сайте, предложения по внешней коммуникации — было использование консервативного подхода в дизайне. То есть наследовать существующее решение, не делать революций, а почистить, убрать лишнее, сделать изящнее и сфокусироваться на эффективности сайта. На банальной способности интерфейса продавать больше.
У меня были хорошие, на мой взгляд, слайды с цифрами, которые показывали на примере других проектов, что «скучный» дизайн хорошо продает. Но, честно говоря, клиент очень хотел радикальных перемен, и мои слова о том, что радикальные изменения могут обернуться потерями, звучали неубедительно. В конечном счете никто не знает будущее, поэтому мой прогноз, основанный на чужих экспериментах, не мог переубедить владельцев бизнеса изменить свое видение будущего сайта.
Им нужна была красивая картинка. В итоге они ее сделали. Я не знаю, какие сейчас показатели по конверсии и удержанию на сайте, но с высокой вероятностью могу утверждать, что в мобильном приложении, которое они переделали под сайт, показатели просели.
Я до сих пор не знаю, можно ли в такой ситуации найти аргументы, которые бы сработали, или единственный вариант победы — это идти за видением клиента. Но и тогда и сейчас я выбираю то, во что верю сам.
Кстати, когда я готовил презентацию для Henderson, референсы и цифры приходилось искать в довольно неожиданных местах. Сейчас в помощь есть проекты вроде abtest.design, где иногда можно найти что-то полезное, если включить голову.
Основной идеей, вокруг которой все строилось — стратегия дизайна, изменения на сайте, предложения по внешней коммуникации — было использование консервативного подхода в дизайне. То есть наследовать существующее решение, не делать революций, а почистить, убрать лишнее, сделать изящнее и сфокусироваться на эффективности сайта. На банальной способности интерфейса продавать больше.
У меня были хорошие, на мой взгляд, слайды с цифрами, которые показывали на примере других проектов, что «скучный» дизайн хорошо продает. Но, честно говоря, клиент очень хотел радикальных перемен, и мои слова о том, что радикальные изменения могут обернуться потерями, звучали неубедительно. В конечном счете никто не знает будущее, поэтому мой прогноз, основанный на чужих экспериментах, не мог переубедить владельцев бизнеса изменить свое видение будущего сайта.
Им нужна была красивая картинка. В итоге они ее сделали. Я не знаю, какие сейчас показатели по конверсии и удержанию на сайте, но с высокой вероятностью могу утверждать, что в мобильном приложении, которое они переделали под сайт, показатели просели.
Я до сих пор не знаю, можно ли в такой ситуации найти аргументы, которые бы сработали, или единственный вариант победы — это идти за видением клиента. Но и тогда и сейчас я выбираю то, во что верю сам.
Кстати, когда я готовил презентацию для Henderson, референсы и цифры приходилось искать в довольно неожиданных местах. Сейчас в помощь есть проекты вроде abtest.design, где иногда можно найти что-то полезное, если включить голову.
❤2
Media is too big
VIEW IN TELEGRAM
В очередном эксперименте с вайбкодингом я попробовал сделать RAG-поиск (Retrieval-Augmented Generation) для своего блога. Чтобы читатели могли задавать вопросы по всем статьям и получать ответы с источниками.
Программирование от меня далеко, но я довольно много занимался системной аналитикой и могу разрезать проект любой сложности на достаточно небольшие кусочки, чтобы его могла переварить ИИ-модель. Я так и поступил.
Вся задача заняла выходные. Я выделил два сервиса: один отвечает за сбор данных и их обработку, второй работает как сервис, к которому можно отправить запрос через API, и он уже занимается поиском.
Разделение на сервисы дает возможность упростить работу, и когда что-то одно готово, начинать делать следующее.
Второй плюс такого подхода в том, что я могу отправлять запросы к OpenAI без страха, что будет блокировка по IP.
Технологии я выбрал самые простые с точки зрения работы с ними, т.е. к ним легко подключаться, у них есть документация, они работают без проблем.
Под капотом: Supabase (векторное хранилище), OpenAI embeddings, GPT-4o mini для генерации ответов, Google Gemini для создания всего кода. Еще я использовал ChatGPT, чтобы получать ответы на непонятные вопросы или работать с непонятными ошибками. Gemini Build очень сильно заточен под написание кода и не склонен объяснять свои решения. Ну и чтобы не тратить лишние токены, вопросы для самообразования я задавал в ChatGPT.
Вместе со всеми настройками отдельно настроил системный промпт для запросов при поиске. Промпт вообще — это великое дело, и через него можно сильно улучшить качество ответов, и что немаловажно, противостоять попыткам взлома через промпты.
Итоги эксперимента: потрачено всего 3 цента за десятки тестов и прогонов (но в пике у меня было в базе всего около 700 страниц, так что низкие затраты определяются размером проекта). RAG-поиск реально собрать «на коленке» одному человеку со средним уровнем подготовки — без огромных бюджетов и команды, качество, может, будет не совершенным, но можно экспериментировать.
Видео на ютюбе: https://youtu.be/9Q_HHl02VHE
Программирование от меня далеко, но я довольно много занимался системной аналитикой и могу разрезать проект любой сложности на достаточно небольшие кусочки, чтобы его могла переварить ИИ-модель. Я так и поступил.
Вся задача заняла выходные. Я выделил два сервиса: один отвечает за сбор данных и их обработку, второй работает как сервис, к которому можно отправить запрос через API, и он уже занимается поиском.
Разделение на сервисы дает возможность упростить работу, и когда что-то одно готово, начинать делать следующее.
Второй плюс такого подхода в том, что я могу отправлять запросы к OpenAI без страха, что будет блокировка по IP.
Технологии я выбрал самые простые с точки зрения работы с ними, т.е. к ним легко подключаться, у них есть документация, они работают без проблем.
Под капотом: Supabase (векторное хранилище), OpenAI embeddings, GPT-4o mini для генерации ответов, Google Gemini для создания всего кода. Еще я использовал ChatGPT, чтобы получать ответы на непонятные вопросы или работать с непонятными ошибками. Gemini Build очень сильно заточен под написание кода и не склонен объяснять свои решения. Ну и чтобы не тратить лишние токены, вопросы для самообразования я задавал в ChatGPT.
Вместе со всеми настройками отдельно настроил системный промпт для запросов при поиске. Промпт вообще — это великое дело, и через него можно сильно улучшить качество ответов, и что немаловажно, противостоять попыткам взлома через промпты.
Итоги эксперимента: потрачено всего 3 цента за десятки тестов и прогонов (но в пике у меня было в базе всего около 700 страниц, так что низкие затраты определяются размером проекта). RAG-поиск реально собрать «на коленке» одному человеку со средним уровнем подготовки — без огромных бюджетов и команды, качество, может, будет не совершенным, но можно экспериментировать.
Видео на ютюбе: https://youtu.be/9Q_HHl02VHE
👨💻2
This media is not supported in your browser
VIEW IN TELEGRAM
Немного запарился и сделал для блога новую страницу с услугами. Давно ее откладывал, а теперь она есть.
Под капотом WordPress, Foundation CSS, GSAP. GSAP MotionPathPlugin взял специально, чтобы страница запомнилась, а не просто информировала. Получилось или нет — посмотрим. Еще добавил котика, специально, чтобы создать эмоциональный якорь, иногда эмоции важнее правильной типографики.
Работал с помощью ИИ, и без него честно не справился бы. Код вышел не идеальным, легаси существующего сайта дает о себе знать, да и много нюансов, которые мне сложно отследить. Но страница живет, и это уже что-то.
Сделать детальные страницы под услуги будет следующим шагом. Пока буду считать это экспериментом и смотреть, к чему он приведет.
Под капотом WordPress, Foundation CSS, GSAP. GSAP MotionPathPlugin взял специально, чтобы страница запомнилась, а не просто информировала. Получилось или нет — посмотрим. Еще добавил котика, специально, чтобы создать эмоциональный якорь, иногда эмоции важнее правильной типографики.
Работал с помощью ИИ, и без него честно не справился бы. Код вышел не идеальным, легаси существующего сайта дает о себе знать, да и много нюансов, которые мне сложно отследить. Но страница живет, и это уже что-то.
Сделать детальные страницы под услуги будет следующим шагом. Пока буду считать это экспериментом и смотреть, к чему он приведет.
👍2🔥2🤪1
Вы наверняка знаете фразу: «Дай человеку рыбу, и он будет сыт один день. Научи его ловить рыбу, и он будет сыт всю жизнь», которую приписывают Лао-цзы или Конфуцию. Я и сам не раз ее повторял. Красивая фраза, и, казалось бы, в ней не может быть подвоха.
Но если посмотреть на рандомизированные исследования влияния денежных грантов для предпринимателей в сравнении с образовательными программами, то окажется, что образовательные программы значительно слабее влияют на благополучие людей.
Это подтверждается и исследованиями домохозяйств (Кения, Индия), которым либо давали деньги, либо проводили образовательные программы — обучение почти всегда оказывалось значительно менее эффективным и в краткосрочной, и в долгосрочной перспективе.
Только не подумайте, что обучение вообще не влияет. Влияет. Но, похоже, это не панацея. Его эффект невелик.
Правда, те же рандомизированные исследования в Кении под эгидой World Bank показали, что даже небольшой тренинг для предпринимателей дал +15% к росту по сравнению со средним по рынку. То есть обучение позволяет быть чуть лучше соседа, который не учился, более конкурентоспособным. Но, похоже, оно не может сделать человека богатым, для этого нужно что-то другое.
Но если посмотреть на рандомизированные исследования влияния денежных грантов для предпринимателей в сравнении с образовательными программами, то окажется, что образовательные программы значительно слабее влияют на благополучие людей.
Это подтверждается и исследованиями домохозяйств (Кения, Индия), которым либо давали деньги, либо проводили образовательные программы — обучение почти всегда оказывалось значительно менее эффективным и в краткосрочной, и в долгосрочной перспективе.
Только не подумайте, что обучение вообще не влияет. Влияет. Но, похоже, это не панацея. Его эффект невелик.
Правда, те же рандомизированные исследования в Кении под эгидой World Bank показали, что даже небольшой тренинг для предпринимателей дал +15% к росту по сравнению со средним по рынку. То есть обучение позволяет быть чуть лучше соседа, который не учился, более конкурентоспособным. Но, похоже, оно не может сделать человека богатым, для этого нужно что-то другое.
👍2😁2🤔1
Media is too big
VIEW IN TELEGRAM
Очередной эксперимент с вайб-кодингом, и в этом ролике рассказ не о том, как все получилось, а о том, как зашел в тупик. Начиналось все банально: нужно было согласовать время со студентами дизайн-лаборатории. Сделал простой интерфейс на V0, людям понравилось, мне понравилось и я начал его улучшать. 53 промпта спустя у меня есть система с авторизацией, PIN-кодами, личным кабинетом, админ-панелью и даже с подлюченнием Grafana. Но что-то пошло не так.
Система внешне выглядит рабочей, но внутренняя логика поведения не поддается точному контролю — сценарии использования ломаются, ошибки воспроизводятся вне зависимости от того, используется легкая или reasoning-модель при кодировании. И не хочется прибегать к ручному кодированию, чтобы не переходить границу между вайб-подходом и традиционным методом создания проектов.
Что я попробовал?
Вначале попробовал формализация логики через flow-диаграммы (Mermaid) и sequence-диаграммы. При этом прогнал их через Claude для доводки. И в конце концов, перенес проекта в другой инструмент (Google Gemini) с передачей логики через диаграммы, чтобы проверить как ИИ следует логики диаграмм.
Пока окончательных выводов и результатов по эффективному использовании диаграмм для управления логикой вайб-кодирования у меня нет. Экспериментирую и пробую разные подходы.
Технологии в ролике: V0, Claude (Anthropic), Google Gemini, Mermaid, Sequencediagram.org, Grafana, внешний email-сендер Resend (для PIN-кодов), Supabase в качестве базы данных.
Видео на Ютюбе https://youtu.be/kk9ahzcdgT8
Система внешне выглядит рабочей, но внутренняя логика поведения не поддается точному контролю — сценарии использования ломаются, ошибки воспроизводятся вне зависимости от того, используется легкая или reasoning-модель при кодировании. И не хочется прибегать к ручному кодированию, чтобы не переходить границу между вайб-подходом и традиционным методом создания проектов.
Что я попробовал?
Вначале попробовал формализация логики через flow-диаграммы (Mermaid) и sequence-диаграммы. При этом прогнал их через Claude для доводки. И в конце концов, перенес проекта в другой инструмент (Google Gemini) с передачей логики через диаграммы, чтобы проверить как ИИ следует логики диаграмм.
Пока окончательных выводов и результатов по эффективному использовании диаграмм для управления логикой вайб-кодирования у меня нет. Экспериментирую и пробую разные подходы.
Технологии в ролике: V0, Claude (Anthropic), Google Gemini, Mermaid, Sequencediagram.org, Grafana, внешний email-сендер Resend (для PIN-кодов), Supabase в качестве базы данных.
Видео на Ютюбе https://youtu.be/kk9ahzcdgT8
❤2✍1
Я не раз наблюдал ситуацию, когда владельцы бизнеса или диджитал-продукта инициируют смену дизайна с аргументом, что устали от текущей версии. Иногда это подкрепляется какими-то другими аргументами, но ключевой триггер — это то, что дизайн надоел.
В принципе, есть хорошие исследования, которые говорят о том, что эффектный дизайн действительно работает на все поведенческие метрики. Но я тут сформулировал гипотезу, что эффект новизны от дизайна у владельцев и у пользователей пропадает с разной скоростью, потому что он зависит от частоты контакта с дизайном.
Это не такая уж и новая мысль. Начиная с 1966 года (Thompson, R. F., & Spencer, W. A. (1966). Habituation: A model phenomenon for the study of neuronal substrates of behavior) существует идея о том, что частота и привыкание связаны. Я фактически только предлагаю переложить это в прикладную область диджитал-продуктов.
Иными словами, бизнес склонен нести лишние издержки, связанные с редизайном продуктов, исходя из субъективной оценки устаревания дизайна, когда объективных причин для этого может не быть.
Но вообще редизайн — это любимый ответ на любую непонятную ситуацию. Особенно когда компания достигла потолка роста, потолка эффективности или потолка идей.
В принципе, есть хорошие исследования, которые говорят о том, что эффектный дизайн действительно работает на все поведенческие метрики. Но я тут сформулировал гипотезу, что эффект новизны от дизайна у владельцев и у пользователей пропадает с разной скоростью, потому что он зависит от частоты контакта с дизайном.
Это не такая уж и новая мысль. Начиная с 1966 года (Thompson, R. F., & Spencer, W. A. (1966). Habituation: A model phenomenon for the study of neuronal substrates of behavior) существует идея о том, что частота и привыкание связаны. Я фактически только предлагаю переложить это в прикладную область диджитал-продуктов.
Иными словами, бизнес склонен нести лишние издержки, связанные с редизайном продуктов, исходя из субъективной оценки устаревания дизайна, когда объективных причин для этого может не быть.
Но вообще редизайн — это любимый ответ на любую непонятную ситуацию. Особенно когда компания достигла потолка роста, потолка эффективности или потолка идей.
✍1🔥1💯1
Хорошая статья Дэниела Растона из 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.
По большому счету, ИИ создает вызов в проектировании интерфейсов и всего пользовательского пути, потому что результаты не детерминированы. В традиционном интерфейсе все было предсказуемо, и можно было гарантированно пройти один и тот же путь два раза. Но с интерфейсами, которые подстраиваются под запросы пользователей, этого уже нельзя ожидать. Все интерфейсы с внедренными ИИ-инструментами движутся в сторону персонализированной выдачи и персонализированного контента.
Дэниел пишет о подходах к созданию генеративных интерфейсов. Он предлагает несколько принципов и точек зрения, которые помогут качественнее спроектировать его.
Из нового для меня, понравилась концепция порогового значения достоверности, когда система возвращает разные интерфейсы в зависимости от того, насколько она уверена в ответе. Никогда не думал в этом ключе, но идея кажется очень полезной.
1. Низкий уровень уверенности (<60%): система запрашивает у пользователя уточнения.
2. Средний уровень уверенности (60–90%): система выдаёт предварительное предложение.
3. Высокий уровень уверенности (>90%): система действует и информирует пользователя.
Остальные рекомендации и идеи, в принципе, ожидаемы и вполне вписываются в подход, о котором многие говорят и который я предлагал в докладе 2025 года, когда выступал в рамках Sreda Summer Summit. Там ключевой идеей была мысль о том, что, хотя ИИ привнес много нового, но эвристики Нильсена не устарели и вполне адаптируются под современные технологии. В докладе я, правда, оставил только четыре из них: ясный статус системы, контроль и свобода действий, предотвращение ошибок, понятность и предсказуемость интерфейса. Но этого как раз достаточно для структурирования подхода к созданию OUI.
Medium
The rise of the Orchestrated User Interface (OUI)
Designing for intent in a brave new world.
👍1👀1
Media is too big
VIEW IN TELEGRAM
Сегодня не про один конкретный инструмент, а про целый набор вещей, которые я делаю для учебного проекта со студентами.
Мы разрабатываем студенческий портал, и я захотел сразу сделать все с редакционной политикой и 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
Мы разрабатываем студенческий портал, и я захотел сразу сделать все с редакционной политикой и 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 баланса над валовой эффективностью, найдут поддержку в нашем бизнесе.
Результаты восьмимесячного исследования опубликованы в статье «AI Doesn’t Reduce Work—It Intensifies It».
Внедрение генеративных инструментов повышает производительность сотрудников: они работают быстрее, выполняют большее число задач в более широком круге. Берут на себя задачи, которые раньше передали бы коллегам или не брали бы вообще. Чаще начинают использовать время, которое раньше было отдыхом, чтобы выполнять какие-то задачи через ИИ. Например, перед уходом на перерыв отправляют задание агенту, чтобы, вернувшись, уже видеть результат выполненной работы.
Общение в чате с ИИ меньше напоминает работу, поэтому границы между рабочим и нерабочим пространством размываются. Люди чаще склонны в нерабочее время проверять чаты и продолжать оставаться включенными в рабочий процесс.
Появилась новая многозадачность, когда разным агентам выдаются разные задачи. И это стало возможным потому, что возникает пауза ожидания между постановкой задачи и получением результата и она воспринимается, как ресурс времени, который можно занять.
Все это складывается в новое ожидание относительно скорости выполнения задач. Многие сотрудники отмечали, что им приходится делать больше дел одновременно и испытывать большее давление, чем до внедрения ИИ.
Получается такая петля зависимостей: чем больше мы используем ИИ, тем выше скорость выполнения задач и их количество, тем шире круг задач, которые мы получаем, и тем выше ожидания скорости, с которой мы должны их выполнить. В итоге рост продуктивности выполнения задач не трансформируется в меньшую занятость.
Я помню хороший термин, который использовал один технический директор относительно программистов, — утилизация ресурсов. Он честно говорил, что задача компании в том, чтобы продать 100% времени сотрудника и чтобы сотрудник на 100% времени был занят.
Что же делать, чтобы не загнать себя, как лошадь?
В статье авторы выступают за внедрение практик, которые бы противодействовали потенциальным когнитивным перегрузкам, возникающим за счет увеличения количества выполняемых работ. Они предлагают делать запланированные перерывы, контролировать уведомления, чтобы не отвлекаться лишний раз, структурировать время работы с ИИ вместо постоянного нахождения в рабочем процессе.
Фактически речь идет о том, чтобы более активно планировать не рабочее время, а время на подумать и отдых.
Но, к сожалению, мне представляется маловероятным, что эти идеи, нацеленные на приоритет качества над количеством, и приоритет work-life баланса над валовой эффективностью, найдут поддержку в нашем бизнесе.
Harvard Business Review
AI Doesn’t Reduce Work—It Intensifies It
One of the promises of AI is that it can reduce workloads so employees can focus more on higher-value and more engaging tasks. But according to new research, AI tools don’t reduce work, they consistently intensify it: In the study, employees worked at a faster…
😱1
Некоторые команды уже месяцами не открывают 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 могу сказать, что практически нет людей, которые не готовы включаться в организованный процесс совместной работы. А результат и эмоциональная удовлетворенность участников такой работы всегда на высоком уровне.
Осталось связать методологию совместного дизайна с возможностями ИИ. А для этого нужно просто пробовать такие подходы. И наверняка кто-то уже пробовал и может об этом рассказать. Я же пока с этим экспериментирую в рамках студенческой дизайн-лаборатории. Кто уже пробовал системно совмещать совместный дизайн с ИИ, что сработало?
Ловушка убедительности
В этом тренде меня кое-что настораживает. ИИ-инструменты создают убедительные артефакты, и возникает впечатление, будто они заменяют процесс мышления. Недавняя статья «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 могу сказать, что практически нет людей, которые не готовы включаться в организованный процесс совместной работы. А результат и эмоциональная удовлетворенность участников такой работы всегда на высоком уровне.
Осталось связать методологию совместного дизайна с возможностями ИИ. А для этого нужно просто пробовать такие подходы. И наверняка кто-то уже пробовал и может об этом рассказать. Я же пока с этим экспериментирую в рамках студенческой дизайн-лаборатории. Кто уже пробовал системно совмещать совместный дизайн с ИИ, что сработало?
LinkedIn
We killed Figma from our design workflow. We haven't built a single mockup in months. Here's the journey that got us there and…
We killed Figma from our design workflow. We haven't built a single mockup in months. Here's the journey that got us there and what replaced it 👇
It started innocently.
Like everyone, we began with vibe coding to test quick ideas.
Generate a prototype…
It started innocently.
Like everyone, we began with vibe coding to test quick ideas.
Generate a prototype…