Немного из 1987 года. Исследование «The Vocabulary Problem in Human-System Communication» было фундаментальной работой для эпохи активной компьютеризации, но его выводы актуальны и сейчас.

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

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

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

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

Внедрение SDD (Spec-Driven Development) подхода в разработку с ИИ обещает сокращение сроков поставки на рынок, но не за счет ускорения разработки, а за счет смещения обнаружения ошибок на более ранние стадии.
Хорошие аргументы в статье «ROI of Spec-Driven Development: how to calculate time-to-market and defend it to the board».

По оценкам отраслевых экспертов, обнаружение дефектов происходит на 40–60% быстрее, а затраты на их устранение снижаются на 75–85% при переносе этапа проверки на более ранний этап. Пятилетнее исследование в автомобильном секторе (Bosch, https://swt.informatik.uni-freiburg.de/staff/langenfeld/resources/Requirements%20Defects%20over%20a%20Project%20Lifetime ) показало, что большинство дефектов (61%) возникают из-за неполных или ошибочных требований, а обнаружение дефектов на поздних этапах обходится во много раз дороже, чем обнаружение на этапе определения требований.

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

У IBM и Microsoft было исследование подхода Test-Driven Development, в котором они показывали, что вложение на начальном этапе 15–35% приводит к снижению дефектов на 40–90% (https://github.com/tpn/pdfs/blob/master/Realizing%20Quality%20Improvement%20Through%20Test%20Driven%20Development%20-%20Results%20and%20Experiences%20of%20Four%20Industrial%20Teams%20(nagappan_tdd).pdf ).

Очень подходит к описанию этого русская пословица: «семь раз отмерь, один отрежь».

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

Хорошая статья про A/B-тестирование и ловушки этого метода https://e8.team/lab/why-ab-tests-show-nothing/

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

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

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

Будущий генеральный директор Apple Джон Тернус планирует вернуть дизайн-команде статус главной движущей силы компании. В этой связи вспомнил статью «What Makes Things Cool? Intentional Design for Innovation» , которая начиналась с примера Apple и вопроса: почему же iPhone — великий продукт и как создавать подобные дизайн-решения?

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

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

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

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

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

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

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

В общих чертах мы видим будущее решение как систему, состоящую из шести слоев.

Слой 1 · Источники данных
Документы, статьи, Jira, GitLab, Confluence и другие источники. На вход поступают тексты и связанные с ними метаданные.

Слой 2 · Извлечение фактов и связей (то, что мы сейчас проверяем в рамках R&D)
LLM выполняет семантическую разметку текста, выделяя отдельные факты, в том числе частично пересекающиеся.

На основе выделенных фактов LLM строит цепочки вида «факт → оператор → факт» (аксиомы), а затем определяет взаимосвязи между ними (индукция).

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

Слой 3 · Хранилище
Контекстно-зависимый граф, индексы фактов и метаданные источников.

Слой 4 · Планировщик запроса
Определяет стратегию поиска. Анализирует намерение пользователя, проверяет достаточность и определенность запроса (clarification), декомпозирует запрос на подзапросы, переформулирует их и выбирает оптимальный способ поиска для каждого из них: атрибутную фильтрацию, многошаговый обход графа (multi-hop) или семантический поиск.

Планировщик не выполняет поиск самостоятельно, а формирует план его исполнения.

Слой 5 · Поиск и навигация
Исполняет план поиска с использованием соответствующих инструментов. Подзапросы выполняются параллельно, после чего результаты объединяются и повторно ранжируются.

На этом же уровне реализована навигация по контекстно-зависимому графу, позволяющая смещать область поиска.

Слой 6 · Получение ответа
На основе найденной информации формируется итоговый ответ со ссылками на первоисточники.

Механизм observability отображает пользователю, по каким вершинам и связям контекстно-зависимого графа был построен ответ, обеспечивая прозрачность поиска и возможность осознанно управлять результатом.

Контуры обратной связи

Навигация по графу (6 → 5)
Пользовательский контур. Анализируя результаты поиска и их визуализацию через observability, пользователь может изменить область поиска, переместившись по контекстно-зависимому графу. После этого поиск выполняется повторно.

Переформулировка запроса (5 → 4)
Системный контур повышения качества поиска. Если полученные результаты не удовлетворяют критериям качества, исполнитель поиска сигнализирует планировщику о необходимости переформулировать запрос и повторить поиск с использованием альтернативной стратегии (self-correcting pattern).

Небольшое количество стресса помогает выполнять задачи.
Это было проверено на мышах еще в 1908 году и сформулировано в виде закона Йеркса — Додсона: производительность повышается с физиологическим или психическим возбуждением, но только до определенного момента. Когда уровень возбуждения становится слишком высоким, производительность снижается.

А теперь небольшой сдвиг от экспериментов столетней давности к сегодняшнему дню дистанционной и офисной работы.

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

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

В нас заложены механизмы, которые включаются при стрессе и помогают нам быть более эффективными. Кривая гормонов стресса (глюкокортикоидов) имеет сходство с кривой Йеркса — Додсона.

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

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

Не раз обсуждал c друзьями одну корпоративную особенность. В многих компаниях ценится не столько умение спокойно и качественно делать работу, сколько способность создавать вокруг своей работы громкую волну обсуждений. Обещания грандиозных прорывов в будущем, громкие презентации незначительных изменений и превращение обычной новой кнопки в отчете в «ГРАНДИОЗНОЕ ИННОВАЦИОННОЕ РЕШЕНИЕ, которое увеличит продажи на 47% и обеспечит рост на 29%».

Подозреваю, многие такое видели.

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

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

Вот оригинал видео https://www.facebook.com/share/r/14hhVEP4t8d/

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

В какой-то момент я решил собрать для себя единый чек-лист тестирования поисковой системы — от самых базовых проверок поискового движка до оценки агентных сценариев и работы с неполными данными. Постепенно это превратилось в структурированную систему проверки, которую можно использовать для аудита поиска. Оформил все в статью на хабре https://habr.com/ru/articles/1057356/

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

Мы с партнером оценивали сколько времени займет обеспечить автоматизированное тестирование от 0 до 3 уровня у нас вышло что-то около 4 недель рабочего времени (это для команды из аналитика и разработчика). И по первым прикидкам, сделать каждый следующий уровень будет требовать такое же количество времени.

Всегда есть повод задуматься об эффективности дизайна. И, возможно, сейчас для этого особенно подходящее время: с одной стороны, нас поджимает ИИ, а с другой — экономика движется в сторону создания впечатлений.
Вот статья: https://michalmalewicz.medium.com/popular-design-trends-that-destroy-conversion-3b3a964827cb. Она хорошо иллюстрирует влияние дизайна на эффективность продукта.

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

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

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

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

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

На мой взгляд, это прекрасный тезис. Хотя на нынешнем этапе развития дизайн-процессов я, скорее всего, остаюсь в меньшинстве.

Есть несколько важных уточнений, которые стоит учитывать, но которые не всегда считываются из статьи.

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

Но я уже далеко ушел от самой статьи.

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

Недавно написал небольшую статью о проектировании сценария для ИИ-систем https://habr.com/ru/articles/1047426/

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

Получается интересная цепочка. Чтобы спроектировать интерфейс для ИИ, нужно понимать, как выстраивать диалог с моделью. А чтобы выстраивать такой диалог, неплохо хотя бы на базовом уровне представлять, как работают механизмы рассуждений ИИ, что такое Chain of Thought, Self-Consistency, Self-Critique, оркестрация и Reasoning Pipeline. И вот вы уже стоите на поляне промпт-инжиниринга или агентного дизайна.

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

Ilya Strebulaev запустил The Unicorn Board, который содержит данные обо всех американских единорогах: https://www.data-driven.vc/

Каждый может найти там что-то интересное для себя, но я хочу обратить внимание на данные об образовании основателей.

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

Кажется, мы движемся к точке, где для облачных моделей будет достаточно промпта из пары предложений, а для локальных придётся писать несколько страниц, чтобы получить сопоставимый результат: подробно описывать шаги рассуждений, ограничения, примеры и критерии проверки. По крайней мере, именно на это указывают свежие рекомендации 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), подходы, эффективные для самых новых моделей, уже не являются универсальными, и, скорее всего, этот разрыв будет только увеличиваться.

Для тех, кто хочет улучшить работу своих промптов для решения задач с помощью ИИ, есть интересный метод, описанный в статье: https://arxiv.org/html/2607.01942v1

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

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

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

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

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 есть дельные советы о том, как улучшить работу с ИИ в рамках компании. Но самый рабочий, на мой взгляд, такой же старый, как и сам процесс менеджмента: проводить регулярные проверки рабочих процессов с высоким потреблением токенов в рамках ретроспективы спринтов, совершенствовать методы работы и обмениваться знаниями между командами.

Бывает, что в статье меня цепляет не основное содержание, а какой-нибудь факт второго порядка. Вот, например, я смотрел материалы по практикам 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) самой задачи (концепции, интерфейсы, поведение системы, изменения требований) и случайные сложности, возникающие из-за несовершенства инструментов и методов. Фактически случайную сложность ИИ нам сейчас полностью снимает.

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

