Бутылочное горлышко программной инженерии больше не код.

      На протяжении большей части истории программного обеспечения планирование было священным. Вам нужно было планировать, прежде чем кто-либо коснется клавиатуры, потому что стоимость создания неправильного продукта могла быть настолько высокой, особенно для стартапов, что сделать все правильно с самого начала было единственной разумной стратегией. Реализация была дорогой, время инженеров было ограничено, и изменение направления, как только команда выбрала подход, могло отложить вас на месяцы. Вся структура современного программного обеспечения, дорожные карты, рамки приоритизации, квартальные ритуалы планирования, возникли как ответ на этот единственный экономический факт. Этот факт больше не актуален, и большинство инженерных организаций не успели адаптироваться. Инструменты ИИ для кодирования снизили стоимость превращения идеи в рабочее программное обеспечение. То, что раньше занимало недели реализации, теперь можно исследовать за часы. Вы можете попросить агента создать прототип трех конкурирующих подходов за ночь и выбросить два, которые не выдерживают проверки, когда вы просыпаетесь утром. Вы можете оспорить предположение с помощью рабочего демо, а не с помощью презентации. Экономика изменилась: планирование и процесс раньше были дешевле, чем создание, а теперь создание дешевле, чем встречи, которые вы проводите, чтобы решить, что строить или как это строить. Это меняет все в том, как должны работать инженерные команды. Совершенного плана больше не существует, и даже если бы он существовал, время, необходимое для его создания, означает, что вы уже проиграли тому, кто только начал строить. В Synthesia мы решили протестировать эту идею самым прямым способом. Каждый квартал наши команды по продукту, инженерии и НИОКР собираются в Лондоне, чтобы спланировать следующие три месяца работы. Исторически мы проводили большую часть этого времени в комнатах, анализируя, обсуждая и приоритизируя. Цель заключалась в том, чтобы выйти с планом, который был бы достаточно хорош, чтобы оправдать стоимость реализации. Во время нашей последней встречи мы изменили последовательность. Мы заменили первые два дня планирования хакатоном. 200 человек из различных областей инженерии, продукта, дизайна, юриспруденции, исследований и талантов образовали 70 команд и работали 28 часов подряд. Задача была проста: взять идею, построить ее, превратить результат в двухминутное демо-видео. Никаких детализированных спецификаций, никакого чрезмерного планирования – просто стройте. То, что произошло, удивило нас. Одна из выигравших команд, группа из пяти инженеров, полностью перестроила наш видеоредактор с нуля. Видеоредактор предоставляет интерфейс, похожий на PowerPoint, где пользователи нашей платформы создают видео с ИИ-аватарами. Инженеры представили полное переосмысление продукта, сосредоточенное на интерактивности, разветвленных нарративах и многовариантном повествовании. Это не было исключением; среди всех 70 команд возникла та же закономерность: когда вы даете людям сосредоточенность и убираете трение, они могут двигаться гораздо быстрее, чем кто-либо ожидал. Урок, который мы извлекли из этого эксперимента, заключается в том, что выполнение больше не является ограничением, а суждение – это то, что ограничивает. Это может противоречить рабочему предположению, с которым большинство инженерных лидеров работали на протяжении всей своей карьеры. Мы потратили годы на создание организаций, оптимизированных для выполнения: сколько функций было выпущено, сколько историй завершено, как быстро сокращается бэклог. Но когда создание становится дешевым, узкое место перемещается вверх по потоку. Трудная часть больше не заключается в написании кода. Вместо этого это знание о том, какой код стоит писать в первую очередь. Когда я говорю о суждении, я имею в виду четыре конкретные вещи. Во-первых, способность помогать менеджерам по продукту быстрее решать правильные проблемы клиентов, что требует различения между тем, что интеллектуально интересно, и тем, что на самом деле важно для пользователей и бизнеса. Во-вторых, определение того, как выглядит "отлично", прежде чем вы начнете, потому что если вы не можете сформулировать этот стандарт, вы не узнаете его, когда увидите. В-третьих, это знание о том, когда что-то достаточно хорошо, чтобы показать это пользователю, не идеально, не отполировано, просто достаточно для обучения. И, наконец, возможность быстро отказываться от идей. Когда вы можете пробовать много вещей параллельно, наиболее ценным навыком становится умение отпускать те, которые не работают, а не влюбляться в свою первую попытку, потому что ее производство стоило так много. Лучшие инженерные команды в ближайшие несколько лет не будут выигрывать за счет объема кода, они будут выигрывать за счет вкуса. Это имеет реальные последствия для того, как мы думаем о самой инженерной роли. Мы переходим от строителей к дирижерам. Агенты ИИ теперь могут выполнять большие части процесса разработки от начала до конца. Работа инженера все больше заключается в выборе правильных проблем, проверке результатов и быстрой итерации. Меньше времени на написание каждой строки и больше времени на управление системами, которые пишут строки за вас. Некоторые люди находят это угрожающим. Я думаю, что это наоборот. Утомительные части инженерии, шаблоны, повторяющееся подключение, работа, которая никогда не была действительно интересной, именно это автоматизируется в первую очередь. То, что остается, – это работа, на которой инженеры всегда хотели бы проводить больше времени: глубокое понимание проблемы, проектирование элегантных решений, принятие трудных решений о том, что строить, а что выбрасывать. Искусство сводится к своей сути. Мы держим себя в ответе за этот сдвиг в Synthesia. Мы отслеживаем использование инструментов ИИ для кодирования, таких как Claude Code и Codex, на неделе, и мы измеряем, как быстро команды могут перейти от идеи к прототипу к обратной связи от пользователей. Метрика, которая сейчас имеет значение, – это скорость цикла обучения, а не объем произведенного кода. Направление, в котором мы движемся, я бы назвал автоматизированным развитием: плотные циклы от прототипа к тестированию пользователями, к выпуску, к доработке. Agile заменяется чем-то еще более быстрым, чем-то, где разрыв между получением инсайта и его тестированием на практике сокращается до почти нуля. Таким образом, вопрос, который имеет значение для каждого инженерного лидера, читающего это, больше не "можем ли мы это построить?" Этот вопрос уже получил ответ. Вы можете построить почти все, удивительно быстро, с небольшой командой и правильными инструментами. Теперь вопрос: что вам следует построить? И есть ли у вас суждение, чтобы это знать?