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