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

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

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

Так кто же прав?

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

Сначала мы рассмотрим этот конфликт через призму мышления Системы 1 и Системы 2 по Даниэлю Канеману и разберём, почему ИИ сделал медленные фазы работы более важными, а не менее. Затем обсудим иллюзию скорости: как устроено мышление вокруг стоимости переделок и почему высокая скорость на неправильном этапе в итоге замедляет весь процесс.

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

Две скорости мышления

Есть один полезный способ взглянуть на тот конфликт мнений, с которого мы начали. В своей часто цитируемой книге «Думай медленно… решай быстро» Даниэль Канеман описывает два режима мышления: один быстрый, автоматический и основанный на распознавании шаблонов, другой медленный, осознанный и аналитический.

Теперь перенесём эту идею на большие языковые модели. В разговоре с Дваркешем Пателем Андрей Карпаты описывает их как призраков или духов, своего рода статистическую выжимку из человеческих текстов, нематериальные сущности, полностью существующие в цифровой среде и имитирующие человека. На вход подаются слова, затем сопоставляются шаблоны, а на выходе появляются слова. Если задуматься, по сути это и есть мышление Системы 1.

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

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

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

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

Иллюзия скорости

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

Разумеется, это шутка, потому что всё устроено наоборот: спешка на старте, постепенно приходящее понимание, что что-то принципиально не так, и болезненная переделка, которая следует за этим. У меня было немало проектов, где я потом жалел, что не остановился и не подумал чуть дольше, прежде чем броситься в работу. Хорошо знакомо это ощущение оцепенения, когда смотришь на недели работы и понимаешь, что всё сделано неправильно.

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

И вот в чём проблема: ИИ способствует наращиваниб технического долга быстрее, чем когда-либо. Отлично, правда?

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

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

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

Когда замедление приносит результат

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

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

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

• Сначала проясните требования, потом пишите код. Потратьте 10 минут на формулировку задачи, критериев успеха и ограничений, прежде чем просить ИИ что-либо генерировать. Как должен выглядеть результат? Что находится вне области задачи? Затем попросите ИИ проанализировать и «провалидировать» всё, что вы написали, прежде чем переходить к генерации.

• Проведите предварительный разбор возможных проблем (pre-mortem). Спросите у ИИ: «Что может пойти не так с этим подходом?» — до того, как зафиксируете архитектурное решение. Это поможет выявить риски, о которых вы не подумали.

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

• Сделайте быстрый прототип. С помощью ИИ всего за несколько часов можно создать прототип, показать его заинтересованным сторонам и проверить своё понимание задачи, прежде чем вкладывать недели работы.

• Создавайте черновые внутренние инструменты. Прежде чем тратить деньги на полноценные решения, используйте ИИ, чтобы собрать грубые версии своими силами. Это позволит понять, что вам действительно нужно, а что — нет. 

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

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

Новый культурный встречный ветер

С учётом того, как сильно ИИ ускоряет процессы, если вам ещё не задавали вопрос, почему что-то делается так долго, то скоро начнут.

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

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

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

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

• Показывайте ход работы. Делитесь артефактами «медленной» фазы: документами с требованиями, эскизами архитектуры, результатами pre-mortem. Это делает невидимую работу видимой и укрепляет уверенность в том, что вы двигаетесь вперёд, а не стоите на месте.

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

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

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

Любопытно, что это хорошо соотносится с концепцией hill chart из методологии Shape Up от Basecamp: подъём в гору — это медленная фаза прояснения, когда неопределённость высока и вы только понимаете, в чём на самом деле состоит работа; спуск — это быстрая фаза реализации, когда путь уже ясен и вам остаётся просто довести дело до конца.

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

Теперь ваша очередь

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

• Потратьте 10 минут и запишите, какую именно задачу вы решаете. Как выглядит успех? Что находится вне области задачи?

• Прежде чем что-то создавать, попросите ИИ провести предварительный разбор возможных проблем для вашего подхода. Возможно, вас удивит, что именно он выявит.

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

Вместо заключения

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

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

• 14 апреля, 20:00. «Влияние нефункциональных требований на архитектуру». Записаться

• 16 апреля, 20:00. «Архитектура ИИ-сервисов для High-Load и Low-Latency инференса». Записаться

• 28 апреля, 20:00. «Почему только 5% компаний получили реальную выгоду от ИИ в 2025 году?». Записаться

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