Если раньше вложения в 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

Первоначальная задумка деградирует по мере воплощения, когда не на что опереться при проектировании — нет рабочего примера, нет итерационного процесса дизайна продукта. Я на этой неделе в этом убедился на собственном опыте, потратив день на попытку собрать проект для SDD-подхода (Specification-Driven Development). Идея была в том, чтобы через ИИ раскладывать бизнес-описание проекта на требования, требования — на задачи, а декомпозированные фичи визуально связывать в цепочки для дальнейшего кодирования.

Вот как ИИ описал итоговый проект, который собрал:
«Локальный AI-инструмент, превращающий описание проекта в редактируемый граф + текст: идея → структура → зависимости → исполнение → обратная связь. Не очередной AI-планировщик со списком задач, а инструмент моделирования проекта, где AI работает прямо над моделью (узлы, типизированные связи, релизы) и меняет ее только через подтвержденные изменения».

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

Это как взять LEGO-конструктор и собирать его случайным образом — только вместо кубиков тут наборы сценариев и код, который их отрабатывает. Результат получается бессмысленным, хотя в случае с ИИ он выглядит как что-то умное. А текстовое описание всего этого так вообще мечта копирайтера.

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

Mistral выпустили небольшую модель Shieldstral размером 3B, заточенную под оценку безопасности, которая показывает эффективность на уровне моделей куда большего размера: https://mistral.ai/news/shieldstral/

