Последний месяц мы с партнером глубоко погружены в проектирование алгоритма для улучшения контекстного поиска. При этом чем дальше мы продвигаемся, тем ближе этап оценки и тестирования качества нашего подхода. Мы понимаем, что ошибки поиска могут возникать на разных уровнях, и наивно фокусироваться только на отдельных аспектах качества, игнорируя при этом всю глубину решаемых задач.
В какой-то момент я решил собрать для себя единый чек-лист тестирования поисковой системы — от самых базовых проверок поискового движка до оценки агентных сценариев и работы с неполными данными. Постепенно это превратилось в структурированную систему проверки, которую можно использовать для аудита поиска. Оформил все в статью на хабре https://habr.com/ru/articles/1057356/
Если последовательно пройти все этапы — от функциональных тестов до проверки качества генерации и поведения системы на неполных данных, то можно понять, до какого уровня сложности задач дотягивает поисковая система и в каком направлении ее нужно улучшать.
Мы с партнером оценивали сколько времени займет обеспечить автоматизированное тестирование от 0 до 3 уровня у нас вышло что-то около 4 недель рабочего времени (это для команды из аналитика и разработчика). И по первым прикидкам, сделать каждый следующий уровень будет требовать такое же количество времени.
В какой-то момент я решил собрать для себя единый чек-лист тестирования поисковой системы — от самых базовых проверок поискового движка до оценки агентных сценариев и работы с неполными данными. Постепенно это превратилось в структурированную систему проверки, которую можно использовать для аудита поиска. Оформил все в статью на хабре https://habr.com/ru/articles/1057356/
Если последовательно пройти все этапы — от функциональных тестов до проверки качества генерации и поведения системы на неполных данных, то можно понять, до какого уровня сложности задач дотягивает поисковая система и в каком направлении ее нужно улучшать.
Мы с партнером оценивали сколько времени займет обеспечить автоматизированное тестирование от 0 до 3 уровня у нас вышло что-то около 4 недель рабочего времени (это для команды из аналитика и разработчика). И по первым прикидкам, сделать каждый следующий уровень будет требовать такое же количество времени.
Всегда есть повод задуматься об эффективности дизайна. И, возможно, сейчас для этого особенно подходящее время: с одной стороны, нас поджимает ИИ, а с другой — экономика движется в сторону создания впечатлений.
Вот статья: https://michalmalewicz.medium.com/popular-design-trends-that-destroy-conversion-3b3a964827cb. Она хорошо иллюстрирует влияние дизайна на эффективность продукта.
Причем, если вы прочитаете статью, то заметите, что в ней много внимания уделено тексту. Можно даже сказать, что именно с текста все начинается. Это понятный посыл, потому что текст является основным инструментом коммуникации с пользователем. Но, к сожалению, дизайнеры чаще начинают не с него.
Есть когнитивное искажение, из-за которого вещи, выглядящие привлекательно, воспринимаются как более функциональные и удобные. Но впечатление, которое дизайн производит на бизнес-заказчика, и впечатление, которое возникает у пользователя, разные. Причина в том, что они решают разные задачи. Один оценивает собственные ощущения от дизайна, второй пытается решить свою конкретную задачу.
Заказчик впечатляется эффектом новизны и остается доволен. Он попадает в когнитивную ловушку и начинает считать дизайн хорошим только потому, что тот ему понравился. Пользователь же движется к своей цели, и здесь эффект новизны быстро исчезает. На первый план выходят трудности, возникающие из-за несоответствия визуального ряда и содержания. Именно они начинают влиять на успешность пользовательских действий.
Если бы компании продолжали проводить UX-тестирования дизайна так же активно, как раньше, то уже на ранних стадиях можно было бы понять, какой дизайн требует улучшений. Но сегодня все больше компаний предпочитают принимать решения, опираясь на впечатления. Владельцы продукта ориентируются на собственное мнение или мнение окружающих. Однако такая оценка всегда вырвана из реального пользовательского пути и, по большому счету, никак не отражает действительность. Исключение составляют только случаи, когда ошибки настолько грубы, что заметны даже без полноценного исследования.
У автора статьи есть тезис, который может не понравиться некоторым дизайнерам: «Для действительно отличного продающего сайта графика не нужна. Начните с текста, шрифтов, иерархии, интервалов, цвета и выделений. И только потом, если вы действительно уверены, что это принесет пользу, подумайте о добавлении изображения».
На мой взгляд, это прекрасный тезис. Хотя на нынешнем этапе развития дизайн-процессов я, скорее всего, остаюсь в меньшинстве.
Есть несколько важных уточнений, которые стоит учитывать, но которые не всегда считываются из статьи.
Дизайн многолик, и правил, работающих в 100% случаев, не существует. Все примеры, приведенные в статье, прежде всего относятся к новым продуктам, с которыми пользователь еще не знаком. Если же речь идет о сильном бренде, то сама сила бренда может настолько влиять на результат, что можно позволить себе почти любую визуальную экстравагантность. При этом в отчете все равно найдутся цифры, демонстрирующие рост и улучшения.
Другое дело, что без некоторых дизайнерских решений этот рост мог бы быть значительно выше. Но проверить это крайне сложно, а чаще всего невозможно. И здесь снова возникает когнитивная ловушка: прирост есть, дизайн нравится владельцам — значит, дизайн успешный, и нужно продолжать делать так же. Хотя на самом деле он может снижать продажи. Просто обычно никто не заинтересован в том, чтобы исследовать столь тонкие причинно-следственные связи.
Но я уже далеко ушел от самой статьи.
В общем, старайтесь не вестись на вау-эффект макетов. Включайте критическое мышление и внимательно читайте тексты. Именно они гораздо чаще определяют успех продукта, чем кажется на первый взгляд. Кстати, недооценка текста, тоже следствие одного из когнитивных искажений.
Вот статья: https://michalmalewicz.medium.com/popular-design-trends-that-destroy-conversion-3b3a964827cb. Она хорошо иллюстрирует влияние дизайна на эффективность продукта.
Причем, если вы прочитаете статью, то заметите, что в ней много внимания уделено тексту. Можно даже сказать, что именно с текста все начинается. Это понятный посыл, потому что текст является основным инструментом коммуникации с пользователем. Но, к сожалению, дизайнеры чаще начинают не с него.
Есть когнитивное искажение, из-за которого вещи, выглядящие привлекательно, воспринимаются как более функциональные и удобные. Но впечатление, которое дизайн производит на бизнес-заказчика, и впечатление, которое возникает у пользователя, разные. Причина в том, что они решают разные задачи. Один оценивает собственные ощущения от дизайна, второй пытается решить свою конкретную задачу.
Заказчик впечатляется эффектом новизны и остается доволен. Он попадает в когнитивную ловушку и начинает считать дизайн хорошим только потому, что тот ему понравился. Пользователь же движется к своей цели, и здесь эффект новизны быстро исчезает. На первый план выходят трудности, возникающие из-за несоответствия визуального ряда и содержания. Именно они начинают влиять на успешность пользовательских действий.
Если бы компании продолжали проводить UX-тестирования дизайна так же активно, как раньше, то уже на ранних стадиях можно было бы понять, какой дизайн требует улучшений. Но сегодня все больше компаний предпочитают принимать решения, опираясь на впечатления. Владельцы продукта ориентируются на собственное мнение или мнение окружающих. Однако такая оценка всегда вырвана из реального пользовательского пути и, по большому счету, никак не отражает действительность. Исключение составляют только случаи, когда ошибки настолько грубы, что заметны даже без полноценного исследования.
У автора статьи есть тезис, который может не понравиться некоторым дизайнерам: «Для действительно отличного продающего сайта графика не нужна. Начните с текста, шрифтов, иерархии, интервалов, цвета и выделений. И только потом, если вы действительно уверены, что это принесет пользу, подумайте о добавлении изображения».
На мой взгляд, это прекрасный тезис. Хотя на нынешнем этапе развития дизайн-процессов я, скорее всего, остаюсь в меньшинстве.
Есть несколько важных уточнений, которые стоит учитывать, но которые не всегда считываются из статьи.
Дизайн многолик, и правил, работающих в 100% случаев, не существует. Все примеры, приведенные в статье, прежде всего относятся к новым продуктам, с которыми пользователь еще не знаком. Если же речь идет о сильном бренде, то сама сила бренда может настолько влиять на результат, что можно позволить себе почти любую визуальную экстравагантность. При этом в отчете все равно найдутся цифры, демонстрирующие рост и улучшения.
Другое дело, что без некоторых дизайнерских решений этот рост мог бы быть значительно выше. Но проверить это крайне сложно, а чаще всего невозможно. И здесь снова возникает когнитивная ловушка: прирост есть, дизайн нравится владельцам — значит, дизайн успешный, и нужно продолжать делать так же. Хотя на самом деле он может снижать продажи. Просто обычно никто не заинтересован в том, чтобы исследовать столь тонкие причинно-следственные связи.
Но я уже далеко ушел от самой статьи.
В общем, старайтесь не вестись на вау-эффект макетов. Включайте критическое мышление и внимательно читайте тексты. Именно они гораздо чаще определяют успех продукта, чем кажется на первый взгляд. Кстати, недооценка текста, тоже следствие одного из когнитивных искажений.
👍2👏1
Недавно написал небольшую статью о проектировании сценария для ИИ-систем https://habr.com/ru/articles/1047426/
С одной стороны, это пример из реального проекта. С другой, когда я сейчас смотрю на сценарий из статьи, он кажется мне простым и вполне очевидным. При этом на каждом этапе работы ИИ можно было бы дополнительно расписать внутренние процессы, чтобы показать цепочку рассуждений модели. Но это уже выходит за рамки того, что мне нужно было для проектирования интерфейса.
Получается интересная цепочка. Чтобы спроектировать интерфейс для ИИ, нужно понимать, как выстраивать диалог с моделью. А чтобы выстраивать такой диалог, неплохо хотя бы на базовом уровне представлять, как работают механизмы рассуждений ИИ, что такое Chain of Thought, Self-Consistency, Self-Critique, оркестрация и Reasoning Pipeline. И вот вы уже стоите на поляне промпт-инжиниринга или агентного дизайна.
Когда дизайнеру надо делать систему с интеграцией ИИ, уже недостаточно думать только об интерфейсе. Все чаще приходится проектировать не экраны, а сам процесс мышления системы. Интересное смешение границ профессий.
С одной стороны, это пример из реального проекта. С другой, когда я сейчас смотрю на сценарий из статьи, он кажется мне простым и вполне очевидным. При этом на каждом этапе работы ИИ можно было бы дополнительно расписать внутренние процессы, чтобы показать цепочку рассуждений модели. Но это уже выходит за рамки того, что мне нужно было для проектирования интерфейса.
Получается интересная цепочка. Чтобы спроектировать интерфейс для ИИ, нужно понимать, как выстраивать диалог с моделью. А чтобы выстраивать такой диалог, неплохо хотя бы на базовом уровне представлять, как работают механизмы рассуждений ИИ, что такое Chain of Thought, Self-Consistency, Self-Critique, оркестрация и Reasoning Pipeline. И вот вы уже стоите на поляне промпт-инжиниринга или агентного дизайна.
Когда дизайнеру надо делать систему с интеграцией ИИ, уже недостаточно думать только об интерфейсе. Все чаще приходится проектировать не экраны, а сам процесс мышления системы. Интересное смешение границ профессий.
👍2
Ilya Strebulaev запустил The Unicorn Board, который содержит данные обо всех американских единорогах: https://www.data-driven.vc/
Каждый может найти там что-то интересное для себя, но я хочу обратить внимание на данные об образовании основателей.
Существует распространенный миф, что для того, чтобы добиться успеха, не нужно учиться, а успешные предприниматели бросают университеты. Однако цифры показывают очевидное преимущество образования для создания компании-единорога. А известные случаи людей, которые бросили учебу и добились успеха, это лишь проявление эффекта выжившего.
Каждый может найти там что-то интересное для себя, но я хочу обратить внимание на данные об образовании основателей.
Существует распространенный миф, что для того, чтобы добиться успеха, не нужно учиться, а успешные предприниматели бросают университеты. Однако цифры показывают очевидное преимущество образования для создания компании-единорога. А известные случаи людей, которые бросили учебу и добились успеха, это лишь проявление эффекта выжившего.
❤1
Кажется, мы движемся к точке, где для облачных моделей будет достаточно промпта из пары предложений, а для локальных придётся писать несколько страниц, чтобы получить сопоставимый результат: подробно описывать шаги рассуждений, ограничения, примеры и критерии проверки. По крайней мере, именно на это указывают свежие рекомендации OpenAI и Anthropic.
Вышли рекомендации по промптингу для новых моделей GPT-5.6 Sol: https://developers.openai.com/api/docs/guides/prompt-guidance-gpt-5p6 и Claude Fable 5: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5.
Общая идея заключается в том, что модели становятся умнее, а промпты при этом нужно делать проще. Это обеспечивает более высокое качество ответов и снижает стоимость обработки запросов.
Обе компании сводят базовые рекомендации к тому, что промпты следует смещать в сторону ясного описания цели, явных ограничений, проверки результата и минимизации описания того, как именно нужно решать задачу. Модели стали умнее, поэтому выбор наиболее эффективного способа решения лучше оставлять за ними.
Сама OpenAI по результатам внутренних тестов оценивает возможную экономию за счёт упрощения промптов (без повторяющихся инструкций, чрезмерного описания шагов и лишних ограничений) в 33–67% в денежном выражении. А это, надо сказать, очень приличные деньги.
В качестве универсального шаблона для сложных задач OpenAI предлагает использовать следующий вариант:
Но важно помнить, что результаты работы промптов нужно проверять при смене модели. Это касается и проектов, и навыков, которые мы уже успели создать для автоматизации своих рутинных задач.
При этом уже заметно, что начинают расходиться лучшие практики промптинга для работы с передовыми облачными моделями и с моделями, которые можно запускать локально. И хотя Colibri позволяет запускать дома большую модель GLM-5.2 (https://github.com/JustVugg/colibri), подходы, эффективные для самых новых моделей, уже не являются универсальными, и, скорее всего, этот разрыв будет только увеличиваться.
Вышли рекомендации по промптингу для новых моделей GPT-5.6 Sol: https://developers.openai.com/api/docs/guides/prompt-guidance-gpt-5p6 и Claude Fable 5: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5.
Общая идея заключается в том, что модели становятся умнее, а промпты при этом нужно делать проще. Это обеспечивает более высокое качество ответов и снижает стоимость обработки запросов.
Обе компании сводят базовые рекомендации к тому, что промпты следует смещать в сторону ясного описания цели, явных ограничений, проверки результата и минимизации описания того, как именно нужно решать задачу. Модели стали умнее, поэтому выбор наиболее эффективного способа решения лучше оставлять за ними.
Сама OpenAI по результатам внутренних тестов оценивает возможную экономию за счёт упрощения промптов (без повторяющихся инструкций, чрезмерного описания шагов и лишних ограничений) в 33–67% в денежном выражении. А это, надо сказать, очень приличные деньги.
В качестве универсального шаблона для сложных задач OpenAI предлагает использовать следующий вариант:
Роль: [функция и контекст модели]
Личность: [тон и стиль взаимодействия]
Цель: [результат, видимый пользователю]
Критерии успеха: [что должно быть выполнено до получения окончательного ответа]
Ограничения: [политика, безопасность, бизнес-требования, требования к доказательствам и ограничения, связанные с побочными эффектами]
Инструменты: [какие инструменты использовать, когда их использовать и какие не использовать]
Выходные данные: [структура, длина, формат и тон ответа]
Правила остановки: [когда повторить попытку, вернуться к предыдущему варианту, воздержаться от ответа, задать уточняющий вопрос или остановиться]
Но важно помнить, что результаты работы промптов нужно проверять при смене модели. Это касается и проектов, и навыков, которые мы уже успели создать для автоматизации своих рутинных задач.
При этом уже заметно, что начинают расходиться лучшие практики промптинга для работы с передовыми облачными моделями и с моделями, которые можно запускать локально. И хотя Colibri позволяет запускать дома большую модель GLM-5.2 (https://github.com/JustVugg/colibri), подходы, эффективные для самых новых моделей, уже не являются универсальными, и, скорее всего, этот разрыв будет только увеличиваться.
OpenAI Developers
Model guidance | OpenAI API
Compare model features, migration guidance, and prompting best practices across OpenAI models.
🔥3
Для тех, кто хочет улучшить работу своих промптов для решения задач с помощью ИИ, есть интересный метод, описанный в статье: https://arxiv.org/html/2607.01942v1
Авторы предлагают рекурсивно компилировать задачу в направленный граф, где каждый узел — это атомарный вызов инструмента. Для каждой атомарной задачи сохраняются входные и выходные данные, включая всю историю эволюции графа, а независимые ветки могут выполняться параллельно.
За счет сохранения промежуточных данных в выполняемых узлах можно восстановить работу после сбоя или заниматься точечным улучшением алгоритма.
Хоть работа с ИИ по своей природе и не является детерминированной, атомарный подход пытается создать детерминированное пространство за счет формирования атомарных задач.
Исследователи отмечают, что предложенный ими подход уменьшает количество необходимых шагов для решения задач, снижает уровень галлюцинаций и ошибок.
Нельзя сказать, что этот метод очень инновационен — скорее, это развитие существующих подходов к решению задач с помощью ИИ. При этом самые передовые LLM-модели, наоборот, уходят от необходимости как-либо декомпозировать для них задачи, больше полагаясь на собственные способности находить правильные ответы. Но при этом все больше пользователей запускают локальные модели или используют более дешевые модели, не обладающие столь сильными способностями к рассуждению. И очевидно, что именно при работе с такими моделями (размера 7B-13B) такой более эффективный способ постановки задачи будет давать наибольшую отдачу.
Авторы предлагают рекурсивно компилировать задачу в направленный граф, где каждый узел — это атомарный вызов инструмента. Для каждой атомарной задачи сохраняются входные и выходные данные, включая всю историю эволюции графа, а независимые ветки могут выполняться параллельно.
За счет сохранения промежуточных данных в выполняемых узлах можно восстановить работу после сбоя или заниматься точечным улучшением алгоритма.
Хоть работа с ИИ по своей природе и не является детерминированной, атомарный подход пытается создать детерминированное пространство за счет формирования атомарных задач.
Исследователи отмечают, что предложенный ими подход уменьшает количество необходимых шагов для решения задач, снижает уровень галлюцинаций и ошибок.
Нельзя сказать, что этот метод очень инновационен — скорее, это развитие существующих подходов к решению задач с помощью ИИ. При этом самые передовые LLM-модели, наоборот, уходят от необходимости как-либо декомпозировать для них задачи, больше полагаясь на собственные способности находить правильные ответы. Но при этом все больше пользователей запускают локальные модели или используют более дешевые модели, не обладающие столь сильными способностями к рассуждению. И очевидно, что именно при работе с такими моделями (размера 7B-13B) такой более эффективный способ постановки задачи будет давать наибольшую отдачу.
👍3
Gartner прогнозирует, что расходы на токены для ИИ-моделей превысят среднюю зарплату разработчика уже в 2028 году, что ставит под сомнение обоснованность таких затрат. https://www.gartner.com/en/newsroom/press-releases/2026-06-24-gartner-predicts-ai-coding-costs-will-surpass-average-developer-salary-by-2028-as-token-consumption-surges
Пока мы живем в эпоху социалистических цен на токены, кажется, что на нас льется водопад невиданной производительности. Но если придется платить реальные деньги за использование моделей, то вся экономика начнет трещать по швам. Переход же к локальным моделям, очевидно, будет сопряжен с просадкой продуктивности в широком круге задач и более высокими требованиями к организации работы, чтобы получать сопоставимый уровень качества.
Вопрос в том, хватит ли задела, созданного за время бурного роста отрасли, когда бизнес был готов вкладывать средства в захват доли рынка, чтобы создать достаточно мощные локальные модели, которые не будут выглядеть как дилижанс на хайвее по сравнению с передовыми LLM. Очевидно, что до эпохи очень дешевой электроэнергии мы все равно не дотянем, даже если уже завтра кто-то создаст действующий термоядерный реактор. А скорость снижения цен на токены за счет оптимизации и эффекта масштаба не успевает за скоростью роста их потребления.
Казалось бы, возможности, которые ИИ создал для компаний в реализации цифровых идей, должны быть видимыми и ощутимыми, потому что скорость разработки ускорилась на порядок. Но мы не видим заметных изменений.
У меня есть предположение, что по-настоящему стоящие идеи крупные компании успешно реализовывали и без ИИ. Не было никаких технических ограничений, чтобы внедрить функциональность, которая приносит ощутимый результат. Единственным по-настоящему непреодолимым барьером было отсутствие видимой потребности в новых внедрениях со стороны владельцев бизнеса.
Появление ИИ-моделей лишь помогло в какой-то момент увеличить скорость разработки, но не увеличило количество хороших идей в бизнесе. В то же время отсутствие дисциплины в использовании ИИ приводит к неконтролируемому росту затрат на токены без видимой отдачи.
Приходит на ум русская пословица: «Заставь дурака Богу молиться — он и лоб расшибет». Не стали ли во многом компании сейчас заложниками такого подхода в области ИИ? Только, в отличие от пословицы, где результат глупого действия сразу виден, результат работы ИИ-моделей в бизнесе выглядит как убедительные артефакты, полные смысла, но при этом не создающие никакой дополнительной ценности.
У Gartner есть дельные советы о том, как улучшить работу с ИИ в рамках компании. Но самый рабочий, на мой взгляд, такой же старый, как и сам процесс менеджмента: проводить регулярные проверки рабочих процессов с высоким потреблением токенов в рамках ретроспективы спринтов, совершенствовать методы работы и обмениваться знаниями между командами.
Пока мы живем в эпоху социалистических цен на токены, кажется, что на нас льется водопад невиданной производительности. Но если придется платить реальные деньги за использование моделей, то вся экономика начнет трещать по швам. Переход же к локальным моделям, очевидно, будет сопряжен с просадкой продуктивности в широком круге задач и более высокими требованиями к организации работы, чтобы получать сопоставимый уровень качества.
Вопрос в том, хватит ли задела, созданного за время бурного роста отрасли, когда бизнес был готов вкладывать средства в захват доли рынка, чтобы создать достаточно мощные локальные модели, которые не будут выглядеть как дилижанс на хайвее по сравнению с передовыми LLM. Очевидно, что до эпохи очень дешевой электроэнергии мы все равно не дотянем, даже если уже завтра кто-то создаст действующий термоядерный реактор. А скорость снижения цен на токены за счет оптимизации и эффекта масштаба не успевает за скоростью роста их потребления.
Казалось бы, возможности, которые ИИ создал для компаний в реализации цифровых идей, должны быть видимыми и ощутимыми, потому что скорость разработки ускорилась на порядок. Но мы не видим заметных изменений.
У меня есть предположение, что по-настоящему стоящие идеи крупные компании успешно реализовывали и без ИИ. Не было никаких технических ограничений, чтобы внедрить функциональность, которая приносит ощутимый результат. Единственным по-настоящему непреодолимым барьером было отсутствие видимой потребности в новых внедрениях со стороны владельцев бизнеса.
Появление ИИ-моделей лишь помогло в какой-то момент увеличить скорость разработки, но не увеличило количество хороших идей в бизнесе. В то же время отсутствие дисциплины в использовании ИИ приводит к неконтролируемому росту затрат на токены без видимой отдачи.
Приходит на ум русская пословица: «Заставь дурака Богу молиться — он и лоб расшибет». Не стали ли во многом компании сейчас заложниками такого подхода в области ИИ? Только, в отличие от пословицы, где результат глупого действия сразу виден, результат работы ИИ-моделей в бизнесе выглядит как убедительные артефакты, полные смысла, но при этом не создающие никакой дополнительной ценности.
У Gartner есть дельные советы о том, как улучшить работу с ИИ в рамках компании. Но самый рабочий, на мой взгляд, такой же старый, как и сам процесс менеджмента: проводить регулярные проверки рабочих процессов с высоким потреблением токенов в рамках ретроспективы спринтов, совершенствовать методы работы и обмениваться знаниями между командами.
Gartner
By 2028, AI coding costs will overtake the average developer’s salary
Gartner_inc Predicts AI Coding Costs Will Surpass Average Developer’s Salary by 2028 as #TokenConsumption Surges. Read more here. #GartnerIT #Tokencosts
Бывает, что в статье меня цепляет не основное содержание, а какой-нибудь факт второго порядка. Вот, например, я смотрел материалы по практикам SDD (spec-driven development), в том числе https://www.techtarget.com/searchitoperations/news/366645858/Atlassian-Jira-Planner-joins-spec-driven-development-AI-coding-trend
«Общеизвестно, что на этап кодирования приходится всего около 15–16% времени, которое разработчики тратят на протяжении всего жизненного цикла разработки программного обеспечения, поэтому более 84% этого времени является узким местом, снижающим производительность. Поэтому, несмотря на то, что средний уровень внедрения агентов в отрасли сейчас превышает 90%, прирост производительности фактически стабилизировался на уровне 10–15%, и этап планирования является одной из проблемных точек, которые мы выявили» — эти слова Ming Wu (руководителя отдела разработки DevAI в Atlassian) меня зацепили.
Если поверить, что сотрудники Atlassian в своих словах правильно оценивают отраслевые практики, то можно понять, почему внедрение ИИ не дает значительного эффекта в продуктовой разработке. С одной стороны, есть широко обсуждаемые примеры получения быстрых результатов за счет ИИ-кодинга, но, фокусируясь на этих примерах, мы очевидно упускаем широкую картину отрасли. А работа в этой отрасли состоит в основном не из программирования. И сокращения времени на программирование недостаточно, чтобы получить значимые изменения.
И, возможно, мы стоим на пороге более глобальных изменений процессов в ИТ, чем просто ускорение отдельных процессов за счет внедрения ИИ.
Если представить, что цель всей активности в ИТ — не просто написание кода, а создание полезных решений и продуктов, то, может быть, программирование и не являлось никогда узким местом этого процесса. А всякие попытки улучшений, сделанные не в узком месте, являются иллюзией продуктивности.
Это как всякого рода дашборды, которые любили строить менеджеры, но которые в большинстве случаев никак не влияли на эффективность принятия решений. Видимо, таких дашбордов было напрограммировано так много, что любой ИИ сейчас прекрасно решает задачу кодинга еще одного такого же пустого, но красивого дашборда.
У Фредерика Брукса в статье No Silver Bullet (1986) была идея, что у разработки ПО есть две стороны: присущие сложности (essence) самой задачи (концепции, интерфейсы, поведение системы, изменения требований) и случайные сложности, возникающие из-за несовершенства инструментов и методов. Фактически случайную сложность ИИ нам сейчас полностью снимает.
Но присущая сложность задачи разработки, глобально, осталась почти без изменений. А она как раз заключается в описании спецификации, проектировании концептуальной совокупности взаимосвязанных элементов, алгоритмов, функций системы — и все это в условиях пользовательских ограничений и специфики среды использования. И, может быть, именно изменение подходов к работе с этой сложностью позволит перейти от простого ускорения отдельных этапов к изменению самого процесса создания цифровых продуктов.
«Общеизвестно, что на этап кодирования приходится всего около 15–16% времени, которое разработчики тратят на протяжении всего жизненного цикла разработки программного обеспечения, поэтому более 84% этого времени является узким местом, снижающим производительность. Поэтому, несмотря на то, что средний уровень внедрения агентов в отрасли сейчас превышает 90%, прирост производительности фактически стабилизировался на уровне 10–15%, и этап планирования является одной из проблемных точек, которые мы выявили» — эти слова Ming Wu (руководителя отдела разработки DevAI в Atlassian) меня зацепили.
Если поверить, что сотрудники Atlassian в своих словах правильно оценивают отраслевые практики, то можно понять, почему внедрение ИИ не дает значительного эффекта в продуктовой разработке. С одной стороны, есть широко обсуждаемые примеры получения быстрых результатов за счет ИИ-кодинга, но, фокусируясь на этих примерах, мы очевидно упускаем широкую картину отрасли. А работа в этой отрасли состоит в основном не из программирования. И сокращения времени на программирование недостаточно, чтобы получить значимые изменения.
И, возможно, мы стоим на пороге более глобальных изменений процессов в ИТ, чем просто ускорение отдельных процессов за счет внедрения ИИ.
Если представить, что цель всей активности в ИТ — не просто написание кода, а создание полезных решений и продуктов, то, может быть, программирование и не являлось никогда узким местом этого процесса. А всякие попытки улучшений, сделанные не в узком месте, являются иллюзией продуктивности.
Это как всякого рода дашборды, которые любили строить менеджеры, но которые в большинстве случаев никак не влияли на эффективность принятия решений. Видимо, таких дашбордов было напрограммировано так много, что любой ИИ сейчас прекрасно решает задачу кодинга еще одного такого же пустого, но красивого дашборда.
У Фредерика Брукса в статье No Silver Bullet (1986) была идея, что у разработки ПО есть две стороны: присущие сложности (essence) самой задачи (концепции, интерфейсы, поведение системы, изменения требований) и случайные сложности, возникающие из-за несовершенства инструментов и методов. Фактически случайную сложность ИИ нам сейчас полностью снимает.
Но присущая сложность задачи разработки, глобально, осталась почти без изменений. А она как раз заключается в описании спецификации, проектировании концептуальной совокупности взаимосвязанных элементов, алгоритмов, функций системы — и все это в условиях пользовательских ограничений и специфики среды использования. И, может быть, именно изменение подходов к работе с этой сложностью позволит перейти от простого ускорения отдельных этапов к изменению самого процесса создания цифровых продуктов.
Search IT Operations
Atlassian Jira Planner joins spec-driven development AI coding trend
Atlassian's Jira Planner aims to improve AI coding efficiency earlier in the planning stage, alleviating downstream release issues.
👍1
Если раньше вложения в CX отличали отраслевых лидеров, то теперь, видимо, их будет отличать вложение в автоматизацию CX с помощью ИИ. И сейчас открываются большие возможности для консультантов и экспертов в области CX, чтобы драйвить такие изменения.
Например, у McKinsey есть матрица приоритетных направлений для внедрения ИИ в области улучшения клиентского опыта. В топе шесть отличных вариантов, которые можно рассматривать для внедрения, когда у вас есть KPI по изменениям на основе ИИ, но вы при этом хотите, чтобы это потенциально принесло пользу и измеримый результат, а не стало просто очередным прожектом.
Next-best action: Анализирует сигналы в реальном времени из всех доступных каналов и выбирает наиболее подходящее действие для клиента в конкретный момент.
Account setup and configuration: Автоматизирует настройку и активацию аккаунта, проводя клиента через необходимые шаги. Агент может выполнить часть действий самостоятельно или сделать это за клиента.
Shopping and solution exploration: Помогает клиенту подобрать оптимальный продукт или решение с учетом его контекста, потребностей и предыдущих действий. Это повышает вероятность конверсии и увеличивает объем покупки.
Contact-center issue resolution: Автоматизирует решение типовых обращений в контакт-центре. Агент самостоятельно обрабатывает распространенные проблемы, а нестандартные случаи передает сотруднику для дальнейшего решения. Это снижает операционные затраты и повышает качество клиентского сервиса.
Personalized case management: Собирает всю необходимую информацию о клиенте и его ситуации, чтобы агент мог решить вопрос с минимальным количеством уточнений и передач между сотрудниками. Клиент получает персонализированный сервис, а обращение быстрее проходит от начала до решения.
Opportunity nurturing and retention: Выявляет подходящие моменты для персонализированного взаимодействия с клиентом — например, чтобы предложить следующий продукт, вернуть клиента или предотвратить его уход. Это помогает снижать отток и создавать новые возможности для роста.
Полный текст статьи: https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/rewiring-customer-experience-for-the-agentic-era
Например, у McKinsey есть матрица приоритетных направлений для внедрения ИИ в области улучшения клиентского опыта. В топе шесть отличных вариантов, которые можно рассматривать для внедрения, когда у вас есть KPI по изменениям на основе ИИ, но вы при этом хотите, чтобы это потенциально принесло пользу и измеримый результат, а не стало просто очередным прожектом.
Next-best action: Анализирует сигналы в реальном времени из всех доступных каналов и выбирает наиболее подходящее действие для клиента в конкретный момент.
Account setup and configuration: Автоматизирует настройку и активацию аккаунта, проводя клиента через необходимые шаги. Агент может выполнить часть действий самостоятельно или сделать это за клиента.
Shopping and solution exploration: Помогает клиенту подобрать оптимальный продукт или решение с учетом его контекста, потребностей и предыдущих действий. Это повышает вероятность конверсии и увеличивает объем покупки.
Contact-center issue resolution: Автоматизирует решение типовых обращений в контакт-центре. Агент самостоятельно обрабатывает распространенные проблемы, а нестандартные случаи передает сотруднику для дальнейшего решения. Это снижает операционные затраты и повышает качество клиентского сервиса.
Personalized case management: Собирает всю необходимую информацию о клиенте и его ситуации, чтобы агент мог решить вопрос с минимальным количеством уточнений и передач между сотрудниками. Клиент получает персонализированный сервис, а обращение быстрее проходит от начала до решения.
Opportunity nurturing and retention: Выявляет подходящие моменты для персонализированного взаимодействия с клиентом — например, чтобы предложить следующий продукт, вернуть клиента или предотвратить его уход. Это помогает снижать отток и создавать новые возможности для роста.
Полный текст статьи: https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/rewiring-customer-experience-for-the-agentic-era
Первоначальная задумка деградирует по мере воплощения, когда не на что опереться при проектировании — нет рабочего примера, нет итерационного процесса дизайна продукта. Я на этой неделе в этом убедился на собственном опыте, потратив день на попытку собрать проект для SDD-подхода (Specification-Driven Development). Идея была в том, чтобы через ИИ раскладывать бизнес-описание проекта на требования, требования — на задачи, а декомпозированные фичи визуально связывать в цепочки для дальнейшего кодирования.
Вот как ИИ описал итоговый проект, который собрал:
«Локальный AI-инструмент, превращающий описание проекта в редактируемый граф + текст: идея → структура → зависимости → исполнение → обратная связь. Не очередной AI-планировщик со списком задач, а инструмент моделирования проекта, где AI работает прямо над моделью (узлы, типизированные связи, релизы) и меняет ее только через подтвержденные изменения».
Но, если честно, то все это оказалось полной мутью — бессмысленным набором функций, который вообще нельзя использовать с пользой. В рабочей папке лежит 510 мегабайт работающего мусора.
Это как взять LEGO-конструктор и собирать его случайным образом — только вместо кубиков тут наборы сценариев и код, который их отрабатывает. Результат получается бессмысленным, хотя в случае с ИИ он выглядит как что-то умное. А текстовое описание всего этого так вообще мечта копирайтера.
Придется мне забрать какие-то полезные идеи и пересобирать проект в полуручном режиме, начать с отрисовки прототипов и детального описания ожидаемых результатов и функционирования отдельных элементов.
Вот как ИИ описал итоговый проект, который собрал:
«Локальный AI-инструмент, превращающий описание проекта в редактируемый граф + текст: идея → структура → зависимости → исполнение → обратная связь. Не очередной AI-планировщик со списком задач, а инструмент моделирования проекта, где AI работает прямо над моделью (узлы, типизированные связи, релизы) и меняет ее только через подтвержденные изменения».
Но, если честно, то все это оказалось полной мутью — бессмысленным набором функций, который вообще нельзя использовать с пользой. В рабочей папке лежит 510 мегабайт работающего мусора.
Это как взять LEGO-конструктор и собирать его случайным образом — только вместо кубиков тут наборы сценариев и код, который их отрабатывает. Результат получается бессмысленным, хотя в случае с ИИ он выглядит как что-то умное. А текстовое описание всего этого так вообще мечта копирайтера.
Придется мне забрать какие-то полезные идеи и пересобирать проект в полуручном режиме, начать с отрисовки прототипов и детального описания ожидаемых результатов и функционирования отдельных элементов.
😁1
Mistral выпустили небольшую модель Shieldstral размером 3B, заточенную под оценку безопасности, которая показывает эффективность на уровне моделей куда большего размера: https://mistral.ai/news/shieldstral/
Мне кажется, это один из примеров того, куда двигаются специализированные модели, которые не требуют дорогого железа и которые можно развернуть внутри своего контура.
Модель прямо напрашивается на то, чтобы на её основе запускали оценку для форумов или изданий, где появляется большое количество контента, создаваемого пользователями.
Русский язык уже в модели, так что можно пробовать использовать её для корпоративных нужд.
Я помню, как «Комсомольская правда» отказалась от пользовательских комментариев, потому что не могла их модерировать, а даже в отсутствие военных действий туда прилетали вещи, которые нарушали все возможные законы. Сейчас же вполне можно собрать политику для модели и обеспечить автоматическую проверку пользовательского контента на безопасность.
Или можно использовать для корпоративных чатов, и через эту модель проверять сообщения от ии-ботов и создать на ее основе этого дополнительную линию защиты, чтобы боты не выдали коммерческую тайну.
Хорошие возможности, которые можно крутить на железе всего за 100 000 рублей и даже дешевле.
Мне кажется, это один из примеров того, куда двигаются специализированные модели, которые не требуют дорогого железа и которые можно развернуть внутри своего контура.
Модель прямо напрашивается на то, чтобы на её основе запускали оценку для форумов или изданий, где появляется большое количество контента, создаваемого пользователями.
Русский язык уже в модели, так что можно пробовать использовать её для корпоративных нужд.
Я помню, как «Комсомольская правда» отказалась от пользовательских комментариев, потому что не могла их модерировать, а даже в отсутствие военных действий туда прилетали вещи, которые нарушали все возможные законы. Сейчас же вполне можно собрать политику для модели и обеспечить автоматическую проверку пользовательского контента на безопасность.
Или можно использовать для корпоративных чатов, и через эту модель проверять сообщения от ии-ботов и создать на ее основе этого дополнительную линию защиты, чтобы боты не выдали коммерческую тайну.
Хорошие возможности, которые можно крутить на железе всего за 100 000 рублей и даже дешевле.
Mistral AI
Introducing Shieldstral. | Mistral AI
Shieldstral introduces a 3B open-weights multimodal safety classifier that outperforms models up to 7x its size.
👍1
SDD (Spec-Driven Development) становится новым стандартом разработки в эпоху ИИ, и для тех, кто вообще в это не погружен, можно попробовать сделать легкий первый шаг через AWS Kiro. Это среда разработки со встроенными ИИ-агентами, созданная компанией Amazon Web Services на базе Code OSS (форка VS Code).
В этом инструменте сразу есть несколько режимов работы, в том числе режим планирования и спецификации, что снимает необходимость внимательно следить за тем, какие промпты пишешь, и позволяет сосредоточиться исключительно на описании задачи и результате, а потом перестроить это во вменяемые требования.
Amazon щедро выдает бесплатно 50 кредитов в месяц, что, по моим прикидкам, эквивалентно 2 долларам в V0. Этого объема токенов не хватит на то, чтобы собрать что-то интересное, но если вы потратите их на планирование и спецификацию своего проекта, то можно убить сразу двух зайцев: пощупать, как на подход к разработке через SDD смотрит одна из лучших ИТ-компаний мира, и получить спецификацию своего проекта на уровне детальной проработки — считай, задаром.
В этом инструменте сразу есть несколько режимов работы, в том числе режим планирования и спецификации, что снимает необходимость внимательно следить за тем, какие промпты пишешь, и позволяет сосредоточиться исключительно на описании задачи и результате, а потом перестроить это во вменяемые требования.
Amazon щедро выдает бесплатно 50 кредитов в месяц, что, по моим прикидкам, эквивалентно 2 долларам в V0. Этого объема токенов не хватит на то, чтобы собрать что-то интересное, но если вы потратите их на планирование и спецификацию своего проекта, то можно убить сразу двух зайцев: пощупать, как на подход к разработке через SDD смотрит одна из лучших ИТ-компаний мира, и получить спецификацию своего проекта на уровне детальной проработки — считай, задаром.
kiro.dev
Kiro: Move beyond AI coding to agentic engineering
Kiro helps developers and teams do their best work: turn prompts into executable specs, validate code correctness to find bugs unit tests miss, and build across large codebases with parallel agents that learn from every session.
👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Странную штуку для себя обнаружил на этой неделе: QWEN справляется с задачей лучше, чем ChatGPT или Grok. Claude сделал неплохо, но все равно хуже.
Мне надо было сделать хитрый анимированный фон по примеру из картинки, и QWEN лучше понял задачу и быстрее сделал что-то вменяемое. Причем я не утруждал себя написанием разных промптов, а просто всем моделям давал одну и ту же задачу.
А итоговый вариант из QWEN скопировал в V0, чтобы можно было тонко настроить параметры анимации под проект и потом уже портировать код дальше.
Вот что получилось в итоге https://mercury-b-d-institut.vercel.app/back.html?visc=1&detail=2&blur=16&bands=5&ew=0.2&glow=0.7&speed=0.095&huespeed=0.045&edgeshift=0&edgesat=0.45&brightness=1.29&overlayopacity=0.05&col0=%23c7bae8&col1=%23f5c7db&col2=%23cfeccb&col3=%23b8c4ec&col4=%23f7efcc&overlay=%23ffffff&blendmode=normal
Я уверен, что все перечисленные модели в состоянии выдать похожий результат. У меня есть гипотеза, что сильно умные модели предпочитают вначале делать простые варианты в ответ на запрос пользователя, экономя таким образом ресурсы. А у QWEN такой маршрутизации нет.
Хотя, скорее всего, это просто спекулятивная догадка с моей стороны, а результат вполне может быть объяснён простой случайностью и небольшой разницей в обучении моделей.
Мне надо было сделать хитрый анимированный фон по примеру из картинки, и QWEN лучше понял задачу и быстрее сделал что-то вменяемое. Причем я не утруждал себя написанием разных промптов, а просто всем моделям давал одну и ту же задачу.
А итоговый вариант из QWEN скопировал в V0, чтобы можно было тонко настроить параметры анимации под проект и потом уже портировать код дальше.
Вот что получилось в итоге https://mercury-b-d-institut.vercel.app/back.html?visc=1&detail=2&blur=16&bands=5&ew=0.2&glow=0.7&speed=0.095&huespeed=0.045&edgeshift=0&edgesat=0.45&brightness=1.29&overlayopacity=0.05&col0=%23c7bae8&col1=%23f5c7db&col2=%23cfeccb&col3=%23b8c4ec&col4=%23f7efcc&overlay=%23ffffff&blendmode=normal
Я уверен, что все перечисленные модели в состоянии выдать похожий результат. У меня есть гипотеза, что сильно умные модели предпочитают вначале делать простые варианты в ответ на запрос пользователя, экономя таким образом ресурсы. А у QWEN такой маршрутизации нет.
Хотя, скорее всего, это просто спекулятивная догадка с моей стороны, а результат вполне может быть объяснён простой случайностью и небольшой разницей в обучении моделей.
В блоге компании Section AI, которая специализируется на корпоративном обучении в области ИИ, вышла статья https://www.sectionai.com/blog/what-should-be-in-your-ai-budget-for-2027 о том, какой корпоративный бюджет нужно заложить в 2027 году на ИИ.
Хоть этот материал рассчитан на американских предпринимателей, но в силу того, что ИИ является международным товаром, это может быть хорошим ориентиром для тех, кто занят планированием расходов на ИИ. И важно, что расчет сделан с позиции внедрения ИИ в текущую работу, трансформацию внутренних процессов, а не с расчетом создания новых продуктов. Т. е. сколько нужно тратить в нашей новой ИИ-стране чудес, чтобы оставаться на одном уровне с лидерами.
Расходы были посчитаны исходя из компании в 1000 человек.
1. Лицензии на ИИ. $480 на человека с учетом корпоративных скидок — Claude, ChatGPT Enterprise, Gemini и т. д. Но можно попробовать начать с самого дешевого тарифа, сейчас он у большинства крупнейших компаний стоит $20.
2. Затраты на токены. Наиболее недооцениваемая часть расходов на ИИ. Для специалиста интеллектуального труда — от 2000 до 5000 долларов в год (2–5% от заработной платы). Для инженера — от 10 000 до 14 000 долларов (5–7% от заработной платы). Все это с учетом высоких зарплат американских специалистов. В нашей же реальности актуальным становится подход с использованием разных моделей. И в итоге выигрышной стратегией становится микс, например, Qwen для массовых задач + Claude для сложных. При хорошей маршрутизации такой подход может дать экономию в 70–90% на токенах без потери качества.
3. Бюджет на ИИ-агентов. Агенты могут потреблять много токенов. Агенты, которые работают в связке с другими агентами, даже склонны к этому, если не контролировать расходы на токены. Но это как раз тот уровень проникновения ИИ-технологии, который может дать результат в рамках всей компании, а не просто как средство персонального перформанса.
Считается, что компания на 1000 человек к концу года запустит 20 ИИ-агентов, которые будут стоить $1500–$2000 в месяц. Соответственно, если такие агенты будут работать на более дешевых моделях, то можно тратить на них в 10–40 раз меньше средств, но тут становится важным вопрос проектирования и маршрутизации. Важно для каждой задачи выбирать ИИ соразмерно сложности задачи, и уже на этом можно сэкономить значительные средства.
4. Руководитель отдела ИИ. Для внедрения ИИ в корпоративную практику нужен человек, который будет обладать достаточными полномочиями и компетенциями, чтобы драйвить этот процесс. В США такой сотрудник обойдется от 200 000 до 400 000 долларов в год.
5. Обеспечение системной трансформации за счет обучения сотрудников, поддержки консультантов, проведения мероприятий, поддержки сотрудников-лидеров трансформации.
По оценке Section, расходы в США на ИИ-трансформацию компании из 1000 человек за год составят 6,6 миллиона долларов, или 6% от общих расходов на зарплату, что эквивалентно найму 60 новых сотрудников. Ну или увольнению 60 сотрудников (или отказу от найма новых 60 сотрудников вместо тех, кто по естественным причинам покинул компанию), чтобы покрыть эти расходы.
Если говорить о других источниках финансирования ИИ-перехода, кроме увольнений, то на первое место выходит сокращение расходов на поставщиков услуг аутсорсинга: дизайн, разработка, поддержка, исследования. Привлечение меньшего количества внешних специалистов за счет использования ИИ дает экономию, которая оправдывает расходы на ИИ.
Сейчас компании используют много SaaS-решений и часто покупают лицензии, которые им не нужны. Оптимизация этих затрат за счет отказа от тех функций, которые сейчас берёт на себя ИИ, и за счет сокращения расходов на неиспользуемые лицензии тоже послужит хорошим оправданием увеличения расходов на ИИ.
Нужно планировать расходы на ИИ и на его внедрение. Начинать можно и с малого, важнее просто наличие стратегии в этом вопросе и продуманного плана. А то придётся, как мне сейчас, упрашивать бухгалтерию оплатить подписку на ИИ вне финансовых планов. И хоть сумма там смешная, но волокиты это не уменьшает.
Хоть этот материал рассчитан на американских предпринимателей, но в силу того, что ИИ является международным товаром, это может быть хорошим ориентиром для тех, кто занят планированием расходов на ИИ. И важно, что расчет сделан с позиции внедрения ИИ в текущую работу, трансформацию внутренних процессов, а не с расчетом создания новых продуктов. Т. е. сколько нужно тратить в нашей новой ИИ-стране чудес, чтобы оставаться на одном уровне с лидерами.
Расходы были посчитаны исходя из компании в 1000 человек.
1. Лицензии на ИИ. $480 на человека с учетом корпоративных скидок — Claude, ChatGPT Enterprise, Gemini и т. д. Но можно попробовать начать с самого дешевого тарифа, сейчас он у большинства крупнейших компаний стоит $20.
2. Затраты на токены. Наиболее недооцениваемая часть расходов на ИИ. Для специалиста интеллектуального труда — от 2000 до 5000 долларов в год (2–5% от заработной платы). Для инженера — от 10 000 до 14 000 долларов (5–7% от заработной платы). Все это с учетом высоких зарплат американских специалистов. В нашей же реальности актуальным становится подход с использованием разных моделей. И в итоге выигрышной стратегией становится микс, например, Qwen для массовых задач + Claude для сложных. При хорошей маршрутизации такой подход может дать экономию в 70–90% на токенах без потери качества.
3. Бюджет на ИИ-агентов. Агенты могут потреблять много токенов. Агенты, которые работают в связке с другими агентами, даже склонны к этому, если не контролировать расходы на токены. Но это как раз тот уровень проникновения ИИ-технологии, который может дать результат в рамках всей компании, а не просто как средство персонального перформанса.
Считается, что компания на 1000 человек к концу года запустит 20 ИИ-агентов, которые будут стоить $1500–$2000 в месяц. Соответственно, если такие агенты будут работать на более дешевых моделях, то можно тратить на них в 10–40 раз меньше средств, но тут становится важным вопрос проектирования и маршрутизации. Важно для каждой задачи выбирать ИИ соразмерно сложности задачи, и уже на этом можно сэкономить значительные средства.
4. Руководитель отдела ИИ. Для внедрения ИИ в корпоративную практику нужен человек, который будет обладать достаточными полномочиями и компетенциями, чтобы драйвить этот процесс. В США такой сотрудник обойдется от 200 000 до 400 000 долларов в год.
5. Обеспечение системной трансформации за счет обучения сотрудников, поддержки консультантов, проведения мероприятий, поддержки сотрудников-лидеров трансформации.
По оценке Section, расходы в США на ИИ-трансформацию компании из 1000 человек за год составят 6,6 миллиона долларов, или 6% от общих расходов на зарплату, что эквивалентно найму 60 новых сотрудников. Ну или увольнению 60 сотрудников (или отказу от найма новых 60 сотрудников вместо тех, кто по естественным причинам покинул компанию), чтобы покрыть эти расходы.
Если говорить о других источниках финансирования ИИ-перехода, кроме увольнений, то на первое место выходит сокращение расходов на поставщиков услуг аутсорсинга: дизайн, разработка, поддержка, исследования. Привлечение меньшего количества внешних специалистов за счет использования ИИ дает экономию, которая оправдывает расходы на ИИ.
Сейчас компании используют много SaaS-решений и часто покупают лицензии, которые им не нужны. Оптимизация этих затрат за счет отказа от тех функций, которые сейчас берёт на себя ИИ, и за счет сокращения расходов на неиспользуемые лицензии тоже послужит хорошим оправданием увеличения расходов на ИИ.
Нужно планировать расходы на ИИ и на его внедрение. Начинать можно и с малого, важнее просто наличие стратегии в этом вопросе и продуманного плана. А то придётся, как мне сейчас, упрашивать бухгалтерию оплатить подписку на ИИ вне финансовых планов. И хоть сумма там смешная, но волокиты это не уменьшает.
👍1
Вы, наверное, сами чувствуете, что сейчас слово «кризис» стало тем определением, которое можно приложить практически к любому явлению. И вот, нежданно, но не удивительно, я читаю в статье про кризис vibe-кодинга применительно к дизайну https://medium.com/@WebdesignerDepot/the-vibe-coding-crisis-is-web-design-becoming-a-commodity-bb72984bdd18
Немного идеализации, но есть и здравые идеи, которые требуют рефлексии. Например, мысль о том, что ИИ повсеместно генерирует усредненный дизайн, который может быть хорошим, но не способен находить новые вызовы со стороны пользователей или предлагать инновационные решения, которых еще не было в его модели обучения.
При переходе от ручного процесса создания дизайна к ИИ мы получили быструю реализацию с готовым кодом, но усредненным значением всего.
Вайб-кодинг, в этом плане, устраняет случайность, он устраняет «неправильность», которая порой и определяет новые тенденции в дизайне.
«Чистота и профессионализм» теперь стали бесплатным товаром. Множество инструментов делают это быстрее и дешевле, чем может сделать человек. Но интуитивно ощущается, что во всем этом остается место для дизайнера, потому что он способен привнести в проект что-то авторское. Пусть даже это будут авторские ошибки.
Что еще остается в руках у человека?
Сторителлинг все еще строится человеком, потому что он базируется вокруг понимания эмоционального впечатления, которое должен оказать дизайн и повествование на посетителя. ИИ генерирует хорошие формальные тексты, но у него нет ощущения впечатления, которое они оказывают на пользователя.
Авторский стиль сейчас становится удивительно заметным. Даже не надо быть уникальным дизайнером. ИИ-генерируемые сайты так сильно бросаются в глаза из-за одинаковости подходов, что любой человеческий начинает выглядеть как глоток свежего воздуха. Это не означает, что ИИ не освоит мимикрию под человека или мы не найдем такой набор промптов, который будет создавать уникальную стилистику. Но сейчас человек, предлагающий что-то со своим чувством вкуса, кажется более ценным, чем раньше.
Становится актуальным вопрос: что стоит за дизайном? Если раньше рядовой дизайнер отвечал за оформление, а за отображение бренда в дизайне, влияние дизайна на достижение ключевых целей компании и подобные вещи отвечали дизайн-директора или кто-то из CEO, то сейчас хороший дизайнер становится таким CEO. Даже если в масштабах компании не было раньше должности с такой зоной ответственности.
Закончу цитатой из статьи: Оригинальность становится сигналом доверия. Если компания может позволить себе выглядеть «по-иному», то это показывает, что у нее есть ресурсы и таланты, чтобы быть «настоящей».
Немного идеализации, но есть и здравые идеи, которые требуют рефлексии. Например, мысль о том, что ИИ повсеместно генерирует усредненный дизайн, который может быть хорошим, но не способен находить новые вызовы со стороны пользователей или предлагать инновационные решения, которых еще не было в его модели обучения.
При переходе от ручного процесса создания дизайна к ИИ мы получили быструю реализацию с готовым кодом, но усредненным значением всего.
Вайб-кодинг, в этом плане, устраняет случайность, он устраняет «неправильность», которая порой и определяет новые тенденции в дизайне.
«Чистота и профессионализм» теперь стали бесплатным товаром. Множество инструментов делают это быстрее и дешевле, чем может сделать человек. Но интуитивно ощущается, что во всем этом остается место для дизайнера, потому что он способен привнести в проект что-то авторское. Пусть даже это будут авторские ошибки.
Что еще остается в руках у человека?
Сторителлинг все еще строится человеком, потому что он базируется вокруг понимания эмоционального впечатления, которое должен оказать дизайн и повествование на посетителя. ИИ генерирует хорошие формальные тексты, но у него нет ощущения впечатления, которое они оказывают на пользователя.
Авторский стиль сейчас становится удивительно заметным. Даже не надо быть уникальным дизайнером. ИИ-генерируемые сайты так сильно бросаются в глаза из-за одинаковости подходов, что любой человеческий начинает выглядеть как глоток свежего воздуха. Это не означает, что ИИ не освоит мимикрию под человека или мы не найдем такой набор промптов, который будет создавать уникальную стилистику. Но сейчас человек, предлагающий что-то со своим чувством вкуса, кажется более ценным, чем раньше.
Становится актуальным вопрос: что стоит за дизайном? Если раньше рядовой дизайнер отвечал за оформление, а за отображение бренда в дизайне, влияние дизайна на достижение ключевых целей компании и подобные вещи отвечали дизайн-директора или кто-то из CEO, то сейчас хороший дизайнер становится таким CEO. Даже если в масштабах компании не было раньше должности с такой зоной ответственности.
Закончу цитатой из статьи: Оригинальность становится сигналом доверия. Если компания может позволить себе выглядеть «по-иному», то это показывает, что у нее есть ресурсы и таланты, чтобы быть «настоящей».
Medium
The “Vibe Coding” Crisis: Is Web Design Becoming a Commodity?
We are entering the era of “Vibe Coding,” where AI generates the average of everything we’ve ever built, leaving the web beautiful but…
❤1
Media is too big
VIEW IN TELEGRAM
Меня увлекли эксперименты с эффектами в WebGL. Не то чтобы я делал какие-то полезные вещи для себя, скорее это наработки, которые потом можно использовать в каких-то проектах. Например, чтобы сделать эффект на странице. Пробую чистый код и разные библиотеки.
Сейчас для дизайнера проблема заключается не в том, чтобы сделать сам эффект, а в том, чтобы объяснить модели, что надо сделать. Причем отдельные вещи, такие как тайминги и детали эффектов, объяснить трудно. Поэтому я вывожу много настраиваемых параметров, чтобы посмотреть, что получается, а потом уже такие же параметры можно использовать в реальном проекте. Это точно проще, чем подбирать все вручную, хотя и выглядит диковато.
Сейчас получился скрипт с частицами, которые заполняют выделенное пространство. Это либо SVG-пространство, либо знаки из шрифтов. Последним добавил режим перемещения по области, может, потом для какой-нибудь презентации использую.
Сейчас для дизайнера проблема заключается не в том, чтобы сделать сам эффект, а в том, чтобы объяснить модели, что надо сделать. Причем отдельные вещи, такие как тайминги и детали эффектов, объяснить трудно. Поэтому я вывожу много настраиваемых параметров, чтобы посмотреть, что получается, а потом уже такие же параметры можно использовать в реальном проекте. Это точно проще, чем подбирать все вручную, хотя и выглядит диковато.
Сейчас получился скрипт с частицами, которые заполняют выделенное пространство. Это либо SVG-пространство, либо знаки из шрифтов. Последним добавил режим перемещения по области, может, потом для какой-нибудь презентации использую.
😁1
Недавно вышла статья про EPAM и результаты его ИИ-стратегии.
Тема мне близка, потому что подобную стратегию переориентации на ИИ заявляет Агима, в которой я проработал восемь лет.
В общем, с одной стороны, клиенты действительно начинают внедрять ИИ, и это создает новые заказы, но с другой — объем старых услуг сокращается быстрее, чем растут новые.
В августе EPAM снизил прогноз по росту выручки. Традиционно модель бизнеса компании построена на T&M (продаже времени сотрудников), но где-то в июле компания начала замечать, что клиенты начинают активно использовать ИИ для решения традиционных задач — тестирования, UX, разработки на JS, фронтенда — в общем-то, везде.
И при этом от внедрения ИИ клиенты ждут видимой отдачи. Они спрашивают: «Как извлечь выгоду из AI и получить положительную отдачу от инвестиций?»
«Мы видим, что наши клиенты все чаще хотят видеть обоснования целесообразности проектов, коммерческие предложения, а не просто инженерные решения, как это было в прошлом» — это слова CEO компании Балажа Фейеша.
При этом, по словам CEO, клиенты перенаправляют свои расходы на токены и графические процессоры. То есть ИИ сам становится конкурентом за бюджет и еще потом пожирает его из кармана разработчика при активном внедрении ИИ в работу.
Но всё-таки EPAM списывать еще рано. AI-native сервисы генерируют уже 11% доходов, а количество сотрудников даже чуть подросло. Да и ожидаемый оборот на одного сотрудника вырастет в этом году и будет где-то $90 000 на сотрудника в год (в 2025 году был $86 800).
На самом деле надо дождаться конца года. Если тренд на миграцию работы от подрядчика к внедряемым заказчиками ИИ стал существенно заметен только в середине лета, то разумно ожидать увидеть к концу года реальную картину.
Когда-то я скромно прогнозировал https://habr.com/ru/articles/1020600/, что в заказной разработке объем часов может уменьшиться на 42%. И если представить, что и EPAM это касается, то к концу года потери будут куда больше, чем просто снижение роста, и это можно будет увидеть по прогнозам на 2027 год.
Тема мне близка, потому что подобную стратегию переориентации на ИИ заявляет Агима, в которой я проработал восемь лет.
В общем, с одной стороны, клиенты действительно начинают внедрять ИИ, и это создает новые заказы, но с другой — объем старых услуг сокращается быстрее, чем растут новые.
В августе EPAM снизил прогноз по росту выручки. Традиционно модель бизнеса компании построена на T&M (продаже времени сотрудников), но где-то в июле компания начала замечать, что клиенты начинают активно использовать ИИ для решения традиционных задач — тестирования, UX, разработки на JS, фронтенда — в общем-то, везде.
И при этом от внедрения ИИ клиенты ждут видимой отдачи. Они спрашивают: «Как извлечь выгоду из AI и получить положительную отдачу от инвестиций?»
«Мы видим, что наши клиенты все чаще хотят видеть обоснования целесообразности проектов, коммерческие предложения, а не просто инженерные решения, как это было в прошлом» — это слова CEO компании Балажа Фейеша.
При этом, по словам CEO, клиенты перенаправляют свои расходы на токены и графические процессоры. То есть ИИ сам становится конкурентом за бюджет и еще потом пожирает его из кармана разработчика при активном внедрении ИИ в работу.
Но всё-таки EPAM списывать еще рано. AI-native сервисы генерируют уже 11% доходов, а количество сотрудников даже чуть подросло. Да и ожидаемый оборот на одного сотрудника вырастет в этом году и будет где-то $90 000 на сотрудника в год (в 2025 году был $86 800).
На самом деле надо дождаться конца года. Если тренд на миграцию работы от подрядчика к внедряемым заказчиками ИИ стал существенно заметен только в середине лета, то разумно ожидать увидеть к концу года реальную картину.
Когда-то я скромно прогнозировал https://habr.com/ru/articles/1020600/, что в заказной разработке объем часов может уменьшиться на 42%. И если представить, что и EPAM это касается, то к концу года потери будут куда больше, чем просто снижение роста, и это можно будет увидеть по прогнозам на 2027 год.
🤔1🐳1
Иногда повышение сложности регистрации может оказаться более полезным для бизнеса, чем ее упрощение. Это неочевидная идея, о которой пишут в https://www.library.hbs.edu/working-knowledge/want-people-to-commit-make-signing-up-a-little-harder.
Исследование Эшли Уилланс (Ashley V. Whillans) https://cssh.northeastern.edu/gap/wp-content/uploads/sites/62/2024/07/wp23.pdf , посвященное сложности регистрации, описывает так называемый «эффект вовлеченности» (The Buy-In Effect). Его суть противоречит классическому правилу маркетинга: «делай процесс регистрации как можно проще».
Когда регистрация полностью беспрепятственна, пользователь не чувствует ценности своего действия и легко забывает о нем. Небольшое ментальное или физическое усилие на старте заставляет человека почувствовать, что он инвестировал свои ресурсы. В результате его мозг считывает это как важное обязательство, что резко повышает вероятность реального использования сервиса в будущем.
Принцип «целенаправленного трения» (intentional friction) сейчас активно внедряется в сферах, где важно долгосрочное удержание: от корпоративных пенсионных программ до образовательных платформ.
Обратите внимание, что усложнение уменьшает количество регистраций, но повышает вовлеченность в целом в программу, в которой пользователи регистрируются. То есть надо думать не в концепции отдельных шагов и воронки (CTR), а с позиции всей активности пользователя (LTV).
Я как-то сразу вспоминаю Noom с очень длинным путем регистрации (онбординг у них на 15 минут, около 100 экранов), где в какой-то момент уже через силу продолжаешь отвечать на вопросы, потому что их очень много. Создается впечатление, что будет суперперсонализированное предложение, которое подойдет именно тебе. И взрывной рост популярности Noom и финансовая статистика говорили, что людей не отпугивала сотня вопросов. Но самое впечатляющее у Noom — это ретеншен, который через 30 дней (Retention D30) составлял 39%, что в десять раз выше среднего по области хелси-приложений.
Но, кажется, что для успешности этой стратегии нужно активно искать баланс усложнения и поддержки мотивации. Фактически усложнение должно быть нацелено на осмысление пользователем своих целей и того, зачем ему все это нужно. Простое усложнение без стратегии даст ожидаемый провал по метрикам, и не во всех ситуациях вообще эта стратегия будет работать. На это же указывала и сама автор исследования.
В общем, отличная тема. Если бы еще кому-то были нужны UX-дизайнеры, то как раз эта была бы область тонких экспериментов с ощутимой ожидаемой отдачей.
Исследование Эшли Уилланс (Ashley V. Whillans) https://cssh.northeastern.edu/gap/wp-content/uploads/sites/62/2024/07/wp23.pdf , посвященное сложности регистрации, описывает так называемый «эффект вовлеченности» (The Buy-In Effect). Его суть противоречит классическому правилу маркетинга: «делай процесс регистрации как можно проще».
Когда регистрация полностью беспрепятственна, пользователь не чувствует ценности своего действия и легко забывает о нем. Небольшое ментальное или физическое усилие на старте заставляет человека почувствовать, что он инвестировал свои ресурсы. В результате его мозг считывает это как важное обязательство, что резко повышает вероятность реального использования сервиса в будущем.
Принцип «целенаправленного трения» (intentional friction) сейчас активно внедряется в сферах, где важно долгосрочное удержание: от корпоративных пенсионных программ до образовательных платформ.
Обратите внимание, что усложнение уменьшает количество регистраций, но повышает вовлеченность в целом в программу, в которой пользователи регистрируются. То есть надо думать не в концепции отдельных шагов и воронки (CTR), а с позиции всей активности пользователя (LTV).
Я как-то сразу вспоминаю Noom с очень длинным путем регистрации (онбординг у них на 15 минут, около 100 экранов), где в какой-то момент уже через силу продолжаешь отвечать на вопросы, потому что их очень много. Создается впечатление, что будет суперперсонализированное предложение, которое подойдет именно тебе. И взрывной рост популярности Noom и финансовая статистика говорили, что людей не отпугивала сотня вопросов. Но самое впечатляющее у Noom — это ретеншен, который через 30 дней (Retention D30) составлял 39%, что в десять раз выше среднего по области хелси-приложений.
Но, кажется, что для успешности этой стратегии нужно активно искать баланс усложнения и поддержки мотивации. Фактически усложнение должно быть нацелено на осмысление пользователем своих целей и того, зачем ему все это нужно. Простое усложнение без стратегии даст ожидаемый провал по метрикам, и не во всех ситуациях вообще эта стратегия будет работать. На это же указывала и сама автор исследования.
В общем, отличная тема. Если бы еще кому-то были нужны UX-дизайнеры, то как раз эта была бы область тонких экспериментов с ощутимой ожидаемой отдачей.
Harvard Business School
Want People to Commit? Make Signing Up a Little Harder | Working Knowledge
Making products or programs slightly harder to access boosts appeal and follow-through, says research by Ashley V. Whillans.
😁1
This media is not supported in your browser
VIEW IN TELEGRAM
Еще один эксперимент в WebGL, который уже тормозит мой старенький компьютер. Фон, конечно, получается забавным, но слишком тяжеловесным. На телефон такое не поставишь.
Еще отдельно радует возможность все такое экспериментальное свободно грузить на Vercel, и они за это даже денег не берут. Так что, если захотите притормозить свой компьютер, то вот вам: https://liquid-seven.vercel.app/
Еще отдельно радует возможность все такое экспериментальное свободно грузить на Vercel, и они за это даже денег не берут. Так что, если захотите притормозить свой компьютер, то вот вам: https://liquid-seven.vercel.app/
❤2👀2😁1
This media is not supported in your browser
VIEW IN TELEGRAM
Хороший набор интерактивных визуализаций: https://uclab.fh-potsdam.de/unfoldables
Причём есть и ссылки на видео, и на статьи, посвящённые проектам. Мне было интересно смотреть даже проекты из 90-х, например Table Lens, потому что это не про уровень технологий, а про уровень мышления.
Причём есть и ссылки на видео, и на статьи, посвящённые проектам. Мне было интересно смотреть даже проекты из 90-х, например Table Lens, потому что это не про уровень технологий, а про уровень мышления.
👍1
Трудно поверить, что чуть меньше 4 лет назад OpenAI впервые представил релиз ChatGPT. И вот уже сейчас почти половина взрослого населения США заявляет, что пользуется чат-ботами, и при этом 24% используют их ежедневно.
Какая же часть Интернета сейчас создается с помощью ИИ? В PWC вышла статья с исследованием этой темы: https://www.pewresearch.org/data-labs/2026/08/20/how-much-of-the-internet-is-written-with-ai/
Если смотреть на контент новых веб-страниц, то уже треть создана с помощью ИИ.
Отдельно стоит сказать про детектор ИИ-контента, который использовался в исследовании. Для определения ИИ-контента использовался продукт Pangram Labs: https://www.pangram.com/blog/introducing-open-pangram.
У них очень высокий уровень детектирования ИИ-контента, который доходит до 99,6%. Причем это распространяется и на новые модели.
Я быстро проверил работу детектора на тексте из моего канала и на сгенерированном с помощью ИИ тексте на ту же тему — результат прекрасный. Для сравнения, я пробовал проверять русские эссе студентов в 2024 году, и все детекторы очень плохо работали с русским языком.
Какая же часть Интернета сейчас создается с помощью ИИ? В PWC вышла статья с исследованием этой темы: https://www.pewresearch.org/data-labs/2026/08/20/how-much-of-the-internet-is-written-with-ai/
Если смотреть на контент новых веб-страниц, то уже треть создана с помощью ИИ.
Отдельно стоит сказать про детектор ИИ-контента, который использовался в исследовании. Для определения ИИ-контента использовался продукт Pangram Labs: https://www.pangram.com/blog/introducing-open-pangram.
У них очень высокий уровень детектирования ИИ-контента, который доходит до 99,6%. Причем это распространяется и на новые модели.
Я быстро проверил работу детектора на тексте из моего канала и на сгенерированном с помощью ИИ тексте на ту же тему — результат прекрасный. Для сравнения, я пробовал проверять русские эссе студентов в 2024 году, и все детекторы очень плохо работали с русским языком.