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