Мне кажется, это один из примеров того, куда двигаются специализированные модели, которые не требуют дорогого железа и которые можно развернуть внутри своего контура.

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

Русский язык уже в модели, так что можно пробовать использовать её для корпоративных нужд.

Я помню, как «Комсомольская правда» отказалась от пользовательских комментариев, потому что не могла их модерировать, а даже в отсутствие военных действий туда прилетали вещи, которые нарушали все возможные законы. Сейчас же вполне можно собрать политику для модели и обеспечить автоматическую проверку пользовательского контента на безопасность.

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

Хорошие возможности, которые можно крутить на железе всего за 100 000 рублей и даже дешевле.

SDD (Spec-Driven Development) становится новым стандартом разработки в эпоху ИИ, и для тех, кто вообще в это не погружен, можно попробовать сделать легкий первый шаг через AWS Kiro. Это среда разработки со встроенными ИИ-агентами, созданная компанией Amazon Web Services на базе Code OSS (форка VS Code).

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

Amazon щедро выдает бесплатно 50 кредитов в месяц, что, по моим прикидкам, эквивалентно 2 долларам в V0. Этого объема токенов не хватит на то, чтобы собрать что-то интересное, но если вы потратите их на планирование и спецификацию своего проекта, то можно убить сразу двух зайцев: пощупать, как на подход к разработке через SDD смотрит одна из лучших ИТ-компаний мира, и получить спецификацию своего проекта на уровне детальной проработки — считай, задаром.

Странную штуку для себя обнаружил на этой неделе: 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 такой маршрутизации нет.

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

В блоге компании 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-решений и часто покупают лицензии, которые им не нужны. Оптимизация этих затрат за счет отказа от тех функций, которые сейчас берёт на себя ИИ, и за счет сокращения расходов на неиспользуемые лицензии тоже послужит хорошим оправданием увеличения расходов на ИИ.

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